Testování výkonu aplikací je nedílnou součástí vývoje softwarových řešení. Proč tomu tak je a vždy bude? Výkon aplikací je jedním z hlavních kritérií úspěšnosti, a to je docela dobrý důvod, proč musíme věnovat optimalizaci výkonu vysokou pozornost. V tomto článku se zaměříme na možnosti a typy testování webových aplikací pro zjištění a ověření jejich reálných možností.

Tento článek vychází ze článku Web Performance Testing – Test objectives and Real Life Monitoring od Robina  Bortze, kterému tímto děkujeme za velmi dobrý a obsáhlý materiál.

Jak jsme naznačili hned v úvodu, výkon webových aplikací je jedním z nejdůležitějších kritérií úspěšnosti. Pokud je aplikace rychlá, má šanci na úspěch. Pokud je aplikace pomalá, je velmi pravděpodobné, že bude rychle zapomenuta.

V dnešním článku se nebudeme zabývat tím, jak aplikace optimalizovat z hlediska výkonu, ale podíváme se na to, jak můžeme efektivně a smysluplně tyto aplikace testovat, abychom si zjistili a ověřili jejich reálné možnosti použití v praxi.

Co to vlastně znamená testovat webové aplikace z hlediska výkonu?

Aplikace testujeme tak, že simulujeme předpokládané chování uživatelů při používání těchto aplikací. Poté zjišťujeme, jak se aplikace chovají na aplikační úrovni, jaké využívají systémové zdroje a jak moc a jaké jsou odezvy těchto aplikací směrem k uživatelům.

Výsledky jsme schopni vyhodnotit a ověřit si tak, zda-li tyto aplikace splňují očekávané chování nebo je nesplňují. Tímto způsobem jsme schopni odhalit výkonnostní problémy, úzká místa, paměťové úniky, nevhodnost hardware apod.

Kritéria výkonnostního testování

Před zahájením testování si musíme určit cíle, kterých chceme dosáhnout a kritéria, která chceme, aby naše aplikace splňovala.

Mezi základní kritéria výkonnostního testování webových aplikací patří uvedení počtu návštěv, které musí aplikace během dne obsloužit a počet jimi zobrazených stránek, které musí aplikace vygenerovat. Často se také používají kritéria v podobě stanovení minimálního počtu současně přistupujících uživatelů k aplikaci, které musí aplikace umět obsloužit.

Pokročilejší kritéria mohou obsahovat definice počtu obsloužených uživatelů a zobrazených stránek na předem definovaných úzkých místech aplikace (to jsou většinou nejpoužívanější stránky nebo stránky nejnáročnější na výkon) tak, jak jdou v čase. Zátěž stránek nebude stejná v jednu hodinu v noci jako v devatenáct hodin večer. Stejně tak ráno mohou být úzká místa aplikace jiná než večer. I s tímto mohou testovací kritéria počítat.

Základním cílem celého testování může být to, jestli aplikace vyhovuje všem stanoveným kritériím. Často se také používá testování, které odpovídá na otázku, jak moc se změní chování aplikace v závislosti na změně výchozích podmínek. Za změněné podmínky se dá považovat např. nárůst počtu uživatelů, netriviální nárůst zpracovávaných dat apod.

Cílem zátěžového testování může být také pokus o selhání aplikace pro ověření, jakou maximální zátěž aplikace snese za daných podmínek.

Jak můžeme simulovat reálnou zátěž, kterou uživatelé vytvářejí při používání aplikace?

Na generování simulované zátěže můžeme použít několik softwarových nástrojů typu JMeter nebo Selenium. Tyto nástroje poskytují uživateli možnost vyklikat si testovací scénáře kopírující reálné chování uživatelů na webu. Tyto scénáře poté vykonávají a měří délku jednotlivých zpracování. Na základě měření jsou schopny poskytnout statistiky, které identifikují slabá a silná místa a napovídají tak, co je potřeba zoptimalizovat a co nikoli.

První část – tedy stanovení kritérií a cílů máme za sebou a nyní se můžeme pustit do samotného testování.

Robin Bortz ve svém článku jmenuje několik typů testů, které vedou k ověření možností aplikace a odhalení případných problémů. V naší firmě máme zkušenosti především se zátěžovými testy a Stress testy. Jejich využívání se nám rozhodně vyplácí, jak se můžete přesvědčit sami na výkonu aplikace NaCesty.cz, kterou jsme připravili pro jednoho z našich zákazníků.

Jaké typy výkonnostního testování používáme?

Zátěžové testy

Zátěžové testy simulují předpokládané chování uživatelů na základě předem definovaných reálných scénářů použití stránek. Zátěžové testy ověřují, jestli je aplikace schopna obsloužit požadovaný počet návštěvníků a vygenerovat pro ně potřebný počet stránek v závislosti na čase.

Součástí obvyklých zátěžových testů je i dlouhodobý test, který ověřuje, zda-li je aplikace z dlouhodobého hlediska schopna zvládnout očekávanou zátěž.

Výsledkem testování jsou informace o tom, jak se aplikace chová při předpokládaném zatížení, jaké spotřebovává systémové zdroje a jaká je délka zpracování požadavků uživatelů na zobrazení stránek. Na základě výsledků jsme schopni najít úzká místa aplikace či paměťové úniky.

Zátěžové testy jsme schopni realizovat pomocí JMeteru nebo Selenia. Testy spouštíme ideálně ze stroje ve vnitřní síti serveru, na kterém aplikace běží, abychom co nejvíce omezili zpoždění, které vzniká při doručení požadavku na stránku do aplikace a délkou přenosu odpovědi zpět uživateli (aby statistiky nebyly zkreslené vnějšími vlivy).

Stress testy

Stress testy mají za účel ověřit robustnost aplikace. Při Stress testech generujeme na aplikaci zatížení, které postupně zvyšujeme a čekáme, až aplikace spadne. Takto jsme schopni zjistit maximální možnosti aplikace a do budoucna budeme vědět, jak se aplikace bude chovat v případech, kdy její zatížení bude vyšší, než je zatížení předpokládané.

Součástí Stress testů je i testování aplikace na to, jak se chová při špičkách. Nárazově zvyšujeme zatížení aplikace tak, abychom věděli, jak se bude aplikace ve špičkách chovat. Sledujeme dobu odezvy a konzumaci systémových zdrojů, které aplikace využívá.

Stress testy jsou dobré k nalezení mantinelů, v jejichž rámci se výkon aplikace dá považovat za výborný, uspokojivý či nedostatečný. Na základě průběžných statistik návštěvnosti a statistik využívání systémových zdrojů jsme schopni určit, jak dlouho bude výkon aplikace dostačovat, což nám dává prostor pro nalezení optimálnějšího řešení.

Za jakých podmínek jsou zátěžové testy smysluplné a jejich výsledky dávají relevantní odpovědi?

1. Testujeme na základě reálných scénářů použití aplikace uživateli. Pro různé typy uživatelů různé testovací scénáře. Toto je úzké místo celého testování a musíme si dávat pozor na to, abychom tyto scénáře chybně nenastavili, což by mohlo mít fatální následky. Scénáře musí být reálné, musí reálně vystihovat chování uživatelů v aplikaci a reflektovat typ aplikace. Testování nerelevantních scénářů dává pro naše potřeby nerelevantní výsledky.
2. Testujeme v prostředí, které je podobné produkčnímu prostředí. Testujeme na serverech, které jsou velmi podobné nebo stejné serverům pro produkční prostředí se stejnou konfigurací, softwarem a konektivitou.
3. Testování většinou provádíme v laboratorních podmínkách, abychom omezili vnější vlivy, které se mohou dotknout délky doručování požadavků a odpovědí na požadavky v závislosti na vzdálenosti či propustnosti datového spoje. V případě potřeby však musíme na tyto vnější faktory dát patřičný pozor. Pokud připravujeme aplikaci čistě pro americký trh, potom má smysl uvažovat nad jejím fyzickým umístěním právě v USA. V případě stejné konektivity serveru do páteřní sítě budou mít uživatelé obsah o chlup rychleji, než kdyby byla aplikace umístěná na serveru se  stejnou konektivitou v Evropě, což může mít v některých případech opodstatnění.
4. Výkon testujeme, až když to má smysl. Nemá cenu testovat výkon aplikace, které nebyla výkonnostně optimalizovaná. To je zpravidla ztráta času.

Asi se shodneme, že výkonnostní testování má smysl a je nutné pro většinu webových aplikací. Pro některé typy aplikací a firmy, které tyto aplikace provozují, může mít aplikace s výkonnostními problémy fatální následky, ze kterých se nemusí již nikdy vzpamatovat. Lidé neradi čekají, nenechávejte je čekat!