Příprava prostředí

Jedná se o důležitou a zpravidla velmi problematickou část přípravy. Vzhledem k tomu, že neexistuje spolehlivá metoda přepočtu výkonnostních charakteristik mezi různými hardwarovými a softwarovými konfiguracemi, mělo by prostředí pro zátěžový test zcela odpovídat prostředí produkčnímu. Většina organizací však nemá takovéto testovací prostředí běžně k dispozici. Pro účely zátěžového testu se tedy obvykle posiluje některé ze stávajících testovacích prostředí s využitím rezervního nebo zapůjčeného hardwaru, aby nedošlo k výraznému zkreslení výsledků testu.
Je třeba mít na paměti, že právě na základě přesné specifikace konfigurace testovacího prostředí byly v analytické fázi vypočteny a určeny ostatní parametry zátěžového testu. Proto je nutné při jakémkoliv požadavku na změnu konfigurace prostředí vždy nejprve provést revizi analýzy pro ZT a přehodnotit návrh testu na základě provedené úpravy.
Součástí testovacího prostředí je také testovací nástroj a jeho generátory zátěže. Fyzické umístění generátorů zátěže v rámci prostředí je určeno především cílem zátěžového testu. Při ladění systému je snahou umístit generátory do vnitřní sítě, co nejblíže k testované aplikaci. Naopak při požadavku na zjištění reálných odezev koncového uživatele se generátory často umisťují do vzdálených lokalit ve vnější síti (například na různé pobočky organizace), aby měření zahrnovalo i vliv síťové infrastruktury.

Příprava monitoringu

Příprava monitoringu je v podstatě jednou z částí přípravy testovacího prostředí. Z technického hlediska se jedná o nastavení přístupů a instalaci monitorovacích agentů či sond na příslušné prvky infrastruktury testovacího prostředí. Právě tyto činnosti však zpravidla narážejí na bezpečnostní pravidla provozu IT, a je tedy nutné si včas vyjednat příslušné výjimky. Absence důležitých výkonnostních charakteristik systému totiž může výrazně snížit vypovídací hodnotu zátěžového testu.

Příprava dat

Příprava testovacích dat vychází z jejich specifikace vytvořené v rámci analýzy pro ZT. Je nutné zdůraznit, že zatímco ve funkčních testech se pracuje řádově s jednotkami až stovkami hodnot, pro zátěžový test může být potřeba připravit statisíce nebo i miliony datových položek v různých databázích.
Přípravu dat pro zátěžový test můžeme rozdělit do následujících oblastí:

Uživatelské účty a role

Z hlediska významu a způsobu přípravy se jedná o zvláštní skupinu dat. Zatímco většinu ostatních dat je mnohdy možné získat z obsahu stávajících databází (nejčastěji jde o produkční databáze), uživatelské účty je téměř vždy nutné vytvořit „na míru“ pro zátěžový test. Parametrem určujícím jejich množství bývá maximální počet současně pracujících uživatelů. Pro některé aplikace je navíc nutné vygenerovat stejný počet klientských certifikátů nebo digitálních podpisů. Z pohledu využití dat se zpravidla nejedná o destruktivní data (během testu se neznehodnocují), ale je nutné mít na paměti specifická pravidla, kterým podléhají (expirace účtů, požadavky na změnu hesla apod.).

Naplnění databáze

Při přípravě databází pro ZT je potřeba zajistit dodržení několika pravidel:

• Celková naplněnost databáze – databáze pro zátěžový test by měla být naplněna daty o stejném objemu a struktuře jako databáze, nad kterou je nebo bude testovaný systém reálně provozován. Toto pravidlo by mělo být dodrženo i u databází spolupracujících systémů začleněných do testovacího prostředí.
• Bezpečnost dat – ideálním zdrojem dat pro zátěžový test bývá obvykle produkční databáze. Produkční data ovšem mohou obsahovat důvěrné informace a v takovém případě je nutné zajistit jejich znehodnocení ve smyslu zákona č. 101, o ochraně osobních údajů. Znehodnocení (anonymizace) dat ale současně nesmí narušit důležité logické vazby, data musí zůstat smysluplná a vzájemně konzistentní. U velkých systémů je anonymizace dat poměrně nákladná, proto jsou pro test často používána „ostrá“ produkční data, se kterými je nutné zacházet v příslušném režimu.

Datové soubory

Jedná se o soubory, které obsahují data potřebná pro běh zátěžových skriptů reprezentujících jednotlivé business transakce. Obsahují především hodnoty, které virtuální uživatelé vyplňují nebo vybírají v rámci svého průchodu aplikací. V nejlepším případě lze tato data vybrat ze stávajícího obsahu testovací databáze pomocí SQL příkazů. Pokud není k dispozici dostatečné množství vhodných záznamů, je nutné tyto položky do databáze nějakým způsobem naplnit. Jelikož nebývá vždy možné přesně definovat všechny datové vazby pro vytvoření plnících SQL skriptů, přistupují testovací týmy často k plnění databází přes uživatelské (nebo jiné) rozhraní aplikace za pomoci nástrojů pro funkční nebo zátěžové testy. Tento způsob přípravy dat je však poměrně pracný a časově náročný. Pokud není možné požadovaná testovací data do datových souborů připravit v požadované kvalitě, množství a v požadovaném čase, je nutné po dohodě s projektovým vedením buď posunout realizaci ZT v čase, nebo dotčenou business transakci z transakčního mixu vyřadit. V testu pak lze chybějící zátěž alespoň částečně kompenzovat adekvátním navýšením počtu uživatelů u jiné transakce s obdobným charakterem zátěže.

Obr 1.: Práce s datovým souborem v nástroji HP LoadRunner

Důležitou součástí přípravy dat je rovněž zajištění způsobu zálohování a obnovy testovacích dat. Bezprostředně po úspěšném dokončení přípravy dat pro zátěžový test je vhodné provést úplnou zálohu obsahu všech dotčených databází. Tyto zálohy jsou velice cenné v případě, že jsou data poškozena. Ne vždy je však z časových důvodů možné provádět kompletní obnovu všech databází mezi jednotlivými běhy testu. Buď je tedy připraveno dostatečné množství dat pro všechny běhy, nebo jsou připraveny SQL skripty, které vracejí použité záznamy do původního stavu.

Příprava zátěžových skriptů

Po schválení analýzy pro ZT, připravení testovacího prostředí a zamražení aplikace je možné zahájit přípravu zátěžových skriptů. Každá business transakce, vybraná v transakčním mixu, je zpravidla implementována jedním zátěžovým skriptem. Pracnost této fáze přípravy je určována především technologií a složitostí testované aplikace, může být ale do značné míry ovlivněna výběrem vhodného nástroje.
Základní kostra skriptu je většinou vytvořena automaticky testovacím nástrojem na základě záznamu komunikace mezi klientskou a serverovou částí aplikace (tzv. nahrávání skriptů). Funkcionalita skriptů se dále upravuje v následujících oblastech:
Parametrizace dat – při nahrávání jsou skripty zaznamenány vždy pod jedním uživatelem a jednou datovou variantou. Cílem parametrizace je upravit skripty tak, aby je bylo možné spouštět pro více uživatelů současně a opakovat s různými vstupními daty. Většinou však nestačí parametrizovat pouze statické vstupy, ale je nutné též pracovat s dynamickými hodnotami, které systém generuje až v okamžiku běhu skriptu.
Simulace chování uživatele – aby zátěž generovaná skripty odpovídala realitě, je nutné parametrizovaný skript rozšířit o funkce napodobující chování skutečného uživatele. Jedná se zejména o simulace uživatelských časů mezi jednotlivými kroky (tzv. thinktime), rozhodovací logiku, náhodný výběr z více variant průchodů a podobně. Mnohé nástroje rovněž umožňují vložení tzv. synchronizačních bodů, které při běhu testu zajišťují vykonání konkrétního kroku více uživateli najednou.
Funkce pro řízení a vyhodnocování – do skriptů je dále nutné zařadit funkcionalitu pro řízení běhu a vyhodnocení testu. Důležité jsou zejména funkce pro sledování odezev systému ve vybraných krocích uživatele (tzv. měřené transakce), bez kterých by nebylo možno většinu testů řádně vyhodnotit. Dále je vhodné využít různé kontrolní mechanismy (kontrolní body, výstupy do logu, výpisy použitých dat atp.), aby bylo možné odhalit a lokalizovat případné problémy při přehrávání skriptů, které by mohly výsledky testu zkreslit.
Doprogramování skriptů – při přípravě zátěžových skriptů se často naráží na technické komplikace. Nejčastěji se jedná o dílčí nekompatibilitu použitého nástroje s testovanou aplikací nebo o složitější algoritmy, které je potřeba ve skriptech vykonávat. Tyto situace je pak nutno řešit „ručním“ doprogramováním problematických částí kódu.

Obr. 2: Princip nahrávání zátěžových skriptů v nástroji HP LoadRunner

Po finálním odladění všech zátěžových skriptů je v testovacím nástroji připraven scénář zkušebního a základního běhu testu. Scénář obsahuje nastavení celkového počtu virtuálních uživatelů, jejich rozdělení do předem definovaných uživatelských skupin, nastavení délky běhu testu, strmosti náběhových křivek a řady dalších vlastností ovlivňujících charakter generované zátěže. Současně se scénářem se také většinou nastavují metriky pro monitoring výkonnostních parametrů určené pro daný běh testu.

Zkušební běh ZT

Pro ověření kompletnosti přípravy k ZT je nutné spustit zkušební běh ZT. Zkušební běh je obvykle prováděn na úrovni třiceti až padesáti procent zátěže definované základním scénářem. Ve zkušebním běhu je ověřena bezchybnost paralelního běhu zátěžových skriptů, správnost testovacích dat, nastavení scénáře testu, funkčnost monitorů, a v neposlední řadě také připravenost testované aplikace a testovacího prostředí na spuštění plné zátěže. Dobrým zvykem je nastavit pro zkušební běh rozšířené logování na straně nástroje i na straně testované aplikace a tyto záznamy po zkušebním běhu pečlivě prostudovat. Pokud ani zde není shledána žádná chyba, je možné prohlásit přípravu ZT za úspěšně dokončenou. Měření může být zahájeno.

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.