Jedným z problémov, s ktorými sa predajcovia softvéru pre viacero produktov často stretávajú, je zdvojenie kompetencií inžinierov – vývojárov, testerov a správcov infraštruktúry – takmer v každom tíme. To platí aj pre drahých inžinierov – špecialistov v oblasti záťažových testov.
Namiesto toho, aby plnili svoje priame povinnosti a využívali svoje jedinečné skúsenosti na zostavenie procesu testovania záťaže, výber metodológie, optimálnych metrík a písanie autotestov v súlade s profilmi záťaže, inžinieri často musia nasadiť testovaciu infraštruktúru od začiatku, nakonfigurovať nástroje záťaže a vložiť ich. v systémoch KI, zaviedli monitorovanie a zverejňovanie správ.
Riešenia niektorých organizačných problémov nájdete v testovaní, ktoré používame v spoločnosti Positive Technologies v . A v tomto budem hovoriť o možnosti integrácie záťažových testov do spoločného CI potrubia pomocou konceptu „testovania záťaže ako služby“ (testovanie záťaže ako služba). Dozviete sa, ako a ktoré ukotvovacie obrazy zdrojov zaťaženia možno použiť v potrubí CI; ako pripojiť zdroje zaťaženia k projektu CI pomocou šablóny zostavy; ako vyzerá ukážkový kanál na spustenie záťažových testov a zverejnenie výsledkov. Článok môže byť užitočný pre softvérových testovacích inžinierov a automatizačných inžinierov v CI, ktorí uvažujú o architektúre svojho zaťažovacieho systému.
Podstata konceptu
Koncept záťažového testovania ako služby zahŕňa schopnosť integrovať záťažové nástroje Apache JMeter, Yandex.Tank a vaše vlastné frameworky do ľubovoľného kontinuálneho integračného systému. Demo bude pre GitLab CI, ale princípy sú spoločné pre všetky CI systémy.
Záťažové testovanie ako služba je centralizovaná služba pre záťažové testovanie. Záťažové testy prebiehajú vo vyhradených fondoch agentov, výsledky sa zverejňujú automaticky v GitLab Pages, Influx DB a Grafana alebo v testovacích reportovacích systémoch (TestRail, ReportPortal atď.). Automatizácia a škálovanie sú implementované čo najjednoduchšie – pridaním a parametrizáciou obvyklej šablóny gitlab-ci.yml v projekte GitLab CI.
Výhodou tohto prístupu je, že celá infraštruktúra CI, agenti zaťaženia, obrázky dokovacích zdrojov záťaže, testovacie kanály a publikované správy sú udržiavané centralizovaným oddelením automatizácie (inžinieri DevOps), zatiaľ čo inžinieri testovania záťaže môžu sústrediť svoje úsilie na vývoj testov. a analýzu ich výsledkov bez toho, aby sa zaoberali otázkami infraštruktúry.
Pre jednoduchosť popisu budeme predpokladať, že testovaná cieľová aplikácia alebo server je už vopred nasadený a nakonfigurovaný (možno na to použiť automatizované skripty v Pythone, SaltStack, Ansible atď.). Potom celý koncept testovania záťaže ako služby zapadá do troch etáp: príprava, testovanie, zverejňovanie správ. Viac podrobností o schéme (na všetky obrázky sa dá kliknúť):
Základné pojmy a definície v záťažovom testovaní
Pri vykonávaní záťažových skúšok sa snažíme dodržiavať , používajte vhodnú terminológiu a odporúčané metriky. Uvediem krátky zoznam hlavných pojmov a definícií v záťažovom testovaní.
Záťažový agent - virtuálny počítač, na ktorom bude aplikácia spustená - zdroj načítania (Apache JMeter, Yandex.Tank alebo samostatne napísaný modul načítania).
Testovací cieľ (cieľ) - server alebo aplikácia nainštalovaná na serveri, ktorá bude zaťažená.
Testovací scenár (testovací prípad) - súbor parametrizovaných krokov: akcie užívateľa a očakávané reakcie na tieto akcie, s požiadavkami a odpoveďami pevnej siete v závislosti od špecifikovaných parametrov.
Profil alebo plán načítania (profil) - v (časť 4.2.4, s. 43) profily zaťaženia definujú metriky, ktoré sú kritické pre konkrétny test a možnosti zmeny parametrov zaťaženia počas testu. Príklady profilov môžete vidieť na obrázku.
Test — skript s vopred určeným súborom parametrov.
Testovací plán (testovací plán) - súbor testov a profil zaťaženia.
Testran (testovanie) - jedna iterácia spustenia jedného testu s plne vykonaným scenárom zaťaženia a prijatou správou.
Sieťová požiadavka (žiadosť) — Požiadavka HTTP odoslaná z agenta do cieľa.
Sieťová odozva (reakcia) — HTTP odpoveď odoslaná z cieľa agentovi.
Kód odpovede HTTP (stav odpovede HTTP) - štandardný kód odpovede z aplikačného servera.
Transakcia je úplný cyklus žiadosť – odpoveď. Transakcia sa počíta od začiatku odoslania požiadavky (request) až po ukončenie prijatia odpovede (response).
Stav transakcie - či bolo možné úspešne dokončiť cyklus žiadosť – odpoveď. Ak sa v tomto cykle vyskytla nejaká chyba, potom sa celá transakcia považuje za neúspešnú.
čas odozvy (latencia) - čas od konca odoslania požiadavky (požiadavky) do začiatku prijatia odpovede (odpovede).
Metriky načítania — charakteristiky prevádzky naloženého vozidla a činiteľa zaťaženia určeného v procese testovania zaťaženia.
Základné metriky na meranie parametrov zaťaženia
Niektoré z najčastejšie používaných a odporúčaných v metodike (s. 36, 52) sú metriky uvedené v tabuľke nižšie. Podobné metriky pre agenta a cieľ sú uvedené v rovnakom riadku.
Metriky pre agenta zaťaženia
Metriky cieľového systému alebo aplikácie testovanej pri zaťažení
Číslo vCPU a pamäť RAM,
Disk - "železné" vlastnosti nakladacieho prostriedku
CPU, Pamäť, využitie disku - dynamika zaťaženia CPU, pamäte a disku
v procese testovania. Zvyčajne sa meria v percentách
maximálne dostupné hodnoty
priepustnosť siete (on load agent) - priepustnosť
sieťové rozhranie na serveri,
kde je nainštalovaný zaťažovací prostriedok.
Zvyčajne sa meria v bajtoch za sekundu (bps)
priepustnosť siete(on target) - šírka pásma sieťového rozhrania
na cieľovom serveri. Zvyčajne sa meria v bajtoch za sekundu (bps)
Virtuálni používatelia- počet virtuálnych používateľov,
implementácia scenárov zaťaženia a
napodobňovanie skutočných akcií používateľov
Stav virtuálnych používateľov, Úspešné/Neúspešné/Celkom — počet úspešných a
neúspešné stavy virtuálnych užívateľov
pre scenáre zaťaženia, ako aj ich celkový počet.
Vo všeobecnosti sa očakáva, že všetci používatelia boli schopní dokončiť
všetky vaše úlohy špecifikované v profile zaťaženia.
Akákoľvek chyba bude znamenať, že skutočný používateľ to nebude môcť
vyriešiť váš problém pri práci so systémom
Počet žiadostí za sekundu (minútu)- počet sieťových požiadaviek za sekundu (alebo minútu).
Dôležitou charakteristikou agenta zaťaženia je počet požiadaviek, ktoré dokáže vygenerovať.
V skutočnosti ide o napodobňovanie prístupu virtuálnych používateľov do aplikácie
Odpovede za sekundu (minútu)
- počet odoziev siete za sekundu (alebo minútu).
Dôležitá charakteristika cieľovej služby: koľko
generovať a odosielať odpovede na otázky pomocou
nakladací prostriedok
Stav odpovede HTTP— počet rôznych kódov odpovede
z aplikačného servera prijatého agentom načítania.
Napríklad 200 OK znamená úspešný hovor,
a 404 - že zdroj sa nenašiel
latencia (čas odozvy) - čas od konca
odoslanie požiadavky (request) pred začatím prijímania odpovede (response).
Zvyčajne sa meria v milisekundách (ms)
Čas odozvy transakcie— čas jednej dokončenej transakcie,
dokončenie cyklu žiadosť – odpoveď.
Ide o čas od začiatku odosielania požiadavky (žiadosti)
až do ukončenia prijatia odpovede (odpovede).
Čas transakcie možno merať v sekundách (alebo minútach)
niekoľkými spôsobmi: zvážte minimum,
maximum, priemer a napríklad 90. percentil.
Minimálne a maximálne hodnoty sú extrémne
stav výkonu systému.
Deväťdesiaty percentil je najčastejšie používaný,
ako ukazuje väčšina používateľov,
pohodlne fungujúce na prahu výkonu systému
Transakcie za sekundu (minútu) - počet dokončených
transakcie za sekundu (minútu),
teda koľko bola aplikácia schopná prijať a
spracovávať požiadavky a vydávať odpovede.
V skutočnosti ide o priepustnosť systému
Stav transakcie , Úspešne / Neúspešne / Celkom - číslo
úspešné, neúspešné a celkový počet transakcií.
Pre skutočných používateľov neúspešné
transakcia bude v skutočnosti znamenať
neschopnosť pracovať so systémom pri zaťažení
Schéma schémy záťažového testu
Koncept záťažového testovania je veľmi jednoduchý a pozostáva z troch hlavných etáp, ktoré som už spomenul: Pripravte-Test-Report, teda príprava testovacích cieľov a nastavenie parametrov pre zdroje záťaže, následné vykonanie záťažových testov a na záver vygenerovanie a zverejnenie správy o teste.
Schematické poznámky:
- QA.Tester je odborník na záťažové testovanie,
- Cieľ je cieľová aplikácia, pre ktorú chcete poznať jej správanie pri zaťažení.
Klasifikátor entít, štádií a krokov v diagrame
Etapy a kroky
Čo sa deje
Čo je pri vchode
Aký je výstup
Príprava: prípravná fáza na testovanie
LoadParameters
Nastavenie a inicializácia
používateľ
parametre zaťaženia,
výber metrík a
príprava plánu testov
(načítať profil)
Vlastné možnosti pre
inicializácia načítacieho agenta
Testovací plán
Účel testovania
VM
Nasadenie cloudu
virtuálny stroj s
požadované vlastnosti
Nastavenia virtuálneho počítača pre agenta načítania
Automatizačné skripty pre
vytváranie VM
VM nakonfigurovaný v
oblak
env
Nastavenie a príprava OS
prostredie pre
práca agenta zaťaženia
Nastavenia prostredia pre
zaťažovací prostriedok
Automatizačné skripty pre
nastavenia prostredia
Pripravené prostredie:
OS, služby a aplikácie,
potrebné pre prácu
zaťažovací prostriedok
LoadAgents
Inštalácia, konfigurácia a parametrizácia
nakladací prostriedok.
Alebo si stiahnite obrázok doku z
predkonfigurovaný zdroj zaťaženia
Načítať zdrojový obrázok doku
(YAT, JM alebo samostatne napísaný rámec)
nastavenie
zaťažovací prostriedok
Nastavené a pripravené
na pracovnú záťaž agenta
Test: fáza vykonávania záťažových skúšok. Zdroje sú agenti zaťaženia nasadení vo vyhradených fondoch agentov pre GitLab CI
Load
Spustenie Load Agenta
s vybraným testovacím plánom
a parametre zaťaženia
Možnosti používateľa
pre inicializáciu
zaťažovací prostriedok
Testovací plán
Účel testovania
Protokoly vykonávania
záťažové testy
Systémové denníky
Dynamika zmien cieľových metrík a agenta zaťaženia
Spustite agentov
Poprava agenta
množstvo testovacích skriptov
v súlade s
zaťažovací profil
Načítať interakciu agenta
za účelom testovania
Testovací plán
Účel testovania
Záznamy
Zbierka "surových" guľatiny
počas záťažovej skúšky:
záznamy o činnosti agenta zaťaženia,
stav testovacieho cieľa
a VM, na ktorom je spustený agent
Protokoly vykonávania
záťažové testy
Systémové denníky
Metrics
Zhromažďovanie „surových“ metrík počas testovania
Dynamika zmien cieľových metrík
a zaťažovací prostriedok
Správa: fáza prípravy správy o skúške
Generator
Spracovanie zhromaždené
nakladací systém a
monitorovací systém "raw"
metriky a denníky
Vytvorenie správy v
ľudsky čitateľná forma
možné s prvkami
analytici
Protokoly vykonávania
záťažové testy
Systémové denníky
Dynamika zmien v metrikách
cieľový a zaťažovací agent
Spracované "surové" guľatiny
vo formáte vhodnom pre
nahráva do externého úložiska
správa o statickom zaťažení,
ľudsky čitateľný
Publikovať
Zverejnenie správy
o záťaži
testovanie v externom prostredí
služby
Spracované "surové"
protokoly vo vhodnom formáte
na vyloženie do externého
úložiská
Uložené v externom prostredí
správy o skladovaní
zaťaženie, vhodné
pre analýzu ľudí
Pripojenie zdrojov zaťaženia v šablóne CI
Prejdime k praktickej časti. Chcem ukázať ako na niektorých projektoch vo firme implementovali sme koncept záťažového testovania ako službu.
Najprv sme s pomocou našich inžinierov DevOps vytvorili vyhradený fond agentov v GitLab CI na spustenie záťažových testov. Aby sme si ich v šablónach nepomýlili s inými, ako sú napríklad zostavy, pridali sme k týmto agentom značky, : naložiť. Môžete použiť akékoľvek iné zrozumiteľné značky. Pýtajú sa GitLab CI Runners.
Ako zistiť potrebný výkon hardvérom? Charakteristiky agentov zaťaženia - dostatočný počet vCPU, RAM a disku - možno vypočítať na základe skutočnosti, že na agentovi by mali bežať Docker, Python (pre Yandex.Tank), GitLab CI agent, Java (pre Apache JMeter). . Pre Javu pod JMeter sa tiež odporúča použiť minimálne 512 MB RAM a ako horný limit, .
Preto na základe našich skúseností odporúčame použiť aspoň 4 vCPU, 4 GB RAM, 60 GB SSD pre agentov zaťaženia. Priepustnosť sieťovej karty je určená na základe požiadaviek profilu zaťaženia.
Používame hlavne dva zdroje načítania – Apache JMeter a obrázky dokovacích staníc Yandex.Tank.
je nástroj s otvoreným zdrojom od spoločnosti Yandex na testovanie záťaže. Jeho modulárna architektúra je založená na vysokovýkonnom asynchrónnom generátore HTTP požiadaviek založených na asynchrónnom prístupe od Phantomu. Tank má zabudovaný monitoring zdrojov testovaného servera cez protokol SSH, dokáže automaticky zastaviť test za špecifikovaných podmienok, dokáže zobraziť výsledky ako v konzole, tak aj vo forme grafov, môžete pripojiť svoje moduly na rozšírenie funkčnosti. Mimochodom, Tank sme používali, keď ešte nebol mainstream. V článku "» si môžete prečítať príbeh o tom, ako sme s ním v roku 2013 vykonávali záťažové testy je jedným z produktov našej spoločnosti.
je open source nástroj na testovanie záťaže od Apache. Dá sa rovnako dobre použiť na testovanie statických aj dynamických webových aplikácií. JMeter podporuje obrovské množstvo protokolov a spôsobov interakcie s aplikáciami: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET atď.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) a IMAP(S), databázy cez JDBC, môžu vykonávať príkazy shellu a pracovať s objektmi Java. JMeter má IDE na vytváranie, ladenie a vykonávanie testovacích plánov. K dispozícii je tiež CLI pre prácu s príkazovým riadkom na akomkoľvek operačnom systéme kompatibilnom s Java (Linux, Windows, Mac OS X). Nástroj dokáže dynamicky generovať správu o teste HTML.
Pre jednoduché používanie v rámci našej spoločnosti, pre schopnosť samotných testerov meniť a pridávať prostredie sme vytvorili zostavy dockerových obrazov zdrojov zaťaženia na GitLab CI s publikovaním do interných . Vďaka tomu je rýchlejšie a jednoduchšie ich spájať do potrubí pre záťažové testy. Ako urobiť docker push do registra cez GitLab CI - viď .
Vzali sme tento základný súbor docker pre Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]A pre Apache JMeter toto:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Ako funguje náš priebežný integračný systém si môžete prečítať v článku "".
Šablóna a kanál
Príklad šablóny na vykonávanie záťažových testov je dostupný v projekte . V Môžete si prečítať pokyny na používanie šablóny. V samotnej šablóne (súbor ) sú tam poznámky o tom, za čo sú jednotlivé kroky zodpovedné.
Šablóna je veľmi jednoduchá a demonštruje tri fázy testovania záťaže opísané v diagrame vyššie: príprava, testovanie a publikovanie správ. Zodpovedný za to : Pripravte, otestujte a nahláste.
- štádium by sa mali použiť na predkonfiguráciu testovacích cieľov alebo na kontrolu ich dostupnosti. Prostredie pre zdroje zaťaženia nie je potrebné konfigurovať, sú vopred zostavené ako obrazy dockerov a zverejnené v registri dockerov: stačí zadať požadovanú verziu vo fáze Test. Môžete ich však prebudovať a vytvoriť si vlastné upravené obrázky.
- štádium používa sa na špecifikáciu zdroja zavádzania, spustenie testov a ukladanie artefaktov testu. Môžete si vybrať ľubovoľný zdroj zaťaženia: Yandex.Tank, Apache JMeter, svoj vlastný alebo všetky spolu. Ak chcete zakázať nepotrebné zdroje, jednoducho pridajte komentár alebo odstráňte úlohu. Vstupné body pre zdroje zaťaženia:
- Parametre spustenia pre Yandex.Tank sú špecifikované v súbore .,
- Parametre spúšťania Apache JMeter sú špecifikované v súbore .
Poznámka: Šablóna konfigurácie zostavy sa používa na nastavenie interakcie so systémom CI a neznamená umiestnenie testovacej logiky do nej. Pre testy je určený vstupný bod, kde sa nachádza riadiaci bash skript. Spôsob spúšťania testov, generovanie správ a samotné testovacie skripty musia implementovať inžinieri kontroly kvality. V ukážke sa pre oba zdroje načítania používa požiadavka na hlavnú stránku Yandex ako najjednoduchší test. Skripty a testovacie parametre sú v adresári .
- Na javisku musíte opísať, ako publikovať výsledky testov získané v testovacej fáze na externé úložiská, napríklad na stránky GitLab alebo špeciálne reportovacie systémy. Stránky GitLab vyžadujú, aby adresár ./public nebol prázdny a po dokončení testov obsahoval aspoň súbor index.html. Môžete si prečítať o nuansách služby GitLab Pages. .
Príklady exportovania údajov:
- z JMeter do ,
- z Yandex.Tank do .
Pokyny na nastavenie odosielania:
- HTML statika v ,
- do InfluxDB a potom do .
V ukážkovom príklade vyzerá potrubie so záťažovými testami a dvoma zdrojmi záťaže (nepotrebné môžete vypnúť) takto:
Apache JMeter dokáže generovať HTML report sám, takže je výhodnejšie ho uložiť na GitLab Pages pomocou štandardných nástrojov. Takto vyzerá správa Apache JMeter:
V ukážkovom príklade pre Yandex.Tank uvidíte iba v sekcii pre stránky GitLab. Počas testovania môže Tank uložiť výsledky do databázy InfluxDB a odtiaľ ich zobraziť napríklad v Grafane (konfigurácia sa vykonáva v súbore ). Takto vyzerá Tankova správa v Grafane:
Zhrnutie
V článku som hovoril o koncepte „testovanie záťaže ako služba“ (testovanie záťaže ako služba). Hlavnou myšlienkou je využiť infraštruktúru predkonfigurovaných fondov záťažových agentov, dockerových obrazov zdrojov záťaže, reportovacích systémov a pipeline, ktorá ich kombinuje v GitLab CI na základe jednoduchej šablóny .gitlab-ci.yml (príklad ). Toto všetko podporuje malý tím automatizačných inžinierov a replikuje sa na žiadosť produktových tímov. Dúfam, že vám to pomôže pri príprave a implementácii podobnej schémy vo vašej spoločnosti. Ďakujem za pozornosť!
PS Chcem sa veľmi pekne poďakovať svojim kolegom Sergejovi Kurbanovovi a Nikolajovi Yusevovi za technickú pomoc pri implementácii konceptu záťažového testovania ako služby v našej spoločnosti.
Autor: - Zástupca Vedúci technológie a vývojových procesov (DevOps) v spoločnosti Positive Technologies
Zdroj: hab.com