Existuje několik oblastí, kde se testování aplikací – doména vývojových týmů – prolíná s provozem IT prostředí – tedy doménou IT profesionálů.
Poté, co jsem napsal titulek k tomuto článku, vzpomněl jsem si na svá vysokoškolská studia. Našeho profesora matematiky rozčilovalo, že se jeho předmět jmenuje „Matematika pro chemiky“ – vždyť přece existuje pouze jedna jediná matematika.
Stejně tak testování aplikací je pouze jediná disciplína, ale s řadou aspektů, z nichž mnohé jsou pro IT profesionály víceméně nezajímavé a mnohé další jsou pak absolutně nezajímavé. Existují ale i pár oblastí, kde se testování aplikací – doména vývojových týmů – prolíná s provozem IT prostředí – tedy doménou IT profesionálů. Pro tento mini-seriál jsem si vybral dvě.
První oblastí našeho zájmu bude výkonnostní testování. Jen málokdo se asi nesetkal s aplikací, která naprosto kolabovala v okamžiku, kdy ji potřeboval použít. Příčin může být řada – např. nedostatečně nadimenzovaný hardware, který nezvládá předvánoční špičku. Ještě pravděpodobnější ovšem je, že aplikace vůbec nikdy nebyla výkonnostně otestována. Při předávání fungovala dobře (v jednouživatelském režimu). Nikdo ale neotestoval, co se stane, pokud se na ni vrhne větší množství uživatelů. Prvoplánová kritika však není na místě. Výkonnostní testování sice není zase tak složité, ale v každém případě je nákladné. Za jistotu, že aplikace se bude za námi stanovených zátěžových podmínek chovat podle nastavených pravidel, musíme zaplatit nemalými náklady na testovací software, věnovaným časem či hardwarem, který si testování vyžaduje. Náklady ale teď ponechme jiným a pojďme se podívat, jak takové výkonnostní testování probíhá. Nejčastěji testovaným typem aplikací jsou aplikace webové, které mívají největší množství uživatelů. Lze však testovat i aplikace jiných typů, uložené procedury v databázi apod. Z technického hlediska se pohyb uživatele po webové aplikaci redukuje na sérii HTTP požadavků uskutečněných prostřednictvím webového prohlížeče. První fází je proto zachycení této interakce. Na obrázku níže vidíte nahrávání této sekvence, které je součástí Visual Studia 2010 Ultimate (rekordér má formu add-inu do Internet Exploreru).
Takto zachycenou sekvenci stačí 100x nebo 1000x namnožit a zátěžový test je hotový. Skoro hotový. Za prvé je potřeba provést variaci parametrů. Např. pro testování nákupů v eshopu není vhodné, aby stále tentýž uživatel nakupoval stále tentýž výrobek – výsledky by nebyly realistické. Naštěstí se jedná o celkem snadnou úlohu. Dále je třeba nastavit realistické podmínky testu jako například:
- Mix různých činností uživatelů (např. 90% si pouze prohlíží produkty a 10% nakupuje)
- Mix různých prohlížečů, což má ovšem smysl pouze pokud web různě reaguje na různé prohlížeče.
- Mix různých síťových připojení – vrstva síťové emulace umožňuje simulovat různé šířky pásma, latenci a dokonce i ztrátovost paketů.
- Počet testovaných uživatelů a průběh zátěže. Například můžete chtít testovat 5 minut s 50 současnými uživateli (tzv. warm-up) a poté přidávat každou minutu 50 uživatelů až do celkového počtu 5000.
- Výkonnostní čítače, které je třeba sledovat. Typicky budete sledovat základní parametry (procesor, paměť, disk a síťové rozhraní) na všech počítačích, které jsou do testu nějakým způsobem zapojeny.
- Ilustrační obrázek nastavení zátěžového testu vidíte níže.
Tím máme definici testu hotovou a zbývá „jenom“ test spustit. Ale pozor. Nesmí dojít k tomu, že úzkým hrdlem celého testu budou počítače zatěžující, nikoliv počítače zatěžované. Pro menší zátěže si lze vystačit s jediným počítačem, který zvládá všechny úlohy při výkonnostním testu. Pro větší zátěže je nutné přejít k distribuované konfiguraci. Zátěž generuje několik tzv. test agentů. Ty jsou řízeny tzv. test controllerem, který sbírá výsledky z agentů a ze všech definovaných výkonnostních čítačů. Tyto výsledky sumarizuje a ukládá do databáze, kde jsou k dispozici pro pozdější analýzu.
Příklad této analýzy vidíte na obrázku níže:
Existuje celá řada pohledů na naměřená data. Nejužitečnější pro prvotní analýzu je zobrazit si závislost doby odezvy na požadavky uživatelů, počtu chybných požadavků, počtu zobrazených stránek a počtu současně přistupujících uživatelů v závislosti na čase. Na obrázku výše například vidíte, že při stále rostoucím počtu uživatelů (červená křivka vlevo) dochází v čase kolem 7:30 minut ke stagnaci počtu zobrazených stránek (zelená křivka vlevo) a k prudkému nárůstu doby pro zobrazení stránky (modrá křivka vlevo). Zároveň vidíte, že přibližně ve stejné době začíná být přetížen procesor testovaného systému (červená křivka vpravo). Naše aplikace v dané hardwarové konfiguraci tedy zvládne obsloužit cca 1500 současných uživatelů. Kromě vyhodnocení jednoho individuálního měření může být zajímavé též srovnání dvou nebo více měření prováděných za různých podmínek. Je možné například srovnávat výkonnostní charakteristiky více verzí aplikace, výkonnost aplikace na dvou různých hardwarových konfiguracích, s různými nastaveními prostředí apod. K tomuto účelu je připravena nadstavba do Excelu, která načte a porovná dva nebo více výsledků měření z databáze v řadě podrobných grafů (viz obrázek)
A jsme u konce. V reálné praxi by celý postup trval určitě déle, než byla doba potřebná na přečtení článku. Nicméně z vlastní zkušenosti mohu potvrdit, že výkonnostní testování je jednou z nejzajímavějších IT disciplín. Zvídaví si mohou tuto funkci vyzkoušet pomocí časově limitované verze VS 2010 Ultimate, která je volně ke stažení. Pokud byste měli o toto téma hlubší zájem, neváhejte mne kontaktovat na adrese mjurek(zavináč)microsoft.com.
Autor: Michael Juřek, Microsoft s.r.o.
Články ze série Microsoft TechNet nevytváří redakce Živě.cz, ale partneři programu Microsoft TechNet. Jsou publikovány v rámci mediálního partnerství Živě.cz a společnosti Microsoft.
