Fáze realizace zátěžového testu je rozdělena do cyklicky opakovaných aktivit, které směřují k postupnému splnění cíle definovaného v analýze pro ZT a jejichž průběh a výsledky jsou následně shrnuty do závěrečné zprávy. V této fázi na zátěžovém testu obvykle spolupracuje větší počet pracovníků různých odborností. Kromě samotných testerů (specialistů ZT) jsou to zejména administrátoři, vývojáři testované aplikace a pracovníci zajišťující podrobný monitoring jednotlivých prvků a vrstev systému. Základním předpokladem pro úspěch testu je jejich vzájemná komunikace a bezvadná synchronizace jimi prováděných činností. Z tohoto důvodu je obvykle jmenován koordinátor ZT, který zajišťuje komunikaci mezi jednotlivými členy týmu a aktivity realizace výkonnostního testu řídí.

Kontrola před spuštěním běhu ZT

Přestože zkušební běh v přípravné fázi proběhl bez problémů, je velice užitečné těsně před zahájením každého běhu ověřit, zda je vše připraveno, jak má být. Při tomto ověření by měla být pozornost soustředěna především na následující oblasti:

• funkčnost testované aplikace a okolních spolupracujících systémů,
• nastavení správného scénáře ZT, funkčnost zátěžových skriptů naplánovaných pro daný běh, testovacích dat a generátorů zátěže,
• správné nastavení monitoringu pro sledování výkonnostních parametrů systému,
• připravenost všech členů týmu na spuštění běhu testu.

Tyto kontroly se mohou na první pohled jevit jako zbytečné. Je ale nutné mít na paměti možné důsledky případných chyb vyplývajících z nedostatečné připravenosti běhu testu. Připojení špatného datového souboru nebo absence některého z měřených parametrů mohou vážně ohrozit vypovídací schopnost testu. Při pozdní identifikaci chyby v průběhu testu znamená opětovné spuštění obvykle několikahodinové zdržení, což vzhledem k počtu zúčastněných pracovníků běh testu poměrně prodraží. Ne vždy je také možné test ihned opakovat. Překážkou může být například nutnost provedení časově náročné obnovy počátečního stavu databází z důvodu vyčerpání potřebných destruktivních dat v datových souborech nebo vypršení času rezervace prostředí. Důslednost je tedy zcela na místě.

Spuštění běhu ZT

Po úspěšné kontrole výchozích podmínek dá koordinátor ZT pokyn k zahájení běhu testu. Specialista ZT aktivuje v příslušném nástroji připravený scénář a spustí generování zátěže. Ve stejný okamžik je spuštěn i monitoring jednotlivých prvků systému.
Po dobu zatížení systému je důležité průběžně ověřovat, zda se test vyvíjí „správným směrem“. Na straně testovacího nástroje se jedná zejména o kontrolu bezchybného běhu zátěžových skriptů, vytížení generátorů zátěže a průběžné vyhodnocení vývoje hodnot základních výkonnostních parametrů. Na straně testovaného systému pak obvykle probíhá sledování vytížení zdrojů na klíčových strojích a sledování zatížení sítě. Pokud testovací prostředí není fyzicky odděleno od produkčního prostředí, je po dobu běhu testu většinou také posílen provozní dohled nad produkčními systémy a vybranými síťovými prvky produkčního prostředí. V případě výskytu většího množství chyb nebo při kritickém přetížení části produkčního prostředí může koordinátor ZT běh testu předčasně ukončit.
Posledním krokem této aktivity je sehrání a uložení všech naměřených dat z běhu ZT do předem zvoleného sdíleného adresáře ihned po ukončení běhu testu. Při pozdějším ukládání by mohlo dojít k záměně těchto dat s daty z jiných běhů, případně k jejich ztrátě, zvláště v případě ručního měření výkonnostních atributů.

Vyhodnocení běhu ZT

Vyhodnocení výsledků jednotlivých běhů bývá obvykle nejnáročnější aktivitou v rámci realizace testu. Je nutné zpracovat a zanalyzovat poměrně velké množství dat z různých zdrojů (testovací nástroj, externí monitorovací nástroje, logovací soubory). Technickou část vyhodnocení může značně usnadnit použití sofistikovaného testovacího nástroje. Interpretace výsledků je však vždy úkolem pro odborníky.

Grafické vyhodnocení monitoringu systémových zdrojů v nástroji HP LoadRunner

Pozornost vedoucích pracovníků je soustředěna především na vyhodnocení uživatelských odezev aplikace a dalších výkonnostních parametrů, pro které byly v analýze ZT definovány limitní hodnoty. Na základě vyhodnocení těchto údajů lze formálně prohlásit, zda testovaná aplikace splňuje či nesplňuje požadavky na výkonnost kladené jejím vlastníkem nebo uživatelem. Hodnoty těchto parametrů mají také obvykle zásadní vliv na další průběh vyhodnocení daného běhu i na průběh zbývajících plánovaných běhů výkonnostního testu.
Při překročení stanovených výkonnostních limitů následuje detailní analýza výsledků běhu a hledání tzv. úzkých míst systému. Je třeba najít logické souvislosti mezi problematickým chováním systému a vývojem hodnot ostatních sledovaných parametrů. Mnohdy se jedná se o bezmála detektivní práci. Nejefektivnější metodou pro odhalení příčin nízké výkonnosti a případných úzkých míst je společné vyhodnocení běhu testu formou workshopu.
Workshop svolává koordinátor ZT a zúčastnit by se ho měli všichni klíčoví pracovníci měřeného systému, tedy zejména architekt systému, vedoucí programátorských týmů, databázoví a síťoví specialisté. Specialista ZT připraví prezentaci klíčových nálezů pro daný běh. Na workshopu je představen průběh zátěže, jsou podrobně vyhodnocena podezřelá data, případně konkrétní nálezy úzkých míst. Podle charakteru nálezu je v diskusi týmem určen postup dalších kroků, včetně časových termínů a pracovníků, kteří budou za jednotlivé kroky zodpovídat. Výstupem workshopu bývá obvykle návrh úprav systému a specifikace dalšího běhu ZT v následujících oblastech:

• výběr vhodného scénáře z analýzy či jeho modifikace,
• specifikace úprav zátěžových skriptů a doplnění měřených transakcí,
• doplnění sledovaných výkonnostních metrik včetně určení způsobu jejich měření a vyhodnocení,
• specifikace úprav hardwarové a softwarové konfigurace měřeného systému (úpravy konfigurace jednotlivých serverů, změna jejich počtu nebo úpravy parametrů sítě),
• specifikace úprav kódu aplikace,
• stanovení času spuštění dalšího běhu ZT a případně nových vstupních podmínek běhu ZT.

V případě návrhu softwarových úprav testované aplikace je nutné počítat s tím, že opravená část aplikace musí být po úpravě funkčně otestována (jde o zásah do zamražené aplikace) a nově nainstalována do testovacího prostředí. Po zásahu do aplikace je vždy nutné ověřit funkčnost zátěžových skriptů, případně dotčené skripty upravit. Často je nezbytné ověřit identifikovaný nález úzkých míst aplikace způsobený například chybnou programovací technikou, případně i navrhovaný postup úpravy softwaru k jejich odstranění. Proto je pro poslední plánovaný běh ZT provedena oprava pouze na jednom místě aplikace a její úspěšnost je ověřovací zátěží pomocí příslušného zátěžového skriptu prověřena. Další úpravy aplikace daného typu je pak možné rozplánovat do následujících „release“ vývoje aplikace dle četnosti využívání příslušných částí aplikace s identifikovanou závadou.
Závěrem workshopu může být i ukončení aktivity realizace ZT – v případě splnění cíle ZT, nebo v případech, kdy není možné efektivně pokračovat z důvodu chybovosti systému, nebo vyčerpání možností doladění systému.

Závěrečná zpráva ZT

Koordinátor ZT provede ve spolupráci se zúčastněnými spolupracujícími rolemi (dle řešených oblastí v průběhu realizace) zhodnocení výsledků všech významných běhů a průběhu ZT. Dále přezkoumá, zda byly naplněny výkonnostní cíle a bylo vyhověno kritériím o ukončení testu. V případě rozhodnutí o ukončení před naplněním cílů ZT (např. časové důvody, nalezené a řešené problémy), musí být toto rozhodnutí v závěrečné zprávě náležitě zdůvodněno.
Dokument závěrečné zprávy by měl obsahovat:

• cíle a rozsah výkonnostního testu,
• popis přípravy (stručný průběh analýzy, přípravy zátěžových skriptů, testovacího prostředí a dat),
• stručný popis významných běhů z hlediska plnění cíle ZT (průběh a identifikované problémy při běhu),
• detailní a grafické výsledky referenčních a dalších významných běhů,
• zhodnocení naplnění cíle ZT,
• popis nalezených problémů testovaného systému a jejich navrhovaná řešení,
• návrh dalšího postupu prací nad testovaným systémem (postupná eliminace nalezených nedostatků systému).

Závěrečná zpráva podléhá standardní schvalovací proceduře ze strany zadavatele a je součástí akceptace provedení výkonnostního testu.
Je třeba si uvědomit, že v případě výkonnostních testů je úspěchem jak nalezení úzkého místa, tak i potvrzení dostatečné výkonnosti systému. Obecně platí, že neexistuje systém, který by neměl nějakou slabinu ve své architektuře. Jen je třeba ji odhalit.

Autoři článku, Jiří Sýkora a Tomáš Síbrt, působí jako test manager a test engineer ve společnosti Cleverlance Enterprise Solutions.