Jedan od problema sa kojima se dobavljači softvera za više proizvoda često suočavaju je dupliciranje kompetencija inženjera - programera, testera i administratora infrastrukture - u skoro svakom timu. To se odnosi i na skupe inženjere - specijaliste u području testiranja opterećenja.
Umjesto da obavljaju svoje direktne 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 infrastrukturu za testiranje od nule, konfigurirati alate za opterećenje i ugraditi ih sebe u CI sistemima, uspostavili praćenje i objavljivanje izvještaja.
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 integracije testova opterećenja u zajednički CI pipeline koristeći koncept “testiranja opterećenja kao usluge” (testiranje opterećenja kao usluge). Naučit ćete kako i koje docker slike izvora učitavanja se mogu koristiti u CI pipelineu; kako povezati izvore opterećenja sa vašim CI projektom koristeći build šablon; kako izgleda demo cevovod za izvođenje testova opterećenja i objavljivanje rezultata. Članak može biti koristan za inženjere za testiranje softvera i inženjere automatizacije u CI koji razmišljaju o arhitekturi svog sistema opterećenja.
Suština koncepta
Koncept testiranja opterećenja kao usluge podrazumijeva mogućnost integracije alata za učitavanje Apache JMeter, Yandex.Tank i vaših vlastitih okvira u proizvoljan kontinuirani sistem integracije. Demo će biti za GitLab CI, ali principi su zajednički za sve CI sisteme.
Testiranje opterećenja kao usluga je centralizirana usluga za testiranje opterećenja. Testovi opterećenja se pokreću u namenskim grupama agenata, rezultati se automatski objavljuju u GitLab Pages, Influx DB i Grafana ili u sistemima za izveštavanje o testovima (TestRail, ReportPortal, itd.). Automatizacija i skaliranje se implementiraju što je jednostavnije moguće - dodavanjem i parametriranjem uobičajenog gitlab-ci.yml šablona u GitLab CI projektu.
Prednost ovog pristupa je u tome što cjelokupnu CI infrastrukturu, agente za opterećenje, docker slike izvora opterećenja, cevovode za testiranje i objavljivanje izvještaja održava centralizirano odjeljenje za automatizaciju (DevOps inženjeri), dok inženjeri za testiranje opterećenja mogu usredotočiti svoje napore na razvoj testa. i analizu njihovih rezultata, bez bavljenja infrastrukturnim pitanjima.
Radi jednostavnosti opisa, pretpostavićemo da je ciljna aplikacija ili server koji se testira već postavljen i konfigurisan unapred (za ovo se mogu koristiti automatske skripte u Python, SaltStack, Ansible itd.). Tada se cijeli koncept testiranja opterećenja kao usluge uklapa u tri faze: priprema, testiranje, objavljivanje izvještaja. Više detalja na dijagramu (sve slike se mogu kliknuti):
Osnovni koncepti i definicije u testiranju opterećenja
Prilikom provođenja testova opterećenja nastojimo se pridržavati , koristite odgovarajuću terminologiju i preporučene metrike. Dat ću kratku listu glavnih koncepata i definicija u testiranju opterećenja.
Učitaj agenta - virtuelna mašina na kojoj će se aplikacija pokrenuti - izvor učitavanja (Apache JMeter, Yandex.Tank ili samopisani modul za učitavanje).
Cilj testa (meta) - server ili aplikacija instalirana na serveru koji će biti podložan učitavanju.
Test scenario (testni slučaj) - skup parametriziranih koraka: radnje korisnika i očekivane reakcije na te akcije, sa fiksnim mrežnim zahtjevima i odgovorima, ovisno o specificiranim parametrima.
Profil ili plan učitavanja (profil) - u (Odeljak 4.2.4, str. 43) profili opterećenja definišu metrike koje su kritične za određeni test i opcije za promenu parametara opterećenja tokom testa. Na slici možete vidjeti primjere profila.
Test — skripta sa unapred određenim skupom parametara.
Plan testiranja (test-plan) - skup testova i profil opterećenja.
Testran (testrun) - jedna iteracija izvođenja jednog testa sa potpuno izvršenim scenarijem opterećenja i primljenim izvještajem.
Mrežni zahtjev (zahtjev) — HTTP zahtjev poslan od agenta do cilja.
Mrežni odgovor (odgovor) — HTTP odgovor poslan od cilja do agenta.
HTTP kod odgovora (status HTTP odgovora) - standardni kod odgovora sa poslužitelja aplikacija.
Transakcija je potpuni ciklus zahtjev-odgovor. Transakcija se računa od početka slanja zahtjeva (zahtjeva) do završetka prijema odgovora (odgovora).
Status transakcije - da li je bilo moguće uspješno završiti ciklus zahtjev-odgovor. Ako je bilo greške u ovom ciklusu, onda se cijela transakcija smatra neuspješnom.
Vrijeme odgovora (latencija) - vrijeme od završetka slanja zahtjeva (zahtjeva) do početka prijema odgovora (odgovora).
Učitaj metriku — karakteristike opterećene usluge i agenta opterećenja utvrđene u procesu testiranja opterećenja.
Osnovne metrike za mjerenje parametara opterećenja
Neki od najčešće korištenih i preporučenih u metodologiji (str. 36, 52) metrike su prikazane u tabeli ispod. Slične metrike za agenta i cilja navedene su u istoj liniji.
metrika za agenta učitavanja
metrika ciljnog sistema ili aplikacije koja se testira pod opterećenjem
Broj vCPU i pamćenje RAM,
disk - "gvozdene" karakteristike agenta opterećenja
CPU, Memorija, upotreba diska - dinamika opterećenja procesora, memorije i diska
u procesu testiranja. Obično se mjeri kao postotak od
maksimalne dostupne vrijednosti
propusnost mreže (na agentu učitavanja) - propusnost
mrežni interfejs na serveru,
gdje je instaliran agent za učitavanje.
Obično se mjeri u bajtovima u sekundi (bps)
propusnost mreže(na cilju) - propusni opseg mrežnog interfejsa
na ciljnom serveru. Obično se mjeri u bajtovima u sekundi (bps)
Virtuelni korisnici- broj virtuelnih korisnika,
implementacija scenarija opterećenja i
imitiranje stvarnih radnji korisnika
Status virtuelnih korisnika, Passed/Failed/Total — broj uspješnih i
neuspješni statusi virtuelnih korisnika
za scenarije opterećenja, kao i njihov ukupan broj.
Općenito se očekuje da su svi korisnici uspjeli završiti
svi vaši zadaci navedeni u profilu učitavanja.
Svaka greška znači da pravi korisnik neće moći
riješite svoj problem pri radu sa sistemom
Zahtjevi u sekundi (minuta)- broj mrežnih zahtjeva u sekundi (ili minuti).
Važna karakteristika agenta učitavanja je koliko zahtjeva može generirati.
U stvari, ovo je imitacija pristupa aplikaciji od strane virtuelnih korisnika
Odgovori u sekundi (minuta)
- broj mrežnih odgovora u sekundi (ili minuti).
Važna karakteristika ciljne usluge: koliko
generirati i slati odgovore na upite sa
agent za utovar
Status HTTP odgovora— broj različitih kodova odgovora
sa poslužitelja aplikacija koje je primio agent za učitavanje.
Na primjer, 200 OK znači uspješan poziv,
i 404 - da izvor nije pronađen
latentnost (vrijeme odziva) - 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 kompletne 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, na primjer, 90. percentil.
Minimalna i maksimalna očitanja su ekstremna
status performansi sistema.
Devedeseti percentil je najčešće korišten,
kao što pokazuje većina korisnika,
udobno radi na pragu performansi sistema
Transakcije u sekundi (minuta) - broj kompletnih
transakcije u sekundi (minuti),
odnosno koliko je aplikacija mogla prihvatiti i
obrađuju zahtjeve i odgovore na pitanja.
U stvari, ovo je propusnost sistema
Status transakcije , Položeno / Neuspjelo / Ukupno - broj
uspješne, neuspješne i ukupan broj transakcija.
Za prave korisnike neuspješno
transakcija će zapravo značiti
nemogućnost rada sa sistemom pod opterećenjem
Šematski dijagram testiranja opterećenja
Koncept testiranja opterećenja je vrlo jednostavan i sastoji se od tri glavne faze, koje sam već spomenuo: Pripremi-Test-Izvještaj, odnosno priprema ciljeva testiranja i postavljanje parametara za izvore opterećenja, zatim izvođenje testova opterećenja i, na kraju, generiranje i objavljivanje izvještaja o testiranju.
Šematske napomene:
- QA.Tester je stručnjak za testiranje opterećenja,
- Cilj je ciljna aplikacija za koju želite da saznate njeno ponašanje pod opterećenjem.
Klasifikator entiteta, faza i koraka u dijagramu
Faze i koraci
Šta se dešava
Šta je na ulazu
Šta je izlaz
Priprema: faza pripreme za testiranje
LoadParameters
Postavljanje i inicijalizacija
korisnika
parametri opterećenja,
izbor metrike i
priprema plana testiranja
(učitaj profil)
Prilagođene opcije za
inicijalizacija agenta učitavanja
Plan testiranja
Svrha testiranja
VM
Cloud implementacija
virtuelna mašina sa
potrebne karakteristike
VM postavke za agenta učitavanja
Skripte za automatizaciju za
Kreiranje VM
VM konfigurisan u
oblak
Pošalji
Podešavanje i priprema OS-a
okruženje za
posao agenta učitavanja
Postavke okruženja za
load agent
Skripte za automatizaciju za
postavke okruženja
Pripremljeno okruženje:
OS, usluge i aplikacije,
neophodna za rad
load agent
LoadAgents
Instalacija, konfiguracija i parametriranje
agent za utovar.
Ili preuzimanje docker slike sa
unaprijed konfigurirani izvor učitavanja
Učitaj izvornu docker sliku
(YAT, JM ili samostalno pisani okvir)
Postavke
load agent
Postavljeno i spremno
agentu za radno opterećenje
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
sa odabranim planom testiranja
i parametre opterećenja
Korisničke opcije
za inicijalizaciju
load agent
Plan testiranja
Svrha testiranja
Dnevnici izvršenja
testovi opterećenja
Sistemski dnevnici
Dinamika promjena metrike ciljeva i agenta opterećenja
Pokreni agente
Agent Execution
gomilu test skripti
u skladu s
profil opterećenja
Učitavanje interakcije agenta
u svrhu testiranja
Plan testiranja
Svrha testiranja
Trupci
Zbirka "sirovih" trupaca
tokom testiranja opterećenja:
učitavanje zapisa aktivnosti agenta,
stanje testne mete
i VM koji pokreće agenta
Dnevnici izvršenja
testovi opterećenja
Sistemski dnevnici
metrika
Prikupljanje "sirovih" metrika tokom testiranja
Dinamika promjena u metrici golova
i agent za učitavanje
Izveštaj: faza pripreme izveštaja o ispitivanju
generator
Obrada prikupljena
sistem utovara i
sistem za praćenje "sirov"
metrike i evidencije
Formiranje izvještaja u
ljudskom čitljivom obliku
moguće sa elementima
analitičari
Dnevnici izvršenja
testovi opterećenja
Sistemski dnevnici
Dinamika promjena metrike
cilj i agent učitavanja
Obrađeni "sirovi" trupci
u formatu pogodnom za
otpremanja na eksternu pohranu
Izvještaj o statičkom opterećenju,
čitljiv za ljude
objaviti
Objavljivanje izvještaja
o opterećenju
testiranje u eksternom
usluga
Prerađeno "sirovo"
evidencije u odgovarajućem formatu
za istovar na eksternu
spremišta
Sačuvano u eksternom
izvještaji o skladištenju
opterećenje, pogodno
za ljudske analize
Povezivanje izvora opterećenja u CI predlošku
Pređimo na praktični dio. Želim da pokažem kako na nekim projektima u kompaniji implementirali smo koncept testiranja opterećenja kao usluge.
Prvo, uz pomoć naših DevOps inženjera, kreirali smo namenski skup agenata u GitLab CI za pokretanje testova opterećenja. Kako ih ne bismo pomiješali u predlošcima s drugima, kao što su skupovi sklopova, dodali smo oznake ovim agentima, : opterećenje. Možete koristiti bilo koje druge razumljive oznake. Pitaju GitLab CI Runners.
Kako saznati potrebnu snagu po hardveru? Karakteristike agenata učitavanja - dovoljan broj vCPU-a, RAM-a i diska - mogu se izračunati na osnovu činjenice da na agentu treba da rade Docker, Python (za Yandex.Tank), GitLab CI agent, Java (za Apache JMeter). . Za Javu pod JMeter-om, također se preporučuje korištenje minimalno 512 MB RAM-a i, kao gornje granice, .
Stoga, na osnovu 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 se određuje na osnovu 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 bazirana je na Phantomovom visokoučinkovitom asinhronom generatoru HTTP zahtjeva zasnovanom na hitovima. Rezervoar ima ugrađeno praćenje resursa servera koji se testira preko SSH protokola, može automatski zaustaviti test pod određenim uslovima, može prikazati rezultate kako u konzoli tako i u obliku grafikona, možete povezati svoje module za proširenje funkcionalnosti. Inače, koristili smo Tank kada još nije bio mainstream. U članku "» možete pročitati priču o tome kako smo s njim izvršili testiranje opterećenja 2013. godine je jedan od proizvoda naše kompanije.
je Apacheov alat za testiranje opterećenja otvorenog koda. Može se jednako dobro koristiti za testiranje i statičkih i dinamičkih web aplikacija. JMeter podržava veliki broj protokola i načina interakcije sa aplikacijama: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, itd.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) i IMAP(S), baze podataka preko JDBC-a, mogu izvršavati naredbe ljuske i raditi sa Java objektima. JMeter ima IDE za kreiranje, otklanjanje grešaka i izvršavanje planova testiranja. Postoji i CLI za rad sa komandnom linijom na bilo kom Javi kompatibilnom operativnom sistemu (Linux, Windows, Mac OS X). Alat može dinamički generirati HTML izvještaj o testu.
Radi lakšeg korišćenja unutar naše kompanije, radi mogućnosti samih testera da menjaju i dodaju okruženje, napravili smo build docker slike izvora učitavanja na GitLab CI sa objavljivanjem na internom . To čini bržim i lakšim njihovo povezivanje u cjevovode za testove opterećenja. Kako napraviti docker push u registar preko GitLab CI - pogledajte .
Uzeli smo ovaj osnovni docker fajl za Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]A za Apache JMeter ovo:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Kako funkcioniše naš sistem kontinuirane integracije možete pročitati u članku "".
Šablon i kanal
Primjer predloška za provođenje testova opterećenja dostupan je u projektu . The Možete pročitati upute za korištenje šablona. U samom predlošku (fajl ) postoje napomene o tome za šta je odgovoran svaki korak.
Šablon je vrlo jednostavan i pokazuje tri faze testiranja opterećenja opisane u dijagramu iznad: priprema, testiranje i objavljivanje izvještaja. Odgovoran za ovo : Pripremite, testirajte i prijavite.
- Scena treba koristiti za prethodno konfiguriranje testnih ciljeva ili provjeru njihove dostupnosti. Okruženje za izvore učitavanja nije potrebno konfigurirati, oni su unaprijed napravljeni kao docker slike i objavljeni u docker registru: samo navedite željenu verziju u fazi testiranja. Ali možete ih obnoviti i napraviti vlastite modificirane slike.
- Scena koristi se za specificiranje 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 tačke za izvore opterećenja:
- Parametri pokretanja za Yandex.Tank navedeni su u .,
- Parametri pokretanja Apache JMeter-a navedeni su u datoteci .
Napomena: Šablon konfiguracije sklopa se koristi za postavljanje interakcije sa CI sistemom i ne podrazumijeva postavljanje testne logike u njega. Za testove je navedena ulazna tačka u kojoj se nalazi kontrolna bash skripta. Metodu izvođenja testova, generiranja izvještaja i same test skripte moraju implementirati QA inženjeri. U demonstraciji, za oba izvora učitavanja, zahtjev glavne stranice Yandexa se koristi kao najjednostavniji test. Skripte i test parametri su u direktoriju .
- Na pozornici potrebno je da opišete kako da objavite rezultate testa dobijene u fazi testiranja na eksternim skladištima, na primer, na GitLab stranicama ili posebnim sistemima za izveštavanje. GitLab Pages zahtijeva da direktorij ./public ne bude prazan i da sadrži barem index.html datoteku nakon završetka testova. Možete pročitati o nijansama usluge GitLab Pages. .
Primjeri kako izvesti podatke:
- od JMetera do ,
- od Yandex.Tank do .
Objavljivanje uputstva za podešavanje:
- HTML statika u ,
- na InfluxDB, a zatim na .
U demo primjeru, cjevovod s testovima opterećenja i dva izvora opterećenja (možete onemogućiti nepotreban) izgleda ovako:
Apache JMeter može sam da generiše HTML izveštaj, tako da je isplativije sačuvati ga u GitLab stranicama koristeći standardne alate. Ovako izgleda izvještaj Apache JMeter:
U demo primjeru za Yandex.Tank, vidjet ćete samo u odjeljku za GitLab stranice. Tokom testiranja, Tank može pohraniti rezultate u bazu podataka InfluxDB, a odatle se mogu prikazati npr. u Grafani (konfiguracija se vrši u datoteci ). Ovako izgleda Tankov izvještaj u Grafani:
Rezime
U članku sam govorio o konceptu "testiranja opterećenja kao usluge" (testiranje opterećenja kao usluge). Glavna ideja je da se koristi infrastruktura unapred konfigurisanih skupova agenata učitavanja, docker slika izvora učitavanja, sistema izveštavanja i cevovoda koji ih kombinuje u GitLab CI baziran na jednostavnom .gitlab-ci.yml šablonu (primer ). Sve ovo podržava mali tim inženjera za automatizaciju i replicira na zahtjev proizvodnih timova. Nadam se da će vam ovo pomoći u pripremi i implementaciji slične šeme u vašoj kompaniji. Hvala vam na pažnji!
PS Želim da kažem veliko hvala mojim kolegama, Sergeju Kurbanovu i Nikolaju Jusevu, na tehničkoj pomoći u implementaciji koncepta testiranja opterećenja kao usluge u našoj kompaniji.
autor: - Zamenik Voditelj tehnologije i razvojnih procesa (DevOps) u Positive Technologies
izvor: www.habr.com