VÝKONNOSTNÍ TESTOVÁNÍ WEBOVÝCH APLIKACÍ

VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ BRNO UNIVERSITY OF TECHNOLOGY

FAKULTA INFORMAČNÍCH TECHNOLOGIÍ ÚSTAV INFORMAČNÍCH SYSTÉMŮ FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS

VÝKONNOSTNÍ TESTOVÁNÍ WEBOVÝCH APLIKACÍ

DIPLOMOVÁ PRÁCE MASTER’S THESIS

AUTOR PRÁCE

Bc. LUKÁŠ MARTINÁK

AUTHOR

VEDOUCÍ PRÁCE SUPERVISOR

BRNO 2012

Ing. RADEK BURGET, Ph.D.

Abstrakt Tato práce se zabývá testováním softwaru, konkrétně výkonnostním testováním webových aplikací. V úvodních kapitolách je nastíněna problematika testování – od vysvětlení obecných pojmů testování a kvality softwaru, označení klíčových problémů, přes zasazení testování do životního cyklu vývoje softwaru, srovnání testování webových a desktopových aplikací, až po výkonnostní testování. Poté je zvolena vhodná webová aplikace k testování (Kentico CMS 6), následovaná představením a srovnáním existujících nástrojů pro výkonnostní a zátěžové testování, z nichž je jeden vybrán pro pozdější testování (Microsoft Visual Studio 2010 Ultimate Edition). Dále jsou navrženy scénáře výkonnostních testů a ukázka jejich implementace (vytváření, úpravy a ladění, rozšiřování, správa, spouštění v distribuovaném prostředí, atd.). V závěru jsou představeny reporty z testování a návrh dalšího rozšíření testů.

Abstract This thesis is about software testing and mainly focused on performance testing of web applications. The introductory chapters outline problems of testing, identification of key issues, explanation of general concepts and software quality, differences between desktop and web application testing and finally – performance testing. Then, there is chosen a web application suitable for testing (Kentico CMS 6) and comparison of existing tools for performance and load testing. One of them (Microsoft Visual Studio 2010 Ultimate Edition) is chosen for the further testing. Therefore, several test scenarios are designed and implemented (including demonstration of creating, editing and debugging, extending with plug-ins, maintaining, running in a distributed environment, etc.). Finally, there are introduced testing reports and suggestions for the further testing.

Klíčová slova Testování a kvalita softwaru, webové aplikace, výkonnostní a zátěžové testování, nástroje pro testování, Kentico CMS, Microsoft Visual Studio 2010

Keywords Software testing and quality, web applications, performance and load testing, performance testing tools, Kentico CMS, Microsoft Visual Studio 2010

Citace Lukáš Martinák: Výkonnostní testování webových aplikací, diplomová práce, Brno, FIT VUT v Brně, 2012

Výkonnostní testování webových aplikací Prohlášení Prohlašuji, že jsem tuto diplomovou práci vypracoval samostatně pod vedením Ing. Radka Burgeta, Ph.D. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal.

…………………… Lukáš Martinák 17. května 2012

Poděkování Děkuji svému vedoucímu za hodnotné připomínky a společnosti Kentico software za pochopení, podporu a HW i SW vybavení nezbytné pro vypracování této práce.

© Lukáš Martinák, 2012 Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.

Obsah 1

Úvod ............................................................................................................................................... 2

2

Testování webových aplikací ......................................................................................................... 3

3

4

5

6

7

8

2.1

Testování a kvalita softwaru ................................................................................................... 3

2.2

Testování součástí životního cyklu SW .................................................................................. 8

2.3

Webové vs. desktopové aplikace ............................................................................................ 9

2.4

Výkonnostní a zátěžové testování......................................................................................... 11

Volba webové aplikace ................................................................................................................ 13 3.1

Redakční systémy ................................................................................................................. 13

3.2

Kentico CMS 6 ..................................................................................................................... 14

3.3

Kentico software ................................................................................................................... 18

Nástroje pro výkonnostní a zátěžové testování ............................................................................ 20 4.1

Existující nástroje ................................................................................................................. 20

4.2

Definice požadavků a představení nástrojů .......................................................................... 21

4.3

Konečný výběr testovacího nástroje ..................................................................................... 29

Vytvoření testovacího prostředí ................................................................................................... 30 5.1

Software ................................................................................................................................ 30

5.2

Hardware............................................................................................................................... 30

Návrh testovacích scénářů ........................................................................................................... 32 6.1

Statický web – ladění aplikace.............................................................................................. 32

6.2

Dynamický obsah – ladění databáze ..................................................................................... 33

6.3

Webová analytika (návštěvníci, aktivity) ............................................................................. 33

6.4

Chat modul............................................................................................................................ 33

Testování webů pomocí VS 2010 ................................................................................................ 34 7.1

Webové výkonové testy ........................................................................................................ 34

7.2

Zátěžové testy ....................................................................................................................... 42

7.3

Spouštění testů ...................................................................................................................... 46

7.4

Implementace rozšíření ......................................................................................................... 49

7.5

Zpracování výsledků ............................................................................................................. 50

Výsledky testování ....................................................................................................................... 52 8.1

Výsledky jednotlivých scénářů ............................................................................................. 52

8.2

Další možná rozšíření testů ................................................................................................... 54

8.3

Problémy při testování a zpracování výsledků ..................................................................... 54

8.4

Co se odladilo v průběhu testování ....................................................................................... 55

9

Závěr ............................................................................................................................................ 57

10

Citovaná literatura ........................................................................................................................ 58 1

1

Úvod

Testování je nezbytnou součástí každého softwarového projektu a pokud má být softwarový produkt kvalitní, nestačí mu dobrý návrh a implementace, musí být i dobře otestovaný. Tato diplomová práce se zaměřuje na testování webových aplikací, protože jsou tyto aplikace stále na vzestupu a jejich testování stojí softwarové firmy nemalé peníze. Stejně jako se dá na testování ušetřit, tak se dá i prodělat, pokud není testování dostatečné a výsledný produkt není dodán v očekávané kvalitě. Právě na definici kvality a testování se podíváme ve druhé kapitole, kde také rozebereme různé druhy testování, chyb, zasazení testování do životního cyklu softwaru a rozdíly mezi testováním desktopových a webových aplikací. Třetí kapitola je zaměřena na výběr webové aplikace vhodné pro testování. Nakonec byl zvolen redakční systém Kentico CMS 6 od brněnské firmy Kentico software, protože redakční systémy jsou jednou z nejlepších ukázek webových aplikací. Ve čtvrté kapitole se seznámíme s existujícími nástroji pro výkonnostní a zátěžové testování, vybereme tři z nich (Apache JMeter, Microsoft Visual Studio 2010 a Microsoft WCAT), postupně si je představíme a vzájemně srovnáme. Nakonec vybereme nástroj (Visual Studio) pro testování Kentico CMS 6. Pátá kapitola se věnuje přípravě testovacího prostředí a po ní následuje šestá kapitola, zabývající se návrhem testovacích scénářů. V sedmé kapitole je popsáno vytváření webových výkonových testů ve Visual Studio 2010 včetně jejich úprav, ladění, vytváření vlastních rozšíření, udržování a zařazování do zátěžových testů, stejně jako jejich spouštění v distribuovaném prostředí a zpracování výsledků. Osmá kapitola pak prezentuje výsledky testování, upozorňuje na problémy, které během testování vznikají a navrhuje další rozšíření testů. Zatímco cílem semestrálního projektu bylo seznámení s problematikou testování, výběr vhodné webové aplikace a nástroje pro její testování, cílem diplomové práce je doplnit semestrální projekt, vytvořit pomocí konkrétního nástroje výkonnostní testy pro konkrétní aplikaci, ukázat jejich výsledky a po zhodnocení výsledků navrhnout jejich další rozšíření.

2

Testování webových aplikací

2

V této kapitole se budeme částečně věnovat testování obecně (definujeme si základní pojmy týkající se testování a kvality softwaru), podíváme se na to, jak testování zapadá do životního cyklu softwaru a pochopitelně si řekneme něco o výkonnostním a zátěžovém testování.

2.1

Testování a kvalita softwaru

Definicí testování je mnoho a odpovědí na tuto otázku tak může být opravdu hodně, přičemž žádná z nich nemusí být špatná. Na testování je totiž možné nahlížet z mnoha pohledů (od analytiků až po koncové zákazníky a uživatele) a jejich pohledy se liší už z principu. Co však mají společné, je to, že proces testování nějakým způsobem patří do procesu ověřování a zajišťování kvality. Potom je však potřeba určit, co je to kvalita a jsme v podobné situaci. Vzhledem k tomu, že je software vytvářen za nějakým účelem, resp. aby pokryl nějakou potřebu, kvalitou rozumíme to, do jaké míry je software pro daný účel vhodný a do jaké míry dokáže danou potřebu uspokojit. Testování tedy můžeme popsat jako zkoumání softwaru za účelem odhalení chyb. Jakým způsobem se software zkoumá a co je považováno za chybu už je zase na konkrétním výkladu. Jenom je potřeba dát si pozor na to, aby se definice chyby nevázala pouze na specifikaci softwaru, protože bychom se mohli dostat do situace, kdy bychom žádnou specifikaci neměli a nemohli bychom tak vlastně ani testovat (nikdy bychom nenalezli chybu). Zatímco je testování prostředkem pro hledání a odhalování chyb, nelze jím zařídit jejich nepřítomnost. K tomu bychom potřebovali formální matematický důkaz, což je pro drtivou většínu softwaru momentálně nepředstavitelné. Při testování tak musíme počítat s následujícím: 

Ať se testuje jakkoli dlouho, vždycky tam zůstanou nějaké chyby.



Není možné pokrýt úplně všechny případy užití.



Některé chyby je velice obtížné odhalit a jejich odhalování se třeba ani nevyplatí.



Specifikace, oproti které se testuje, bývá často neúplná, matoucí nebo prostě chybí.



Stejný druh testování odhaluje stejné chyby, proto je vhodné jej doplňovat jiným.



Testování vhodné pro jeden produkt nemusí být vhodné pro jiný.



Regresní testy je potřeba automatizovat anebo omezit (jinak se časem přestanou vyplácet).

V souvislosti s testováním je ještě důležité si uvědomit, kdy už je vhodné přestat. Následující obrázek ukazuje závislost nákladů na testování a počtu nalezených chyb na počtu provedených testů.

3

Obrázek 2.1: Optimální počet provedených testů [1]

Jak je z obrázku patrné, nízký počet provedených testů znamená nízké náklady na testování, ale vysoké množství nenalezených chyb. Čím více testů se bude provádět, tím více chyb se bude nacházet, ale budou růst náklady na testování. V určitém bodě už se však nacházení dalších chyb vzhledem k nákladům na testování nevyplatí.

2.1.1

Druhy testování a chyb

Jak již bylo zmíněno, testování slouží k odhalování chyb. Chyby se také dají nazývat různě (bugy, defekty, problémy, selhání, atp.) a každý člověk může daným názvem myslet něco jiného. To už je potom na domluvě zainteresovaných osob (návrhář, vývojář, tester, zákazník, atd.), aby používali společný slovník. Obecně je chyba softwaru faktorem, který snižuje hodnotu/kvalitu softwaru. Podle Pattona [1] se za chybné chování dají označovat situace, kdy: 

Software nedělá něco, co by podle specifikace dělat měl.



Software dělá něco, co by podle specifikace dělat neměl.



Software dělá něco, o čem se specifikace nezmiňuje.



Software nedělá něco, o čem se specifikace sice nezmiňuje, ale měla by se zmiňovat.



Software je obtížně srozumitelný, těžko se s ním pracuje, je pomalý nebo (podle názoru testera) jej koncový uživatel nebude považovat za správný.

Dále se tedy podíváme na to, jakým způsobem se chyby dají odhalovat. Automatické a manuální testování Toto rozdělení je poměrně jasné – manuální testování zajišťuje člověk sám, automatické potom provádí nějaký softwarový nástroj. Manuální testování je potřeba zejména tam, kde je zapotřebí lidského pohledu (například při testování designu, přehlednosti uživatelského rozhraní, snadnosti použití, atp.) nebo při provádění složitých scénářů, které prostě není možné z nějakého důvodu 4

automatizovat. Automatické testy by se měly nasazovat v případě, že je nutné daný test provádět opakovaně nebo s velkým množstvím rozličných dat. Důležitým faktorem však zůstává cena, takže si musíme odpovědět na otázku, zda budou automatické testy v konečném součtu levnější než jejich manuální provádění. Černá a bílá skříňka Při tomto rozdělení testování záleží na tom, zda má tester k dispozici zdrojové kódy (znalost vnitřního fungování). Pokud tester vidí do vnitřní implementace, potom se jedná o testování bílé skříňky (angl. white box, glass box, transparent box), v opačném případě pak černé skříňky (angl. black box). Je vhodné oba přístupy kombinovat, protože metoda černé skříňky umožní testerovi použít více vlastní fantazii (na dané vstupy systém nějak reaguje) a jeho pohled není zkreslen tím, co vidí v implementaci. Na druhou stranu je metoda bílé skříňky výhodná v tom, že testera mohou napadnout další testovací scénáře pouhým zkoumáním zdrojového kódu. Statické a dynamické testování Testování můžeme dále rozdělovat na statické a dynamické, přičemž při statickém testování se zaměřujeme pouze na zdrojový kód, aniž bychom museli danou aplikaci spouštět – to je výhodné především v rané fázi vývoje a také se tím šetří spousta času (instalace, spouštění). Dynamické testování vyžaduje spuštění softwaru a zaměřuje se více na jeho vstupy/výstupy. Testovací mix Při testování je velice vhodné kombinovat všechny výše uvedené přístupy, protože každý z nich se zaměřuje na jiný druh chyby.

2.1.2

Software Quality Model (ISO 9126) a FURPS+

Mezinárodní norma ISO 9126-1, jejíž výtah můžeme najít na [2], označuje 6 hlavních charakteristik kvality – funkcionalitu (vhodnost k danému účelu, přesnost výstupů, schopnost komunikace s okolím, dodržování norem a doporučení, nepovolení neautorizovaného přístupu), spolehlivost (vyspělost – frekvence výpadků, schopnost zotavení z výpadků), použitelnost (pochopitelnost uživatelem, učící křivka, schopnost použití v různých prostředích), efektivitu (rychlost odpovědi, využití

systémových

prostředků),

udržovatelnost

(analyzovatelnost,

měnitelnost, stabilita,

testovatelnost) a přenositelnost (instalovatelnost, přizpůsobitelnost, nahraditelnost). My se však více zaměříme na model FURPS+, který pochází od firmy Hewlett-Packard a je ve světě softwarových projektů velice rozšířený pro vytváření požadavků a ukazatelů kvality [3; 4]. Jednotlivá písmenka reprezentují určitou oblast požadavků, postupně si je všechny uvedeme, popíšeme a ukážeme, jaký způsob testování do dané oblastí zapadá.

5

Functionality (funkcionalita) Tato oblast se zabývá funkčními požadavky, tedy požadavky na funkcionalitu softwaru, jeho hlavní vlastnosti a chování. Tyto požadavky mohou být velice technické (např. použití SHA-2 pro ukládání uživatelských hesel), ale i méně technické – např. „Po kliknutí na odkaz Přidej do košíku se daný produkt vloží do nákupního košíku, kterému bude přepočítána jeho celková cena a upravený počet položek“. Funkční požadavky vznikají z mnoha oblastí – od bezpečnosti, dokumentace a nápovědy, přes licencování a lokalizace, až k nejrůznějším workflow. Funkční testy mohou provádět testeři sami podle předem zadaných scénářů (jednotlivé testovací případy (test-cases) mohou vycházet z případů užití (use-cases)), anebo se pro takové testování vytvářejí automatické testy, ať už se jedná o jednotkové testy (unit tests) na úrovni kódu nebo funkční testy uživatelského rozhraní (web tests, UI tests). Pro funkční testování existuje celá řada nástrojů, jmenovat můžeme například Microsoft Visual Studio, Rational Functional Tester, Selenium, Telerik Test Studio, SmartBear TestComplete, aj. Usability (použitelnost) Druhá oblast se zabývá požadavky na použitelnost software. Jedná se především o požadavky na uživatelské rozhraní – přístupnost (ovládání pomocí klávesových zkratek, dostatečný kontrast barev, atd.), estetiku (grafický design, barevné provedení, vhodnost použití jednotlivých prvků rozhraní k danému účelu), konzistenci (pojmenování stejné akce stejným jménem v celém rozhraní), atp. Použitelnost je velice obtížně testovatelná, zahrnuje totiž uživatelské cítění a každý uživatel ho má jiné. Snahou je zpřístupnit software co největšímu počtu uživatelů a zavděčit se jejich většině, případně zacílit na určitý segment uživatelů. Každý uživatel má na software jiné nároky a bude se mu zdát nějakým způsobem použitelný. Pro webové stránky existují pravidla přístupnosti, které zaštiťuje iniciativa Web Accessibility Initiative (WAI) konsorcia W3C. U nás jsou například definována pravidla přístupného webu (http://www.pravidla-pristupnosti.cz/), kterými se musí řídit státní webové stránky a je doporučené jejich používání pro jakýkoli web. Takže je možné testovat podle nějakého předpisu nebo obecně známých doporučení, ale automaticky testovatelná je z pochopitelných důvodů pouze část těchto požadavků. Reliability (spolehlivost) Požadavky na spolehlivost zahrnují dostupnost, přesnost výsledků, schopnost zotavení z různých výpadků, atd. Dostupnost je často udávaná jako „počet devítek“ – procento času, které je daný systém dostupný, přičemž do nedostupnosti se počítají nejen pády a restarty systému, ale i jeho aktualizace a údržba.

6

Z pohledu testování je důležité zejména to, jak se projevuje výpadek systému, jak se aplikace z výpadku zotavuje, jak dlouho trvá obnova ze zálohy a opět se dostáváme k tomu, že taková data je poměrně obtížné získat automatickým procesem. Tabulka níže ukazuje maximální dobu mimo provoz v jednom roce, aby byla zajištěná daná dostupnost: Dostupnost 99% (dvě devítky) 99,9% (tři devítky) 99,99% (čtyři devítky) 99,999% (pět devítek)

Celková doba ve výpadku (za rok) 87 hodin 8,76 hodin 52,6 minut 5,26 minut

Tabulka 2.1: Tabulka dostupnosti software[5]

Performance (výkonnost) Tato kategorie nás bude v této práci zajímat zřejmě nejvíce. Jde o požadavky na propustnost systému, jeho odezvu v různých situacích (což také souvisí s použitelností), rychlost zotavení (což souvisí s dostupností), využití systémových prostředků a například i dobu prvního spuštění aplikace. O výkonnostním testování si řekneme více v kapitole 2.2, poté se v kapitole 4 podíváme na to, jak se zorientovat mezi dostupnými nástroji a nakonec si tři z nich ukážeme podrobněji. Supportability (podporovatelnost) Podporovatelnost je široká oblast požadavků zaměřená například na testování, udržovatelnost, spravovatelnost, zajištění zpětné kompatibility, konfigurovatelnost, škálovatelnost, lokalizovatelnost, atd. Z pohledu testování může jít především o čistotu systémového návrhu (například dodržování nějaké štábní kultury (coding rules), návrhových vzorů (design patterns), všeobecných doporučení, atp.). + (další požadavky) Tyto další požadavky představují zejména nejrůznější omezení z odlišných pohledů. Například z pohledu implementace a návrhu je to programovací jazyk, framework, platforma, použité nástroje pro vývoj a testování, typ databáze, atd., nutnost použití určitého rozhraní – zejména kvůli vazbám na další systémy, fyzická omezení – hardwarové požadavky na provoz (například velikost serverovny/datacentra) a potom mnohá další omezení jako např. licencování (včetně zahrnutí externích projektů). Ve fázi testování se pak musí ověřit splnitelnost těchto požadavků. Vzhledem k jejich rozmanitosti je však i jejich testování rozmanité (od kontroly licenčních ujednání, přes nasazení systému na jinou databázi až po zkoušení nasazení 50 serverů v jedné místnosti).

7

2.2

Testování součástí životního cyklu SW

Testování je nezbytnou součástí životního cyklu softwaru a odvíjí se od toho, jakým způsobem je projekt řízen. Nebudeme si zde dopodrobna procházet všechny známé metodiky a modely vývoje softwaru a popisovat, jak v nich vypadá testování, ale pozastavíme se nad tím, že různé metodiky a modely mohou vnímat jednotlivé procesy testování jinak. Nehledě na zvolenou metodiku, každý softwarový projekt prochází několika fázemi od získávání požadavků až po nasazení a údržbu.

2.2.1

Zpracování požadavků, specifikace

V této fázi se testování může týkat zpracování požadavků, případně vytvořené specifikaci (jestli jsou správně definovány a bude možné ověřit jejich splnění). Už v této přípravné fázi vývoje se dají odhalit chyby, které by v budoucnu mohly být opravdu nákladné na opravu. Od testerů se očekává, že budou schopni komunikovat řečí zákazníka a zároveň se budou umět na daný projekt dívat očima vývojáře, aby mohli posoudit splnitelnost požadavků. Agilní projekty se vyznačují tím, že testeři pomáhají se zpracováním požadavků, ale oproti klasickému přístupu to neznamená žádnou zbytečnou byrokracii navíc a jde spíše o výpomoc týmu.

2.2.2

Analýza a návrh

V době, kdy probíhá analýza a připravuje se návrh, se zároveň připravují testovací scénáře a prostředí. Někdy je na tuto fázi kladen větší důraz – vytvářejí se technické dokumenty, schémata a diagramy, které potom slouží k implementaci a dokumentaci, jindy se tato fáze nahrazuje přímým prototypováním bez jakéhokoli modelování. Tomu se přizpůsobuje i testování – je-li součástí vývoje definice případů užití, sestavují se z nich testovací případy, atp. Pokud se žádné dokumenty nevytvářejí a jde jenom o vzájemnou komunikaci mezi členy týmu, očekává se vlastní iniciativa testera při vymýšlení testovacích scénářů.

2.2.3

Implementace a integrace

Ve fázi implementace se buď dotvářejí testovací scénáře, připravují testovací konfigurace a prostředí, anebo už se naplno testuje. Extrémem je TDD (Test Driven Development), kdy se testy vytváří ještě dříve než samotná implementace dané funkcionality. Do popředí se čím dál více dostávají jednotkové (unit) a integrační (integration) testy, které dokáží odhalit chyby ještě před zákaznickým spuštěním aplikace a jsou důležité především pro regresní testování. Po implementaci následuje fáze klasického funkčního testování (ať už automatického nebo manuálního) a odstraňování chyb. Když je aplikace připravena po funkční stránce, je potřeba ověřit její bezpečnost (penetrační testy), škálovatelnost (výkonnostní testy), atp. Zároveň se musí vyzkoušet proces aktualizace ze starších verzí, případně zálohování a obnovy ze záloh.

8

2.2.4

Provoz a údržba

Po splnění akceptačních testů jde aplikace do provozu a pokud se pracuje na jejím dalším rozšiřování, celý proces startuje od začátku. Během provozu aplikace mohou její uživatelé nacházet chyby a pokud se musí opravit, zase je v tom procesu obsaženo i testování (reprodukování chybného chování, otestování opravy a jednotlivých částí aplikace, které mohla daná oprava potenciálně rozbít).

2.3

Webové vs. desktopové aplikace

V této kapitole se zaměříme na testování webových aplikací v kontrastu k desktopovým aplikacím. Podobně jako jsou rozdíly mezi webovými a desktopovými aplikacemi, jsou i rozdíly v jejich testování, ale zároveň toho mají spoustu společného. Při vytváření softwaru jde v prvé řadě o to, aby plnil svůj účel a testování má zajistit, aby tomu tak opravdu bylo. Nejprve si rozdělíme aplikace do několika skupin, abychom se na ně mohli později odkazovat a poté probereme konkrétní oblasti, kde se tyto aplikace podobají nebo liší. Desktopové aplikace: 

Bez potřeby připojení k síti (vše offline) – např. kalkulačka, grafické programy, atp.



Aplikace klient-server – např. klienti pro ICQ, e-mail, obchodování na burze, atp.



Aplikace využívající databázi – např. ekonomický software (účetnictví, kniha jízd, …).

Webové aplikace: 

Běžící na vnitřní síti – rychlé připojení klientů k webovému portálu.



Běžící na internetu – problémové připojení pro některé uživatele.



Aplikace vyžadující další software – Java Virtual Machine, Flash Player, Silverlight, atp.

2.3.1

Systémové požadavky

Ještě před instalací softwaru (případně jeho použitím) by se měl zákazník přesvědčit, že má vše, co daná aplikace vyžaduje pro svůj běh. U desktopových aplikací mezi takové požadavky patří operační systém, velikost místa na disku, množství operační paměti, grafická karta či rychlost procesoru. Pokud má daná aplikace fungovat na více platformách, měla by se pochopitelně testovat na každé z nich a také bychom se při testování měli zaměřit na to, co se stane v případě, kdy systém některý z definovaných požadavků nesplňuje. V případě webových aplikací musíme rozlišit systémové požadavky na prostředí, ve kterém aplikace běží (webový/databázový server, platforma, dostupné systémové prostředky, atp.) a požadavky na koncového uživatele (většinou pouze internetový prohlížeč, někdy je však nutné mít nainstalovaný další software).

9

2.3.2

Instalace a aktualizace

Jednou z hlavních výhod webových aplikací je ale to, že je koncoví uživatelé nemusí instalovat a stačí jim použít jejich oblíbený internetový prohlížeč, ale při testování je nutné myslet i na samotné nasazení aplikace. Desktopové aplikace se většinou musí nějakým způsobem instalovat a pro některé uživatele to může být problém. Další výhodou webových aplikací je možnost jejich aktualizace na jednom místě (webový server) a všichni koncoví uživatelé budou mít software aktuální, zatímco u desktopových aplikací bývá proces aktualizací náročnější, protože si každý uživatel musí svoji aplikaci aktualizovat sám. Samozřejmě existují výjimky z obojího uvedeného – když běží webové stránky na nějakém redakčním systému, který by se měl aktualizovat, může jít o poměrně bolestivý proces, zatímco při aktualizaci nějakého moderního webového prohlížeče stačí jeho restartování a o všechno se postará sám na pozadí, aniž by s tím měl uživatel nějaké starosti. Obojí by každopádně mělo být předmětem testování se zaměřením na uživatelské pohodlí.

2.3.3

Spouštění a provoz

Dalším ze zásadních rozdílů je to, že desktopové aplikace se většinou spouštějí a vypínají častěji, než je tomu u webových aplikací, které často běží (pokud možno) nepřetržitě. Zároveň narážíme na rozdíl, kdy desktopovou aplikaci v jeden čas obsluhuje jediný uživatel, zatímco u webových aplikací se očekává simultánní připojení více uživatelů. Právě dlouhodobý provoz webové aplikace a konkurenční připojení uživatelů je potřeba testovat pomocí zátěžových testů.

2.3.4

Specifické oblasti a celkové shrnutí

Stejně jako u desktopových aplikací se i v případě webových aplikací musíme zaměřit na grafické uživatelské rozhraní, jeho přehlednost a použitelnost. I když jsou desktopové aplikace používány na různých platformách a ověřuje se, zda se na nich chovají stejně a vypadají alespoň podobně, v případě webových aplikací je tento problém mnohem větší, což je dáno širokou škálou dostupných internetových prohlížečů a jejich verzí. Každý prohlížeč zpracovává (x)HTML, CSS, Javascript, atp. jiným způsobem a na tvůrcích softwaru je, aby se ho snažili odladit pro danou cílovou skupinu uživatelů, což pro začátek znamená dodržování obecně uznávaných standardů a doporučení (například od konsorcia W3C). U webových aplikací se tak navíc testuje validita kódu, zobrazování v různých prohlížečích nainstalovaných na různých operačních systémech a přístupnost. U webových aplikací jsou typicky mnohem větší bezpečnostní rizika (protože je zpravidla používá větší množství lidí a mezi nimi také větší množství potenciálních útočníků), a tak se musí zvláštní pozornost věnovat vstupům od uživatele a celkovému zabezpečení aplikace – bezpečností se zabývá projekt https://www.owasp.org/, kde je možné najít potřebné informace. Webové aplikace také mívají větší problémy dostát uživatelským požadavkům na rychlost odezvy, než je tomu u těch 10

desktopových, a tak je potřeba si dávat větší pozor na efektivitu kódu, databázových dotazů, atd. Dříve bylo mnohem složitější automaticky testovat a ladit webové aplikace, ale v dnešní době už v tom není až zas takový rozdíl, přestože některé nástroje mohou mít problémy se zpracováním framesetů, javascriptu, atp.

Výkonnostní a zátěžové testování

2.4

Před samotným testováním si nejprve ujasníme, jak budeme chápat pojmy z této oblasti. Pojmy výkonnostní, zátěžové a stresové testování (angl. performance, load, stress testing) bývají často zaměňovány a jejich definice se obecně různí, my je budeme v tomto textu rozlišovat a chápat podobně jako Microsoft [6; 7; 8].

Výkonnostní testování – performance testing

2.4.1

Výkonnostní testování je proces, při kterém se zjišťuje, jakou má aplikace odezvu v daných podmínkách. Cílem takového testování může být například identifikace úzkých hrdel systému, optimalizace a odladění konfigurace systému pro nejvyšší výkon, anebo ověření, že systém bude schopný spolehlivě běžet pod danou zátěží. Ukazateli výkonu jsou zejména: 

doba odezvy,



propustnost (počet vyřízených požadavků za jednotku času – zejména Requests per Second),



maximální počet konkurenčních spojení,



využití systémových prostředků (procesor, paměť, síť, disk).

Pokud je to možné, testovací konfigurace by se měla co nejvíce blížit vybavení, které je použité na produkčním webu (nemá velký význam testovat webovou aplikaci běžící na počítači s jednojádrovým CPU a 1GB RAM, kterou navíc sdílí i SQL server, když je daný web nasazený na dedikovaném serveru se 4 CPU a 8 GB RAM a odděleném SQL serveru – v ještě horším případě by tomu mohlo být naopak).

2.4.2

Zátěžové testování – load testing

Zátěžové testování je typ výkonnostního testování, kdy měříme odezvu systému v normálních podmínkách a postupně zvyšujeme zátěž (tedy počet souběžně připojených uživatelů), abychom objevili práh, po jehož překročení už se aplikace přestane chovat očekávaným způsobem. Limitem může být například vytížení CPU nad 80%, doba odezvy 3 sekundy nebo použití 1GB RAM. Při

11

zátěžovém testování ladíme také problémy, které vznikají souběžným přístupem ke stejným datům v paměti a databázi.

2.4.3

Stresové testování – stress testing

Stresové testování má za úkol ověřit, jak se aplikace chová v extrémních podmínkách – při zátěži vyšší než je schopna zvládnout nebo s omezenými systémovými prostředky. Ve světě webových aplikací jde zejména o nejrůznější omezení webových serverů, které jsou sdílené více uživateli (shared hosting), přičemž každý uživatel (resp. webová aplikace) má k dispozici pouze omezené systémové prostředky, s nimiž si musí vystačit. Dalším příkladem může být simulace různých výpadků – použití záložní síťové linky, obnova databáze během reálného provozu, atp.

12

3

Volba webové aplikace

V této kapitole vybereme aplikaci vhodnou pro výkonnostní testování a podíváme se na to, co všechno je k takovému testování potřeba. Teoreticky bychom mohli vybrat libovolnou webovou aplikaci, ale vzhledem k autorovým zkušenostem s používáním a testováním redakčních systémů (Drupal, Joomla!, WordPress, Kentico CMS) se podíváme na redakční systémy, konkrétně Kentico CMS 6.

3.1

Redakční systémy

Redakční systém (Content Management Systém – CMS) je dobrou ukázkou webové aplikace, kde se bez výkonnostního testování neobejdeme. Když zjednodušíme její definici, je to webová aplikace, která umožňuje efektivně vytvářet a spravovat webové stránky, přičemž její používání přináší různým lidem různé výhody. V počátcích internetu bylo vytváření obsahu webu výhradní záležitostí programátorů, což už v dnešní době rozhodně neplatí. Podíváme se tedy na výhody redakčních systémů z několika pohledů: 1. Návštěvník webu a. Funkcionalita, na kterou je uživatel zvyklý, je dostupná na velkém množství webů (např. komentáře pod články, přihlášení odběru informací, atp.). b. Tvůrci redakčních systémů (a vývojáři, kteří je používají) většinou dbají na výkon a bezpečnost více, než je tomu u proprietárních dynamických stránek. 2. Obyčejný uživatel / Editor obsahu webu a. Vytváření obsahu webu bez znalosti jakéhokoli programování. b. Uživatelské rozhraní, na které je uživatel zvyklý. 3. Web developer / Webová agentura a. Rychlejší a snadnější tvorba webu (použití existující funkcionality a šablon). b. Vyšší kvalita a nižší cena pro koncového zákazníka. 4. Hostingové společnosti a. Nabídka použití redakčních systémů (už předpřipravených instalací) přináší nové zákazníky a udržuje ty stávající. Nasazení redakčních systémů na webu má samozřejmě i své nevýhody – například u zmíněné bezpečnosti je to dvousečná zbraň, protože objevená zranitelnost jednoho systému může potenciálně ohrozit tisíce webů (např. na DotNetNuke je postaveno více než 700 000 webů [9], WordPress se pyšní neuvěřitelným množstvím více než 70 000 000 webů [10].

13

Redakčních systémů existují tisíce, jejich porovnáváním se zabývá například webový portál http://www.cmsmatrix.org/. Na tomto trhu se pohybují jak open-source systémy dostupné zadarmo, tak i komerční aplikace s cenou v řádu desítek tisíc amerických dolarů. Jedním ze zástupců komerčních systémů pro správu obsahu je právě Kentico CMS, na který se podíváme dále.

3.2

Kentico CMS 6

Kentico CMS je robustní redakční systém, který je použitelný jako základ libovolného webového projektu – od osobních blogů, přes firemní prezentace, intranetové portály a komunitní weby, až po elektronické obchody s podporou online marketingu. Obsahuje spoustu vestavěných modulů („out-ofthe-box“) a zároveň je vysoce přizpůsobitelný. Momentálně na něm běží více než 7000 webů v 84 zemích světa, které byly vytvořeny skrze síť cca 1200 implementačních partnerů (především webových agentur). Mezi koncové zákazníky patří například Microsoft, McDonald’s, Vodafone, O2, Audi, Samsung, Sony, a další. Více informací je možné získat na http://www.kentico.com.

3.2.1

Systémové požadavky

Kentico CMS je postaveno na technologii ASP.NET, z čehož plynou následující systémové požadavky [11]: 

Windows Server 2003, 2008, 2008 R2, XP, Vista nebo 7.



Microsoft .NET Framework 3.5 SP1 nebo vyšší.



Microsoft Internet Information Services (IIS) nebo vestavěný web server ve Visual Studio/Visual Web Developer 2005/2008/2010.



3.2.2

Microsoft SQL Server 2005, 2008, 2008 R2 (včetně SQL Server Express Edition).

Klíčové vlastnosti a moduly

Systém poskytuje nepřeberné množství modulů a vlastností, které jsou podrobně popsány a vysvětleny na http://www.kentico.com/Product/All-Features. Zde si ukážeme jenom některé z nich, aby si čtenář mohl udělat alespoň základní obrázek o komplexnosti tohoto redakčního systému. Správa obsahu (Content Management) 

Přehledná stromová struktura dokumentů různých typů s možností definovat vlastní



Jednoduchá správa dokumentů – vytváření, editace, kopírování, přesouvání a linkování s možností zamykání (check-in/out), kontrolou pravopisu, atp.



Rozšířený WYSIWYG Editor (CKEditor) – možnost vkládání obrázků a multimédií



Vytváření různých jazykových verzí a verzování dokumentů (+ porovnávání side-by-side).



Podpora workflow (proces schvalování a publikování na základě uživatelských rolí)

14



Definice uživatelských oprávnění na úrovni dokumentů



Kategorizace obsahu pomocí kategorií a tagů



Použití předdefinovaných šablon stránek a rozložení (Page templates / layouts)



Správa metadat a SEO



Podpora MS Office, WebDAV, MS SharePoint

E-Commerce 

Definování různých druhů produktů a jejich variant nebo příslušenství



Možnost definování vlastního nákupního procesu (jednotlivé kroky objednávky)



Možnost použití více měn



Přizpůsobení výpočtu daně



Různé možnosti nastavení přepravy



Různé možnosti plateb (podpora platebních bran)



Definování slev na základě ceny objednávky nebo množství, případně slevových kupónů



Šablony pro potvrzovací e-maily, faktury, atp.



Možnosti rozšíření nebo nahrazení stávající funkcionality

Komunitní weby (Social Networking) a intranetová řešení (Intranets, portals & collaboration) 

Definování komunitních skupin a oprávnění uživatelů



Integrace s Facebookem, LiveID, OpenID



Diskuzní fóra s možností zamykání, moderování, atp.



Vytváření uživatelského obsahu (stránky, články, ankety, atp.) přímo na živém webu



Možnost vytváření kamarádů a zasílání zpráv

Řešení pro spolupráci uživatelů (Intranets, portals & collaboration) 

Vytváření různých oddělení a uživatelských skupin



Management projektů



Knihovny dokumentů, integrace s Microsoft SharePoint a podpora WebDAV

On-Line Marketing 

E-mail Marketing – Statické i dynamické newslettery s kampaněmi



On-line formuláře (průzkumy, atp.)



Web Analytics (podrobné reporty podobné Google analytics)

Development 

Portal Engine – možnost vytváření rozložení stránek a použití web parts přímo v prohlížeči 15



Předpřipravených více než 300 web parts a widgets



Integrace s MS Visual Studio



Dobrá rozšiřitelnost a použitelnost API

Zabezpečení 

Možnost přihlášení přes formulář, Windows autentikaci, OpenID, LiveID, facebook, atp.



Definice uživatelských rolí a jejich oprávnění s jemnou granularitou



Definice oprávnění na dokumentech i modulech



Personalizace uživatelského rozhraní na základě uživatelských oprávnění

Další vlastnosti 

Správa několika (desítek) webů na jedné instanci s možností globálních i webových nastavení



Podpora webových farem (více webových serverů napojených na jednu databázi)



Několik úrovní vyrovnávací paměti (cache) pro zvýšení výkonu



Škálovatelnost (systém zvládne miliony dokumentů, uživatelů, atp.)



Podpora Windows Azure (cloudové řešení od Microsoftu)



Full-text vyhledávání (smart search postavený na Lucene.NET)



Podpora mobilních verzí webu a RSS/XML formátu



Podpora REST a OData

3.2.3

Silné a slabé stránky

K silným stránkám Kentico CMS patří výkon a škálovatelnost – někteří zákazníci provozují několik set webů na jedné instanci, někteří používají ohromné množství dokumentů v různých jazykových mutacích, jiní mají obrovský provoz na webu (traffic), atp. Například http://www.conduit.com má momentálně 260 000 přispěvatelů a 250 000 000 uživatelů. Další silnou stránkou je vysoký počet modulů (pokrytí funkcionality „vše v jednom“) a možnosti rozšíření. Kentico drží krok s novými technologiemi a trendy, ať už to byl dříve Silverlight, .NET 4.0, MVC, SharePoint, Facebook nebo Windows Azure. Neméně důležitou součástí produktu je zákaznická podpora (e-mail, telefon, diskuzní fórum, 24/7), která je hodnocená hodně kladně a také „7-day bug-fixing policy“, kde se Kentico zavazuje, že udělá vše, co je v jeho silách, aby byl každý bug od zákazníka opravený do 7 dnů. Nakonec bych ještě zmínil jednu silnou stránku a tou je cena. Přestože se může zdát, že cena v řádu tisíců dolarů je nepřiměřeně vysoká, zvlášť když existují desítky open-source projektů, v oblasti komerčních redakčních systémů postavených na platformě .NET je oproti konkurenci naopak hodně nízká. Co se týče slabých stránek, produkt má sice hodně modulů a vlastností, ale dosud šel spíše do šířky než do hloubky – některé moduly tak mohly nejdříve působit jen jako „nástřel“ a byly/jsou rozšiřovány až v novějších verzích. Někomu se může zdát cena příliš vysoká 16

a i když je Kentico CMS použitelné i zdarma (Free Edition), pro komplexnější weby si zakázník většinou musí pořídit vyšší edici. Přestože je Kentico vysoce rozšiřitelné, nemá tak živou komunitu jako jeho konkurenti. Další oblastí, kde Kentico momentálně zaostává za konkurencí, je marketing, takže přichází o spoustu zajímavých projektů. Pro někoho může být také použití platformy .NET jako značná nevýhoda, protože náklady na provoz (např. licence na Windows, MS SQL, …) jsou znatelně vyšší než je tomu u Apache (PHP, MySQL, …).



Silné stránky Výkon a škálovatelnost



Slabé stránky Nepříliš aktivní komunita



Široký záběr funkcionality (vše v jednom)



Nedotaženost některých modulů



Rozšiřitelnost a otevřenost API



Marketing zaostává za konkurencí



Podpora nových technologií



Zákaznická podpora a opravy bugů



Velké množství implementačních partnerů



Výhodná cena Tabulka 3.1: Silné a slabé stránky Kentico CMS

3.2.4

Weby postavené na Kentico CMS

Zákaznické webové projekty je možné nalézt na http://www.kentico.com/Customers/CustomerProjects. Zde si ukážeme několik webů, které byly přihlášeny do soutěže „Kentico Site of the Year 2011“ a v lednu 2012 byly vyhlášeny jako vítězné projekty v 17 různých kategoriích: Kategorie Global Winner (+Best Travel Site) Best Community/Social Media Site Best E-Commerce Site Best Education Site Best Financial Site Best Government and Municipal Site Best Healthcare Site Best Nonprofit Organization Site Other Best Intranet Site Best Mobile Site Best Graphic Design Largest Site Best Integration Best EMS Implementation

Název Webu Discover Ireland Surround Health Purvis Beer Oxford Online Learning Zone Kapitaalplaza Czech Tourism Sleep Disorder Center San Francisco Opera Chiquita IMG Models Immortals Movie Mobile App Australian Academy of Cinemagraphic makeup Sday.gr The Fox News Shop Barrett Steel

URL http://discoverireland.ie/ http://surroundhealth.net/ http://www.purvisbeer.com.au/ http://primary.oolz.oupe.es/ http://www.kapitaalplaza.nl/ http://www.czechtourism.com/ http://www.sleep-ksu.net/ http://sfopera.com/ http://www.chiquita.com/ (nedostupné veřejnosti) http://immortalsmovie.mobi/ http://www.aacm.qld.edu.au/ http://SDay.gr http://shop.foxnews.com/ http://www.barrettsteel.com/

Tabulka 3.2: Kentico Site of the Year 2011

17

3.3

Kentico software

Kentico software s.r.o. je brněnská firma, která byla založena Petrem Palasem v roce 2004. Když svoji firmu založil, neměl žádné zaměstnance, pouze si pronajal kancelář a sám pracoval na první verzi Kentico CMS (původně bakalářská práce), protože viděl potenciál v aplikacích pro tehdy novou platformu .NET, konkrétně redakčních systémech. Rozhodl se svoje řešení prodávat online a první zákazníci byli z USA (např. http://www.gibson.com). Až po roce fungování začal přijímat kolegy/zaměstnance, kteří mu pomáhali s implementací a postupně se začal zajímat více o manažerskou práci a byznys jako takový. V současné době má 65 zaměstnanců v ČR, 7 v USA a jednoho ve Velké Británii. Firma si na sebe od začátku fungování vydělává sama a zatím odolává snaze investorů do ní nějakým způsobem zasáhnout. Od roku 2008 se Kentico software objevuje v žebříčku nejúspěšnějších firem (na základě růstu obratu ve srovnání s předchozími lety) ve střední Evropě, který sestavuje poradenská společnost Deloitte [12]: Pořadí 1. 2. 3. 4. 5.

Společnost Nav N Go Kft. Javatech Sp. z o.o. EuroTax Sp. z o.o. SalesManager Software Sp. z o.o. Kentico software s.r.o.

Země Maďarsko Polsko Polsko Polsko ČR

Růst 7 838% 862% 795% 612% 553%

Tabulka 3.3: Top 5 Rising Stars 2008 Central Europe (za období 2005-2007)

Pořadí 1. 2. 3. 4. 5.

Společnost Multicom d.o.o. Internet Shop s.r.o. LiveSport s.r.o. RAYNET s.r.o. Kentico software s.r.o.

Země Chorvatsko ČR ČR ČR ČR

Růst 1 805% 1 137% 1 088% 838% 710%

Tabulka 3.4: Top 5 Rising Stars 2009 Central Europe (za období 2006-2008)

Pořadí 1. 2. 3. 4. 5.

Společnost Netmedia S.A. TeamNet International S.A. Kompan.pl Sp. z o.o. Sygic a.s. Kentico software s.r.o.

Země Polsko Rumunsko Polsko Slovensko ČR

Růst 15 005% 3 120% 2 107% 1 917% 1 781%

Tabulka 3.5: Top 5 Technology Fast 50 2010 Central Europe (za období 2007-2009)

V roce 2011 se společnost umístila v kategorii Technology Fast 50 až na 11. místě s růstem 1 367%, ale pořád je to 3. místo mezi českými společnostmi (LiveSport s.r.o. a Internet Shop s.r.o. se umístily na druhém a třetím místě celkového žebříčku).

18

Kentico je zároveň Microsoft Gold Certified Partner s vizí stát se jedničkou na trhu redakčních systémů pro webové agentury postavených na platformě ASP.NET a misí společnosti je pomáhat zákazníkům vytvářet úspěšné webové stránky. Společnost také spolupracuje s brněnskými vysokými školami, pořádá přednášky, účastní se workshopů a nabízí témata bakalářských i diplomových prací. Většina jejích zaměstnanců v ní začínala už při studiu a firma v tomto trendu hodlá pokračovat i nadále. V létě 2011 Kentico uspořádalo Summer of Code, kdy dalo příležitost 4 studentům, aby si vyzkoušeli práci v týmu na reálném projektu, přičemž všichni účastníci nakonec zůstali ve firmě i po skončení této akce a stali se tak součástí vývojových týmů. Co se týče samotného vývoje produktu Kentico CMS (což je jediný produkt společnosti), funkcionalita je rozdělena mezi sedm menších vývojových týmů, kde každý tým má svého vedoucího, dva až tři vývojáře, jednoho až dva testery a jednoho dokumentátora. V porovnání s konkurencí je tak Kentico několikanásobně menší, a přesto s ní drží krok.

19

Nástroje pro výkonnostní a zátěžové

4

testování V době, kdy začaly vznikat první webové aplikace, začaly s nimi ruku v ruce vznikat i nástroje pro testování jejich výkonu a sledování jejich chování pod zátěží. Momentálně existuje nepřeberné množství nástrojů pro výkonnostní a zátěžové testování a přestože by se mohlo zdát, že trh je nasycen, objevují se stále další společnosti a produkty, které se tímto testováním zabývají. Pokusíme se tedy definovat požadavky na software, podle nich porovnat několik nástrojů a nakonec z nich jeden vybrat pro naše testování.

4.1

Existující nástroje

Na úvod je třeba říci, že výkonnostní testování není zrovna levná záležitost a některé firmy prostě netestují, protože na to jednoduše nemají peníze. Pro některé projekty má však výkon aplikace zásadní důležitost, takže si musí udělat v rozpočtu místo. I když existují open-source nástroje, které lze pořídit zdarma, není vždycky pravda, že to nakonec vyjde levněji. U open-source nástrojů je mnohem vyšší riziko, že daný projekt skončí, mívají hůře zajištěnou zákaznickou podporu, uživatelské rozhraní zpravidla nebývá tak intuitivní a uživatelsky přívětivé jako u komerčních projektů, práce s daným programem může být méně efektivní a třeba vůbec nenabízí určité možnosti – potom se může takové používání prodražit (např. jsou potřeba kvalifikovanější lidé nebo je nutné doimplementovat určitou funkcionalitu). Na druhou stranu však záleží na právě na požadavcích, zkušenostech vývojářů/testerů a typu projektu – pro jednorázový projekt v hodnotě $500 asi těžko budeme pořizovat software na jeho testování za $5000. Existují profesionální nástroje od velkých společností typu Hewlett-Packard, IBM nebo Microsoft, jejichž cena se pohybuje v řádu desítek tisíc dolarů: 

HP LoadRunner



IBM Rational Performance Tester



Microsoft Visual Studio

Dále je k dispozici celá řada komerčních projektů, které se pohybují v řádu tisíců dolarů: 

WebPerformance Load Tester



Neotys NeoLoad



SmartBear LoadComplete

20

A nakonec se dostáváme i k těm zdarma dostupným nástrojům, které se však v mnohém vyrovnají svým komerčním protějškům: 

Apache JMeter



Silk Performer



OpenSTA

Vyčerpávající výčet open-source nástrojů je možné nalézt na http://www.opensourcetesting.org/ performance.php. Základní popis většího množství testovacích nástrojů můžeme vidět například v dokumentu http://www.vcaa.com/tools/loadtesttool-evaluationchart-023.pdf nebo na webových stránkách http://www.soft wareqatest.com/qatweb1.html#LOAD.

4.2

Definice požadavků a představení nástrojů

V prvé řadě nás nejspíše bude zajímat cena. I když se do testování možná vyplatí investovat, těžko se to obhajuje, pokud zrovna není nějaký akutní problém. Protože je Kentico zlatým partnerem Microsoftu (a zároveň MSDN subscriber), má k dispozici v rámci MSDN programu levnější licence na jeho produkty a mezi výhody patří také jedna licence na MS Visual Studio 2010 Ultimate. Z tohoto pohledu bychom tedy ostatní komerční produkty nechali stranou a podívali se na řešení poskytovaná zdarma. Dále nás určitě bude zajímat, co všechno potřebujeme ke zprovoznění daného nástroje – jaké má systémové požadavky, kolik zabírá místa na disku, v paměti, atp. Další otázkou je, jak se v daném nástroji vytvářejí a upravují testy. U komerčních projektů zaměřených na pohodlí zákazníka je zpravidla dodáváno uživatelské rozhraní umožňující daný test „naklikat“, tedy vytvoření testu probíhá odposloucháváním a zaznamenáváním komunikace mezi klientem a serverem. Někdy je k nahrávání testů využit prohlížeč vestavěný přímo do nástroje, jindy se využívá klasický prohlížeč nainstalovaný v systému. Neméně důležitou vlastností je, co všechno ten který nástroj umí měřit a jakým způsobem to zobrazuje. Většina nástrojů je napojená přímo na výkonové čítače (vytížení CPU, RAM, atp.) a potom nabízí ještě řadu ukazatelů spojených s průběhem testů (počet testů za jednotku času, nejpomalejší testy, atp.). Je potřeba dát si pozor na to, že některé nástroje neumožňují sledovat měřené údaje v průběhu testů, zatímco jiné zobrazují aktuální data a už během testu je možné odhalit, že něco není v pořádku a kde je asi chyba.

21

Pro vytváření testů může být také důležité, jaké protokoly daný nástroj podporuje. Některé se zaměřují pouze na HTTP(S), jiné umožňují testování nejrůznějších protokolů (FTP, SOAP/XMLRPC, LDAP, apod.). Záleží tedy na tom, co všechno máme v plánu testovat. Dalším faktorem pro rozhodování může být programovací jazyk, který daný systém využívá pro psaní testů. Můžeme se setkat s nástroji, které nemají GUI a veškeré skripty jsou ve formě zdrojového kódu (od proprietárních jazyků, po klasické C/C++/C#, Java, atp.), jiné nástroje umožňují vygenerování zdrojových kódů z předem naklikaných testů do některého z vyšších programovacích jazyků. Záleží tedy na autorovi testů a jeho preferencích – může se stát, že někdo do zdrojových kódů vůbec nepůjde a jiný naopak nepotřebuje GUI, když si všechno může naprogramovat. S použitím programovacího jazyka souvisí i rozšiřitelnost nástroje. Pokud daný nástroj nemá veškerou funkcionalitu zabudovanou v sobě, může být velice důležité, jakým způsobem se dá upravovat jeho chování, případně rozšiřovat (customizations). S tím také souvisí množství a kvalita dostupných zásuvných modulů, které jsou k dispozici, ať už se jedná o záležitost komunity nebo komerčních projektů zaměřených na rozšiřování nástrojů pro testování. Jedním z posledních ukazatelů při výběru mohou být reporty, které daný nástroj umí vygenerovat, protože to je to, co pomáhá vývojářům odhalovat problémy a ve finále právě takové reporty chce vidět management. Některé nástroje nabízejí pouze textové logy a souhrny, jiné z daných logů vykreslují grafy a umožňují také jejich export například do MS Excel, kde se pak dají srovnávat jednotlivé běhy testování. Každý uživatel má svůj žebříček hodnot a vidí používání softwaru z jiného pohledu. Výše uvedené ukazatele tak mohou sloužit spíše jako inspirace, jak by se člověk mohl mezi těmi nástroji zorientovat.

4.2.1

Microsoft Visual Studio 2010 (Ultimate Edition)

MS Visual Studio 2010 Ultimate je určeno pro vývoj aplikací a obsahuje nástroje pro funkční i zátěžové testování aplikací, my se však zaměříme zejména na webové výkonové testy (web performance tests) a zátěžové testy (load tests). Už v dřívějších verzích MS Visual Studio byly podobné možnosti, verze 2010 je však značně rozšiřuje a zajišťuje pohodlnějsí práci v uživatelském rozhraní. Cena Visual Studio slouží primárně pro vývoj aplikací a testovací nástroje jsou jenom jeho součástí, kterou však nelze instalovat samostatně. Pro vytváření, úpravy a spouštění webových výkonových (případně 22

zátěžových) testů je zapotřebí mít Visual Studio v edici Ultimate, což je nejdražší možná varianta, kde se cena se pohybuje okolo $12,000 s novým MSDN subscription (při prodloužení stávajícího subscription jsou to necelé $4,000). Dříve bylo pro testování s více než 250 virtuálními uživateli potřeba přikoupit tzv. Virtual Users Pack, jehož cena se pohybovala okolo $1,000 za 1000 virtuálních uživatelů, přičemž takových balíčků se dalo pořídit neomezené množství. Nyní však Microsoft udělal vstřícný krok směrem k zákazníkům a umožnil jim, aby měli neomezené množství virtuálních uživatelů v rámci licence na Visual Studio 2010 Ultimate, takže nejsou nutné žádné další náklady. Systémové požadavky Visual Studio v rámci instalace přináší i .NET Framework a SQL Server Express, aby byl zajištěn jeho bezproblémový chod. Ostatní požadavky podle [13] jsou následující: 

Windows XP SP3 a novější,



CPU 1,6+ GHz,



1 GB RAM (x86), 2GB RAM (x64),



3 GB volného místa na disku, který má minimálně 5400 otáček za minutu,



grafická karta s DirectX 9, rozlišení displeje větší než 1024x768px.

Vytváření a úprava testů Testy se dají vytvářet pomocí automatického nahrávání komunikace mezi prohlížečem (Internet Explorer) a serverem. Po dokončení nahrávání je test spuštěn znovu pro detekci dynamických parametrů – Visual Studio se pokusí najít měnící se parametry (např. proměnné části URL (query string), hodnoty formulářových polí, atp.) a extrahovat je do proměnných, které dále můžeme používat. Ne vždy se to podaří úplně stoprocentně, ale vše se dá dodatečně upravit v přehledném prostředí Visual Studio. Úpravy testů se dělají přímo v GUI, anebo je také možné vygenerovat test v podobě zdrojového kódu v jazyce C#, který lze následně libovolně upravovat. Co se dá měřit Vzhledem k tomu, že je tento nástroj určený k testování aplikací pro platformu Windows, lze s ním měřit veškeré výkonové čítače (Performance Counters) dostupné ve Sledování spolehlivosti a výkonu (Performance Monitor), což je standardní součástí Windows. Jsou tedy dostupné informace o systémových prostředcích (procesor, paměť, disk, síť) i jednotlivých aplikacích a procesech. Hlavní protokol pro testování je HTTP(s), ale pomocí rozšíření lze testovat v podstatě cokoli. Programovatelnost (rozšiřitelnost) Vzhledem k použití platformy .NET se i pro testy se používají jazyky C# a Visual Basic. Rozšiřovat lze pomocí zásuvných modulů (plug-ins) na úrovni jednotlivých požadavků (requests), webových výkonových testů i zátěžových testů, stejně jako lze rozšiřovat a měnit průběh nahrávání a způsob

23

extrakce parametrů – vždy stačí pouze zdědit ze správné třídy a překrýt (override) příslušné metody. Vše je podrobně popsáno na [14] a podíváme se na to později v následujících kapitolách. Je možné vytvářet testy přímo ve zdrojových kódech, anebo se dá vygenerovat kód z nahraných testů a ten později upravovat. Dostupných rozšíření není mnoho, nejspíše proto, že řešení samotné obsahuje tolik vlastností, že buď není potřeba ho tolik rozšiřovat, anebo jsou ta rozšíření dostatečně jednoduchá na implementaci. Reporty Visual Studio nabízí grafické vyjádření všech sledovaných parametrů a je možné je sledovat už za běhu, což je výhodné především proto, že není nutné čekat na doběhnutí testu, abychom se dozvěděli, že se něco změnilo. Zároveň se před spuštěním testů dají nastavit prahové hodnoty pro varování a chybu, po jejichž překročení se v grafu u dané hodnoty zobrazí malé ikonky varování/chyby. Dobré je, že každý výkonový čítač má tyto hodnoty předdefinované, protože u většiny z nich uživatel ze začátku třeba neví, jaké hodnoty by měl očekávat, anebo ví, ale nechat uživatele před spuštěním testu nastavit stovky prahových hodnot by asi nebyl správný přístup. Takhle je na uživateli ponecháno pouze rozhodnutí, jestli chce přednastavené hodnoty měnit nebo ne. Další pěknou vlastností je možnost vytváření grafů až po doběhnutí testu – jsou sledovány a zaznamenávány hodnoty desítek/stovek různých čítačů a všechny nelze sledovat naráz (technicky ano, ale z uživatelského pohledu to nedává moc smysl mít grafy s desítkami čar), takže je možné si jednotlivé čítače do grafu přidávat postupně a sledovat je i zpětně. Informace o proběhnutých testech jsou podávány v pěkném shrnutí a také je možné z výsledků testů vygenerovat report (včetně srovnání jednotlivých běhů) do tabulkového procesoru Microsoft Excel. To se hodí zejména v případě, kdy chceme mít přehled o větším množství ukazatelů výkonu a jejich srovnání mezi jednotlivými běhy testů (např. ve fázi ladění výkonu). Je znát, že se jedná o komerční nástroj, protože práce s grafy (a obecně výsledky testů) je opravdu pohodlná. Pro ukládání výsledků testů se používá MS SQL Server. Shrnutí Popis od výrobce: http://www.microsoft.com/visualstudio/en-us/products/2010-editions/ultimate/overview Aktuální verze: 2010 SP1 Výhody: 

Out-of-the-box řešení



Přehledné a uživatelsky přívětivé GUI



Kvalita zpracování



Dobrá rozšiřitelnost

24

Nevýhody: 

Cena



Náročnější systémové požadavky



Dlouhá instalace



Omezení na platformu Windows

Hodí se zejména na dlouhodobé testování aplikace během jejího vývoje, zvláště výhodné je pak propojení s profilerem, kde je vidět až na úroveň řádků zdrojového kódu, kde se spotřebovává nejvíce času.

4.2.2

Microsoft Web Capacity Analysis Tool

WCat je jednoduchá konzolová aplikace pro generování zátěže na webový server. Přestože nemá žádné GUI, pro základní testování výkonnosti a propustnosti aplikace je poměrně dobře použitelná, umožňuje využívat více fyzických klientů a (stejně jako ostatní nástroje) generovat tisíce virtuálních uživatelů. Součástí IIS 6.0 Resource Kit Tools byla její předchozí verze (WCAT 5.2), ta současná (WCAT 6.3) je však schopná pracovat s IIS 5.1, IIS 6 i IIS 7. Cena Tato minimalistická aplikace byla Microsoftem vydána zdarma. Dříve sloužila především pro interní účely – testování IIS, jádra Windows, .NET CLR, atp. Zřejmě se nepředpokládá, že by tento nástroj používala masa zákazníků v komerčním prostředí a také je podporovaný pouze formou diskuzního fóra. Systémové požadavky Prvním z požadavků je operační systém Windows XP a novější. Pro controller je doporučováno mít procesor s taktem minimálně 1GHz a 256 MB RAM. Samozřejmě čím vyšší výkon a dostupnost systémových prostředků má daný počítač, tím více zátěže umožní generovat – Microsoft uvádí, že pro jednoho virtuálního uživatele by měl být dostupný přibližně 1MB paměti. Vytváření a úprava testů Testy se bohužel musí vytvářet ručně, resp. je potřeba vytvořit zdrojový kód (připomínající konfigurační soubory – viz ukázkový kód z [15] níže). Ten je samozřejmě možné nějakým způsobem generovat, ale už to není součástí nástroje samotného.

25

scenario { transaction { id = "foo"; weight = 1000; request { url = "/foo1.htm"; } request { url = "/foo2.htm"; } } transaction { id = "bar"; weight = 2000; request { url = "/bar.htm"; } } }

Existuje například doplněk pro Fiddler (nástroj pro zachytávání síťového provozu), který umožní z daných požadavků (requests) vytvořit potřebný kód nebo je možné například pomocí nástroje Log Parser vygenerovat WCAT skript z logů IIS. Co se dá měřit Měřitelné jsou veškeré výkonové čítače ve Windows a je nutné je vyjmenovat v konfiguračním souboru, který by mohl vypadat například takto: settings { clientfile server clients virtualclients

= = = =

"scenario.ubr"; "localhost"; 2; 10;

counters { interval = 10; counter = "Processor(_Total)\\% Processor Time"; counter = "Processor(_Total)\\% User Time"; counter = "Memory\\Available MBytes"; counter = "Process(w3wp)\\Working Set"; } }

Programovatelnost (rozšiřitelnost) Tento nástroj se dá rozšiřovat pomocí externích knihoven napsaných v jazyce C.

26

Reporty WCAT generuje výstupní XML soubory a poskytuje základní XSL transformaci pro jejich zobrazení, ale jedná se vlastně o souhrnná data, grafická nadstavba (například grafy s průběhem hodnot) bohužel není dostupná. Shrnutí Popis od výrobce: http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1466 Aktuální verze: 6.3 Výhody: 

Zdarma



Rychlé použití (velice malé – cca 2MB)



Nízké požadavky na systémové prostředky

Nevýhody: 

Absence GUI



Nemožnost nahrávání testů (vše je nutné psát manuálně)



Vysoká pracnost

Nástroj je spíše v duchu „od vývojářů pro vývojáře“, než aby to bylo řešení pro zákaznické použití. Nicméně pořád je to velice silný prostředek pro výkonnostní testování.

4.2.3

Apache JMeter

Dříve známý pod jménem Jakarta JMeter je tento nástroj na trhu již od roku 1998 a je zřejmě nejrozšířenější open-source nástroj pro výkonnostní a zátěžové testování. Je kompletně napsaný v jazyce Java a tím pádem přenositelný mezi operačními systémy (podmínkou je samozřejmě Java Virtual Machine). Základní balíček ke stažení má cca 20MB a jeho funkcionalitu je možné rozšířit pomocí široké škály zásuvných modulů (např. http://code.google.com/p/jmeter-plug-ins/). Cena JMeter je je dostupný zdarma i se zdrojovými kódy. Systémové požadavky Jediným požadavkem na provoz JMeteru je Java Virtual Machine 1.5+, ale opět platí, že čím vyšší je výkon používaného počítače, tím lépe. Vytváření a úprava testů Vytváření testů probíhá v grafickém rozhraní, kde je potřeba nastavit jednotlivé vlastnosti každého klientského požadavku. JMeter nemá žádný vestavěný prohlížeč pro nahrávání testů, ale je možné jej 27

nastavit jako proxy server a potom k nahrávání testu použít klasický prohlížeč, který bude mít správně nastavený právě tento proxy server. Přičemž je možné nastavit, které požadavky se (ne)mají logovat – například může být zbytečné pro každý požadavek znovu stahovat statické soubory s javascriptem a obrázky, takže se dají z automatického nahrávání vyloučit. Co se dá měřit JMeter původně vznikl pro testování webových aplikací, ale díky své oblíbenosti a open-source byl postupně rozšiřován a nyní se používá pro testování například i LDAP, POP3, FTP, atd. Možná proto, že je psán v Javě a od začátku multiplatformní, nemá vestavěnou podporu výkonových čítačů Windows (jako předchozí dva nástroje), ale je dostupný zásuvný modul, který to dokáže. Programovatelnost (rozšiřitelnost) Tento nástroj je vysoce rozšiřitelný, což potvrzuje řada dostupných rozšíření. Jak už bylo zmíněno, používaným programovacím jazykem je zde Java a postup rozšiřování je popsán například na http://jmeter.apache.org/extending/jmeter_tutorial.pdf. Reporty Data pro reporty se sbírají pomocí takzvaných listenerů, které umožňují data standardně ukládat do XML nebo CSV (resp. z nich načítat), stejně jako je v reálném čase zobrazovat v podobě grafů, tabulek či hodnot samotných. Existuje několik předdefinovaných komponent pro zobrazování reportů a případně není problém vytvořit (nebo si obstarat) další – možností je tedy dost. Shrnutí Popis od výrobce: http://jmeter.apache.org/ Aktuální verze: 2.5.1 Výhody: 

Zdarma



Open-source



Zavedený produkt – aktivní komunita, dostupná rozšíření



Multiplatformní software

Nevýhody: 

Open-source (viz 4.1)



Složitější proces vytváření testů



Nutnost použití rozšíření

V open-source světě je tento nástroj asi nejpoužívanější a nejoblíbenější, ale je nutno dodat, že s komerčními aplikacemi se zvláště v uživatelské přívětivosti (kvalita GUI) nedá moc srovnávat.

28

4.3

Konečný výběr testovacího nástroje

Tato práce si neklade za cíl vyjmenovat a strovnat veškeré dostupné nástroje pro výkonnostní testování, pro detailní srovnání tedy byly vybrány tyto tři nástroje: Apache JMeter, Microsoft Visual Studio 2010 a Microsoft Web Capacity Analysis Tool. Z těchto nástrojů bylo nakonec vybráno Visual Studio 2010, především díky uživatelské přívětivosti, použitelnosti a rozšiřitelnosti.

JMeter

Visual Studio

WCAT

Cena

Zdarma

$12,000 / $4,000

Zdarma

Systémové požadavky

neudávané

náročnější

nízké

Vytváření a úprava testů

Uživatelsky méně přívětivé

Uživatelsky přívětivé

Je nutné vytvářet kód

Co se dá měřit

Veškeré výkonové čítače Veškeré výkonové dostupné ve Windows i čítače dostupné ve dalších OS Windows

Programovatelnost

Open-source, Java

.NET (C#, VB), dobře připravené rozhraní, DLL v jazyce C dostupné plug-iny

Reporty

Vizuální zobrazení dat z XML/CSV

Přehledné, podrobné, graficky dobře zpracované, možnost srovnání a vygenerování do MS Excel

Pouze data v XML

Výhody

+ Zdarma + Open-source + Zavedený produkt + Multiplatformní

+ Out-of-the-box řešení + Uživatelsky přívětivé GUI + Kvalita zpracování + Dobrá rozšiřitelnost

+ Zdarma + Velice malé (2MB) + Nízké nároky na systémové prostředky

- Nepříliš příjemné GUI - Open-source - Není vše v jednom – pomalejší použití

- Cena - Náročnější systémové požadavky - Dlouhá instalace - Omezení na platformu Windows

- Nepřítomnost GUI - Vytváření a správa testů - Reporty - Omezení na platformu Windows

Nevýhody

Veškeré výkonové čítače dostupné ve Windows

Tabulka 4.1: Srovnání nástrojů pro výkonnostní testování

29

5

Vytvoření testovacího prostředí

Prostředí pro výkonnostní testování by v ideálním případě mělo odpovídat prostředí, ve kterém bude daný systém reálně nasazen. V praxi se však setkáváme s tím, že by to bylo příliš nákladné a kolikrát se musíme spokojit s tím, co máme zrovna k dispozici a na základě porovnání testovacího a reálného prostředí udělat nějaké odhady. V následujících podkapitolách se podíváme na prostředí, ve kterém budeme testovat Kentico CMS 6.

5.1

Software

Všechny počítače počítače poběží na operačním systému Windows. Webové servery a SQL server konkrétně na Windows Server 2008 R2 (mají nastavený dual-boot, kde je druhou volbou starší Windows Server 2003 R2 SP2), klientské počítače mají nainstalované Windows Server 2003 R2 SP2. Pro běh Kentico CMS je na webových serverech potřeba mít nainstalovaný .NET Framework 3.5 SP1 (nebo vyšší) a Internet Information Services (součásti Windows), na SQL serveru budeme mít navíc Microsoft SQL Server 2008 R2. Na jednom z klientských počítačů je nutné mít nainstalované Microsoft Visual Studio 2010 Ultimate a pro spouštění testů z více počítačů najednou musíme mít nainstalované Microsoft Visual Studio Agents 2010 (obsahuje Test Controller 2010 i Test Agents 2010 zajišťující distribuované spouštění testů a kolekci dat). Konkrétní nastavení si ukážeme v kapitole 7.3.1.

5.2

Hardware

Pro výkonnostní testování máme k dispozici celkem 7 počítačů, které jsou na oddělené síti od firemní domény. Jejich konfigurace odpovídá běžným kancelářským strojům s rychlejšími disky, pouze databázový server má oproti webovým serverům a klientským počítačům více paměti (4x4GB):

Základní deska

Giga-Byte EP45C-DS3R (Intel® Socket 775, Intel® P45)

Procesor

Intel® Core™ 2 Quad Q9400 BOX (2.66 GHz)

Grafická karta

MSI R4350-D512H PCIE 512 MB DDR2 SDRAM

Paměť

Kingston 2G-UDIMM (PC2-6400), 4GB (2x2GB) DDR2 SDRAM, 1066 MHz

Pevný disk

WD1500HLFS VelociRaptor 5RZ, 150GB SATA II, 10000 rpm, 16MB Cache Tabulka 5.1: Konfigurace počítačů pro testování

Původní zapojení pro testování bylo navrženo tak, aby se co nejméně projevovalo omezení propustnosti sítě, a proto má každý klient výhradní linku ke svému webovému serveru a i mezi oběma servery vede dedikovaná gigabitová linka. Zapojení se může v průběhu testování měnit v závislosti 30

na aktuálně prováděných testech a vždycky si jej uvedeme. Tato konfigurace je připravena na testování tzv. web farmy, kdy stejná aplikace běží na více fyzických strojích (WEB1, WEB2), aniž by to uživatel poznal (navenek se tváří jako jeden server).

Obrázek 5.1: Síťové schéma zapojení serverů a klientů

31

6

Návrh testovacích scénářů

V této kapitole navrhneme několik základních scénářů pro testování Kentico CMS 6, které budou realizovány pomocí nástroje Visual Studio 2010. Protože Kentico nabízí několik ukázkových webů pro vyzkoušení, můžeme je s výhodou použít i pro naše účely (případně si je patřičně upravit). Nejedná se o produkční optimalizované weby, ale dá se na nich ukázat nabízená funkcionalita a minimálně pro začátek budou určitě stačit.

6.1

Statický web – ladění aplikace

Nejprve uděláme základní test propustnosti aplikace při servírování statického obsahu. Zde by se měla dát naplno využít aplikační vyrovnávací pamět (cache) a výsledné hodnoty pak budou sloužit jako referenční u dalších testů. Uděláme tedy srovnání jednotlivých nastavení vyrovnávací paměti (vypnuto, s ukládáním obsahu / datových zdrojů – Content cache, s ukládáním HTML výstupu celé stránky – Output cache) a pro každé nastavení určíme maximální počet simultánně připojených virtuálních uživatelů. Tyto scénáře by nám měly dát představu o tom, jak velkou zátěž dokáže vygenerovat testovací sestava a jak se s ní vypořádá webový server. Můžeme použít základní osobní web „Personal site“, kde každý virtuální uživatel navštíví jeden z 10 různých příspěvků na blogu a protože nám jde čistě o maximální propustnost aplikace, nemusíme si dělat starosti se simulováním reálného chování uživatelů na webu. Zátěž budeme generovat ze dvou klientských počítačů, které mají na webový server přímou linku:

Obrázek 6.1: Schéma zapojení počítačů v testu

Pro každé nastavení vyrovnávací paměti provedeme desetiminutový test, během něhož se bude postupně zvyšovat počet virtuálních uživatelů a podle rychlosti odezvy potom určíme jejich maximální počet, se kterým se naše aplikace dokáže vypořádat podle předpokladů. Jako limit si nastavíme dobu odezvy stránky na 4 vteřiny (včetně doby odezvy všech závislých požadavků, které mohou být ukládané do vyrovnávací paměti nástroje simulující chování prohlížeče) – jakmile bude

32

tento práh překročen, budeme vědět, že už nemůžeme přidávat žádné další virtuální uživatele, protože by načítání stránky bylo pro uživatele příliš pomalé.

6.2

Dynamický obsah – ladění databáze

Obsah, který se často mění a není možné jej z nějakého důvodu ukládat do paměti, se musí načítat z databáze. Potom je velice důležité, jaké dotazy se na databázi volají a jak je na ně připravená. Kromě dynamického obsahu na živém webu by měl tento scénář pokrýt také administrační rozhraní a prozradit, kolik současně připojených editorů může pohodlně pracovat s obsahem webu případně objekty v aplikačním rozhraní. V tomto scénáři se budeme snažit o reálnější simulaci provozu než v předchozím případě a v jednotlivých testech určitě využijeme času na rozmyšlenou (think time). Zapojení necháme z předchozího testování a opět budeme zvyšovat počet virtuálních uživatelů. Zátěžový test bude obsahovat minimálně následující scénáře: 

Vytváření a úprava dokumentů



Vyhledání dokumentu a čtení jeho vlastností



Kontrola nástěnky (dashboard) v MyDesk



Kontrola systémových informací (System, EventLog, ScheduledTasks, EmailQueue)



Přiřazení uživatele do role



Filtrování kontaktů a prohlížení jejich aktivit

6.3

Webová analytika (návštěvníci, aktivity)

Zde se zaměříme na logování chování uživatelů na webu, jak moc to aplikaci brzdí a schopnost aplikace zpracovávat zalogovaná data. Definujeme několik kampaní a necháme uživatele navštěvovat webové stránky v různém procentuálním rozložení s případným stažením nějakého dokumentu (jako cílovou aktivitu). U těchto testů si musíme dát pozor na to, aby jednotlivé běhy nebyly ovlivněny vysokým počtem záznamů v databázi z předchozího testování a také bude velice důležité nastavení nových (resp. vracejících se) virtuálních uživatelů, aby se nám nevytvořilo během několika desetiminutových testů milion nových anonymních kontaktů, které už nikdy nepoužijeme.

6.4

Chat modul

Do nové verze Kentico CMS 7 byl implementován modul, který umožňuje uživatelům vytvářet diskuzní místnosti, kde mohou komunikovat s ostatními uživateli v reálném čase. V tomto scénáři je potřeba ověřit, že naše aplikace unese komunikaci několika desítek/stovek uživatelů v jedné místnosti a že je možné zároveň používat několik desítek místností. 33

Testování webů pomocí VS 2010

7

Po instalaci Visual Studio 2010 se konečně můžeme podívat na samotné vytváření testů, jejich spouštění, ladění a zpracování výsledků. Jak už bylo zmíněno ve čtvrté kapitole, webové testy představují automatické funkční testování webových stránek, přičemž se dají sdružovat do zátěžových testů, abychom mohli simulovat chování více uživatelů najednou. Tento proces si tedy v následujících kapitolách podrobněji popíšeme. Pro více informací, snímky obrazovky, ukázkovou webovou aplikaci a vytvořené testy můžeme nahlédnout do [16]. Nejrůznější vychytávky a řešení problémů pak můžeme nalézt v [17].

7.1

Webové výkonové testy

Webové výkonové testy (web performance tests) jsou základním stavebním kamenem testovacích scénářů. Dříve (před vydáním VS 2010) se jim říkalo zkráceně webové testy (web tests), ale Microsoft přidal slovíčko výkonové (performance) právě proto, aby v uživatelích evokovalo zaměření jejich použití na výkon a odlišilo je od automatických testů uživatelského rozhraní neboli kódových testů UI (Coded UI tests), které byly k testování webových aplikací také hojně používány. Webový test odpovídá chování jednoho uživatele na daném webu, které však může být vysoce parametrizované, což si dále ukážeme.

7.1.1

Vytváření a úprava testů

Pokud do testovacího projektu přidáme nový Web Performance Test, bude mít příponu .webtest a otevře se nám internetový prohlížeč (Internet Explorer) s integrovaných modulem Web Test Recorder pro nahrání testovacího scénáře. Soubor s příponou .webtest je XML soubor, ve kterém jsou specifikovány jednotlivé položky tak, aby je rozhraní Visual Studio mohlo zobrazit v Test Editoru. Existuje několik možností, jak testy vytvářet a upravovat: 

Pracovat v prostředí internetového prohlížeče jako běžný uživatel a simulovat jeho chování, které se po ukončení nahrávání uloží do právě otevřeného webového testu jako sada požadavků (requests) včetně závislých požadavků (obrázky, skripty, CSS, atp.).



Nepoužívat internetový prohlížeč a místo toho psát jednotlivé požadavky (Request URLs) na webovou aplikaci ručně v Test Editoru.



Z webového testu vygenerovat kód (C# nebo Visual Basic) a upravovat jej ručně.



Nepoužívat vůbec rozhraní webových výkonových testy a namísto nich přímo psát kód s využitím testovacího frameworku.

34

Nahrávání testů pomocí webového prohlížeče je pohodlné a umožňuje dokonale simulovat chování uživatele. Mezi jednotlivými požadavky je zaznamenávána i časová prodleva, tedy jakýsi čas na rozmyšlenou (think time), čehož můžeme později využít při přehrávání testů. Průběh nahrávání můžeme také pozastavit, smazat, anebo jednotlivé požadavky opatřit komentářem. Na co je potřeba dát si pozor, je fakt, že je zaznamenáván veškerý síťový provoz z prohlížeče, takže se nám do nahrávání mohou plést požadavky nejrůznějších plug-inů a modulů prohlížeče (například našeptávání při psaní webové adresy, RSS čtečka, atp.). Proto je doporučeno v době nahrávání testů taková rozšíření prohlížeče zakázat. Na následujícím obrázku můžeme vidět rozhraní Visual Studio 2010 při nahrávání webového výkonového testu WebTest1.webtest. Je zde vidět otevřený Web Test Recorder vestavěný do Internet Exploreru a pod ním rozhraní Web Test Editoru, kde se po dokončení nahrávání bude moci daný test upravovat a ladit.

Obrázek 7.1: Nahrávání webového výkonového testu ve Visual Studio 2010

7.1.2

Možnosti Web Test Editoru

Jakmile máme nahraný scénář, můžeme ho v rozhraní Web Test Editoru začít upravovat. Na obrázku níže máme jednoduchý test, který vyzkouší, zda se různých 100 uživatelů specifikovaných pomocí parametrů ze zdroje dat (data source) může přihlásit do systému a poté se z něj zase odhlásit. Z tohoto obrázku budeme vycházet při popisu dalších vlastností Web Test Editoru.

35

Obrázek 7.2: Úpravy testu ve Web Test Editoru

Samotný test tvoří pouhé tři požadavky (requests) na webovou stránku Home.aspx, kde se také nachází formulář pro přihlášení uživatele (textová pole pro uživatelské jméno a heslo + tlačítko pro potvrzení formuláře). 

Při prvním požadavku se tedy načte stránka, z níž jsou pomocí extrakčních pravidel (extraction rules) extrahována skrytá pole formuláře (hidden fields) včetně ViewState.



Druhý požadavek slouží k vlastnímu odeslání formuláře, přičemž si můžeme všimnout, jakým způsobem je formulář vyplněn – jeho skrytá pole jsou vyplněna extrahovanými hodnotami z předchozí stránky (také proto, aby prošla validací MAC – machine authentication check) a políčka jména s heslem jsou naplněna z externího zdroje dat (v našem případě je to jednoduchý CSV soubor).



Po úspěšném přihlášení se na místě textových polí na stránce vypíše jméno přihlášeného uživatele a tlačítko pro přihlášení je zaměněno za tlačítko pro odhlášení, což je kontrolováno pomocí validačního pravidla (validation rule), které hledá text ve stránce.



Poslední požadavek na stránku je ve skutečnosti kliknutí na tlačítko pro odhlášení.

Takto se postupuje ve smyčce pro 100 uživatelů z externího datového zdroje. Všimněme si, že v jednotlivých požadavcích používáme kontextové parametry (context parameters) uzavřené do dvojic složených závorek. Tyto parametry mohou být definovány předem (ať už jako datový zdroj nebo řídicí proměnná), ale můžeme je také vytvářet až za běhu – např. právě 36

extrahováním dat z odpovědi webového serveru (response) nebo pomocí různých rozšíření (plug-in). Ve skutečnosti však máme k dispozici daleko více prvků, které můžeme do webových výkonnostních testů zakomponovat a postupně se na ně podíváme dále. Datové zdroje Datové zdroje jsou jednou z nejdůležitějších součástí každého testu, protože právě to nám dává výhodu oproti manuálnímu testování. Zde máme možnost použít data z databáze (tabulky nebo pohledu), CSV souboru nebo XML. U databáze jsou podporované standardní poskytovatele dat (data providers) v .NET, takže je možné bez problému použít například Oracle databázi. Ke všem zdrojům dat se potom přistupuje stejně jako ke kontextovým parametrům, jenom je navíc možné zvolit způsob přístupu k jednotlivým položkám – zda se mají ve smyčce procházet sekvenčně (Sequential), náhodně (Random), anebo každý řádek projít pouze jednou (Unique). U datových zdrojů je potřeba dát si pozor na to, že při distribuovaném spouštění na více agentech musí mít každý agent tento zdroj dat dostupný (ve stejném umístění) a že se při volbě Unique rozdělí data mezi jednotlivé agenty, zatímco při ostatních volbách má každý agent k dispozici celou množinu dat. Parametrizace požadavků Běžnou praxí je postup, kdy se webové testy píšou a ladí na lokálním stroji a až poté se přenesou na nějakou výkonnou sestavu pro získání relevantních výsledků. Hlavně proto je nám umožněno pohodlně parametrizovat webový server, což ve skutečností znamená, že se po kliknutí na ikonku Parametrize Web Servers vytvoří nový kontextový parametr (context parameter), kterým bude nahrazena serverová část URL každého požadavku na daný web server. Můžeme tak pohodlně na jednom místě změnit parametr a rázem testy poběží na jiném stroji. U každého požadavku je možné specifikovat, zda má zpracovávat také závislé požadavky (Parse Dependent Requests), jaký je očekávaný HTTP Status Code odpovědi, jestli následovat přesměrování, a spoustu dalších možností. Ke každému webovému požadavku (web request) je navíc možné přidat libovolný počet následujících položek: 

HTTP hlavičky (Header) – Např. Accept-Encoding, Cache-Control, Host, User-Agent, atp.



Parametr URL (QueryString Parameter) – Libovolné parametry, které se pak ve správném formátu připojí do URL.



Parametr formuláře (Form Post Parameter) – Opět se jedná o libovolné parametry přidané ve správném formátu, tentokrát ale do POST požadavku.



Parametr s nahrávaným souborem (File Upload Parameter) – Umožňuje simulovat nahrání souboru z disku (resp. dat ve specifikovaném MIME type).



Validační pravidlo (Validation Rule) – Slouží k rozhodování, zda byl daný požadavek vyřízen podle předpokladů, například jestli obsahuje nějaký určitý HTML tag nebo text,

37

případně zda byl správně vyplněný formulář, jestli byla doba odpovědi menší než určitá hodnota, atp. Každé pravidlo má nějakou úroveň (Low, Medium, High), aby bylo možné specifikovat chování za běhu testu – např. všechna pravidla s úrovní Medium a výše musí být splněna, jinak bude test přerušen. Výsledkem validačního pravidla je vždy pravdivostní hodnota true nebo false. 

Extrakční pravidlo (Extraction Rule) – tato pravidla nám umožňují extrahovat data z odpovědi webového serveru (ať už je to hlavička, formulářové pole, či prostý text) a ukládat je do kontextových parametrů pro pozdější použití. Velice se zde hodí podpora regulárních výrazů.



Plug-in na úrovni požadavku (request plug-in) – k implementaci rozšíření se dostaneme v kapitole 7.4.

Řídicí struktury Okolo webových požadavků lze vytvářet řídicí struktury – máme k dispozici podmínky a cykly. V podmínkách můžeme s výhodou použít kontextové parametry, cookies, porovnávání číselných i řetězcových hodnot a opět není problém si tento seznam pravidel libovolně rozšířit. Zajímavá je také volba pravděpodobnosti (Probability Rule), ve které se dá specifikovat, s jakou pravděpodobností má být podmínka splněna. Tyto podmínky se využívají i v cyklech, kde je navíc možné specifikovat i počet opakování (tradiční cyklus for) a důležitým nastavením každého cyklu je položka Advance Data Cursors, která určuje, zda se má použít další řádek hodnot z datových zdrojů (např. v ukázkovém příkladu jsme chtěli, aby se postupně přihlásilo sto různých uživatelů a ne aby se přihlásil stokrát ten samý). Další možnosti Jak jsme si také mohli všimnout v ukázkovém příkladu, do testu je možné vkládat komentáře. To se hodí jednak pro pozdější úpravy testů, ale také pro sledování jejich průběhu, protože pokud má test několik desítek požadavků, může být velice složité se v něm později orientovat a hledat chybu. Další šikovnou možností je vyjmutí části testu do nového testu (Extract Web Test) a vložení volání jiného testu do aktuálního (Insert Call to Web Test), což nám pomáhá zejména v přehlednosti (výsledné testy jsou menší) a udržovatelnosti (úprava jednoho chování na jednom místě) – například si můžeme vytvořit automatické přihlášení do systému s přechodem na domovskou stránku a potom jej můžeme použít na začátku každého testu, aniž bychom to museli znovu nahrávat a ladit. Když se potom změní umístění přihlašovací stránky, bude nám stačit úprava jednoho parametru v jednom testu namísto toho, abychom pátrali, kde všude se takové přihlašování používalo.

38

7.1.3

Generování kódu

Samozřejmě, že pokud se vydáme cestou psaní kódu, jsou naše možnosti omezené pouze vlastnostmi daného programovacího jazyka (případně .NET frameworku). Web Test Editor umožňuje z daného webového výkonového testu vygenerovat kódový webový výkonový test pomocí tlačítka Generate Code, což má za následek, že se z XML souboru .webtest, který byl upravovatelný ve Web Test Editoru, stane klasický zdrojový kód v souboru Coded.cs (v případě generování C# kódu). Ten je poté možno libovolně upravovat, ale už neexistuje cesta zpět, jak ze zdrojového kódu vytvořit klasický webový výkonový test (XML soubor)! Při psaní testů jsou nám k dispozici například následující knihovny: 

Microsoft.VisualStudio.QualityTools.LoadTestFramework.dll



Microsoft.VisualStudio.QualityTools.WebTestFramework.dll



Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

a odpovídající jmenné prostory (namespaces):   

using Microsoft.VisualStudio.TestTools.LoadTesting; using Microsoft.VisualStudio.TestTools.WebTesting; using Microsoft.VisualStudio.TestTools.UnitTesting;

Pro ukázku převedení webového výkonového testu na kódový webový výkonový test použijeme ještě jednodušší test než v předchozím případě, ale bude obsahovat většinu důležitých prvků:

Obrázek 7.3: Webový výkonový test před konverzí

39

Vidíme, že test obsahuje jediný požadavek, který je vykonán s pravděpodobností 50%. Tento požadavek má parametr v URL, je odesílán pomocí POSTu a formulářové pole UserName je navázáno z datového zdroje. Do hlavičky jsme mu přidali Referer a po odeslání chceme veškerá skrytá pole formuláře uložit/extrahovat do kontextového parametru $HIDDEN1. Tento test má parametrizovaný WebServer pomocí kontextového parametru WebServer1 a používá dvě validační pravidla. Nyní se podíváme na to, jak se nám vygeneroval kód v jazyce C#, přičemž některé (v tuto chvíli méně podstatné) části zkrátíme pomocí tří teček „...“. //-----------------------------------------------------------------------------// // This code was generated by a tool. // Runtime Version:4.0.30319.261 // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // //-----------------------------------------------------------------------------namespace { using using using using using

PerformanceTests System; System.Collections.Generic; System.Text; Microsoft.VisualStudio.TestTools.WebTesting; Microsoft.VisualStudio.TestTools.WebTesting.Rules;

[DeploymentItem("Users.csv")] [DataSource("DataSource1", "Microsoft.VisualStudio.TestTools.DataSource.CSV", "|DataDirectory|\\Users.csv", Microsoft.VisualStudio.TestTools.WebTesting.DataBindingAccessMethod.Sequential, Microsoft.VisualStudio.TestTools.WebTesting.DataBindingSelectColumns.SelectOnlyBoundColu mns, "Users#csv")] [DataBinding("DataSource1", "Users#csv", "UserName", "DataSource1.Users#csv.UserName")] ... public class WebTestExampleCoded : WebTest { public WebTestExampleCoded() { this.Context.Add("WebServer1", "http://localhost"); ... } public override IEnumerator<WebTestRequest> GetRequestEnumerator() { // Initialize validation rules that apply to all requests in the WebTest if ((this.Context.ValidationLevel >= Microsoft.VisualStudio.TestTools.WebTesting.ValidationLevel.Low)) { ValidateResponseUrl validationRule1 = new ValidateResponseUrl(); this.ValidateResponse += new EventHandler(validationRule1.Validate); } ... // Web Test (Request) Comment this.AddCommentToResult("Web Test (Request) Comment");

40

ProbabilityRule conditionalRule1 = new ProbabilityRule(); conditionalRule1.ContextParameterName = "Probability"; conditionalRule1.Percentage = 50D; this.BeginCondition(conditionalRule1); if (this.ExecuteConditionalRule(conditionalRule1)) { WebTestRequest request1 = new WebTestRequest((this.Context["WebServer1"].ToString() + "/Release_6.0_SC10/Home.aspx")); request1.ThinkTime = 11; request1.Method = "POST"; request1.Headers.Add(new WebTestRequestHeader("Referer", "http://www.referer.com")); request1.QueryStringParameters.Add("viewmode", "livesite"); FormPostHttpBody request1Body = new FormPostHttpBody(); request1Body.FormPostParameters.Add("UserName", this.Context["DataSource1.Users#csv.UserName"].ToString()); request1.Body = request1Body; ExtractHiddenFields extractionRule1 = new ExtractHiddenFields(); extractionRule1.Required = true; extractionRule1.HtmlDecode = true; extractionRule1.ContextParameterName = "1"; request1.ExtractValues += new EventHandler<ExtractionEventArgs>(extractionRule1.Extract); yield return request1; request1 = null; } this.EndCondition(conditionalRule1); ... } } }



Vytvoří se nova třída, které dědí ze základní třídy WebTest.



Pomocí atributů jsou definovány datové zdroje a způsob jejich použití: o

DeploymentItem označuje soubor, který bude kopírován s testem při jeho reálném

nasazení (deployment), o

DataSource slouží k pojmenování datového zdroje, určení jeho typu a možnosti

přístupu, o 

DataBinding definuje navázání datového zdroje do kontextového parametru.

V konstruktoru jsou přidány kontextové parametry na úrovni Web Testu pomocí: this.Context.Add(, ) .



Následuje překrytí (override) metody GetRequestEnumerator(), která obsahuje celý test – jde vlastně o implementaci enumerátoru pro kolekci požadavků (WebTestRequest).



Nejprve jsou inicializována veškerá validační pravidla, která platí pro celý test (navíc v závislosti na tom, jaká validační úroveň (validation level) je při testování nastavená) a poté už jsou uvedeny jednotlivé položky samotného testu.

41



Komentáře ve webovém testu se přidají do kódového testu jako klasické komentáře a navíc se stejné komentáře přidají i do výsledku testu (aby byly vidět při přehrání).



Dále vidíme použití podmínky z Microsoft.VisualStudio.TestTools.WebTesting.Rules – nejprve se nadefinuje (např. jako conditionalRule1) a potom je uzavřena do konstrukce, v níž se pravidlo spustí a pokud vrátí logickou hodnotu true, je vykonáno tělo podmínky: this.BeginCondition(conditionalRule1); if (this.ExecuteConditionalRule(conditionalRule1)) { ... } this.EndCondition(conditionalRule1);



Teď už nám zbývá jenom vytvoření samotného požadavku (WebTestRequest), který má v konstruktoru uvedenou URL, přičemž vidíme také použití kontextového parametru.



Dále jsou nastavené veškeré parametry požadavku, od QueryString parametru, přes tělo formuláře, až po extrakční pravidlo pro extrahování skrytých polí formuláře.



Jakmile je požadavek plně definován, yield return request1; se postará o zařazení požadavku do kolekce požadavků, aby mohl být při spuštění testu proveden.

Vidíme, že vytváření kódových webových výkonových testů není vůbec složité, ale může být velice pracné. Doporučený postup je tedy nahrání webového výkonového testu pomocí Web Test Recorderu, volitelně jeho parametrizace ve Web Test Editoru, vygenerování kódu a jeho následná úprava.

7.2

Zátěžové testy

Když už máme vytvořené webové výkonové testy, které nám simulují chování jednoho uživatele na webu, přichází čas vytvořit zátěžové testy (load tests), které nám budou simulovat chování více uživatelů najednou. Stejně jako webové výkonové testy jsou to vlastně XML soubory (tentokrát s příponou .loadtest), takže se dá v případě nutnosti (například kvůli nedostupnému nastavení v GUI) upravovat přímo XML. Když přidáme do našeho projektu nový zátěžový test, objeví se pomocník (New Load Test Wizard), který nás provede veškerým nastavením zátěžového testu krok za krokem, přičemž každý krok má pěkně popsané jednotlivé volby tak, aby se ani začátečník neztratil. Navíc se všechna nastavení dají později upravit, takže není problém, když tohoto pomocníka nebudeme chtít používat. Jednotlivá nastavení zátěžových testů (resp. jejich možnosti) si ukážeme dále.

42

Scénáře (Scenarios) Zátěžový test se může skládát z několika scénářů, přičemž každý scénář obsahuje kromě vlastního nastavení také Mix testů, prohlížečů a sítí. Více scénářů se hodí například ve chvíli, kdy chceme opravdu rozlišit různé skupiny uživatelů a každé skupině přiřadit vlastní testy – například v jednom scénáři můžeme mít uživatele vnitřní sítě se stejným prohlížečem a ve druhém scénáři externí uživatele připojené pomocí pomalejšího připojení a vykonávající úplně jiné testy. Zátěžový vzor (Load Pattern) Každý scénář může používat jiný způsob zátěže (změnu počtu konkurentních virtuálních uživatelů) a možnosti máme tři:  konstantní počet virtuálních uživatelů,  zvyšující

se

počet,

přičemž

definujeme

minimální počet, maximální počet a o kolik se má v jakém

časovém

intervalu

počet

uživatelů

navyšovat,  počet uživatelů, který je automaticky upravován (zvýšen nebo snížen v rámci nastavených mezí) na základě hodnot nějakého výkonového čítače (zpravidla vytížení procesoru nebo paměti RAM). Obrázek 7.4: Zátěžový test v Load Test Editoru

Každý typ zátěže se používá v jiné situaci. Konstantní zátěž (constant load pattern) volíme tehdy, kdy chceme zjistit, zda máme vše správně nastavené, testy se spouštějí ve správném pořadí a rozložení, jestli aplikace odpovídá očekávaným způsobem (tzv. smoke test, který stačí ověřit na nízké zátěži), anebo naopak když testujeme maximální možnou propustnost aplikace. Postupně rostoucí zátěž (step load pattern) použijeme například pro zjištění maximálního počtu uživatelů, při kterém ještě aplikace zvládá reagovat podle očekávání a při jehož překročení už začne docházet k problémům (stress testing). A nakonec zátěž zaměřená na dosažení cíle (goal based pattern) se používá pro ověření, že bude aplikace schopná dlouhodobě běžet v daných podmínkách a přežije uživatelské špičky.

43

Mix testů a jejich model (Test Mix) Jednotlivé webové výkonové testy přiřazujeme do mixu testů, přičemž máme čtyři možnosti, jak se nakonec budou během zátěžového testu spouštět: 

Na základě počtu spuštěných testů daným uživatelem – procentuální rozložení testů, kdy je virtuálnímu uživateli přiřazen test podle toho, kolikrát už provedl jiný test. Například pokud máme v mixu testů dva testy, kdy v jednom testu daný uživatel čte nějaký blogový příspěvek, ve druhém testu k danému příspěvku připojí komentář a my chceme namodelovat situaci, kde uživatel ke každému pátému příspěvku připojil komentář, nastavíme mix na 80% pro pouhé čtení blogu a 20% pro čtení s přidáním komentáře.



Na základě počtu virtuálních uživatelů – opět procentuální rozložení testů, ovšem tentokrát nastavená procenta znamenají, kolik virtuálních uživatelů daný test spustí. Hodí se například ve scénáři, kdy máme na webu několik editorů pracujících v systému a návštěvníků, kteří jenom prochází živý web – potom určíme, kolik procent virtuálních uživatelů bude v té které roli.



Podle počtu spuštění uživatelem za hodinu – toto nastavení se používá pro testy s dlouhým časem na rozmyšlenou – když například simulujeme situaci, kdy si každý uživatel sociální sítě v průměru pětkrát za hodinu zkontroluje status ostatních a jednou za hodinu změní ten vlastní.



Sekvenčně za sebou – slouží k vykonávání testů v přesném pořadí za sebou – tímto lze například simulovat nákupní proces.

Mix prohlížečů (Browser Mix) V tomto nastavení každého scénáře můžeme nastavit procentuální rozložení použití různých prohlížečů. Použití prohlížeče neznamená, že by se používalo jiné vykreslovací jádro, ale jde o použití jiných hlaviček v požadavcích – zejména User-Agent řetězec. Webová aplikace totiž může uživatelům poskytovat různý obsah právě na základě definice prohlížeče (např. obsah pro mobilní zařízení). Máme k dispozici několik předdefinovaných prohlížečů a další lze přidávat pomocí XML souborů v umístění instalace Visual Studio – typicky je to %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\Templates\LoadTest\Browsers\. Definice prohlížeče může vypadat například takto:

44

Mix sítí (Network Mix) Podobně jako je to u prohlížečů, můžeme definovat i různé druhy sítě, abychom mohli reálněji napodobit připojení jednotlivých uživatelů. Visual Studio přichází se softwarovým síťovým emulátorem, který simuluje chování různých sítí přímo na úrovni paketů. Každý typ sítě pak definuje její propustnost, ztrátovost paketů, latenci, atd., přičemž tyto parametry mohou být rozděleny podle směru – od klienta k serveru a obráceně. Máme k dispozici několik předdefinovaných typů (LAN, 3G, Dial-up, kabelové připojení 1.5Mbps/768Kbps/384Kbps, atp.) a další můžeme stejně jako u prohlížečů doplnit mezi ostatní XML soubory s nastavením potřebných parametrů do %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\Templates\LoadTest\Networks\. Po restartování Visual Studia se objeví mezi ostatními volbami. Sady výkonových čítačů (Counter Sets) Bez výkonových čítačů (Peformance Counters) by výkonové testy postrádaly smysl – právě toto jsou ukazatele, které nás při testování zajímají. Jsou rozděleny do několika předdefinovaných kategorií (resp. sad), ale není problém si vytvořit vlastní. Máme k dispozici veškeré výkonové čítače systému – od vytížení procesoru, disku, sítě, paměti, a k tomu navíc statistiky vlastních testů (počet spuštěných testů, virtuálních uživatelů, požadavků, transakcí, chyb, atd.). Můžeme si také vytvářet vlastní skupiny čítačů a to jak přímo v rozhraní, tak i pomocí XML souborů, stejně jako tomu bylo u prohlížečů a sítí, tedy typicky v umístění %ProgramFiles%\Microsoft Visual Studio 10.0\ Common7\IDE\Templates\ LoadTest\CounterSets. U každého čítače se dají nastavit prahové hodnoty, po jejichž překročení bude systém hlásit varování případně chybu. Všechny čítače mají na základě zkušeností Microsoftu předdefinované hodnoty tak, aby se jimi uživatel nemusel zpočátku zabývat, ale mohl si je kdykoli upravit, což rozhodně přispívá uživatelskému pohodlí. Samozřejmě můžeme sbírat čítače i ze vzdálených strojů (což je při testování nejčastější varianta), stačí v nastavení běhu přidat počítače, ze kterých se mají data sbírat a přiřadit k nim dané sady výkonových čítačů, jejichž data chceme sbírat. Pouze je třeba dát si pozor na správné nastavení uživatelských oprávnění a spuštěných služeb na jednotlivých počítačích. Nastavení běhu zátěžových testů (Run Settings) Dostáváme se k poslední velké sadě nastavení zátěžového testu – nastavení jeho běhu. Opět můžeme definovat více souborů s nastavením, ale na rozdíl od scénářů, které se používají souběžně, pouze jeden soubor s nastavením běhu může být aktivní. Veškerá nastavení jsou velice pěkně popsána, takže si uvedeme jenom ty nejdůležitější z nich. Hlavním nastavením je doba, po kterou má daný test běžet (Run Duration) – můžeme ji buď specifikovat jako počet hodin, minut a sekund s případným časem na zahřátí aplikace (kdy se ještě nesbírají data výkonových čítačů, abychom neměli zkreslené výsledky testů kvůli dlouhému startu

45

aplikace, kompilaci různých stránek, načítání dat do vyrovnávací paměti, apod.), anebo využijeme možnosti spuštění určitého počtu iterací (Test Iterations) – toto nastavení zajistí, aby test proběhl právě tolikrát, bez ohledu na počet virtuálních uživatelů (i když máme 50 virtuálních uživatelů a nastavíme počet iterací na 10, test bude spuštěn právě 10x a ne 500x). Dalším důležitým nastavením je frekvence vzorkování (Sample Rate), které nám říká, jak často se budou sbírat data výkonových čítačů. Čím častěji se data budou sbírat, tím více detailů budeme mít k dispozici, zároveň je ale potřeba myslet i na velikost těchto dat v databázi s výsledky – například určitě nebudeme potřebovat, aby se nám při celodenním testu sbírala data každých 5 vteřin a naopak při krátkém desetiminutovém testu nenecháme sbírat data každou minutu, protože bychom měli nakonec jenom 10 vzorků. Také si můžeme vybrat, jestli vůbec budeme ukládat data (Storage Type) do databáze, anebo se data nemají ukládat vůbec (jsou v paměti, aby se mohly vykreslovat grafy a zobrazovat tabulky v průběhu testu, ale nejsou uložená persistentně) – například při krátkodobém ladění aplikace a testů si nemusíme ukládat výsledky jednotlivých běhů. Posledním důležitým nastavením, které si uvedeme, je validační úroveň (Validation Level), která označuje maximální úroveň, kterou musí mít validační pravidlo, aby mohlo být v rámci zátěžového testu spuštěno – tyto úrovně jsou tři (Low, Medium, High). Pro jistotu uvedeme příklad – pokud má test nastavenou úroveň High, budou spuštěna úplně všechna pravidla a naopak pokud má nastavenou úroveň Low, budou spuštěna pouze pravidla s nastavenou úrovní Low. Toto se hodí zejména v případě, kdy je pro nás důležitější výkon, než ověřování všech pravidel ve webových testech. Jak bylo řečeno na začátku, můžeme mít nadefinovaných více souborů s nastavením běhu testů, což se hodí, pokud chceme mít různé nastavení pro krátký „smoke“ test, jestli je vše dobře zapojeno a nastaveno, krátké testy, které ověřují určitou funkcionalitu, ale nepotřebujeme zaznamenávat výsledky do databáze a potom třeba nastavení pro testy, jejichž výsledky budeme chtít navzájem porovnávat. Potom stačí daný soubor nastavit jako aktivní (Set As Active) a spustit zátěžový test.

7.3

Spouštění testů

Dostáváme se k samotnému spouštění testů a v této kapitole se podíváme na jeho různé možnosti. Nejjednoduší je zřejmě použití tlačítka Run Test v Load Test Editoru (případně Web Test Editoru) nebo použití stejnojmenné volby z kontextového menu na libovolné položce testu. Kromě normálního spuštění máme k dispozici i volbu Debug Test, která se hodí zejména při použití vlastních rozšíření do testů a/nebo kódových webových výkonových testů. I když je použití GUI velice pohodlné, testy můžeme spouštět i z příkazového řádku pomocí utility MSTest.exe, kterou najdeme v instalačním adresáři Visual Studio. To se může hodit ve chvíli, kdy chceme pravidelně spouštět (například jako naplánovanou úlohu – Scheduled Task) nějakou sadu testů a ověřit si tak, že vše funguje, jak má.

46

U webových výkonových testů je v souvislosti se spouštěním testů poměrně důležité nastavení v Test Settings -> Web Test, které nám říká, kolikrát má daný Web Test proběhnout (Fixed run count), případně jestli má být spuštěn pro každý řádek datového zdroje (One run per data source row), jaký prohlížeč má být použit a zda simulovat čas na rozmyšlenou (Simulate think times). Typicky nám bude stačit jeden běh testu v libovolném prohlížeči a bez simulace času na rozmyšlenou, ale to se samozřejmě může časem měnit podle testovaného scénáře (například když potřebujeme ověřit, že máme v datovém zdroji korektní data a test je pro ně odladěný). Se spouštěním zátěžových testů souvisí i ukládání jejich výsledků. Pokud tedy chceme ukládat výsledky testů pro pozdější použití, musíme vytvořit databázi očekávané struktury (k tomu máme předpřipravený skript v instalačním adresáři Visual Studio 2010, tedy: %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\loadtestresults repository.sql), který stačí spustit například pomocí utility: SQLCMD /S /i loadtestresultsrepository.sql . Potom už následuje nastavení připojení k této databázi, aby se nasbíraná data a výsledky testů mohly začít ukládat. Toto nastavení bylo poněkud nelogicky umístěno do nabídky Test -> Manage Test Controllers -> Load test results store, přestože žádné kontrolery používat nemusíme. O tom, jak spouštět testy v distribuovaném prostředí, pojednává následující kapitola.

7.3.1

Distribuované testy

Kromě spouštění na lokálním počítači, které bude používáno především v době vytváření a ladění testů, můžeme potřebovat spouštění testů z více strojů najednou – zejména pro generování větší zátěže. Distribuované prostředí se skládá z několika počítačů v různých rolích, jimž se souhrnně říká Test Rig. Hlavní role plní agenti (Agents), což jsou stroje, které vytvářejí žádanou zátěž a/nebo sbírají data výkonových čítačů a tito agenti jsou řízeni jedním kontrolerem (Controller), který stará o rozdělování testů mezi agenty. K instalaci budeme potřebovat instalační CD (resp. jeho obraz – ISO image) Microsoft Visual Studio Agents 2010. Nejprve musíme z tohoto zdroje nainstalovat a zprovoznit Test Controller 2010 a potom na každý stroj v roli agenta nainstalovat Test Agent 2010, kterému se nastaví odpovídající kontroler. Kontroler i agenti běží jako standardní služby (Services) Windows, ale pro potřeby kódových UI testů je možné agenta spustit i ve formě klasického procesu. Dále je důležité, aby tito agenti měli dostatečná práva na čtení výkonových čítačů (služby musí běžet pod účtem, který bude ve skupině, jež má daná práva – nejjistějším nastavením je pochopitelně systémová skupina Administrators, ale za to by nás IT oddělení asi nepochválilo. Podobně bude potřeba přidat výjimku do firewallu a řešení případných dalších problémů nejen se sběrem dat je možné najít v [17].

47

Po instalaci na všech počítačích se v nabídce Test -> Manage Test Controller můžeme připojit k danému kontroleru a poté se nám zobrazí všechny stroje, které mají nakonfigurovaného agenta pro použití zvoleného kontroleru. Každý stroj může mít nastavené libovolné vlastnosti (attributes), což je vždycky dvojice název – hodnota, které potom můžeme využít například při jejich rozlišování. Můžeme tedy určit, kteří agenti mají generovat zátěž, který počítač slouží jako webový server, atp. Na následujícím obrázku můžeme vidět testovací sestavu, která se skládá ze dvou klientských počítačů použitých pro generování zátěže (CLIENT1, CLIENT2), webového serveru (WEB1/WEB1-2008) a databázového serveru (SQL1). Také vidíme nastavení připojení (ConnectionString) do databáze s výsledky, o které jsme se bavili v předchozí podkapitole. Zde máme možnost vypnout některé agenty nebo restartovat celou sestavu.

Obrázek 7.5: Možnosti nastavení pro distribuované testy

U každého agenta jde později nastavit také jeho váha (Weighting), takže kontroler může distribuovat zátěž nerovnoměrně podle nastavení vah jednotlivých agentů a přímo ve scénáři (Scenario Properties -> Agents to Use) můžeme specifikovat množinu agentů zařazených do testu, pokud ji chceme ještě nějak omezit (pokud necháme pole prázdné, kontroler může použít všechny agenty).

48

Implementace rozšíření

7.4

Rozšiřování možností testů není vůbec složité a můžeme ho provádět v několika úrovních: 

na úrovni samotného nástroje Visual Studio (Visual Studio Add-In),



na úrovni zátěžových testů (Load Test Plug-In),



na úrovni webových výkonových testů (Web Performance Test Plug-In),



na úrovni jednotlivých požadavků ve webovém výkonovém testu (Request-Level Plug-In).

Nejkomplikovanější postup je pochopitelně pro vytvoření rozšíření samotného nástroje Visual Studio, které se může týkat prakticky čehokoli – od zobrazení nové záložky s upraveným souhrnem výsledků testů, přes úpravu parsování odpovědi a navazování dynamických parametrů, až po nové možnosti nahrávání testů. My se však budeme dále zabývat rozšiřováním samotných testů. Doporučený postup je vytvořit novou knihovnu, ve které budou rozšiřující třídy a potom pouze přidat referenci na danou knihovnu do projektu s testy, což se hodí, zvláště když napíšeme rozšíření, která budeme chtít používat v několika testovacích projektech.

7.4.1

Rozšíření na úrovni zátěžových testů

Když chceme přidat vlastní rozšíření celému zátěžovému testu, musíme vytvořit třídu, která implementuje rozhraní Microsoft.VisualStudio.TestTools.LoadTesting.ILoadTestPlugin, což v praxi znamená naimplementovat metodu public void Initialize(LoadTest loadTest), ve které máme k dispozici objekt aktuálně spouštěného zátěžového testu. Kromě jeho vlastností můžeme obsluhovat následující události: Událost

Popis Heartbeat Nastává každou vteřinu LoadTestAborted Nastává při přerušení testu LoadTestFinished Nastává při ukončení testu na daném agentovi LoadTestStarting Nastává těsně před spuštěním testu na daném agentovi LoadTestWarmupComplete Nastává po uběhnutí času na zahřátí TestFinished Nastává při dokončení iterace jednoho z testů TestSelected Nastává při vybrání testu pro danou iteraci TestStarting Nastává při spouštění testu v dané iteraci ThresholdExceeded Nastává při překročení nastavené prahové hodnoty Tabulka 7.1: Tabulka nabízených událostí zátěžového testu

V rozhraní Load Test Editoru pak použijeme kontextové menu a volbu Add Load Test Plug-in. Pokud v projektu nemáme žádnou referenci na projekt, který obsahuje třídu, jež implementuje dříve zmíněné rozhraní, Visual Studio nás na to upozorní.

49

Rozšíření na úrovni webových výkonových testů

7.4.2

Na úrovni webového výkonového testu se rozšíření implementuje podobně, akorát se neimplementuje rozhraní, ale vytváří třída, která dědí z WebTestPlugin a potom můžeme změnit chování metod určených pro obsluhu událostí, které jsou spouštěny postupně: 

před začátkem webového výkonového testu (PreWebTest),



před začátkem transakce ve webovém výkonovém testu (PreTransaction),



před začátkem každého explicitně uvedeného požadavku (PrePage),



před navázáním kontextových parametrů k požadavku (PreRequestDataBinding),



před zasláním požadavku (PreRequest), včetně závislých požadavků (dependent requests).

Analogicky k těmto metodám s prefixem „Pre“ jsou dostupné i metody s prefixem „Post“, které jsou volány v opačném pořadí a obsluhují události po dané akci – například PostRequest je spuštěna po zpracování každého požadavku, atp.

7.4.3

Rozšíření na úrovni požadavků

Podobně jako je tomu u rozšíření na úrovni webových výkonových testů, na úrovni konkrétních požadavků je možné použít rozšíření, které dědí ze třídy WebTestRequestPlugin a můžeme tak měnit chování metod PreRequestDataBinding, PreRequest a PostRequest, které mají stejný význam jako v předchozím případě.

7.4.4

Extrakční a validační pravidla

Dále se nám nabízí možnost definovat vlastní extrakční a validační pravidla, která dědí z ExtractionRule, resp. ValidationRule a kde definujeme především chování metod Extract, resp. Validate. Pokud jsou na jednotlivé požadavky navázána validační i extrakční pravidla, je potom

pořadí spouštění metod následující: PostRequest, Extract a Validate. To platí i pro rozšíření na úrovni celých webových výkonových testů – potom jsou tato pravidla spouštěna po každém požadavku.

7.5

Zpracování výsledků

Po spuštění zátěžového testu se zobrazí okno s výsledky testování, kde se už v průběhu testu můžeme dívat na grafy přednastavených výkonových čítačů. Po doběhnutí testu budeme mít k dispozici i souhrnné výsledky – průměry, percentily, atd., jak bylo popsáno v kapitole 4.2.1. Souhrn výsledků (Summary) je přehledný a obsahuje nejdůležitější informace o provedeném testu. Velice zajímavá je možnost vytváření reportů v Excelu, která nabízí také přímé srovnání několika běhů testů – podle

50

nastavení je potom vygenerován sešit s několika listy a každý z nich se věnuje srovnání jiných oblastí, přičemž srovnávané hodnoty jsou doplněny grafy a procenty, abychom měli analýzu výsledků ještě snazší. Práce s grafy je opravdu pohodlná, můžeme použít zobrazení až čtyř různých grafů najednou, definovat vlastní grafy a do každého grafu přidávat vlastní výkonové čítače. Pokud nějaká hodnota překračuje práh definovaný pro daný výkonový čítač, je u ní v grafu zobrazená příslušná ikonka pro varování (případně chybu), což se nám zároveň zobrazuje ve stromě výkonových čítačů nalevo od grafů. U každého čítače můžeme nastavit barvu a měřítko, abychom se v grafu mohli lépe orientovat.

Obrázek 7.6: Výsledky zátěžového testu v podobě grafů

Další novinkou ve verzi 2010 je graf virtuálních uživatelů, kde je vidět, jaký uživatel prováděl který test v daném časovém rozmezí a máme možnost sledovat, jak se jednotliví uživatelé vracejí na web, případně se vytvářejí noví uživatelé (podle nastavení Percentage of New Users).

51

Výsledky testování

8

Tato kapitola je zaměřená na výsledky testování – zde si ukážeme, jak naše aplikace obstála v jednotlivých scénářích, kde nám testování pomohlo odhalit problémy a navrhneme další možná rozšíření testů. Také se podíváme na několik problémů, které mohou v souvislosti s testováním a zpracováním výsledků nastat a jak se s nimi vypořádat.

8.1

Výsledky jednotlivých scénářů

V kapitole 6 jsme se věnovali návrhu jednotlivých scénářů, zde si postupně projdeme výsledky jejich testování a vyvodíme patřičné závěry.

8.1.1

Zjištění možností testovací sestavy a webové aplikace

K původnímu scénáři pro zjištění maximálního počtu konkurenčních uživatelů, kteří mají dobu odezvy stránky (včetně závislých požadavků, které mohou být ve vyrovnávací paměti) nižší než 4 vteřiny, přidáme ještě srovnání výkonu aplikace při různém nastavení použití vyrovnávací paměti aplikace, ale tentokrát se stejnou uživatelskou zátěží. V první tabulce níže můžeme sledovat, jak se s použitím aplikační vyrovnávací paměti významně zvyšuje počet uživatelů, které aplikace zvládne obsloužit v rozumném čase. Nastavení vyrovnávací paměti (cache)

Maximální počet konkurenčních uživatelů, při němž je doba načtení stránky nižší než 4s

Vypnuto Využití paměti pro obsah (datové zdroje) Využití paměti pro výstupní HTML

250 400 2000+

Tabulka 8.1: Srovnání propustnosti aplikace při různém nastavení použití paměti

Při tomto měření se nám stalo, že navzdory použití 2000 konkurenčních uživatelů byla odezva stránek nižší než 80 milisekund a protože jsme měli agenty vytížené na maximum (resp. více než 90% CPU), zřejmě nemělo cenu v tomto konkrétním testu pokračovat dále – pro představu a srovnání to stačí. Při konstantním souběžném spojení 200 virtuálních uživatelů:

Průměrné vytížení CPU Agenta Průměrné vytížení CPU Web serveru Průměrné vytížení CPU SQL serveru Průměrná hodnota RPS Průměrná doba odezvy stránky

Ukládání vypnuto 9% 91% 47% 153 3.05s

Ukládání obsahu 12% 96% 17% 206 2.05s

Ukládání výstupu 94% 90% 0% 2811 0.03s

Tabulka 8.2: Výkonnost aplikace při různém nastavení ukládání do paměti cache

52

Ve druhé tabulce je patrné ještě více, že bychom měli používat vyrovnávací paměť všude, kde se dá, abychom zajistili vyšší výkon aplikace. V tomto testu se také prokázalo omezení testovací sestavy, protože vidíme, že webový server má ještě rezervy ve využití procesoru a doba odezvy celé stránky je pořád dostatečně nízká, nicméně agenti už jsou natolik vytíženi, že nedokáží vygenerovat více zátěže.

8.1.2

Souběžná práce více editorů

Tento scénář zátěžového testu obsahuje několik webových výkonových testů, kde každý virtuální uživatel vystupuje jako editor a provádí různé akce. Cílem bylo zjistit, kolik editorů může současně pracovat v administračním rozhraní a najít případné problémy. Jakákoli přesná čísla by ovšem byla poměrně zavádějící, protože všechno je závislé na počtu objektů v databázi, náročnosti databázových dotazů, které běží současně, atp. Na základě provedených testů sice můžeme říci, že není problém, aby najednou pracovalo v administračním rozhraní několik desítek i stovek uživatelů, ale záleží na tom, kde se právě nacházejí – problémy například vznikají, pokud více editorů pracuje v jeden čas nad stejnými dokumenty (případně ve stejném podstromu), což se může projevit neúměrným zpomalením ukládání dokumentů, načítání stromu dokumentů a občas v databázi nastane deadlock, který se objeví v podobě chyby zobrazené v uživatelském rozhraní. Samozřejmě to je extrémní případ, kdy je takových editorů několik desítek, provádějí akce rychleji než je běžné, anebo provádějí náročnější operace (přesun mnoha dokumentů, atp.). Tento scénář tak spíše posloužil pro odladění stávajících problémů, do kterých by se zákazníci mohli dostat, než aby poskytl pěkná čísla a grafy.

8.1.3

Sledování aktivit uživatelů

Po zapnutí on-line marketingu, sledování návštěvnosti webu, aktivit uživatelů a vytváření nových kontaktů jsme se dostali do problémů, které stále řešíme a výsledky tak ještě nejsou v současné době dostupné. Na vině byly i testy, které moc neodpovídaly reálným situacím a vytvářely příliš mnoho (miliony) nových anonymních uživatelů, se kterými si potom systém nedokázal poradit. Muselo tedy následovat přepracování testů i systému, které ještě není úplně dokončené.

8.1.4

Chat modul

Pro testování tohoto modulu bylo vytvořeno několik webových výkonových testů – například pro vytváření nových místností a uživatelů, vstupování do náhodné místnosti a její opouštění, komunikace s ostatními (používání náhodných hlášek), atp. Testy ukázaly, že je opravdu možné, aby najednou existovalo 100 místností a v každé z nich desítky uživatelů, kteří současně vedou diskuzi, aniž by načítání trvalo více než několik vteřin a server byl jinak nepoužitelný, což je úspěch, se kterým se snad ani nepočítalo.

53

8.2

Další možná rozšíření testů

Testy se určitě budou dále rozšiřovat a bude jich postupem času přibývat – teoreticky by na každý modul mohl být napsaný výkonnostní test k ověření škálovatelnosti aplikace, aby doplnil její klasické testování, které momentálně probíhá tak, že se skriptem naplní databáze a potom se v uživatelském rozhraní ověří funkcionalita daného modulu a odezva jeho rozhraní „od oka“ (případně se řeší, jak dlouho trval ten který dotaz, zjišťuje se jeho Execution plan a ladí databázové indexy).

8.3

Problémy při testování a zpracování výsledků

Výčet problémů uvedený v této kapitole rozhodně není úplný, ale minimálně do začátku nám pomůže si uvědomit, na co si dát pozor a co je potřeba řešit. Něčemu se dá vyhnout rovnou, něčemu se ale nedá vyhnout nikdy a budeme na ten samý problém narážet pořád dokola.

8.3.1

Nastavení testovacího prostředí

Mezi takové všeobecné problémy spojené s nastavením testovacího prostředí patří: 

nedostatečná uživatelská oprávnění pro instalaci softwaru, spouštění služeb a úprav registrů,



zastavené služby, které musí běžet pro generování zátěže, čtení výkonových čítačů, atp.,



starší operační systém nebo ovladače (problémy zejména se síťovými kartami),



nedostatek volného místa na disku a v paměti.

Může se zdát, že je to všechno jasné, ale kolikrát se prostě stane, že člověk zapomene spustit nějakou službu po restartu systému, nenastaví patřičná oprávnění nebo nepřidá výjimku do firewallu a pak se diví, že něco nefunguje.

8.3.2

Zahlcení sítě

Zde je potřeba si uvědomit, že i když výkonnostní testování probíhá v laboratorních podmínkách, jsme přeci jenom omezeni propustností sítě. Právě proto, abychom mohli dosáhnout co nejvyšších výsledků, máme webový server a jednotlivé klienty zapojené pomocí dedikovaných linek s rychlostí 1Gb/s, což znamená maximální (teoretickou) propustnost 125MB/s. Pokud by byl test složený z jediné stránky, která má velikost 25kB, můžeme z daného klienta dosáhnout maximálně 5000RPS a i tento strop je čistě teoretický, protože nepočítáme s ostatním síťovým provozem (DNS požadavky, zabalení dat do síťových hlaviček, atp.) a frontou požadavků. Kentico CMS umožňuje kompresi výstupu do gzip/deflate, což nám v těchto extrémních scénářích rozhodně pomůže, ale pořád je nutné mít na paměti, že pokud máme síť vytíženou nad 80%, těžko můžeme očekávat vyšší RPS.

54

8.3.3

Nedostatečný výkon agentů pro generování zátěže

Podobně jsme na tom u agentů na klientských počítačích – jestliže se vytížení procesoru pohybuje nad 80%, měli bychom uvažovat o použití více agentů, protože tento už více zátěže pravděpodobně vygenerovat nedokáže. V kombinaci s předchozím problémem vytížení sítě se dostáváme do nezáviděníhodné situace – pokud máme vytížené agenty i síť nad přijatelnou hodnotu, museli bychom přidávat další hardware (síťové karty na webový server a počítače pro klienty/agenty), což může být další problém.

8.3.4

Nedostatek volného místa v databázi s výsledky

Zvláště při původním nastavení (sbírání hodnot většiny systémových výkonových čítačů) a použití databázového serveru v edici SQL Express (dostupné zdarma) se může stát, že už nebudeme moci uložit výsledky testu kvůli nedostatku místa. Edice SQL Express měla původní limit pro velikost databáze 4GB, v nejnovější verzi SQL Server Express je to již 10GB, ale stejně bychom měli staré a nepotřebné výsledky testů mazat, abychom se do takových problémů nedostali, případně použít plnohodnotnou verzi SQL Serveru.

8.3.5

Přehnané požadavky, scénáře a interpretace výsledků

Při počátečním testování jsme zkoušeli různé možnosti nastavení testovacího prostředí i nástroje, a tak jsme například použili možnost Percentage of New Users = 100, což znamená, že každý virtuální uživatel představuje unikátního návštěvníka webu, kterému se musí načíst veškeré závislé požadavky bez použití klientské vyrovnávací paměti (představující vyrovnávací paměť prohlížeče). Na tom by samo o sobě nebylo nic špatného, pokud by test obsahoval nějaký složitější scénář, než jednoduché načtení statické stránky, jejíž HTML výstup je uložený v paměti a nepustili bychom tam 100 simultánně připojených virtuálních uživatelů. Takhle se totiž podařilo, že aplikace zpracovávala cca 4000 požadavků za sekundu, stránka byla načtená v řádech desetin sekundy a my jsme tak během 10 minut vytvořili více než 220 000 unikátních návštěv, což by za 1 den bylo více než 30 milionů unikátních návštěvníků a tolik unikátních návštěvníků denně má v dnešní době například YouTube. Takže kromě takových scénářů si musíme dávat pozor i na interpretaci jejich výsledků.

8.4

Co se odladilo v průběhu testování

Během výkonnostního testování jsme narazili na několik problémových oblastí aplikace, které jsme museli upravit do hotfixu, anebo do nové verze Kentico CMS (EMS) 7, která bude vydána na konci června 2012. Někde například chyběly důležité indexy v databázi, a tak se nám při vysokém počtu záznamů stávalo, že vyhledávání/řazení trvalo nepřiměřeně dlouho, což bylo nepříjemné zejména v oblasti on-line marketingu (mazání neaktivních kontaktů a jejich aktivit). Dále se podařilo odhalit 55

problémy se zpracováním dat více vlákny najednou, kdy si každé vlákno muselo posílat vlastní dotaz do databáze, a tak jsme do nové verze zavedli tzv. Progressive caching, který umožňuje ostatním vláknům použít výsledek dotazu toho prvního vlákna, což u dlouhých dotazů nebo velkém objemu dat přináší viditelné zrychlení. Díky těmto testům jsme také přidali možnost nastavení vyrovnávací paměti na klientovi a veškeré možnosti nastavení cache přesunuli do uživatelského rozhraní, aby to bylo pro uživatele pohodlnější. Vedlejším účinkem zátěžového testování bylo automatizování některých činností jako je například vytváření testovacích dat nebo nejrůznější nastavení aplikace pro manuální funkční testování.

56

9

Závěr

V semestrální části diplomového projektu se nám podařilo seznámit s problematikou testování, i když se tyto úvodní kapitoly do konečné diplomové práce ještě rozšiřovaly, stejně jako se upravovaly i testovací scénáře. Z dostupných webových aplikací byl vybrán redakční systém Kentico CMS 6 a po srovnání existujích nástrojů pro výkonnostní testování bylo zvoleno Microsoft Visual Studio 2010. Bylo vytvořeno více než 20 webových výkonových testů včetně drobných rozšíření, které se potom používaly v zátěžových testech a jejich výsledky slouží nejen této diplomové práci, ale hlavně firmě Kentico software pro zlepšování redakčního systému Kentico CMS. Během testování také vznikl Performance Report pro zákazníky Kentico software, který je dostupný na http://www.kentico.com/ Product/Resources/Brochures/Kentico-CMS-Performance-Report/KenticoCMS-6-0-Performance, nicméně tento dokument vznikal nezávisle na této diplomové práci a ve spolupráci s dalšími kolegy. Tato práce neobsahuje vysoké množství hodnot v tabulkách a krásné grafy pro zákazníky a management (jako je tomu v případě výše zmíněného Performance Reportu), ale snaží se uplatnit autorovy znalosti a zkušenosti v oboru testování webových aplikací získaných téměř pětiletou praxí v Kentico software, školeními od Microsoftu a LBMS. Může se tak hodit začínajícím testerům (především se zájmem o výkonnostní testování, případně použití nástroje MS Visual Studio) a lidem z oblasti zajišťování kvality (QA). Upozorňuje na problémy, které vznikají obecně v oblasti testování a konkrétně při používání nástroje Microsoft Visual Studio 2010 pro zátěžové testování. Na první pohled se může zdát, že výsledků testování je oproti počátečním očekáváním málo a nejsou v dostatečně reprezentativní podobě, ale je nutno říci, že se díky těmto testům odladilo několik poměrně závažných chyb, které by se jinak nepodařilo najít a zákazníkům tak půjde zase o něco lepší produkt, což je samo o sobě také výsledkem. Na tyto testy se samozřejmě bude do budoucna dále navazovat a díky získaným zkušenostem budou přínosem pro firmu Kentico software i její produkt.

57

10

Citovaná literatura

[1] Patton, Ron. Testování softwaru. Vyd. 1. Praha: Computer Press, 2002. ISBN 80-722-6636-5. [2] ISO 9126 Software Quality Characteristics [online]. http://www.sqa.net/iso9126.html, 2010 [cit. 2012-01-08]. [3] SQA Definition – FURPS [online]. http://www.sqa.net/index.htm#furps, 2010 [cit. 2012-01-08]. [4] Eeles, Peter. Capturing Architectural Requirements [online]. http://www.ibm.com/developerworks/rational/library/4706.html#N100A7, 2005 [cit. 2012-01-08]. [5] Neuwirth, Michal. High Availability and Scalability – Introduction [online]. http://devnet.kentico.com/Blogs/Michal-Neuwirth/March-2010/High-Availability---Scalability--Introduction.aspx, 2010 [cit. 2011-12-10]. [6] Gheorgiu, Grig. Performance vs. load vs. stress testing [online]. http://agiletesting.blogspot.com/2005/02/performance-vs-load-vs-stress-testing.html, 2005 [cit. 2012-01-10]. [7] MSDN. Testing .NET Application Performance [online]. http://msdn.microsoft.com/en-us/library/ff647788.aspx#scalenetchapt16_topic4, 2004 [cit. 2011-10-08]. [8] MSDN. Performance Testing Guidance for Web Applications [online]. http://msdn.microsoft.com/en-us/library/bb924375.aspx, 2007 [cit. 2011-11-28]. [9] The CMS matrix [online]. http://www.cmsmatrix.org/, 2011[cit. 2011-09-29]. [10] Stats – WordPress.com [online]. http://en.wordpress.com/stats/, 2012 [cit. 2012-01-10]. [11] System requirements – Kentico CMS for ASP.NET [online]. http://www.kentico.com/Support/Support-files/System-requirements, 2011 [cit. 2011-12-01]. [12] Deloitte Technology Fast 50 in Central Europe [online]. http://www.deloitte.com/fast50ce, 2011 [cit. 2011-12-03]. [13] Microsoft. Overview of Visual Studio 2010 Ultimate [online]. http://www.microsoft.com/visualstudio/en-us/products/2010-editions/ultimate/overview, 2011 [cit. 2011-11-20]. [14] MSDN. Creating and Using Custom Plug-ins for Load and Web Performance Tests [online]. http://msdn.microsoft.com/en-us/library/ee923683.aspx, 2011[cit. 2011-12-14]. [15] Microsoft. WCAT 6.3.1 User’s Guide. 2007.

58

[16] Gousset, Mickey. Řízení životního cyklu aplikací ve Visual Studiu 2010. 1. vydání. Brno: Zoner Press, 2010. ISBN 978-80-7413-102-8. [17] Geoff Grey. Visual Studio Performance Testing Quick Reference Guide [online]. http://vsptqrg.codeplex.com/, 2011 [cit. 2012-02-22].

59