Zátěžové testování aneb “Kdo to sakra zaplatí” Ján Hrabik

...ale spíš bylo jedno království, kde bylo potřeba udělat zátěžový test...a né ledajaký, ale obrovský.....

Co je „Zátěžové testování“? Cíl zátěžového testování: Co je zátěžové testování :

Zátěžový test jako odpověď na otázky Jaké budou odezvy kritických transakcí? Kolik uživatelů může se systémem pracovat? Jak bude provoz systému zatěžovat webové, aplikační, databázové servery? Jaký je optimální počet serverů pro provoz systému? Jak bude systém reagovat při výpadku některé z komponent? (DB servery, aplikační servery, load balancing) Ve které části systému dochází k degradaci výkonu? Co je příčinou nízké výkonnosti systému? …

Ale to stojí peníze!

Sestavení týmu pro zátěžový test Spolupráce odborníků s různou specializací –Testeři –Business analytici –Vývojáři testované aplikace –Správce prostředí –DB specialista, síťový specialista … Pověření konkrétních osob z jednotlivých týmů –Poskytování informací o testované aplikaci a daném prostředí –Spolupráce na přípravě testu (příprava prostředí, příprava testovacích dat...) –Dohled při spuštění testu (stabilita prostředí, ovlivnění okolních systémů …) –Účast na vyhodnocení testu Zátěžový test je týmová práce!

Kdy provádět zátěžové testy Nasazení nového systému Upgrade stávající verze systému (nová release) Optimalizace výkonnosti systému (ladění) Plánování rozvoje infrastruktury Nasazování nových technologií Akceptační testy

Plánování zátěžového testu Důsledné naplánování všech fází přípravy a realizace testu Vytvoření dokumentu popisujícího organizační, metodické a technické aspekty testu (Analýza ZT) –Harmonogram –Sestavení týmu pro ZT –Definice cíle testu –Volba a popis prostředí pro ZT - testovací prostředí x kopie produkčního prostředí –Výběr vhodného nástroje –Návrh scénáře testu –Specifikace testovacích dat –Specifikace monitorovaných parametrů –Postup při vyhodnocení testu Schválení dokumentu všemi zúčastněnými stranami

Stanovení postupu při vyhodnocení Stanovení limitů výkonnostních parametrů –Odezvy kritických transakcí –Vytížení CPU DB serveru, využití operační paměti … Určení limitních hodnot pro jednotlivé parametry (SLA) –Konkrétní mezní hodnoty (např. odezva nesmí být větší než 5 sekund) –Rozsahy hodnot (nízká, vysoká, kritická) Vyhodnocovaný časový úsek v rámci testu –Celý průběh testu –Konkrétní úsek testu (např. pouze při zatížení 100 VU) Stanovení statistické veličiny pro vyhodnocení –Průměr –Percentil (např. 90% odezev do 5 sekund)

Základní parametry zátěže ● Počet současně pracujících uživatelů –Počet uživatelů, kteří v jeden okamžik aktivně pracují s aplikací ● Simulované činnosti (business transakce) –Konkrétní činnosti, které uživatelé v aplikaci vykonávají –Např. registrace, objednání zboží, vyhledání dokumentu … –Každá činnost je v ZT obvykle reprezentována jedním skriptem ● Uživatelské profily –Rychlost a rytmus práce –Parametry síťového připojení (rychlost, bandwidth, packet loss...) –Typ a nastavení klientské aplikace (např. typ internetového prohlížeče) –Operační systém

Příprava prostředí a zátěžových skriptů Příprava prostředí –Umístění generátorů zátěže (před/za firewall, do internetu, na lokální pracoviště) –Umístění měřících sond (u agentního monitoringu) –Úprava testovacího prostředí, aby odpovídalo produkci Příprava skriptů –Nahrání či naskriptování uživatelské činnosti –Korelace –Parametrizace –Vložení měřených úseků (transakcí) –Přidání dodatečné programové logiky Vytvoření scénáře z kombinace skriptů, počtů uživatelů a časového návrhu testu

Stanovení cílů zátěžového testu Ověření výkonnosti při očekávaném zatížení –Jaké odezvy bude mít aplikace při běžném zatížení? –Jaké bude vytížení aplikačních serverů ve špičce? Ověření výkonnostních limitů systému –Kolik uživatelů systém obslouží před zhoršením výkonnosti? –Kolik požadavků za hodinu je systém schopen vyřídit? Ověření chování systému při výpadku jednotlivých komponent –Jak bude systém reagovat na poruchy webových serverů, aplikačních serverů, DB serverů, load balancingu … Ladění systému –Úprava systému na základě výsledků zátěžového testu –Opakované spouštění testu pro ověření účinku úprav systému

Výběr monitorů a výkonnostní metriky Dle cíle zátěžové testu jsou vybrány vhodné monitory, určeny sledované výkonové ukazatele (metriky) a jsou stanoveny jejich limity. Tyto budou porovnávány s naměřenými výsledky zátěžového testu.

Vyhodnocení testu Vyhodnocení sledovaných parametrů v souvislosti s průběhem zátěže Porovnání naměřených hodnot s předem stanovenými limity a cílem ZT Hledání „úzkých míst“ systému – Podrobná analýza získaných hodnot výkonnostních parametrů – Identifikace vrstvy/komponenty systému, ve které dochází k problému – Navržení změn pro optimalizaci výkonu Navržení dalšího běhu testu s upraveným scénářem pro získání podrobnějších informací

Náklady na automatizované zátěžové testy – Potřeba součinnosti interních specialistů (DB, OS, business, vývoj…), případně dodavatele Pořízení nástroje (licence, support) Pořízení HW pro nástroj Cena kvalitního specialisty na ZT Upgrade testovacího prostředí Náklady na zaškolení interních pracovníků pro práci s nástrojem Údržba skriptů

Náklady na automatizované zátěžové testy

Hledání úspor při automatizovaných zátěžových testech – Opakované výkonnostní testy všech release aplikace - pouze rozdílová analýza, „oprášení“ skriptů Zaškolením interních pracovníků, pro realizaci opakovaných testů Pronájem licencí komerčních nástrojů, využití freeware alternativ Pronájem HW, pronájem cloudu (veřejný, privátní…) Testováním aplikace na budoucím produkčním prostředí

Nedělejte šuplíkové testy Plánujte zátěžové testy včas a v dostatečném rozsahu spolu s ostatními druhy testů Řádně si promyslete cíle zátěžových testů

Mýty v ZT ● ZT je drahý ● Na ZT potřebuji specialisty, kteří jsou drazí ● Proč bych měl platit za ZT, když se to dá udělat zadarmo ● Tady ZT nikdo nepotřebuje, proč bychom ho dělali ● Musíme udělat ZT stůj co stůj, i když na systému nebude žádná zátěž

ZT je drahý a) ZT z principu být drahý nemusí b) ZT vyžaduje přípravu, která se může prodražit c) ZT většinou vyžaduje nástroj, který se může prodražit d) ZT většinou potřebuje specialisty, kteří se mohou prodražit e) ZT potřebuje testovací prostředí, které se také může prodražit

ZT je drahý ● 10% ZT je analýza ● 60% ZT je skriptování ● 10% ZT je příprava prostředí a dat ● 10% ZT je provední ZT ● 10% ZT je vyhodnocení ● Místo, kde markantně ušetřit je skriptování!

Jak konkrétně ušetřit ● Kvalitnější analýza je schopna ušetřit cca 5- 15% procent času skriptování ● Kvalitnější analýza je schopna ušetřit cca 10% na přípravu prostředí a cca 5-50% na přípravu dat ● Kvalitnější analýza může navrhnout pokročilejší re-use skriptů a tím srazit skriptování až o 75% ● Automatizace tvorby výsledků může uspořit až několik MD času

Konkrétní případ ● Test A v rozložení procent( ), v rozložení MD ( ) – 100% - 20MD ● Test B za použití kvalitnější analýzy v procentech( ), MD ( ) – 85% - 17MD ● Test C za použití výborné analýzy s re-usem skriptů v procentech( ), MD ( ) – 70% - 14 MD

ZT nikdo nepotřebuje/ZT musí být ● Dva extrémy projektového imperativu ● Podceňování, případně přeceňování projektových rizik ● Tento mýtus je většinou dobře řešitelný na straně provozu, kteří ví, jaký byl v současnosti provoz stávajícího řešení (za předpokladu, že nové řešení by mělo pouze nahradit, né rozšířit současné řešení) ● Mnohdy chyba špatně zadaných akceptačních kriterií

ZT nikdo nepotřebuje/ZT musí být ● Řešením je striktně dodržovat projektová pravidla ● Požadavky na ZT musí být SMART ● Oddělit požadavky na ZT, která mají dopad na funkčnost od těch, která ne (například obrazovka navíc při čekání delším než 10 vteřin) – a vyžadovat funkcionalitutěchto požadavku před začátkem ZT ● Provádět ZT pouze nad “frozen” prostředím – to dokonce i v případě agile projektů

Pro ZT potřebuji/nepotřebuji odborníky

● Specialisté dokáží ušetřit peníze – čím náročnější ZT, tím více dokáží ušetřit ● Kvalitní analýza ZT dokáže šetřit peníze, AN musí být dostatečně znalý problematiky ● Skriptér by měl být více programátor než tester, ale se znalostí principů ZT ● Projektový manažer se znalostí technik re-use může dát pro ZT tak dobrý základ, že může ušetřit až polovinu nákladů na ZT

Mýtus dne: V agile se ZT nedělají ● Omyl! Dělají ● Mohou být velmi efektivní ● Mohou stát zlomek cen běžných ZT ● Používají re-use ve velkých rozměrech ● Bývají maximálně automatizované včetně reportingu

Shrnutí ● ZT stojí peníze ● ZT se mohou prodražit ● Na ZT se dá ušetřit ● ZT potřebuje přípravu ● ZT fungují lépe s re-usem

Děkuji za pozornost ● Ján Hrabik ● ●