UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

UNICORN COLLEGE Katedra informačních technologií

BAKALÁŘSKÁ PRÁCE Využití open source nástrojů pro výkonnostní testování v enterprise prostředí a jejich porovnání s HP LoadRunner

Autor BP: Karol Kováč Vedoucí BP: Ing. Miroslav Žďárský 2015, Praha

Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Využití open source nástrojů pro výkonnostní testování v enterprise prostředí a jejich porovnání s HP LoadRunner vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne ………........

…..........……………… (Karol Kováč)

Poděkování Děkuji vedoucímu bakalářské práce Ing. Miroslavovi Žďárskému za pomoc s výběrem tématu a rady při zpracování mé bakalářské práce. Dále bych rád poděkoval panu Ing. Bořkovi Zelinkovi za odbornou pomoc a další cenné rady.

Využití open source nástrojů pro výkonnostní testování v enterprise prostředí a jejich porovnání s HP LoadRunner Use of open source performance testing tools in enterprise environment and their comparison with HP LoadRunner

6

Abstrakt Cílem práce je analyzovat vybrané open source nástroje pro výkonnostní testování a nalézt nejvhodnější nástroj pro použití v enterprise prostředí. Motivací je nalézt nástroj, který je schopný nahradit komerční nástroj LoadRunner od společnosti Hewlett-Packard. První, teoretická, část práce má za úkol zúžit seznam vhodných nástrojů, které jsou pak ve druhé části práce prakticky zkoušeny, analyzovány a porovnávány s přihlédnutím k dovednostem referenčního nástroje LoadRunner. Klíčová slova: Výkonnostní testování, distribuovaná zátěž, monitoring, open source software, enterprise software, podnikové aplikace.

Abstract Goal of this work is to analyze open source performance testing tools and identify tool fitting an enterprise environment needs the best. Motivation is to identify an alternative tool for the commercial solution the LoadRunner from the Hewlett-Packard company. First part of this work aims to narrow the list of suitable tools which are analyzed further keeping in mind features and capabilities of reference solution LoadRunner in the practical part of this work. Keywords: Performance testing, distributed testing, monitoring, open source software, enterprise application.

7

Obsah 1. Úvod.................................................................................................................................11 2. Teoretická část..................................................................................................................12 2.1. Definice základních pojmů.......................................................................................12 2.1.1 Výkonnostní testování.......................................................................................12 2.1.2 Enterprise prostředí............................................................................................13 2.1.3 Enterprise software............................................................................................13 2.1.4 Open source software.........................................................................................14 2.1.5 Souběžná zátěž...................................................................................................15 2.1.6 Distribuovaná zátěž............................................................................................15 2.1.7 Monitoring.........................................................................................................16 2.1.8 Reporting............................................................................................................16 3. Cíle a motivace výkonnostního testování.........................................................................18 3.1. Čas transakce............................................................................................................18 3.2. Čas přemýšlení.........................................................................................................18 3.3. Úzké hrdlo................................................................................................................18 3.4. Ladění výkonu..........................................................................................................19 3.5. Dimenzování.............................................................................................................19 4. Nástroje pro výkonnostní testování..................................................................................20 4.1. Komerční nástroje.....................................................................................................20 4.1.1 HP LoadRunner..................................................................................................20 4.2. Open source nástroje................................................................................................21 4.2.1 The Grinder........................................................................................................22 4.2.1.1 Klady....................................................................................................................22 4.2.1.2 Zápory..................................................................................................................23

4.2.2 JMeter................................................................................................................23 4.2.2.1 Klady....................................................................................................................24 4.2.2.2 Zápory..................................................................................................................24

4.2.3 SoapUI...............................................................................................................24 4.2.3.1 Klady....................................................................................................................25 4.2.3.2 Zápory..................................................................................................................25

4.2.4 LoadUI...............................................................................................................25 8

4.2.4.1 Klady....................................................................................................................26 4.2.4.2 Zápory..................................................................................................................26

4.2.5 OpenSTA............................................................................................................26 4.2.5.1 Klady....................................................................................................................26 4.2.5.2 Zápory..................................................................................................................26

5. Závěr teoretické části........................................................................................................28 6. Praktická část....................................................................................................................29 6.1. Definice prostředí a cílů...........................................................................................29 6.1.1 Testovaná aplikace.............................................................................................29 6.1.2 Testovaná platforma...........................................................................................30 6.1.3 Testovací platforma............................................................................................31 6.1.4 Uživatelské skupiny...........................................................................................31 6.1.5 Testovaná zátěž..................................................................................................32 6.1.6 Požadavky na výkon..........................................................................................32 6.1.7 Testovací scénáře...............................................................................................33 6.1.8 Scénáře zátěže....................................................................................................35 6.1.9 Sledované hodnoty.............................................................................................38 6.2. HP LoadRunner........................................................................................................39 6.2.1 Instalace nástroje................................................................................................39 6.2.2 Vývoj testovacích skriptů..................................................................................40 6.2.3 Logy...................................................................................................................42 6.2.4 Tvorba testovacích scénářů................................................................................43 6.2.5 Spuštění a kontrola průběhu testů......................................................................43 6.2.6 Analýza výsledků...............................................................................................44 6.2.7 Plnění cílů..........................................................................................................45 6.2.8 Shrnutí................................................................................................................45 6.3. OpenSTA..................................................................................................................46 6.3.1 Instalace.............................................................................................................46 6.3.2 Vývoj testovacích skriptů..................................................................................47 6.3.3 Logy...................................................................................................................49 6.3.4 Tvorba testovacích scénářů................................................................................49 6.3.5 Spuštění a kontrola průběhu testů......................................................................50 6.3.6 Analýza výsledků...............................................................................................52 9

6.3.7 Plnění cílů..........................................................................................................52 6.3.8 Shrnutí................................................................................................................53 6.4. The Grinder...............................................................................................................54 6.4.1 Instalace.............................................................................................................54 6.4.2 Vývoj testovacích skriptů..................................................................................55 6.4.3 Logy...................................................................................................................57 6.4.4 Tvorba testovacích scénářů................................................................................57 6.4.5 Spuštění a kontrola průběhu testů......................................................................58 6.4.6 Analýza výsledků...............................................................................................60 6.4.7 Plnění cílů..........................................................................................................61 6.4.8 Shrnutí................................................................................................................61 6.5. JMeter.......................................................................................................................62 6.5.1 Instalace.............................................................................................................62 6.5.2 Vývoj testovacích skriptů..................................................................................62 6.5.3 Logy...................................................................................................................64 6.5.4 Tvorba testovacích scénářů................................................................................64 6.5.5 Spuštění a kontrola průběhu testů......................................................................66 6.5.6 Analýza výsledků...............................................................................................67 6.5.7 Plnění cílů..........................................................................................................68 6.5.8 Shrnutí................................................................................................................68 7. Závěr praktické části........................................................................................................69 8. Conclusion........................................................................................................................71 9. Seznam použitých zkratek................................................................................................73 10. Seznam zdrojů................................................................................................................74 10.1. Knižní zdroje..........................................................................................................74 10.2. Internetová zdroje...................................................................................................75 10.3. Software..................................................................................................................81 11. Seznam ilustrací..............................................................................................................83 12. Seznam tabulek...............................................................................................................84 13. Seznam příloh.................................................................................................................85 13.1. DVD se vstupy a výstupy praktické části...............................................................86

10

1. Úvod Výkonnostní testování se stejně jako všechno ostatní související s informačními technologiemi a vývojem software vůbec rychle vyvíjí a pomalu se mění v jednu nepřehlednou sadu různých řešení stejného problému více nebo méně vhodných pro daný projekt nebo prostředí. Otázky typu: jak nebo za kolik je možné vykonat výkonnostní testování, jsou výsledky testů dostatečně informativní, jak je obtížné potřebné testy připravit, kde je možné snížit náklady, mají v dnešní době již mnoho nejasných odpovědí. Nicméně v oboru výkonnostního testování je přece jen jeden silný hráč, který vyčnívá nad ostatními, a to hlavně svojí uceleností. Je jím společnost Hewlett-Packard se svým produktem LoadRunner. Ne všechny firmy si nicméně tento produkt mohou finančně dovolit nebo o něj ani nemají zájem buď kvůli licenčním podmínkám či z jakýchkoliv jiných důvodů. Cílem této práce je analyzovat dostupné open source nástroje a ověřit, zda je ve velkých podnicích zabývajících se vývojem softwaru pro vnitropodnikové použití vhodné jejich nasazení. Úvod práce se bude věnovat obecné analýze dostupných nástrojů a jejich vyhodnocení identifikuje nejlepší kandidáty pro praktické porovnání s referenčním komerčním nástrojem HP LoadRunner. Sledovat se budou zejména aspekty jako jejich stabilita, robustnost, systémová náročnost, náročnost na použití, zpracování výsledků, reporty, pokrytí protokolů, licenční podmínky, možnosti automatického nahrávání a přehrávání skriptů, kompatibilita s operačními systémy, frekvence vydávaní nových verzí, dokumentace a podpora nebo možnosti monitorování vlastních i serverových prostředků. Pro toto téma jsem se rozhodl z toho důvodu, že z volně dostupných informací není zcela jasné, který z open source nástrojů lze v oblasti výkonnostního testování považovat za dobrou alternativu ke komerčním řešením. Důraz bude kladen především na formu prezentace výsledků testování a na možnosti jejich dalších analýz těmito nástroji.

11

2. Teoretická část Tato část práce definuje základní pojmy, se kterými se bude dále pracovat, popisuje cíle a motivace výkonnostního testování a také na teoretické úrovni analyzuje a porovnává různé nástroje používané pro výkonnostní testování. Prvotní výběr vhodného nástroje pro použití v enterprise prostředí bude závislý zcela na informacích dostupných na domovských stránkách porovnávaných nástrojů. Jejich praktické porovnání bude předmětem praktické části práce.

2.1. Definice základních pojmů 2.1.1

Výkonnostní testování

Výkonnostní testování je typ testování, jehož cílem je zjistit, zda testovaný produkt splňuje výkonnostní požadavky informačního systému. Jedná se například o to, zda je výkon hardwaru dostačující, zda je produkt při stávajícím nebo odhadovaném budoucím zatížení stabilní, zda jsou odezvy systému v souladu s požadavky nebo také jaké jsou krajní hodnoty a takzvaná úzká hrdla produktu. Poznáme celou řadu typů výkonnostního testování jako je například výkonnostní profilování, jehož cílem je zjištění odezev jednotlivých transakcí produktu1, zátěžový test, jehož cílem je zjistit chování produktu při odhadovaném produkčním zatížení2, objemový test, jehož cílem je zjistit rychlost databáze, nebo vytrvalostní test, jehož cílem je ověřit houževnatost produktu při dlouze trvající zátěži3. Jako ostatní typy testování i výkonnostní testování se musí řádně naplánovat, připravit, vykonat a vyhodnotit. Ve fázi plánování se na základě výkonnostních požadavků identifikují cíle, milníky, časová náročnost, vhodné prostředí, vhodné typy testování, testovací scénáře, nástroje pro testování a v neposlední řadě akceptační kritéria. Ve fázi příprav se pak již vybrané nástroje a technologie použijí k přípravě automatizovaných testovacích skriptů (nahráním nebo manuálně), k přípravě testovacích dat a také k připravě testovacího prostředí. V této fázi je také vhodné si vybrané technologie vyzkoušet a potvrdit si jejich správný výběr vzhledem k testovanému produktu. Jakmile jsou testovací skripty připraveny, je možné je spustit dle 1 2 3

GRINSHPAN L.: Solving Enterprise Applications Performance Puzzles: Queuing Models to the Rescue. 1st edition., Wiley-IEEE Press, 2012. 256 s. ISBN 978-1118061572, str. 19-22. SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str. 14-15. SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str. 15.

12

předem definovaných scénářů z plánovací fáze. Žádné spuštění automatických testů není bezproblémové, a proto se v rámci vykonávací fáze řeší právě především tyto obtíže. V průběhu realizace testů se výsledky průběžně ukládají pro pozdější zpracování. Vyhodnocují se jak neprodleně po dokončené iteraci testu, tak i na závěr celého testování. Průběžné výsledky testů nejsou zpravidla ve formě vhodné pro prezentaci projektovým sponzorům, nicméně slouží k řešení objevených chyb souvisejících s výkonností. Na závěr celého testování se výsledky, reportované chyby a jejich řešení formalizují do podoby závěrečného reportu. Právě příprava, realizace a vyhodnocení výkonnostních testů budou hrát hlavní roli v této práci. Za jakých podmínek budou analyzované nástroje vhodné pro výkonnostní testování v enterprise prostředí ukáže zejména praktická část této práce. 2.1.2

Enterprise prostředí

Enterprise prostředím je v kontextu této práce myšleno prostředí velké firmy, ve které jsou nasazovány netriviální systémy, sestaveny zpravidla z vícero softwarových či hardwarových komponent, zajišťující jejich robustnost a dostupnost pro uživatele, kteří jsou často rozmístěny v kancelářích po celém světe4. Dodávka systému se v tomto prostředí nespokojí jenom se samotným dodáním funkčního kusu software, ale požaduje určitou kvalitu jak dodávaného produktu, tak i dokumentace nebo komunikace směrem k sponzorům projektu. Zmíněný fakt je pro tuto práci důležitý z toho důvodu, že právě spuštění, monitoring, reportování a prezentace výsledků výkonnostního testování musí v enterprise prostředí splňovat často velmi náročné požadavky. Cílem tedy bude najít vhodný open source nástroj co nejvíce splňující nároky na testování výkonu softwaru vyvíjeného v enterprise prostředí nebo pro něj. 2.1.3

Enterprise software

Enterprise software je komplexní software, který se používá uvnitř podniku. Jeho hlavní charakteristikou je, že je používán konečným počtem uživatelů. Počet uživatelů je možné definovat na rozdíl od aplikací veřejných, které může používat až nekonečně mnoho uživatelů. Počet uživatelů enterprise aplikací je možné časově segmentovat a specifikovat kdy bude aplikace používána největším množstvím uživatelů, a také určit, jaký bude jejich

4

GRINSHPAN L.: Solving Enterprise Applications Performance Puzzles: Queuing Models to the Rescue. 1st edition., Wiley-IEEE Press, 2012. 256 s. ISBN 978-1118061572, str. 31.

13

počet5. Enterprise aplikace jsou zpravidla vyvíjeny vícevrstvou architekturou, ve které jsou jednotlivé funkční komponenty rozděleny do několik vrstev. Typicky se jedná o třívrstvou architekturu, kde jsou od sebe logicky odděleny prezenční, logická (nebo také aplikační) a datová vrstva. Jak vypadá třívrstvá architektura ilustruje obrázek 1. Ilustrace 1: Třívrstvá architektura enterprise aplikace

Zdroj: Vlastní zpracování Zdroj: Vlastní zpracování Enterprise aplikace mohou být vyvíjeny a také velmi často jsou dvou-, čtyř- nebo i vícevrstvou architekturou. 2.1.4

Open source software

Open source software je software, jenž může být volně a zdarma používán, měněn nebo dále sdílen v modifikované nebo nemodifikované formě. Aby software splňoval pravidla 5

GRINSHPAN L.: Solving Enterprise Applications Performance Puzzles: Queuing Models to the Rescue. 1st edition., Wiley-IEEE Press, 2012. 256 s. ISBN 978-1118061572, str. 9-19.

14

open source software (OSS), musí dodržovat následující pravidla definovaná společností Open Source Initiative (OSI). Podle definice OSS společností OSI musí produkt obsahovat zdrojový kód a musí být povolena jeho další distribuce ve formě zdrojového nebo binárního kódu. V případě, že součásti produktu není zdrojový kód, musí být tento zdrojový kód bezplatně dostupný na Internetu. Preferovanou formou modifikací produktu je právě skrz zdrojový kód. Záměrné znehodnocení zdrojového kódu produktu není povoleno6. 2.1.5

Souběžná zátěž

Souběžná zátěž je zátěž generovaná vícero uživateli najednou. V této souvislosti se často používá hodnota počtu virtuálních uživatelů, tedy počtu uživatelů, kteří požadovanou zátěž generují. Tato hodnota je jedna z nejdůležitějších hodnot ve výkonnostním testování a popisuje, kolik reálných uživatelů maximálně bude skutečný produkt používat ve stejnou dobu. Tato hodnota je často používána i jako jedno z akceptačních kritérií pro výkonnostní testování. Počet virtuálních uživatelů má také vliv na to, který z testovacích nástrojů je pro daný počet virtuálních uživatelů vhodný použít. V případě komerčních nástrojů má často vysoký počet virtuálních uživatelů negativní vliv na náklady spojené s pořizováním licencí7. 2.1.6

Distribuovaná zátěž

V případě, že je počet virtuálních uživatelů příliš vysoký, je velmi pravděpodobné, že jedna testovací stanice nebude schopná takovou zátěž generovat. V takovém případě je nutné zátěž generovat z vícero stanic. Právě distribuci skriptů na více stanic a jejich následné spuštění se říká distribuce zátěže. Jenom distribucí testovacích skriptů a jejich spuštěním ovšem problém distribuce zátěže nekončí. Po vykonání testů je nutné výsledky ze všech stanic, kde byly skripty spuštěny, nashromáždit a analyzovat. V distribuovaném testování se pracuje s výrazy Master8 a Slave9. Pod pojmem Master se rozumí stanice, která je zodpovědná za vytváření 6 7 8 9

OPEN SOURCE INITIATIVE: Open source initiative [online]. 2014. [cit. 13.04.2014]. Dostupné z URL: . SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str. 213-214. Z anglického slova Pán. Z anglického slova Sluha.

15

požadovaného počtu virtuálních uživatelů, kontrolu běhů testů a sběr naměřených dat. Tato stanice musí být také schopná simulovat různé uživatelské skupiny 10. Pod pojmem Slave se pak rozumí stanice, která je stanicí Master řízena a je zodpovědná za vykonání samotných testovacích skriptů a měření výsledků. Ilustrace 2: Zátěž distribuovaná pomocí tří Slave stanic

Zdroj: Vlastní zpracování 2.1.7

Monitoring

Monitoringem se v této práci myslí sledování využití zdrojů testovaných a testovacích stanic v průběhu výkonnostních testů. Výstupem monitoringu jsou data a grafy reprezentující naměřené skutečnosti. Mezi často sledované hodnoty patří zejména využití procesorů, fyzických disků, fyzických nebo virtuálních pamětí a sítí 11. Monitoring těchto hodnot je důležitý ke správné identifikaci příčin výkonnostních problémů a k jejich následnému odstranění. 2.1.8

Reporting

Reportingem se v této práci rozumí finální výstup z výkonnostního testování, jehož součástí je analýza výsledků zpracována jak v textové tak v tabulkové podobě. Součástí reportů, pro větší srozumitelnost, by také měly být grafy popisující průběh jednotlivých 10 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str. 129. 11 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str. 185-195.

16

testů, rychlosti odpovědí nebo využití zdrojů. Právě v této oblasti se předpokládá, že bude síla analyzovaných open source nástrojů silně divergovat. Nároky na podobu reportů závisí především na typu posluchače. Skupina testerů nebo výkonnostních analistů bude zcela jistě požadovat velice detailní reporty vedoucí k identifikaci potenciálních úzkých hrdel testovaného systému. Na druhou stranu management bude spíše zajímat konečný výsledek. Tuto skupinu posluchačů zpravidla nezajímají detaily o tom, jak byl který výkonnostní problém vyřešen. Co je zaujímá především, je zda testovaný systém splnil výkonnostní požadavky či nikoliv12. Tabulka 1: Příklad často reportovaných hodnot Hodnota

Popis/Možnosti

Čas testování

Celkový čas běhu testu.

Počet virtuálních uživatelů

Celkový počet použitých virtuálních uživatelů.

Počet úspěšných odpovědí

Celkový počet úspěšných odpovědí. Počet úspěšných odpovědí pro jednotlivé transakce. Procento úspěšných odpovědí z celkového počtu odpovědí.

Počet neúspěšných odpovědí Celkový počet neúspěšných odpovědí. Počet neúspěšných odpovědí pro jednotlivé transakce. Procento neúspěšných odpovědí z celkového počtu odpovědí. Propustnost

Celková průměrná propustnost v transakcích za sekundu. Průměrná propustnost transakcí za sekundu pro jednotlivé transakce nebo skupiny uživatelů.

Velikost dat

Celková velikost odeslaných nebo přijatých dat. Velikost odeslaných nebo přijatých dat pro jednotlivé transakce. Průměrné hodnoty odeslaných nebo přijatých dat (například: v Kbytes/sec).

Odezvy transakcí

Minimální, maximální a průměrné odezvy transakcí. Průměrné odezvy transakcí vhledem k času. Průměrné odezvy transakcí vzhledem k počtu virtuálních uživatelů. Zdroj: Vlastní zpracování

12 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str. 173-174.

17

3. Cíle a motivace výkonnostního testování Jak již bylo zmíněno v úvodu této práce, cílem výkonnostního testování je zjistit, zda výkon testované aplikace dosahuje požadovaných parametrů. Hlavním cílem zákazníka je zcela určitě, aby časy potřebné pro vykonání určitých transakcí, tedy transakční časy odpovídaly jeho požadavkům. Tyto časy by měly být dosaženy jak ve stavu s minimálním počtem uživatelů, tak s předpokládaným množstvím uživatelů používajících danou transakci souběžně. Motivací každého projektového týmu nebo zákazníka k vykonání výkonnostního testování je fakt, že testovací tým je schopný odhalit výkonnostní problémy nebo nedostatky ještě před nasazením aplikace do produkce. Také pak poskytnout informace a podklady potřebné pro vyladění výkonu nebo správné nadimenzování hardware a software konfigurace.

3.1. Čas transakce Čas jednotlivých transakcí bývá často jeden z hlavních indikátorů výkonu aplikace a také kritériem pro akceptaci dodávaného řešení. Proto je tomuto indikátoru v průběhu celého cyklu výkonnostního testování věnovaná zvýšená pozornost. Uživatel požaduje od aplikace určitou akci, tato akce je aplikací zpracována, v případě potřeby přeposlána na některou z jejích komponent a výsledek akce je pak předán zpátky uživateli. Právě čas, který aplikace nad zpracováním a předáním výsledku uživateli stráví, je nazýván čas transakce13.

3.2. Čas přemýšlení S časem transakce je přímo spojen pojem čas přemýšlení uživatele. Tímto časem se rozumí doba, kterou uživatel aplikace stráví vstřebáním přijaté informace vrácené transakcí t1, než pak zavolá transakci t2. Tento čas je z principu proměnný a zcela závisí na situaci a rychlosti reakci uživatele. Je velmi důležité jej ve výkonnostním testování zohlednit14.

3.3. Úzké hrdlo Úzké hrdlo aplikace je místo, ve kterém se vyskytuje nežádoucí limitace počtu zpracovávaných transakcí. Toto místo způsobuje takzvané „zácpy“, kvůli kterým není 13 GRINSHPAN L.: Solving Enterprise Applications Performance Puzzles: Queuing Models to the Rescue. 1st edition., Wiley-IEEE Press, 2012. 256 s. ISBN 978-1118061572, str. 6-8. 14 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str. 99.

18

využit výkonnostní potenciál celého informačního systému. Tyto limitace můžou být dvojího charakteru a to softwarového nebo hardwarového. Softwarová úzká hrdla jsou způsobena špatným nastavením aplikačních parametrů nebo špatným aplikačním designem15. Na druhou stranu hardwarová úzká hrdla jsou způsobena například výkonem procesoru, výkonem a velikostí operační paměti nebo rychlostí sítě.

3.4. Ladění výkonu Laděním výkonu aplikace se rozumí vědomé a kontrolované změny konfigurace hardwaru nebo softwaru za účelem odstranění výkonnostních problémů odhalených při realizaci výkonnostních testů. Včasným vyladěním aplikace se zásadním způsobem šetří náklady, které by v případě selhání služby z důvodu přetížení byly znatelné.

3.5. Dimenzování Dimenzováním se rozumí vhodné sestavení komponent aplikace a jejich konfigurace na základě výsledků výkonnostního testování a požadavků na výkon aplikace. Dimenzovat lze i bez provedení výkonnostních testů, nicméně hrozí riziko, že se aplikace poddimenzuje což může zapříčinit budoucí problémy s výkonem aplikace, nebo naopak předimenzuje a vynaložené náklady na sestavení a provoz aplikace tak nebudou efektivně využity.

15 GRINSHPAN L.: Solving Enterprise Applications Performance Puzzles: Queuing Models to the Rescue. 1st edition., Wiley-IEEE Press, 2012. 256 s. ISBN 978-1118061572, str. 127.

19

4. Nástroje pro výkonnostní testování Nástrojů pro výkonnostní testování je celá řada. Mezi nástroje, které se v dnešní době používají nejčastěji, patří komerční řešení LoadRunner od společnosti Hewlett-Packard nebo open source nástroje jako je JMeter, The Grinder, SoapUI, LoadUI a OpenSTA. Je nutno říci, že každý z těchto nástrojů má své výhody, omezení a nedostatky. Proč má nástroj LoadRunner teoreticky tak výrazně navrch a kde a jak se mu výše jmenované open source nástroje mohou více či méně vyrovnat, budou pojednávat následující kapitoly. Nalézt nástroj, který by mohl řešení od společnosti Hewlett-Packard nahradit, není jednoduché, avšak díky této práci budou nalezeny konkrétní informace založené na teoretickém a praktickém srovnání, které lze k tomuto účelu využít a toto hledání ulehčit. Mezi vlastnosti, které budou analyzovány a porovnávány, patří licenční podmínky, náklady spojené s jejich použitím a údržbou, použitelnost vývojové prostředí, možnost automatického nahrávaní skriptů, skriptovací jazyk, monitoring zdrojů, zpracování výsledků, reporty, možnost distribuce zátěže, podporované protokoly, podpora a operační systém, na kterém je nástroj možné spustit.

4.1. Komerční nástroje Z komerčních nástrojů se tato práce bude věnovat nástroji LoadRunner od společnosti Hewlett-Packard, který je v oblasti výkonnostního testování považován za jakýsi standard. Mezi další komerční nástroje z oblasti výkonnostního testování stojí za zmínku Rational Performance Tester od společnosti IBM16 nebo Silk Performer od společnosti Borland17. HP LoadRunner je nicméně z těchto řešení nejucelenější a je vhodný k téměř všemu potřebnému pro realizaci výkonnostního testovaní v enterprise prostředí, bez potřeby integrace s dalšími nástroji. Záměrem této práce je nalézt vhodný open source nástroj, který by dokázal tento komerční nástroj důstojně nahradit. Proto bude LoadRunner sloužit hlavně jako referenční nástroj. 4.1.1

HP LoadRunner

LoadRunner je komerční produkt od společnosti Hewlett-Packard používaný pro 16 INTERNATIONAL BUSINESS MACHINE CORP.: Rational Performance Tester [online]. [cit. 29.03.2015]. Dostupné z URL: . 17 BORLAND SOFTWARE CORPORATION: Silk Performer [online]. 2014. [cit. 20.04.2014]. Dostupné z URL: .

20

výkonnostní testování na všech možných úrovních složitosti. Tento produkt je aktivně vyvíjen a podporován. LoadRunner disponuje automatickým nahráváním skriptů a podporuje velkou škálu protokolů jak v dnešní době hojně používaných (HTTP/S, SOAP, REST, JDBC, JMS), tak i protokolů, které jsou zpravidla dnes již méně často testovány (RTE, ICA a podobné). Kompletní seznam podporovaných protokolů je k nalezení na stránkách

http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=4AA1-

3191ENW. Velmi výraznou výhodou tohoto nástroje oproti open source nástrojům je propracovaný systém analyzování a reportování výsledků testování. Výsledky ze všech distribuovaných instancí testů jsou dostupné jednak v průběhu testování, dále i po ukončení běhu testů, kdy jsou ještě jednou automaticky analyzovány a zpracovány do srozumitelných reportů a grafů. Všechny naměřené údaje testů je také možno si stáhnout a dále analyzovat v nástroji Analysis, který je součásti dodávky nástroje LoadRunner. Možnosti tohoto nástroje jsou nesčetné a s jeho pomocí je možné vytvořit téměř jakýkoliv graf, s kterým je možné dále pracovat. Součástí tohoto nástroje je taky administrátorské rozhraní kde se dají veškeré testy a testovací scénáře modifikovat, nastavovat počty jejich virtuálních uživatelů, počty generátorů zátěže, četnosti testovacích případů a podobně. Mezi další možnosti administrátorského rozhraní, které stojí za zmínku, patří také plánovaní automatického spuštění testů a rezervace prostředí v případě rozsáhlejších testů18.

4.2. Open source nástroje V dnešní době je již na trhu open source nástrojů pro výkonnostní testování dobrý a ustálený výběr. Pří analýze trhu bylo zjištěno, že je možné seznam těch nejvíce používaných nástrojů zúžit na 5 následujících možností: SoapUI, LoadUI, JMeter, The Grinder a OpenSTA. Bylo také možné pozorovat trend, že na trhu se objevují cloudová řešení i pro potřeby výkonnostního testování. Cloudové služby nebudou součástí analýzy v této práci. Nástroje, které budou analyzovány a porovnávány, jsou ověřeny léty používání jak na malých tak na velkých enterprise projektech. Je nutno říci, že mezi vlastnosti, které jsou pro tyto nástroje typické, jsou slabá podpora a možné různé úrovně licencí. Některé z nástrojů mají ve verzích, které jsou poskytovány zdarma, omezenou 18 HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.: LoadRunner [online]. 2014. [cit. 20.04.2014]. Dostupné z URL: .

21

funkcionalitu. Pro aktivaci dalších funkčností, většinou tak potřebných v enterprise prostředí, je nutno zakoupit profesionální verzi nástroje. V takovém případe se již nejedná o open source nástroj, který je předmětem této práce. 4.2.1

The Grinder

Grinder je nástroj umožnující distribuované testování jakýchkoliv protokolů nebo jiných komunikačním kanálů, ke kterým existuje Java rozhraní pro programování aplikací (API). Mezi podporované technologie patří webové technologie (HTTP, HTTPS), webové služby (SOAP, REST), mailové služby (POP3, SMTP), databázové služby (JDBC, LDAP), služby pro přenos souborů (FTP) nebo aplikační služby (CORBA, RMI, JMS, EJBs). Skripty v nástroji Grinder se vyvíjejí ve dvou programovacích jazycích, a to Jython nebo Clojure. Je na místě zdůraznit, že programovací jazyk Jython není prakticky nikde jinde používán. Z uvedených příkladů použití tohoto nástroje je zjevné, že vývoj skriptů vyžaduje pokročilé programátorské dovednosti. Grinder je jednoduše škálovatelný díky možné distribuci zátěže pomocí takzvaných Injectors, takže je v teoretické rovině možné provádět testy s nekonečně mnoho virtuálními uživateli. Testovací skripty, testovací scénáře a generování zátěže na všech Injector stanicích jsou centrálně řízeny pomocí grafické konzole. Grinder disponuje sadou předdefinovaných grafů popisujících běh testů a výsledky je také možné uložit do souborů pro jejich další zpracování. V testovacích skriptech lze stejně jako v případě HP LoadRunner definovat transakce ve kterékoliv části skriptu. Tyto transakce je možné měřit a vytvářet s naměřenými daty statistiky. Pro zjednodušení vývoje testovacích skriptů je možné tyto skripty nahrávat pomocí TCP proxy. Nahrávaní skriptů v případě dobré funkčnosti této vlastnosti ušetří nemalé náklady spojené se zdlouhavým manuálním vývojem skriptů. Mezi další vlastnosti tohoto nástroje také patří parametrizace, tedy dynamické vytváření vstupních dat pomocí textových souborů, náhodné vytváření hodnot, databáze nebo výstupů z předešlých iterací testu. Vlastnosti nástroje Grinder je možné obohatit pomocí pluginů, které jsou tímto nástrojem podporovány, nicméně není jich mnoho19. 4.2.1.1

Klady

Testovací nástroj Grinder podporuje bezesporu velkou sadu protokolů, které hlavně v době 19 ASTON PHILIP, FITZGERALD CALUM: The Grinder, a Java Load Testing Framework [online]. 2013. [cit. 20.04.2014]. Dostupné z URL: .

22

vzrůstajícího počtu aplikací vyvíjených v programovacím jazyku JAVA dokáží pokrýt potřeby většiny nově vyvíjených enterprise aplikací. Mezi silné stránky tohoto nástroje také patří schopnost distribuce zátěže, dynamická parametrizace a centralizované zpracování výsledků. V případě potřeby je možné pomocí pluginů nástroj přizpůsobit potřebám projektového týmu. 4.2.1.2

Zápory

Mezi mínusy nástroje Grinder lze uvést skriptovací jazyky, které zvyšují nároky na dovednosti testovacích týmů a zjevně nedostačující zpracování výsledků, které jsou v enterprise prostředí obzvláště důležité. Nároky na vývoj testovacích skriptů mohou být vyváženy díky možnosti nahrávaní skriptů pomocí TCP proxy, nicméně bez ručních zásahů do testovacích skriptů se testovací tým neobejde. Poslední verze nástroje Grinder byla uvolněna koncem roku 2012. Otázkou tedy je, v jakém rozsahu vývojový tým pracuje na jeho aktualizaci. 4.2.2

JMeter

JMeter je svým využitím velice podobný nástroji Grinder s tím rozdílem, že pro výrobu testovacích skriptů není potřeba v podstatě skoro žádná znalost skriptovacího jazyka. Jedná se spíše o výběr a spojování dostupných jakýchsi „mikro“ částí neboli elementů a jejich konfiguraci. Samozřejmě tomu tak není zcela ve všech případech, jelikož například SQL příkazy musí být stále připraveny ručně. I v případě nástroje JMeter je možné automatické nahrávaní skriptů pomocí TCP proxy. Možností distribuce zátěže se JMeter a Grinder velice podobají, kromě použitého názvosloví. Zatímco v případě nástroje Grinder se jedná o Konzoly a Injektory, v případě nástroje JMeter se jedná o Master a Slave stanice. Co se týče protokolů a dalších technologií, které je možno tímto nástrojem testovat, se také jedná o velice podobný seznam s jediným rozdílem, a to s tím, že JMeter navíc pokrývá databázi MongoDB, která je v dnešní době hojně používána. Nástroj JMeter se těší velké popularitě mezi komunitou testerů, což má za následek časté aktualizace nástroje a velice dobře popsané funkcionality a návody, jak jej využít. Mezi další výhody popularity tohoto nástroje patří fakt, že je na Internetu dostupné velké množství rozšíření takzvaných pluginů, které zásadně vylepšují a zjednodušují použití v enterprise prostředí. Stejně jako Grinder je tento nástroj multiplatformní, což znamená, že je možné jej spustit na operačních systémech Windows,

23

Unix/Linux nebo Mac OS X20. 4.2.2.1

Klady

Mezi hlavní klady tohoto nástroje patří jeho vývojové prostředí a samotný vývoj testovacích skriptů, který nevyžaduje dovednosti zkušeného programátora. Další silnou stránkou je jeho popularita a množství dostupných informací a rozšíření, které usnadňují upravení testovacích skriptů dle potřeb projektu. Reporty, analýza výsledků a také monitoring serverů jsou i díky dostupným rozšířením na vysoké úrovni21. 4.2.2.2

Zápory

Záporů nebylo na první pohled objeveno mnoho až na fakt, že na rozdíl od nástroje Grinder nástroj JMeter nedokáže definovat transakce na úrovni kroků v testovacím skriptu. To může kvůli nepřehledným výsledkům záporně ovlivňovat nároky na ladění výkonu aplikace. 4.2.3

SoapUI

SoapUI je velice oblíbený nástroj pro testování webových služeb využívajících hlavně protokolů SOAP a REST. Nástroj je určen hlavně pro funkční testování webových služeb, nicméně je v něm možné spouštět i výkonnostní testy. Je nutno dodat, že právě proto, že nástroj není primárně určen k výkonnostnímu testování, postrádá mnoho užitečných a někdy až potřebných funkcionalit, jako je například distribuované testování a kvalitní grafické zpracování výsledků testů. Tento fakt nicméně společnost SmartBear, která nástroj vyvíjí, napravuje integrací s jejich dalším nástrojem pro výkonnostní testování LoadUI, který bude popsán v následující kapitole. Protokolů, které SoapUI nástroj podporuje, není mnoho. Konkrétně se jedná o protokoly HTTP/S, SOAP, REST, JMS, AMF a JDBC. Na druhou stranu nástroj disponuje možností vytvoření si takzvaných Mockup služeb, které simulují webovou službu a na základě určitých vstupů vracejí předem definované výstupy. Takto je možno testovat i webové služby, které ještě nebyly vyvinuty nebo k nim není možný přístup z jakýchkoliv jiných důvodů. Nástroj SoapUI také poskytuje velice jednoduchou automatizaci testů. SoapUI je dostupný ve dvou verzích, a to v open source licenci nebo v placené verzi SoapUI PRO, která disponuje větším počtem funkcionalit a také jednodušším ovládáním. Nástroj je možné obohatit další sadou funkcionalit, kterých 20 APACHE SOFTWARE FOUNDATION: Apache JMeter [online]. 2014. [cit. 20.04.2014]. Dostupné z URL: . 21 POKHILKO ANDREY et al: Custom Plugins for Apache JMeter [online]. 2014. [cit. 20.04.2014]. Dostupné z URL: .

24

je v současné době díky popularitě nástroje mnoho22. 4.2.3.1

Klady

Mezi klady tohoto nástroje lze řadit možnost vytvoření Mockup služeb, díky kterým je možné tento nástroj využít pro testování výkonnosti jednotlivých komponent již v ranní fázi vývoje software a odhalit tak úzká hrdla mnohem dříve, než je aplikace připravena k celkovému testování. Díky úzké specializaci na testování protokolů SOAP a REST má tento nástroj mnoho rozšiřujících funkcionalit ulehčujících práci s těmito protokoly. Také možnost rozšíření díky mnoha pluginům uživatelé zcela jistě uvítají. 4.2.3.2

Zápory

Velkým záporem tohoto nástroje je fakt, že není primárně učen pro výkonnostní testování a neposkytuje tak mnoho pro tyto účely potřebných funkcionalit, jako je například distribuce zátěže nebo možnost vytvářet komplikovanější testovací scénáře. Dalšími zápory pak je malé množství protokolů, které lze tímto nástrojem testovat, a také omezení funkcionalit v open source verzi. Zpřístupnění všech služeb by již bylo za poplatek a tím pádem se nejedná o open source nástroj, kterého analýza by byla předmětem této práce. 4.2.4

LoadUI

Na rozdíl od nástroje SoapUI je nástroj LoadUI od stejné společnosti určen výhradně pro výkonnostní testování. Tento nástroj dokáže testovat skoro stejnou sadu protokolů jako jeho již zmíněný kolega SoapUI. Jedná se o protokoly HTTP/S, SOAP, REST, JMS, AMF, JDBC s jediným rozdílem, kterým je protokol POX. Testovací scénáře se v nástroji LoadUI ovládají pomocí netradičního uživatelského rozhraní založeného na táhnout a pustit23 principu. Je to v porovnání s ostatními nástroji analyzovanými v této práci velmi originální řešení nicméně je to také řešení, které nemusí každému zcela vyhovovat. Tak jako SoapUI i LoadUI je dodáván ve dvou licenčních verzích. Open source verze není pro použití v enterprise prostředí zcela vhodná vzhledem k faktu, že důležité funkcionality jako jsou distribuce zátěže a monitoring serverů nejsou v této verzi zpřístupněny. Naopak placená verze tohoto nástroje poskytuje i jiné velice užitečné funkce, jako je například porovnání se skutečnými hodnotami z produkčních systémů24. 22 SMARTBEAR SOFTWARE: SoapUI [online]. 2014. [cit. 26.04.2014]. Dostupné z URL: . 23 Z anglického výrazu Drag&Drop. 24 SMARTBEAR SOFTWARE: LoadUI [online]. 2014. [cit. 26.04.2014]. Dostupné z URL: .

25

Open source verze nástroje LoadUI již není z oficiálních míst k dispozici. Dostupná je již pouze PRO verze nástroje. 4.2.4.1

Klady

Velkým kladem nástroje je jeho velmi dobrá integrace s nástrojem SoapUI, což ušetří hodně času, který by jinak byl potřebný k přípravě testovacích scénářů. V LoadUI je možné spustit už případně existující a funkční sadu testů z nástroje SoapUI. 4.2.4.2

Zápory

Zcela zásadním záporem nástroje LoadUI je jeho velmi omezené použití v open source verzi. Další nevýhodou může být netradiční rozhraní, které nemusí vyhovovat všem uživatelům. 4.2.5

OpenSTA

OpenSTA je nástroj pro distribuované výkonnostní testování umožnující testování HTTP/S protokolů. Tento nástroj disponuje možností automatického nahrávaní skriptů, které je pak možné hned použít při generování souběžné zátěže25. Údaje z průběhu testů i po jeho ukončení je možné sledovat nebo analyzovat přímo v uživatelském rozhraní nástroje. OpenSTA nástroj je distribuován jako open source nástroj a nemá žádné skryté placené funkcionality, jako je tomu u předešlých dvou nástrojů. OpenSTA je možné nainstalovat a spustit jenom na operačním systému Windows. 4.2.5.1

Klady

Mezi silné stránky tohoto nástroje zcela jistě patří automatické nahrávaní skriptů, možnost distribuce zátěže a fakt, že jsou všechny funkcionality nástroje dostupny z jednoho místa. 4.2.5.2

Zápory

Naopak za slabé stránky lze považovat značně omezený seznam podporovaných protokolů. Nevýhodou také může být velmi sporadický vývoj. Poslední stabilní verze byla vydána koncem roku 2007 a na domovských stránkách tohoto projektu není k nalezení žádná zmínka o uvolnění novější verze.

25 CYRANO: OpenSTA user Home [online]. 2013. [cit. 26.04.2014]. Dostupné z URL: .

26

Tabulka 2: Přehled vlastností všech nástrojů Nástroj/Parametr Poslední verze Poslední aktualizace Aktivní vývoj Typ licence GUI

Grinder 3.11 25.10.2012 Ano BSD Ano

JMeter 2.13 13.03.2015 Ano Apache License Ano

Programovací jazyk

Jython

GUI, Java

Nahrávání skriptů Monitoring serverů Zpracování výsledků Grafické reporty Distribuce zátěže

Ano Ne Ano Ne Ano

Podporované protokoly

Operační systém Podpora Domovská stránka

SoapUI LoadUI 5.1.2 2.726 05.09.2014 29.04.2014 Ano Ano EUPL EUPL Ano Ano XML, Groovy, XML, Groovy, Java Java Ne Ne Ne Ne Ano Ano Ano Ano Ne Ne

Ano Ano Ano Ano Ano HTTP, HTTPS, SOAP, FTP, SOAP, REST, JDBC, LDAP, JMS, SMTP(S), SOAP, REST, HTTPS(S), LDAP, HTTP(s), POP3(S), IMAP(S), HTTP(s), AMF, POP3, FTP, SMTP AMF, JDBC, MongoDB, Nativní příkazy JDBC, JMS JMS nebo shell scripts, TCP Windows, Windows, Windows, Linux Windows, Linux Linux, Mac Linux, Mac Mailing list Wiki Ne Ne http://grinder.sour ceforge.net/

https://jmeter.apache.org/

OpenSTA 1.4.4 19.10.2007 Ne GPLv2 Ano

LoadRunner 12.02 21.01.2015 Ano Proprietární Ano

SCL

ANSI-C, Java, .NET

Ano Ano Ano Ano Ano

Ano Ano Ano Ano Ano

HTTP(S)

http://h20195.www2.hp.c om/V2/GetPDF.aspx %2F4AA13191ENW.pdf

Windows

Windows

Ano http://hp.com/us/en/softw http://www.soa http://www.load http://opensta. are-solutions/loadrunnerpui.org/ ui.org/ org/ load-testing/

Zdroj: Vlastní zpracování27 26 Poslední open source verze. 27 Poslední aktualizace 09.04.2015.

27

Mailing list

5. Závěr teoretické části I přesto, že nástroje od společnosti SmartBear (SoapUI a LoadUI) jsou na první pohled vyzrálé aplikace, je použití jejich open source verzí pro výkonnostní testování složitých testovacích scénářů v enterprise prostředí nevyhovující, a to zejména z toho důvodu, že jim chybí hlavní funkcionality, jako je distribuovaná zátěž nebo grafická analýza a zpracování výsledků. Navzdory těmto omezením by bylo možné tyto nástroje využít v průběhu vývoje software pro izolované výkonnostní testování jednotlivých komponent. Ostatní analyzované nástroje i přes některé jiné záporné vlastnosti aspoň jednu z těchto funkcionalit nabízejí a jsou tedy možným kandidátem pro nahrazení komerčních nástrojů. V následujících částech bude cílem této práce prakticky vyzkoušet a analyzovat vývoj, nastavení a spuštění testovacích skriptů a scénářů, stejně tak jako zpracování výsledků testování v nástrojích Grinder, JMeter a OpenSTA. Tyto nástroje pak budou porovnávány s referenčním nástrojem LoadRunner od společnosti Hewlett-Packard. Součástí analýzy bude také zhodnocení všech nástrojů a případná definice podmínek, za jakých je tyto nástroje možné použít v enterprise prostředí.

28

6. Praktická část Cílem této části je praktické vyzkoušení a analyzování vybraných nástrojů a jejich porovnání se zavedeným komerčním nástrojem HP LoadRunner. Na úvod této části bude definována testovaná aplikace, testované prostředí, testovací scénáře, požadavky na výkon a sledované hodnoty. Následovat bude samotné plnění cílů výkonnostního testování za použití vybraných nástrojů a následné zhodnocení jejich naplnění. Hodnotit se bude na základě složitosti použití nástroje, jeho ergonomie, možnosti nahrávaní testovacích skriptů, popřípadě náročnosti ručního vytváření skriptů. Sledovaná bude také hardwarová náročnost každého nástroje a v neposlední řadě schopnosti měření různých předem definovaných hodnot. Všechny nástroje analyzované v této části práce prošly technologickým testem v rámci teoretické části, ve které byly analyzovány nástroji podporované protokoly.

6.1. Definice prostředí a cílů 6.1.1

Testovaná aplikace

Aplikace pojmenovaná blueFruits, která bude předmětem testování, simuluje jednoduchou obchodní logiku hlavního skladu společnosti, jež vlastní síť velkoobchodů a maloobchodů s ovocem a zeleninou. Aplikace slouží jako kanál pro objednávání ovoce a zeleniny jejím pobočkám, které jsou rozmístěny po celém světě. Pro jednoduchost aplikace předpokládá, že zásoby ovoce a zeleniny jsou neomezeny a každá pobočka si může objednat stejné produkty. Reální obchodní logika by byla zcela jistě více komplikovaná. Pro účely této práce ale takto jednoduchý model postačí. Aplikace je složena ze dvou vrstev, a to z aplikační a perzistentní vrstvy. Aplikační uživatelské rozhraní je vyvinuto v programovacím jazyku PHP5, který je spouštěn nad Apache2 webovým serverem. Uživatelské rozhraní je obohaceno jednoduchou webovou službou napsanou v jazyce Java, která je spuštěná na webovém serveru Apache Tomcat. Perzistentní vrstva je zabezpečena relační databází MySQL. Testovaný systém je vybudován na operačním systému Debian Linux. Uživatelské rozhraní nabízí možnost objednání ovoce a zeleniny, jež jsou přidávány do nákupního košíku tak, jak je tomu ve většině běžných internetových obchodech. Každý košík neboli objednávka má datum doručení, který si uživatel může zvolit při jeho 29

prvotním zakládaní. Pro ukončení objednávky je nutné, aby uživatel košík uzavřel. Další možností aplikace je zobrazení všech košíků uživatele a jejich obsahu bez rozdílu, jaký je jejich historický stav. Zobrazení obsahu košíku je vyvinuto pomocí technologie AJAX, která byla do aplikace přidána záměrně. Pro přístup do webového rozhraní aplikace je nutné, aby se uživatel autentizoval. Dalším rozhraním aplikace je již zmíněná webová služba, poskytující dvě operace. Operace getAll vrací všechny produkty (ovoce a zeleninu) z databáze a operace insertItem vloží produkt do definovaného košíku, stejně jako kdyby byl vložen přes webové uživatelské rozhraní. Webové služby jsou veřejně přístupny a není nutná další autentizace uživatelů. Tento komunikační kanál je určen především operátorům pro přijímání telefonických objednávek. Uvedená jednoduchá aplikace byla vyvinuta pouze pro účely této práce a jejím jediným úkolem je sloužit jako objekt výkonnostního testování. Testovaná aplikace v podobě webového portálu a webových služeb byla vybraná záměrně z toho důvodu, že v dnešní době jsou tyto technologie často používány v enterprise prostředí a také často nahrazují již zastaralé terminálové nebo takzvané „thick“ klienty. Tyto technologie jsou také velmi častým cílem výkonnostního testování. Zvolená architektura a technologie nicméně nedovolují praktické vyzkoušení všech nástroji podporovaných protokolů a omezují se na HTTP/S, SOAP a JDBC. Tabulka 3: Shrnutí použitích technologií v testované aplikaci Komponenta

Použitá technologie

Operační systém

Debian Linux

Webový server

Apache2

Servlet

Apache Tomcat

Databáze

MySql

Webový portál

PHP5, AJAX

Webová služba

Java Zdroj: Vlastní zpracování

6.1.2

Testovaná platforma

Testovaná aplikace běží na virtuálním serveru s 32-bitovým operačním systémem Debian Linux. Virtualizace je zabezpečena pomocí nástroje VMware v jeho bezplatné verzi Player28. Hostující virtuální server používá 512MB paměti a jedno jádro výpočetní 28 VMWARE INC.: All Downloads [online]. 2015. [cit. 28. 02. 2015]. Dostupné z URL:

30

jednotky CPU s taktem 2.5GHz. Hostující operační systém je nainstalován bez pracovní plochy kvůli úspoře zdrojů a také kvůli diskovému prostoru. Na druhou stranu bylo systému přiděleno málo operační paměti zcela záměrně. Cíl je, aby bylo při výkonnostním testování možné narazit na úzké hrdlo aplikace. Celý virtuální server zabírá zhruba 2GB prostoru, což ulehčuje jeho obnovu do původního stavu. To je velice důležité pro analýzu testovacích nástrojů a zabezpečení relativní objektivity výsledků, protože každý test bude spouštěn oproti naprosto stejnému obrazu virtuálního serveru. 6.1.3

Testovací platforma

Příprava, spuštění a analýza výsledků výkonnostního testování bude prováděna na přenosném počítači s procesorem Intel Core i5 o frekvenci 2.50GHz a 4 GB operační pamětí. Operačním systémem testovací platformy je 64 bitový Windows 7 Profesional. Tato platforma je zároveň i hostitelem virtuálního stroje, na kterém běží instance testované platformy. 6.1.4

Uživatelské skupiny

Aby bylo možné naplnit cíle výkonnostního testování, je nutné je nejdříve stanovit. Pro stanovení cílů je potřebné pochopit obchodní logiku, kterou testovaná aplikace poskytuje. Dále je potřeba znát zainteresované strany a také uživatelskou základnu. V neposlední řadě je potřebné definovat uživatelské skupiny, jež poskytují informace o vzorcích užití navrhovaného systému29. Základní funkcionalita systému již byla popsána výše. Uživatelé systému mohou být rozděleny na běžné uživatele, manažery a operátory. Běžní uživatelé přistupují k aplikaci přes webové rozhraní, ve kterém po autentizaci provádí nákup ovoce a zeleniny, přidávají je do již existujících nebo nově vytvořených košíků. Obsah neuzavřených košíků si mohou kdykoliv prohlídnout. Poslední možnou uživatelskou akcí je uzavření objednávky, kterou uživatel košík uzamkne a nelze s ním již více operovat. Druhou skupinou uživatelů jsou manažeři, kteří nemají zájem pro přímý přístup do aplikace. Více je zajímají data uložená v databázi, které pro ně mají velikou hodnotu z důvodů kontroly pohybu materiálu, monitorování aktivit poboček obchodů a pro ostatní vnitropodnikové účely. Tato skupina uživatelů přistupuje k datům aplikace pomocí . 29 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str 89.

31

externích aplikací používajících přímý přistup k databázi pomocí JDBC nebo ODBC. Jedná se tedy hlavně o vzdálené spouštění PL/SQL skriptů. Poslední skupinou uživatelů jsou operátoři, kteří jsou zodpovědní za přijímání objednávek přes telefon. Pro tyto účely používají velice jednoduchou externí aplikaci, která s testovanou aplikací komunikuje pomocí webových služeb, využívajících SOAP protokol. Úkolem operátorů je přidávání produktů do již existujících, ale neuzavřených košíků. Tabulka 4: Shrnutí uživatelských skupin Uživatelská skupina

Komunikační protokol

Běžní uživatelé

HTTP/S

Manažeři

JDBC nebo ODBC

Operátoři

SOAP Zdroj: Vlastní zpracování

6.1.5

Testovaná zátěž

V předchozí kapitole byli definovány uživatelské skupiny aplikace, které je ještě nutné obohatit informací o uživatelské základně. Uživatelská základna je počet uživatelů používajících testovanou aplikaci30. Jestli je tento počet jenom odhad, skutečný počet uživatelů, kteří již používají jinou aplikaci, nebo je to budoucí předpokládaný počet uživatelů, není pro účely této práce podstatné. Podstatné je stanovit si počet uživatelů a jejich rozložení do skupin pro účely definování jednoznačného cíle, který bude plněn každým z analyzovaných nástrojů. Z dříve definovaných uživatelských skupin bude aplikaci nejvíce používat skupina běžných uživatelů, reprezentována až 1000 unikátních uživatelů používajících aplikaci ve stejnou chvíli. Manažerů používajících JDBC nebo ODBC pro přístup do databáze bude až 100 a skupina operátorů bude dosahovat maximálně 100 uživatelů využívajících zároveň webovou službu aplikace. 6.1.6

Požadavky na výkon

Jedním z cílů výkonnostního testování prováděného analyzovanými nástroji je zjistit, zda je testovaná aplikace schopna s použitím výše definovaných scénářů a počtem uživatelů dosahovat určitých maximálních přípustných časů transakcí. Stanovení maximálních přípustných časů a jiných akceptačních kritérií není triviální úkol a je potřeba oslovit 30 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str 84-85.

32

všechny zainteresované strany projektu. Tato analýza je zcela nezbytná a je součástí přípravní fáze31. V následující tabulce jsou definovány maximální přípustné časy všech sledovaných transakcí, doplněné o maximální počty uživatelů používajících testovanou aplikaci ve stejnou chvíli. Tabulka 5: Požadavky na výkon aplikace z pohledu transakcí Uživatelská skupina Počet paralelních uživatelů

Transakce

Maximální akceptovatelný čas transakce v milisekundách

Běžný uživatel

Přihlášení

500

Seznam produktů

500

Výběr produktů

500

Výběr košíku

500

Vytvoření nového košíku

2000

Zobrazení obsahu košíku

2000

Uzavření objednávky

2000

Odhlášení

500

1000

Manažeři

100

Zobrazení obsahu košíků

5000

Operátoři

100

Zobrazení všech produktů

300

Přidání produktu do košíku

500


Testovací scénáře

V této kapitole jsou definovány testovací scénáře, které budou sloužit pro simulaci skutečného provozu aplikace. Uživatelské skupiny, transakce, zátěž a požadavky na výkon již byly stanoveny. Teď je potřeba s jejich pomocí a pomocí uživatelských časů přemýšlení definovat přesné scénáře, které budou plněny nástroji pro výkonnostní testování. Při definování testovacích scénářů je nutné vzít v úvahu skutečnost, že ne každý uživatel potřebuje stejný čas na přemýšlení. Vzhledem k tomu, že tento čas není možné přesně 31 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str 94-94.

33

stanovit, budou definovány jejich rozsahy. Úkolem testovacích nástrojů pak bude náhodně se pohybovat v těchto rozsazích. Testovací scénář číslo 1 bude prováděn virtuálními uživateli simulujícími běžné uživatele. Prvním krokem bude provedení transakce Přihlášení, po které budou uživatelé vybírat ovoce a zeleninu ze seznamu všech produktů a poté je dají do košíku. Čas přemýšlení, tedy výběr produktů, se bude pohybovat v rozmezí 20 až 30 sekund. Druhou transakcí bude Potvrzení výběru produktů, která po jejím vykonání vezme uživatele do obrazovky výběru košíku. Zde uživatel stráví přemýšlením 3 až 5 sekund a následně provede transakci Vytvoření nového košíku. Aplikace po úspěšném vykonání této transakce přesměruje uživatele na seznam všech košíků, kde uživatel stráví 3 až 5 sekund hledáním košíku, jehož obsah si zobrazí vykonáním transakce Zobrazení obsahu košíku. Uživatel si po kontrole obsahu, který mu bude trvat 8 až 12 sekund, uvědomí, že něco zapomněl, a tak se bude muset vrátit do obrazovky výběru produktů vykonáním transakce Seznam produktů. V seznamu produktů uživatel sjedná nápravu a během 10 až 15 sekund vykoná opětovné zavolání transakce Potvrzení výběru produktů, která jej přesměruje do obrazovky výběru košíku, kde znovu stráví 3 až 5 sekund. Poté co si uživatel vybere správný košík, potvrdí toto spuštěním transakce Potvrzení výběru košíku a bude opět přesměrován do seznamu všech košíku, kde stráví 3 až 5 sekund výběrem košíku, který by rád uzavřel transakcí Uzavření objednávky. Po vykonání této transakce bude uživateli zobrazen seznam všech produktů v košíku a celková cena objednávky. Zde stráví uživatel 5 až 10 sekund. Poté se odhlásí provedením transakce Odhlášení. Testovací scénář 2 již nebude tak komplikovaný vzhledem k tomu, že simuluje uživatelskou skupinu manažerů, kteří do aplikace přistupují přes JDBC/ODBC jenom za účelem Zobrazení obsahů košíků jednotlivých uživatelů. SQL výraz použitý pro tyto účely je záměrně neoptimalizován a jsou v něm obsaženy na výpočet náročné operace, jako je například operace ORDER. Uživatel ze skupiny manažer používá tuto transakci každých 50 až 70 sekund, pokaždé pro zobrazení obsahu košíku jiného běžného uživatele. Testovací scénář 3 slouží k simulaci operátorů, kteří do aplikace přistupují z jiné aplikace, sloužící k přístupu k datům testované aplikace pomocí SOAP protokolu. První transakcí, kterou operátoři spouštějí, je Zobrazení všech produktů pomocí webové služby ContentManagerService a operace getAll. Po obdržení seznamu všech produktů trvá

34

zhruba 7 až 9 sekund, než z něj vyberou produkt, který si volající přeje přidat do jeho košíku. Poté je volána transakce Přidání produktu do košíku pomocí operace insertItem stejné webové služby. Tabulka 6: Shrnutí kroků testovacích scénářů Testovací scénář Scénář 1

Krok Přihlášení Čas přemýšlení (20 až 30 sekund) Potvrzení výběru produktů Čas přemýšlení (3 až 5 sekund) Vytvoření nového košíku Čas přemýšlení (3 až 5 sekund) Zobrazení obsahu košíku Čas přemýšlení (8 až 12 sekund) Seznam produktů Čas přemýšlení (10 až 15 sekund) Potvrzení výběru produktů Čas přemýšlení (3 až 5 sekund) Potvrzení výběru košíku Čas přemýšlení (3 až 5 sekund) Uzavření objednávky Čas přemýšlení (5 až 10 sekund) Odhlášení

Scénář 2

Zobrazení obsahu košíků Čas přemýšlení (50 až 70 sekund)

Scénář 3

Zobrazení všech produktů Čas přemýšlení (7 až 9 sekund) Přidání produktu do košíku Zdroj: Vlastní zpracování

6.1.8

Scénáře zátěže

Poslední částí, která musí být definována předtím, než budou testovací nástroje použity a analyzovány, jsou scénáře zátěže. Jedná se tedy o definování toho, kolik virtuálních uživatelů a jaké testovací scénáře budou tito uživatelé spouštět v určitém časovém okamžiku. Díky použití takzvaného LESS přístupu budou definovány scénáře, jež budou

35

nástroji pro výkonnostní testování naplňovány. V akronymu LESS označuje první písmeno L anglický výraz Load Test, E Endurance Test, první S Stress Test a druhé S Spike Test. Přístup LESS je více specifikován v publikaci Integrated Approach to Web Performance Testing: A Practitioner's Guide32. Pro účely porovnání testovacích nástrojů postačí dva z těchto přístupů a to Load Test a Stress Test. Cílem Load testu, neboli zátěžového testu, je zjistit, zda je výkon testované aplikace pod předpokládanou zátěží akceptovatelný vzhledem k předem identifikovaným akceptačním kritériím. Cílem Stress testu je zjistit, pod jakou zátěží se výkon testované aplikace nebo systému drasticky zhorší, či zda systém dokonce zkolabuje33. Pro účely Load testu bude použito 1200 virtuálních uživatelů s rozložením testovacích scénářů tak, jak je definováno v sekci 6.1.6. Virtuální uživatelé budou v tomto zátěžovém scénáři přistupovat k testované aplikaci každou sekundu v dávkách 2 uživatelů. Nárůst počtu uživatelů až k požadovanému předpokládanému množství bude trvat zhruba 8 minut. Zátěžový scénář pak bude pokračovat s tímto množstvím uživatelů po dobu 1 hodiny. Po uplynutí testovacího času se všichni uživatelé od aplikace odpojí zároveň. Takovýto scénář byl zvolen právě proto, že 1200 je maximální odhadovaný počet uživatelů používajících testovanou aplikaci zároveň. Pracuje se s předpokladem, že naměřené hodnoty budou stejné, ne-li lepší v případě využití aplikace méně uživateli. Následující ilustrace graficky znázorňuje, jak bude tento zátěžový scénář vypadat.

32 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850. 33 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str 14-20.

36

Ilustrace 3: Load test scénář 1400


1200 1000 800 600 400 200 0 Čas v minutách

Zdroj: Vlastní zpracování Scénář Stress testu půjde o krok dále a bude v určitých intervalech počet virtuálních uživatelů zvyšovat. Pro prvotní náběh uživatelů bude použito stejného scénáře jako v Load testu. Test bude běžet s předpokládaným počtem uživatelů po dobu 10 minut a poté bude přidáno dalších 100 uživatelů. 1 uživatel za sekundu. Poté bude test pokračovat dalších 10 minut. Po uplynutí tohoto intervalu bude opět přidáno 100 uživatelů stejným způsobem jako v předešlé iteraci. Takto se navyšování uživatelů bude opakovat až do doby, kdy bude výkon testované aplikace viditelně degradovat. Tímto způsobem se determinuje maximální počet uživatelů, pod kterým je testovaná aplikace ještě schopna udržet požadovaný výkon. Následující ilustrace graficky zobrazuje, jak bude Stress test scénář vypadat za předpokladu, že testovaná aplikace vydrží dosahovat akceptovatelné výkonnosti po dobu 4 iterací zvyšování zátěže.

37

Ilustrace 4: Stress test scénář 1800


1600 1400 1200 1000 800 600 400 200 0

Čas v minutách


Sledované hodnoty

Z důvodu naplnění cílů testování je nutné definovat, které hodnoty, neboli KPI (Key Performance Indicator), budou sledovány. Vzhledem k cílům stanovených v sekci 6.1.6 Požadavky na výkon je zcela nevyhnutelné sledovat časy odezev všech testovaných transakcí. Tyto časy budou sledovány v průběhu celé realizace testů a budou zaznamenávány vzhledem k počtu právě přihlášených virtuálních uživatelů a vzhledem k času trvání testování. Mezi další sledované hodnoty budou patřit počty úspěšných a neúspěšných transakcí, propustnost v počtu transakcí a velikosti přenesených dat a 90 percentil odezvy transakcí. Pro úspěšné odhalení úzkých hrdel aplikace a jejich odstraňování laděním a dimenzováním je nutné také sledovat využití zdrojů stanic pod zátěží, jako je výpočetní jednotka (procesor), fyzická operační paměť (RAM), virtuální operační paměť, vstupně/výstupní operace, vytížení sítě, a protože testovaná aplikace používá Java servlet, který běží v JVM, bude také sledována hodnota heapsize34. Využití zdrojů nebude sledováno pouze na testovaných stanicích, ale také na stanicích, které zátěž generují.

34 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str 161.

38

V tomto případě se bude sledovat hlavně využití procesoru a fyzické operační paměti35. Tabulka 7: Shrnutí sledovaných hodnot při vykonávání výkonnostního testování Skupina Metriky výkonnosti

Sledovaná hodnota Časy odezev transakcí vzhledem k počtu virtuálních uživatelů. Časy odezev transakcí vzhledem k času trvání testu. Počet úspěšných a neúspěšných transakcí. Propustnost v počtu transakcí za určitý čas. Velikost přenesených dat. 90 percentil odezvy transakcí.

Využití zdrojů testované stanice

Využití procesoru. Využití fyzické a virtuální operační paměti. Vstupně/výstupní operace. Vytížení sítě. Využití heapsize.

Využití zdrojů testovací stanice

Využití procesoru. Využití fyzické a virtuální operační paměti. Zdroj: Vlastní zpracování

6.2. HP LoadRunner Z důvodu nedostupnosti komerční licence k produktu HP LoadRunner byla pro účely této práce použita volně dostupná zkušební licence, která sice dovoluje použíti všech funkčností tohoto produktu, nicméně omezuje maximální počet virtuálních uživatelů na 50. 6.2.1

Instalace nástroje

Instalace nástroje HP LoadRunner se iniciuje spuštěním instalační aplikace, která uživatele provází celou instalací produktu tak, jako je tomu u většiny instalačních průvodců aplikací určených pro operační systém Windows. V případě chybějících komponent potřebných pro běh nástroje HP LoadRunner si instalační průvodce bez jakýchkoliv problémů poradí s jejich dodatečnou instalací. Po instalaci a kontrole všech potřebných závislostí se instalační průvodce dále postará o bezproblémové nainstalování všech čtyř komponent potřebných k úspěšnému použití nástroje LoadRunner. Tyto komponenty jsou Analyses, která slouží, jak název napovídá, k analýze výsledků testování, dále Controller, která slouží 35 SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850, str 212-213.

39

ke spouštění, monitorování a řízení testů, Virtual User Generator, která slouží k tvorbě testovacích skriptů a Load Generator, která slouží k simulování virtuálních uživatelů generujících zátěž36. Součástí instalace jsou také četné dokumentace, mezi něž patří velice rozsáhlá uživatelská příručka a sada dalších užitečných nástrojů, jakým je například Protocol Advisor37, sloužící k identifikaci protokolů vhodných pro použití při vytváření testovacích skriptů. Součástí instalace zkušební verze nástroje je i jednoduchý webový portál HP Web Tours simulující cestovní agenturu. Tento portál je možno použít k neprodlenému vyzkoušení si všech základních funkcionalit nástroje HP LoadRunner za pomocí tutoriálu, jenž je součástí instalace produktu38. 6.2.2

Vývoj testovacích skriptů

K vývoji testovacích skriptů v nástroji HP LoadRunner slouží komponenta Virtual User Generator, často také zkráceně označována jako VuGen. Výchozím programovacím jazykem je v tomto vývojovém prostředí jazyk C. Tento jazyk je použit také při automatickém vytváření skriptů pomocí funkce nahrávaní. Při vývoji testovacích skriptů není nezbytně nutné programovací jazyk C ovládat, jelikož ve většině případů si vývojář vystačí s proprietárními funkcemi, které začínají prefixem lr_. Všechny funkce jsou dostatečně popsány v referenční příručce, která je z vývojového prostředí přístupná pomocí klávesy F1. Skripty je možné vyvíjet také v dalších jazycích, jako je například Java nebo .NET. Pro účely této práce jsou skripty vyvíjeny v nástroji preferovaném jazyce, kterým je jazyk C. Složitost vývoje skriptů je závislá na tom, který z podporovaných protokolů je použit. Pro potřeby naplnění cílů definovaných v předešlé kapitole je zapotřebí využití následujících tří podporovaných protokolů, a to HTTP/HTML pro scénář simulující běžné uživatele, Web Services pro scénář simulující operátory a ODBC pro přístup k databázi potřebný pro scénář simulující manažery. V případě, že není vývojářům zcela jasné, který z podporovaných protokolů by měl být pro daný scénář použit, je možno využít nástroj 36 HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.: Tutorial [offline pdf]. 2015. [cit. 28.02.2015]. Dostupné z . Str 6-7. 37 HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.: LoadRunner User Guide [offline pdf]. 2015. [cit. 28.02.2015]. Dostupné z . Str 152-155. 38 HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.: Tutorial [offline pdf]. 2015. [cit. 28.02.2015]. Dostupné z .

40

Protocol Advisor, jehož úkolem je pomocí simulace uživatelských aktivit tyto protokoly identifikovat. Jakmile je správný protokol identifikován, je možné automaticky vytvářet testovací skripty pomocí funkcionality Nahrávaní. Nahrávaní pomocí HTTP/HTML protokolu je velice efektivní a funguje bez jakéhokoliv dodatečného nastavování. V režimu nahrávaní je možné identifikovat začátky a konce transakcí nebo ověření výsledku transakce pomocí hledání výskytu textu na vrácené stránce. Nahrávaní je možno jednoduše pozastavit a znovu spustit pro potřeby vytváření nových akcí testovacího skriptu. Po dokončení nahrávaní jsou automaticky vytvořeny testovací skripty, které je možné hned přehrát a sledovat jejich průběh. Průběh přehrávání lze sledovat přímo ve vývojovém prostředí v textové podobě nebo po jeho dokončení v konsolidovaných výsledcích testu. I přesto, že jsou skripty po nahrání zcela funkční, jejich kontrola a případná modifikace je nezbytná, a to hlavně z důvodu parametrizace testovacích dat. Je potřeba myslet na to, že při spuštění testování bude tyto skripty využívat mnoho virtuálních uživatelů, kteří je budou spouštět vícekrát. Základní parametrizace zajišťující bezpečné spuštění skriptů vícero virtuálními uživateli za využití předdefinovaných funkcí nebo textových souborů je přímočará a jednoduše přístupná z vývojového prostředí. Při vytváření skriptů pomocí Web Services protokolu již není možné využít automatické vytváření skriptů pomocí nahrávání. I přesto je vytváření těchto skriptů jednoduché, a to díky nástroji SOA Tools, který je součástí vývojového prostředí. V tomto nástroji je možné importovat webové služby pomocí WSDL souboru a následně vytvářet kód pro jejich volání z testovacích skriptů. Opět je nutná kontrola skriptů a případná parametrizace. Vytvořené skripty je možné přehrát a sledovat jejich průběh přímo ve vývojovém prostředí. Vytváření automaticky generovaných skriptů pomocí nahrávaní ODBC protokolu již tak přímočaré není. Nejdříve je potřeba nainstalovat si správné ODBC ovladače a klienta, který tyto ovladače použije pro přístup k testované databázi. V tomto případě byl použit open source klient ODBCQueryTool39. Díky zmíněným nástrojům již není problém pomocí funkce nahrávání vytvořit skripty pro přístup do databáze a následného volání SQL výrazů. Vytvořené skripty je opět možné přehrát a malými manuálními úpravami připravit 39 DICE: ODBC Query Tool [online]. [cit. 22. 02. 2015]. Dostupné z URL: .

41

pro následné spuštění vícero uživateli. Ilustrace 5: Uživatelské rozhraní HP Virtual User Generator


Logy

Nastavení úrovně logování je přístupné přes vývojové prostředí Virtual User Generator. Logování se nastavuje na úrovni skriptů a toto nastavení je sdílené pro všechny akce a transakce uvnitř daného testovacího skriptu. V samotném nastavení logování je možné nastavit standardní nebo rozšířené logování s 3 dalšími úrovněmi, logování úplně vypnout nebo jej naopak vynutit. Toto nastavení pak ovlivňuje rozsah informací zobrazených při spuštění skriptu jak ve vývojovém prostředí, tak i v log souborech vytvářených v průběhu spouštění testovacích scénářů. V případě, že je zapotřebí výchozí logování obohatit o uživatelsky vynucené záznamy potřebné k ladění kódu, lepší kontrole nad průběhem testů nebo k zobrazení použitých parametrů, je možné využít specifické funkce LoadRunner, jakou je například lr_log_message.

42

6.2.4

Tvorba testovacích scénářů

Pro vytváření, spouštění a řízení běhu testovacích scénářů je v aplikaci HP LoadRunner určena komponenta Controller. Tato komponenta je rozdělena na tři záložky; Design, Run a Diagnostics for J2EE/.NET. Záložka Design, jak již název napovídá, slouží k návrhu testovacích scénářů, které se pak spouští a řídí v záložce Run. Poslední záložka není v implicitní instalaci aktivována, a proto také není součástí této analýzy. Navrhování testovacích scénářů je opět prováděno v uživatelském rozhraní, které je velice intuitivní a pro jeho ovládání není zapotřebí žádných programátorských dovedností. Pro začátek je potřeba nastavit uživatelské skupiny. Každá skupina je reprezentována testovacím skriptem vyvinutým v předešlé fázi. Dále je pak zapotřebí definovat, kterým generátorem zátěže budou tyto jednotlivé skupiny spuštěny. Poté co jsou tyto skupiny definovány, je možné nastavit jejich chování, respektive průběh vytváření zátěže. Oba cílené scénáře zátěže - jak Load Test, tak i Stress test, které byly definovány v sekci 6.1.8, lze bez větších problémů v tomto prostředí nastavit. Za velice užitečnou funkcionalitu komponenty Controller lze považovat možnost nastavení SLA (Service Level Agreement) hodnot tak, jak byly stanoveny v sekci 6.1.6 Požadavky na výkon. Tyto hodnoty jsou pak považovány za cíle testování a jsou vyhodnoceny jako splněné či nesplněné v závislosti na konečných výsledcích testu. V případě nutnosti modifikace nastavení testovacích skriptů, které jsou součástí právě navrhovaného testovacího scénáře, je možné k těmto nastavením jednotlivě přistupovat přímo ze záložky Design. V případě nutnosti modifikace zdrojového kódu testovacího skriptu je tento kód uživateli zobrazen v komponentě Virtual User Generator. Po uložení změn nastavení skriptů nebo jejich kódu jsou tyto změny okamžitě aktivní i v komponentě Controller. 6.2.5

Spuštění a kontrola průběhu testů

Jakmile jsou testovací scénáře navrženy, je možné je jednoduše kliknutím jednoho tlačítka spustit. Skripty jsou automaticky distribuovány na generátory zátěže a jsou postupně spouštěny přesně tak, jak byly navrženy. Průběh testů je možné sledovat a řídit v přehledném prostředí záložky Run komponenty Controller, kam je uživatel automaticky přesměrován neprodleně po spuštění scénáře. Tato záložka poskytuje informace o virtuálních uživatelích, o jejich počtech a stavech, stejně tak jako o celkovém stavu průběhu testovacího scénáře. V případě nastalých chyb je tento fakt důrazně zvýrazněn 43

a k detailním informacím chyb je možné okamžitě přistupovat. V kontrolní části záložky Run je možné testování zastavit, vynulovat nahromaděné statistiky, kontrolovat stav jednotlivých virtuálních uživatelů nebo manuálně uživatelské skupiny inicializovat, spouštět nebo zastavovat. Průběh testů lze monitorovat pomocí velkého množství dostupných online grafů, které graficky zobrazují informace o počtech virtuálních uživatelů, časech transakcí, využití lokálních a vzdálených hardwarových zdrojů. Vše, co je potřebné k analýze výsledků testování, je v tomto prostředí dostupné i v průběhu samotného testu. Ze sledovaných hodnot definovaných v sekci 6.1.9 tohoto dokumentu komponenta Controller postrádá schopnost monitorování využití operační paměti a využití sítě na stanicích s operačním systémem UNIX/Linux a také monitorování heapsize virtuálního stroje Java. Po skončení nebo vypnutí testování komponenta Controller automaticky sesbírá naměřená data ze všech generátorů zátěže, které je pak možné dále analyzovat v komponentě Analysis. 6.2.6

Analýza výsledků

Výsledky testů je možné podrobněji analyzovat v HP LoadRunner komponentě Analysis, jež je pro dané účely určena. Tato komponenta už ve svém výchozím nastavení poskytuje dostatek informací potřebných k vyhodnocení úspěšnosti či neúspěšnosti testů. V případě dobrých výsledků testů lze tyto výchozí reporty a grafy bez větších modifikací použít k prezentaci zainteresovaným osobám projektu. Pro zmíněné účely lze také využít možnosti automatického generování komplexních reportů, které je možné exportovat do mnoha formátů, jako je například formát PDF, Microsoft Presentation, Microsoft Word nebo HTML. V případě špatných výsledků testů lze tuto komponentu použít k více detailním analýzám testovacích iterací, díky kterým lze lépe izolovat problém nebo nalézt úzké hrdlo aplikace. Tomu také napomůže mnoho přidaných funkcí, které je na tyto grafy možné použít. Mezi ně patří možnost kombinace vícero grafů, změna granularity, nastavování různých filtrů, automatická korelace různých grafů nebo možnost přiblížení nebo oddálení grafů. Následující ilustrace zobrazuje příklad automaticky generovaného shrnutí testu jasně zobrazující naplnění SLA cílů.

44

Ilustrace 6: Shrnutí výsledku výkonnostního testu vytvořeno komponentou Analysis


Plnění cílů

Až na pár výjimek, jako je sledování využití operační paměti, sítě nebo heapsize na vzdáleném serveru s operačním systému Linux, byly všechny cíle výkonnostního testování tak, jak byly definovány v sekci 6.1 tohoto dokumentu, naplněny. Vývoj testovacích skriptů byl až na menší problémy s nahráváním ODBC komunikace zcela bezproblémový a nevyžadoval žádné zvláštní programovací schopnosti. Návrh testovacích scénářů se taky obešel bez větších těžkostí a jejich následné spuštění nevyžadovalo víc než pár kroků ve vývojovém prostředí. Samozřejmě ne všechny testovací skripty fungovaly hned napoprvé a některé z nich bylo nutné ručně doladit. Jednalo se tedy hlavně o parametrizaci a plnění skriptů testovacími daty. Nicméně díky přehlednému a velice informativnímu vývojovému prostředí nástroje HP LoadRunner to nebyl velký problém a skripty se podařilo doladit během pár zkušebních iterací. 6.2.8

Shrnutí

I přes omezení zkušební verze nástroje HP LoadRunner na maximální počet 50 virtuálních uživatelů generujících zátěž je možné s jistotou říci, že až na pár výjimek tento nástroj poskytuje všechno, co tým zodpovědný za výkonnostní testování enterprise aplikací potřebuje. Velkou výhodou je fakt, že pro obsluhu nástroje není zapotřebí žádná specifická specializace jeho uživatelů. Mnoho funkcionalit nástroje lze jednoduše vyzkoušet následováním přiloženého tutoriálu a v případě potřeby řešení komplexnějších problémů pomůže rozsáhlá komunita uživatelů a taky podpora dodavatele, mezi které patří také jejich uživatelské fórum. K největším přednostem nástroje patří zpracování a analýza 45

výsledků testování. Toto je velice důležité pro potřeby prezentování výsledků zainteresovaným osobám, kde také pomůže možnost sledování plnění výkonnostních cílů.

6.3. OpenSTA Před samotnou instalací OpenSTA je nutné si uvědomit, že poslední verze tohoto nástroje byla vydaná koncem roku 2007 a oficiálně podporované operační systémy jsou jenom dva, a to Microsoft Windows 2000 a Microsoft Windows NT 4.0 40. Oba operační systémy jsou velice zastaralé a nejsou již ani podporovány samotným výrobcem těchto operačních systémů. Ze zdrojů dostupných na Internetu je možné zjistit, že OpenSTA je ještě použitelná na dalších dvou operačních systémech, a to Microsoft Windows XP a Microsoft Windows Server 200341. I v tomto případe se, až na výjimku rozšířené podpory Microsoft Windows Server 200342, jedná o již nepodporované operační systémy. Zmíněný fakt se dá sám o sobě považovat za velkou limitaci tohoto nástroje. Jedinou stávající dostupnou možností, jak OpenSTA zprovoznit na testovací platformě s operačním systémem Windows 7, je Windows XP mód. Jedná se vlastně o virtuální operační systém běžícím nad Windows 7 s použitím softwaru Windows Virtual PC 43. Právě v této konfiguraci je nástroj OpenSTA v práci dále analyzován. 6.3.1

Instalace

Už samotná malá velikost instalačního souboru napovídá, že instalace není nikterak zdlouhavá a náročná. Instalační průvodce sestává z pár kroků, které kromě výběru instalačního adresáře neposkytují žádné jiné možnosti výběru. Samotná instalace nástroje OpenSTA trvá jen několik málo sekund a po jejím dokončení je nutný restart operačního systému. Po restartu jsou aktivovány všechny potřebné a na pozadí běžící podpůrné aplikace, jako je například omniNames, Architecture Manager Deamon a OpenSTA Deamon. Tyto aplikace slouží hlavně ke správě a řízení komunikace mezi různými moduly OpenSTA architektury. Mezi ty na první pohled viditelné aplikace, které jsou součástí instalace, patří 40 CYRANO: Getting Started [online]. [cit. 22.02.2015]. Dostupné z URL: . 41 SQAFORUMS.COM: Error opening file for output [online]. [cit. 22.02.2015]. Dostupné z URL: . 42 MICROSOFT CORPORATION: Fáze životního cyklu produktu [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: . 43 MICROSOFT CORPORATION: Windows XP Mode [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

46

OpenSTA Name Server, sloužící ke konfiguraci hostitele repositáře, ve kterém jsou uloženy definiční soubory a výsledky testů, nastavení notifikací a úrovně logů. Další viditelné aplikace, tedy aplikace, které jsou k nalezení v nabídce programů operačního systému Windows, jsou Web Relay Daemon, která umožňuje distribuci zátěže44, a aplikace OpenSTA Commander, která slouží jako uživatelské rozhraní pro vývoj samotných testů45. 6.3.2


Testovací skripty, scénáře a monitory zátěže prostředků zvané Collectors jsou vyvíjeny v OpenSTA Commander prostředí. Jedná se o jednoduché uživatelské rozhraní, které se skládá ze dvou panelů. Užší panel slouží pro přístup k depozitáři, ve kterém jsou uloženy kolektory, tedy monitory zátěže, samotné testovací skripty a testovací scénáře. Tato kapitola popisuje především vývoj testovacích skriptů. Ostatní možnosti nástroje budou analyzovány v příštích kapitolách. Testovací skripty jsou vyvíjeny v programovacím jazyku SCL (Script Control Language)46. Jak tomu je i u nástroje HP LoadRunner, s vývojem skriptů značně pomůže možnost automatického generování skriptů pomocí nahrávaní. Díky v podstatě pozastavenému vývoji jsou pro nahrávání skriptů oficiálně podporovány pouze zastaralé verze prohlížeče Internet Explorer 4 a 5. I přes tuto skutečnost je nicméně možné skripty nahrávat pomocí novějších verzí prohlížeče Internet Explorer, nebo dokonce dalších prohlížečů, jako je například Mozilla Firefox47. Samotné nahrávání skriptů je velice intuitivní díky použití známých ovládacích znaků pro nahrávání, pozastavení nebo ukončení nahrávání. I u tohoto nástroje je možné přímo v průběhu nahrávání vytvářet transakce, jejichž časy jsou v průběhů běhu testů měřeny. Po dokončení nahrávání je automaticky generován kód testovacích skriptů v jazyce SCL. Tento kód je přehledný a i nepříliš zkušenému programátorovi lehce srozumitelný. Kód testovacích skriptů lze modifikovat v komponentě Script Modeler, která je automaticky spuštěna po kliknutí na jméno skriptu v depozitáři. Tato komponenta je dále rozdělena do tří panelů, kde hlavní panel slouží pro editaci zdrojového kódu skriptů. Další dva panely jsou; panel s výsledky, 44 CYRANO: The OpenSTA Architecture [online]. [cit. 22.02.2015]. Dostupné z URL: . 45 CYRANO: Getting Started [online]. [cit. 22.02.2015]. Dostupné z URL: . 46 CYRANO: Script Control Language Introduction [online]. [cit. 28.02.2015]. Dostupné z URL: . 47 UTEST: Load Testing with OpenSTA [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

47

který lze použít k náhledu na nahrané skripty z různých uhlů pohledů, a panel s výstupy informujícími o průběhu kompilace nebo průběhu spuštění právě editovaného skriptu. Skripty, jsou-li vytvořeny manuálně nebo generovány automaticky při nahrávání, je možné jednoduše přehrát a sledovat jejich průběh v panelu s výstupy. Pro vytvoření uživatelských výstupů viditelných v tomto panelu je možné použít SCL příkaz REPORT. Daný příkaz zároveň zapisuje do výsledků samotného spuštění testovacího scénáře. Toto lze využít pro ladění testovacích skriptů. Parametrizování v OpenSTA je uživatelsky přívětivé, a to díky funkcionalitě podobné té, již poskytuje nástroj HP LoadRunner. Proměnné hodnoty potřebné k parametrizaci lze jednoduše vytvořit díky průvodci vytváření proměnných a následně jej zakomponovat do testovacího skriptu. V průběhu vytváření proměnných hodnot lze definovat jejich rozsah, zdroj, typ nebo pořadí hodnot. Rozsah proměnných stanovuje, který virtuální uživatel a skript jej může použít. Dostupné jsou 4 typy rozsahu: lokální, na úrovni skriptu, na úrovni vlákna nebo globální. Více se lze o těchto možnostech dozvědět z rozsáhlé dokumentace OpenSTA 48. Z možností zdrojů proměnných jsou k dispozici jednoduchá proměnná, seznam hodnot, soubor nebo databáze. Proměnné lze vytvořit ve dvou typech, ve znacích nebo v číslech. Poslední definovatelnou vlastností proměnné je její pořadí hodnot, a to hlavně v případě, že se jedná o více těchto hodnot. Pořadí může být buď sekvenční nebo náhodné. Právě díky těmto možnostem je jednoduché vytvářet kvalitní testovací data pro účely simulování mnoha virtuálních uživatelů. Vytváření proměnných hodnot z odpovědí testované aplikace je jednoduché, především díky možnosti prohlédnutí si struktury HTML odpovědi tak, jak byla zaznamenána v průběhu nahrávaní. Díky této funkcionalitě nabízené panelem výsledku nahrávání je odchycení výsledku HTTP volání a následného nalezení požadované hodnoty a její předání do dalších kroků testovacího skriptu velice jednoduché. Obecně lze považovat vývoj testovacích skriptů v OpenSTA za uživatelsky přívětivý, zejména díky obsáhlé dokumentaci OpenSTA nástroje49 a SCL referenčního průvodce50 na stránkách výrobce. Vytváření skriptů používajících protokol HTTP/S, pro 48 CYRANO: Modeling Scripts [online]. [cit. 22.02.2015]. Dostupné z URL: . 49 CYRANO: User Guide Content [online]. [cit. 22.02.2015]. Dostupné z URL: . 50 CYRANO: OpenSTA SCL Reference[online]. 2005. [cit. 22.02.2015]. Dostupné z URL: .

48

který je tento nástroj primárně určen, je velice přímočaré. K vytváření skriptů pro testování SOAP protokolu v tomto nástroji neexistuje žádná speciální funkcionalita, nicméně je možné pro tento protokol využít rovněž protokol HTTP/S. Co se týče ostatních protokolů jako je například ODBC nebo JDBC, nástroj OpenSTA neposkytuje žádné možnosti. 6.3.3

Logy

OpenSTA nástroj poskytuje řadu příkazů umožnujících testovacím skriptům sdělovat informace na různých místech uživatelského rozhraní. Mezi nejzajímavější příkazy patří REPORT, LOG a NOTE. Zatímco příkaz REPORT zobrazuje požadované informace v Report logu ve výsledcích testování příkaz LOG je zobrazuje v Audit logu. Příkaz NOTE na druhou stranu slouží k zobrazení informací v monitorovací záložce testu a slouží zejména ke sledování hodnot určité proměnné použité právě bežícím virtuálním uživatelem. Příkaz NOTE je velice silným nástrojem v době ladění testovacího scénáře s větším množstvím virtuálních uživatelů. Všechny výsledky a logy skončených testů jsou uloženy v depozitáři OpenSTA. K těmto výsledkům je možné přistupovat přes systémového souborového průzkumníka nebo přes uživatelské rozhraní nástroje OpenSTA. 6.3.4


Testovací scénáře se v nástroji OpenSTA vytvářejí v komponentě Commander. Stejně jako je tomu u vytváření testovacích skriptů. Pro realizaci nového scénáře je nutné vytvořit nový test ve složce Tests v OpenSTA depozitáři. Po vytvoření a otevření nového scénáře jsou uživateli nabídnuty tři záložky, a to Configuration, ve které se nastavuje náběh a průběh testu pomocí skupin, Monitoring, ve které se sleduje průběh testů po jejich spuštění, a Results, ve které jsou k nalezení všechny nasbírané statistiky a výsledky jednotlivých testů. Záložky Monitoring a Results budou více rozebírány v následující sekci. V záložce Configuration se scénáře skládají z jedné nebo více skupin testovacích skriptů, které se do scénářů vkládají z adresáře skriptů hlavního depozitáře. Každé skupině je možné nastavit, zda se má spustit neprodleně po spuštění testu, nebo s jistým zpožděním. Dále je možné nastavit hostující počítač, z něhož je test spuštěn. Tato možnost je potřebná hlavně pro nastavení distribuované zátěže výkonnostního testování. Další možností nastavení je počet virtuálních uživatelů pro danou skupinu a jejich náběh. Díky spojování různých skupin je v OpenSTA možné nasimulovat takřka jakýkoliv testovací

49

scénář. Je tomu tak i v případě nastavení testovacích scénářů tak, jak byly definovány v sekci 6.1.7 Testovací scénáře. Pro potřeby monitorování a analýzy průběhu testů je možné do scénáře vkládat skupiny předem vytvořených sběračů měřených hodnot, takzvaných kolektorů. 6.3.5


Jakmile jsou všechny vlastnosti testovacího scénáře nastaveny, je možné přistoupit k jeho spuštění pomocí komponenty Commander. Testy jsou jednoduše spuštěny stlačením tlačítka Play v záložce Configuration. Průběh testů je po jejich spuštění možné sledovat v záložce Monitoring, která umožňuje pohled na průběh testů pomocí sady informací v podobě tabulek nebo grafů. Mezi tyto informace patří například souhrnná informace o průběhu testu, graf aktuálního počtu aktivních virtuálních uživatelů nebo seznam zaznamenaných chyb. Další informace je možné sledovat v podadresářích jednotlivých skupin testovacího scénáře. V případě, že byly do testovacího scénáře zařazeny sběrače informací o využití systémových zdrojů, je toto možné sledovat v podobě grafů právě v těchto podadresářích. Pro řádné sledování využití zdrojů testované platformy bylo zapotřebí na testované platformě nastavit SNMP protokol a jednotlivé sledované hodnoty pracně přidávat do kolektoru. Nástroj OpenSTA při spuštění Load testu s požadovanou zátěží 1100 uživatelů indikoval vysoké využití procesoru až do 80% v momentě, kdy bylo k testované aplikaci připojeno zhruba 600 uživatelů. Po tomto nárůstu byl z dostupných informací viditelný drastický pokles využití zdrojů a úplná stagnace počtu iterací provedených testovací skupinou simulující běžné uživatele. Po tomto zjištění již nebylo nutné v testu dále pokračovat a byl zastaven jednoduchým stiskem tlačítka Stop.

50

Ilustrace 7: Využití procesoru testované aplikace v průběhu Load testu s 1100 virtuálními uživateli

Zdroj: Vlastní zpracování Po rychlé analýze nasbíraných výsledků testu byly počty virtuálních uživatelů v Load testovacím scénáři jednoduše upraveny na 400 běžných uživatelů a 100 operátorů. Takto upravený test byl o poznání úspěšnější. Dalším z požadovaných testů, který byl v nástroji OpenSTA spuštěn, byl Stress test. Vzhledem k výsledkům předešlých testů byla testovaná zátěž upravena na počátečních 300 virtuálních uživatelů simulujících běžné uživatele a 100 virtuálních uživatelů simulujících operátory. Celkový maximální počet uživatelů byl upraven na 800. Výsledek testu dopadl stejně jako v případe Load testu. Nicméně v případě Stress testu je lépe viditelný vliv počtu uživatelů na výkonnost testované aplikace. Zřetelné je to na následujícím grafu, kde čas transakce Výběr košíku narůstá s spolu s nárůstem počtu virtuálních uživatelů.

51

Ilustrace 8: Časy transakcí naměřené Stress testem

Zdroj: Vlastní zpracování

6.3.6

Analýza výsledků

Analýzu výsledků testů je možné provádět v záložce Results komponenty Commander, která je k tomuto účelu určena. Kromě hodnot, jež je možné sledovat již v průběhu testu v záložce Monitoring, tato záložka obsahuje mnoho dalších ukazatelů potřebných k vyhodnocení úspěšnosti testů. Mezi tyto hodnoty patří například počty úspěšných a neúspěšných transakcí, výsledky měření časů transakcí v podobě grafů nebo celková propustnost testované aplikace. Naměřené hodnoty reprezentované tabulkami je možné exportovat do souborů, které lze poté dále zpracovat dalšími externími nástroji. Grafy, jež jsou v OpenSTA generovány je možné upravovat dle potřeb uživatele. Tak je tomu rovněž v případě komerčního nástroje HP LoadRunner, grafy v OpenSTA lze přibližovat nebo oddalovat pro jednodušší analýzu. Celkově vzato analýza výsledků v nástroji OpenSTA je velice uživatelsky přívětivá a lze její vlastnosti přirovnat k referenčnímu komerčnímu nástroji. Za jedinou významnější výjimku může být považována absence kombinace grafů, kterou poskytuje komponenta Analyses nástroje HP LoadRunner. 6.3.7

Plnění cílů

S nástrojem OpenSTA bylo, až na pár výjimek jako například měření 90 percentilu odezvy 52

jednotlivých transakcí nebo měření heapsize, možné nastavit měření všech požadovaných indikátorů výkonnosti tak, jak byly definované v sekci 6.1.9 Sledované hodnoty. Již v průběhu testu se ale ukázalo, že ne všechna měření fungují správně. Většina hodnot měřených pomocí SNMP protokolu nebyla vůbec zaznamenána. Mezi tyto nesprávně měřené indikátory patří využití sítě nebo I/O operací. Z hlediska pokrytí testovacích scénářů s nástrojem OpenSTA nebylo možné nasimulovat uživatelskou skupinu používající ODBC protokol pro přímou komunikaci s databází, jelikož je tento nástroj určen jenom k testování HTTP/S protokolu. Na druhou stranu testování webových služeb nebylo právě díky protokolu HTTP žádný problém. Nastavení průběhu, náběhu a celkové zátěže testů naplnilo veškeré cíle, ačkoliv například možnost zastavení všech skriptů ve stejnou chvíli po předem definované době úplně chybí. Tato absence ovšem nemění nic na tom, že OpenSTA je lehce ovladatelný nástroj, který poskytuje funkcionality měřitelné s komerčním nástrojem HP LoadRunner. 6.3.8

Shrnutí

I přesto, že se povedlo s nástrojem OpenSTA naplnit všechny cíle testování a ovládání tohoto nástroje je uživatelsky přívětivé bez vysokých požadavků na dovednosti vývojáře testovacích skriptů, má tento nástroj jen velmi malou potenci, a to hlavně kvůli své zastaralosti. Poslední aktualizace nástroje byla uvolněna před sedmi lety a většina nástrojem podporovaných operačních systémů a webových prohlížečů již není ani komerčně podporována. Pro správné spuštění nástroje v operačním systému Windows 7 je zapotřebí využít Windows XP Mode a pro nahrávání modernějších webových stránek byly dokonce zapotřebí zásahy do registrů operačního systému Windows 51. V průběhu testu byla také zaznamenána nestabilita nástroje, která byla vyřešená díky přenastavení chování soketů tak, jak bylo doporučeno na Internetu 52. Na druhou stranu velikou silou nástroje OpenSTA je značně rozsáhlá dokumentace a také fakt, že tento nástroj byl v minulosti populární a na Internetu je tedy k nalezení pestrá kolekce řešení problémů a řada jiných užitečných rad. I přes svou zastaralost a úzkou specializaci je tento nástroj za předpokladu, že je 51 MICROSOFT CORPORATION: You cannot post data to a non-NTLM-authenticated Web site [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: . 52 RADIUMTESTING.BLOGSPOT.CZ: Opensta Performance testing tool: error 10048 opensta [online]. 2008. [cit. 22.02.2015]. Dostupné z URL: .

53

objekt testování testovatelný jenom pomocí HTP protokolu, dobrou alternativou k nástroji HP LoadRunner, a to hlavně díky jednoduchosti ovládání, velmi dobrým možnostem měření výkonu a zpracování výsledků, které jsou až na malé výjimky použitelné bez jakýchkoliv modifikací.

6.4. The Grinder 6.4.1

Instalace

Na rozdíl od dříve analyzovaných nástrojů pro výkonnostní testování se nástroj Grinder neinstaluje pomocí žádného instalačního průvodce. Naopak je spouštěn přímo ze spustitelných Java binárních souborů. Nicméně správné spuštění nástroje Grinder není úplně triviální. Předtím než je nástroj spuštěn, je potřeba být obeznámen s architekturou tohoto nástroje. Nástroj Grinder se skládá ze tří komponent, a to Worker, Agent a Console. Worker je komponenta, která interpretuje a vykonává testovací skripty. Agent je komponenta, jež spouští nebo zastavuje Worker komponenty dle potřeby. Poslední komponentou je komponenta Console, řídící ostatní komponenty, sbírající a interpretující výsledky testování a také sloužící jako vývojové prostředí. Součástí nástroje Grinder je také volitelná komponenta TCPProxy, která slouží díky možnosti nahrávání k automatickému generování testovacích skriptů. Jakmile je tedy uživatel obeznámen se všemi součástmi tohoto nástroje, je možné je spustit pomocí ručně vytvořených Windows Batch spouštěcích skriptů. V případě, že je Grinder spouštěn v operačním systému Linux, jednalo by se o spouštěcí skripty napsané pomocí jazyka Shell. Pro správné spuštění je tedy nutné vytvořit sadu skriptů tak, jak jsou popsány v příručce nástroje. Konkrétně se jedná o skript setGrinderEnv.cmd, který nastaví systémové proměnné pro účely nástroje Grinder, startAgent.cmd, jenž spouští komponentu Agent,

startConsole.cmd,

spouštějící

komponentu

Console

a

nakonec

skript

startProxy.cmd, který spouští volitelnou komponentu TCPProxy. Poté co jsou všechny skripty vytvořené, je možné nástroj Grinder spustit pomocí skriptu startConsole.cmd a startAgent.cmd. Při spouštění těchto skriptů je komponenta Agent automaticky nastavena díky souboru grinder.properties53. Tento soubor pro kontrolu vlastností komponent Agent a Worker bude více analyzován v následujících kapitolách. 53 ASTON PHILIP, FITZGERALD CALUM: Getting Started [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: .

54

6.4.2


Jak již bylo zmíněno, vývojové prostředí nástroje Grinder poskytuje jeho komponenta Console. Programovacím jazykem pro vývoj testovacích skriptů je jazyk Jython, který implementuje jazyk Python v jazyce Java54. Možnosti vývojového prostředí Grinder nicméně nedosahují takových kvalit jak tomu bylo u dosud analyzovaných nástrojů. Komponenta Console z hlediska vývoje skriptů poskytuje jenom jakýsi jednoduchý editor skriptů v záložce Script. Ani tento editor neposkytuje žádné možnosti, které by mohly vývojářům testovacích skriptů jakkoliv vývoj ulehčit. Jedná se spíše jenom o editor, v němž je možné provádět menší nenáročné změny. V tomto vývojovém prostředí úplně chybí základní funkce, jako jsou například kontrola syntaxe, zobrazení řádků nebo možnost rolování textu. Ostatní záložky komponenty Console poskytují jenom nástroje pro kontrolu a zobrazení výsledků testů. Možností, jak vyvíjet a ladit testovací skripty pro Grinder, je zcela určitě více, za zmínku ale stojí hlavně plugin do populárního vývojového prostředí Eclipse55 GrinderStone56. Vzhledem k cílům této práce nebyl tento plugin využit. Pro vývoj testovacích skriptů, scénářů a zátěže byl v této práci využit textový open source editor Notepad++57. Tyto skripty pak byly pro účely ladění spouštěny rovnou v nástroji Grinder. Právě díky úplné absenci jakýchkoliv nástrojů pro ulehčení vývoje testovacích skriptů je nutné, aby vývojář dobře ovládal objektově orientované programování nebo využil další nástroj, jako je například GrinderStone. Navzdory tomu, že vývojové prostředí nenaplňuje základní potřeby pro vývoj skriptů, je možné pomocí komponenty TCPProxy, která je součástí nástroje Grinder, pohodlně nahrávat HTTP skripty tak jako u ostatních nástrojů. Kvalita těchto automaticky generovaných skriptů je velice dobrá i přesto, že není možné v průběhu jejich nahrávání definovat jednotlivé transakce. Jedinou možnost, kterou komponenta TCPProxy poskytuje, je vkládání komentářů do nahrávaného skriptu. Automaticky generované skripty je vzápětí možné bez problémů spustit v nástroji Grinder. 54 PYTHON SOFTWARE FOUNDATION: jython [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: . 55 THE ECLIPSE FOUNDATION: eclipse [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: . 56 ANDRUSCHUK BORISLAV: Grinder for Eclipse [online]. 2011. [cit. 22.02.2015]. Dostupné z URL: . 57 DON HO: Notepad++ [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

55

Pro účely následné modifikace nahraných skriptů je vhodné obeznámit se se základními příkazy a metodami na oficiálních stránkách nástroje Grinder 58. Tyto informace společně s automaticky generovanými skripty umožní alespoň trošku zkušenému vývojáři vytvořit základní HTTP testovací skripty. Pro účely následné parametrizace dat nebo kontrolu výsledků a jiných potřebných funkčností je možné využít funkce samotného nástroje Grinder, jež jsou specifikovány v Grinder API59, nebo také funkce programovacího jazyka Jython, jež jsou popsány v její uživatelské příručce60. Dalším užitečným zdrojem informací pro vývoj skriptů v nástroji Grinder je samotný Internet, kde je díky relativně velké popularitě toho nástroje možné nalézt mnoho příkladů užití. Právě při vývoji testovacích skriptů pro protokol SOAP není oficiální dokumentace postačující, a i přes možnost automatického generování skriptů pomocí nahrávání, je nutné sáhnout po informacích na Internetu, kde je možné nalézt údaje, které těžkosti s vývojem těchto skriptů eliminují61. Pro vývoj skriptů testujících výkonnost SQL databází je potřeba zase o trochu více dovedností než v případe HTTP nebo SOAP protokolů. V první řadě je potřeba nalézt správný ovladač a balíček potřebný pro připojení k databázi. V případě této práce se jedná o MySQL databázi a její Java driver 62, společně s Jython balíčkem ZxJDBC, který poskytuje rozhraní k JDBC protokolu 63. Spojením správného ovladače, Jython balíčku a informací dostupných na oficiálních stránkách nástroje Grinder 64 je možné vytvořit testovací skripty využívající SQL dotazy. Ze všech doposud analyzovaných nástrojů pro výkonnostní testování klade právě nástroj Grinder největší požadavky na programátorské dovednosti vývojáře testovacích skriptů.

58 ASTON PHILIP, FITZGERALD CALUM: Scripts [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: . 59 ASTON PHILIP, FITZGERALD CALUM: The Grinder Documentation [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: . 60 PYTHON SOFTWARE FOUNDATION: Jython User Guide [online]. 2014. [cit. 22.02.2015]. Dostupné z URL: . 61 NABBLE LLC.: Webservice Calls [online]. 2009. [cit. 22.02.2015]. Dostupné z URL: . 62 ORACLE CORPORATION: Download Connector/J [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: . 63 JUNEAU J., WIERZBICKI F., BAKER J., SOTO L., NG V.: Chapter 12: Databases and Jython: Object Relational Mapping and Using JDBC [online]. 2010. [cit. 22.02.2015]. Dostupné z URL: . 64 ASTON PHILIP, FITZGERALD CALUM: Grinding a database with JDBC [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: .

56

6.4.3

Logy

Ačkoliv v prostředí komponenty Console nástroje Grinder není možné sledovat detaily a logy z průběhu právě běžícího testu, je toto umožněno v příkazové řádce, ve které je spuštěna komponenta Agent. Pro zobrazení požadovaných informací v příkazové řádce agenta je možné využít příkaz print uvnitř testovacího skriptu. Je nutno dodat, že ladění testovacích skriptů použitím výstupu v příkazové řádce Windows není ideální. Proto je pro analýzu testů efektivnější zaznamenávat průběh testů do dedikovaných log souborů. Základní sada logů je nástrojem Grinder vytvářena automaticky a sestává ze dvou souborů pro každý spuštěný Worker proces. Jeden ze souborů slouží k zaznamenávání statistik testů a je možné jej použít ke generování grafů a reportů. Druhý soubor je spíše informativní a slouží k zaznamenání aktivity Worker procesu. Do tohoto souboru je možné zapisovat vlastní informace pomocí příkazu grinder.logger. Tento log je vhodný pro případné ladění testovacích skriptů. V případě potřeby si díky jazyku Jython není problém vytvořit vlastní log soubory. 6.4.4


Tvorba testovacích scénářů je asi největší slabinou nástroje Grinder. Oproti nástrojům analyzovaným v předchozích kapitolách neposkytuje tento nástroj žádné uživatelské rozhraní, kde by bylo možné tyto scénáře navrhnout. Jedinou možností, jak je nastavit, zůstávají soubory properties, ve kterých lze například nastavit, kolik procesů celkově se má spustit, v jakých dávkách počty těchto procesů narůstají, popřípadě v jakých časových rozestupech. Problém je ten, že každý spuštěný proces vyžaduje až 150MB operační paměti. S tímto poznáním není složité si spočítat, na kolik testovacích stanic by se musela generovaná zátěž rozložit, aby bylo možné nástrojem Grinder simulovat 1200 a víc virtuálních uživatelů. Řešení tohoto problému je jediné, a to simulovat zátěž pomocí vláken. Použití vláken pro náběh není úplně jednoduché vzhledem k tomu, že jej není možné nastavovat pomocí properties souboru bez dodatečných změn v kódu samotných test skriptů. Toto nicméně není triviální a bez znalostí objektově orientovaného programování je to jen stěží dosažitelné. Pro účely této práce byly nicméně tyto dodatečné změny kódu provedeny. Pomocí pár nově implementovaných metod a matematických operací je možné úspěšně vytvořit oba testy tak, jak jsou definovány v sekci 6.1.8 Scénáře zátěže. Na rozdíl od

57

nástroje OpenSTA nebo LoadRunner není možné jednoduše logicky oddělit transakci Přihlášení a Odhlášení od ostatních transakcí. Proto každý běh testovacího skriptu spouští i tyto dvě transakce. Lze tedy očekávat, že s použitím stejného počtu virtuálních uživatelů bude zátěž na databázi větší, než tomu bylo u zátěže generovaným nástrojem OpenSTA. 6.4.5


Pro úspěšné spuštění výkonnostních testů je zapotřebí proces Agent, který se stará o spouštění Worker procesů interpretujících testovací skripty a vykonávajících samotné testování. Proces Agent také slouží jako možné rozhraní pro kontrolu průběhu testů. Každý Agent proces reprezentuje jeden virtuální počítač neboli JVM. Testovací scénáře je možné spustit a sledovat jejich průběh buď přímo v procesu Agent pomocí příkazové řádky nebo pomocí komponenty Console. Implicitně zobrazované informace v příkazové řádce zcela jistě nejsou k řádné kontrole postačující, jelikož poskytují informace jenom o případných chybách v rámci spuštění testovacích scénářů definovaných v properties souborech. Pro jakékoliv jiné potřebné informace je zapotřebí toto explicitně definovat přímo v testovacích skriptech, například pomocí již zmiňovaného příkazu print. Další možností spuštění testů je komponenta Console, jež je spouštěna společně s lokálními nebo vzdálenými Agent procesy a slouží ke kontrole a řízení těchto procesů. Pomocí Console komponenty je možné zaslat různé signály Agent procesům, jako například Start nebo Restart testu. Další možností komponenty Console je sledování statistik tak, jak jsou reportovány testovacími skripty a předávány pomocí Agent procesů. Ačkoliv je tato komponenta určena převážně ke sledování statistik, kvalita informací v ní zobrazených zaostává za kvalitou poskytovanou ostatními nástroji. Možnosti, které tato komponenta poskytuje, lze rozdělit na tři skupiny, jež jsou v uživatelském rozhraní rozděleny na další tři záložky. Jedná se o záložku Graphs, ve které jsou zobrazeny nic neříkající grafy zobrazující průběh všech transakcí. Každá transakce má svůj vlastní graf, jenž je příliš malý a nelze jej nijak zvětšovat nebo přibližovat. Vedle grafů jsou zobrazovány základní statistiky, jakými jsou průměrný čas transakcí, průměrný počet transakcí za sekundu, maximální počet transakcí za sekundu a počet úspěšných a neúspěšných testů. Záložka Results zobrazující průběh testu v tabulkové formě udává jenom o něco málo více informací než záložka s grafy. V záložce Processes pak lze sledovat jen stav všech spuštěných procesů. Mezi

58

zbývající hrstku dalších způsobů kontroly průběhu testů lze řadit možnost distribuce testovacích skriptů na všechny Agent procesy, nastavení intervalu pro získávání statistik, nastavení property souboru, který je spouštěn, nebo sledování aktuálního celkového počtu transakcí vykonaných za sekundu (TPS). Poslední možností, jak sledovat spuštění a průběh testů, je průběžně kontrolovat obsah log souborů. Podobně, jak tomu bylo v případě nástroje OpenSTA při spuštění Load testu s požadovanou zátěží 1200 virtuálních uživatelů, nástroj Grinder indikoval problém s výkonností testované aplikace mnohem dříve, než byl počet těchto uživatelů dosažen. Na rozdíl od ostatních nástrojů nebyl pokles výkonnosti viditelný na žádném z grafů, ale zobrazil se v tabulce statistik, kde bylo možné vysledovat nárůst neúspěšných transakcí. Po tomto zjištění bylo možné test ukončit tlačítkem Reset. Pro druhý test simulující mnohem menší počet uživatelů, a to 500, stačilo změnit počet vláken v Load.properties souboru. Při spuštění druhého testu bylo možné vysledovat mnoho neúspěšných transakcí Zobrazení obsahu košíků přistupujících do databáze použitím zxJDBC modulu. Vzhledem k tomu, že testovací scénáře v nástroji Grinder přistupují k databázi mnohem častěji, než tomu bylo v případě nástroje OpenSTA, bylo toto chování očekávané. Pro třetí běh Load testu již bylo nastartováno pouze 400 virtuálních uživatelů. I přes menší počet uživatelů mnoho databázových transakcí skončilo neúspěšně. Při spuštění Stress testu s maximálním počtem 800 virtuálních uživatelů byly výsledky s mnoha neúspěšnými transakcemi očekávány.

59

Ilustrace 9: Statistiky testu v uživatelském rozhraní nástroje Grinder


Analýza výsledků

Jak již bylo mnohokrát zmíněno nástroj Grinder i přes to, že je to nástroj určený k výkonnostnímu testování, neposkytuje pohled na průběh nebo finální výsledky testů v lehce čitelné podobě. Jedinou možností, jak zjistit, že výkonnost testované aplikace nedosahuje očekávaných hodnot, je sledování tabulky statistik. Ani po skončení běhu testu není situace v nástroji Grinder o nic lepší a jediný způsob, jak analyzovat výsledky testů, je zpracování výsledných log souborů. Pouhým otevřením těchto souborů není ovšem možné nic objevit, a tak je zapotřebí tyto soubory nejdříve nějakým způsobem zpracovat. Nástroj Grinder sám o sobě takovou možnost nenabízí a je tedy nutné použít nějakou další aplikaci. Mezi takové aplikace patří například Grinder Analyzer 65, pomocí které je možné zpracovat výsledné log soubory. Nevýhodou této aplikace je fakt, že není její pomocí možné sledovat průběh testů. Druhou aplikací, již je možné v kontextu 65 TRAVIS BEAR: Grinder Analyzer [online]. 2012. [cit. 22.02.2015]. Dostupné z URL: .

60

zpracovávání Grinder statistik nalézt, je grafový systém Graphite66. Tento systém není určen pouze pro použití s nástrojem Grinder a není jej tedy možné použít přímo. Nicméně použitím nástroje Grinder to Graphite67 je možné tyto dva nástroje integrovat a kromě analýzy finálních výsledků testů je možné jejich integrací sledovat také průběh testů v reálném čase. Všechny zmíněné aplikace jsou dostupné zdarma. Další možností, jak výsledky testů zpracovat, je vytvoření vlastního nástroje. Vzhledem k tomu, že vytvoření vlastního nástroje je příliš komplikované a k použití systému Graphite je zapotřebí dalšího webového serveru, byl pro účely této práce použit nástroj Grinder Analyzer. 6.4.7

Plnění cílů

Z hlediska sledování hodnot tak, jak byly definovány v sekci 6.1.9 Sledované hodnoty, lze říci, že až na pár hodnot, jako jsou například průměrný čas odezvy transakcí, není možné nástrojem Grinder bez použití dalších aplikací ostatní hodnoty nijak sledovat. I použitím dalších aplikací lze sledovat jenom malou část požadovaných hodnot, jako je například odezva transakcí vzhledem k času trvání testování. Monitoring využití zdrojů jak testovací, tak testované platformy nelze nástrojem Grinder za použití výchozích funkčností dosáhnout. Na druhou stranu na rozdíl od nástroje OpenSTA bylo možné simulovat všechny testovací scénáře tak, jak byly definovány 6.1.7 Testovací scénáře. Lze předpokládat, že díky použitému programovacímu jazyku Jython nebude pro nástroj Grinder problém testovat žádný protokol. Ačkoliv bylo nástrojem Grinder možné nastavit všechny scénáře zátěže definované v sekci 6.1.8, je nutno říci, že z doposud analyzovaných nástrojů vyžadoval nástroj Grinder nejvíce programátorských dovedností. 6.4.8

Shrnutí

Nástroj Grinder, ačkoliv je určen k výkonnostnímu testování, neposkytuje skoro žádné možnosti sledování průběhu testů nebo jejich finální analýzu. Vývoj testovacích skriptů i přes možnost automatického vytváření skriptů pomocí funkčnosti nahrávání vyžaduje značné programátorské dovednosti. V případě, že je testovací tým složen z více programátorů, lze tento nástroj pomocí četných modifikací a rozšíření v enterprise prostředí využít. Bez zkušeného týmu by nicméně použití tohoto nástroje mohlo generovat nemalé finanční náklady, se kterými by se v projektu muselo počítat. 66 WIKIDOT INC.: Graphite - Scalable Realtime Graphing [online]. 2012. [cit. 22.02.2015]. Dostupné z URL: . 67 TRAVIS BEAR: Grinder To graphite [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: .

61

6.5. JMeter 6.5.1

Instalace

Stejně jako v případě nástroje Grinder nástroj JMeter není nutno instalovat. Ke správnému spuštění tohoto nástroje stačí, aby archivační soubor stažený z oficiálních stránek68 a obsahující spustitelné soubory byl řádně rozbalen a na hostitelském systému byla nainstalovaná Java v minimální verzi 6. Samotné spuštění nástroje JMeter je v porovnání s nástrojem Grinder velice jednoduché a v podstatě stačí jenom spustit skript jmeter.bat. Co se týče instalace, lze považovat instalaci nástroje JMeter za nejjednodušší ze všech analyzovaných nástrojů. Je nutno poznamenat, že na rozdíl od všech ostatních nástrojů pro výkonnostní testování není nástroj JMeter složen z vícero komponent. Vývoj, spuštění, kontrola a sledování průběhu testů se odehrává v jednom uživatelském rozhraní. JMeter lze také spustit bez uživatelského rozhraní nebo taky v serverovém módu, který je potřebný pro distribuované testování. Pořád se ale jedná o ten samý nástroj, který je pouze spuštěn jiným spouštěcím skriptem. Po samotném spuštění nástroje je zobrazeno přehledné uživatelské rozhraní, jehož součástí je panel nástrojů, okno se stromovou strukturou zobrazující elementy aktuálního projektu a okno s detaily právě označeného elementu. 6.5.2


Vývoj testovacích skriptů v nástroji JMeter lze považovat za zcela odlišný od ostatních analyzovaných nástrojů. V tomto nástroji se skripty nevyvíjejí pomocí žádného programovacího jazyku. Vše je naopak vyvíjeno vytvářením a vnořováním elementů do stromové struktury test plánu v levé částí vývojového prostředí. Elementů je mnoho typů od logických elementů až po monitorovací elementy. Pro uživatele používající tento nástroj poprvé mohou být některé použité terminologie zavádějící, nicméně velice rozsáhlá dokumentace na oficiálních stránkách nástroje69 orientaci ulehčí. Další možností, jak s vývojem testovacích skriptů začít, je využít takzvaných šablon, jež vytvoří ukázkový test plán pro nejčastěji testované protokoly. Tyto šablony je pak možné modifikovat dle vlastních potřeb a dosáhnout tím cíle. Tak jak tomu bylo dosud u všech analyzovaných nástrojů, je i v případě nástroje JMeter možné využít 68 APACHE SOFTWARE FOUNDATION: Apache JMeter [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: . 69 APACHE SOFTWARE FOUNDATION: User's Manual [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

62

automatického generování HTTP/S skriptů. Použití této funkcionality je popsané v oficiálním tutoriálu70, s jehož pomocí je práce s funkčností nahrávaní velice jednoduchá. Na rozdíl od ostatních nástrojů však zde není možnost nijak zasahovat do nahrávání. Není možné označit začátky nebo konce jednotlivých transakcí nebo vkládat komentáře, jak tomu je v případě nástroje Grinder. Toto je nicméně možné nastavit dodatečně poté, co jsou skripty vygenerovány ve stromové struktuře test plánu, s jehož pomocí lze v hlavním okně modifikovat každý vygenerovaný element. Podobně jednoduché je vytvoření skriptů pro ostatní podporované protokoly, mezi které patří také protokoly potřebné k naplnění všech cílů definovaných v sekci 6.1 Definice prostředí a cílů. Zde také pomůže velice rozsáhlá dokumentace. Až překvapivě triviální je vytvoření skriptů pro testování databází pomocí JDBC protokolu. I ověření, zda test dopadl správně, lze jednoduchým přidáním elementu pro kontrolu výsledku. Stejně jak tomu je u vytváření základních testovacích skriptů, i pro parametrizování testovacích dat si uživatel vystačí s přidáváním dostupných elementů do stromu testovacího plánu. Mezi elementy, jež se starají o přípravu testovacích dat, patří také element ke čtení CSV souborů. Mezi další možnosti, jak parametrizovat nebo jinak dále obohacovat testovací skripty, patří využití speciálních JMeter funkcí popsaných v uživatelském manuálu71. Všechny elementy ve stromu testovacího plánu lze kopírovat, klonovat nebo deaktivovat. Použité elementy lze také jednoduše myší přesouvat v rámci testovacího plánu. Elementy jsou spouštěny v takovém pořadí, v jakém jsou seřazeny ve stromu testovacího plánu. Ladění testovacích skriptů lze zjednodušit přidáním monitorovacího elementu, který zobrazuje všechna poslaná a přijatá data. V ladění také pomůže aktivování okna zobrazujícího log samotného nástroje JMeter, který pomůže především v odchytávání závažnějších problémů s testovacím plánem. Oproti ostatním analyzovaným nástrojům je vývoj testovacích skriptů nenáročný na programátorské dovednosti uživatele. V případě, že by přece jen bylo zapotřebí zásadnějšího zásahu do poskytovaných funkcionalit, které JMeter implicitně poskytuje, je možné jej obohatit již dostupnými pluginy nebo si napsat 70 APACHE SOFTWARE FOUNDATION: Apache JMeter HTTP(S) Test Script Recorder [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: . 71 APACHE SOFTWARE FOUNDATION: Functions and Variables [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

63

proprietární plugin. 6.5.3

Logy

Vzhledem k charakteru, jakým jsou testovací skripty v nástroji JMeter vyvíjeny a spouštěny, není potřeba rozsáhlého logování nevyhnutelná, jako je tomu v případě ostatních analyzovaných nástrojů. Je to způsobeno hlavně tím, že uživatel nepoužívá žádný programovací jazyk pro vývoj těchto skriptů. Ale v případě, že je přece jen potřeba sledovat průběh testovacích skriptů za účelem odchytávání různých chyb, postačí často aktivovat pohled na záznamy nástroje. V tomto pohledu, který je součástí uživatelského rozhraní, je možné sledovat základní informace běhu skriptů a detailnější popisy různých chyb. Pro sledování samotných výsledků testů, jako je například sledování výsledků jednotlivých kroků v testovacích skriptech, je možné použít některý z řady takzvaných Listener elementů. Ačkoliv by se mohlo zdát, že absence rozsáhlejšího logování je zcela zásadní nevýhodou tohoto nástroje, je na místě říci, že pro potřeby naplnění cílů testování tak, jak byly definovány v sekci 6.1 této práce, byly implicitní možnosti logování nabízené nástrojem JMeter zcela postačující. 6.5.4


K nastavení testovacích scénářů, náběhu a monitoringu je vhodné využít možnost jednoduchého rozšíření nástroje JMeter pomocí takzvaných pluginů. Mezi populární a lehce použitelnou sadu těchto pluginů lze považovat open source projekt JMeter Plugins72. Na rozdíl od pluginů nástroje Grinder jsou pluginy v nástroji JMeter použitelné přímo v uživatelském prostředí stejně jako všechny ostatní elementy, které jsou součástí základní sady nástroje. I samotná instalace těchto pluginů je velice jednoduchá a sestává z prostého nakopírování binárních souborů do souborové struktury nástroje JMeter. Právě díky těmto pluginům je nastavení testovacích scénářů ještě jednodušší než ve výchozí podobě nástroje. Pro účely naplnění cílů této práce byl pro náběh virtuálních uživatelů každé uživatelské skupiny použit element Stepping Thread Group, který bez potíží díky přehlednému nastavení stoprocentně pokryl požadavky Load testu. Pro potřeby nastavení na náběh náročnějšího Stress testu byl použit Ultimate Thread Group element. V použitých 72 POKHILKO ANDREY et al: Custom Plugins for Apache JMeter [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

64

elementech lze jednoduše nastavovat různá prodlení, kdy jsou uživatele startováni, čas jejich startování, velikost skupin nebo například také podmínky pro postupné zastavování těchto uživatelů. Užitečnou možností těchto elementů je také grafické zobrazení průběhu testovacího scénáře z pohledu počtu virtuálních uživatelů. Pro uživatele je tedy jednoduché udělat si představu o tom, jak bude zátěž testu v čase skutečně vypadat. V rámci tvorby testovacích scénářů je také možné nastavovat sledování výkonnosti testované aplikace nebo testovací stanice pomocí velké škály monitorovacích elementů. Pro účely monitoringu využití zdrojů testovacích a testovaných stanic je možné využít komponentu Server Agent, která je součástí již zmíněných JMeter Plugins pluginů a slouží ke sběru informací o využití zdrojů z operačního systému. Podporovány jsou operační systémy Windows a Linux. Tuto komponentu nicméně nelze spustit přímo z nástroje JMeter. Server Agent je nutné spustit na stanici, kterou je potřeba monitorovat. Výhodou jistě je, že pro jeho spuštění nejsou nutná administrátorská práva. Když je tato komponenta spuštěna na jednom nebo více stanicích, je již sběr dat z těchto stanic velice jednoduchý a jejich výsledky jsou viditelné přímo v uživatelském prostředí JMeter. Analýza výsledků a monitoring bude více popsán v následujících kapitolách.

65

Ilustrace 10: Nastavení Stress testu v uživatelském rozhraní nástroje JMeter

6.5.5

Zdroj: Vlastní zpracování Spuštění a kontrola průběhu testů

Spuštění samotných testů v nástroji JMeter není o nic těžší než v ostatních analyzovaných nástrojích. Spuštění testů se provádí prostým zmáčknutím tlačítka Start v nástrojové liště. V případě distribuovaného testu by se jednalo o tlačítko Remote Start All. Podobně lehce lze test předčasně ukončit pomocí tlačítka Stop nebo Remote Stop All. Mezi další ovládací prvky nástroje lze řadit tlačítka Clear a Clear All, které se starají o vymazání nasbíraných dat z předešlého běhu testu. Co se týče samotné kontroly průběhu testu, lze nástroj JMeter přirovnat k nástrojům HP LoadRunner a OpenSTA, ve kterých bylo také možné sledovat průběh testů z vícero pohledů díky různým měřením. Nastavení všech potřebných monitoringů je v nástroji JMeter i díky pluginům a jejich dobré dokumentaci 73 relativně jednoduché i pro nezkušeného uživatele. Na rozdíl od nástroje Grinder není potřeba ani k provádění těchto měření žádné programátorské dovednosti. Vše je nastavitelné přes 73 POKHILKO ANDREY et al: Project Documentation Wiki [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

66

uživatelské rozhraní. Podobně jak tomu bylo u ostatních nástrojů, které nebyly omezeny maximálním možným počtem virtuálních uživatelů, bylo nástrojem JMeter zjištěno, že testovaná aplikace nedokáže obsluhovat požadovaný počet 1200 paralelních uživatelů. Pří prvním spuštění Load testu byla zjištěna degradace výkonu testované aplikace už při 300 uživatelích. Nicméně degradace v tomto případě byla až do zhruba 400 paralelních uživatelů akceptovatelná. Pro druhé spuštění Load testu již bylo použito pouze 500 paralelních uživatelů. Tento test doběhl v pořádku, nicméně naměřené hodnoty nenaplňovaly očekávání vzhledem k tomu, jak byly definovány v sekci 6.1.6 Požadavky na výkon. Pro potřeby dodatečné analýzy výkonu testované aplikace byl použit upravený Stress test scénář s maximálním počtem uživatelů 500 a náběhem uživatelů v 5 dávkách s velkými časovými rozestupy mezi jednotlivými dávkami. Samotná úprava původního Stress testu v nástroji JMeter nepředstavuje velkou časovou nebo technickou náročnost. Už v průběhu tohoto testu bylo patrné, že výkon aplikace degraduje s 300 paralelními virtuálními uživateli. 6.5.6

Analýza výsledků

Analýza výsledků v nástroji JMeter je díky již zmíněným pluginům velice efektivní, a to díky možnosti sledování využití jak lokálních zdrojů, tak zdrojů testované platformy. Sledovat průběh a výsledky testů je možné v grafické i v textové podobě v závislosti na tom, jaký Listener element je použit. Nástrojem Jmeter, jako jediným ze všech analyzovaných nástrojů, bylo možné sledovat všechny hodnoty definované v sekci 6.1.9 Sledované hodnoty, včetně využití zdrojů Java Virtual Machine. Naměřené výsledky včetně grafů nejsou v tomto nástroji nikam ukládány, nicméně je možné je kdykoliv uložit přímo na disk z uživatelského rozhraní. Velice užitečnou možností grafů ze sady JMeter pluginů je vytváření kompozitních grafů. Jedná se o možnost kombinování vícero grafů do jednoho. Kombinace například počtu aktivních uživatelů, časů odezev a využití zdrojů do jednoho grafu pomůže při potřebné analýze nebo při prezentování výsledků. Jedinou nevýhodou generovaných grafů je fakt, že je není možné přibližovat nebo oddalovat. Na druhou stranu je možné měnit jejich granularitu nebo vybírat, které hodnoty budou na grafu viditelné.

67

Ilustrace 11: Kompozitní graf s výsledky Stress testu v nástroji JMeter


Plnění cílů

Z hlediska plnění cílů lze říci, že nástroj JMeter naplnil všechny cíle tak, jak byly definovány v sekci 6.1 této práce. Všechna požadovaná sledování byla dostupna buď přímo z implicitních možností nástroje nebo díky rozšiřujícím pluginů. Pluginy byly užitečné i v případě tvorby testovacích scénářů, které byly také vytvořeny dle stanovených požadavků. 6.5.8

Shrnutí

Ze všech analyzovaných nástrojů je nástroj JMeter nejjednodušší jak na vytváření skriptů, tak na jejich spouštění a kontrolu. Uživatelské prostředí je opatrně navrženo, aby orientace v něm byla jednoduchá a efektivní. Pro vývoj jakékoliv potřebné části pro naplnění cílů testování této práce nebyly zapotřebí žádné programátorské dovednosti. Nahrávání, modifikace a přehrávání skriptů je velice jednoduché a díky velmi rozsáhlé dokumentaci není problém vytvořit i složitější testovací skripty a scénáře. Jednoznačně největší výhodou nástroje je velké množství lehce integrovatelných pluginů, které ještě více rozšiřují možnosti tohoto nástroje. Právě díky pluginům, které byly použity pro potřeby této práce, lze generovat kvalitní grafy pro potřeby prezentování výsledků testů zainteresovaným členům projektu.

68

7. Závěr praktické části Za předpokladu, že licence komerčních nástrojů, jakým je například HP LoadRunner, není součástí nákladů projektu a že ani žádným jiným způsobem, například dočasnou nedostupností licencí a podobně, projekt neomezuje, není na místě uvažovat o použití alternativních nástrojů. V opačném případě a v případě, že je objektem výkonnostního testování aplikace založená na webových technologiích, ke kterým lze přistupovat pomocí HTTP/S, SOAP nebo REST protokolů, lze za určitých podmínek využít jakýkoliv z nástrojů detailněji analyzovaných v praktické části. Každý z nástrojů je však vhodný k použití za zcela jiných podmínek. Není-li součástí týmu zodpovědného za vykonávání výkonnostního testování aspoň pár testerů se zkušenostmi s objektově orientovaným programováním, jen stěží bude tento tým schopný naplno využít potenciál nástroje Grinder. Lze předpokládat, že náklady spojené se získáváním zkušeností a schopností potřebných k použití tohoto nástroje by měly negativní vliv na náklady projektu. V opačném případě je naopak s nástrojem Grinder možné testovat i více technologicky náročné aplikace právě díky použitému programovacímu jazyku Jython. Co se týče prezentování výsledků testování, je nástroj Grinder ze všech analyzovaných nástrojů nejvíce strohý. Na druhou stranu je možné k tomuto účelu integrovat vlastní funkcionalitu nebo využít nějaký již z existujících nástrojů k tomu určených. Je však potřeba předpokládat, že bez pokročilejších technických dovedností může mít taková integrace negativní vliv na náklady projektu. Z ostatních analyzovaných open source nástrojů je naopak nejvíce uživatelsky přívětivý a také nejméně programátorsky náročný nástroj JMeter. Použití tohoto nástroje je i díky velmi rozsáhlé dokumentaci jednoduché a intuitivní. I s méně zkušeným týmem lze pomocí tohoto nástroje dosáhnout velice komplexní cíle testování. Tento nástroj má díky své popularitě také množství rozšiřujících pluginů, kterými lze dosáhnout ještě daleko více. Za zmínku stojí sada pluginů z projektu JMeter Plugins, která poskytuje mnoho monitorovacích funkčností, s jejíž pomocí lze vytvářet statistiky a grafy kvalitativně na úrovni referenčního nástroje HP LoadRunner. I co se týče podporovaných protokolů lze tento nástroj považovat za velice vyzrálý a konkurence schopný. Poslední z prakticky analyzovaných nástrojů OpenSTA je jakýmsi skloubením obou předchozích nástrojů. Ačkoliv je pro vývoj testovacích skriptů nutná znalost programování, 69

má tento nástroj i intuitivní uživatelské rozhraní, pomocí kterého lze nastavovat i náročnější testovací scénáře. Uživatelské rozhraní navíc podporuje aktivní monitorování průběhů testů, průběžného sledování výsledků testů a také monitorování využití lokálních a vzdálených zdrojů. Za velkou nevýhodu nástroje lze považovat jeho velmi úzkou specializaci, pozastavený vývoj a také fakt, že jej lze jen velice komplikovaně použít na dnes podporovaných operačních systémech. Jediné operační systémy nástrojem podporované jsou Windows 2000, NT 4.0, Server 2003 a XP. Nicméně v případě, že je projekt vybaven testovacími platformami právě s nějakým ze zmiňovaných operačních systémů, je tento nástroj dobrou alternativou ke komerčnímu nástroji, jakým je referenční HP LoadRunner.

70

8. Conclusion If licenses of commercial performance test tools such as HP LoadRunner are allotted for in the project budget, there is no reason to use any alternative open source tool. If this is not the case, and the application under consideration is web-based, accessible via HTTP/S, SOAP or REST protocols, it is possible to use any of the open source tools analyzed in the practical part of this work (i.e., The Grinder, OpenSTA or JMeter) instead. Each tool, however, is suitable for use under different specific conditions. In order for The Grinder tool's potential to be fully utilized, the project's performance testing team should at least comprise of a couple of senior test analysts experienced with object-oriented programming. It can be assumed that the costs related to on-boarding senior resources or upskilling junior ones to ensure effective use of this tool would significantly impact project cost. On the other hand, if the team consists of experienced developers, it is very possible to leverage on their programming skills to support the testing team in testing even technologically complex solutions and/or applications. This is thanks to the programming language, Jython, which is used for the test case and test scenarios development in this tool. Among the tools in-scope of this study, Grinder provides the least features in the aspect of presentation of test results. Furthermore, it provides the least information to support a more extensive test analyses. The only solution to this drawback is to integrate some of the already existing 3rd party solutions taking care of results presentation with The Grinder tool. Nevertheless, careful consideration should be given to such integrations as it entails additional project cost. The JMeter tool is, on the other hand, the most user-friendly and least difficult tool to use from among all of the analyzed tools in this work. The usage of this tool is even made simpler thanks to the comprehensive documentation which is formatted in a very easy and intuitive manner. With this tool, it is feasible to achieve very complex performance test objectives even with a less experienced test team. Due to JMeter's popularity, there is an abundance of available plug-ins in the market that allows for extensibility. Among those plug-ins, the product called “JMeter Plug-ins” is worthy of mention as it provides many monitoring features which enables its users to create graphs and statistics on the same quality level as the reference commercial tool, HP Load Runner. Even in terms of supported protocols and technologies, this tool can be considered as very 71

mature and competitive. OpenSTA, the last tool to be analyzed as part of this study, can be viewed as a combination of The Grinder and JMeter tools. Although some experience in SCL programming is required, the tool's user environment is very intuitive enabling its users to develop highly complex test scenarios. The user interface provides features such as active monitoring of the test run, preliminary monitoring of the test results as well as monitoring of the local and remote machine resource utilization. A downside of this tool is its very limited implementation in that, it only supports the HTTP/S protocol. Furthermore, this tool is no longer being developed or maintained and, as such, only runs on very outdated operating system versions (i.e., Windows 2000, NT 4.0, Server 2003 and XP). Nevertheless, if the project scope is limited to HTTP/S protocol and the project has access to one of the supported operating systems, then OpenSTA is a viable alternative to the reference commercial tool.

72

9. Seznam použitých zkratek Tabulka 8: Seznam použitých zkratek Zkratka AJAX AMF API CORBA EJB FTP HP HTTP/S JDBC JMS JVM KPI LDAP OSI OSS POP3 REST RMI SCL SLA SMTP SNMP SOAP SQL TCP XML

Význam Asynchronní JavaScript a XML technika používaná při vývoji Webových aplikací. Binární formát používaný k přenosu zpráv mezi Adobe Flash klientem a vzdálenými službami. Rozhraní pro programovací jazyky. Standard pro komunikaci systémů na různých platformách. Serverové komponenty umožnující modulární tvorbu podnikových aplikací. Protokol pro přenos souborů. Společnost Hewlett-Packard. Protokol pro (zabezpečenou) výměnu hypertextových dokumentů. Přístup k relačním databázím v programovacím jazyku JAVA. Služba pro přenos zpráv v JAVA rozhraní. Java virtuální stanice. Klíčové indikátory výkonnosti. Protokol pro přístup k datům na adresářovém serveru. Open source iniciativa. Open source software. Protokol pro přenos mailových zpráv. Protokol pro výměnu zpráv založených na URI. Technologie umožnující volání metod mezi JAVA virtuálními stroji. Programovací jazyk pro vývoj testovacích skriptů v nástroji OpenSTA. Dohoda o dodávce služeb. Protokol pro přenos mailových zpráv. Asynchronní protokol pro správu a monitoring stanic. Protokol pro výměnu zpráv založených na XML. Strukturovaný dotazovací jazyk. Internetový protokol transportní vrstvy. Rozšířitelný značkovací jazyk. Zdroj: Vlastní zpracování

73

10. Seznam zdrojů 10.1. Knižní zdroje GRINSHPAN L.: Solving Enterprise Applications Performance Puzzles: Queuing Models to the Rescue. 1st edition., Wiley-IEEE Press, 2012. 256 s. ISBN 978-1118061572.

SUBRAYA B. M.: Integrated Approach to Web Performance Testing: A Practitioner's Guide. IRM Press, 2006. 368 s. ISBN 978-1591407850.

74

10.2. Internetová zdroje ANDRUSCHUK BORISLAV: Grinder for Eclipse [online]. 2011. [cit. 22.02.2015]. Dostupné z URL: .

APACHE SOFTWARE FOUNDATION: Apache JMeter [online]. 2014. [cit. 20.04.2014]. Dostupné z URL: .

APACHE SOFTWARE FOUNDATION: Apache JMeter [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

APACHE SOFTWARE FOUNDATION: User's Manual [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

APACHE SOFTWARE FOUNDATION: Apache JMeter HTTP(S) Test Script Recorder [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

APACHE SOFTWARE FOUNDATION: Functions and Variables [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

ASTON PHILIP, FITZGERALD CALUM: The Grinder, a Java Load Testing Framework [online]. 2013. [cit. 20.04.2014]. Dostupné z URL: .

ASTON PHILIP, FITZGERALD CALUM: Getting Started [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: .

75

ASTON PHILIP, FITZGERALD CALUM: Scripts [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: .

ASTON PHILIP, FITZGERALD CALUM: The Grinder Documentation [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: .

ASTON PHILIP, FITZGERALD CALUM: Grinding a database with JDBC [online]. 2013. [cit. 22.02.2015]. Dostupné z URL:

BORLAND SOFTWARE CORPORATION: Silk Performer [online]. 2014. [cit. 20.04.2014]. Dostupné z URL: .

CYRANO: Getting Started [online]. [cit. 22.02.2015]. Dostupné z URL: .

CYRANO: The OpenSTA Architecture [online]. [cit. 22.02.2015]. Dostupné z URL: .

CYRANO: Getting Started [online]. [cit. 22.02.2015]. Dostupné z URL: .

CYRANO: Script Control Language Introduction [online]. 2005. [cit. 28.02.2015]. Dostupné z URL: .

CYRANO: Modeling Scripts [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: 76

.

CYRANO: User Guide Content [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: .

CYRANO: OpenSTA SCL Reference[online]. 2005. [cit. 22.02.2015]. Dostupné z URL: .

HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.: LoadRunner [online]. 2014. [cit. 20.04.2014]. Dostupné z URL: .

HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.: Tutorial [offline pdf]. 2015. [cit. 28.02.2015]. Dostupné z: .

HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.: LoadRunner User Guide [offline pdf]. 2015. [cit. 28.02.2015]. Dostupné z: .

INTERNATIONAL BUSINESS MACHINE CORP.: Rational Performance Tester [online]. [cit. 29.03.2015]. Dostupné z URL: .

JUNEAU J., WIERZBICKI F., BAKER J., SOTO L., NG V.: Chapter 12: Databases and Jython: Object Relational Mapping and Using JDBC [online]. 2010. [cit. 22.02.2015]. Dostupné z URL: .

77

MICROSOFT CORPORATION: Fáze životního cyklu produktu [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

MICROSOFT CORPORATION: Windows XP Mode [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

MICROSOFT CORPORATION: You cannot post data to a non-NTLM-authenticated Web site [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

NABBLE LLC.: Webservice Calls [online]. 2009. [cit. 22.02.2015]. Dostupné z URL: .

OPEN SOURCE INITIATIVE: Open source initiative [online]. 2014 [cit. 13.04.2014]. Dostupné z URL: .

ORACLE CORPORATION: Download Connector/J [online]. 2015 [cit. 22.02.2015]. Dostupné z URL: .

POKHILKO ANDREY et al: Custom Plugins for Apache JMeter [online]. 2014. [cit. 20.04.2014]. Dostupné z URL: .

POKHILKO ANDREY et al: Custom Plugins for Apache JMeter [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

POKHILKO ANDREY et al: Project Documentation Wiki [online]. 2015. [cit. 78

22.02.2015]. Dostupné z URL: .

PYTHON SOFTWARE FOUNDATION: Jython User Guide [online]. 2014. [cit. 22.02.2015]. Dostupné z URL: .

PYTHON SOFTWARE FOUNDATION: jython [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

RADIUMTESTING.BLOGSPOT.CZ: Opensta Performance testing tool: error 10048 opensta [online]. 2008. [cit. 22.02.2015]. Dostupné z URL: .

SMARTBEAR SOFTWARE: SoapUI [online]. 2014. [cit. 26.04.2014]. Dostupné z URL: .

SMARTBEAR SOFTWARE: LoadUI [online]. 2014. [cit. 26.04.2014]. Dostupné z URL: .

SQAFORUMS.COM: Error opening file for output [online]. [cit. 22.02.2015]. Dostupné z URL: .

THE ECLIPSE FOUNDATION: eclipse [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

TRAVIS BEAR: Grinder To graphite [online]. 2013. [cit. 22.02.2015]. Dostupné z URL: .

79

TRAVIS BEAR: Grinder Analyzer [online]. 2012. [cit. 22.02.2015]. Dostupné z URL: .

UTEST: Load Testing with OpenSTA [online]. 2015. [cit. 22.02.2015]. Dostupné z URL: .

WIKIDOT INC.: Graphite - Scalable Realtime Graphing [online]. 2012. [cit. 22.02.2015]. Dostupné z URL: .

80

10.3. Software APACHE SOFTWARE FOUNDATION: Apache JMeter 2.12 [software]. Platforma: Multiplatformní. Licence: Apache License. Dostupné z URL: .

ASTON PHILIP, FITZGERALD CALUM: Grinder 3.11 [software]. Platforma: Multiplatformní. Licence: BSD. Dostupné z .

CYRANO: OpenSTA 1.4.4 [software]. Platforma: Windows. Licence: GNU GPL. Dostupné z .

DICE: ODBC Query Tool 1.0.4 [software]. Platforma: Windows. Licence: GNU GPL. Dostupné z URL: .

DON HO: Notepad++ 6.5.5 [software]. Platforma: Windows. Licence: GNU GPL. Dostupné z URL: .

HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.: LoadRunner 12.01 Community Edition [software]. Platforma: Windows. Licence: Proprietární. Dostupné z .

POKHILKO ANDREY et al: JmeterPlugins 1.2.0 [software]. Platforma: Multiplatformní. Licence: Apache License. Dostupné z .

TSCHALAR RONALD: HTTPClient 3.11 [software]. Platforma: Multiplatformní. Licence: GNU GPL. Dostupné z .

81

TRAVIS BEAR: Grinder Analyzer V2.b19 [software]. Platforma: Multiplatformní. Licence: GNU GPL. Dostupné z URL: .

VMWARE INC.: VMware Player 6.0.3 [software]. Platforma: Windows. Licence: Proprietární. Dostupné z URL: .

82

11. Seznam ilustrací Ilustrace 1: Třívrstvá architektura enterprise aplikace.........................................................14 Ilustrace 2: Zátěž distribuovaná pomocí tří Slave stanic......................................................16 Ilustrace 3: Load test scénář.................................................................................................37 Ilustrace 4: Stress test scénář................................................................................................38 Ilustrace 5: Uživatelské rozhraní HP Virtual User Generator..............................................42 Ilustrace 6: Shrnutí výsledku výkonnostního testu vytvořeno komponentou Analysis........45 Ilustrace 7: Využití procesoru testované aplikace v průběhu Load testu s 1100 virtuálními uživateli................................................................................................................................51 Ilustrace 8: Časy transakcí naměřené Stress testem.............................................................52 Ilustrace 9: Statistiky testu v uživatelském rozhraní nástroje Grinder.................................60 Ilustrace 10: Nastavení Stress testu v uživatelském rozhraní nástroje JMeter.....................66 Ilustrace 11: Kompozitní graf s výsledky Stress testu v nástroji JMeter.............................68

83

12. Seznam tabulek Tabulka 1: Příklad často reportovaných hodnot...................................................................17 Tabulka 2: Přehled vlastností všech nástrojů.......................................................................27 Tabulka 3: Shrnutí použitích technologií v testované aplikaci.............................................30 Tabulka 4: Shrnutí uživatelských skupin..............................................................................32 Tabulka 5: Požadavky na výkon aplikace z pohledu transakcí............................................33 Tabulka 6: Shrnutí kroků testovacích scénářů......................................................................35 Tabulka 7: Shrnutí sledovaných hodnot při vykonávání výkonnostního testování..............39 Tabulka 8: Seznam použitých zkratek..................................................................................73

84

13. Seznam příloh 1. DVD obsahující analyzované nástroje, zdrojové kódy testovacích scénářů a testované aplikace, výsledky testů a testovanou aplikaci (Virtuální VMware image).

85

13.1. DVD se vstupy a výstupy praktické části

Adresář/Soubor

Obsah

eclipse_blueFruits

Adresář obsahuje zdrojové kódy k Webové službě ContentManager.

Grinder_Results

Adresář obsahuje kompletní nástroj Grinder, jehož součástí jsou testovací scripty, testovací scénáře a výsledky všech relevantních testů. Součástí adresáře je také nástroj Grinder Analyzer.

LoadRunner_Results

Součástí tohoto adresáře jsou VUGen projekt, Load a Stress testovací scénáře a také výsledky Load testovacího scénáře spustitelné v HP Analysis nástroji.

OpenSTA_Results

Adresář obsahuje OpenSTA repositář obsahující testovací scripty, scénáře a výsledky testů.

Thesis_Box

Adresář obsahuje virtuální VMware image testované stanice, na kterém běží testovaná Webová aplikace, testovaná databáze a testovaná Webová služba. Operační systém virtuální stanice je Debian 7. Administrátorské heslo operačního systému a databáze je „unicorn“.

www_bluefruits

Adresář obsahuje zdrojové kódy k testované Webové aplikaci.

db_backup.sql

Tento soubor slouží jako záloha výchozího stavu databáze bluefruits.

WS_blueFruits.war

WAR soubor obsahující Webovou službu ContentManager.

BlueFruits-soapui-project.xml SoapUI projekt s Webovou službou ContentManager.

86

UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Recommend Documents