Dokument Analýza pro ZT určuje základní atributy výkonnostního měření:

• co se bude měřit (aplikace, transakční mix),
• nad jakým prostředím se bude měřit (testovací prostředí, generátory zátěže),
• jakými prostředky se bude měřit (testovací nástroj, potřebné monitory, měřené parametry),
• s jakými omezeními a riziky bude měření provedeno (standardní projektový postup řízení rizik),
• v jakém čase a s jakými zdroji bude měření provedeno (definice týmu, harmonogram),
• jaká bude organizace ZT (bezpečnost produkčního prostředí).

Podrobnost analýzy je dána stanoveným cílem výkonnostních testů a organizační úrovní schvalovacího orgánu. Například akceptační výkonnostní test bude schvalovat ředitel IT provozu – analýza bude podrobnější, lokální ladicí ZT bude schvalovat vedoucí projektu – analýza nemusí obsahovat všechny níže uvedené kapitoly.

Fáze analýzy pro ZT

Vlastní analýzu pro ZT je možné rozdělit na tři části (fáze):

• upřesnění zadání ZT,
• analýza testovaného systému,
• návrh realizace ZT.

Jednotlivé aktivity analýzy pro ZT na sebe navazují a jsou většinou na sobě závislé (obr. 1). Znamená to, že bez znalostí získaných v předchozí aktivitě nemůže analytik ZT efektivně pokračovat v analytických pracích následujících aktivit. Současně aktivity analýzy odpovídají příslušným kapitolám, které jsou do analýzy zpracovávány.

Obr. 1: Posloupnost aktivit analýzy pro ZT

Upřesnění zadání ZT

V průběhu této fáze je upřesněno zadání ZT. Aktivity slouží k revizi původně definovaných požadavků na ZT se skutečnými podmínkami realizovaného projektu.

Definice cílů a rozsahu ZT

Cílem aktivity je zpracování podkladů z akviziční části změny (projektu) a doplnění o poznatky z vývoje řešení, jeho funkčního testování a dodaných provozních podkladů či požadavků. Analytik ZT definuje ve spolupráci s vedením projektu finální cíl ZT a provede specifikaci činností (rozsah testování), na které se budou řešitelé ZT primárně soustředit. Nejčastěji definované cíle ZT:

• výkonnostní akceptace řešení,
• optimalizace hardwarové a softwarové konfigurace,
• zjištění limitů hardwarové a softwarové konfigurace,
• hledání úzkých míst již provozovaného systému,
• ověření výkonnosti po změně technologie, po upgradu na novou verzi (operačního systému, aplikace, databáze) nebo po významné změně konfigurace.

Specifikace realizačního týmu

V rámci aktivity je provedena revize definice realizačního týmu, dle aktuální disponibility příslušných pracovníků, probíhá v úzké součinnosti se zadavatelem ZT nebo projektovým vedením. Složení realizačního týmu je dáno cílem ZT. V případě optimalizace hardwarové a softwarové konfigurace je potřeba součinnosti poměrně velkého počtu pracovníků IT provozu a vývoje, pro benchmarkové měření pak je počet spolupracujících specialistů minimalizován a tým je rozšiřován až podle charakteru odhalených úzkých míst.

Specifikace testovacího prostředí

Cíl ZT určuje, zda půjde o měření ve vnitřní smyčce zákazníka, nebo bude nutné generování zátěže realizovat zpoza firewallu. Toto je nutno projednat s bezpečnostními pracovníky, zda je to vůbec možné a za jakých podmínek. Stejně tak cíl ZT přímo ovlivňuje potřebnou výkonnost jednotlivých serverů, kapacitu databází atd. Velmi důležitou částí je upřesnění potřebného počtu generátorů zátěže. Obecně platí, že by se ZT měl realizovat na samostatné testovací smyčce, mimo produkční prostředí. Ne vždy je možné toto pravidlo dodržet, proto je nutné projednat podporu pracovníků IT provozu (monitoring) v oblastech, kde ZT produkční prostředí použije, aby nedošlo k jeho poškození.

Kritické faktory

Průběžná aktivita po celou dobu analýzy, identifikace rizik by měla pokračovat i po schválení analýzy. Aktivita je analogická se standardními projektovými postupy, tj. při zjištění omezujících podmínek v průběhu analýzy je nutné všechna rizika zaevidovat, ohodnotit jejich závažnost a stanovit kroky k jejich eliminaci, je-li možná. Obvyklá rizika při realizaci ZT:

• omezující technické podmínky ZT – například vyřazení business transakce z důvodu obtížné přípravy potřebných dat nebo nutnost emulace některého ze spolupracujících systémů z důvodu jeho nedostupnosti,
• odmínky ohrožující splnění časového rámce ZT – například vysoká pracnost přípravy testovacích dat, velké množství testovacích dat, nedostatek lidských zdrojů,
• podmínky ohrožující vlastní realizaci ZT – nedostatek prostředků pro sestavení adekvátního testovacího prostředí, vysoké riziko způsobení poruchy produkčního prostředí s dopadem do businessu zákazníka,
• další omezení – dle charakteru projektu – je vhodné se v rámci analýzy seznámit s projektovými riziky, které mohou ovlivnit i realizaci ZT.

Analýza testovaného systému

Tato fáze analýzy řeší, jaké transakce je nutné měřit pod zátěží. Popis testovaného systému v analýze je určen především pro pracovníky, kteří nejsou přímými účastníky projektu (schvalovatelé, provozní dohled).

Popis testovaného systému

Informace získané v této aktivitě použije analytik v dalších aktivitách k definici transakčního mixu a podmínek pro běh ZT. Při popisu řešení vyhodnocuje analytik systém z několika pohledů:

• charakteristika systému – výčet hlavních funkcí, architektura, použité operační systémy, databáze a další software (včetně verzí),
• vazby na okolní spolupracující systémy – výčet systémů, způsob vzájemné komunikace,
• procesy běžící na pozadí – například aplikační a auditní logy, aplikace sdílející server, služby, dávky, případné backupy, provozní monitoring.

Výběr transakčního mixu (business transakcí)

Klíčová aktivita analýzy. Úkolem je definování business transakcí a jejich kombinace tak, abychom při realizaci ZT generovali věrohodnou, vyváženou zátěž, odpovídající provozní špičce. Při výběru business transakcí do transakčního mixu je nutno brát v úvahu především následující kritéria:

• četnost provádění transakcí a počty uživatelů, kteří je vykonávají,
• uživatelské role,
• způsob komunikace s okolními systémy,
• vliv na vytížení systémových zdrojů (vytížení CPU, využití operační paměti, I/O operace, ...),
• typ a náročnost DB operací.

Součástí kapitoly je rovněž zdůvodnění, proč byla některá z výraznějších business transakcí zanedbána, vyřazena z transakčního mixu nebo nahrazena jinou.

Popis vybraných business transakcí

Pro každou business transakci z transakčního mixu zpracuje analytik průchod obrazovkami dané business transakce, odhadne uživatelské časy (tzv. thinktime) a poté je ověří se zástupcem uživatelů. Současně s popisem business transakcí provádí návrh měřených transakcí (dílčí odezvy systému). Tyto popisy slouží jako podklad specialistovi, který připravuje zátěžové skripty.

Specifikace testovacích dat

Dalším rozborem popsaných transakcí zjišťuje analytik potřebu dat pro úspěšnou realizaci ZT. Při specifikaci testovacích dat zohledňuje analytik data pro následující oblasti:

• loginy a role virtuálních uživatelů, definice uživatelských skupin pro ZT,
• naplnění databází z hlediska objemu i rozsahu,
• definice datových souborů z hlediska jejich struktury a obsahu – datové soubory slouží jako zdroj dat pro zátěžové skripty.

Součástí datové analýzy je rovněž způsob obnovy dat, který ovlivňuje počet připravovaných dat.

Specifikace měřených parametrů a jejich metriky

V rámci aktivity jsou nadefinovány měřené parametry pro základní běh. V základním běhu by měly být na jednotlivých prvcích měřeny alespoň základní výkonnostní ukazatele, jako vytížení CPU, využití operační paměti, práce s disky. Jsou-li definovány SLA pro některý z prvků konfigurace, je vhodné je v analýze rovněž uvést. Nelze-li měřit některý z prvků prostředky použitého testovacího nástroje, je nutné se dohodnout s jeho správcem na možnostech ručního měření.

Návrh realizace ZT

Tato fáze analýzy řeší především stanovení postupů, definici scénářů a organizační záležitosti ZT.

Definice cyklů ZT

Dle cíle ZT, možností testovacího prostředí pro ZT a dalších informací zjištěných v předchozích aktivitách definuje analytik potřebné úkony pro vlastní spouštění ZT:

• definuje podmínky pro spuštění testu a přípravné kroky,
• definuje úlohy běžící na pozadí, dávková zpracování,
• definuje základní a alternativní scénáře ZT.

Definice (výpočet) scénářů ZT Provádí se obvykle pouze výpočet základního scénáře, scénáře alternativních cyklů jsou definovány až po prvním měření zátěže dle výsledků měření. Pro definici scénáře je zapotřebí zajistit v průběhu analýzy následující informace:

• maximální počet současně pracujících uživatelů ve špičce,
• počet business transakcí za den (za hodinu) ve špičce,
• počet pracovních hodin za den, denní režim,
• získání dalších informací o denních špičkách.

Cílem je určení hodinových četností pro jednotlivé zátěžové skripty, jejichž pomocí bude generována zátěž. Hodnoty slouží pro výpočet při rozdělování počtů virtuálních uživatelů pro jednotlivé zátěžové skripty.

Kritéria pro ukončení ZT

Kapitola definuje postup pro jednotlivé alternativy ukončení realizace ZT. V této aktivitě jsou porovnána původně požadovaná akceptační a další kritéria pro ZT s reálnými možnostmi testovacího prostředí, časovými a dalšími omezeními. Zátěžový test je možné ukončit i bez splnění akceptačních kritérií, vždy je nutné tento krok projednat se zadavatelem ZT a vedením projektu. Obvyklé důvody ukončení ZT bez splnění akceptačních kritérií:

• závažné chyby softwaru odhalené při ZT,
• vyčerpání možností při optimalizaci hardwaru a softwarové konfigurace,
• překročení času vymezeného pro realizaci ZT,
• dosažení smluvně dohodnutého počtu běhů ZT.

Harmonogram ZT

Výsledkem aktivity je rozpracování aktivit na základě jejich předpokládaných pracností do podrobného harmonogramu přípravy a vlastní realizace ZT.

Organizační zabezpečení ZT

Kapitola popisuje organizační opatření pro spouštění a vyhodnocování jednotlivých běhů ZT.
Opatření se obvykle týkají:

• účasti konkrétních pracovníků při spouštění běhu ZT,
• účasti konkrétních pracovníků na vyhodnocení jednotlivých běhů ZT,
• režimu provádění ZT,
• způsobu monitoringu rizikových oblastí,
• způsobu komunikace týmu.

Připomínkové řízení a schválení analýzy pro ZT

Zpracovaná analýza je předána k připomínkám zadavateli ZT a projektovému manažerovi, kteří určí pracovníky, jež se budou podílet na připomínkovém řízení. Připomínky jsou zpracovávány standardním způsobem, jak je zvykem například u projektové dokumentace. Způsob vypořádání připomínek je pro urychlení vhodné prezentovat na workshopu, kde je možné dokument rovnou finalizovat.
Zahájení přípravných prací před schválením analýzy pro ZT generuje riziko víceprací při případných úpravách transakčního mixu či testovacího prostředí. Při změně testovacího prostředí v rámci schvalovacího řízení může vzniknout potřeba provést revizi celé analýzy pro ZT.

Jiří Sýkora působí jako test manager, Tomáš Sibrt jako QA test engineer společnosti Cleverlance Enterprise Solutions.