Eitt af þeim vandamálum sem framleiðendur hugbúnaðar sem standa frammi fyrir mörgum vörum standa oft frammi fyrir er tvítekning á hæfni verkfræðinga - þróunaraðila, prófunaraðila og innviðastjórnenda - í næstum öllum liðum. Þetta á einnig við um dýra verkfræðinga - sérfræðinga á sviði hleðsluprófa.
Í stað þess að sinna beinum skyldum sínum og nota einstaka reynslu sína til að byggja upp álagsprófunarferli, velja aðferðafræði, bestu mælikvarða og skrifa sjálfvirkar prófanir í samræmi við álagssnið, þurfa verkfræðingar oft að beita prófunarinnviðum frá grunni, stilla hleðsluverkfæri og fella þau inn. sig í CI kerfum, sett upp eftirlit og birtingu skýrslna.
Þú getur fundið lausnir á nokkrum skipulagsvandamálum í prófunum sem við notum hjá Positive Technologies í . Og í þessu mun ég tala um möguleikann á að samþætta álagsprófanir í sameiginlega CI leiðslu með því að nota hugtakið „álagsprófun sem þjónusta“ (álagspróf sem þjónusta). Þú munt læra hvernig og hvaða docker myndir af hleðslugjafa er hægt að nota í CI leiðslunni; hvernig á að tengja hleðslugjafa við CI verkefnið þitt með því að nota byggingarsniðmát; hvernig kynningarleiðslan lítur út til að keyra álagspróf og birta niðurstöðurnar. Greinin gæti verið gagnleg fyrir hugbúnaðarprófunarverkfræðinga og sjálfvirkniverkfræðinga í CI sem eru að hugsa um arkitektúr álagskerfisins.
Kjarni hugtaksins
Hugmyndin um álagsprófun sem þjónustu felur í sér getu til að samþætta álagsverkfæri Apache JMeter, Yandex.Tank og þína eigin ramma í handahófskennt samfellt samþættingarkerfi. Sýningin verður fyrir GitLab CI, en meginreglurnar eru sameiginlegar fyrir öll CI kerfi.
Álagsprófun sem þjónusta er miðlæg þjónusta fyrir álagsprófun. Hleðslupróf eru keyrð í sérstökum umboðshópum, niðurstöðurnar eru birtar sjálfkrafa í GitLab Pages, Influx DB og Grafana eða í prófunarskýrslukerfum (TestRail, ReportPortal osfrv.). Sjálfvirkni og stærðarstærð er útfærð eins einfaldlega og hægt er - með því að bæta við og breyta venjulegu gitlab-ci.yml sniðmáti í GitLab CI verkefninu.
Kosturinn við þessa nálgun er að allur CI innviði, hleðslumiðlar, hafnarmyndir af hleðsluuppsprettum, prófunarleiðslur og birtingarskýrslur eru viðhaldið af miðlægri sjálfvirknideild (DevOps verkfræðingar), á meðan hleðsluprófunarverkfræðingar geta einbeitt kröftum sínum að þróun prófunar. og greiningu á niðurstöðum þeirra, án þess að takast á við innviðamál.
Til að einfalda lýsinguna munum við gera ráð fyrir að markforritið eða miðlarinn sem verið er að prófa hafi þegar verið settur á markað og stillt fyrirfram (sjálfvirk forskriftir í Python, SaltStack, Ansible o.s.frv. er hægt að nota fyrir þetta). Þá passar allt hugtakið álagsprófun sem þjónustu í þrjú stig: undirbúningur, prófun, birting skýrslna. Nánari upplýsingar á skýringarmyndinni (allar myndir eru smellanlegar):
Grunnhugtök og skilgreiningar í álagsprófun
Við framkvæmd álagsprófa reynum við að fylgja , notaðu viðeigandi hugtök og ráðlagðar mæligildi. Ég mun gefa stuttan lista yfir helstu hugtök og skilgreiningar í álagsprófun.
Hleðslumiðill - sýndarvél sem forritið verður ræst á - hleðslugjafinn (Apache JMeter, Yandex.Tank eða sjálfskrifuð hleðslueining).
Prófmarkmið (markmið) - þjónn eða forrit uppsett á þjóninum sem verður háð hleðslu.
Prófunaratburðarás (prófunartilvik) - sett af færibreytum skrefum: notendaaðgerðir og væntanleg viðbrögð við þessum aðgerðum, með föstum netbeiðnum og svörum, allt eftir tilgreindum breytum.
Prófíll eða hleðsluáætlun (snið) - kl (Kafli 4.2.4, bls. 43) álagssnið skilgreina mælikvarða sem eru mikilvægir fyrir tiltekið próf og valkosti til að breyta álagsbreytum meðan á prófun stendur. Þú getur séð dæmi um snið á myndinni.
Próf — handrit með fyrirfram ákveðnu setti af breytum.
Prófáætlun (prófunaráætlun) - sett af prófum og hleðslusniði.
Testran (testrun) - ein endurtekning á að keyra eitt próf með fullkominni álagssviðsmynd og móttekinni skýrslu.
Netbeiðni (beiðni) — HTTP beiðni send frá umboðsmanni til markmiðs.
Netsvörun (svörun) — HTTP svar sent frá markinu til umboðsmannsins.
HTTP svarkóði (staða HTTP svars) - staðall svarkóði frá forritaþjóninum.
Færsla er heill beiðni-svar hringrás. Færsla er talin frá upphafi sendingar beiðni (beiðni) þar til svars (svars) er lokið.
Staða viðskipta - hvort hægt hafi verið að ljúka beiðni-svörunarlotunni. Ef einhver villa var í þessari lotu, þá er öll viðskiptin talin misheppnuð.
Svartími (töf) - tíminn frá lokum sendingar beiðni (beiðni) þar til svars (svars) hefst.
Hlaða mæligildi — eiginleikar hleðsluþjónustunnar og hleðslumiðilsins sem ákvarðað er í álagsprófunarferlinu.
Grunnmælingar til að mæla álagsfæribreytur
Sumt af því sem oftast er notað og mælt með í aðferðafræðinni (bls. 36, 52) mæligildin eru sýnd í töflunni hér að neðan. Svipaðar mælingar fyrir umboðsmann og miða eru skráðar á sömu línu.
Mælingar fyrir hleðslumiðilinn
Mælingar á markkerfinu eða forritinu sem verið er að prófa undir álagi
Númer vCPU og minni RAM,
Disk - "járn" eiginleikar hleðslumiðilsins
CPU, Minni, diskanotkun - gangverki CPU, minni og hleðslu disks
í prófunarferlinu. Venjulega mælt sem hlutfall af
hámarks tiltækum gildum
Netafköst (á hleðsluefni) - afköst
netviðmót á þjóninum,
þar sem hleðslumiðillinn er settur upp.
Venjulega mælt í bætum á sekúndu (bps)
Netafköst(á marki) - bandbreidd netviðmóts
á markþjóninum. Venjulega mælt í bætum á sekúndu (bps)
Sýndarnotendur- fjöldi sýndarnotenda,
innleiða álagssviðsmyndir og
líkja eftir raunverulegum aðgerðum notenda
Staða sýndarnotenda, Samþykkt/Tókst/Totalt — fjöldi árangursríkra og
misheppnaðar stöður sýndarnotenda
fyrir álagssviðsmyndir, svo og heildarfjölda þeirra.
Almennt er búist við að allir notendur hafi getað lokið
öll verkefnin þín sem tilgreind eru í hleðslusniðinu.
Sérhver villa mun þýða að raunverulegur notandi mun ekki geta það
leysa vandamál þitt þegar þú vinnur með kerfið
Beiðnir á sekúndu (mínútu)- fjöldi netbeiðna á sekúndu (eða mínútu).
Mikilvægur eiginleiki hleðslumiðlara er hversu margar beiðnir hann getur framkallað.
Reyndar er þetta eftirlíking af aðgangi sýndarnotenda að forritinu
Svör á sekúndu (mínútu)
- fjöldi netsvara á sekúndu (eða mínútu).
Mikilvægur eiginleiki markþjónustunnar: hversu mikið
búa til og senda svör við fyrirspurnum með
hleðslumiðill
HTTP svar staða— fjöldi mismunandi svarkóða
frá forritaþjóninum sem hleðsluþjónninn fékk.
Til dæmis, 200 OK þýðir vel heppnað símtal,
og 404 - að auðlindin fannst ekki
Leyfi (viðbragðstími) - tími frá lokum
að senda beiðni (beiðni) áður en byrjað er að fá svar (svar).
Venjulega mælt í millisekúndum (ms)
Viðbragðstími viðskipta— tími einnar fullrar færslu,
lokið við beiðni-svar hringrás.
Þetta er tíminn frá upphafi sendingar beiðninnar (beiðni)
þar til lokið er að fá svar (svar).
Hægt er að mæla viðskiptatíma í sekúndum (eða mínútum)
á nokkra vegu: íhugaðu lágmarkið,
hámark, meðaltal og til dæmis 90. hundraðshluti.
Lágmarks- og hámarksaflestur eru öfgafullir
frammistöðustöðu kerfisins.
Níutugasta hundraðshlutinn er oftast notaður,
eins og það sýnir flestum notendum,
vinna þægilega á þröskuldi kerfisframmistöðu
Færslur á sekúndu (mínútu) - fjöldi heill
viðskipti á sekúndu (mínútu),
það er hversu mikið umsóknin gat tekið við og
afgreiða beiðnir og gefa út svör.
Í raun er þetta afköst kerfisins
Staða viðskipta , Samþykkt / mistókst / Samtals - fjöldi
heppnuð, misheppnuð og heildarfjöldi viðskipta.
Fyrir alvöru notendur misheppnað
viðskiptin munu í raun þýða
vanhæfni til að vinna með kerfið undir álagi
Skýringarmynd hleðsluprófunar
Hugmyndin um álagsprófun er mjög einföld og samanstendur af þremur meginþrepum, sem ég hef þegar nefnt: Undirbúa-próf-skýrslu, það er að útbúa prófunarmarkmið og stilla færibreytur fyrir álagsuppsprettur, framkvæma síðan álagspróf og í lokin búa til og birta prófunarskýrslu.
Skýringarmyndir:
- QA.Tester er sérfræðingur í álagsprófum,
- Target er markforritið sem þú vilt vita um hegðun þess undir álagi.
Flokkari eininga, þrepa og þrepa í skýringarmyndinni
Stig og skref
Hvað er að gerast
Hvað er við innganginn
Hver er útkoman
Undirbúa: undirbúningsstig fyrir prófun
LoadParameters
Stilling og frumstilling
notandi
hlaða breytur,
val á mæligildum og
undirbúningur prófáætlunar
(hlaða prófíl)
Sérsniðnir valkostir fyrir
frumstilling hleðslumiðils
Prófaáætlun
Tilgangur prófunar
VM
Uppsetning skýja
sýndarvél með
nauðsynlegir eiginleikar
VM stillingar fyrir hleðslumiðil
Sjálfvirkni forskriftir fyrir
VM sköpun
VM stilltur í
ský
Framsfl
OS uppsetning og undirbúningur
umhverfi fyrir
hleðslumiðlarastarf
Umhverfisstillingar fyrir
hleðslumiðill
Sjálfvirkni forskriftir fyrir
umhverfisstillingar
Undirbúið umhverfi:
OS, þjónusta og forrit,
nauðsynleg til vinnu
hleðslumiðill
LoadAgents
Uppsetning, uppsetning og breytustilling
hleðslumiðill.
Eða að hlaða niður docker mynd frá
forstilltur hleðslugjafi
Hlaða upprunalegu docker mynd
(YAT, JM eða sjálfskrifaður rammi)
Stillingar
hleðslumiðill
Sett upp og tilbúið
til vinnuálagsfulltrúa
Próf: stigi framkvæmdar álagsprófa. Heimildir eru hleðslumiðlar sem eru notaðir í sérstökum umboðshópum fyrir GitLab CI
hlaða
Ræsir hleðslumiðilinn
með valinni prófunaráætlun
og hlaða breytur
Notendavalkostir
til frumstillingar
hleðslumiðill
Prófaáætlun
Tilgangur prófunar
Framkvæmdaskrár
álagspróf
Kerfisskrár
Dynamics breytinga á markmælingum og álagsmiðli
Keyra umboðsmenn
Framkvæmd umboðsmanns
fullt af prófskriftum
í samræmi við
hlaða snið
Hlaða Agent Interaction
í þeim tilgangi að prófa
Prófaáætlun
Tilgangur prófunar
Logs
Safn af „hráum“ annálum
við álagsprófun:
virkniskrár hleðslumiðils,
ástand prófunarmarkmiðsins
og VM sem rekur umboðsmanninn
Framkvæmdaskrár
álagspróf
Kerfisskrár
Bragfræði
Að safna „hráum“ mælingum meðan á prófun stendur
Dynamics breytinga á markmælingum
og hleðslumiðill
Skýrsla: undirbúningsstig prófskýrslu
rafall
Vinnsla safnað
hleðslukerfi og
eftirlitskerfi "hrátt"
mæligildi og logs
Skýrslugerð í
mannslæsilegt form
mögulegt með þáttum
sérfræðingar
Framkvæmdaskrár
álagspróf
Kerfisskrár
Dynamics breytinga á mæligildum
skotmark og hleðsluefni
Unnið "hrá" logs
á sniði sem hentar
hleður upp á ytri geymslu
Stöðugt hleðsluskýrsla,
mannlæsilegur
Birta
Útgáfa skýrslunnar
um álag
próf í ytri
þjónustu
Unnið „hrátt“
logs á viðeigandi sniði
fyrir affermingu til ytra
geymslur
Vistað í ytri
geymsluskýrslur um
hlaða, hentugur
fyrir manngreiningu
Að tengja hleðslugjafa í CI sniðmáti
Við skulum halda áfram að verklega hlutanum. Mig langar að sýna hvernig á sumum verkefnum í fyrirtækinu við höfum innleitt hugmyndina um álagsprófun sem þjónustu.
Í fyrsta lagi, með hjálp DevOps verkfræðinga okkar, bjuggum við til sérstakan hóp af umboðsmönnum í GitLab CI til að keyra álagspróf. Til að rugla þeim ekki saman í sniðmátum við önnur, eins og samsetningarsamstæður, bættum við merkjum við þessa umboðsmenn, : hlaða. Þú getur notað hvaða önnur skiljanleg merki sem er. Þeir spyrja GitLab CI Runners.
Hvernig á að finna út nauðsynlegan kraft með vélbúnaði? Hægt er að reikna út eiginleika hleðslumiðla - nægilegan fjölda vCPU, vinnsluminni og diska - út frá því að Docker, Python (fyrir Yandex.Tank), GitLab CI umboðsmaður, Java (fyrir Apache JMeter) ættu að vera í gangi á umboðsmanninum . Fyrir Java undir JMeter er einnig mælt með því að nota að lágmarki 512 MB af vinnsluminni og, sem efri mörk, .
Þannig, byggt á reynslu okkar, mælum við með að nota að minnsta kosti 4 vCPUs, 4 GB vinnsluminni, 60 GB SSD fyrir hleðslumiðla. Afköst netkortsins eru ákvörðuð út frá kröfum hleðslusniðsins.
Við notum aðallega tvo hleðslugjafa - Apache JMeter og Yandex.Tank docker myndir.
er opinn uppspretta tól frá Yandex fyrir álagsprófun. Einingaarkitektúr þess er byggður á afkastamiklum ósamstilltum HTTP-beiðnarrafalli Phantom. Tankurinn er með innbyggt eftirlit með auðlindum þjónsins sem er í prófun í gegnum SSH samskiptareglur, getur sjálfkrafa stöðvað prófið við tilteknar aðstæður, getur sýnt niðurstöðurnar bæði í stjórnborðinu og í formi myndrita, þú getur tengt einingarnar þínar til þess að auka virkni. Við the vegur, við notuðum Tank þegar það var ekki enn mainstream. Í greininni "» þú getur lesið söguna af því hvernig við gerðum álagsprófanir með því árið 2013 er ein af vörum fyrirtækisins okkar.
er opinn uppspretta hleðsluprófunartæki frá Apache. Það er jafn vel hægt að nota til að prófa bæði kyrrstæð og kraftmikil vefforrit. JMeter styður gríðarlegan fjölda samskiptareglna og leiða til að hafa samskipti við forrit: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET osfrv.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) og IMAP(S), gagnagrunnar í gegnum JDBC, geta framkvæmt skel skipanir og unnið með Java hluti. JMeter er með IDE til að búa til, kemba og framkvæma prófunaráætlanir. Það er líka CLI fyrir stjórnlínuaðgerðir á hvaða Java-samhæfu stýrikerfi sem er (Linux, Windows, Mac OS X). Tólið getur búið til HTML prófunarskýrslu á virkan hátt.
Til að auðvelda notkun innan fyrirtækis okkar, fyrir getu prófunaraðila sjálfra til að breyta og bæta umhverfinu, gerðum við smíði á bryggjumyndum af hleðsluheimildum á GitLab CI með birtingu á innri . Þetta gerir það hraðar og auðveldara að tengja þau í leiðslur fyrir álagsprófanir. Hvernig á að gera docker push to registry í gegnum GitLab CI - sjá .
Við tókum þessa grunnskjalaskrá fyrir Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Og fyrir Apache JMeter þennan:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Þú getur lesið hvernig samfellda samþættingarkerfið okkar virkar í greininni "'.
Sniðmát og leiðsla
Dæmi um sniðmát til að framkvæma álagspróf er til í verkefninu . Í Þú getur lesið leiðbeiningarnar um notkun sniðmátsins. Í sniðmátinu sjálfu (skrá ) eru athugasemdir um hvað hvert skref ber ábyrgð á.
Sniðmátið er mjög einfalt og sýnir þrjú stig álagsprófunar sem lýst er á skýringarmyndinni hér að ofan: að undirbúa, prófa og birta skýrslur. Ber ábyrgð á þessu : Undirbúa, prófa og tilkynna.
- Svið ætti að nota til að forstilla prófunarmarkmið eða athuga hvort þau séu tiltæk. Umhverfið fyrir hleðslugjafa þarf ekki að vera stillt, þær eru forsmíðaðar sem bryggjumyndir og settar inn í hleðslukerfið: tilgreindu bara þá útgáfu sem óskað er eftir á prófunarstigi. En þú getur endurbyggt þær og búið til þínar eigin breyttu myndir.
- Svið notað til að tilgreina hleðslugjafa, keyra prófanir og geyma prófunargripi. Þú getur valið hvaða hleðslugjafa sem er: Yandex.Tank, Apache JMeter, þinn eigin eða allt saman. Til að slökkva á óþarfa heimildum skaltu bara skrifa athugasemdir eða eyða verkinu. Aðgangsstaðir fyrir hleðslugjafa:
- Ræsingarbreytur fyrir Yandex.Tank eru tilgreindar í .,
- Apache JMeter ræsingarfæribreytur eru tilgreindar í skránni .
Athugið: Samsetningarstillingarsniðmátið er notað til að setja upp samskipti við CI kerfið og felur ekki í sér staðsetningu prófunarrökfræði í því. Fyrir próf er inngangsstaðurinn tilgreindur, þar sem stjórnbash forskriftin er staðsett. Aðferðin við að keyra próf, búa til skýrslur og prófunarforskriftirnar sjálfar verða að vera útfærðar af QA verkfræðingum. Í kynningu, fyrir báða hleðslugjafana, er Yandex aðalsíðubeiðnin notuð sem einfaldasta prófið. Forskriftir og prófunarfæribreytur eru í möppunni .
- Á sviðinu þú þarft að lýsa því hvernig á að birta prófunarniðurstöðurnar sem fengust á prófunarstigi á ytri geymslur, til dæmis á GitLab síður eða sérstök skýrslukerfi. GitLab Pages krefst þess að ./public mappan sé ekki tóm og innihaldi að minnsta kosti index.html skrá eftir að prófunum er lokið. Þú getur lesið um blæbrigði GitLab Pages þjónustunnar. .
Dæmi um hvernig á að flytja út gögn:
- frá JMeter til ,
- frá Yandex.Tank til .
Leiðbeiningar um uppsetningu birtingar:
- HTML tölfræði í ,
- til InfluxDB og svo til .
Í kynningardæminu lítur leiðslan með álagsprófum og tveimur álagsgjöfum (þú getur slökkt á óþarfa) svona út:
Apache JMeter getur búið til HTML skýrslu sjálft, svo það er arðbærara að vista hana á GitLab síðum með stöðluðum verkfærum. Svona lítur Apache JMeter skýrslan út:
Í kynningardæminu fyrir Yandex.Tank muntu aðeins sjá í hlutanum fyrir GitLab síður. Á meðan á prófun stendur getur tankurinn vistað niðurstöðurnar í InfluxDB gagnagrunninum og þaðan er hægt að birta þær til dæmis í Grafana (stillingar eru gerðar í skránni ). Svona lítur skýrsla Tanks út í Grafana:
Yfirlit
Í greininni talaði ég um hugtakið "load testing as a service" (load testing as a service). Meginhugmyndin er að nota innviði fyrirfram stilltra hópa hleðslumiðla, hafnarmyndir af hleðsluheimildum, skýrslukerfum og leiðslu sem sameinar þau í GitLab CI byggt á einföldu .gitlab-ci.yml sniðmáti (dæmi ). Allt þetta er stutt af litlu teymi sjálfvirkniverkfræðinga og endurtekið að beiðni vöruteyma. Ég vona að þetta muni hjálpa þér við að undirbúa og innleiða svipað kerfi í þínu fyrirtæki. Takk fyrir athyglina!
PS Ég vil þakka samstarfsmönnum mínum, Sergey Kurbanov og Nikolai Yusev, kærar þakkir fyrir tæknilega aðstoð við innleiðingu hugmyndarinnar um álagsprófun sem þjónustu í fyrirtækinu okkar.
Höfundur: - Staðgengill Yfirmaður tækni- og þróunarferla (DevOps) hjá Positive Technologies
Heimild: www.habr.com