facebook LinkedIN LinkedIN - follow
IT SYSTEMS 12/2008 , ITSM (ITIL) - Řízení IT

Výkonnostní testy podnikových aplikací

Jiří Surý


S přechodem aplikací na vícevrstvou architekturu a s prudkým vývojem v oblasti nových technologií se začaly výrazným způsobem projevovat výkonnostní problémy nově vznikajících systémů. Zpočátku bylo hledání úzkých míst realizováno pomocí manuálně prováděných testů za účasti většího počtu uživatelů. To se při zvyšování počtu současně pracujících uživatelů stávalo organizačně i finančně neúnosné, navíc nebylo možné tyto testy zopakovat s garancí stejné zátěže v průběhu testu. Začaly vznikat podpůrné nástroje pro zátěžové testy. Vznikla tak disciplína výkonnostních testů.


Nástroje pro výkonnostní testy umožňují:

  • nahrazení reálných uživatelů velkým množstvím tzv. virtuálních uživatelů (řádově i tisíce, desetitisíce),
  • generování konzistentní, měřitelné a opakovatelné zátěže řízené z jednoho místa,
  • monitoring jednotlivých prvků měřeného systému, snazší odhalení úzkých míst systému, tzv. bottlenecks.

Výkonnostní testy (často se používá i pojem zátěžové testy) slouží k získávání výkonnostních charakteristik měřeného systému při různých typech zátěže (denní špička, noční či měsíční dávkové zpracování atd.), případně i při různých konfiguracích daného systému.
Hlavním přínosem výkonnostních testů je získání informací o pravděpodobném chování IT systému v reálném provozování i po několika letech ještě před vlastním nasazením systému do provozu, což mimo jiné umožňuje efektivnější plánování nákladů na rozšiřování daného systému. Současně je korektní říci, že kvalitní komerční testovací nástroje i vlastní realizace výkonnostních testů jsou poměrně drahé. Proto je nutné vždy zvážit důležitost měřeného systému a vyhodnotit cenu zátěžovým testem získaných informací oproti možným obchodním ztrátám způsobených výkonnostními problémy.

Princip výkonnostních testů

Hlavním principem automatizovaných výkonnostních testů je simulace vybraných business transakcí (tzv. transakční mix) pomocí zátěžových skriptů. Každý skript je upraven tak, že je schopen postupně zpracovávat předem připravená data (parametrizace skriptů), aby v daném čase provedl požadovaný počet transakcí s příslušným počtem virtuálních uživatelů. Pro nahrávání skriptů a realizaci zátěžových testů je nezbytně nutné, aby byl daný systém bez chyb, tedy funkčně otestovaný.
Testovací nástroj pro zátěžové testy do skriptu obvykle zaznamenává komunikaci mezi klientskou stanicí a serverem na úrovni příslušného komunikačního protokolu, jako například HTTP(S), SOAP, Corba, ODBC a podobně, což je dáno použitou technologií při vývoji aplikace. Odezvy jednotlivých uživatelských kroků jsou obvykle měřeny na úrovni síťového rozhraní (od odeslání dotazu do doručení odpovědi). Není zohledněna doba zpracování odpovědi na klientské stanici a její zobrazení.
Zde je tudíž vidět rozdíl skriptování zátěžových testů oproti skriptování automatizovaných funkčních testů, kde nástroj pracuje na úrovni GUI aplikace. Nahrává do testovacího skriptu jednotlivé objekty na obrazovce a testovací skript při simulaci provádí stejné úkony jako manuální tester, jen výrazně rychleji.
Jak znázorňuje obrázek 1 (pro ilustraci je použita terminologie nástroje HP LoadRunner), připravené skripty jsou dle scénáře připraveného v řídícím modulu (controller) rozesílány generátory zátěže (load generators) do prostředí měřeného systému, odkud je vytvářena zátěž. Generátory zátěže mohou být jak uvnitř firemní infrastruktury, tak i v různých destinacích po světě. Měření jednotlivých prvků systému zprostředkovávají tzv. monitory (monitors). Kvalita monitorů je dána použitým nástrojem pro zátěžové testy. Podobně některé nástroje umožňují i diagnostiku až na úroveň jednotlivých dotazů, algoritmů a metod. Naměřené informace jsou ukládány v databázi controlleru pro pozdější vyhodnocení.

Obr. 1: Schéma principu výkonnostních testů
Obr. 1: Schéma principu výkonnostních testů

 

Použití výkonnostních testů

Výkonnostní testy mají poměrně široké spektrum použití, které je dáno jednak cíli testů a jednak stavem aplikace v životním cyklu daného systému. Nejčastěji používané přístupy (cíle) zátěžových testů:

  • Výkonnostní akceptace systému – akceptační ověření, že výkonnostní požadavky na systém byly splněny. Využívá se při akceptaci nové aplikace nebo změny velkého rozsahu či změny platformy (DB, OS). Při změně platformy je často prováděn tzv. benchmarkový test (porovnání výkonnostních atributů před změnou platformy a po ní).
  • Odladění systému a jeho komponent – hledání úzkých míst systému a jejich opravování. Obvykle je ladění provázáno s výkonnostní akceptací rozsáhlých systémů.
  • Ověření správnosti použité platformy, technologie a infrastruktury – slouží pro ověření zvolené technologie pro vývoj nových aplikací či řešení. Test je prováděn před zahájením vlastního vývoje systému na připraveném vzorku budoucího řešení.
  • Zjištění výkonnostních limitů systému – slouží pro zjištění maximálního možného počtu současně pracujících uživatelů, maximálního počtu transakcí, úrovně naplnění databáze při zachování korektního chování systému při zatížení.
  • Zjištění výkonnostních charakteristik systému při různých typech zátěže – slouží pro ověření chování systému v kritických provozních fázích, například denních a měsíčních špičkách, nočních dávkách, omezené hardwarové konfiguraci apod.
  • Ověření chování systému při výpadku některé z komponent systému – slouží například k ověření správnosti nastavení loadbalanceru pomocí vypnutí jednoho z webserverů nebo aplikačních serverů.

Uvedené cíle jsou z hlediska náročnosti realizace, ale i z hlediska délky trvání výrazně odlišné. Například benchmarkové porovnání chování aplikace při upgrade Oracle z verze 9 na verzi 10 je záležitost zhruba dvou až tří běhů v průběhu jednoho týdne, kdežto odladění nového rozsáhlého systému může být záležitost i dvaceti běhů zátěžových testů v průběhu čtyř měsíců.

Fáze výkonnostních testů

Z hlediska fází platí pro zátěžové testy analogická pravidla jako pro funkční testování:

Plánování zátěžových testů

Příprava a realizace zátěžových testů je časově a organizačně náročná, je důležité včas indikovat potřebu výkonnostních testů a jejich rozplánování včetně alokace zdrojů. Obvykle jsou výkonnostní testy realizovány po úspěšném provedení systémově-integračních testů, případně v rámci UAT testů.

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

Přípravu je možné rozdělit do následujících na sebe navazujících a vzájemně závislých aktivit:

  • Analýza pro zátěžový test – analýza pro zátěžový test je prvním krokem přípravné fáze testů. Jde o základní realizační dokument (podobně jako je základní dokument u projektu), který podléhá schválení řídícím orgánem. V rámci analýzy je nutné detailně specifikovat všechny nutné náležitosti, od upřesnění cíle zátěžových testů, výběru transakčního mixu, specifikace testovacích dat až po definici organizačních opatření a vypracování podrobného harmonogramu testování.
  • Příprava testovacího prostředí – testovací prostředí pro zátěžové testy by mělo co nejvíce odpovídat produkčnímu prostředí. Není-li to možné, musí být testovací konfigurace alespoň porovnatelná s produkční pro interpretaci naměřených výsledků. Měření má smysl jen nad stejnou platformou a shodným nastavením jednotlivých prvků systému.
  • Příprava testovacích dat – na základě podrobné specifikace testovacích dat, obsažené v analýze pro testy, jsou naplněny jednotlivé databáze testovaného systému a připraveny datové soubory pro běh zátěžových skriptů. Pracnost přípravy dat je obvykle úměrná rozsahu daného testu. U rozsáhlejších testů se může jednat řádově o statisíce až miliony datových položek.
  • Příprava zátěžových skriptů – po schválení analýzy pro zátěžový test, připravení testovacího prostředí a zamražení aplikace je možné zahájit přípravu zátěžových skriptů. Postupně jsou nahrávány, parametrizovány (upraveny na používání dat z připravených datových souborů) a odladěny do zátěžových skriptů jednotlivé business transakce z transakčního mixu.
  • Příprava základního scénáře a provedení zkušebního běhu – po dokončení přípravy zátěžových skriptů je v testovacím nástroji připraven scénář základního běhu zátěžového testu dle návrhu v analýze pro zátěžový test (rozdělení zátěžových skriptů mezi virtuální uživatele, nastavení parametrů v monitorech, nastavení pacing time, kontrola think time). Pro ověření připravenosti zátěžového testu je obvykle realizován tzv. zkušební běh zátěžového testu (na přibližně třicet procent zátěže základního běhu), který ověří, zda si jednotlivé skripty nekonkurují, data jsou korektní, konfigurace je připravena.

Realizace zátěžových testů

Vlastní realizace zátěžového testu spočívá v úpravách hardwarové a softwarové konfigurace pro jednotlivé běhy zátěžového testu a v jejich spouštění. Jako první běh je obvykle realizován základní cyklus, který je brán jako referenční. Druhý a další běhy jsou dány cílem zátěžového testu a výsledky předchozích běhů, tj. přímo navazují na aktivitu vyhodnocení běhu zátěžového testu, kde je definován postup pro další běh, tj. případné úpravy hardwarové a softwarové konfigurace, scénářů a měřených parametrů daného běhu.

Vyhodnocení zátěžových testů

Každý běh zátěžového testu je obvykle na společném workshopu vyhodnocen, jsou zjištěny nálezy a pokud možno identifikovány problémové oblasti. Ne vždy je možné jednoznačně určit úzké místo, proto se na schůzce dohodnou nové parametry dalšího běhu, aby bylo možné přesné určení zdroje problému, případně potvrzení příčiny identifikovaného úzkého místa. Po ukončení všech plánovaných běhů zátěžového testu je obvykle zpracována závěrečná zpráva o průběhu a výsledcích zátěžového testu (zdokumentování významných měření a nálezů).

Obr. 2: Controller nástroje HP LoadRunner, ukázka zobrazení připraveného scénáře zátěžového testu
Obr. 2: Controller nástroje HP LoadRunner, ukázka zobrazení připraveného scénáře zátěžového testu

 

Testovací nástroje pro výkonnostní testy

Při výběru nástroje je nutné zohlednit cíl výkonnostního testu (co a jak se bude měřit), technologii řešení (kompatibilita měřené aplikace s nástrojem), efektivní použitelnost nástroje (co je schopen nahrát a monitorovat a s jakou použitelností, respektive potřebou dalších úprav) a v neposlední řadě i cenu nástroje. Uvedené atributy výrazným způsobem ovlivňují pracnost realizace, kvalitu a cenu výkonnostního testu. Často je vhodné před vlastním zahájením přípravy a realizace výkonnostních testů provést technologický test, jehož pomocí je možné o výběru vhodného nástroje pro výkonnostní test dané aplikace efektivně rozhodnout.
Nástroje pro zátěžové testování lze tedy velice obtížně vzájemně porovnávat. Každý z nástrojů má své výhody i nevýhody v různých oblastech funkcionality. Je vhodné posuzovat nástroj vždy s ohledem na konkrétní typ testované aplikace, cíle výkonnostních testů a dalších požadavků daného testu.
Nástroje pro výkonnostní testy je možné dělit z několika pohledů a hledisek. Pro základní přehled zde uvádíme pouze hledisko licenční:

Komerční nástroje

Profesionální řešení, často realizované ve spolupráci s monitorovacími nástroji. Nejvýznamnější performance komerční nástroje (viz obrázek 3 a 4):

  • HP LoadRunner – prakticky nejrozšířenější, nejpoužívanější nástroj, s největším počtem zabudovaných monitorů a protokolů (HTTP/S, web services, SAP, Siebel, Oracle, ODBC, People Soft, TCP/IP, ...).
  • IBM Rational Performance Tester – dobrá alternativa měření webových aplikací (levnější než LoadRunner umožňující měřit velké systémy), dále umožňuje práci s protokoly SAP, Siebel (zde již práce není tak komfortní), Citrix atd.
  • Compuware QA Load – nástroj poskytuje sice větší množinu protokolů, ale ne všechny umožňují efektivní nahrávání zátěžových skriptů. Nabízí pouze základní monitoring. Pro podrobnější monitorování prvků systému je nutné (podobně jako u IBM RPT) spojení se spolupracujícím monitorovacím nástrojem.
  • Borland SilkPerformer – poměrně velké množství monitorů a protokolů s vysokou podporou nahrávání, není příliš rozšířen, přestože má slušnou úroveň. Firma Borland akvizovala firmu Segue a jako základ pro výkonnostní testování použila nástroj SilkPerformer.

Nekomerční

Často jsou vytvořeny pouze pro konkrétní typ aplikace či řešení, a nemají tedy širší využití. Velmi rozšířeným a  pro generování zátěže často používaným nástrojem je Apache JMeter. Další open source nástroje je možné nalézt například na adrese www.opensourcetesting.org/performance.php (může obsahovat i  některé již zkomercionalizované nástroje).

Obr. 3: Podíl testovacích nástrojů na světovém trhu
Obr. 3: Podíl testovacích nástrojů na světovém trhu

 

Obr. 4: Pozice testovacích nástrojů na trhu z pohledu analytické společnosti Gartner
Obr. 4: Pozice testovacích nástrojů na trhu z pohledu analytické společnosti Gartner



Autor působí jako test manager ve společnosti Cleverlance Enterprise Solutions.

O problematice výkonnostního testování podnikových aplikací připravujeme seriál, který bude v IT Systems vycházet v první polovině příštího roku. Podrobně v něm probereme realizaci jednotlivých fází výkonnostních testů, od plánování a přípravy přes vlastní realizaci až po vyhodnocení.

Chcete získat časopis IT Systems s tímto a mnoha dalšími články z oblasti informačních systémů a řízení podnikové informatiky? Objednejte si předplatné nebo konkrétní vydání časopisu IT Systems z našeho archivu.

Inzerce

Modernizace IS je příležitost přehodnotit způsob práce

IT Systems 4/2025V aktuálním vydání IT Systems bych chtěl upozornit především na přílohu věnovanou kybernetické bezpečnosti. Jde o problematiku, které se věnujeme prakticky v každém vydání. Neustále se totiž vyvíjí a rozšiřuje. Tematická příloha Cyber Security je příležitostí podívat se podrobněji, jakým kybernetickým hrozbám dnes musíme čelit a jak se před nimi můžeme chránit. Kromě kybernetické bezpečnosti jsme se zaměřili také na digitalizaci průmyslu.