Zátěžové testy podnikových portálů

Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod

Zátěžové testy podnikových portálů

Diplomová práce

Autor:

Bc. Pavel Lukeš Informační technologie a management

Vedoucí práce:

Praha

Ing. Bohuslav Růžička, CSc.

Duben, 2015

Prohlášení: Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze, dne 30. 4. 2015

Pavel Lukeš

Anotace Tato diplomová práce popisuje praxí ověřené postupy pro komplexní přístup k zátěţovému testování a rychlé určení kritického místa testovaného systému. Seznamuje s moţnostmi nejčastěji vyuţívaných aplikací pro provádění zátěţových testů. Klíčová slova: zátěţové testy, podnikové portály, výkon, optimalizace.

Annotation This thesis deals with describing procedures verified by practice for the complex approach to load testing and fast determination of the critical point of tested system. It introduces the possibilities of the most frequently used applications for executing of load tests. Keywords: load tests, corporate portals, performance, optimization.

Obsah Úvod ........................................................................................................................................... 7 1 Přínos zátěţových testů ........................................................................................................... 9 1.1 Chování systému při souběhu procesů ........................................................................... 10 1.2 Simulace reálných uţivatelů ........................................................................................... 11 1.3 Optimalizace a ladění výkonu systému – sníţení nákladů na provoz ............................ 12 1.4 Sledování dopadu změny v systému na jeho výkonnost ................................................ 13 1.5 Příprava na marketingovou kampaň ............................................................................... 14 1.6 Poskytnout zákazníkovi nadstandardní záţitek při pouţití podnikového systému......... 15 1.7 Zjištění dopadu DDoS útoku na systém ......................................................................... 15 1.8 Průběţné vyhodnocování kondice systému .................................................................... 16 2 Typy zátěţových testů ........................................................................................................... 17 2.1 Výkonnostní test (Performance test) .............................................................................. 17 2.2 Test hraniční zátěţe (Load/Stress test) ........................................................................... 18 2.3 Test odolnosti (Soak test) ............................................................................................... 18 2.4 Test selhání (Failover test) ............................................................................................. 19 2.5 Test části infrastruktury (Targeted Infrastructure Test) ................................................. 20 2.6 Test citlivosti sítě (Network Sensitivity Test) ................................................................ 21 2.7 Test objemu dat (Volume test) ....................................................................................... 22 3 Testovací software ................................................................................................................. 23 3.1 Základní princip .............................................................................................................. 23 3.2 Specifika webových portálů ........................................................................................... 23 3.2.1 Statické zdroje ......................................................................................................... 24 3.2.2 Dynamické zdroje .................................................................................................... 25 3.2.3 Správa sessions ........................................................................................................ 25 3.2.4 Pouţité technologie ................................................................................................. 26 3.2.5 Zabezpečení ............................................................................................................. 26 3.3 Terminologie .................................................................................................................. 26 3.3.1 Schématické znázornění .......................................................................................... 27 3.4 Potřebné dovednosti ....................................................................................................... 28 3.4.1 Tvorba skriptu ......................................................................................................... 28 3.4.2 Nastavení scénáře .................................................................................................... 30 3.4.3 Provedení testu ........................................................................................................ 31 3.4.4 Zobrazení výsledků ................................................................................................. 31 4

3.5 Instalované systémy ........................................................................................................ 32 3.5.1 Testovací nástroj Loadrunner .................................................................................. 33 3.5.2 Testovací nástroj JMeter.......................................................................................... 37 3.5.3 Testovací nástroj SmartMeter.................................................................................. 42 3.5.4 Testovací nástroj Gatling ......................................................................................... 45 3.6 Cloudové systémy........................................................................................................... 47 3.6.1 Výhody .................................................................................................................... 47 3.6.2 Nevýhody ................................................................................................................ 48 4 Ţivotní cyklus zátěţového testu ............................................................................................ 49 4.1 Návrh testů ...................................................................................................................... 50 4.1.1 Definice scénářů ...................................................................................................... 50 4.1.2 Definice kritérií pro vyhodnocení testu ................................................................... 50 4.1.3 Vyhodnocení proveditelnosti a pracnosti testu........................................................ 51 4.2 Provádění ........................................................................................................................ 51 4.2.1 Příprava testovacích dat ........................................................................................... 51 4.2.2 Příprava nástrojů pro obnovu dat ............................................................................ 52 4.2.3 Tvorba skriptů ......................................................................................................... 52 4.2.4 Vývoj/konfigurace pomocných programů ............................................................... 52 4.2.5 Konfigurace prostředí pro provedení testu .............................................................. 53 4.2.6 Vytvoření scénářů .................................................................................................... 53 4.2.7 Provádění testu ........................................................................................................ 54 4.2.8 Vytvoření reportu testu a archivace ......................................................................... 54 4.3 Hlášení a vyhodnocení.................................................................................................... 54 4.3.1 Vyhodnocení testu ................................................................................................... 54 4.3.2 Analýza testovaného systému.................................................................................. 55 4.4 Obnova stavu systému .................................................................................................... 55 4.4.1 Obnova testovacích dat............................................................................................ 55 4.4.2 Obnova testovaného systému .................................................................................. 55 5 Určení kritických míst systému ............................................................................................. 57 5.1 Typické pouţívané architektury ..................................................................................... 57 5.1.1 Vše na jednom serveru ............................................................................................ 57 5.1.2 Aplikace a databáze na vlastním serveru................................................................. 58 5.1.3 Horizontálně škálované aplikační servery ............................................................... 59 5.1.4 Akcelerovaný aplikační server ................................................................................ 60 5.1.5 Replikovaná databáze .............................................................................................. 61 5.2 Analýza výsledků zátěţových testů ................................................................................ 62 5

5.3 Profilování aplikace ........................................................................................................ 68 5.4 Monitoring systému ........................................................................................................ 70 5.5 Analýza logů ................................................................................................................... 72 6 Ověřené postupy z praxe ....................................................................................................... 74 6.1 Evidence stavu prostředí ................................................................................................. 74 6.2 Spouštění porovnatelných testů ...................................................................................... 74 6.3 Testy Proof-of Conceptů ................................................................................................ 75 6.4 Ověření prostupnosti jednotlivých vrstev ....................................................................... 75 6.5 Určení délky náběhové hrany ......................................................................................... 76 6.6 Sledování grafů ............................................................................................................... 78 6.7 Zvýšení výkonu systému ................................................................................................ 78 6.8 Zvýšení prostupnosti Load Balanceru ............................................................................ 80 Závěr ......................................................................................................................................... 85 Seznam pouţité literatury ......................................................................................................... 87 Seznam pouţitých obrázků ....................................................................................................... 90 Seznam příloh ........................................................................................................................... 92 Příloha A – Slovník pojmů ......................................................................................................... 1

6

Úvod Cílem této práce je popsat zátěţové testy podnikových portálů a uvést důvody, proč se jimi zabývat. Práce přiblíţí přínosy zátěţových testů, nejen z technického, ale i z obchodního hlediska. Popíše jejich základní členění a typický ţivotní cyklus. Dále budou uvedeny základní typy a rozdíly mezi aplikacemi pouţívanými pro zátěţové testování. Na základě autorovy několikaleté praxe s laděním a testováním sloţitých bankovních a korporátních systémů, budou popsány osvědčené způsoby pro rychlé nalezení oblasti obsahující kritické místo. Pomocí profilovacích nebo monitorovacích systémů bude ukázáno, jak určit problematickou oblast v kódu aplikace. Existuje několik důvodů, proč se zvyšují poţadavky na rychlost i spolehlivost webových systémů. Vyuţívání internetu jako obchodního kanálu je dnes samozřejmostí pro stále větší počet firem. Nemusí se jednat pouze o internetové obchody různého typu. Online sluţby také častěji vyuţívají banky, pojišťovny i telefonní operátoři. Řada firem nabízí pro své klienty online samoobsluţné zóny. Dokonce i sázkové kanceláře mohou nabízet online způsob sázení. Online systémy jsou integrovány s řadou dalších firemních aplikací a databází. Společné části tedy mohou vyuţívat návštěvníci internetového portálu, i zaměstnanci v rámci intranetu. Poskytované online sluţby i firemní webové prezentace jsou propagovány pomocí reklamních kampaní. Není výjimkou, ţe v průběhu kampaně, nebo těsně po ní dosahuje návštěvnost a tedy i zatíţení systémů mnohonásobku běţného provozu. Stejně tak jako narůstá mnoţství online sluţeb, zvyšuje se i počet uţivatelů, kteří je vyuţívají. Dokonce k tomu pouţívají různá zařízení. Počítače a notebooky dnes doplňují chytré telefony a tablety. Rychlost i kvalita připojení mobilních zařízení dosud nedosahuje standardů klasických pevných připojení. Uţivatelé i přesto očekávají stabilní a rychlé vyřizování poţadavků, které vyvolávají. Pro uspokojení velkého mnoţství současně připojených uţivatelů je k dispozici řada řešení. Online systém je zpravidla provozován na celé farmě serverů. Vyuţívá se často horizontálního škálování (viz kapitola 5.1.3). Pro úsporu výkonu se mnohdy vyuţívají různé

7

krátkodobé paměti – cache1. V případě Cloudových a virtualizovaných řešení se výkon systému můţe měnit dle potřeb i za jeho chodu. Řešení se běţně skládá z mnoha vzájemně propojených částí přes různé síťové prvky. Vyuţívají různorodý hardware a řadu technologií, které zajišťují správné rozdělení všech poţadavků a udrţení kontextu pro kaţdého aktivního uţivatele. Současně posiluje trend portálů, které dokáţí v rámci jedné obrazovky spojit zobrazení výstupů z několika systémů zároveň a upravovat vzhled a skladbu obrazovek dle poţadavků uţivatele. Sloţitost řešení dosahuje takových rozměrů, ţe uţ není moţné rozvrhnout nastavení a konfiguraci všech prvků s jistotou, ţe bude vše rychlé, stabilní a efektivně vyuţitelné. Pro ověření, zda je vše dostatečně výkonné, a také ţe přetíţení systému nezpůsobí nečekané zpomalení, pád, nebo dokonce poškození některé z částí celého systému, se vyuţívají právě zátěţové testy. Simulací chování uţivatelů dojde k zatíţení systému, při kterém je moţné sledovat a měřit jeho odezvy. Postupným navyšováním počtu simulovaných uţivatelů je moţné nacházet limity systému. Po kaţdé provedené změně lze pomocí testů ověřit její dopad na rychlost a spolehlivost. To umoţňuje vyhodnotit, zda je změnu moţné nasadit i na produkční verzi systému. Zátěţové testy se dnes stávají standardem, který umoţňuje s vysokou úrovní bezpečnosti a spolehlivosti provozovat firemní online systém. Odkrývají, kam sahají jeho výkonnostní hranice a jak se zachová, pokud dojde k jejich překročení.

1

Cache – Vyuţívají se pro uloţení načtených dat z různých zdrojů do krátkodobé paměti. Při dalším poţadavku na stejná data dojde k rychlému vrácení informací z paměti bez zatěţování dalších vrstev. [48 strana 208]

8

1 Přínos zátěžových testů Hlavním přínosem zátěţových testů je spolehlivý systém a spokojený návštěvník. Při provozování online systému, který generuje zisk, je účelem minimalizovat finanční ztráty z důvodu nefunkčnosti a zvýšit spokojenost zákazníků kvalitou a rychlostí systému. To, ţe má smysl se rychlostí a kvalitou systému zabývat i pro zvýšení obchodní úspěšnosti, dokazuje řada statistik [2]: Statistiky pro internetové obchody: – 44 % lidí u pomalých stránek ztrácí důvěru ve spolehlivost. – Uţivatel si dobu načítání stránek pamatuje o 35 % delší. – Odezva nad 5 vteřin je vnímána jako velice pomalá. – 51 % nakupujících uvádí pomalost jako hlavní důvod k opuštění online obchodu. – 18 % nakupujících opouští i naplněný košík pokud je web pomalý. – 46 % uţivatelů uvádí rychlost nákupu jako hlavní kritérium rozhodující, zda se do obchodu vrátit. – Stránky s odezvou nad 6 vteřin mají o 50 % větší míru opuštění. Statistiky pro mobilní zařízení: – 16 % nákupů je realizováno z mobilního telefonu. – 64 % uţivatelů očekává odezvu pod 4 vteřiny. – 89 % uţivatelů očekává odezvu jako na Desktopu. – 79 % nákupů v chytrém telefonu je realizováno přes Desktop verzi. – 55 % stráveného času v obchodu vytvoří uživatelé mobilních zařízení. – 43 % uţivatelů zamíří na web konkurence při negativním záţitku. Z výše uvedeného je patrné, ţe pečlivá optimalizace pomáhá úspěšně dokončit započatý obchodní případ i zajistit loajalitu zákazníků, zejména v dnešní uspěchané době. Z pohledu vývoje systému je moţné zátěţové testy pouţívat pro zlepšení různých oblastí. Vţdy záleţí na charakteru systému i časových a finančních moţnostech, do jaké míry bude zátěţovými testy pokryt. Pro přesnější informaci o přínosech na různých úrovních slouţí následující podkapitoly.

9

1.1 Chování systému při souběhu procesů Zátěţové testy dokáţí odhalit řadu slabin v systému, zároveň pomohou ověřit, zda je připraven na souběh více současně probíhajících procesů. Webové systémy jsou zpravidla vyuţívány mnoha uţivateli současně. To, ţe to umoţňují, je jejich veliká přednost. Jeden udrţovaný systém je provozován na výkonné infrastruktuře a uţivatelé ho pouţívají pomocí takzvaných tenkých klientů neboli internetových prohlíţečů. Sám internetový prohlíţeč dokáţe vyvolávat směrem k systému řadu asynchronních volání, tedy i pro jednoho uţivatele můţe být vytvořeno více poţadavků současně. Tento princip je uplatňován především pro statické zdroje, tedy obrázky, JavaScripty2 a kaskádové styly3 (více o statických souborech je uvedeno v kapitole 3.2.1). Asynchronně mohou být volány také funkce z webového rozhraní, coţ často vyuţívají moderní systémy. K vytvoření takového volání se vyuţívá například AJAX4. Samotná aplikace pak můţe obsahovat funkce, které nejsou optimalizovány pro souběh více vláken současně. Ačkoli mívá kaţdý uţivatel webového systému vlastní session5, můţe pouţívat společné funkce s jiným uţivatelem. Není-li taková situace v systému dobře ošetřena, můţe dojít k chybě, nebo nesprávnému zpracování poţadavku. Také můţe dojít k prodlouţení doby odezvy některého z poţadavků, který čeká, neţ se poţadavek jiného uţivatele zpracuje. Takové chování není při testech s jedním uţivatelem patrné. Nemusí být odhaleno ani při testování menší skupinkou testujících uţivatelů. V systému bude vyvoláváno více souběţných poţadavků, ale šance, ţe se sejdou v jedné konkrétní funkci, je velice malá. Pro robustní řešení jsou často vyuţívány distribuované systémy. Pro jejich provoz je vyuţito více instancí systému a předřazený prvek Load Balancer6, který na jednotlivé instance 2

JavaScript – interpretovaný programovací jazyk pro WWW stránky i výsledný skript, který se odesílá se stránkou na klienta (do prohlíţeče) a teprve tam je vykonáván. [41] 3

Kaskádové styly - kolekce metod pro grafickou úpravu webových stránek. Slovo kaskádové vyjadřuje jejich schopnost vrstvit na sebe definice stylu pro jednotlivé prvky. [9] 4

AJAX - Asynchronous JavaScript and XML – technologie, která umoţňuje měnit obsah stránek bez jejich kompletního znovunačtení, za pomoci asynchronního zpracování poţadavků. [4] 5

Session - v protokolu HTTP umoţňuje webovému serveru ukládat libovolné informace o kaţdém uţivateli, který k němu přistupuje. [36] 6

Load Balancer – chová se jako reverzní Proxy a rozděluje síťový nebo aplikační provoz na více serverů. [27]

10

rozděluje poţadavky. Díky tomu je lépe vyuţita výpočetní síla, a souběţné poţadavky můţe zpracovávat více serverů. Dochází i ke zvýšení spolehlivosti, protoţe se jednotlivé instance dokáţí zastupovat. Moţností zapojení a konfigurací je více, některé budou zmíněny v kapitole o typických architekturách (kapitola 5.1). Velkým přínosem zátěţového testování je moţnost ověření, zda Load Balancer dokáţe efektivně vyuţívat jednotlivé instance systému. Také jestli dochází ke správnému předávání poţadavků uţivatelů na servery, které udrţují jejich aktivní session. Dále je moţné ověřit, jak se systém zachová, pokud dojde k přetíţení a případnému vypnutí jedné z instancí systému. Více o takto zaměřených testech je v kapitole 2.4 věnující se testům selhání. Souběh více konkurenčních procesů je pro webové portály naprosto běţný a měl by být prvním důvodem k provedení zátěţového testu.

1.2 Simulace reálných uživatelů Zátěţové testy nabízí odpověď na otázku, jakou návštěvnost dokáţe systém unést či při jakém počtu uţivatelů se jeho rychlost nebo spolehlivost začne zhoršovat. Záleţí na typu systému a očekávaném vyuţití, aby bylo moţné rozhodnout jak komplexní, a tedy i časově náročný test simulující reálné uţivatele připravit. Při simulaci reálných uţivatelů dokáţí testovací systémy pracovat s definovaným počtem uţivatelů v čase testu. Můţe být stanovena křivka, která určuje, kolik uţivatelů se v který okamţik do testu zapojí a budou současně provádět průchod testovacím skriptem [x]. Je tedy moţné simulovat náběhovou křivku, která odpovídá realitě, ale také nárazové chování, které systém zaţívá v konkrétních časových špičkách. Pro co nejreálnější simulaci skutečných uţivatelů je zapotřebí co nejpřesněji definovat, jak se uţivatelé v systému chovají. Je moţné vytvořit více různých skupin a kaţdou z nich nechat procházet vlastní testovací skript. Pro získání informací o poţadavcích stávajícího systému je moţné vyuţít aplikační logy, například access log7, který zaznamenává informace

7

Access log - soubor, do kterého jsou na straně serveru ukládány záznamy o všech zpracovaných poţadavcích. [28]

11

o kaţdém poţadavku. Dále je moţné vyjít z informací v monitorovacích a analytických systémech, dostačující bývají i informace z Google Analytics8. Správně vytvořený test dokáţe s poměrně velikou přesností odhalit, při jakém počtu uţivatelů dochází ke změnám chování systému a nalézt okamţik, kdy začínají být jeho reakce nedostačující. Během testu je také moţné vyvolat spuštění různých dávkových zpracování, nebo jiných náročných operací, které systém vykonává na pozadí. Tím dojde k ověření, jaký dopad má vytvořená zátěţ na chování systému pro uţivatele, který s ním pracuje. Další uţitečná funkce testovacích aplikací je předstírání různé rychlosti připojení pro jednotlivé skupiny simulovaných uţivatelů. Díky tomu je moţné měřit délku odezvy například pro uţivatele, kteří k systému přistupují přes mobilní telefon.

1.3 Optimalizace a ladění výkonu systému – snížení nákladů na provoz Velikou přidanou hodnotou zátěţových testů je odhalování slabin systému, nebo výkonově neoptimálních částí. Zátěţový test sám o sobě nenabízí odpověď, co v systému způsobuje nestabilitu, sníţenou odezvu nebo jeho zkolabování. Je ale schopen problém opakovatelně vyvolávat.

Některé

aplikace

pro

zátěţové

testování

jsou

integrované

s různými

monitorovacími systémy a díky tomu dokáţí zobrazit mnohem přesnější informace o konkrétním poţadavku a jeho průchodu testovaným systémem. Tomuto tématu je věnována kapitola 5.4. Díky ladění a odstraňování chyb ve výkonově náročných částech a funkcích systémů je moţné optimalizovat hardwarové nároky na provoz a vytvořit tak dostatečnou rezervu pro spolehlivý chod systému. Vyladěný systém vystačí s méně výkonnou infrastrukturou. Tak je moţné ušetřit na nákupu, pronájmu, licencích atp. Pro výkonově optimalizovanou aplikaci je ideální začít s testy jiţ v průběhu vývoje. Je-li kaţdá část systému podrobena testům v rané fázi, je snadnější a rychlejší najít slabé místo a jednodušší je i jeho oprava. Při testování kompletní aplikace se řada výkonově

8

Google Analytics - nástroj od společnosti Google, který umoţňuje získávat statistická data o uţivatelích webu. Zobrazení dat je k dispozici pouze oprávněným osobám. [19]

12

neoptimálních částí systému můţe schovávat „za sebou“ a pak je potřeba odkrývat jednu po druhé. To je časově náročnější nejen na analýzu oblasti, která problém způsobuje, ale také na komunikaci ohledně nálezu. Ta můţe navíc probíhat mezi mnoha vývojovými týmy. Zátěţové testy se běţně pouţívají pro testování jednotlivých částí systému. Dokáţí komunikovat přes celou řadu rozhraní. Často se pouţívají pro testy webových sluţeb (SOAP9, RESTful10), databází atp.

1.4 Sledování dopadu změny v systému na jeho výkonnost Pokud je výkonnost systému dostatečná, je pomocí zátěţových testů moţné ověřovat, zda libovolná změna nemá negativní dopad na výkonnost některé jeho části. Testy je moţné spustit po kaţdé změně, nejčastěji pak: Po nasazení nové verze systému. Po aplikaci konfigurační změny v systému. Po změně nastavení aplikačního serveru, na kterém je systém provozován. Po změně verze kterékoli části systému, nebo aktualizaci operačního systému, aplikačního serveru, databáze atp. Po změně mnoţství dat, které systém spravuje, nebo se kterými pracuje. Nejčastěji pak po hromadném importu dat do databáze. Pro sledování dopadu změny na výkonnost systému je důleţité provést tzv. referenční běh testu. Tedy test, který změří odezvu systému před provedenou změnou. Díky těmto referenčním hodnotám je moţné velice přesně porovnat dopad změny provedením testu po aplikaci změny. Porovnání naměřených hodnot je moţné provádět i v prostředí, které není výkonově shodné s produkčním. Na takovém prostředí je výsledek testu vţdy pouze orientační. Dojde-li ke změně odezvy, je velice pravděpodobné, ţe bude reakce aplikace odlišná i po nasazení do ostrého provozu.

9

SOAP - protokol pro posílání XML zpráv mezi dvěma aplikacemi. Pracuje na principu peer-to-peer. [42]

10

RESTful – rozhraní systému vyuţívající principy Fieldingovi REST architektury. Je pouţitelné pro jednotný a snadný přístup k datům i stavům aplikace přes protokol HTTP nebo HTTPS. [35]

13

Testy je moţné provádět i v pravidelných intervalech. Často jsou součástí systému průběţné integrace11 (angl. Continuous Integration). Mohou být tedy spuštěny automaticky po procesu sestavení a nasazení aplikace. Čím kratší interval je mezi jednotlivými testy, tím lépe je moţné určit, která provedená změna měla dopad do výsledků testu. Pravidelné a systematické provádění zátěţových testů je nejlepší pojistkou před náhlým a nečekaným zhoršením výkonu aplikace. Eliminuje riziko, že systém se zhoršenou kvalitou výkonu bude nasazen do produkčního prostředí a způsobí jeho nestabilitu, kolaps nebo negativní uţivatelský záţitek při jeho pouţívání.

1.5 Příprava na marketingovou kampaň Marketingová kampaň můţe mít řadu podob. Jejím výsledkem je velmi často zvýšená návštěvnost webových stránek, nebo online systémů. Je-li cílem kampaně zvýšení návštěvnosti na konkrétních stránkách, je moţné pomocí zátěţového testu ověřit, zda jsou stránky na takovou zátěţ připraveny. Je-li kampaň plánovaná jako krátkodobá, můţe stačit dočasné posílení výkonu sytému. Zátěţový test dokáţe ověřit, zda je výkon zvýšen dostatečně a zda konfigurace systému umoţňuje jeho efektivní vyuţití. Stránky, na které je kampaň směrována, se nazývají Landing Page. Test těchto stránek by měl být proveden před kampaní vţdy. Pokud by systém zkolaboval, nebo by byla jeho reakce příliš pomalá, můţe dojít k negativnímu pocitu návštěvníka. Kampaň pak můţe mít opačný dopad, neţ bylo očekáváno a náklady na ni vynaloţené jsou ztracené. Výhodou testů, které se zaměřují na testování konkrétních stránek, je rychlost vytvoření a tedy i náklady na jejich provedení. Takovýto test je možné připravit během několika minut. Často je moţné, někdy dokonce nutné, ověření přímo na produkčním prostředí, které je dostupné z internetu. Není tedy potřeba vytvářet prostupy nebo zavádět servery testovacího systému do interní infrastruktury. Test je moţné provést z prostředí poskytovatele Cloudového sluţby pro generování virtuálních uţivatelů (viz kapitola 3.6).

11

Průběţná integrace - metoda vývoje software, kde kaţdý vývojář integruje svoji část práce průběţně. Kaţdá integrace je ověřena automatickými testy k co nejrychlejšímu nalezení chyb. [34]

14

1.6 Poskytnout zákazníkovi nadstandardní zážitek při použití podnikového systému Online systém je uţivateli vnímán jako rozhraní, přes které je v kontaktu s firmou. Jeho spolehlivost a rychlost je v podstatě vizitka firmy. Jak je uvedeno v příkladech statistik, rychlost webu má přímou vazbu na spokojenost návštěvníka a je jedním z hlavních kritérií, na základě kterých se rozhoduje, zda se na webové stránky vrátí. Proto dnes řada firem přistupuje k online systému jako k platformě, která musí být co nejvíce uţivatelsky přívětivá, intuitivní a musí mít rychlé reakce. Pro splnění těchto poţadavků vzniká i řada technologických řešení a standardů, které tento trend podporují. Pro rychlý systém nestačí pouze výkonný server. Optimalizaci je potřeba řešit i v oblasti mnoţství stahovaných dat či počtu poţadavků, které jsou vytvářeny směrem k systému a to i s ohledem na různá rozlišení nebo schopnosti pouţívaných prohlíţečů. Skutečně rychlé jsou ty systémy, které mají rychlost jako jedno z hlavních kritérií již v samotném návrhu. Takové systémy pouţívají moderní technologie na úrovni klienta i serveru a dokáţí pruţně reagovat na výpadek v některé části systému tak, aby návštěvník nezpozoroval, ţe došlo k jakékoli komplikaci. Některé testovací systémy nabízí moţnost definovat SLA12 na rychlost odezvy. Je tedy moţné měřit, zda odezva webového rozhraní odpovídá definovaným kritériím. Rychlost můţe být také sledována u kaţdého z poţadavku, a pokud překročí definovaný čas, můţe být poţadavek vyhodnocen jako „nevyhovující“. Veškeré naměřené údaje jsou pak součástí statistik výsledného reportu z testu.

1.7 Zjištění dopadu DDoS útoku na systém Mnoţící se DDoS13 útoky jsou nepříjemnou hrozbou. Do určité úrovně datového toku se jim dá poměrně účinně bránit pomocí řady řešení. Jejich eliminace je sloţitější problematika,

12

SLA - Service-level agreement, dohoda o úrovni poskytovaných sluţeb. Vznikla potřebou co nejpřesněji definovat rozsah, úroveň a intenzitu sluţeb poskytovaných dodavatelem zákazníkovi. Můţe obsahovat i garantovanou rychlost odezvy systému. [39] 13

DDoS - Distributed Denial of Service, je technika útoku na internetové sluţby nebo stránky, při níţ dochází k přehlcení poţadavky a pádu nebo minimálně nefunkčnosti a nedostupnosti pro ostatní uţivatele. [12]

15

která přesahuje rámec této práce. Z pohledu zátěţového testování je podstatné, ţe i DDoS útok je moţné předstírat pomocí testu. Řada řešení má ochranu proti DDoS útokům. Poţadavky generované útočníkem jsou tedy okamţitě odhaleny a zahazovány. Proto je potřeba testovací servery, které zátěţ generují, vyjmout z ochrany před DDoS útokem. Poté lze vyzkoušet, jak by systém dopadl, pokud by se poţadavky dostaly aţ na jeho rozhraní. V tomto testu není podstatné, jak systém na poţadavky reaguje. Hlavní je ověřit, ţe nastane vyčerpání zdrojů, které jsou konfiguračně záměrně nastaveny. Ačkoli systém přestane reagovat, nenastane neočekávané vyřazení některé jeho části z provozu, nebo poškození dat či některé části infrastruktury. Test tedy slouží primárně k ověření, že po ukončení útoku bude systém znovu zcela funkční bez jakéhokoli zásahu. Pro simulaci DDoS útoku mají systémy pro zátěţové testování často speciální módy. Ty umoţňují generovat velké mnoţství poţadavků, ale jejich výsledkem se nezabývají. Díky tomu dochází k úspoře výkonu na straně serverů generujících zátěţ a vytvoření většího počtu poţadavků za vteřinu. Další moţností je navazování velkého počtu spojení se systémem, coţ vede k vyčerpání maximálního povoleného počtu souběţných spojení. Tím dojde k vyřazení funkčnosti systému pro ostatní uţivatele. Během testu je moţné velice pomalu stahovat data s odpovědí ze systému. Dojde tak k vytvoření mnoha otevřených spojení a vyčerpání maximálního povoleného počtu souběţných poţadavků k serveru. Příprava testu pro zjištění dopadu DDoS útoku není sloţitá. Jedná se o jednoduché a tedy i málo nákladné testy, které ale velice reálně znázorní, zda systém útok zvládne bez újmy.

1.8 Průběžné vyhodnocování kondice systému Zátěţový test můţe být pouţit i pro průběţné monitorování kondice systému. Můţe být spouštěn v pravidelných intervalech a jeho výsledky mohou poslouţit ke sledování trendu výkonu systému či porovnání výkonu různých období. V malém počtu uţivatelů můţe být spuštěn i nad produkčním prostředím a zobrazovat rychlost systému při různé reálné návštěvnosti, zvyšujícím se objemu dat či dlouhodobém spuštění systému. V případě, ţe bude test zaměřen na různé části celého systému, tedy na jednotlivé aplikace, integrační vrstvy a databáze, mohou jeho výsledky rovnou navést na problematickou oblast.

16

2 Typy zátěžových testů Zátěţové testování je prováděno s cílem zjistit, jak bude testovaná aplikace reagovat na více současně probíhajících procesů. Samotný test můţe mít mnoho podob, a můţe cílit na různé části systému. Důleţité také je, zdali hledáme slabé místo celého systému, nebo se testem snaţíme zaměřit na konkrétní oblast. Reálná aplikace čelí různým typům zatíţení. Záleţí na trendech chování uţivatelů, ale také na procesech, které se odehrávají na jejím pozadí. Dnes je řada systémů provozována ve virtualizovaném prostředí, které dokáţe dynamicky měnit přirazené prostředky pro jednotlivé instance serverů. Výkon aplikace tedy můţe být závislý i na zatíţení jiných provozovaných systémů ve stejném Cloudovém prostředí. Podobné je to i u sdílených částí systémů. Typicky je to fyzická infrastruktura, datové sítě, síťové prvky, ale také například databáze, které mohou být společné pro více provozovaných systémů. Zátěţovým testem tedy nemusíme řešit pouze konkrétní systém nebo aplikaci, ale parametry celého prostředí. Pro horizontálně škálované systémy (viz kapitola 5.1.3) jsou také určeny speciální typy testů, které dokáţí zjistit, jak se chovají při zatíţení, nebo nečekaném vyřazení některé jeho části mimo provoz. Nejčastěji jsou zátěţové testy rozděleny do kategorií, kterým se věnují následující podkapitoly.

2.1 Výkonnostní test (Performance test) Nejčastějším zátěţovým testem je tzv. výkonnostní test, anglicky nazývaný Performance test. Cílem testu je podrobit systém definované zátěţi a měřit jeho chování. Test simuluje skupinu, nebo skupiny uţivatelů, které postupně volají poţadavky podle definovaného skriptu [xiii]. Jejich zapojení do testu bývá určeno tzv. náběhovou hranou. Virtuální uţivatelé [xvii] se do testu připojují postupně a dochází tak k časovému rozloţení činností, které provádějí. Díky tomu nejsou všechny funkce ze skriptů volány současně a simulace se blíţí k reálnému zatíţení aplikace běţnými uţivateli.

17

Výkonnostní test se nejčastěji pouţívá pro změření reakcí očekávané zátěţe, nebo porovnání vlastností systému před a po provedené změně. Je také součástí Performance tuningu14. V tomto procesu je test opakovaně spouštěn a mezi jednotlivými testy jsou aplikovány změny. Po kaţdém testu dochází k porovnání a zhodnocení výhodnosti změny. Tento postup umoţňuje provést veliké mnoţství pokusů a vede často k velice rychlému nalezení vhodné varianty kódu a nastavení aplikace i prostředí.

2.2 Test hraniční zátěže (Load/Stress test) Test hraniční zátěţe, který se anglicky nazývá Load/Stress test, slouţí k nalezení hraničního počtu současných virtuálních uţivatelů, při kterém dochází k překročení akceptovatelných poţadavků, nebo vyřazení systému mimo provoz. Tento test tedy hledá odpověď na otázku, kolik současných uţivatelů můţe systém obslouţit, ale také jakou zátěţ vydrţí konkrétní oblast systému. Test nemusí představovat scénář [xii] vycházející z reálného chování uţivatelů, můţe se zaměřovat pouze na konkrétní funkci či část systému. Testem hraniční zátěţe také dochází k nalezení nejslabšího místa v systému. V takovém případě je často test vykonáván aţ do okamţiku, kdy systém přestane reagovat na poţadavky. Následně je analýzou logů, monitorovacích systémů a pomocí dalších analytických nástrojů vyhledána konkrétní oblast, která způsobila neschopnost reagovat na poţadavky. Více informací o způsobech určení kritického místa je v kapitole 5.

2.3 Test odolnosti (Soak test) Řada online systémů je v nepřetrţitém provozu. Aplikace ale nemusí být schopna dlouhodobě efektivně vyuţívat přidělené prostředky. Nejčastěji dochází k problémům v oblasti uvolňování paměti, kterou aplikace vyuţila pro zpracování některé vykonané funkce, ale následně nedošlo ke kompletnímu odstranění objektů nebo hodnot, které do paměti uloţila. Výsledkem můţe být postupné zahlcování operační paměti aţ do okamţiku, kdy aplikace pro její

14

Performance tuning – proces za účelem zlepšení výkonu systému. Prováděním zátěţových testů je měřena reakce systému. Pomocí úpravy a změny softwarových, hardwarových a síťových prvků dochází k úpravám systému a měření dopadu změny na výkon. [30]

18

nedostatek zkolabuje. Pro ověření, zda aplikace dokáţe dlouhodobě vykonávat svoji činnost, slouţí zátěţový test odolnosti, anglicky nazývaný Soak test. Tímto testem dochází k simulaci reálného chování uţivatelů, ale po velice dlouhou dobu. Primárně jsou sledovány přidělené zdroje systému a jejich efektivní uvolňování. Pro tuto činnost bývají vyuţívány různé monitorovací a profilovací systémy. Hodnoty bývají sledovány na více úrovních, například přímo v aplikačním serveru, databázi i operačním systému. Díky tomu je lépe odhalitelné skutečné hospodaření se zdroji a snáze se dohledává problematická oblast.

2.4 Test selhání (Failover test) Dojde-li k selhání některé části systému, nemusí to nutně znamenat jeho kompletní vyřazení z provozu. Dnes jsou často řešení stavěna tak, aby i při kompletním výpadku jedné infrastruktury ji okamţitě zastoupila záloţní, mnohdy provozovaná v jiné lokalitě a tedy i z jiného datového centra15. Řešení můţe být také záměrně připraveno na postupné odstavování jednotlivých serverů. Jejich údrţba pak probíhá ve chvíli, kdy na ně nejsou směrovány ţádné poţadavky od uţivatelů a do provozu jsou vráceny zpět po provedení plánovaných úprav. Takto je moţné postupně provést údrţbu všech serverů, aniţ by to uţivatel systému zpozoroval. Toto řešení má tedy jistě své nesporné výhody a přispívá ke spolehlivosti fungování celého systému. Je s ním ale spojena i řada problémů k vyřešení. Především pak zachovávání session aktivních uţivatelů. Způsobů jak uchovávat session a replikovat je mezi jednotlivými instancemi serverů je více. Zda je nastavení v pořádku a dokáţe rychle reagovat i během většího zatíţení serverů, je moţné otestovat zátěţovým testem. Stejně tak je důleţité ověřit, zda provoz systému dokáţe obslouţit maximální počet očekávaných současně přistupujících uţivatelů i v případě, kdy dojde k výpadku nebo odstavení některého ze serverů. Klasickým příkladem nepodchycené situace je pak kaskádové vyřazení všech serverů poté, co došlo k vyřazení prvního z nich. Všechny poţadavky, které původně obsluhoval vyřazený server, musí zpracovat jiný, nebo jsou rozděleny na zbývající servery. Je-li takových poţadavků mnoho,

15

Datové centrum – místo s konektivitou k internetu, ve kterém je moţné provozovat servery, datová úloţiště a další prvky ICT infrastruktury. [11]

19

můţe to znamenat přetíţení a vyřazení celého systému z provozu, nebo postupné přetěţování jednotlivých serverů aţ do stavu, kdy postupně dojde k vyřazení všech. Z tohoto důvodu se doporučuje chování systému otestovat testem selhání, kdy dojde k vytvoření maximální zátěţe a poté k úmyslnému vyřazení jednoho či více serverů z provozu. Dále se dá testem selhání, který se anglicky nazývá Failover test, ověřit, jak rychle se systém zotaví, pokud během plné zátěţe proběhne jeho restart. Po restartu mohou být prázdné systémové cache (dočasné paměti) a veškeré poţadavky musí být plnohodnotně zpracovány. Systém si také musí nově zpřístupnit řadu zdrojů, jako je operační paměť, ale také připojení do databáze a na různé další systémy, se kterými komunikuje. To můţe znamenat, ţe nově nastartovaný systém nedokáţe pod zátěţí zpracovat všechny poţadavky a hrozí jeho zkolabování, nebo zhoršení rychlosti jeho reakcí. Nastane-li takový stav na produkčním prostředí, můţe být jeho řešení velice problematické. Často je potřeba nahradit rozhraní systému informací o jeho vyřazení mimo provoz, poté ho bez zpřístupnění uţivatelům nastartovat a postupně na něj uvolňovat poţadavky návštěvníků, nebo jeho inicializaci dopomoci tzv. „zahřátím“ pomocí zátěţového testu. Není-li takové řešení k dispozici, je nutné počkat aţ do období, kdy je návštěvnost niţší a umoţní přirozené nastartování systému. To s sebou ale často nese značný ušlý zisk a řadu frustrovaných návštěvníků. Je tedy lepší se na podobnou situaci připravit pomocí testů selhání.

2.5 Test části infrastruktury (Targeted Infrastructure Test) U sloţitějších systémů, které se skládají z více vzájemně integrovaných částí, je pro nalezení slabého místa moţné připravit zátěţové testy, které se zaměřují na jednotlivé oblasti. Nejčastěji se jedná o testy mířící přímo do „back end“ systémů16, komunikující přes jejich rozhraní a dále do integračních vrstev a databází. Tyto testy jsou sloţitější na přípravu. Nevyuţívají poţadavky webového rozhraní, které se dají často jednoduše získat pomocí speciálních programů, které zaznamenávají veškerá proběhlá volání mezi prohlíţečem a serverem. Vyuţívají zprávy, které mohou být podle některého ze standardu (často SOAP, RESTful, JDBC apod.), ale také mohou vyuţívat

16

Back end – část systému, která je provozována na serveru či serverech a není určena pro přímou komunikaci s uţivatelem. Uţivatel pro práci se systémem vyuţívá Front end vrstvu aplikace, která předává poţadavky na Back end vrstvu. [16]

20

specifické zprávy, pomocí kterých „back end“ systémy komunikují. Získání těchto zpráv můţe být sloţitější, stejně tak jako jejich úprava, pro opakovatelné pouţití. Veliká výhoda těchto testů je v mnohem větší přesnosti při zjišťování, která z částí systému má největší vliv na výkonnost celku. Má-li být některá z částí infrastruktury vyuţívána pro novou aplikaci, je moţné testem ověřit, zda současná konfigurace bude výkonově dostačující. V případě sdílení společných částí mezi systémy dokáţe jedna aplikace přetěţující jedinou část systému způsobit zpomalení všech systémů, které jsou s ní integrovány a pouţívají její rozhraní pro zpracování některých poţadavků.

2.6 Test citlivosti sítě (Network Sensitivity Test) Online systémy jsou provozovány nejčastěji na síti internet, pro interní pouţití pak v intranetových sítích. Veškeré síťové komponenty mají svoji maximální propustnost, ale skutečné hodnoty je potřeba ověřit měřením. Nejde ale pouze o objem dat, který je moţné v čase přenést, záleţí i na tom, kolik paralelních poţadavků můţe být zpracováváno a jak rychle je v síti vytvořeno nové spojení. Kvalita sítě není zásadní pouze mezi webovým prohlíţečem a systémem, ale také v rámci jednotlivých systémových částí. Záleţí na počtu integrací a typech protokolů, přes které systém komunikuje. Zásadní dopad má i zabezpečení sítě a celkový návrh architektury. Pro testy citlivosti sítě, anglicky nazývané „Network Sensitivity Test“ jsou typické scénáře, které zkoušejí maximální propustnost dat, dále pak vytvoření předpokládaného paralelního počtu připojení, pomocí kterých jsou stahovány malé i velké soubory. Důleţité je, aby docházelo k vytvoření spojení stejným protokolem a zabezpečením, které je typické pro reálně provozovaný systém. Rozhraní se dále testují na očekávaný počet poţadavků za vteřinu, bez ohledu na sloţitost následného zpracování. Aţ ve chvíli, kdy dokáţe celá infrastruktura splnit očekávané poţadavky na propustnost, je moţné pokračovat v testování samotných systémů a případné výkonové problémy hledat ve výkonu aplikací, nikoli na síťové úrovni.

21

2.7 Test objemu dat (Volume test) Většina systémů pracuje s daty, která jsou ukládána v databázích. Dnes jsou velmi rozšířené relační databáze, ale velikou oblibu pro určité typy dat získávají i tzv. NoSQL17 databáze. Je-li v systému málo dat, nejsou zpravidla databázové operace výkonově náročné. Podle implementace jednotlivých operací ale můţe docházet ke zpomalování, je-li databáze vyuţívána více vlákny současně. Při vykonání některých operací dochází k zamykání určitých oblastí v databázi a ostatní poţadavky, které do nich přistupují, musí vyčkat, aţ dojde k odemčení přístupu. To se začne projevovat na rychlosti práce s databází. Pokud se objem dat v databázi začne zvyšovat, mohou se prodluţovat i časy jednotlivých operací. Případně i délky zámků a tedy i čekání ostatních poţadavků. S objemem dat roste zpomalení práce s databází i z principu jejího fungování, pro zrychlení operací vyuţívá různé dočasné paměti (cache). Pokud obsahuje velké mnoţství dat, nemusí stačit operační paměť pro všechny cache a práce s databází tak bude pomalejší. Pro změření, zda jsou všechny operace dostatečně optimalizované i pro očekávané mnoţství dat, která bude databáze obsahovat, slouţí právě test objemu dat, anglicky nazývaný Volume test. Testem se ověří reakce aplikace ve stavu, kdy je dat méně a opakovaně pak ověří její rychlost po naplnění většího mnoţství dat. Dojde-li ke zhoršení výkonu nad akceptovatelnou mez, je potřeba hledat výkonově výhodnější cestu k práci s daty. Testem je moţné ověřovat, zda došlo k nápravě.

17

NoSQL - databázový koncept, ve kterém datové úloţiště i zpracování dat nepouţívají tabulková schémata tradiční relační databáze. [29]

22

3 Testovací software Některé z testů aplikací či systémů mohou provádět přímo uţivatelé, kteří dle instrukcí provádějí jednotlivé kontroly a porovnávají výsledky s předpoklady. Zátěţové testy ale vyţadují velké mnoţství uţivatelů, kteří souběţně provádějí nadefinované činnosti v testovaném systému. Proto jsou vyuţívána softwarová řešení, která dokáţí uţivatele simulovat. Specializované programy pro zátěţové testy jsou schopné vytvořit stovky aţ statisíce současných simulovaných uţivatelů. Je moţné vyuţít volně dostupné programy, i velmi komplexní a profesionální systémy. K dispozici jsou i online systémy, provozované jako sluţba. Ty je moţné vyuţít k vytvoření a spuštění zátěţového testu bez potřeby instalace a zavádění systému do vlastní infrastruktury.

3.1 Základní princip Testovací nástroje pro zátěţové testy webových systémů musí dokázat vytvořit stovky aţ statisíce současných virtuálních uţivatelů [xvii]. V současnosti dostupná výpočetní technika není schopná vytvořit tolik oken webových prohlíţečů a v nich simulovat chování uţivatelů. Proto se vyuţívá zachycování poţadavků, které uţivatel při pouţívání webového systému vytváří. Testovací nástroj tedy neprovádí klikání v prohlíţeči, ale v definovaném sledu volá nahrané poţadavky, které byly získány v době vytváření skriptu [xiii]. Některé poţadavky, které v době nahrávání splňovaly všechny náleţitosti pro úspěšné zpracování v testovaném systému, mohou být při dalším pouţití neplatné. V takovém případě je nutné získaný skript upravit tak, aby i při opakovaném zavolání splňoval vytvořený poţadavek všechna kritéria, a testovaný systém provedl jeho zpracování stejně, jako v době vytváření skriptu.

3.2 Specifika webových portálů Webové systémy nabízí standardizované rozhraní, které je pro automatizaci testů zpravidla velice dobře pouţitelné. Pro správnou přípravu, nastavení testu ale i samotný výběr nástroje je potřeba znát některá specifika, o kterých pojednává tato kapitola. 23

3.2.1 Statické zdroje Důleţité je, jakým způsobem systém poskytuje statické zdroje (tedy obrázky a další soubory s neměnícím se obsahem). Mnohdy jsou vraceny prohlíţeči přímo z pevného disku serveru, aniţ by jejich fyzické umístění muselo být vyhledáno v aplikaci či databázi. Další často pouţívanou moţností jsou cache (viz kapitola 5.1.4), které vrácený zdroj po definovanou dobu drţí v paměti. Díky tomu dokáţí statický zdroj vracet mnohem rychleji. Často vyuţívaný cachovací systém je například Varnisch, ale můţe být vyuţita i vlastní implementace. Největší riziko přináší poskytování statických zdrojů pomocí aplikace, která pro jejich načtení musí získat informace nebo i celý statický zdroj z databáze. V takovém případě je při načítání i poměrně jednoduché stránky vytvořeno několik paralelních připojení do databáze a hrozí, ţe dojde k jejich vyčerpání. V případě, ţe se statický zdroj, především pak JavaScript nebo definice kaskádových stylů, nepovede načíst do prohlíţeče, můţe se systém stát pro uţivatele zcela nepouţitelným (nemusí se zobrazit správné prvky, nebo nemusí reagovat na pokyny uţivatele). Webový prohlíţeč si dokáţe načtené soubory uchovávat v lokálním úloţišti (podle definice hlaviček statických zdrojů). Je-li takto uloţený soubor opět potřeba zobrazit, dojde k načtení z úloţiště prohlíţeče bez nutnosti nového stahování. Toto chování je v testu potřeba zohlednit, jinak by mohlo dojít ke generování větší neţ reálné zátěţe. Během zátěţového testování hrají statické zdroje specifickou úlohu. Je sloţité předpokládat, kolik reálných uţivatelů přistoupí k webovým stránkám s uloţenými statickými zdroji a kolik uţivatelů si tato data teprve vyţádá. Opomíjení těchto souborů v testech by nám mohlo zakrýt problém s propustností datového toku, protoţe statické soubory mají v celkové velikosti webové stránky často majoritní podíl. Dále také vytvářejí zátěţ na Load Balancerech, discích a síťových prvcích. Testovací nástroje proto většinou nabízejí v rámci nastavení scénáře [xii] volbu, zda má či nemá docházet ke stahování statických zdrojů. Díky tomu je moţné jednoduše vyzkoušet více variant, při kterých dochází k úplnému aţ ţádnému stahování statických zdrojů. Tak je moţné vyhodnotit, jaký je jejich dopad na rychlost celého webového systému.

24

3.2.2 Dynamické zdroje Dynamický zdroj obsahuje informace, které musí webová aplikace získat či vypočítat. Nejčastěji na základě zaslaných parametrů, uloţených informací v paměti či databázi. Také můţe být potřeba zavolat další systém nebo systémy či provést sloţitý výpočet, nebo kombinaci uvedeného. Získat informaci pro sestavení odpovědi můţe být výkonově velice náročné. Protoţe dynamické zdroje mohou vracet různá data, není moţné je ukládat do paměti prohlíţeče. V jistých případech je ale moţné jejich cachování (ukládání do dočasné paměti) na straně serveru. To je moţné aplikovat například v okamţiku, kdy je výsledek shodný pro stejné vstupní parametry nebo jiné shodné podmínky. Pro vytváření testu je tedy velice důleţité vědět, které volání musí obsahovat stále měnící se parametry atp. Při nesprávné přípravě testu můţe být generovaná zátěţ jiná, neţ při zatíţení skutečnými uţivateli.

3.2.3 Správa sessions Webové systémy fungují nejčastěji tak, ţe po prvním navázání spojení webového prohlíţeče se systémem dojde k zaloţení session na straně serveru. K uţivateli je poté vrácena tzv. HTTP cookie18, která prohlíţeči sdělí ID session. Tedy jedinečné ID, které webový prohlíţeč zasílá jako součást kaţdého dalšího poţadavku. Na základě tohoto ID systém ukládá na straně serveru data pro uţivatele a slouţí i k udrţení jeho identifikace. Není tedy zásadní, zda je uţivatel přihlášen, například pomocí jména a hesla, či nikoliv [46 strana 51]. U běţné webové aplikace je session na straně aplikačního serveru vytvořena pro kaţdého uţivatele. Znalost tohoto chování je důleţitá při vytváření testu, který simuluje mnoţinu reálných uţivatelů. Pokud pro vytvoření zátěţe vyuţijeme software, který nedokáţe vytvořit dostatečný počet současných virtuálních uţivatelů [xvii], není řešením menšímu počtu uţivatelů zvýšit rychlost jejich aktivity. Přestoţe na systém směřuje odpovídající počet poţadavků, není vytvořen odpovídající počet uţivatelských session. Tím dochází k menšímu vyuţití operační paměti

18

HTTP cookie – součást hlaviček zasílaných mezi serverem a klientem (prohlíţečem). Pokud server poţádá o uloţení dat, které posílá v cookies, dojde v prohlíţeči k uloţení a následnému odesílání společně s kaţdým poţadavkem směrem k serveru, který o uloţení poţádal. [21]

25

a také nemusí dojít k objevení konfiguračních limitů, které omezují počet paralelních aktivních session či definují za jakých podmínek session zaniká. Testem tedy nemusí být odkryta řada nedostatků, které v reálném provozu mohou mít fatální dopad na chod systému a jeho spolehlivost.

3.2.4 Použité technologie Pro tvorbu rozhraní webového systému mohou být vyuţity různé technologie. Jejich podpora ale nemusí být na straně testovacího nástroje. Jedná se například o Flash, Flex, Java Applet či další pluginy, které mohou být součástí webových prohlíţečů. Před výběrem testovacího nástroje je tedy potřeba provést analýzu, zda dokáţe simulovat poţadavky na všechny části testovaného systému, jeţ mají být pokryty zátěţovým testem.

3.2.5 Zabezpečení Webové systémy mohou komunikovat po zabezpečených protokolech. Při zahájení komunikace probíhá mezi webovým prohlíţečem a webovým systémem proces, který se nazývá Handshake a slouţí ke vzájemné výměně certifikátů a definování způsobu vzájemné komunikace. Mezi další způsoby zabezpečení mohou patřit různé Proxy servery, přes které můţe komunikace z webového prohlíţeče probíhat. Dále můţe být webový systém zpřístupněn pouze po zadání jména a hesla do „Basic access authentication“, tedy standardu, pro jednoduchý způsob zabezpečení pomocí jména a hesla [7]. Způsob komunikace a zabezpečení musí být testovacím systémem podporován, aby bylo moţné navázat komunikaci s webovým systémem během testu. Také je ale důleţité, aby testovací systém dokázal přes zabezpečení získat poţadavky a vytvořit z nich skript v době jeho tvorby. Jinak by mohlo být nutné vytvářet všechny poţadavky ve skriptu ručně.

3.3 Terminologie Pro testovací systémy není zavedena jednotná terminologie. Pro zjednodušení popisu a orientace budou pouţity nejčastěji pouţívané termíny, které jsou souhrnně uvedené v příloze „Příloha A – Slovník pojmů“ této práce. Na uvedené pojmy bude v textu pro lepší přehlednost odkazováno. 26

3.3.1 Schématické znázornění Test Scénář (Příklad: testování e-shopu) Skupina virtuálních uživatelů 1 Skupina virtuálních uživatelů 2 (Příklad: Průzkumnící)

(Příklad: Nakupující)

Skript 1

Skript 2

(Příklad: Procházení katalogu)

(Příklad: Proces nákupu)

Virtuální uživatel 1-1

Virtuální uživatel 1-2

Virtuální uživatel 1-x

Virtuální uživatel 2-1

Virtuální uživatel 2-2

Virtuální uživatel 2-y

Aktuální transakce (Příklad: úvodní stránka)

Aktuální transakce (Příklad: kategorie zboţí)

Aktuální transakce (Příklad: detail zboţí)

Aktuální transakce (Příklad: vloţit do košíku)

Aktuální transakce (Příklad: výběr dopravy)

Aktuální transakce (Příklad: objednat)

Počet uţivatelů a prováděné transakce se mění s časem

Obrázek 1 – Terminologie částí vykonávaného testu, zdroj: vlastní

Kontrolér Generátor Testovaný systém Data server Agent

Obrázek 2 – Terminologie komponent testovacího systému, zdroj: vlastní

27

3.4 Potřebné dovednosti Potřebné dovednosti vycházejí z ţivotního cyklu zátěţového testu, kterému je věnována kapitola 4. Komplexní systémy nabízí softwarovou podporu především v části přeměny definice chování simulovaného uţivatele do skriptu [xiii], nastavení, provedení a vyhodnocení testu. Levnější nebo zdarma dostupné programy se zaměřují především na část provedení testu.

3.4.1 Tvorba skriptu Pro tvorbu skriptu testu vyuţívající rozhraní webové aplikace, se pouţívají speciální programy – nahrávače [ix]. Tyto programy bývají součástí všech aplikací pro zátěţové testy. Zaznamenávají poţadavky jdoucí z webového prohlíţeče směrem k testovanému systému. Většina nahrávačů dokáţe provádět automatizované úpravy zaznamenaných poţadavků jiţ během jejich ukládání. Díky tomu výrazným způsobem šetří čas při následné úpravě nahraného skriptu [xiii]. Jedná se především o tyto schopnosti: Přenést poţadavky z komunikace mezi klientem a serverem do „jazyka“ nástroje. Výstupem z nahraných poţadavků je předpřipravený skript. Ten je dále moţné upravovat v rozhraní systému pro jeho úpravu. Rozdělit poţadavky podle jejich charakteru. Nejčastěji se jedná o oddělení statických zdrojů, které se pro některé testy vynechávají (viz kapitola 3.2.1). Převést binární obsah zpráv do textové podoby pro moţnou úpravu jejich obsahu během testu. Tato funkce se vyuţívá především pro volání protokolu AMF19, jenţ pro komunikaci pouţívají aplikace vytvořené v technologii Flash a Flex. Ty mohou být součástí webového rozhraní (viz kapitola 3.2.4). Uzavřít poţadavky vyvolané jednou akcí (například kliknutím na odkaz nebo tlačítko) uţivatele do transakcí [xvi]. Tyto transakce jsou pak zobrazovány a měřeny jako celek, coţ je pro úpravu skriptu i analýzu výsledků přehlednější.

19

AMF Protokol – umoţňuje zasílání binárních zpráv, které obsahují serializované objekty. [3]

28

Vloţit mezi jednotlivé kroky uţivatele čas čekání. Jedná se o období, během kterého uţivatel nevyvolává interakce s webovým rozhraním. Nejčastěji je moţné zadat konkrétní hodnotu času, po kterou bude virtuální uţivatel čekat, neţ zahájí další krok. Automaticky provést korelaci parametrů [viii]. Automaticky vkládat kontrolu správnosti obsahu zprávy vrácené ze systému. Tedy na základě nalezeného textu ve zprávě vytvořit prvek, provádějící v rámci běhu testu kontrolu, zda zpráva obsahuje očekávaný text. Dojde tak k ověření, ţe došlo ke správnému zpracování volání. Nejčastěji je u webových stránek kontrolována hodnota textu v HTML tagu