Ještě než se pustíme do tématu samotného, dovolte mi poznámku k použité terminologii. V některé literatuře či metodikách je zátěžový test považován pouze za jeden z typů testů výkonnostních. V této sérii článků budeme však oba termíny používat jako synonyma. Důvodem je fakt, že označení zátěžové testy a zkratka ZT jsou mezi českou veřejností v tomto obecném smyslu zažité. V následujícím cyklu článků jsou uvedené postupy kombinací metodických doporučení a několikaletých zkušeností z realizací výkonnostních testů různého typu. Postupy jsou obecně použitelné při plánování, přípravě a realizaci jakéhokoliv typu výkonnostního testu.

Proč výkonnostní testy plánovat

Pro úspěšnou a včasnou realizaci výkonnostních testů je velmi důležité, aby byla jejich potřeba v rámci standardních firemních change management procesů včas identifikována. V praxi to znamená, že výkonnostní testy by měly být plánovány již v akviziční fázi dané změny či projektu, aby byl dostatečný časový prostor pro jejich realizaci, případně aby nekolidovali s jinými projekty na stejném prostředí. Hlavním důvodem je včasné ohodnocení pracnosti a dalších nároků ZT a posléze alokace potřebných zdrojů (finančních, materiálových, lidských) již v okamžiku schválení realizace změny, projektu.
Často dochází k tomu, že při schvalování dané změny či projektu nejsou do požadavků na otestování řešení výkonnostní testy vůbec zahrnuty a jejich potřeba je identifikována až v průběhu vývoje řešení, nebo až po nasazení řešení do produkčního prostředí. To vede v projektu k těmto důsledkům:

• Přečerpání projektového finančního budgetu – ovlivňuje cena nástroje, organizační náročnost výkonnostních testů, nároky na další zdroje, především pracnosti jednotlivých řešitelů, protože řešitelský tým se obvykle skládá z více než deseti osob.
• Časovým posunům – zátěžové testy je možné provádět až po úspěšném provedení funkčních testů, při pozdějším pokusu o alokaci mohou být klíčoví pracovníci již alokováni na jiné úkoly a je nutné na ně čekat nebo pracně vyjednávat jejich uvolnění, což zpětně ovlivňuje celkové náklady realizace změny.
• Nedostatečnému výkonnostnímu otestování – při nenaplánování ZT je obvykle v časové a finanční tísni dodatečně definován pouze minimalistický rozsah výkonnostních testů, mohou být při výběru transakčního mixu zanedbány business transakce, které jsou pro zátěž systému významné. V konečném důsledku mohou být následky stejné, jako by se ZT vůbec nerealizovaly.
• Nasazení výkonnostně neotestovaného řešení do produkčního prostředí – výkonnostní výpadky v provozu systému způsobují často finanční ztráty provozovatele, a to jak přímé snadno vyčíslitelné z nemožnosti obchod realizovat, tak nepřímé, kdy se klient vlivem častých výpadků a pomalých odezev systému rozhodne pro jiného dodavatele.

Fáze plánování výkonnostních testů

Při plánování výkonnostních testů se postupuje postupným upřesňováním požadavků na zdroje, analogicky jako při plánování funkčních, systémově integračních a akceptačních testů. Upřesňování požadavků a jejich pracností probíhá obvykle v následujících krocích:

• Definice business požadavku na změnu – již při definici business požadavku na změnu může být identifikována potřeba zátěžových testů.
• Analýza požadavku na změnu – business požadavek je posuzován z hlediska realizovatelnosti a dopadů požadavku. V tomto kroku by měl být požadavek na ZT identifikován a ohodnocen z hlediska pracnosti a finanční zátěže. Není-li možné jednoznačně identifikovat všechny dopady (tedy i přesnou cenu realizace), provádí se tzv. feasibility study, která je pak podkladem pro rozhodnutí o realizaci, či nerealizaci požadované změny.
• Schválení (zamítnutí) realizace požadavku na změnu – na základě všech potřebných podkladů je o změně rozhodnuto příslušným orgánem.

V případě plánování výkonnostních testů je rozdíl pouze v atributech, které oproti funkčním testům ovlivňují pracnost a nároky na zdroje. Patří mezi ně testovací nástroj, testovací prostředí (nutná co největší shoda s produkčním prostředím), spolupracující role atd.
Jinou pozornost je potřeba věnovat při plánování a přípravě opakovaného výkonnostního testu nad již existující aplikací, kdy je možné použít poznatky z předchozích zátěžových měření (typicky u benchmarkových testů při migraci databáze na vyšší verzi) oproti výkonnostnímu testu nad novou aplikací (systémem).
Výkonnostní testy jsou plánovány s různým stupněm podrobnosti v následujících fázích realizace změny (projektu):

• fáze zpracování požadavku na změnu (projekt),
• fáze vývoje řešení změny (projektu),
• fáze ukončení funkčních (SIT) testů.

Obr. 1: Výkonnostní testy v životním cyklu změny (projektu)

Fáze zpracování požadavku na změnu (projekt)

V rámci definice strategie otestování schvalované změny se požadovaná změna posuzuje kromě rozsahu funkčních testů a jejich technik také z pohledu potřeby realizace dalších typů testů (výkonnostních, bezpečnostních). Často je požadavek na výkonnostní testy dán jednoznačnými pravidly útvaru IT provozu, kdy jsou například u nových řešení, pro změny vývojové technologie či změny verze databáze požadovány výkonnostní testy automaticky jako podmínka jejich začlenění do produkčního prostředí. Tato fáze představuje poslední možnost, kdy lze požadovat výkonnostní test tak, aby byl v ceně realizace změny korektně obsažen bez uplatnění změnového řízení realizace změny (projektu).
Pro základní naplánování výkonnostních testů je nutné:

• Definovat cíl a rozsah zátěžového testu – prvotní definice výkonnostních akceptačních kritérií, specifikace cíle výkonnostního testu, odhad předpokládaného počtu business transakcí použitých v ZT.
• Určit nástroj pro zátěžový test – ne vždy je to v této fázi možné a v takovém případě je tedy cena realizace změny obvykle určena podmíněně. Pro nové řešení nebo novou technologii je často nutné provést technologické testy nad vzorkem řešení i s několika nástroji. Je-li možné nástroj určit již v této fázi a zadavatel řešení vlastní jeho licenci, pak musí odpovědný pracovník pro daný projekt alokovat licenci na předpokládaný termín realizace výkonnostního testu. Nástrojům se budeme podrobněji věnovat v některém z dalších článků.
• Specifikovat testovací prostředí – prostředí závisí na cíli a dostupnosti disponibilního hardwaru a softwaru a předběžném předpokladu, jaké okolní systémy bude nutné zakomponovat do testovacího prostředí. Součástí testovacího prostředí je i vybraný nástroj pro realizaci ZT včetně generátorů zátěže, případně dalších komponent testovacího nástroje.
• Specifikovat realizační tým a hrubý odhad pracnosti – definice rolí potřebných pro úspěšnou realizaci, odhad pracností za jednotlivé role, případná částečná konkretizace týmu.
• Definovat milníky zátěžového testu – návrh začlenění rámcového harmonogramu ZT do plánu souvisejících prací při realizaci dané změny, návrh milníků ZT.

Fáze vývoje řešení změny (projektu)

V případě, že nebylo možné v předchozí fázi rozhodnout o vhodném nástroji pro výkonnostní test, je nutné nejpozději v polovině vývojových prací provést technologický test, aby bylo možné rozhodnout o nejvhodnějším nástroji pro plánovaný výkonnostní test.
Technologický test je obvykle prováděn jako prověření realizovatelnosti plánovaného ZT z hlediska kompatibility testovacího nástroje s použitou technologií a technikami programování. Technologický test je pak prováděn na pilotním vzorku řešení, nebo na již hotové části aplikace.
Závěrem technologického testu bývá rozhodnutí o stupni testovatelnosti aplikace daným nástrojem, případně doporučení pro vývojové pracovníky, jak postupovat, aby byla náročnost pozdější realizace ZT přijatelná.
Součástí technologického testu bývá často rovněž určení potřebné konfigurace a počtu strojů pro testovací nástroj a jeho komponenty (v případě HP LoadRunneru například Controlleru a generátorů zátěže).
Při větším počtu virtuálních uživatelů může potřeba generátorů zátěže přesáhnout i počet deseti strojů, proto je nutné technologický test zrealizovat co nejdříve, aby bylo možné generátory zátěže včas zajistit. Ne vždy je k dispozici dostatečný počet volných strojů a je třeba je zapůjčit, což může trvat i déle než jeden měsíc.
Vybraný nástroj zároveň může ovlivnit pracnost přípravy zátěžových skriptů a ve velké míře i způsob monitoringu a zpracování výsledků měření ZT, proto je nutné v předchozí fázi odhadnutou pracnost revidovat a v případě nutnosti dokončit schvalovací proces realizace změnového požadavku (při podmíněném schválení realizace změny), nebo včas vyvolat změnové řízení na požadovanou alokaci zdrojů.

Fáze ukončení funkčních (SIT) testů

V průběhu realizace systémově integračních testů je zpracována analýza pro ZT, která reviduje požadavky na zátěž, cíle ZT, akceptační kritéria, definuje transakční mix, potřebná testovací data, organizaci výkonnostních testů, podrobný harmonogram atd. Z tohoto pohledu je tedy analýza pro ZT pro následnou realizaci výkonnostních testů klíčová, proto bude analýza pro ZT podrobně probrána v následujícím článku.
Z hlediska plánování výkonnostních testů je analýza pro ZT posledním a nejpodrobnějším krokem. Protože pro výkonnostní testy je nutná bezchybná aplikace, je úspěšné ukončení funkčních (SIT) testů logickým milníkem pro ukončení schvalovacího řízení analýzy pro výkonnostní test. Následuje zamražení vývoje aplikace a zahájení přípravy výkonnostního testu – příprava zátěžových skriptů, příprava testovacího prostředí, příprava testovacích dat.

Obr. 2: Ukázka slepého harmonogramu ZT včetně vzájemných vazeb

Z uvedeného je patrné, že vzhledem ke složitosti realizace výkonnostních testů a často velkému množství neznámých ve fázi „zpracování požadavku na změnu“ je vhodné akceptační výkonnostní testy realizovat jako samostatný požadavek přímo vázaný na příslušnou změnu (projekt).

V dalším díle našeho seriálu o výkonnostních testech podnikových aplikací se budeme věnovat problematice analýz potřebných pro výkonnostní testy. Mimo jiné otázkám upřesnění zadání zátěžových testů, analýze testovaného systému (popis testovaného systému, návrh transakčního mixu, popis business transakcí, specifikace testovacích dat), návrhu režimů a scénářů testů.

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