Üks probleeme, millega mitme toote tarkvara müüjad sageli silmitsi seisavad, on peaaegu iga meeskonna inseneride – arendajate, testijate ja infrastruktuuri administraatorite – pädevuste dubleerimine. See kehtib ka kallite inseneride kohta - koormustestimise valdkonna spetsialistid.
Selle asemel, et täita oma otseseid ülesandeid ja kasutada oma ainulaadseid kogemusi koormustestiprotsessi koostamiseks, metoodika, optimaalsete mõõdikute valimiseks ja automaattestide koostamiseks vastavalt koormusprofiilidele, peavad insenerid sageli juurutama testimise infrastruktuuri nullist, konfigureerima laadimistööriistu ja neid kinnistama. CI-süsteemides, seada sisse järelevalve ja aruannete avaldamine.
Mõnele organisatsioonilisele probleemile leiate lahendusi testimisel, mida me Positive Technologiesis kasutame . Ja selles räägin ma võimalusest integreerida koormustestid ühisesse CI torujuhtmesse, kasutades mõistet "koormustestimine kui teenus" (koormustestimine teenusena). Saate teada, kuidas ja milliseid laadimisallikate dokkepilte saab CI-konveieris kasutada; kuidas ühendada laadimisallikad oma CI projektiga ehitusmalli abil; milline näeb välja demokonveier koormustestide käitamiseks ja tulemuste avaldamiseks. Artikkel võib olla kasulik CI tarkvara testimisinseneridele ja automaatikainseneridele, kes mõtlevad oma laadimissüsteemi arhitektuurile.
Kontseptsiooni olemus
Koormustesti kui teenuse kontseptsioon eeldab võimalust integreerida laadimistööriistad Apache JMeter, Yandex.Tank ja teie enda raamistikud suvaliseks pidevaks integreerimissüsteemiks. Demo on GitLab CI jaoks, kuid põhimõtted on ühised kõigile CI-süsteemidele.
Koormustestimine kui teenus on koormustestimise tsentraliseeritud teenus. Koormustestid käitatakse spetsiaalsetes agentide kogumites, tulemused avaldatakse automaatselt GitLabi lehtedes, Influx DB-s ja Grafanas või testi aruandlussüsteemides (TestRail, ReportPortal jne). Automatiseerimine ja skaleerimine on rakendatud võimalikult lihtsalt – lisades ja parameetrites GitLab CI projektis tavapärase gitlab-ci.yml malli.
Selle lähenemisviisi eeliseks on see, et kogu CI infrastruktuuri, laadimisagente, laadimisallikate dokikujutisi, testimistorusid ja aruannete avaldamist haldab tsentraliseeritud automatiseerimisosakond (DevOpsi insenerid), samas kui koormustestimise insenerid saavad keskenduda testiarendusele. ja nende tulemuste analüüsi, ilma infrastruktuuriprobleemidega tegelemata.
Kirjelduse lihtsuse huvides eeldame, et testitav sihtrakendus või -server on juba eelnevalt juurutatud ja konfigureeritud (selleks saab kasutada Pythoni, SaltStacki, Ansible jne automatiseeritud skripte). Seejärel mahub kogu koormustesti kui teenuse kontseptsioon kolme etappi: aruannete koostamine, testimine, avaldamine. Täpsemalt diagrammil (kõik pildid on klikitavad):
Koormustestimise põhimõisted ja määratlused
Koormustestide läbiviimisel püüame kinni pidada , kasutage sobivat terminoloogiat ja soovitatud mõõdikuid. Annan lühikese loetelu koormustestimise peamistest mõistetest ja definitsioonidest.
Laadige agent - virtuaalne masin, millel rakendus käivitatakse - laadimisallikas (Apache JMeter, Yandex.Tank või ise kirjutatud laadimismoodul).
Testi eesmärk (sihtmärk) - serverisse installitud server või rakendus, mida hakatakse laadima.
Testi stsenaarium (testjuhtum) - parameetritega sammude komplekt: kasutaja toimingud ja eeldatavad reaktsioonid nendele toimingutele koos fikseeritud võrgupäringute ja vastustega, olenevalt määratud parameetritest.
Profiil või koormusplaan (profiil) - sisse (Jaotis 4.2.4, lk 43) koormusprofiilid määratlevad mõõdikud, mis on konkreetse testi jaoks kriitilised, ja valikud koormuse parameetrite muutmiseks katse ajal. Profiilide näiteid näete joonisel.
Test — etteantud parameetrite komplektiga skript.
Katseplaan (test-plaan) - testide komplekt ja koormusprofiil.
Testran (testrun) - üks kordus ühe testi läbiviimisest täielikult täidetud laadimisstsenaariumi ja vastuvõetud aruandega.
Võrgupäring (taotlus) — HTTP-päring, mis saadetakse agendilt sihtmärgile.
Võrguvastus (vastus) — HTTP-vastus, mis saadetakse sihtmärgilt agendile.
HTTP vastuse kood (HTTP vastuste olek) – standardne vastusekood rakendusserverist.
Tehing on täielik päringu-vastuse tsükkel. Tehingut arvestatakse päringu (päringu) saatmise algusest kuni vastuse (vastuse) saamise lõpuni.
Tehingu olek - kas päringu-vastuse tsüklit oli võimalik edukalt läbida. Kui selles tsüklis ilmnes viga, loetakse kogu tehing ebaõnnestunuks.
Reageerimisaeg (latentsus) - aeg päringu (päringu) saatmise lõpust vastuse (vastuse) saamise alguseni.
Laadige mõõdikud — koormustesti käigus kindlaks määratud koormatud teenuse ja koormusteguri omadused.
Põhilised mõõdikud koormusparameetrite mõõtmiseks
Mõned metoodikas kõige sagedamini kasutatavad ja soovitatavad (lk 36, 52) mõõdikud on toodud allolevas tabelis. Agendi ja sihtmärgi sarnased mõõdikud on loetletud samal real.
Laadimisagendi mõõdikud
Koormuse all testitava sihtsüsteemi või rakenduse mõõdikud
Kogus vCPU ja mälu RAM,
Ketas - koormusaine "raudsed" omadused
Protsessor, Mälu, kettakasutus - protsessori, mälu ja ketta laadimise dünaamika
katsetamise käigus. Tavaliselt mõõdetakse protsentides
maksimaalsed saadaolevad väärtused
võrgu läbilaskevõime (on load agent) – läbilaskevõime
serveri võrguliides,
kuhu laadimisagent on paigaldatud.
Tavaliselt mõõdetakse baitides sekundis (bps)
võrgu läbilaskevõime(sihtmärgil) - võrguliidese ribalaius
sihtserveris. Tavaliselt mõõdetakse baitides sekundis (bps)
Virtuaalsed kasutajad- virtuaalsete kasutajate arv,
koormusstsenaariumide rakendamine ja
reaalse kasutaja tegevuse jäljendamine
Virtuaalsete kasutajate olek, Läbitud/Ebaõnnestunud/Kokku — edukate ja
virtuaalsete kasutajate ebaõnnestunud olekud
laadimisstsenaariumide jaoks, samuti nende koguarv.
Üldiselt eeldatakse, et kõik kasutajad said lõpule viia
kõik teie koormusprofiilis määratud ülesanded.
Igasugune viga tähendab, et tegelik kasutaja ei saa seda teha
lahendage oma probleem süsteemiga töötades
Taotlusi sekundis (minutis)- võrgupäringute arv sekundis (või minutis).
Laadimisagendi oluline omadus on see, kui palju päringuid see genereerida suudab.
Tegelikult on see virtuaalsete kasutajate rakendusele juurdepääsu imitatsioon
Vastuseid sekundis (minutis)
- võrgu vastuste arv sekundis (või minutis).
Sihtteenuse oluline tunnus: kui palju
abil päringutele vastuseid genereerida ja saata
laadimisagent
HTTP vastuse olek— erinevate vastusekoodide arv
laadimisagendi poolt vastu võetud rakendusserverist.
Näiteks 200 OK tähendab edukat kõnet,
ja 404 – et ressurssi ei leitud
Hilinemine (reageerimisaeg) – aeg lõpust
päringu (päringu) saatmine enne vastuse (response) saamise alustamist.
Tavaliselt mõõdetakse millisekundites (ms)
Tehingu reageerimise aeg— ühe täieliku tehingu aeg,
päringu-vastuse tsükli lõpetamine.
See on aeg päringu (päringu) saatmise algusest
kuni vastuse (vastuse) saamise lõpuni.
Tehinguaega saab mõõta sekundites (või minutites)
mitmel viisil: arvestage miinimumiga,
maksimum, keskmine ja näiteks 90. protsentiil.
Minimaalne ja maksimaalne näidud on äärmuslikud
süsteemi jõudluse olek.
Üheksakümnendat protsentiili kasutatakse kõige sagedamini,
nagu näitab enamik kasutajaid,
mugavalt töötades süsteemi jõudluse lävel
Tehinguid sekundis (minutis) - komplektide arv
tehinguid sekundis (minutis),
ehk kui palju suutis taotlus vastu võtta ja
taotlusi töödelda ja vastuseid väljastada.
Tegelikult on see süsteemi läbilaskevõime
Tehingu olek , Läbitud / Ebaõnnestunud / Kokku - arv
edukad, ebaõnnestunud ja tehingute koguarv.
Tegelikele kasutajatele ebaõnnestus
tehing tegelikult tähendab
võimetus töötada koormuse all oleva süsteemiga
Koormustesti skemaatiline diagramm
Koormustesti kontseptsioon on väga lihtne ja koosneb kolmest põhietapist, mida ma juba mainisin: Valmistage-testi-aruannest katseeesmärkide ettevalmistamine ja laadimisallikate parameetrite seadmine, seejärel koormustestide läbiviimine ja lõpuks testiaruande genereerimine ja avaldamine.
Skemaatilised märkused:
- QA.Tester on koormustestimise ekspert,
- Target on sihtrakendus, mille käitumist koormuse all soovite teada.
Olemite, etappide ja sammude klassifikaator diagrammil
Etapid ja sammud
Mis toimub
Mis on sissepääsu juures
Mis on väljund
Ettevalmistus: katsetamise ettevalmistamise etapp
Laadimisparameetrid
Seadistamine ja lähtestamine
kasutaja
koormuse parameetrid,
mõõdikute valik ja
katseplaani koostamine
(laadimisprofiil)
Kohandatud valikud
laadimisagendi lähtestamine
Katseplaan
Testimise eesmärk
VM
Pilve juurutamine
virtuaalne masin
nõutavad omadused
VM-i seaded laadimisagendi jaoks
Automatiseerimisskriptid jaoks
VM-i loomine
VM on konfigureeritud
pilv
Saada
OS-i seadistamine ja ettevalmistamine
keskkond
koormaagendi töö
Keskkonna seaded jaoks
laadimisagent
Automatiseerimisskriptid jaoks
keskkonna seaded
Ettevalmistatud keskkond:
OS, teenused ja rakendused,
tööks vajalik
laadimisagent
LoadAgents
Paigaldamine, seadistamine ja parameetrite seadistamine
laadimisagent.
Või dokkimispildi allalaadimine aadressilt
eelkonfigureeritud laadimisallikas
Laadi allika doki pilt
(YAT, JM või ise kirjutatud raamistik)
Seaded
laadimisagent
Seadistatud ja valmis
koormuse agent tööle
Test: koormustestide läbiviimise etapp. Allikad on laadimisagendid, mis on juurutatud GitLab CI jaoks spetsiaalsetes agentide kogumites
Koormus
Laadimisagendi käivitamine
valitud testiplaaniga
ja koormuse parameetrid
Kasutaja valikud
initsialiseerimiseks
laadimisagent
Katseplaan
Testimise eesmärk
Täitmise logid
koormustestid
Süsteemi logid
Eesmärgimõõdikute ja koormusagendi muutuste dünaamika
Käivitage agendid
Agendi täitmine
palju testskripte
vastavalt
koormusprofiil
Laadige agendi interaktsioon
katsetamise eesmärgil
Katseplaan
Testimise eesmärk
Logid
"Toores" palkide kogu
koormustesti ajal:
laadimisagendi tegevuse kirjed,
katseobjekti olek
ja agenti käitav VM
Täitmise logid
koormustestid
Süsteemi logid
Meetrika
Testimise käigus "toorete" mõõdikute kogumine
Eesmärkide mõõdikute muutuste dünaamika
ja laadimisagent
Aruanne: katsearuande koostamise etapp
Tekitaja
Töötlemine kogutud
laadimissüsteem ja
seiresüsteem "toores"
mõõdikud ja logid
Aruande koostamine aastal
inimloetav vorm
võimalik elementidega
analüütikud
Täitmise logid
koormustestid
Süsteemi logid
Mõõdikute muutuste dünaamika
sihtmärk ja laadimisagent
Töödeldud "toored" palgid
sobivas vormingus
laadib üles välismällu
Staatilise koormuse aruanne,
inimloetav
Avalda
Aruande avaldamine
koormuse kohta
katsetamine väliselt
teenus
Töödeldud "toores"
sobivas vormingus logid
väljast mahalaadimiseks
hoidlad
Salvestatud välisesse
salvestusaruanded
koormus, sobiv
inimese analüüsi jaoks
Koormusallikate ühendamine CI-mallis
Liigume edasi praktilise osa juurde. Tahan näidata, kuidas mõne ettevõtte projekti puhul oleme rakendanud koormustestimise kontseptsiooni teenusena.
Esiteks lõime meie DevOpsi inseneride abiga GitLab CI-s spetsiaalse agentide kogumi, et käitada koormusteste. Et mitte ajada neid mallides teistega segamini, näiteks koostekogumitega, lisasime nendele agentidele sildid, : koormus. Võite kasutada muid arusaadavaid silte. Nad küsivad GitLabi CI jooksjad.
Kuidas teada saada vajalikku võimsust riistvara abil? Laadimisagentide omadused – piisav arv vCPU-sid, RAM-i ja ketast – saab arvutada selle põhjal, et agendil peaksid töötama Docker, Python (Yandex.Tanki jaoks), GitLab CI agent, Java (Apache JMeteri jaoks). . JMeteri all oleva Java puhul on samuti soovitatav kasutada vähemalt 512 MB RAM-i ja ülempiirina .
Seega soovitame oma kogemuse põhjal kasutada laadimisagentide jaoks vähemalt 4 vCPU-d, 4 GB muutmälu, 60 GB SSD-d. Võrgukaardi läbilaskevõime määratakse koormusprofiili nõuete alusel.
Peamiselt kasutame kahte laadimisallikat – Apache JMeter ja Yandex.Tank dockeri pilte.
on Yandexi avatud lähtekoodiga tööriist koormustestimiseks. Selle modulaarne arhitektuur põhineb Phantomi suure jõudlusega asünkroonsel löögipõhisel HTTP päringu generaatoril. Paagil on sisseehitatud testitava serveri ressursside jälgimine SSH-protokolli kaudu, see suudab testi määratud tingimustel automaatselt peatada, saab tulemusi kuvada nii konsoolis kui ka graafikute kujul, saate ühendada oma moodulid selle funktsiooni laiendamiseks. Muide, me kasutasime Tanki siis, kui see polnud veel mainstream. Artiklis "» saad lugeda lugu sellest, kuidas me 2013. aastal sellega koormusteste tegime on üks meie ettevõtte toodetest.
on Apache'i avatud lähtekoodiga koormuse testimise tööriist. Seda saab ühtviisi hästi kasutada nii staatiliste kui ka dünaamiliste veebirakenduste testimiseks. JMeter toetab tohutul hulgal protokolle ja viise rakendustega suhtlemiseks: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET jne), SOAP / REST veebiteenused, FTP, TCP, LDAP, SMTP(S), POP3( S) ) ja IMAP(S), JDBC kaudu andmebaasid, saavad täita shellikäske ja töötada Java-objektidega. JMeteril on IDE testiplaanide loomiseks, silumiseks ja täitmiseks. Samuti on olemas CLI käsurea kasutamiseks mis tahes Javaga ühilduvas operatsioonisüsteemis (Linux, Windows, Mac OS X). Tööriist suudab dünaamiliselt luua HTML-testi aruande.
Meie ettevõttesisese kasutamise hõlbustamiseks, et testijad ise saaksid keskkonda muuta ja lisada, koostasime GitLab CI laadimisallikate dokikujutistest koos avaldamisega sisekeskkonnas. . See muudab nende ühendamise koormustestide jaoks torujuhtmetesse kiiremaks ja lihtsamaks. Kuidas teha dokkeri tõuke GitLab CI kaudu registrisse - vt .
Võtsime selle Yandex.Tank jaoks mõeldud dokkimisfaili:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]Ja Apache JMeteri jaoks see:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Kuidas meie pideva integratsiooni süsteem töötab, saate lugeda artiklist "'.
Mall ja torujuhe
Koormustestide läbiviimise malli näide on projektis saadaval . Sisse Saate lugeda malli kasutamise juhiseid. Mallis endas (fail ) on märkmed selle kohta, mille eest iga samm vastutab.
Mall on väga lihtne ja demonstreerib ülaltoodud diagrammil kirjeldatud koormustestimise kolme etappi: aruannete ettevalmistamine, testimine ja avaldamine. Selle eest vastutav : Valmistage ette, testige ja teatage.
- Etapp tuleks kasutada testi sihtmärkide eelkonfigureerimiseks või nende saadavuse kontrollimiseks. Laadimisallikate keskkonda ei ole vaja konfigureerida, need on dokkerite kujutistena eelehitatud ja postitatud dockeri registrisse: lihtsalt määrake soovitud versioon testimisetapis. Kuid saate need uuesti üles ehitada ja oma muudetud pilte teha.
- Etapp kasutatakse laadimisallika määramiseks, testide käitamiseks ja testartefaktide salvestamiseks. Saate valida mis tahes laadimisallika: Yandex.Tank, Apache JMeter, enda või kõik koos. Mittevajalike allikate keelamiseks lihtsalt kommenteerige või kustutage töö. Laadimisallikate sisenemispunktid:
- Yandex.Tank käivitamise parameetrid on määratud jaotises .,
- Apache JMeteri käivitusparameetrid on failis määratud .
Märkus. Koostu konfiguratsioonimalli kasutatakse interaktsiooni seadistamiseks CI-süsteemiga ja see ei tähenda testloogika paigutamist sellesse. Testide jaoks määratakse sisenemispunkt, kus asub kontroll-bashi skript. Testide käitamise, aruannete genereerimise ja testskriptide endi peavad rakendama kvaliteedikontrolli insenerid. Demos kasutatakse mõlema laadimisallika jaoks kõige lihtsama testina Yandexi põhilehe päringut. Skriptid ja testiparameetrid on kataloogis .
- Laval peate kirjeldama, kuidas testimisetapis saadud testitulemusi avaldada välistele salvestustele, näiteks GitLabi lehtedele või spetsiaalsetele aruandlussüsteemidele. GitLab Pages nõuab, et ./avalik kataloog ei oleks tühi ja sisaldaks pärast testide lõppu vähemalt faili index.html. GitLab Pages teenuse nüansside kohta saate lugeda. .
Näited andmete eksportimise kohta:
- JMeterist kuni ,
- Yandex.Tankist kuni .
Postitamise seadistamise juhised:
- HTML staatika sisse ,
- InfluxDB-sse ja seejärel .
Demonäites näeb koormustestide ja kahe laadimisallikaga torujuhe (mittevajaliku saate keelata) järgmine:
Apache JMeter suudab HTML-i aruande ise genereerida, seega on kasulikum salvestada see tavaliste tööriistade abil GitLabi lehtedele. Apache JMeteri aruanne näeb välja selline:
Yandex.Tank demo näites näete ainult GitLabi lehtede jaotises. Testimise käigus saab Tank tulemused salvestada InfluxDB andmebaasi ja sealt saab neid näiteks Grafanasse kuvada (konfiguratsioon tehakse failis ). Nii näeb Tanki aruanne Grafanas välja:
Kokkuvõte
Artiklis rääkisin mõistest "koormustestimine kui teenus" (koormustestimine kui teenus). Põhiidee on kasutada eelkonfigureeritud laadimisagentide kogumite, laadimisallikate dokkipiltide, aruandlussüsteemide ja konveieri, mis ühendab need GitLab CI-s lihtsa .gitlab-ci.yml malli alusel (näide ). Seda kõike toetab väike automatiseerimisinseneride meeskond ja tootemeeskondade nõudmisel kopeeritakse. Loodan, et see aitab teil sarnase skeemi ettevalmistamisel ja rakendamisel teie ettevõttes. Tänan tähelepanu eest!
PS Tahan tänada oma kolleege Sergei Kurbanovit ja Nikolai Jusevit tehnilise abi eest koormustestimise kui teenuse kontseptsiooni rakendamisel meie ettevõttes.
Autor: - Asetäitja Positive Technologies tehnoloogia- ja arendusprotsesside (DevOps) juht
Allikas: www.habr.com