Jedním z problémů, s nimiž se dodavatelé softwaru pro více produktů často potýkají, je zdvojení kompetencí inženýrů – vývojářů, testerů a správců infrastruktury – téměř v každém týmu. To platí i pro drahé inženýry – specialisty v oblasti zátěžových zkoušek.
Místo toho, aby plnili své přímé povinnosti a využívali své jedinečné zkušenosti k sestavení procesu zátěžového testování, výběru metodologie, optimálních metrik a psaní autotestů v souladu s profily zátěže, musí inženýři často nasadit testovací infrastrukturu od začátku, nakonfigurovat nástroje zátěže a vložit je. sami v systémech CI, nastavit sledování a zveřejňování zpráv.
Řešení některých organizačních problémů můžete najít v testování, které používáme v Positive Technologies v . A v tomto budu mluvit o možnosti integrace zátěžových testů do společného CI potrubí pomocí konceptu „testování zátěže jako služby“ (testování zátěže jako služba). Dozvíte se, jak a které dockerové obrazy zdrojů zatížení lze použít v kanálu CI; jak připojit zdroje zatížení k projektu CI pomocí šablony sestavení; jak vypadá ukázkový kanál pro spuštění zátěžových testů a publikování výsledků. Článek může být užitečný pro inženýry testování softwaru a automatizační inženýry v CI, kteří přemýšlejí o architektuře svého zátěžového systému.
Podstata konceptu
Koncept zátěžového testování jako služby implikuje schopnost integrovat zátěžové nástroje Apache JMeter, Yandex.Tank a vaše vlastní frameworky do libovolného kontinuálního integračního systému. Demo bude pro GitLab CI, ale principy jsou společné pro všechny CI systémy.
Zátěžové testování jako služba je centralizovaná služba pro zátěžové testování. Zátěžové testy probíhají ve vyhrazených fondech agentů, výsledky jsou automaticky publikovány v GitLab Pages, Influx DB a Grafana nebo v testovacích reportovacích systémech (TestRail, ReportPortal atd.). Automatizace a škálování jsou implementovány maximálně jednoduše – přidáním a parametrizací obvyklé šablony gitlab-ci.yml v projektu GitLab CI.
Výhodou tohoto přístupu je, že celou infrastrukturu CI, agenty zatížení, obrazy dockerů zdrojů zatížení, testovací kanály a publikační zprávy spravuje centralizované oddělení automatizace (inženýři DevOps), zatímco inženýři zátěžového testování mohou soustředit své úsilí na vývoj testů. a analýzu jejich výsledků, aniž by se zabývaly problémy infrastruktury.
Pro jednoduchost popisu budeme předpokládat, že testovaná cílová aplikace nebo server je již předem nasazen a nakonfigurován (k tomu lze použít automatizované skripty v Pythonu, SaltStack, Ansible atd.). Pak celý koncept zátěžového testování jako služby zapadá do tří fází: příprava, testování, zveřejňování zpráv. Další podrobnosti o schématu (na všechny obrázky lze kliknout):
Základní pojmy a definice v zátěžovém testování
Při provádění zátěžových zkoušek se snažíme dodržet , použijte vhodnou terminologii a doporučené metriky. Uvedu krátký seznam hlavních pojmů a definic v zátěžovém testování.
Zátěžový agent - virtuální stroj, na kterém bude aplikace spuštěna - zdroj zatížení (Apache JMeter, Yandex.Tank nebo samostatně psaný zaváděcí modul).
Testovací cíl (cíl) - server nebo aplikace nainstalovaná na serveru, který bude zatěžován.
Testovací scénář (testovací případ) - soubor parametrizovaných kroků: akce uživatele a očekávané reakce na tyto akce s pevnými požadavky a odpověďmi sítě v závislosti na zadaných parametrech.
Profil nebo plán zatížení (profil) - v (Oddíl 4.2.4, str. 43) profily zatížení definují metriky, které jsou kritické pro konkrétní test, a možnosti pro změnu parametrů zatížení během testu. Příklady profilů můžete vidět na obrázku.
Test — skript s předem určenou sadou parametrů.
Testovací plán (test-plan) - soubor testů a zátěžový profil.
Testran (testrun) - jedna iterace spuštění jednoho testu s plně provedeným scénářem zatížení a přijatou zprávou.
Síťový požadavek (žádost) — Požadavek HTTP odeslaný z agenta cíli.
Síťová odezva (odpověď) — HTTP odpověď odeslaná z cíle agentovi.
Kód odpovědi HTTP (stav odpovědí HTTP) – standardní kód odpovědi z aplikačního serveru.
Transakce je úplný cyklus žádost-odpověď. Transakce se počítá od začátku odeslání požadavku (žádosti) do dokončení přijetí odpovědi (response).
Stav transakce - zda bylo možné úspěšně dokončit cyklus žádost-odpověď. Pokud v tomto cyklu došlo k nějaké chybě, je celá transakce považována za neúspěšnou.
Doba odezvy (latence) - čas od konce odeslání požadavku (requestu) do začátku přijetí odpovědi (response).
Metriky zatížení — charakteristiky naloženého provozu a zatěžovacího činitele určeného v procesu zátěžového testování.
Základní metriky pro měření parametrů zatížení
Některé z nejčastěji používaných a doporučených v metodice (str. 36, 52) jsou metriky uvedeny v tabulce níže. Podobné metriky pro agenta a cíl jsou uvedeny na stejném řádku.
Metriky pro agenta zatížení
Metriky cílového systému nebo aplikace testované při zatížení
Číslo vCPU a paměť RAM,
Disk - "železné" vlastnosti nakládacího prostředku
procesor, Paměť, využití disku - dynamika zatížení CPU, paměti a disku
v procesu testování. Obvykle se měří v procentech
maximální dostupné hodnoty
Propustnost sítě (on load agent) - propustnost
síťové rozhraní na serveru,
kde je nainstalován load agent.
Obvykle se měří v bajtech za sekundu (bps)
Propustnost sítě(on target) - šířka pásma síťového rozhraní
na cílovém serveru. Obvykle se měří v bajtech za sekundu (bps)
Virtuální uživatelé- počet virtuálních uživatelů,
implementace scénářů zatížení a
napodobování akcí skutečných uživatelů
Stav virtuálních uživatelů, Úspěšně/Neúspěšně/Celkem — počet úspěšných a
neúspěšné stavy virtuálních uživatelů
pro scénáře zatížení a také jejich celkový počet.
Obecně se očekává, že všichni uživatelé byli schopni dokončit
všechny vaše úkoly uvedené v profilu zatížení.
Jakákoli chyba bude znamenat, že skutečný uživatel nebude schopen
vyřešit váš problém při práci se systémem
Požadavky za sekundu (minutu)- počet síťových požadavků za sekundu (nebo minutu).
Důležitou charakteristikou agenta zatížení je, kolik požadavků může generovat.
Ve skutečnosti se jedná o napodobení přístupu virtuálních uživatelů k aplikaci
Odezvy za sekundu (minutu)
- počet síťových odpovědí za sekundu (nebo minutu).
Důležitá charakteristika cílové služby: kolik
generovat a odesílat odpovědi na dotazy pomocí
nakládací agent
Stav odpovědi HTTP— počet různých kódů odezvy
z aplikačního serveru přijatého agentem zatížení.
Například 200 OK znamená úspěšný hovor,
a 404 - že zdroj nebyl nalezen
Latence (doba odezvy) - čas od konce
odeslání požadavku (request) před zahájením příjmu odpovědi (response).
Obvykle se měří v milisekundách (ms)
Doba odezvy transakce— čas jedné úplné transakce,
dokončení cyklu žádost-odpověď.
Toto je čas od začátku odeslání požadavku (žádosti)
až do dokončení obdržení odpovědi (odpovědi).
Čas transakce lze měřit v sekundách (nebo minutách)
několika způsoby: zvažte minimum,
maximum, průměr a například 90. percentil.
Minimální a maximální hodnoty jsou extrémní
stav výkonu systému.
Nejčastěji se používá devadesátý percentil,
jak ukazuje většina uživatelů,
pohodlný provoz na prahu výkonu systému
Transakce za sekundu (minutu) - počet dokončených
transakce za sekundu (minutu),
tedy kolik byla aplikace schopna přijmout a
zpracovávat požadavky a vydávat odpovědi.
Ve skutečnosti jde o propustnost systému
Stav transakce , Prospěl / Neprošel / Celkem - počet
úspěšné, neúspěšné a celkový počet transakcí.
Pro skutečné uživatele neúspěšné
transakce bude ve skutečnosti znamenat
neschopnost pracovat se systémem pod zátěží
Schéma zátěžového testování
Koncept zátěžového testování je velmi jednoduchý a skládá se ze tří hlavních fází, které jsem již zmínil: Připravte zprávu o testu, tedy příprava testovacích cílů a nastavení parametrů pro zdroje zátěže, následné provedení zátěžových testů a na závěr vygenerování a zveřejnění testovací zprávy.
Schematické poznámky:
- QA.Tester je odborníkem na zátěžové testování,
- Cíl je cílová aplikace, u které chcete znát její chování při zatížení.
Klasifikátor entit, fází a kroků v diagramu
Etapy a kroky
Co se děje
Co je u vchodu
Jaký je výstup
Příprava: přípravná fáze pro testování
LoadParameters
Nastavení a inicializace
uživatel
parametry zatížení,
výběr metrik a
příprava zkušebního plánu
(načíst profil)
Vlastní možnosti pro
inicializace load agenta
Testovací plán
Účel testování
VM
Cloudové nasazení
virtuální stroj s
požadované vlastnosti
Nastavení virtuálního počítače pro agenta zatížení
Automatizační skripty pro
vytvoření VM
VM nakonfigurovaný v
mrak
Env
Nastavení a příprava OS
prostředí pro
práce agenta zátěže
Nastavení prostředí pro
zátěžový agent
Automatizační skripty pro
nastavení prostředí
Připravené prostředí:
OS, služby a aplikace,
nutné pro práci
zátěžový agent
LoadAgents
Instalace, konfigurace a parametrizace
nakládací agent.
Nebo si stáhněte obrázek dockeru z
předkonfigurovaný zdroj zatížení
Načíst zdrojový obrázek dockeru
(YAT, JM nebo samostatně napsaný rámec)
Nastavení
zátěžový agent
Nastaveno a připraveno
na pracovní zátěž agenta
Test: fáze provádění zátěžových zkoušek. Zdroje jsou agenti zatížení nasazení ve vyhrazených fondech agentů pro GitLab CI
Zatížení
Spuštění Load Agenta
s vybraným testovacím plánem
a parametry zatížení
Možnosti uživatele
pro inicializaci
zátěžový agent
Testovací plán
Účel testování
Protokoly provedení
zátěžové zkoušky
Systémové protokoly
Dynamika změn metrik cílů a agenta zatížení
Spustit agenty
Poprava agenta
spousta testovacích skriptů
v souladu s
nosný profil
Načíst interakci agenta
za účelem testování
Testovací plán
Účel testování
Záznamy
Sbírka "surových" protokolů
při zátěžové zkoušce:
záznamy o činnosti agenta zatížení,
stav testovacího cíle
a virtuální počítač, na kterém běží agent
Protokoly provedení
zátěžové zkoušky
Systémové protokoly
Metrics
Shromažďování „surových“ metrik během testování
Dynamika změn metrik cílů
a zátěžový agent
Zpráva: fáze přípravy zprávy o zkoušce
Generátor
Zpracování shromážděno
nakládací systém a
monitorovací systém "raw"
metriky a protokoly
Vytvoření zprávy v
člověkem čitelná forma
možné s prvky
analytici
Protokoly provedení
zátěžové zkoušky
Systémové protokoly
Dynamika změn metrik
cíl a agent zatížení
Zpracované "surové" protokoly
ve formátu vhodném pro
nahrává na externí úložiště
zpráva o statické zátěži,
člověkem čitelné
Publikovat
Zveřejnění zprávy
o zátěži
testování v externím
služby
Zpracované "syrové"
protokoly ve vhodném formátu
pro vyložení na externí
úložišť
Uloženo v externím
ukládání zpráv o
zatížení, vhodné
pro analýzu lidí
Připojení zdrojů zátěže v šabloně CI
Přejděme k praktické části. Chci ukázat jak na některých projektech ve firmě implementovali jsme koncept zátěžového testování jako službu.
Nejprve jsme s pomocí našich inženýrů DevOps vytvořili vyhrazený fond agentů v GitLab CI pro spouštění zátěžových testů. Aby nedošlo k jejich záměně v šablonách s jinými, jako jsou sestavovací fondy, přidali jsme k těmto agentům tagy, : zatížení. Můžete použít jakékoli jiné srozumitelné značky. Oni se ptají GitLab CI Runners.
Jak zjistit požadovaný výkon podle hardwaru? Charakteristiku agentů zatížení – dostatečný počet vCPU, RAM a disku – lze vypočítat na základě skutečnosti, že na agentovi by měl běžet Docker, Python (pro Yandex.Tank), GitLab CI agent, Java (pro Apache JMeter). . Pro Javu pod JMeter se také doporučuje použít minimálně 512 MB RAM a jako horní limit .
Na základě našich zkušeností tedy doporučujeme použít minimálně 4 vCPU, 4 GB RAM, 60 GB SSD pro zátěžové agenty. Propustnost síťové karty je určena na základě požadavků zátěžového profilu.
Používáme především dva zdroje načítání – Apache JMeter a obrázky dockerů Yandex.Tank.
je open source nástroj od Yandexu pro zátěžové testování. Jeho modulární architektura je založena na vysoce výkonném asynchronním generátoru požadavků HTTP založených na asynchronních hitech od společnosti Phantom. Tank má vestavěný monitoring zdrojů testovaného serveru přes protokol SSH, dokáže automaticky zastavit test za zadaných podmínek, umí zobrazit výsledky jak v konzoli, tak ve formě grafů, můžete připojit své moduly pro rozšíření funkčnosti. Mimochodem, Tank jsme používali, když ještě nebyl mainstream. V článku "» si můžete přečíst příběh, jak jsme s ním v roce 2013 prováděli zátěžové testy je jedním z produktů naší společnosti.
je open source nástroj pro testování zátěže od Apache. Lze jej stejně dobře použít pro testování statických i dynamických webových aplikací. JMeter podporuje velké množství protokolů a způsobů interakce s aplikacemi: HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET atd.), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3( S) ) a IMAP(S), databáze přes JDBC, mohou spouštět příkazy shellu a pracovat s objekty Java. JMeter má IDE pro vytváření, ladění a provádění testovacích plánů. K dispozici je také CLI pro ovládání příkazového řádku na jakémkoli operačním systému kompatibilním s Java (Linux, Windows, Mac OS X). Nástroj dokáže dynamicky generovat HTML testovací zprávu.
Pro snadné použití v naší společnosti, pro schopnost samotných testerů měnit a přidávat prostředí jsme vytvořili sestavení dockerových obrazů zdrojů zatížení na GitLab CI s publikací do interní . To umožňuje jejich rychlejší a snadnější připojení do potrubí pro zátěžové testy. Jak udělat docker push do registru přes GitLab CI - viz .
Vzali jsme tento základní soubor dockeru pro Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]A pro Apache JMeter toto:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]Jak náš systém průběžné integrace funguje si můžete přečíst v článku "".
Šablona a potrubí
Příklad šablony pro provádění zátěžových zkoušek je k dispozici v projektu . V Můžete si přečíst pokyny k použití šablony. V samotné šabloně (soubor ) jsou tam poznámky o tom, za co je každý krok zodpovědný.
Šablona je velmi jednoduchá a ukazuje tři fáze zátěžového testování popsané v diagramu výše: příprava, testování a publikování zpráv. Zodpovědný za to : Připravte, otestujte a podejte zprávu.
- Stage by měly být použity k předkonfiguraci testovacích cílů nebo ke kontrole jejich dostupnosti. Prostředí pro zdroje zatížení není třeba konfigurovat, jsou předem vytvořeny jako obrazy dockerů a umístěny v registru dockerů: stačí zadat požadovanou verzi ve fázi Test. Můžete je ale přestavět a vytvořit si vlastní upravené obrázky.
- Stage slouží k určení zdroje zavádění, spouštění testů a ukládání artefaktů testu. Můžete si vybrat jakýkoli zdroj zatížení: Yandex.Tank, Apache JMeter, svůj vlastní nebo všechny dohromady. Chcete-li zakázat nepotřebné zdroje, stačí přidat komentář nebo úlohu smazat. Vstupní body pro zdroje zatížení:
- Spouštěcí parametry pro Yandex.Tank jsou uvedeny v souboru .,
- Spouštěcí parametry Apache JMeter jsou uvedeny v souboru .
Poznámka: Šablona konfigurace sestavy se používá k nastavení interakce se systémem CI a neznamená umístění testovací logiky do ní. U testů je určen vstupní bod, kde se nachází řídicí bash skript. Metodu spouštění testů, generování zpráv a samotné testovací skripty musí implementovat inženýři QA. V ukázce se pro oba zdroje načítání používá požadavek na hlavní stránku Yandex jako nejjednodušší test. Skripty a parametry testu jsou v adresáři .
- Na jevišti musíte popsat, jak publikovat výsledky testů získané ve fázi Test na externí úložiště, například na stránky GitLab nebo speciální systémy podávání zpráv. Stránky GitLab vyžadují, aby adresář ./public nebyl prázdný a po dokončení testů obsahoval alespoň soubor index.html. Můžete si přečíst o nuancích služby GitLab Pages. .
Příklady jak exportovat data:
- z JMeter do ,
- z Yandex.Tank do .
Pokyny k nastavení příspěvku:
- HTML statika v ,
- do InfluxDB a poté do .
V ukázkovém příkladu vypadá potrubí se zátěžovými testy a dvěma zdroji zatížení (zbytečný můžete zakázat) takto:
Apache JMeter umí generovat HTML report sám, takže je výhodnější ho uložit na GitLab Pages pomocí standardních nástrojů. Takto vypadá zpráva Apache JMeter:
V ukázkovém příkladu pro Yandex.Tank pouze uvidíte v sekci pro stránky GitLab. Během testování může Tank uložit výsledky do databáze InfluxDB a odtud je lze zobrazit např. v Grafaně (konfigurace se provádí v souboru ). Takto vypadá Tankova zpráva v Grafaně:
Shrnutí
V článku jsem mluvil o konceptu „testování zátěže jako služby“ (testování zátěže jako služba). Hlavní myšlenkou je využít infrastrukturu předkonfigurovaných fondů zátěžových agentů, dockerových obrázků zdrojů zátěže, reportovacích systémů a kanálu, který je kombinuje v GitLab CI na základě jednoduché šablony .gitlab-ci.yml (příklad ). To vše je podporováno malým týmem automatizačních inženýrů a replikováno na žádost produktových týmů. Doufám, že vám to pomůže při přípravě a implementaci podobného schématu ve vaší společnosti. Děkuji za pozornost!
PS Chci moc poděkovat svým kolegům Sergeji Kurbanovovi a Nikolai Yusevovi za technickou pomoc při implementaci konceptu zátěžového testování jako služby v naší společnosti.
Autor: - Náměstek Vedoucí technologických a vývojových procesů (DevOps) ve společnosti Positive Technologies
Zdroj: www.habr.com