Koormustestimine CI-teenusena arendajatele

Üks peamisi probleeme, millega tihti silmitsi seisavad mitme toote tarkvara pakkujad, on inseneride – arendajate, testijate ja infrastruktuuri administraatorite – oskuste dubleerimine peaaegu igas meeskonnas. See kehtib ka kallite inseneride – koormustestimise spetsialistide kohta.

Kuna insenerid peavad sageli alates nullist üles seadma testimistööriistade infrastruktuuri, seadistama koormustestimise tööriistu ning integreerima need CI-süsteemidesse, seadistama jälgimist ja aruannete avaldamist, jääb neil vähem aega oma põhikohustuste täitmiseks ja oma ainulaadse kogemuse rakendamiseks koormustestimise protsessi ülesehitamisel, meetodite valimisel, optimaalsete mõõdikute määramisel ja automaatsete testide kirjutamisel koormusprofiilide järgi.

Mõningate organisatsiooniliste probleemide lahendustega testimisel, mida rakendame Positive Technologies, võite tutvuda teises artiklis. Selles artiklis räägin koormustestide integreerimisest üldisesse CI-protsessi mõiste „koormustestimine teenusena” (load testing as a service) abil. Saate teada, kuidas ja milliseid koormusallikaid Docker-pilte CI-protsessis kasutada; kuidas ühendada koormusallikaid oma CI-projekti ehitusmalli abil; kuidas näeb välja demopipeline koormustestide käivitamiseks ja tulemuste avaldamiseks. Artikkel võib olla kasulik tarkvaratestimise inseneridele ja automatiseerimisinseneridele CI-s, kes on mõelnud oma koormussüsteemi arhitektuurile.

Mõiste olemus

Mõiste load testing as a service tähendab võimalust integreerida koormustööriistu nagu Apache JMeter, Yandex.Tank ja oma raamistikud igasse pideva integreerimise süsteemi. Demokood on mõeldud GitLab CI jaoks, kuid põhimõtted on üldiselt rakendatavad kõigile CI-süsteemidele.

Koormustestimine teenusena — see on tsentraalselt hallatav teenus koormustestide läbiviimiseks. Koormustestid käivitatakse eraldatud agentide basseinides, tulemuste avaldamine toimub automaatselt GitLab Pages, Influx DB ja Grafana või testitulemuste raportimise süsteemides (TestRail, ReportPortal jne). Automatiseerimine ja mõõtmete laiendamine on võimalikult lihtne — lihtsalt lisades ja parametriseerides GitLab CI projektis tavalist gitlab-ci.yml malli.

Selle lähenemise eeliseks on see, et kogu CI-infrastruktuur, koormuse agentuurid, koormusallikate docker-pildid, testimisprotsessid ja raportite avaldamine — toetatakse tsentraalse automatiseerimise osakonna (DevOps-inseneride) poolt, samas kui koormustestimise insenerid saavad keskenduda testide arendamisele ja nende tulemuste analüüsimisele, tegelemata infrastruktuuri probleemidega.

Lihtsuse huvides oletame, et sihtotstarbeline testitav rakendus või server on juba eelnevalt üles seatud ja konfigureeritud (selleks võivad olla kasutatud automatiseeritud skriptid Pythonis, SaltStackis, Ansible'is jne). Sel juhul jaguneb kogu koormustestimise kontseptsioon teenusena kolmeks etapiks: ettevalmistus, testimine, aruannete avaldamine. Täpsemalt skeemil (kõik pildid on klikatavad):

Peamised mõisted ja määratlemised koormustestimises

Koormustestide läbiviimisel püüame järgida standardeid ja ISTQB metoodikat, kasutades vastavaid termineid ja soovitatud mõõdikuid. Toome välja lühikese loetelu peamistest mõistetest ja määratlemistest koormustestimises.

Koormusagent (load agent) — virtuaalne masin, millel käivitub rakendus, mis tekitab koormust (Apache JMeter, Yandex.Tank või isekirjutatud koormusmoodul).

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

Testimisstsenaarium (test case) — parameteriseeritud toimingute kogum: kasutajate tegevused ja oodatavad reaktsioonid nendele tegevustele, koos fikseeritud võrgupäringute ja vastustega, sõltuvalt määratud parameetritest.

Koormusprofiil (profile) — in ISTQB metoodikas (p. 4.2.4, lehekülg 43) koormusprofiilid määratlevad konkreetse testi jaoks kriitilise tähtsusega mõõdikud ja koormusparameetrite muutmise variandid testi käigus. Koormusprofiile saab näha joonisel.

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

Testiplaan (test-plan) — testide kogum ja koormusprofiil.

Testijooks (testrun) — üks iteratsioon ühe testi käitamisest täieliku koormusstsenaariumi ja saadud aruandega.

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

Võrguvastus (response) — HTTP-vastus, mis saadetakse eesmärgilt agentile.
HTTP vastuse kood (HTTP responses status) — rakenduste serveri standardne vastusekood.
Tehing (transaction) — täielik "päring — vastus" tsükkel. Tehingut loetakse algusest päringu saatmisest (request) kuni vastuse vastuvõtmise lõpetamiseni (response).

Tehingu staatuse (transactions status) — kas «päring – vastus» tsükkel õnnestus edukalt lõpetada. Kui selle tsükli jooksul esines viga, loetakse kogu tehing ebaõnnestunuks.

Vastuse aeg (latency) — aeg, mis kulub päringu (request) saatmise lõpust vastuse (response) vastuvõtu alguseni.

Koormusmõõdikud (metrics) — koormustestimise käigus määratud koormatud teenuse ja koormusagendi omadused.

Põhikategooriad koormuse mõõtmiseks

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

Mõõdikud koormusagendi jaoks
Sihtsüsteemi või rakenduse, mida koormuse all testitakse, mõõdikud

Kogus  vCPU ja mälu RAM,
Ketas — „rauda“ omadused koormusagendi jaoks
CPU, Mälu, Diski kasutus — protsessori, mälu ja ketta koormuse dünaamika
testimise käigus. Tavaliselt mõõdetakse protsentides
maksimaalselt saadaval olevast väärtusest

Võrgu läbilaskevõime (koormusagendil) — võrguühenduse läbilaskevõime
serveris,
kus koormusagent on installitud.
Tavaliselt mõõdetakse baitides sekundis (bps)
Võrgu läbilaskevõime(sihtimise päeval) — võrgu liidese läbilaskevõime
sihtserveris. Tavaliselt mõõdetakse baitides sekundis (bps)

Virtuaalsed kasutajad— virtuaalsete kasutajate arv,
kes rakendavad koormusskeeme ja
imitavad päris kasutajate tegevusi
Virtuaalsete kasutajate olek, Edastus/Ebaõnnestumine/Kokku — eduka ja
ebaõnnestunud virtuaalsete kasutajate olekute arv
koormusskeemide jaoks ning nende koguarv.

Tavaliselt eeldatakse, et kõik kasutajad suudavad täita
oma ülesandeid, mis on määratletud koormaprofiilis.
Iga viga tähendab, et ka päris kasutaja ei suuda
oma ülesannet süsteemis lahendada

Nõuded sekundis (minuutis)— võrgu päringute arv sekundis (või minutis).

Oluline koormusagendi omadus: kui palju ta suudab genereerida päringuid.
Sisuliselt on see simulatsioon rakenduse poole pöördumisest virtuaalsete kasutajate poolt
Vastused sekundis (minuutis)
— võrgu vastuste arv sekundis (või minutis).

Oluline sihttouote omadus: kui palju on õnnestunud
genereerida ja saata vastuseid päringutele,
mis pärit koormusagendilt

HTTP vastuste olek— erinevate vastuskoodide arv
rakenduste serverist, mis on saadud koormustestija poolt.
Näiteks 200 OK tähendab eduka pöördumist,
samal ajal kui 404 – et ressurssi ei leitud

Ooteaeg (latentsusaeg) – aeg pärast
päringu (request) saatmise lõpetamist kuni vastuse (response) vastuvõtmise alguseni.
Tavaliselt mõõdetakse millisekundites (ms)

Tehingu vastuse aeg– ühe täieliku tehingu aeg,
tsükli «päring – vastus» lõpetamine.
See aeg algab päringu (request) saatmisest
kuni vastuse (response) vastuvõtmise lõpetamiseni.

Tehingu aeg võib olla mõõdetud sekundites (või minutites)
mitmel erineval viisil: arvestatakse minimaalset,
maksimaalset, keskmist ja näiteks 90. persentiili.
Minimaalsed ja maksimaalsed näidud on süsteemi
soorituse äärmused.
90. persentiili kasutatakse kõige sagedamini,
kuna see näitab enamikku kasutajatest,
kes töötavad mugavalt süsteemi soorituse piiridel.

Tehingud sekundis (minuutis) – täistehingute arv sekundis (minuutis),
ehk kui palju päringuid rakendus suutis vastu võtta ja
töötada läbi ning vastuseid anda.
Tegelikult on see süsteemi läbilaskevõime.
Tehingute staatus

, Läbimurre / Ebaõnnestumine / Kokku – arv , Läbimise / Ebaõnnestumise / Kokku — arv
edukate, eba puutumised ja üldine tehingute arv.

Reaalsete kasutajate puhul tähendab ebaõnnestunud
tehing tegelikult
süsteemi koormuse all mitte töötamist.

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 läbiviimine ja lõpuks testimisraporti koostamine ja avaldamine.

Märkused skeemile:

• QA.Tester — koormustestimise ekspert,
• Target — sihtrakendus, mille käitumist tuleb koormuse all uurida.

Entiteetide, etappide ja sammude klassifikaator skeemil

Etapid ja sammud
Mis toimub
Mis on sisendiks
Mis on väljundiks

Prepare: testimise ettevalmistamise etapp

LoadParameters
Koormuse parameetrite seadmine ja initsialiseerimine,
kasutaja
valikute mõõdikud ja
testimiskava ettevalmistamine
(koormuse profiil)
Kohandatud parameetrid koormuse agenti initsialiseerimiseks
Kasutaja parameetrid
koormuse agendi initsialiseerimiseks
Testimiskava
Testimise eesmärk

VM
Kasutuselevõtt pilves
virtuaalmasina
vajalikud omadused
VM-i parameetrid koormuse agendi jaoks
Automatiseerimise skriptid
VM-i loomine
Konfigureeritud VM
pilves

Env
OP-i seadistamine ja
keskkonna ettevalmistamine
koormuse agendi tööks
Keskkonna parameetrid
koormuse agendi jaoks
Automatiseerimise skriptid
keskkonna seadistamine
Valmis keskkond:
OP, teenused ja rakendused
tööks vajalikud
koormuse agendi jaoks

LoadAgents
Paigaldamine, seadistamine ja parameetrite määramine
koormuse agendi jaoks.
Või allalaadimine Docker-pildist
ettevalmistatud koormuse allikaga
Koormuse allika Docker-pilt
(YAT, JM või omatehtud raamistik)
Seadistamise parameetrid
koormuse agendi jaoks
Konfigureeritud ja valmis
tööks koormuse agent

Test: koormustestide täitmise etapp. Allikateks on koormuse agendid, mis on paigaldatud eraldatud agentide basseinidesse GitLab CI jaoks.

Load
Koormuse agendi käivitamine
valitud testplaaniga
ja koormuse parameetritega
Kohandatud parameetrid
iniitsialiseerimiseks
koormuse agendi jaoks
Testimiskava
Testimise eesmärk
Täitmislogid
koormustestide
Süsteemilogid
Eesmärgi ja koormuse agendi mõõdikute dünaamika

RunAgents
Koormuse agentide
koormustestide skriptide täitmine
koormusprofili kohaselt
koormuse profiil
Kohanduste koormuseagent
testimise eesmärgil
Testimiskava
Testimise eesmärk

Logs
Toorandmete logide kogumine
koormustestimise käigus:
koormuseagendi tegevusraportid,
testimise eesmärgi olek
ja VM, kus koormuseagent töötab

Täitmislogid
koormustestide
Süsteemilogid

Metrics
Toorandmete mõõdikute kogumine testimise käigus

Mõõdikute dünaamiline muutumine sihtmärgi
ja koormuseagendi kohta

Report: ettevalmistusprotsessi raporti tegemiseks testimisest

Generator
Kogutud töötlemine
koormussüsteemi ja
monitooringusüsteemi toorandmete
mõõdikute ja logide
Aruande koostamine
inimesele loetaval kujul,
võimalusel analüüsi elementidega
analüütika
Täitmislogid
koormustestide
Süsteemilogid
Mõõdikute dünaamiline muutumine
sihtmärgi ja koormuseagendi
Töödeldud toorlogid
vormingus, mis sobib
välistele andmesalvestussüsteemidele
Statistiline koormusaruanne,
inimesele analüüsimiseks sobiv

Publish
Aruande avaldamine
koormustestimise
välises teenuses
Töödeldud toorlogid vormingus, mis sobib
välistele
andmesalvestussüsteemidele
Salvestatud välises
andmesalvestussüsteemis koormuse
aruanded, mis sobivad
inimese analüüsimiseks
Koormuse allikate ühendamine CI-mallis
analüüsiks inimese poolt

Koormusallikate ühendamine CI-mallis

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

Esmalt, meie DevOps-inseneride tööga, lõime GitLab CI-s spetsiaalse agentide basseini koormustestide käivitamiseks. Et neid šabloonides teiste, näiteks kokkupanemise, basseinide seas segamini ei ajada, lisasime nende agentide külge tunnused, tags: load. Võite kasutada ka muid arusaadavaid märke. Need määratakse registreerimise ajal GitLab CI Runners.

Kuidas määrata vajalik riistvara võimsus? Koormuse agentide omadused — piisav arv vCPU, RAM ja Disk — saab arvutada lähtuvalt sellest, et agendil peavad olema käimas Docker, Python (Yandex.Tank'i jaoks), GitLab CI agent, Java (Apache JMeter'i jaoks). JMeter'i jaoks Java puhul soovitatakse kasutada vähemalt 512 MB RAM-i ning ülemiseks piiriks, 80% kasutada olevast mälust..

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

Meie peamine koormusallikas on kaks — Apache JMeteri ja Yandex.Tanki Docker-pildid.

Yandex.Tank on Yandexi avatud lähtekoodiga tööriist koormustestide teostamiseks. Selle modulaarne arhitektuur põhineb kõrge jõudlusega asünkroonsel hit-based HTTP-päringute generaatoril Phantom. Tank sisaldab testitava serveri ressursside jälgimist SSH protokolli kaudu, suudab automaatselt testimise tingimuste saavutamisel peatada ning kuvab tulemusi nii konsoolis kui graafikute kujul. Samuti on võimalik lisada oma mooduleid funktsionaalsuse laiendamiseks. Muide, me kasutasime Tanki ajal, mil see polnud veel peavoolus. Artiklis „Yandex.Tank ja koormustestide automatiseerimine“ saab lugeda, kuidas me 2013. aastal läbi viisime koormustestimise PT Appllication Firewall — üks meie ettevõtte tooteid.

Apache JMeter — on avatud lähtekoodiga tööriist, mida kasutatakse koormustestimiseks Apache'i ettevõttest. Seda saab võrdselt hästi kasutada nii staatiliste kui dünaamiliste veebirakenduste testimiseks. JMeter toetab arvukalt protokolle ja suhtlemisviise rakendustega: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET jne), SOAP / REST veebiteenused, FTP, TCP, LDAP, SMTP(S), POP3(S) ja IMAP(S), andmebaasid JDBC kaudu, suudab käivitada shell-käske ja töötada Java-objektidega. JMeteril on IDE testiplaneeringute loomiseks, silumiseks ja täitmiseks. Samuti on olemas CLI, mis töötab igas Java-toega operatsioonisüsteemis (Linux, Windows, Mac OS X). Tööriist suudab dünaamiliselt genereerida HTML-aruande testimise kohta.

Kasutamise mugavuse nimel meie ettevõtte sees, et testijad saaksid keskkonda ise muuta ja lisada, oleme loonud koormusallikaid Docker-piltide kogumid GitLab CI-s koos publikatsiooniga meie sise- dokkeri registrisse Artifactory. See muudab koormustestide jaoks nende ühendamise torujuhtmetesse kiireks ja lihtsaks. Kuidas teha docker push registrisse läbi GitLab CI — vaadake juhendis.

Yandex.Tanki põhidoogeri faili võtsime selle:

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

Aga Apache JMeter on järgmine:

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

Kuidas meie pidevat integreerimistöötluse süsteem töötab, võite lugeda artiklist «Arendusprotsesside automatiseerimine: kuidas me Positive Technologies rakendasime DevOpsi ideid».

Mall ja tööprotsess

Näide koormustestimise mallist on saadaval projektis demo-load. Dokumendihalduses readme-failis saate lugeda juhiseid malliga töötamiseks. Igas mallis (fail .gitlab-ci.yml) on märkused selle kohta, mida iga samm tähistab.

Mall on väga lihtne ja demonstreerib kolme koormustestimise etappi, nagu eespool diagrammil kirjeldatud: ettevalmistus, testimine ja aruannete avaldamine. Selle eest vastutavad stages: Prepare, Test ja Report.

1. Etapp Prepare tuleb kasutada testimise eesmärkide ettevalmistamiseks või nende kergesti kättesaadavuse kontrollimiseks. Koormuse allikate keskkonda seadistama ei pea, need on eelnevalt kokku pandud kui docker-pildid ja saadaval docker registry's: piisab vajalikku versiooni määramisest etapis Test. Kuid neid saab ka tagasi ehitada ja luua oma modifitseeritud pildid.
2. Etapp Test kasutatakse koormuse allika määramiseks, testide käivitamiseks ja testimisartefaktide salvestamiseks. Vōib valida mis tahes koormuse allika: Yandex.Tank, Apache JMeter, oma või kõiki koos. Vähenenud allikate keelamiseks piisab, kui kommenteerida või kustutada töö. Koormuse allikate sisenemiskohad:
   • Yandex.Tanki käivitamise parameetrid on määratud failis./tests/yandextank.sh,
   • Apache JMetri käivitamise parameetrid on määratud failis ./tests/jmeter.sh.

   Märkus: kokkupaneku konfiguratsiooni mall on mõeldud CI-süsteemiga suhtlemise seadistamiseks ja ei eelda testide loogika paigutamist. Testide jaoks on määratud sisenemiskoht, kus asub juhtiva bash-skripti. Testide käivitamise meetod, aruannete koostamine ja testimistooted — peavad olema rakendatud QA-inseneride poolt. Demokohas kasutatakse mõlema koormuse allika jaoks kõige lihtsama testina Yandexi peamise lehe päringut. Testide stsenaariumid ja parameetrid asuvad kataloogis ./tests.

3. Etapis Aruanne on vajalik kirjeldada Test-etapis saadud testitulemuste avaldamise viise välistesse salvestuskohtadesse, näiteks GitLab Pages või spetsiaalsetesse aruandekuule. GitLab Pages jaoks peab testide lõppedes kataloog ./public olema mitte tühi ja sisaldama vähemalt faili index.html. GitLab Pages teenuse toimimisest saate lugeda lingi kaudu.

   Näited, kuidas andmeid eksportida:

   • JMeter-ist GitLab Pages-i,
   • Yandex.Tank-ist InfluxDB-sse ja Grafanasse.

   Avaldamise seadistamise juhised:

   • HTML-statistika GitLab Pages-i,
   • InfluxDB-s ja seejärel Grafana.

Demoprintis näeb koormustestide torustik kahest koormuse allikast (ühe saab deaktiveerida) välja selline:

Apache JMeter suudab ise genereerida HTML-aruande, seega on mõistlikum see GitLab Pages-is tavaliste vahendite abil salvestada. Niisugune näeb välja Apache JMeter aruanne:

Demoprintis Yandex.Tank-i jaoks näete ainult vale tekstiaruannet GitLab Pages-i jaotises. Testimise tõttu oskab Tank salvestada tulemusi InfluxDB baasi, kust saab neid näiteks Grafanas kuvada (seadistamine toimub failis ./tests/example-yandextank-test.yml). Niisugune näeb välja Tanki aruanne Grafanas:

Kokkuvõte

Artiklis räägin „koormustestimise kui teenuse” (load testing as a service) kontseptsioonist. Põhiidee seisneb ettenähtud koormuseagentide basseinide, koormuseallikate Docker-piltide, aruandlussüsteemide ja neid ühendava GitLab CI teekonna kasutamises lihtsa .gitlab-ci.yml malli alusel. Kõike seda toetab väike automatiseerimise inseneride meeskond ja seda kopeeritakse tootevõistkondade nõudmisel. Loodan, et see aitab teid sarnase skeemi ettevalmistamisel ja rakendamisel teie ettevõttes. Aitäh tähelepanu eest! lingi kauduP. S. Soovin suured tänud öelda oma kolleegidele, Sergei Kurbanovile ja Nikolai Yusevile, tehnilise abi eest koormustestimise kui teenuse (load testing as a service) kontseptsiooni rakendamisel meie ettevõttes.

Autor

Timur Gilmullin: — tegevdirektori asetäitja arendustehnoloogia ja -protsesside osakonnas (DevOps) ettevõttes Positive Technologies NFC: Near Field Communication tehnoloogia analüüs

Allikas: habr.com