Jedan od problema s kojima se često susreću dobavljači softvera za više proizvoda je dupliciranje kompetencija inženjera - programera, testera i administratora infrastrukture - u gotovo svakom timu. To se također odnosi i na skupe inženjere - stručnjake u području ispitivanja opterećenja.
Umjesto da obavljaju svoje izravne dužnosti i koriste svoje jedinstveno iskustvo za izgradnju procesa testiranja opterećenja, odabir metodologije, optimalne metrike i pisanje autotestova u skladu s profilima opterećenja, inženjeri često moraju implementirati testnu infrastrukturu od nule, konfigurirati alate za opterećenje i ugraditi ih sami u CI sustavima, uspostavili praćenje i objavu izvješća.
Rješenja za neke organizacijske probleme možete pronaći u testiranju koje koristimo u Positive Technologies u . A u ovom ću govoriti o mogućnosti integriranja testova opterećenja u zajednički CI cjevovod koristeći koncept "testiranja opterećenja kao usluge" (testiranje opterećenja kao usluga). Naučit ćete kako i koje docker slike izvora učitavanja mogu se koristiti u CI cjevovodu; kako povezati izvore učitavanja s vašim CI projektom pomoću predloška za izgradnju; kako izgleda demo cjevovod za izvođenje testova opterećenja i objavljivanje rezultata. Članak bi mogao biti koristan inženjerima za testiranje softvera i inženjerima automatizacije u CI-ju koji razmišljaju o arhitekturi svog sustava za učitavanje.
Suština pojma
Koncept testiranja opterećenja kao usluge podrazumijeva mogućnost integracije alata za učitavanje Apache JMeter, Yandex.Tank i vlastitih okvira u proizvoljan sustav kontinuirane integracije. Demo će biti za GitLab CI, ali principi su zajednički za sve CI sustave.
Load testing kao usluga je centralizirana usluga za testiranje opterećenja. Testovi opterećenja izvode se u namjenskim skupovima agenata, rezultati se automatski objavljuju u GitLab Pages, Influx DB i Grafana ili u sustavima za izvještavanje o testiranju (TestRail, ReportPortal itd.). Automatizacija i skaliranje implementirani su što je moguće jednostavnije – dodavanjem i parametrizacijom uobičajenog predloška gitlab-ci.yml u GitLab CI projektu.
Prednost ovog pristupa je u tome što cjelokupnu CI infrastrukturu, agente za učitavanje, docker slike izvora učitavanja, ispitne kanale i izvješća o objavljivanju održava centralizirani odjel za automatizaciju (DevOps inženjeri), dok inženjeri za testiranje učitavanja mogu usmjeriti svoje napore na razvoj testova i analizu njihovih rezultata, bez bavljenja infrastrukturnim pitanjima.
Radi jednostavnosti opisa, pretpostavit ćemo da je ciljana aplikacija ili poslužitelj koji se testira već postavljen i konfiguriran unaprijed (za to se mogu koristiti automatizirane skripte u Pythonu, SaltStacku, Ansibleu itd.). Tada se cijeli koncept testiranja opterećenja kao usluge uklapa u tri faze: priprema, testiranje, objava izvješća. Više detalja na dijagramu (sve slike se mogu kliknuti):
Osnovni pojmovi i definicije u ispitivanju opterećenja
Prilikom provođenja ispitivanja opterećenja nastojimo se pridržavati , koristite odgovarajuću terminologiju i preporučenu metriku. Dat ću kratak popis glavnih koncepata i definicija u testiranju opterećenja.
Agent opterećenja - virtualni stroj na kojem će se aplikacija pokrenuti - izvor učitavanja (Apache JMeter, Yandex.Tank ili modul učitavanja koji ste sami napisali).
Cilj testa (cilj) - poslužitelj ili aplikacija instalirana na poslužitelju koja će biti podložna učitavanju.
Testni scenarij (testni slučaj) - skup parametriziranih koraka: radnje korisnika i očekivane reakcije na te akcije, s fiksnim mrežnim zahtjevima i odgovorima, ovisno o navedenim parametrima.
Profil ili plan opterećenja (profil) - u (odjeljak 4.2.4, str. 43) profili opterećenja definiraju metriku koja je kritična za određeni test i opcije za promjenu parametara opterećenja tijekom testa. Na slici možete vidjeti primjere profila.
Test — skripta s unaprijed određenim skupom parametara.
Plan testiranja (plan testiranja) - skup testova i profil opterećenja.
testran (testrun) - jedna iteracija izvođenja jednog testa s potpuno izvršenim scenarijem opterećenja i primljenim izvješćem.
Mrežni zahtjev (zahtjev) — HTTP zahtjev poslan od agenta do cilja.
Odgovor mreže (odgovor) — HTTP odgovor poslan od cilja agentu.
HTTP kod odgovora (status HTTP odgovora) - standardni kod odgovora aplikacijskog poslužitelja.
Transakcija je potpuni ciklus zahtjeva-odgovora. Transakcija se računa od početka slanja zahtjeva (zahtjeva) do završetka primitka odgovora (odgovora).
Status transakcije - da li je bilo moguće uspješno završiti ciklus zahtjev-odgovor. Ako je u ovom ciklusu došlo do greške, cijela se transakcija smatra neuspješnom.
Vrijeme odgovora (latencija) - vrijeme od završetka slanja zahtjeva (zahtjeva) do početka zaprimanja odgovora (odgovora).
Učitaj metriku — karakteristike opterećene usluge i agenta opterećenja određene u procesu ispitivanja opterećenja.
Osnovne metrike za mjerenje parametara opterećenja
Neki od najčešće korištenih i preporučenih u metodologiji (str. 36, 52) metrika je prikazana u donjoj tablici. Slične metrike za agenta i cilja navedene su u istom retku.
Mjerni podaci za agenta učitavanja
Mjerni podaci ciljnog sustava ili aplikacije koja se testira pod opterećenjem
Broj vCPU i pamćenje RAM,
Disk - "željezne" karakteristike sredstva opterećenja
CPU, Memorija, upotreba diska - dinamika učitavanja procesora, memorije i diska
u procesu testiranja. Obično se mjeri kao postotak od
maksimalne dostupne vrijednosti
propusnost mreže (on load agent) - protok
mrežno sučelje na poslužitelju,
gdje je instaliran agent opterećenja.
Obično se mjeri u bajtovima po sekundi (bps)
propusnost mreže(on target) - propusnost mrežnog sučelja
na ciljnom poslužitelju. Obično se mjeri u bajtovima po sekundi (bps)
Virtualni korisnici- broj virtualnih korisnika,
implementacija scenarija opterećenja i
oponašanje stvarnih radnji korisnika
Status virtualnih korisnika, Položeno/Nije uspješno/Ukupno — broj uspješnih i
neuspješni statusi virtualnih korisnika
za scenarije opterećenja, kao i njihov ukupan broj.
Općenito se očekuje da su svi korisnici uspjeli dovršiti
sve vaše zadatke navedene u profilu opterećenja.
Svaka pogreška značit će da pravi korisnik neće moći
riješite svoj problem pri radu sa sustavom
Broj zahtjeva u sekundi (minuta)- broj mrežnih zahtjeva u sekundi (ili minuti).
Važna karakteristika agenta za učitavanje je koliko zahtjeva može generirati.
Zapravo, radi se o imitaciji pristupa aplikaciji od strane virtualnih korisnika
Odgovori u sekundi (minuta)
- broj mrežnih odgovora u sekundi (ili minuti).
Važna karakteristika ciljne usluge: koliko
generirati i poslati odgovore na upite s
sredstvo za utovar
Status HTTP odgovora— broj različitih kodova odgovora
od poslužitelja aplikacija koje prima agent za učitavanje.
Na primjer, 200 OK znači uspješan poziv,
i 404 - da resurs nije pronađen
skrivenost (vrijeme odgovora) - vrijeme od kraja
slanje zahtjeva (zahtjeva) prije početka primanja odgovora (odgovora).
Obično se mjeri u milisekundama (ms)
Vrijeme odgovora na transakciju— vrijeme jedne pune transakcije,
završetak ciklusa zahtjev-odgovor.
Ovo je vrijeme od početka slanja zahtjeva (zahtjeva)
do završetka prijema odgovora (odgovora).
Vrijeme transakcije može se mjeriti u sekundama (ili minutama)
na nekoliko načina: razmotrite minimum,
maksimum, prosjek i npr. 90. percentil.
Minimalna i maksimalna očitanja su ekstremna
status performansi sustava.
Devedeseti percentil je najčešće korišten,
kao što pokazuje većina korisnika,
udobno raditi na pragu performansi sustava
Transakcija u sekundi (minuta) - broj kompletnih
transakcija u sekundi (minuta),
odnosno koliko je aplikacija mogla prihvatiti i
obraditi zahtjeve i izdati odgovore.
Zapravo, ovo je propusnost sustava
Status transakcije , Položen / Nije prošao / Ukupno - broj
uspješne, neuspješne i ukupan broj transakcija.
Za stvarne korisnike neuspješno
transakcija će zapravo značiti
nemogućnost rada sa sustavom pod opterećenjem
Shematski dijagram testiranja opterećenja
Koncept testiranja opterećenja vrlo je jednostavan i sastoji se od tri glavne faze, koje sam već spomenuo: Pripremite izvješće o ispitivanju, odnosno priprema ciljeva testiranja i postavljanje parametara za izvore opterećenja, zatim izvođenje testova opterećenja i na kraju generiranje i objavljivanje izvješća o testiranju.
Shematske bilješke:
- QA.Tester je stručnjak za testiranje opterećenja,
- Cilj je ciljna aplikacija za koju želite znati njeno ponašanje pod opterećenjem.
Klasifikator entiteta, faza i koraka u dijagramu
Faze i koraci
Što se događa
Što je na ulazu
Što je izlaz
Pripremiti: faza pripreme za testiranje
Parametri opterećenja
Postavljanje i inicijalizacija
korisnik
parametri opterećenja,
izbor metrike i
priprema plana testiranja
(učitaj profil)
Prilagođene opcije za
inicijalizacija agenta za učitavanje
Plan testiranja
Svrha testiranja
VM
Implementacija u oblaku
virtualni stroj sa
tražene karakteristike
Postavke VM-a za agenta učitavanja
Skripte za automatizaciju
Stvaranje VM-a
VM konfiguriran u
oblak
Poslati
Postavljanje i priprema OS-a
okruženje za
load agent work
Postavke okruženja za
agent opterećenja
Skripte za automatizaciju
postavke okruženja
Pripremljeno okruženje:
OS, usluge i aplikacije,
potrebno za rad
agent opterećenja
LoadAgents
Instalacija, konfiguracija i parametriranje
sredstvo za utovar.
Ili preuzimanje docker slike s
pretkonfigurirani izvor učitavanja
Učitaj izvornu docker sliku
(YAT, JM ili sami napisani okvir)
postavke
agent opterećenja
Postavljeno i spremno
to work load agent
Test: faza izvođenja testova opterećenja. Izvori su agenti za učitavanje raspoređeni u namjenskim skupovima agenata za GitLab CI
Opterećenje
Pokretanje agenta za učitavanje
s odabranim planom testiranja
i parametri opterećenja
Korisničke opcije
za inicijalizaciju
agent opterećenja
Plan testiranja
Svrha testiranja
Dnevnici izvršenja
testovi opterećenja
Dnevnici sustava
Dinamika promjena metrike cilja i agenta opterećenja
Pokreni agente
Izvršenje agenta
hrpe testnih skripti
u skladu s
profil opterećenja
Interakcija agenta za učitavanje
u svrhu testiranja
Plan testiranja
Svrha testiranja
Drva
Prikupljanje "sirovih" trupaca
tijekom testiranja opterećenja:
evidencija aktivnosti agenta opterećenja,
stanje ispitnog cilja
i VM koji pokreće agenta
Dnevnici izvršenja
testovi opterećenja
Dnevnici sustava
Metrika
Prikupljanje "sirovih" metrika tijekom testiranja
Dinamika promjena u metrici cilja
i agent opterećenja
Izvješće: faza pripreme izvješća o ispitivanju
Generator
Obrada prikupljena
sustav utovara i
sustav praćenja "sirovi"
metrika i dnevnici
Formiranje izvještaja u
čovjeku čitljiv oblik
moguće s elementima
analitiki
Dnevnici izvršenja
testovi opterećenja
Dnevnici sustava
Dinamika promjena metrike
target and load agent
Obrađeni "sirovi" trupci
u formatu prikladnom za
prenosi u vanjsku pohranu
Izvješće o statičkom opterećenju,
čovjeku čitljiv
Objaviti
Objava izvješća
o opterećenju
ispitivanje u vanjskim
usluga
Obrađeno "sirovo"
dnevnike u odgovarajućem formatu
za istovar na vanjski
spremišta
Spremljeno u vanjski
izvješća o skladištenju
opterećenje, pogodno
za ljudske analize
Povezivanje izvora opterećenja u CI predlošku
Prijeđimo na praktični dio. Želim pokazati kako na nekim projektima u tvrtki implementirali smo koncept testiranja opterećenja kao usluge.
Prvo, uz pomoć naših DevOps inženjera, stvorili smo namjenski skup agenata u GitLab CI za izvođenje testova opterećenja. Kako ih u predlošcima ne bi zamijenili s drugima, kao što su skupovi za montažu, dodali smo oznake ovim agentima, : opterećenje. Možete koristiti bilo koje druge razumljive oznake. Oni pitaju GitLab CI trkači.
Kako saznati potrebnu snagu po hardveru? Karakteristike agenata za učitavanje - dovoljan broj vCPU-a, RAM-a i diska - mogu se izračunati na temelju činjenice da Docker, Python (za Yandex.Tank), GitLab CI agent, Java (za Apache JMeter) trebaju biti pokrenuti na agentu . Za Javu pod JMeterom također se preporučuje korištenje minimalno 512 MB RAM-a i, kao gornja granica, .
Stoga, na temelju našeg iskustva, preporučujemo korištenje najmanje 4 vCPU-a, 4 GB RAM-a, 60 GB SSD-a za agente učitavanja. Propusnost mrežne kartice određena je na temelju zahtjeva profila opterećenja.
Uglavnom koristimo dva izvora učitavanja - Apache JMeter i Yandex.Tank docker slike.
je Yandexov alat otvorenog koda za testiranje opterećenja. Njegova modularna arhitektura temelji se na Phantomovom asinkronom generatoru HTTP zahtjeva visokih performansi. Spremnik ima ugrađeno praćenje resursa poslužitelja koji se testira putem SSH protokola, može automatski zaustaviti test pod određenim uvjetima, može prikazati rezultate i u konzoli iu obliku grafikona, možete povezati svoje module za proširenje funkcionalnosti. Inače, Tank smo koristili kad još nije bio mainstream. U članku "» možete pročitati priču o tome kako smo s njim proveli testiranje opterećenja 2013 jedan je od proizvoda naše tvrtke.
je Apache alat za testiranje opterećenja otvorenog koda. Može se jednako dobro koristiti za testiranje statičkih i dinamičkih web aplikacija. JMeter podržava veliki broj protokola i načina interakcije s aplikacijama: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, itd.), SOAP / REST web usluge, FTP, TCP, LDAP, SMTP(S), POP3( S) ) i IMAP(S), baze podataka putem JDBC-a, mogu izvršavati naredbe ljuske i raditi s Java objektima. JMeter ima IDE za stvaranje, otklanjanje pogrešaka i izvršavanje testnih planova. Tu je i CLI za rad naredbenog retka na bilo kojem operativnom sustavu kompatibilnom s Javom (Linux, Windows, Mac OS X). Alat može dinamički generirati HTML test izvješće.
Za jednostavnu upotrebu unutar naše tvrtke, za mogućnost samih testera da mijenjaju i dodaju okruženje, napravili smo gradnje docker slika izvora učitavanja na GitLab CI s objavom u internom . To čini bržim i lakšim njihovo spajanje u cjevovode za ispitivanja opterećenja. Kako napraviti docker push to registar putem GitLab CI - vidi .
Uzeli smo ovu osnovnu docker datoteku za Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]A za Apache JMeter ovo:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Kako funkcionira naš sustav kontinuirane integracije možete pročitati u članku "".
Predložak i cjevovod
Primjer predloška za provođenje ispitivanja opterećenja dostupan je u projektu . U Možete pročitati upute za korištenje predloška. U samom predlošku (datoteka ) postoje bilješke o tome za što je odgovoran svaki korak.
Predložak je vrlo jednostavan i pokazuje tri faze testiranja opterećenja opisane u gornjem dijagramu: priprema, testiranje i objavljivanje izvješća. Odgovoran za ovo : Pripremite, testirajte i prijavite.
- faza treba koristiti za pretkonfiguriranje ciljeva testiranja ili provjeru njihove dostupnosti. Okruženje za izvore učitavanja ne treba konfigurirati, oni su unaprijed izgrađeni kao docker slike i objavljeni u docker registru: samo odredite željenu verziju u fazi testiranja. Ali možete ih ponovno izgraditi i izraditi vlastite modificirane slike.
- faza koristi se za određivanje izvora učitavanja, pokretanje testova i pohranjivanje artefakata testa. Možete odabrati bilo koji izvor učitavanja: Yandex.Tank, Apache JMeter, vlastiti ili sve zajedno. Da biste onemogućili nepotrebne izvore, samo komentirajte ili izbrišite posao. Ulazne točke za izvore opterećenja:
- Parametri pokretanja za Yandex.Tank navedeni su u .,
- Parametri pokretanja Apache JMetera navedeni su u datoteci .
Napomena: Predložak konfiguracije sklopa koristi se za postavljanje interakcije s CI sustavom i ne podrazumijeva postavljanje testne logike u njega. Za testove je navedena ulazna točka, gdje se nalazi kontrolna bash skripta. Metodu izvođenja testova, generiranje izvješća i same testne skripte moraju implementirati QA inženjeri. U demonstraciji, za oba izvora učitavanja, zahtjev za glavnu stranicu Yandexa koristi se kao najjednostavniji test. Skripte i testni parametri nalaze se u direktoriju .
- Na pozornici trebate opisati kako objaviti rezultate testiranja dobivene u fazi testiranja na vanjskim pohranama, na primjer, na GitLab stranicama ili posebnim sustavima za izvješćivanje. GitLab Pages zahtijeva da direktorij ./public ne bude prazan i da sadrži barem datoteku index.html nakon što testovi završe. Možete pročitati o nijansama usluge GitLab Pages. .
Primjeri izvoza podataka:
- od JMeter do ,
- od Yandex.Tank do .
Upute za postavljanje objave:
- HTML statika u ,
- u InfluxDB i zatim u .
U demo primjeru, cjevovod s testovima opterećenja i dva izvora opterećenja (možete onemogućiti nepotrebni) izgleda ovako:
Apache JMeter može sam generirati HTML izvješće pa je isplativije spremiti ga u GitLab Pages pomoću standardnih alata. Ovako izgleda Apache JMeter izvješće:
U demo primjeru za Yandex.Tank vidjet ćete samo u odjeljku za GitLab stranice. Tijekom testiranja, Tank može spremiti rezultate u InfluxDB bazu podataka, a odatle ih prikazati npr. u Grafanu (konfiguracija se vrši u datoteci ). Ovako izgleda Tankov izvještaj u Grafanu:
Rezime
U članku sam govorio o konceptu "testiranje opterećenja kao usluga" (testiranje opterećenja kao usluga). Glavna je ideja koristiti infrastrukturu unaprijed konfiguriranih skupova agenata učitavanja, docker slika izvora učitavanja, sustava izvješćivanja i cjevovoda koji ih kombinira u GitLab CI na temelju jednostavnog .gitlab-ci.yml predloška (primjer ). Sve to podržava mali tim inženjera za automatizaciju i replicira se na zahtjev proizvodnih timova. Nadam se da će vam ovo pomoći u pripremi i implementaciji slične sheme u vašoj tvrtki. Hvala na pažnji!
PS Želim reći veliku zahvalnost svojim kolegama, Sergeyu Kurbanovu i Nikolaju Yusevu, za tehničku pomoć pri implementaciji koncepta testiranja opterećenja kao usluge u našoj tvrtki.
Autor: - Zamjenik Voditelj odjela za tehnologije i razvojne procese (DevOps) u Positive Technologies
Izvor: www.habr.com