Jedným z problémov, s ktorými sa často stretávajú viaceré softvérové firmy, je duplicita kompetencií inžinierov — vývojárov, testerov a administrátorov infraštruktúry — takmer v každom tíme. To sa týka aj nákladných inžinierov — odborníkov na testovanie záťaže.
Namiesto toho, aby sa venovali svojim priamym povinnostiam a využívali svoje jedinečné skúsenosti na budovanie procesu testovania záťaže, výber metodológie, optimálne hodnoty metrík a písanie automatizovaných testov podľa profilov záťaže, inžinieri sa často musia od základov zaoberať nastavovaním testovacej infraštruktúry, nastavovaním nástrojov záťaže, ich integráciou do CI systémov, konfiguráciou monitorovania a publikovaním správ.
Riešenia niektorých organizačných problémov v testovaní, ktoré používame v Positive Technologies, nájdete v . A v tomto článku sa zameriam na integráciu testov záťaže do celkového CI reťazca pomocou konceptu „testovanie záťaže ako služba“ (load testing as a service). Dozviete sa, aké docker obrazy zdrojov záťaže je možné použiť v CI reťazci; ako pripojiť zdroje záťaže do svojho CI projektu pomocou stavebného šablónu; aký je demopipeline pre spustenie testov záťaže a publikovanie výsledkov. Článok by mohol byť užitočný pre testerov softvéru a inžinierov automatizátorov v CI, ktorí premýšľajú o architektúre svojho systému záťaže.
Podstata konceptu
Koncept testovania záťaže ako služby predpokladá možnosť integrácie nástrojov záťaže Apache JMeter, Yandex.Tank a vlastných rámcov do akejkoľvek systému kontinuálnej integrácie. Demopříklad bude pre GitLab CI, ale zásady sú všeobecné pre všetky CI systémy.
Testovanie záťaže ako služba je centralizovaná služba na vykonávanie testovania záťaže. Testy záťaže sa spúšťajú v vyhradených skupinách agentov, publikovanie výsledkov prebieha automaticky v GitLab Pages, Influx DB a Grafana alebo v systémoch na reportovanie testov (TestRail, ReportPortal a pod.). Automatizácia a škálovanie sa realizujú maximálne jednoducho — pridaním a parametrazáciou v projekte GitLab CI bežnej šablóny gitlab-ci.yml.
Hlavnou výhodou tohto prístupu je, že celá CI infraštruktúra, záťažové agenti, Docker obrazy zdrojov záťaže, testovacie pipeline a publikovanie správ — sú podporované silami centralizovaného oddelenia automatizácie (DevOps inžiniermi), zatiaľ čo inžinieri zaťažovania sa môžu zamerať na vývoj testov a analýzu ich výsledkov, bez zaoberania sa infraštruktúrnymi otázkami.
Pre jednoduchosť opisu predpokladajme, že cieľová testovaná aplikácia alebo server sú už nasadené a nastavené vopred (na to môžu byť použité automatizované skripty na Pythone, SaltStack, Ansible a iné). Potom celá koncepcia záťažového testovania ako služby spočíva v troch fázach: príprava, testovanie, publikovanie správ. Viac informácií v schéme (všetky obrázky sú klikateľné):
Základné pojmy a definície v záťažovom testovaní
Pri vykonávaní záťažových testov sa snažíme dodržiavať , používame príslušnú terminológiu a odporúčané metriky. Uvediem krátky zoznam základných pojmov a definícií v záťažovom testovaní.
Záťažový agent (load agent) — virtuálny stroj, na ktorom bude spustená aplikácia — zdroj záťaže (Apache JMeter, Yandex.Tank alebo vlastný záťažový modul).
Cieľ testovania (target) — server alebo aplikácia, ktorá je nainštalovaná na serveri a bude podrobovaná záťaži.
Testovací scenár (test case) — súbor parametizovaných krokov: činnosti používateľov a očakávané reakcie na tieto činnosti, so zaznamenanými sieťovými požiadavkami a odpoveďami, v závislosti od zadaných parametrov.
Profil alebo plán záťaže (profile) — v (b. 4.2.4, str. 43) profily záťaže definujú kriticky dôležité metriky pre konkrétny test a možnosti zmeny parametrov záťaže počas testu. Príklady profilov môžete vidieť na obrázku.
Test (test) — scenár s vopred definovaným súborom parametrov.
Testovací plán (test-plan) — súbor testov a profil záťaže.
Testran (testrun) — jedna iterácia spustenia jedného testu s úplne vykonaným scenárom záťaže a získanou správou.
Sieťový požiadavok (request) — HTTP požiadavok odosielaný od agenta k cieľu.
Sieťová odpoveď (response) — HTTP odpoveď, zaslaná od cieľa k agentovi.
HTTP kód odpovede (HTTP responses status) — štandardný kód odpovede zo servera aplikácií.
Transakcia (transaction) — kompletný cyklus «žiadosť — odpoveď». Transakcia sa považuje od začiatku zaslania žiadosti (request) po dokončenie prijatia odpovede (response).
Stav transakcie (transactions status) — či sa podarilo úspešne dokončiť cyklus «žiadosť – odpoveď». Ak v tomto cykle nastala akákoľvek chyba, celá transakcia sa považuje za neúspešnú.
Čas odozvy (latency) — čas od skončenia zaslania žiadosti (request) do začiatku prijatia odpovede (response).
Metricy zaťaženia (metrics) — charakteristiky zaťažovaného služby a zaťažovacieho agenta definované v priebehu zaťažovacieho testovania.
Hlavné metriky na meranie parametrov zaťaženia
Niektoré z najbežnejších a odporúčaných v metodológii (str. 36, 52) metriky sú uvedené v tabuľke nižšie. Podobné metriky pre agenta a cieľ sú uvedené v jednom riadku.
Metriky pre zaťažovacího agenta
Metriky cieľového systému alebo aplikácie testovanej pod zaťažením
Počet vCPU a pamäte RAM,
Disk — „hardvérové“ charakteristiky zaťažovacieho agenta
CPU, Pamäť, využitie disku — dynamika zaťaženia procesora, pamäte a disku
počas testovania. Zvyčajne sa meria v percentách z
maximálne dostupných hodnôt
Priepustnosť siete (Network throughput) (na zaťažovacom agente) — priepustnosť
sieťového rozhrania na serveri,
kde je nainštalovaný zaťažovací agent.
Zvyčajne sa meria v bajtoch za sekundu (bps)
Priepustnosť siete (Network throughput)(na cieli) — priepustnosť sieťového rozhrania
na cieľovom serveri. Zvyčajne sa meria v bajtoch za sekundu (bps)
Virtuálni používatelia (Virtual users)— počet virtuálnych používateľov,
implementujúcich scenáre zaťaženia a
napodobňujúcich skutočné akcie používateľov
Stav virtuálnych používateľov (Virtual users status), Úspešné/Nepodarilo sa/Spolu — počet úspešných a
neúspešných stavov činnosti virtuálnych používateľov
pre scenáre zaťaženia a ich celkový počet.
Zvyčajne sa očakáva, že všetci používatelia dokázali splniť
všetky svoje úlohy, uvedené v profile zaťaženia.
Akákoľvek chyba znamená, že ani skutočný používateľ nebude schopný
splniť svoju úlohu pri práci so systémom
Žiadosti za sekundu (Requests per second) (minútu)— počet sieťových žiadostí za sekundu (alebo minútu).
Dôležitá charakteristika zaťažovacieho agenta: koľko môže generovať žiadostí.
Toto je v podstate simulácia interakcie s aplikáciou virtuálnymi používateľmi
Odpovede za sekundu (minútu)
— počet sieťových odpovedí za sekundu (alebo minútu).
Dôležitá charakteristika cieľovej služby: koľko sa podarilo
vygenerovať a odoslať odpovedí na požiadavky zo
zaťažovacieho agenta
HTTP stav odpovedí— počet rôznych kódov odpovede
od servera aplikácie, získaných zaťažovacím agentom.
Napríklad 200 OK znamená úspešné volanie,
a 404 — že zdroj nebol nájdený
Latency (čas odozvy) — čas od skončenia
odoslania požiadavky (request) do začiatku prijímania odpovede (response).
Zvyčajne sa meria v milisekundách (ms)
Čas odozvy transakcie— čas jednej kompletnej transakcie,
ukončenie cyklu „požiadavka — odpoveď“.
Tento čas je od začiatku odosielania požiadavky (request)
do dokončenia prijímania odpovede (response).
Čas transakcie môže byť meraný v sekundách (alebo minútach)
niekoľkými spôsobmi: počíta sa minimálne,
maximálne, priemerné a napríklad 90. percentil.
Minimálne a maximálne hodnoty sú extrémne
stavy výkonnosti systému.
Deväťdesiaty percentil sa používa najčastejšie,
pretože ukazuje väčšinu používateľov,
ktorí pohodlne pracujú na hranici výkonnosti systému
Transakcie za sekundu (minútu) — počet kompletných
transakcií za sekundu (minútu),
to znamená, koľko požiadaviek aplikácia dokázala prijať a
spracovať a vydať odpovedí.
Toto je v podstate priepustnosť systému
Stav transakcií , Prešlo / Zlyhalo / Celkom — počet
úspešných, neúspešných a celkový počet transakcií.
Pre skutočných používateľov neúspešná
transakcia bude v podstate znamenať
neprístupnosť systému pod zaťažením
Zásadná schéma zaťažovacieho testovania
Zásadná schéma zaťažovacieho testovania je veľmi jednoduchá a pozostáva z troch hlavných fáz, o ktorých som už spomínal: Pripravte — Testujte — Zpráva, teda príprava cieľov testovania a nastavenie parametrov pre zdroje zaťaženia, potom vykonanie zaťažovacích testov a nakoniec vyhotovenie a publikovanie správy o testovaní.
Poznámky k schéme:
- QA.Tester — expert na zaťažovacie testovanie,
- Cieľ — cieľová aplikácia, pre ktorú je potrebné zistiť, ako sa správa pod zaťažením.
Klasifikátor entít, fáz a krokov na schéme
Fázy a kroky
Čo sa deje
Čo na vstupe
Čo na výstupe
Prepare: fáza prípravy na testovanie
LoadParameters
Úloha a inicializácia
užívateľom
parametrov zaťaženia,
vyberanie metrík a
príprava testovacieho plánu
(profil zaťaženia)
Používateľské parametre pre
inicializáciu zaťažovacieho agenta
Testovací plán
Cieľ testovania
VM
Nasadenie v cloude
virtuálnej mašiny s
žiadanými špecifikáciami
Parametre VM pre zaťažovací agent
Automatizačné skripty na
vytvorenie VM
Nakonfigurovaná VM v
cloude
Env
Nastavenie OS a príprava
prostredia na
prácu zaťažovacieho agenta
Parametre prostredia pre
zaťažovací agent
Automatizačné skripty na
nastavenia prostredia
Pripravené prostredie:
OS, služby a aplikácie,
nevyhnutné na prácu
zaťažovací agent
LoadAgents
Inštalácia, nastavenie a parametizácia
zaťažovacieho agenta.
Alebo stiahnutie docker obrazu s
prednastaveným zdrojom zaťaženia
Docker obraz zdroja zaťaženia
(JMeter, JM alebo vlastný rámec)
Parametre nastavenia
zaťažovací agent
Nakonfigurovaný a pripravený
na prácu zaťažovací agent
Test: fáza vykonania zaťažovacích testov. Zdroje sú zaťažovacie agenti, nasadené v vyhradených pooloch agentov pre GitLab CI
Load
Spustenie zaťažovacieho agenta
s vybraným testovacím plánom
a parametrami zaťaženia
Používateľské parametre
pre inicializáciu
zaťažovací agent
Testovací plán
Cieľ testovania
Logy vykonania
zaťažovacích testov
Systémové denníky
Dynamika zmien metrík cieľa a zaťažovacieho agenta
RunAgents
Vykonanie agentom
zaťaženia testových scenárov
v súlade s
profilom zaťaženia
Interakcia zaťažovacieho agenta
s cieľom testovania
Testovací plán
Cieľ testovania
Záznamy
Zber "surových" logov
počas zaťažovacích testov:
zápisy o činnostiach zaťažovacieho agenta,
stave cieľa testovania
a VM, na ktorej je agent spustený
Logy vykonania
zaťažovacích testov
Systémové denníky
Metrics
Zber "surových" metrík v priebehu testovania
Dynamika zmien metrík cieľa
a zaťažovacieho agenta
Report: fáza prípravy správy o testovaní
Generator
Spracovanie zozbieraných
zaťažovacou sústavou a
sústavou monitorovania "surových"
metrík a logov
Vytvorenie správy v
čitateľnej podobe,
možno s prvkami
analýzy
Logy vykonania
zaťažovacích testov
Systémové denníky
Dynamika zmien metrík
cieľa a zaťažovacieho agenta
Spracované "surové" logy
v formáte vhodnom na
export do externých úložísk
Statická správa o zaťažení,
vhodná na analýzu človekom
Publish
Publikovanie správy
o zaťažení
testovanie vo vonkajšom
servise
Spracované „surové“
logy vo formáte vhodnom
na export do externých
úložísk
Uložené vo vonkajšom
úložisku správy o
zaťažení, vhodné
na analýzu človekom
Pripojenie zdrojov zaťaženia v CI šablóne
Prejdime k praktickej časti. Chcem ukázať, ako sme na niektorých projektoch v spoločnosti realizovali koncept zaťažovacieho testovania ako služby.
Na začiatku našim DevOps inžinierom sa podarilo v GitLab CI vytvoriť vyhradený pool agentov na spustenie testov zaťaženia. Aby sme ich nepoplietli s inými, napríklad kompilacnými, poolmi, pridali sme na tieto agenti tagy, : load. Môžete použiť akékoľvek iné zrozumiteľné tagy. Tieto sa nastavujú GitLab CI Runners.
Ako zistiť požadovanú silu hardvéru? Špecifikácie zaťažovacích agentov — dostatočný počet vCPU, RAM a Disk — môžu byť vypočítané na základe toho, že na agente musia bežať Docker, Python (pre Yandex.Tank), agent GitLab CI, Java (pre Apache JMeter). Pre Java pod JMeter sa odporúča používať minimálne 512 MB RAM a ako horný limit .
Týmto spôsobom, na základe našich skúseností, odporúčame používať pre zaťažovacie agenty aspoň: 4 vCPU, 4 GB RAM, 60 GB SSD. Šírka pásma sieťovej karty sa určuje na základe požiadaviek profilu zaťaženia.
V podstate používame dva zdroje zaťaženia — dockerové obrazy Apache JMeter a Yandex.Tank.
— je open-source nástroj spoločnosti Yandex na vykonávanie zaťažovacích testov. Na jeho modulárnej architektúre je založený vysoko výkonný asynchrónny hit-based generátor HTTP požiadaviek Phantom. Tank má zabudovaný monitoring zdrojov testovaného servera prostredníctvom protokolu SSH, dokáže automaticky zastaviť test na základe zadaných podmienok, vie zobrazovať výsledky ako v konzole, tak aj vo forme grafov, k nemu môžeme pripojiť vlastné moduly na rozšírenie funkčnosti. Mimochodom, Tank sme použili, keď to ešte nebolo mainstreamom. V článku „“ si môžete prečítať príbeh, ako sme v roku 2013 pomocou neho vykonali zaťažovacie testovanie — jedného z produktov našej spoločnosti.
— je open-source nástroj pre vykonávanie záťažového testovania od spoločnosti Apache. Môže sa rovnako dobre používať 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 a pod.), SOAP / REST webové služby, FTP, TCP, LDAP, SMTP(S), POP3(S) a IMAP(S), databázy cez JDBC, dokáže vykonávať shell príkazy a pracovať s Java objektmi. JMeter má IDE na vytváranie, ladenie a vykonávanie testovacích plánov. Existuje aj CLI na prácu v príkazovom riadku akéhokoľvek kompatibilného s Java OS (Linux, Windows, Mac OS X). Nástroj dokáže dynamicky generovať HTML správu o testovaní.
Pre pohodlné používanie v našej spoločnosti, s možnosťou, aby si testeri sami mohli upravovať a pridávať prostredie, sme vytvorili zostavy Docker obrazov zdrojov zaťaženia na GitLab CI s publikovaním do interného . Tak sa rýchlejšie a jednoduchšie integrujú do pipeline na záťažové testy. Ako vykonať docker push do registry cez GitLab CI — pozrite sa v .
Základný Docker súbor pre Yandex.Tank sme vzali tento:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]A pre Apache JMeter tento:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Ako je organizovaný náš systém continuous integration, si môžete prečítať v článku „».
Šablóna a pipeline
Príklad šablóny na vykonávanie záťažových testov je dostupný v projekte . V si môžete prečítať inštrukcie na používanie šablóny. V šablóne (súbor ) sú poznámky o tom, za čo zodpovedá ten alebo onen krok.
Šablóna je veľmi jednoduchá a demonštruje tri fázy záťažového testovania, ktoré sú popísané vyššie na schéme: príprava, testovanie a publikovanie správ. Za to zodpovedajú : Prepare, Test a Report.
- Fáza by sa mala používať na predbežné nastavenie cieľov testovania alebo overenie ich dostupnosti. Prostredie pre zdroje zaťaženia nie je potrebné nastavovať, sú vopred zostavené ako Docker obrazy a nahrané do docker registry: stačí uviesť požadovanú verziu v etape Test. Ale je možné ich znovu zostaviť a vytvoriť svoje upravené obrazy.
- Fáza sa používa na určenie zdroja záťaže, spúšťanie testov a uchovávanie artefaktov testovania. Je možné zvoliť akýkoľvek zdroj záťaže: Yandex.Tank, Apache JMeter, vlastný alebo všetky naraz. Na vypnutie nepotrebných zdrojov je potrebné jednoducho zakomentovať alebo odstrániť job. Vstupné body pre zdroje záťaže:
- parametre spúšťania Yandex.Tank sú uvedené v súbore.,
- parametre spúšťania Apache JMeter sú uvedené v súbore .
Poznámka: šablóna konfiguračného súboru sa používa na nastavenie interakcie s CI systémom a nepredpokladá, že bude obsahovať logiku testov. Pre testy je uvedený vstupný bod, kde sa nachádza spravujúci bash skript. Spôsob spúšťania testov, generovanie správ a samotné testovacie scenáre musia byť realizované QA inžiniermi. V demonštračnom príklade pre oba zdroje záťaže sa ako najjednoduchší test používa požiadavka na hlavnú stránkuYandexu. Scenáre a parametre testov sa nachádzajú v adresári .
- Na etape je potrebné opísať spôsoby publikovania výsledkov testovania získaných v etape Test do externých úložísk, napríklad do GitLab Pages alebo špeciálnych reportovacích systémov. Pre GitLab Pages je potrebné, aby po skončení testov bol adresár .\/public nepustý a obsahoval minimálne súbor index.html. O nuansách fungovania služby GitLab Pages si môžete prečítať .
Príklady, ako exportovať údaje:
- z JMeter do ,
- z Yandex.Tank do .
Inštrukcie na nastavenie publikácie:
- HTML statiky do ,
- do InfluxDB a potom do .
V demonštračnom príklade je pipeline s záťažovými testami a dvoma zdrojmi záťaže (môžete vypnúť nepotrebný) takto:
Apache JMeter dokáže sám generovať HTML report, preto je výhodnejšie ho ukladať do GitLab Pages štandardnými prostriedkami. Takto vyzerá report Apache JMeter:
V demonštračnom príklade pre Yandex.Tank uvidíte iba v sekcii pre GitLab Pages. Počas testovania Tank dokáže ukladať výsledky do databázy InfluxDB, a odtiaľ ich môžete zobraziť napríklad v Grafane (nastavenie sa vykonáva v súbore ). Takto report Tanku vyzerá v Grafane:
Zhrnutie
V článku som hovoril o koncepcii „testovanie záťaže ako služba“ (load testing as a service). Hlavná myšlienka spočíva v používaní infraštruktúry predkonfigurovaných poolov záťažových agentov, Docker obrazov zdrojov záťaže, systémov reportovania a ich zjednocujúceho pipeline v GitLab CI na základe jednoduchého šablónového súboru .gitlab-ci.yml (príklad ). To všetko je podporované malým tímom automatizačných inžinierov a je opakovane používané na požiadanie produktových tímov. Dúfam, že vám to pomôže pri príprave a realizácii podobného schémy vo vašej spoločnosti. Ďakujem za pozornosť!
P. S. Chcem sa poďakovať svojim kolegom, Sergejovi Kurbanovovi a Nikolajovi Jusevovi, za technickú pomoc s realizáciou koncepcie load testing as a service v našej spoločnosti.
Autor: — zástupca vedúceho oddelenia technológií a procesov vývoja (DevOps) v spoločnosti Positive Technologies
Zdroj: habr.com
