Koormustestimine kui CI-teenus arendajatele

Üks probleemidest, millega tarkvarade arendajad sageli silmitsi seisavad, on inseneride - arendajate, testijate ja infrastruktuuri administraatorite - oskuste kopeerimine peaaegu igas meeskonnas. See kehtib ka kallite inseneride kohta, kes on spetsialiseerunud koormustestimisele.

Kuna nad ei saa tegeleda oma otseste kohustustega ja kasutada oma ainulaadset kogemust koormustestimise protsessi ülesehitamiseks, metodoloogia valimiseks, optimaalseid mõõdikute väärtusi seadmiseks ning koormuse profiilidega vastavuses automaatkatseid kirjutades, peavad insenerid sageli nullist üles seadma test infrastuktuuri, seadistama koormuse tööriistu, integreerima neid CI-süsteemidesse, seadistama jälgimise ja aruannete avaldamise.

Mõningaid organisatsioonilisi probleemide lahendusi testimises, mida rakendame Positive Technologies'is, leiate teises artiklis. Selles artiklis räägin koormustestide integreerimise võimalusest CI-torustikku, kasutades kontseptsiooni "koormustestimine teenusena" (load testing as a service). Te peate, kuidas ja milliseid koormuse allikaid docker-pilte saab CI-torustikus kasutada; kuidas integreerida koormuse allikad oma CI-projektiga ehitusmalli kaudu; kuidas näeb välja demo-pipeline koormustestide käivitamiseks ja tulemuste avaldamiseks. Artikkel võib olla kasulik tarkvaratestijate ja CI automatiseerijate jaoks, kes on mõelnud oma koormussüsteemi arhitektuuri üle.

Kontseptsiooni olemus

Kontseptsioon "koormustestimine teenusena" tähendab võimalust integreerida koormustööriistu Apache JMeter, Yandex.Tank ja enda raamistikud igasugusesse pideva integratsiooni süsteemi. Demona on GitLab CI, kuid esitatud põhimõtted kehtivad kõikide CI-süsteemide puhul.

"Koormustestimine teenusena" on tsentraliseeritud teenus koormustestimise läbiviimiseks. Koormustestid käivitatakse eraldi agentide basseinides, tulemuste avaldamine toimub automaatselt GitLab Pagesis, Influx DB-s ja Grafanas või testide aruandluse süsteemides (TestRail, ReportPortal jne). Automatiseerimine ja skaleerimine rakendatakse võimalikult lihtsalt - lihtsalt GitLab CI projekti sisestades ja parametriseerides tavapärast gitlab-ci.yml malli.

Käe eelis seisneb selles, et kogu CI-infrastruktuur, koormuse agente, koormusallika dokkeripildid, testimise ja aruandluse torud — toetab keskne automatiseerimise osakond (DevOps-insenerid), samas kui koormustestimise insenerid saavad keskenduda oma jõupingutustele testide arendamisele ja nende tulemuste analüüsimisele, mitte tegeleda infrastruktuuri küsimustega.

Lihtsuse huvides eeldame, et sihtotstarbeline testitav rakendus või server on eelnevalt üles seatud ja konfigureeritud (selleks võivad olla kasutatud automatiseeritud skriptid Pythonis, SaltStackis, Ansible'is jne). Sel juhul mahub kogu koormustestimise kontseptsioon teenusena kolme etapi: valmistamine, testimine, aruannete avaldamine. Üksikasjad on toodud skeemil (kõik pildid on klikitavad):

Peamised mõisted ja määratlemised koormustestimises

Koormustestimise läbiviimisel püüame järgida standardite ja metoodika ISTQB, kasutame vastavaid termineid ja soovitatud mõõdikuid. Toome lühikese loetelu peamistest mõistetest ja määratlemistest koormustestimises.

Koormuse agent (load agent) — virtuaalne masin, millel käivitatakse rakendus — koormuse allikas (Apache JMeter, Yandex.Tank või kohandatud koormuse moodul).

Testimise eesmärk (target) — server või rakendus, mis on serveris installitud ja millele koormust rakendatakse.

Testimise stsenaarium (test case) — parametreeritud sammude kogum: kasutajate toimingud ja oodatavad reaktsioonid nendele toimingutele, fikseeritud võrgu päringutega ja vastustega sõltuvalt määratud parameetritest.

Koormuse profiil või plaan (profile) — ISTQB metoodika (p. 4.2.4, lk 43) koormuse profiilid määratlevad konkreetse testi jaoks kriitiliselt olulised mõõdikud ja koormuse parameetrite muutmise võimalused testi käigus. Profiilide näiteid näete joonisel.

Test (test) — stsenaarium, millel on eelnevalt määratletud parameetrite kogum.

Testimisplaan (test-plan) — testide ja koormuse profiili kogum.

Testimisjooks (testrun) — ühe testi käivitamise üks iteratsioon täielikult täidetud koormuse stsenaariumiga ja saadud aruandega.

Võrgu päring (request) — HTTP-päring, mis saadetakse agente eesmärgile.

Võrgu vastus (response) — HTTP-vastus, mis saadetakse sihtpunktist agendile.
HTTP vastuse kood (HTTP responses status) — standardne vastuse kood rakenduste serverilt.
Tehing (transaction) — täiskäik "päring — vastus". Tehing loetakse algusest, kui päringu (request) saatmine algab, kuni vastuse (response) vastuvõtmise lõpuni.

Tehingu staatus (transactions status) — kas õnnestus edukalt lõpetada "päring – vastus" tsükkel. Kui selles tsüklis oli mingisugune viga, siis kogu tehing loetakse ebaõnnestunuks.

Latentsusaeg (latency) — aeg päringu (request) saatmise lõpust kuni vastuse (response) vastuvõtmise alguseni.

Mõõdikud (metrics) — omadused, mida määratletakse koormustestimise käigus koormatava teenuse ja koormusagendi protsessis.

Peamised mõõdikud koormuse parameetrite mõõtmiseks

Mõned kõige levinumad ja soovitatavad meetodid ISTQB (lk 36, 52) mõõdikud on esitatud allolevas tabelis. Sarnased mõõdikud agendi ja sihtpunkti jaoks on esitatud ühel real.

Koormusagendi mõõdikud
Testitava sihtsüsteemi või rakenduse mõõdikud koormuse all

Kogus  vCPU ja mälu RAM,
Ketas — koormusagendi "rauda" omadused
CPU, Mälu, ketta kasutus — protsessori, mälu ja ketta koormuse dünaamika testimise käigus. Tavaliselt mõõdetakse protsentides maksimaalselt kättesaadavatest väärtustest
maksimaalselt kättesaadavad väärtused
Võrguliiklus

(koormusagendil) — võrgu liidese läbilaskevõime serveris,
kus koormusagent on installitud.
Tavaliselt mõõdetakse baitides sekundis (bps)
(sihtpunktil) — võrgu liidese läbilaskevõime
(koormusagendil) — võrgu liidese läbilaskevõimesihtserveris. Tavaliselt mõõdetakse baitides sekundis (bps)
Virtuaalsed kasutajad

— virtuaalsete kasutajate arv,kes viivad ellu koormusstsenaariume ja
simuleerivad reaalseid kasutaja tegevusi
Virtuaalsete kasutajate staatus
, Läbimine/Ebaõnnestumine/Kokku — edukate jaebaõnnestunud virtuaalsete kasutajate staatuste arv
koormusstsenaariumide jaoks ning nende koguarv.
Tavaliselt eeldatakse, et kõik kasutajad suudavad täita

kõiki oma ülesandeid, mis on toodud koormuse profiilis.
Iga viga tähendaks, et ka reaalne kasutaja ei saaks
oma ülesannet süsteemis lahendada.
Päringud sekundis (minuuti)

— võrgu päringute arv sekundis (või minutis).Oluline omadus koormusagendi jaoks: kui palju ta suudab genereerida päringuid.

Oluline omadus koormusagendi puhul: kui palju ta saab päringuid genereerida.
Tegelikult on see rakendusse virtuaalsete kasutajate pöördumise simuleerimine.
Responses per second (minute)
— võrgureaktsioonide arv sekundis (või minutis).

Sihtteenuse oluline omadus: kui palju õnnestus
genereerida ja saata vastuseid päringutele
koormuse agendi poolt.

HTTP responses status— erinevate vastusekoodide arvu
rakenduse serverilt, mida koormuse agent sai.
Näiteks, 200 OK tähistab eduka pöördumise
ja 404 — et ressurssi ei leitud.

Latency (vastuse aeg) — aeg päringu saatmise lõpust
vastuse vastuvõtu alguseni.
Tavaliselt mõõdetakse millisekundites (ms).

Transaction response time— ühe täieliku tehingu aeg,
tsükli "päring — vastus" lõpetamine.
See on aeg päringu saatmise algusest
vastuse vastuvõtu lõpetamiseni.

Tehingu aega võib mõõta mitmel viisil: arvesse võetakse minimaalne,
maksimaalne, keskmine ja näiteks 90. percentiil.
Minimaalsed ja maksimaalsed näidud on süsteemi jõudluse äärmuslikud
seisundid.
Kaupa 90. percentiil kasutatakse kõige sagedamini,
sest see näitab enamiku kasutajate,
kes töötavad mugavalt süsteemi jõudluse piiril.
Transactions per second (minute)

— täielike tehingute arv sekundis (minutis), st kui palju rakendus suutis vastu võtta ja
töödelda päringuid ning anda vastuseid.
Tegelikult on see süsteemi läbilaskevõime.
Transactions status
, Passed / Failed / Total — edukate, ebaõnnestunud ja kogutehingute arvu.

Reaalsete kasutajate jaoks tähendab ebaõnnestunud tehing tegelikult süsteemi töövõimetust koormuse all.
Koormustestimise põhimõtteline skeem

Koormustestimise põhimõtteline skeem on väga lihtne ja koosneb kolmest põhietapist, millest olen juba rääkinud:
Prepare — Test — Report
, st testimise eesmärkide ettevalmistamine ja parameetrite seadmine koormusallikatele, seejärel koormustestide teostamine ja lõpuks testimise aruande koostamine ja avaldamine.

Märkus skeemi kohta:

QA.Tester — koormustestimise ekspert, Target — sihtrakendus, mille käitumist koormuse all tuleb teada.Klassifitseerija objektide, etappide ja sammude jaoks skeemil.

Etapid ja sammud

• Mis toimub?
• Klassifitseerijate erinevad osad

Etapp 1

Etapp 2
Etapp 3
Sisend
Väljund

Prepare: testimise ettevalmistamise etapp

LoadParameters
Ülesanne ja initsialiseerimine
kasutaja poolt
koormuse parameetrid,
mõõdikute valimine ja
testiplaani ettevalmistamine
(koormuse profiil)
Kohandatud parameetrid
koormuse agendi initsialiseerimiseks
Testiplaan
Testimise eesmärk

VM
Pilves kasutuselevõtt
virtuaalse masina
nõutud spetsifikatsioonidega
VM-i parameetrid koormuse agendi jaoks
Automatiseerimise skriptid
VM-i loomiseks
Seadistatud VM pilves
Env

Ooperisüsteemi seadistamine ja keskkonna ettevalmistamine
koormuse agendi tööks
Keskkonna parameetrid
koormuse agendi jaoks
keskkonna seadistamine
Valmistatud keskkond:
Automatiseerimise skriptid
Ooperisüsteem, teenused ja rakendused,
milleks on vajalik
LoadAgents
Koormusagendi installimine, seadistamine ja parameetriseerimine.
Valmistatud keskkond:

Või allalaadimine Docker-pildist
ette seadistatud koormuse allikaga
Docker-pilt koormuse allikast
(YT, JM või isekirjutatud raamistik)
Seadistusparameetrid
Seadistatud ja töövalmis
koormuse agent
Test: koormustestide sooritamise etapp. Allikateks on koormuse agendid, mis on juurutatud eraldatud agentide basseinidesse GitLab CI jaoks
Valmistatud keskkond:
Koormuse agendi käivitamine
valitud testiplaani

ja koormuse parameetritega

Laadi
Kohandatud parameetrid
initsialiseerimiseks
Teostamise logid
koormustestide
Süsteemi logid
Valmistatud keskkond:
Testiplaan
Testimise eesmärk
Mõõdikute dünaamika
sihtmärgi ja koormuse agendi
RunAgents
Ageneti täitmine

koormustestide stsenaariumitega
koormuse profiliga
Koormuse agendi interaktsioon
vastavalt
testimise eesmärgiga
Logid
Toored logid
Testiplaan
Testimise eesmärk

koormustestimise protsessis:
logikirjed koormuse agendi tegevustest,
katse sihtmärgi olek
ja VM, millel agent töötab
Mõõdikud
Toored mõõdikud testimise käigus

Mõõdikute dünaamika
sihtmärgi ja koormuse agendi
RunAgents

Mõõdikute dünaamika
sihtmärgi ja koormuse agendi

Aruanne: testiaruande ettevalmistamise etapp
Generator

Kogutud töötlemine

koormussüsteemi ja
seire süsteem toored
mõõdikud ja logid
Aruande koostamine
inimese loetavas formaadis,
võimalikult analüüsielementidega
Mõõdikute dünaamika
sihtmärgi ja koormuse agendi
Töödeldud toored logid
Mõõdikute dünaamika
sihtmärgi ja koormuse agendi
RunAgents
vormingus, mis sobib
välistele salvestuslahendustele
Statistiline koormusaruanne,
mis sobib inimese analüüsimiseks
Publish
Aruande avaldamine
koormustestimise kohta

välises teenuses
Koormustestimise aruande avaldamine
välises teenuses
tulemus.
teenuses
Töödeldud "toor"
logid formaadis, mis sobib
väliseksportimiseks
salvestuskohtadesse
Salvestatud välises
salvestuskojas aruanne
koormusest, sobivad
inimese analüüsiks

Koormusallikate ühendamine CI-mallis

Liigume praktilise osa juurde. Soovin näidata, kuidas oleme mõnedes projektides ettevõttes Positive Technologies rakendanud koormustestimise kontseptsiooni teenusena.

Esmalt lõid meie DevOps-insenerid GitLab CI-s eraldiseisva agentide hulga koormustestide käivitamiseks. Et mitte segada neid mallides teistega, näiteks kogumallide, hulga tõttu, lisasime nendele agentidele sildid, tags: load. Võib kasutada kõiki muid arusaadavaid silte. Need määratakse registreerimise ajal GitLab CI Runners.

Kuidas teada vajalikku "rauda"? Koormusagentide omadused — piisav vCPU, RAM ja Disk — võivad olla arvutatud lähtudes sellest, et agendi peal peavad olema käivitatud Docker, Python (Yandex.Tank jaoks), GitLab CI agent ja Java (Apache JMeteri jaoks). JMeteri Java jaoks soovitatakse kasutada vähemalt 512 MB RAM-i ja maksimaalselt 80% saadaval olevast mälust..

Seega, lähtudes meie kogemusest, soovitame kasutada koormusagentide jaoks vähemalt: 4 vCPU, 4 GB RAM, 60 GB SSD. Võrgukaardi läbilaskevõime määratakse koormusprofiili nõuete alusel.

Meil kasutatakse peamiselt kahte koormusallikat — Apache JMeter ja Yandex.Tank docker-pildid.

Yandex.Tank on Yandexi avatud lähtekoodiga tööriist koormustestimise läbiviimiseks. Selle modulaarses arhitektuuris on kõrge jõudlusega asünkroonne hit-based HTTP-päringute genereerija Phantom. Tankil on sisseehitatud testitava serveri ressursside jälgimine SSH-protokolli kaudu, see suudab automaatselt lõpetada testi määratud tingimuste täitmisel, oskab tulemusi kuvada nii konsoolis kui ka graafikutena ning sellele saab ühendada oma mooduleid funktsionaalsuse laiendamiseks. Muide, kasutasime Tanki, kui see polnud veel ainult peavool. Artiklis "Yandex.Tank ja koormustestimise automatiseerimine" saab lugeda ajalugu, kuidas 2013. aastal viisime läbi selle abiga koormustestimise PT Application Firewall ühe meie ettevõtte toote.

Apache JMeter — avatud lähtekoodiga koormustestimise tööriist Apache'ilt. Seda saab kasutada nii staatiliste kui dünaamiliste veebirakenduste testimiseks. JMeter toetab suurt hulka protokolle ja suhtlemismehhanisme rakendustega: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET jne), SOAP / REST veebiteenused, FTP, TCP, LDAP, SMTP(S), POP3(S) ja IMAP(S), andmebaase JDBC kaudu, suudab käivitada shell-käske ja töötada Java-objektidega. JMeteril on IDE testiplaanide loomiseks, silumiseks ja täitmiseks. Samuti on olemas CLI tööks mis tahes Java-ühilduvas operatsioonisüsteemis (Linux, Windows, Mac OS X). Tööriist suudab dünaamiliselt genereerida HTML-aruande testimise kohta.

Kasutusmugavuse tagamiseks meie ettevõttes ja selleks, et testijad saaksid ise keskkonda muuta ja lisada, oleme loonud koormuse allikate Docker-piltide kogumise GitLab CI-s, avaldades need sisemises docker-repositooriumis Artifactory. Nii on nende integreerimine koormustestimise torustikes kiirem ja lihtsam. Kuidas teha docker push registrisse läbi GitLab CI — vaadake juhendis.

Meie baas Docker-fail Yandex.Tank jaoks on järgmine:

Dockerfile 
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]

Ja Apache JMeteri jaoks on see:

Dockerfile 
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]

Kuidas meie pideva integreerimise süsteem töötab, saate lugeda artiklist «Arendustegevuse automatiseerimine: kuidas me Positive Technologies'is rakendasime DevOpsi ideid».

Mall ja torustik

Näidis mall koormustestide läbiviimiseks on saadaval projektis demo-load. Failis readme -failis .gitlab-ci.ymlleiate juhise mallist kasutamiseks. Otseses mallis (failis

) on märkuseid selle kohta, mille eest vastutab samm. Mall on väga lihtne ja demonstreerib kolme etappi koormustestimisest, nagu on kirjeldatud ülaltoodud skeemis: ettevalmistamine, testimine ja aruande avaldamine. Selle eest vastutavad: stages.

1. Prepare, Test ja Report Etapp Prepare
2. Prepare, Test ja Report tuleb kasutada testimise eesmärkide eelnevaks seadistamiseks või nende kättesaadavuse kontrollimiseks. Koormuse allikate keskkonda seadistama ei pea, need on eelnevalt loodud Docker-piltidena ja väljastatud docker registrisse: piisab, kui määrata vajalik versioon etapis Test. Kuid neid saab ka uuesti ehitada ja luua oma modifitseeritud pildid. kasutatakse koormusallika määramiseks, testide käivitamiseks ja testimise artefaktide salvestamiseks. Saate valida mistahes koormusallika: Yandex.Tank, Apache JMeter, oma või kõik koos. Ebavajalike allikate väljalülitamiseks piisab, kui kommenteerida või eemaldada töökoht. Koormusallikate sisenemiskohad:
   • Yandex.Tank käivitamise parameetrid määratakse failis./tests/yandextank.sh,
   • Apache JMeter käivitamise parameetrid määratakse failis ./tests/jmeter.sh.

   Märkus: kokkupaneku konfiguratsiooni mall on mõeldud CI-süsteemiga suhtlemise seadistamiseks ja ei eelda testiloogika sisaldamist. Testide jaoks määratakse sisenemiskoht, kus asub juhtimisbash-skript. Testide käivitamise viis, aruannete koostamine ja testitsenaariumid peavad olema QA-inseneride poolt ellu viidud. Demopreemia puhul kasutatakse mõlema koormusallika puhul kui kõige lihtsamat testi Yandexi eeslehe päringut. Skriptid ja testiparameetrid asuvad kataloogis ./tests.

3. Etapis Aruanne on vaja kirjeldada testimistulemuste avaldamise viise, mis on saadud Test etapil, välistele salvestuskohtadele, näiteks GitLab Pages'ile või spetsiaalsetele aruandlussüsteemidele. GitLab Pages'i puhul on vajalik, et testide lõppedes oleks kataloog ./public mitte tühi ja sisaldaks vähemalt faili index.html. GitLab Pages teenuse toimimise nüansse saab lugeda linki pidi.

   Näited, kuidas andmeid eksportida:

   • JMeterist GitLab Pages'i,
   • Yandex.Tankist InfluxDB ja Grafana.

   Avaldamise seadistamise juhised:

   • HTML-statika suunamiseks GitLab Pages'i,
   • InfluxDB-sse ja sealt edasi Grafana.

Demopreemia korral koosnevad koormustestide torujuhtmed kahest koormusallikast (üht neist saab välja lülitada) järgmistest:

Apache JMeter suudab ise genereerida HTML-aruande, seega on mõttekas seda GitLab Pages'is tavapäraste vahendite abil salvestada. Nii näeb välja Apache JMeter aruanne:

Demopreemia puhul Yandex.Tank jaoks näete ainult vale tekstiaruannet GitLab Pages'i jaotis. Testimise käigus suudab Tank salvestada tulemusi InfluxDB andmebaasi ja sealt edasi saab neid näiteks kuvada Grafanas (seadistamine toimub failis ./tests/example-yandextank-test.yml). Nii näeb Tanki aruanne Grafanas välja:

Elulookirjeldus

Artiklis räägin ma kontseptsioonist "koormustestimine teenusena" (load testing as a service). Peamine idee on kasutada eelseadistatud koormusagentide basseinide infrastruktuuri, koormusallikate Docker-pilte, aruandesüsteeme ning neid ühendavat pipelines'i GitLab CI-s, mis põhineb lihtsal mallil .gitlab-ci.yml (näide linki pidi). Kõike seda toetab väike automatiseerimise inseneride meeskond ning seda kopeeritakse toote meeskondade nõudmisel. Loodan, et see aitab teil sarnase skeemi ettevalmistamisel ja rakendamisel teie ettevõttes. Aitäh tähelepanu eest!

P. S. Soovin väga tänada oma kolleege, Sergei Kurbanovi ja Nikolai Yusevi, tehnilise abi eest kontseptsiooni rakendamisel load testing as a service meie ettevõttes.

Autor: Timur Gilmullin — tehnoloogia ja arendusprotsesside osakonna asejuht (DevOps) ettevõttes Positive Technologies

Allikas: habr.com