Automatické testování webového informačního systému

Masarykova Univerzita Fakulta informatiky Automatické testování webového informačního systému Diplomová práce Bc. Tomáš Krištof Brno, Jaro 2016

Místo tohoto listu vložte kopie oficiálního podepsaného zadání práce a prohlášení autora školního díla.

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Bc. Tomáš Krištof Vedoucí práce: RNDr. David Sehnal, Ph.D. i

Poděkování Děkuji RNDr. Davidu Sehnalovi, Ph.D. za cenné rady a věcné připomínky při odborném vedení této práce. Děkuji také Ing. Romanu Ježdíkovi, který mi umožnil tuto práci vytvořit. iii

Shrnutí Tato práce řeší problematiku automatického testování webových aplikací vyvíjených na platformě ASP.NET MVC. Vysvětluje základní pojmy v oblasti testování a představuje dostupné nástroje sloužící k testování či jeho automatizaci. Na základě zjištěných poznatků popisuje testovací strategii a postup při implementaci sady automatických testů ve společnosti ALVAO s.r.o. Výsledkem práce je zavedení automatického testování do vývojového procesu této firmy. iv

Klíčová slova Chyba, test, automatické testování, průběžná integrace, ASP.NET MVC, webová aplikace v

Obsah 1 Úvod................................ 1 2 Testování softwaru........................ 3 2.1 Definice............................ 3 2.2 Účel testování softwaru.................... 4 2.2.1 Kvalita softwaru.................. 4 2.2.2 Vhodná míra testování............... 5 2.3 Techniky testování....................... 7 2.3.1 Černá skříňka.................... 7 2.3.2 Bílá skříňka..................... 7 2.3.3 Šedá skříňka..................... 7 2.4 Úrovně testů......................... 8 2.4.1 Jednotkové testy.................. 8 2.4.2 Integrační testy................... 9 2.4.3 Testy systému.................... 9 2.4.4 Akceptační testy.................. 12 3 Automatické testování...................... 13 3.1 Automatizace aplikací..................... 14 3.2 Nástroje pro automatizaci webových aplikací......... 15 3.2.1 Selenium....................... 15 3.2.2 Watir......................... 17 3.2.3 WatiN........................ 17 3.2.4 Windmill....................... 18 3.2.5 Ranorex....................... 18 3.2.6 SoapUI........................ 19 3.2.7 Sahi.......................... 19 3.2.8 Tellurium...................... 19 3.3 Průběžná integrace...................... 20 3.4 Nástroje pro průběžnou integraci............... 20 3.4.1 TeamCity...................... 21 3.4.2 Jenkins........................ 22 3.4.3 Travis CI....................... 22 3.4.4 Bamboo....................... 23 3.4.5 Team Foundation Server.............. 23 4 Testování aplikací vyvíjených na platformě ASP.NET MVC 25 4.1 Architektura MVC...................... 25 vii

4.2 Testování vrstvy Model.................... 26 4.3 Testování vrstvy Controller.................. 28 4.4 Testování vrstvy View..................... 32 4.5 Potlačení závislostí při testování............... 33 4.6 Testovací frameworky pro ASP.NET MVC.......... 35 4.6.1 MSTest........................ 36 4.6.2 xunit.net....................... 37 4.6.3 NUnit........................ 39 4.6.4 SpecFlow...................... 41 4.6.5 QUnit......................... 43 4.6.6 Jasmine........................ 44 5 Informační systém ALVAO WebApp............. 47 5.1 Technické specifikace informačního systému......... 48 5.2 Architektura systému z hlediska vývoje............ 49 5.3 Návrh testů.......................... 49 5.3.1 Volba nástrojů.................... 50 5.3.2 Testovací strategie................. 50 5.3.3 Konvence při psaní testů.............. 51 5.3.4 Pomocné třídy.................... 51 5.3.5 Jednotkové testy.................. 52 5.3.6 Integrační testy................... 53 5.3.7 Akceptační testy.................. 53 5.4 Proces sestavování a testování aplikace............ 54 5.4.1 Vyhodnocení procesu testování.......... 55 6 Závěr................................ 57 Bibliografie............................... 59 A Seznam příloh........................... 63 viii

Seznam obrázků 2.1 Následky chyb, zdroj: [4] 4 2.2 Projektový trojimperativ, zdroj: [5] 5 2.3 Optimální množství testování, zdroj: [6] 6 2.4 V-model 9 3.1 Průběžná integrace, zdroj: [16] 21 4.1 Architektonický vzor MVC 26 5.1 Architektura systému ALVAO Service Desk, zdroj: [33] 48 5.2 TeamCity, úvodní stránka 55 5.3 TeamCity, průběžný vývoj testů 55 ix

1 Úvod Testování hraje důležitou roli v životním cyklu vývoje softwaru. S rostoucím množstvím zdrojového kódu aplikace přirozeně roste i pravděpodobnost výskytu chyb. Se vzrůstající složitostí aplikace se zvyšují nároky na její testování. V dřívějších dobách bylo testování považováno za podřadnou disciplínu. Dnes, kdy je stále větší poptávka po kvalitním a spolehlivém softwaru, to již neplatí. Kvalitu softwaru nezřídka kdy zajišťují specializované a početné týmy, jejichž členové mohou být minimálně stejně hodnotní, jako členové vývojového týmu. Na testování je kladen větší důraz. Nejen tyto faktory způsobují, že testování je rozvíjeno jako samostatný proces ve vývoji softwaru. Tato práce si klade za cíl ustanovit základní pojmy v oblasti testování a analyzovat jeho cíle a postupy. Čtenář se seznámí se stanovením vhodné míry testování, jednotlivými technikami testování a rozdělením testů na dílčí úrovně. Dále bude seznámen s problematikou automatického testování a přínosem průběžné integrace. Spolu s vysvětlením těchto pojmů budou také diskutovány a porovnány vhodné nástroje, které danou problematiku řeší. Následně se práce hlouběji zaměří na automatické testování webových aplikací implementovaných na platformě ASP.NET MVC. Čtenáři budou popsány jednotlivé vrstvy aplikace vyvíjené na této platformě a navrženy způsoby, jak je tyto vrstvy možné testovat. Poté bude obeznámen s nástroji, které je možné při testování webových aplikací vyvíjených na platformě ASP.NET MVC použít. V praktické části práce bude čtenář seznámen s návrhem testovací strategie a implementací sady automatických testů pro informační systém WebApp společnosti ALVAO s.r.o. 1

2 Testování softwaru Testování je nedílnou součástí vývojového cyklu softwaru a je to jeden ze způsobů, jak ověřit kvalitu softwaru. Pojem testování můžeme obecně vysvětlit jako získávání informací o stavu a vlastnostech systému a jejich následném zpracování. V následujícím textu budou hlouběji vysvětleny základní pilíře testování. 2.1 Definice Pro účely této práce budou zavedeny následující termíny a definice. Testování je proces analýzy softwaru za účelem nalezení rozdílů mezi stávajícím a požadovaným chováním a vyhodnocením jeho vlastností [1, s. 76]. Spolehlivost je pravděpodobnost, že systémové služby budou poskytovány tak, jak byly definovány v systémové specifikaci [2, s. 272]. S testováním se pojí i pojmy jako verifikace a validace. Tyto pojmy jsou navzájem často zaměňovány, mají však rozdílný význam. Verifikace je proces hodnocení systému či komponenty s cílem určit, zda-li produkty v dané vývojové fázi splňují podmínky, které byly dány na začátku této fáze [3, s. 9]. Program je verifikován vzhledem k nejbližším určujícím dokumentům nebo specifikacím. Validace je proces hodnocení systému či komponenty během nebo na konci vývojového procesu s cílem určit, zda byly dodrženy specifikované požadavky [3, s. 9]. Program je validován vůči požadavkům uživatele nebo systému. 3

2. Testování softwaru 2.2 Účel testování softwaru Software vyvíjejí lidé, je tedy potřeba počítat s tím, že může obsahovat chyby. Je velice obtížné zajistit, aby byl výsledný produkt bez závad. Chyby mohou vznikat různými způsoby a lze je rozdělit na chyby způsobené lidským faktorem a chyby způsobené prostředím. Chyby způsobené lidským faktorem jsou ovlivněny například komunikační propastí mezi vývojáři a zadavateli projektu, těsnými časovými termíny, nedostatkem zkušeností vývojáře a měnícími se technologiemi. Za chyby způsobené prostředím můžeme považovat chyby způsobené výskytem radiace, magnetismu,... Výskyt chyby způsobí defekt, který může vést k selhání systému. Tuto závislost ilustruje obrázek 2.1. Selhání systému může vést ke ztrátě peněz, času a reputace, v krajních případech i ke zranění či smrti. Je zřejmé, že pokud se chceme vyvarovat selhání systému, musíme se také vyvarovat výskytu chyb, případně chyby včas odhalit a odstranit. Prostředkem, jak toho docílit, je testování softwaru. Obrázek 2.1: Následky chyb, zdroj: [4] 2.2.1 Kvalita softwaru Při procesu vývoje softwaru je nutné stanovit požadavky, co od projektu očekáváme, a zdroje, které do něj chceme investovat. Základními zdroji jsou cena, čas a kvalita, přičemž všechny se navzájem ovlivňují a ovlivňují také funkcionalitu, která je či není ve výsledném softwaru zahrnuta. Pokud například chceme systém s pevně daným rozsahem funkcionality doručit dříve, bude pravděpodobně stát více peněz nebo bude obsahovat více chyb a defektů. Tento projektový trojimperativ je zobrazen na obrázku 2.2. 4

2. Testování softwaru Obrázek 2.2: Projektový trojimperativ, zdroj: [5] Jedna z úloh testování je zajistit, že všechny klíčové požadavky kladené na výsledný systém jsou ověřovány ještě před tím, než je systém uveden do provozu a všechny defekty jsou hlášeny vývojovému týmu pro zajištění opravy [4]. Samotné testování přímo neodstraní defekty, dokonce ani nezvýší kvalitu systému. Odstranění defektů je možné pouze po jejich detekci (nahlášení), což až následně vede ke zvýšení kvality softwaru. Testování je jednou z komponent v procesu zajišťování kvality, která se snaží zajistit, aby systém vstoupil do provozu bez závad, které mohou vést k vážným selháním. 2.2.2 Vhodná míra testování Proces testování může ukázat, že v systému existuje jeden nebo více defektů. Nemůže ale ukázat, že se v systému naopak žádný defekt nenachází k tomu by bylo potřeba otestovat všechny přípustné i nepřípustné vstupy a podmínky, které se mohou vyskytnout. Jelikož jich je ve většině případů nekonečně mnoho, cena za vytvoření a provedení takových testů by byla obrovská ať již časová či finanční. Naopak s nízkým počtem testů se pojí riziko vysokého množství defektů, které mohou vést k selhání systému. Je tedy nutné zvolit vhodný poměr mezi množstvím testů, které se budou provádět. Vztah tohoto úsilí je znázorněn na obrázku 2.3. 5

2. Testování softwaru Obrázek 2.3: Optimální množství testování, zdroj: [6] Nejdůležitějším aspektem k dosažení přípustného výsledku z konečného a omezeného množství testů je prioritizace [4]. Nejdůležitější testy jsou vytvářeny přednostně tak, abychom si vždy byli jistí, že testy, které již vytvořeny byly, jsou důležitější než testy, které stále ještě zbývá vytvořit. Nejdůležitější testy jsou takové, které ověřují nejdůležitější funkce systému definované buď uživatelem, nebo vlastníkem. Dalším důležitým faktorem je stanovení kritérií pro ukončení testování. Tato kritéria poté poskytují objektivní informaci o tom, zda-li je bezpečné testování ukončit [7]. Stanovení takových kritérií je vždy závislé na konkrétním projektu a odvíjí se od strategie testování. Příklad: Testování je možné ukončit, pokud jsou testy pokryty všechny hlavní scénáře, není-li znám žádný kritický defekt a je dosaženo definovaného pokrytí kódu testy. 6

2.3 Techniky testování 2. Testování softwaru Jednotlivé techniky používané k hledání chyb je možné rozdělit do několika kategorií. Každá technika pohlíží na objekt testování jiným způsobem a liší se i předpokládanou znalostí vnitřní struktury objektu, případně znalostí testovaného kódu. 2.3.1 Černá skříňka Testování metodou černé skříňky spočívá v absenci znalosti vnitřního fungování testovaného objektu. Zkoumá pouze základní aspekty systému bez znalosti jeho vnitřní logické struktury [8]. Hlavním cílem je ověřit funkcionalitu systému. Tato technika slouží především k ověřování požadavků kladených na výsledný software. Příklad: Tester, bez znalosti vnitřní struktury webové aplikace, testuje webovou stránku s použitím prohlížeče: poskytuje uživatelský vstup (stisk kláves) a ověřuje výstup oproti předpokládanému výsledku. 2.3.2 Bílá skříňka Někdy je možné se též setkat s pojmem skleněná skříňka. Vnitřní logická struktura objektu je dobře známá, předmětem testování jsou konkrétní algoritmy a interní mechanismy. Nutným předpokladem pro použití této techniky při testování je detailní znalost zdrojového kódu. Příklad: Tester studuje implementaci konkrétního prvku na webové stránce, stanoví všechny povolené i nepovolené vstupy a ověří výstup oproti předpokládaným hodnotám, které jsou také určeny analýzou zdrojového kódu. 2.3.3 Šedá skříňka Testování metodou šedé skříňky je na pomezí mezi technikami bílé a černé skříňky. Jedná se o techniku testování základních aspektů systému s omezenou znalostí interní logické struktury objektu [8]. Příklad: Tester studuje konkrétní prvek na webové stránce. Se znalostí jeho implementace vytvoří testovací scénáře (metoda bílé skříňky), 7

2. Testování softwaru které následně testuje skrze dostupné uživatelské rozhraní poskytováním uživatelského vstupu (metoda černé skříňky). 2.4 Úrovně testů Testování aplikace probíhá, stejně jako její vývoj, v několika úrovních. Každé fázi vývoje odpovídá konkrétní fáze testování. Jednotlivé testy jsou navrženy tak, aby odhalily problémy specifické pro danou fázi vývoje. Na obrázku 2.4 jsou zobrazeny testovací fáze V-modelu. Tyto fáze bývají též nazývány úrovněmi [7]. Jednotlivé úrovně testů mohou být aplikovány i na iterativní proces vývoje softwaru a mohou se lišit v závislosti na systému. Pokud například vyvíjený systém obsahuje software třetích stran, může proběhnout jeho akceptační testování ještě před testováním celého systému. Testování můžeme rozdělit do čtyř hlavních fází: jednotkové testy ověřují správnou funkčnost co nejmenších izolovaných částí zdrojového kódu [9] integrační testy testují vzájemnou komunikaci mezi komponentami a jejich společnou integraci systémové testy zkoumají funkcionalitu systému jako celku akceptační testy provádí zákazník před převzetím systému 2.4.1 Jednotkové testy Před samotným testováním je nutné, aby byl napsán zdrojový kód, což je patrné ze spodní částí V-modelu na obrázku 2.4. Zdrojový kód bývá organizován do jednotlivých komponent neboli jednotek. Tyto jednotky jsou navzájem izolované a určené k budoucí integraci na vyšších úrovních. Jednotkové testy se zaměřují na individuální, izolované části zdrojového kódu a mají za úkol ověřit, že zdrojový kód dané jednotky splňuje své specifikace [10]. V procedurálních programovacích jazycích, jako je například C, jsou za jednotky považovány jednotlivé funkce. V objektově orientovaných jazycích jako C#, jsou za jednotky považovány jednotlivé třídy. 8

2. Testování softwaru Obrázek 2.4: V-model Jednotkové testy jsou podrobné a velmi rychlé, plně automatizovatelné (nevyžadují ruční vstup) a jejich tvorba je nenáročná a levná. 2.4.2 Integrační testy Jakmile jsou jednotlivé komponenty vytvořeny, je dalším krokem jejich vzájemná integrace. Smyslem integračních testů je odhalit defekty ve vzájemné komunikaci mezi komponentami [4]. Tato strategie ulehčuje izolování chyb. Pokud je chyba nalezena při testování samostatné jednotky, je jasné, že chyba musí být v této jednotce. Pokud je chyba nalezena po integraci více komponent, tak je s největší pravděpodobností spojená se vzájemnou interakcí komponent [6]. Vzhledem k prodlevě při komunikaci jsou integrační testy pomalejší než testy jednotkové. Jelikož nevyžadují ruční vstup, tak jsou plně automatizovatelné. Údržba integračních testů však může být náročná, pokud se jednotlivé integrační komponenty často mění. 2.4.3 Testy systému Po vzájemné integraci všech komponent je na řadě testování systému jako celku. V této fázi testování je potřeba ověřit, zda implementace 9

2. Testování softwaru systému odpovídá specifikovaným požadavkům zákazníka. Mnoho testů také ověřuje nespecifikované předpoklady. Základní testy Základní testy podávají první důkaz o tom, že je systém funkční a mohou se provést další, pečlivější testy. Tyto testy ověřují pouze ty nejzákladnější specifikace systému. Cílem je zjistit, zda je systém schopný provozu a zda jeho běžné funkce pracují dle předpokladů. Testy funkcionality Testy funkcionality provádí podrobnou verifikaci napříč všemi specifikovanými požadavky. Jedná se o testy komunikace, modulů, testy uživatelského rozhraní, bezpečnostní testy,... Testy robustnosti Robustnost udává, jak odolný je systém vůči chybnému vstupu a změnám v provozním prostředí. Testy z této kategorie ověřují chování systému v chybových situacích. Testy interoperability Testy interoperability ověřují schopnost systému komunikovat s produkty třetích stran. Testy jsou navrženy tak, aby se ověřilo, že systém může být propojen s jiným softwarem a spolupracovat s ním. Testy výkonu Testy výkonu jsou vytvářeny za účelem porovnat předpokládaný a skutečný výkon systému. Metriky výkonnosti je nutné u každého systému měřit rozdílně. Pro on-line informační systém to může být například požadavek, aby doba odezvy jednotlivých požadavků byla v 90% případů menší než 1 sekunda. 10

2. Testování softwaru Testy škálovatelnosti Testy škálovatelnosti zkoumají schopnost systému růst spolu se zvyšujícím se počtem uživatelů nebo velikostí databáze. Jejich cílem je zjistit, zda doba odezvy systému roste lineárně spolu se zvyšujícím se počtem prováděných operací. Systém může být škálovatelný pouze do určité míry technické hranice tvoří například propustnost datové sítě, kapacita datového úložiště a výkon procesoru. Stresové testy Cílem stresových testů je ověřit chování systému v situacích, kdy je pod větší zátěží, než pro jakou byl konstruován. Splnění těchto testů zajistí, že systém bude přijatelně pracovat i v těch nejhorších podmínkách, které mohou nastat. Je také zkoumáno, zda dochází k automatickému spuštění procesu obnovy systému, pokud dojde k selhání systému. Testy zátěže Testy zátěže jsou koncipovány tak, aby ověřily, že systém zůstane stabilní i poté, co je po dlouhou dobu vystaven plné, ovšem očekávané zátěži. Pomáhají určit provozní kapacitu systému, stejně jako jeho úzká hrdla. Testy spolehlivosti Testy spolehlivosti ověřují schopnost softwaru zůstat funkční po dlouhou dobu. Spolehlivost systému bývá často vyjádřena hodnotou střední doby mezi poruchami (mean time to failure, MTTF). Regresní testy V této kategorii nejsou vytvářeny nové testy, místo toho jsou spouštěny ty již vytvořené, aby se ověřilo, že nová verze softwaru nezpůsobila defekty v dříve funkčních částech a funguje tedy správně. Během testování jsou zaznamenávány chyby, jejichž oprava může způsobit nepozorovanou chybu v jiné části systému. Účel regresních testů je tyto chyby odhalit. 11

2. Testování softwaru Testy dokumentace Testovat dokumentaci znamená verifikovat technickou přesnost a čtivost uživatelské příručky a návodu. Ověřuje se například správná gramatika v dokumentaci, jednotná terminologie a konzistence slovníčku pojmů. 2.4.4 Akceptační testy Poslední fáze testování nese název akceptační testování. Předchozí fáze testování měly za úkol nalézt v softwaru chyby. Cílem akceptačního testování je demonstrovat, že produkt splňuje požadavky, které jsou na něj kladeny. Akceptační testování provádí často samotný zákazník a jeho úspěšným dokončením se zavazuje systém přijmout. Není-li software vyvíjen komerčně, dochází po úspěšném akceptačním testování k nasazení do produkčního prostředí [7]. Akceptační testy jsou někdy též nazývány alfa a beta testy. Alfa testování je interní testování systému v místě jeho vývoje. Může jej provádět buď samotný zákazník, nebo vývojový tým. Po jeho dokončení přichází na řadu beta testování, které je již externí. Systém je poskytnut vybraným koncovým uživatelům, kteří ověřují funkcionalitu produktu. 12

3 Automatické testování Testovací strategii můžeme rozdělit na manuální a automatickou. Manuální, tradiční přístup k testování, zahrnuje testera, který ručně připravuje série testů, o nichž si myslí, že nejlépe prověří danou funkcionalitu programu. Tester krok po kroku ověřuje, zda výsledky jednotlivých akcí splňují či nesplňují předpoklady. Manuální testování hraje důležitou roli v projektech, kde se velice často mění funkcionalita [11]. Práce manuálního testera obvykle obsahuje tyto kroky: porozumění testované funkcionalitě příprava testovacího prostředí manuální provedení testovacích scénářů ověření dosažených výsledků Automatizace těchto kroků snižuje náklady vynaložené na testování. Úspora času je mantrou informačního věku počítač může provádět sérii testovacích kroků mnohem rychleji a může je provádět nepřetržitě po celý den, i mimo pracovní dobu. Časově náročné testy mohou být vykonávány přes noc tak, aby byl ráno k dispozici jejich výsledek. Aplikace se průběžně vyvíjí a množství její funkcionality se zvyšuje. S tím však roste i počet testů, které je potřeba vykonat k ověření správné funkčnosti. Změna i jen pár procent zdrojového kódu vyžaduje, aby 100% funkcionality bylo znovu otestováno. Přínosem automatizace testování je i kumulace jednotlivých testů během vývoje softwaru, takže je vždy testována nová i stávající funkcionalita softwaru. Náklady je potřeba vynaložit pouze na vytvoření testu. Jejich znovupoužití je ale následně velmi levné a snadné. Jelikož 100% automatizace není v reálném světě dosažitelná, je manuální testování stále nezbytným prvkem testovacího procesu. Automatizace testování se z počátku pojí s nutností vynaložit větší náklady na testování, avšak benefity, které přináší, se vyplatí. Automatizované testy mohou být prováděny rychleji a s vyšší frekvencí oproti manuálním testům, mohou být spouštěny opakovaně a nepřetržitě 13

3. Automatické testování to vše vede k úspoře nákladů vynaložených na proces testování softwaru. Testování je možné automatizovat dvěma způsoby. Přímočarý přístup vede k automatizaci celého systému, který následně provádí sérii předem definovaných kroků prostřednictvím běžného uživatelského rozhraní. Tímto způsobem je možné automaticky spouštět systémové testy funkcionality. Sofistikovanějším způsobem je zavedení systému průběžné integrace do procesu vývoje. Systém průběžné integrace umožní provádět automatickou kompilaci, sestavení a otestování aplikace například při každé změně ve zdrojovém kódu. Je tak možné automatizovat i testy nižších úrovní, konkrétně jednotkové a integrační testy. 3.1 Automatizace aplikací Pro automatizaci aplikací je nutné určitým způsobem specifikovat sérii kroků, které bude nástroj pro testování provádět, čímž se eliminuje nutnost lidské interakce. Toho je možné docílit několika způsoby: Záznamem uživatelských akcí Implementace testů je prováděna prostřednictvím testovacího nástroje, který umožňuje zaznamenávat a následně přehrávat manuální činnost testera. K vytváření těchto testů nejsou potřeba znalosti programování, jejich údržba je ale velice náročná pokud se změní uživatelské rozhraní testované aplikace, je často nutné opětovné vytvoření a zaznamenání nových testů. 14 Testovacími skripty Implementaci skriptů vykonává programátor, přičemž využívá API specializovaného testovacího nástroje. Pro vytváření skriptů je nutná znalost určitého programovacího jazyka (většinou stejného jazyka, v jakém je implementována i samotná testovaná aplikace). Výhodou těchto systémových testů je jejich vysoká míra znovupoužitelnosti a snadná údržba při změně v testované aplikaci je možné upravit pouze konkrétní část skriptu, která je změnou postižena.

3. Automatické testování 3.2 Nástroje pro automatizaci webových aplikací Existuje mnoho nástrojů, které pomáhají automatizovat testování webových aplikací prostřednictvím uživatelského rozhraní. Při jejich výběru je nutné brát v potaz mnoho faktorů, jako jsou například podporované programovací jazyky a licenční podmínky, potažmo cena. Vytváření automatických testů pro webové aplikace může být náročné, jelikož uživatelské rozhraní se může měnit v závislosti na druhu a verzi webového prohlížeče, ve kterém je aplikace spouštěna. Moderní nástroje umožňují vytvářet testy s dostatečnou mírou abstrakce, čímž tento problém eliminují. 3.2.1 Selenium Selenium 1 je bezplatná multiplatformní sada nástrojů určená speciálně k automatizaci webového prohlížeče. Jeho součástí je i nástroj pro zaznamenání sekvence akcí provedených v internetovém prohlížeči, což umožňuje vytvářet testy bez nutné znalosti skriptovacího či programovacího jazyka. Podporované programovací jazyky jsou C#, Java, Python, Ruby, PHP, Haskel, Objective-C a Javascript. Mezi podporované prohlížeče patří všechny běžné internetové prohlížeče jako Internet Explorer, Google Chrome, Mozilla Firefox a Opera, navíc jsou podporovány i některé méně známé verze a prohlížeče pro mobilní telefony. Selenium se skládá z několika komponent Selenium IDE, Selenium API, Selenium Remote Control, Selenium WebDriver a Selenium Grid. Selenium IDE Selenium IDE 2 je integrované vývojové prostředí pro Selenium skripty. Je implementováno jako rozšíření pro internetový prohlížeč Mozilla Firefox a umožňuje nahrávání, editaci a spouštění testů. Selenium IDE umožňuje jednoduše a rychle zaznamenávat testy ve skutečném prostředí, ve kterém budou spouštěny. V případě potřeby je následně možná jejich ruční editace. 1. http://www.seleniumhq.org/ 2. http://www.seleniumhq.org/projects/ide/ 15

3. Automatické testování Selenium API Alternativou k záznamu testů v prohlížeči je jejich vývoj v různých programovacích jazycích. Selenium API je framework, přes který probíhá komunikace se Seleniem. Selenium Remote Control Selenium Remote Control 3, zkráceně RC, je nástroj umožňující vytvářet automatické testy uživatelského rozhraní v jakémkoliv programovacím jazyce. Skládá se ze serverové části, která přijímá příkazy přes protokol HTTP a stará se o spouštění a ukončování jednotlivých testů v prohlížeči, a sady knihoven, umožňující vytvářet testy v libovolném programovacím jazyce. Selenium RC není již dále vyvíjen a je podporován pouze z důvodu zachování zpětné kompatibility. Selenium WebDriver Nástupcem Selenium RC je Selenium WebDriver 4. Pracuje tak, že přijímá příkazy, které dále přeposílá do specifického webového prohlížeče. Výhodou je, že ke spouštění testů není potřeba žádný server WebDriver přímo spouští instanci webového prohlížeče, kterou následně ovládá. Selenium Grid Spuštění instancí prohlížeče na vzdáleném počítači umožňuje Selenium Grid 5. Jedná se o server, který se zároveň chová jako rozbočovač testy kontaktují Selenium Grid a vyžádají si volnou instanci webového prohlížeče. Selenium Grid má nakonfigurován seznam serverů, které umožňují přístup k instancím webového prohlížeče, a ty následně přiděluje jednotlivým testům. Selenium Grid zároveň umožňuje paralelní spouštění testů na více stanicích současně a centrální správu různých verzí webového prohlížeče. 3. http://www.seleniumhq.org/projects/remote-control/ 4. http://www.seleniumhq.org/projects/webdriver/ 5. http://www.seleniumhq.org/projects/grid/ 16

3. Automatické testování 3.2.2 Watir Watir 6 (Web Application Testing in Ruby) je open-source balík knihoven pro skriptovací jazyk Ruby. Umožňuje ovládat webový prohlížeč a automatizovat tak testování. Podporuje webové prohlížeče Internet Explorer, Mozilla Firefox, Google Chrome, Opera a Safari. Watir neumožňuje záznam a následné spouštění uživatelských akcí, při tvorbě testů je vyžadována znalost jazyka Ruby. Neznamená to ovšem, že je možné testovat webové aplikace implementované pouze v jazyce Ruby jelikož Watir ovládá přímo webový prohlížeč, je nezávislý na operačním systému, programovacím jazyce a frameworku, který testovaná aplikace používá. Výhodou Watiru je, že při psaní testů je možné využívat všechny dostupné funkce skriptovacího jazyka Ruby je tak možné přistupovat přímo do databáze a číst či zapisovat data, vytvářet soubory nebo zasílat a přijímat emailové zprávy. Jistá omezení může činit fakt, že z Watiru není možné ovládat moduly prohlížeče, jako jsou Java applety, Adobe Flash nebo Microsoft Silverlight. 3.2.3 WatiN WatiN 7 (Web Application Testing in.net) je open-source nástroj vytvořený v jazyce C# a je zaměřený především na snadnou automatizaci webových aplikací vyvíjených na platformě.net. Hlavní inspirací pro jeho vývoj byl framework Watir. WatiN podporuje ovládání webových prohlížečů Internet Explorer a Mozilla Firefox, a stejně jako Watir neumožňuje záznam a spouštění uživatelských akcí v prohlížeči. Zdrojový kód testů vyniká velice snadnou a čitelnou syntaxí. Z technického hlediska probíhá komunikace s prohlížečem Internet Explorer prostřednictvím jeho COM rozhraní. S prohlížečem Mozilla Firefox komunikuje WatiN přes JavaScript Shell Server (JSSh), což je volně dostupný rozšiřující modul pro tento prohlížeč. Od verze Mozilla Firefox 4.0 není tento modul podporován, je možné jej nainstalovat pouze do prohlížeče verze 3.6 nebo nižší [12]. 6. https://watir.com/ 7. http://watin.org/ 17

3. Automatické testování Nevýhodou nástroje WatiN je především podporování zastaralých verzí prohlížeče. Internet Explorer je plně podporován pouze ve verzi 9. S novějšími verzemi funguje nástroj také, není ovšem tak stabilní a při jejich používání se aplikace za určitých okolností může dostávat do nedeterministických stavů. 3.2.4 Windmill Windmill 8 je multiplatformní open-source framework pro kompletní testování webových aplikací s pokročilými možnostmi ladění. Mezi testery je tento nástroj oblíbený zejména proto, že se zaměřuje na jednoduchou tvorbu testů a jejich přenositelnost [13]. Windmill podporuje webové prohlížeče Internet Explorer, Mozilla Firefox, Google Chrome, Opera a Safari na operačních systémech Windows, Mac OS X nebo Linux. Samotný framework je implementován v jazyce Python a Javascript, testy je možné vyvíjet v jazycích Python, Javascript nebo Ruby, případně je zaznamenávat ve webovém prohlížeči. Oproti Seleniu umožňuje nahrávání testů ze všech podporovaných webových prohlížečů, obsahuje navíc vestavěný debugger. 3.2.5 Ranorex Ranorex 9 je komerční framework pro automatizaci testování uživatelského rozhraní desktopových, webových a mobilních aplikací. Podporuje mnoho technologií jako Silverlight, Winforms, WPF, HTML5, Flash, Flex, Windows Apps (Nativní/Hybridní) a mobilní ios a Android aplikace. Umožňuje zaznamenávat testy sledováním interakce s objekty v uživatelském rozhraní. Jednotlivé kroky jsou poté přenositelné a mohou být používány ve více testech. Pokročilé testy mohou být vytvářeny v programovacích jazycích C# nebo VB.NET. Ranorex je dostupný pouze pro operační systém Windows, jelikož je silně závislý na Windows API 10. 8. http://www.getwindmill.com/ 9. http://www.ranorex.com/ 10. https://msdn.microsoft.com/library/windows/desktop/ff818516.aspx 18

3. Automatické testování 3.2.6 SoapUI SoapUI 11 je multiplatformní open-source nástroj společnosti Smart- Bear Software pro automatické testování webových služeb založených na architekturách REST a SOAP. Disponuje jednoduchým uživatelským rozhraním a umožňuje vytvářet a spouštět automatické regresní testy, testy funkcionality a testy zátěže. Na trhu je i komerční verze Pro, která nabízí rozšířenou funkcionalitu, jako je například detailní analýza průběhu testů a podpora pro pokročilé skriptování. 3.2.7 Sahi Sahi 12 je nástroj pro automatické testování webových aplikací s velkým množstvím dynamického obsahu nebo AJAXu. Je dostupný v bezplatné i komerční verzi. Umožňuje záznam a následnou editaci a spouštění testů. Z technického hlediska se Sahi chová jako proxy server, který komunikuje s webovým prohlížečem. Do webových stránek injektuje Javascriptový kód, který umožňuje záznam a spouštění testů. Využití proxy činí Sahi nezávislým na použitém webovém prohlížeči. 3.2.8 Tellurium Tellurium 13 je webová open-source platforma pro automatické testování s vestavěnou podporou pro webové aplikace. Nástroj je odvozený od Selenia, byl ovšem vyvíjen s rozdílným konceptem Selenium se zaměřuje na jednotlivé prvky uživatelského rozhraní, kdežto Tellurium se chová k jednotlivým prvkům uživatelského rozhraní jako k modulům. Každý modul je tvořen množinou vnořených elementárních prvků. Tellurium umožňuje vytvářet testy na základě přirozeného jazyka (angličtiny). Je tak vhodný pro testery, kteří neovládají žádný programovací či skriptovací jazyk. Podporovanými prohlížeči pro spouštění testů jsou Internet Explorer, Mozilla Firefox a Google Chrome. 11. https://www.soapui.org/ 12. http://sahipro.com/ 13. http://www.te52.com/ 19

3. Automatické testování 3.3 Průběžná integrace Nástroje popsané v předchozí kapitole byly zaměřeny převážně na komplexní systémové testy. Chceme-li automaticky spouštět jednotkové, případně integrační testy, potřebujeme zavést systém, který umožní automatické provádění předem definovaných úloh, včetně kompilace a sestavení softwarové aplikace a spuštění a vyhodnocení nízkoúrovňových testů. K tomu slouží systémy průběžné integrace (Continuous Integration, CI). Průběžná integrace je metoda vývoje softwaru, kde jednotliví členové vývojového týmu často a pravidelně integrují svoji část práce. Každá integrace je ověřena automatickou kompilací, sestavením a testy za účelem co nejrychlejší detekce chyb [14]. Přínos průběžné integrace tkví především ve zrychlení vývoje, rychlejším dodávání nových verzí a snížení chybovosti. Poskytuje také stabilnější a lépe řízené prostředí. Nejvýznamnější částí implementace průběžné integrace je sestavení systému. Sestavení může probíhat automaticky, může být vyvoláváno detekcí změn ve zdrojovém kódu. Po zahájení sestavení je z repozitáře načtena nejnovější verze zdrojového kódu, následně se nástroj průběžné integrace pokusí projekt sestavit a otestovat. Na závěr se odešle upozornění, které obsahuje detailní informace s výsledky sestavení [15]. Schéma procesu průběžné integrace je znázorněno na obrázku 3.1. 3.4 Nástroje pro průběžnou integraci Nástrojů pro průběžnou integraci existuje celá řada. Každý disponuje rozdílnými možnostmi, při jejich výběru je nutné zohlednit mnoho faktorů. Mohou se lišit podporovanými operačními systémy, systémy pro správu verzí zdrojového kódu, programovacími jazyky, kompilátory a možností konfigurace. V následujících kapitolách budou popsány charakteristiky vybraných serverů průběžné integrace. 20

3. Automatické testování 3.4.1 TeamCity Obrázek 3.1: Průběžná integrace, zdroj: [16] TeamCity 14 od společnosti Jetbrains je server pro spojitou integraci implementovaný v jazyce Java. Jedná se o komerční software, opensource projekty mohou požádat o bezplatnou licenci. Pro menší projekty, pro které jsou dostačující maximálně tří sestavovací agenti a dvacet konfigurací sestavení je k dispozici speciální bezplatná licence. TeamCity je možné provozovat na operačních systémech Windows, Mac OS X a Linux. Podporuje všechny hlavní systémy pro správu verzí zdrojového kódu, jako je Git, Mercurial, Subversion, CVS, Microsoft Team Foundation Server a Perforce. Změny ve zdrojovém kódu je možné sledovat přímo v prostředí TeamCity, které je dostupné přes webový prohlížeč. Uživatelům je dostupná funkce tzv. osobního sestavení, která spustí proces sestavení, jehož výsledky budou zobrazeny pouze uživateli, který toto osobní sestavení spustil. TeamCity umí detekovat změny v repozitáři a sestavit aplikaci, jakmile je zaznamenána změna ve zdrojovém kódu. Server může být nakonfigurován tak, aby v rámci sestavení prováděl kompilaci zdrojového kódu, spouštění jednotkových a integračních testů, nasazení aplikace do testovacího prostředí a spuštění systémových testů. Disponuje mnoha vlastnostmi, jako je široká škála rozšíření, možnost 14. https://www.jetbrains.com/teamcity/ 21

3. Automatické testování ovládat TeamCity přes REST API, kontrolou kvality kódu a mnoha dalšími. 3.4.2 Jenkins Jenkins 15 je open-source server zajišťující spojitou integraci. Samotný nástroj je implementován v jazyce Java a je tak možné jej provozovat na všech operačních systémech. Disponuje bohatým ekosystémem doplňků a širokou škálou vlastních rozšíření. Téměř každou část systému je možné libovolně upravit dle vlastních potřeb. Především díky velkému množství rozšiřujících modulů podporuje obrovské množství systémů pro správu verzí zdrojového kódu, od těch hlavních, jako je Git, TFS, Subversion a Mercurial, až po méně známé, jako je Accu- Rev a mnoho dalších. Ve výchozím stavu je možné sestavovat pouze aplikace napsané v jazyce Java, jiné programovací jazyky jsou ale dostupné po instalaci doplňků. Silnou stránkou Jenkins je široká komunita uživatelů a vývojářů a velké množství doplňků, které lze do systému instalovat. Těch jsou v dnešní době stovky a jejich počet stále roste. 3.4.3 Travis CI Travis CI 16 je populární webová služba podporující spojitou integraci. Umožňuje sestavení a otestování projektů uložených na GitHubu. Pro open-source projekty je používání této služby zcela zdarma, pro privátní projekty je zpoplatněno. Travis CI podporuje sestavení projektů implementovaných v jazycích C, C++, C#, Java, Javascript, Perl, Python, Ruby, Visual Basic a dalších [17]. Služba kontroluje změny ve zdrojovém kódu, jejichž přítomnost spouští proces sestavení a otestování aplikace. Může být nakonfigurována tak, aby spouštěla sestavení pouze na konkrétní vývojové větvi, případně na větvi, jejíž název odpovídá zadanému vzoru. Po dokončení procesu sestavení je vývojáři zasláno upozornění. V rámci konfigurace je možné nastavit operační systém, ve kterém mají probíhat automatické testy. Podporovanými operačními systémy jsou Windows, Mac OS X a Linux. 15. https://jenkins.io/index.html 16. https://travis-ci.org/ 22

3. Automatické testování 3.4.4 Bamboo Bamboo 17 je nástroj společnosti Atlassian. Pro open-source projekty je k dispozici zdarma, pro komerční projekty je zpoplatněn na základě počtu sestavovacích agentů. Bamboo je implementován v jazyce Java, je tak možné jej provozovat na různých operačních systémech podporovanými jsou Windows, Mac OS X, Linux a Solaris. Dále podporuje systémy pro správu verzí zdrojového kódu Git, Mercurial, Subversion, Perforce a CVS [18]. Poskytuje vestavěnou podporu pro programovací jazyky a frameworky Java,.NET, PHP a Javascript. Podobně jako Jenkins je možné systém rozšiřovat pomocí široké škály dostupných doplňků, jejichž pomocí je možné rozšířit i škálu podporovaných programovacích jazyků. Podporuje paralelní sestavování až na 250 agentech, což může značně urychlit proces testování. Sestavení je spouštěno po detekci změn ve zdrojovém kódu. 3.4.5 Team Foundation Server TFS 18 je server podnikové úrovně pro týmy ke sdílení kódu, sledování práce a dodávání softwaru [19]. Jedná se komerční systém společnosti Microsoft pro správu verzí zdrojového kódu, který obsahuje sadu vestavěných nástrojů pro podporu průběžné integrace a trasování chyb. Je možné sestavit pouze aplikace, které jsou implementovány na platformě.net nebo v nativním C++. Podporované systémy pro správu verzí jsou TFS a Git. Server je možné provozovat pouze na operačním systému Windows. 17. https://www.atlassian.com/software/bamboo 18. https://www.visualstudio.com/products/tfs-overview-vs.aspx 23

4 Testování aplikací vyvíjených na platformě ASP.NET MVC MVC je architektonický vzor, který se používá při vývoji webových aplikací. Rozděluje aplikaci do tří hlavních vrstev - Model, View a Controller, od čehož je odvozen i jeho název. Struktura tohoto vzoru je znázorněna na obrázku 4.1. Jedním z frameworků, který tento vzor implementují, je i ASP.NET MVC, za jehož vývojem stojí společnost Microsoft. ASP.NET MVC se vyznačuje převážně svojí lehkostí a vysokou mírou testovatelnosti [20]. 4.1 Architektura MVC Architektonický vzor Model-View-Controller si klade za cíl především oddělit od sebe jednotlivé části aplikace, jako jsou například data a uživatelské rozhraní. Každá ze tří vrstev aplikace má svoji specifickou a jedinečnou úlohu, za kterou je zodpovědná, a zároveň je izolovaná od ostatních vrstev [21]. Controller obsahuje aplikační logiku, odpovídá na HTTP požadavky uživatele a, pokud je to nutné, předává data prostřednictvím modelu k zobrazení do view [22]. Model reprezentuje data a definuje datovou logiku objektu. Zapouzdřuje vlastnosti a chování doménové entity [21]. V této části aplikace dochází často k získávání dat z databáze, jejich případné modifikaci a následnému ukládání. View je část aplikace, která je zodpovědná za zobrazování a prezentaci dat uživateli. To nejčastěji znamená generování HTML kódu, jež se má zobrazit ve webovém prohlížeči. Je to jediná vrstva aplikace, která je uživateli dostupná jakákoliv interakce s aplikací probíhá právě přes view. Controller předává do view referenci na model, jehož data se mají zobrazit [22]. View se zaměřuje pouze na prezentaci dat neobsahuje žádnou logiku, která by data modifikovala [21]. Controller řídí aplikační logiku aplikace, obstarává příchozí požadavky a chová se jako koordinátor mezi vrstvami model 25

4. Testování aplikací vyvíjených na platformě ASP.NET MVC Obrázek 4.1: Architektonický vzor MVC a view. Uživatelský vstup je controlleru poskytován skrze view, následně controller pracuje s modelem, aby vykonal požadovanou specifickou akci, a výsledek předává zpět do view k zobrazení [21]. 4.2 Testování vrstvy Model Model obsahuje business logiku aplikace, jedná se tak o primární vrstvu k testování. Oproti ostatním vrstvám obsahuje nejméně závislostí, což z něj činí zároveň i nejsnadnější vrstvu k otestování. Pro demonstraci testování modelu si nejprve vytvoříme konkrétní model. Zavedeme třídu Account, která bude obsahovat i metodu Withdraw. Tato třída reprezentuje účet uživatele a její implementaci znázorňuje zdrojový kód 4.1. Před jakýmkoliv testováním je nejprve nutné si ujasnit, jaké chování od objektu testování očekáváme. Pouze poté je možné vytvořit testy, které budou řádně plnit svou funkci, tedy validovat chování. Jakmile si tato očekávání ujasníme, můžeme se pustit do samotné tvorby testů. Metoda Account.Withdraw() z daného účtu odebere určitý obnos peněz. Pokud je stav účtu příliš nízký, je vyvolána výjimka. Testy metody Withdraw jsou zobrazeny ve zdrojovém kódu 4.2. Pokud bychom tyto testy spustili, zjistili bychom, že všechny skončí úspěšně. 26

4. Testování aplikací vyvíjených na platformě ASP.NET MVC public class Account { private string customername ; public int Id { get ; private set ; } public double Balance { get ; private set ; } \\... public void Withdraw ( double amount ) { if ( Balance < amount ) { throw new ArgumentException ( amount, " Balance is too low "); } else { Balance -= amount ; } } } Zdrojový kód 4.1: Model Account [ TestClass ] public class WithdrawTests { [ TestMethod ] public void Withdraw_ValidAmount_ChangesBalance () { // arrange double balance = 100; double expected = 84; var account = new Account (" Bill Gates ", balance ); // act account. Withdraw (16) ; double result = account. Balance ; // assert Assert. AreEqual ( expected, result ); } } Zdrojový kód 4.2: Testování modelu Account 27

4. Testování aplikací vyvíjených na platformě ASP.NET MVC Poté co ověříme, že objekt testování dělá to, co dělat má, je dobré se zaměřit i na to, zda nedělá to, co dělat nemá. Tento přístup můžeme nazvat jako soustředění se na pozitiva, respektive soustředění se na negativa [21]. Při soustředění na negativa bychom mohli například otestovat, zda-li je možné z účtu odebrat větší množství peněz, než jaká je aktuální bilance na účtu, případně záporné množství peněz. V obou případech bychom očekávali, že bude vyvolána výjimka. První test by po spuštění v pořádku prošel dle očekávání, druhý však nikoliv a skončil by chybou. Implementaci modelu Account dle zdrojového kódu 4.1 obsahuje chybu, jejíž přítomností je možné odebírat z účtu i záporné množství peněz. Díky testům bychom defekt v aplikaci objevili a chybu mohli opravit. V tomto případě jsme první implementovali model a až následně jsme psali testy. Existuje přístup k vývoji softwaru, kdy jsou testy naopak psány před samotnou implementací zdrojového kódu. Tato technika se nazývá programování řízené testy (z anglického test-driven development, TDD). Požadavky na funkcionalitu jsou po návrhu aplikace přepsány do spustitelných testů, ještě před samotným vývojem. Tyto testy jsou spouštěny spolu s rozšiřováním funkcionality aplikace, dokud všechny testy neprojdou bez chyb. Poté je vývoj funkcionality považován za ukončený [23]. 4.3 Testování vrstvy Controller ASP.NET MVC framework mapuje URL na třídy, které jsou označeny jako controllery. Tato třída následně zpracovává příchozí požadavky a vstup od uživatele v jednotlivých metodách, takzvaných akcích. Většina z těchto metod vrací instanci třídy odvozené od třídy ActionResult. V případě, že metoda vrací datový typ, který není odvozený od třídy ActionResult (jako například řetězec, číslo nebo pravdivostní hodnotu), je tato hodnota automaticky obalena do příslušné třídy dědící od ActionResult [24]. Akce mohou vracet tyto datové typy: 28 ViewResult zobrazí výsledek na webové stránce

4. Testování aplikací vyvíjených na platformě ASP.NET MVC public class AccountController : Controller { public ActionResult Index () { ViewBag. Message = " Account index."; return View (); } public Actionresult Account ( int id) { var db = new AccountDataContext (); var account = db. Accounts. Find (id); return View ( account ); } } Zdrojový kód 4.3: Controller AccountController PartialViewResult zobrazí výsledek v samostatné části webové stránky RedirectResult přesměruje na jinou akci pomocí její URL adresy RedirectToRouteResult přesměruje na jinou akci pomocí názvu příslušného controlleru a metody ContentResult vrátí uživatelem definovaný typ obsahu JsonResult vrátí serializovaný JSON objekt JavaScriptResult vrátí skript, který je možné vykonat na straně klienta FileResult vrátí binární soubor EmptyResult reprezentuje návratovou hodnotu, která je použita, pokud metoda musí vracet hodnotu null (metoda je typu void) Příklad controlleru je znázorněn ve zdrojovém kódu 4.3. Testování controlleru se od testování modelu liší především v logice, kterou chceme testovat. Oproti business logice, kterou obsahuje 29

4. Testování aplikací vyvíjených na platformě ASP.NET MVC model, se testuje aplikační logika. Je dobrým zvykem psát controllery co nejjednodušeji tak, aby neobsahovaly žádné komplikované a komplexní algoritmy. I přesto by vývojáři měli mít jistotu, že se chovají dle jejich zamýšlení proto je vhodné je testovat. Při vývoji controlleru je důležité vyvarovat se přidávání zbytečné zodpovědnosti a soustředit se pouze na aplikační logiku. Typickou úlohou controlleru je: ověřovat stav modelu pomocí vlastnosti ModelState.IsValid pokud ModelState není validní, vrátit chybu získat datovou entitu provést akci nad datovou entitou uložit datovou entitu vrátit odpovídající ActionResult Při jednotkovém testování aplikační logiky controlleru se zaměřujeme především na obsah jednotlivých akcí, chování závislostí či samotného frameworku ignorujeme. K otestování akcí controlleru Account- Controller implementujeme sadu testů, viz zdrojový kód 4.4. Test Index_NoParams_ReturnsView() vytváří instanci controlleru, nad kterou následně volá akci Index(). Tento jednoduchý test následně ověřuje, zda vyvolaná akce vrací předpokládaný ViewResult. Druhý test s názvem Account_ValidAccountId_ReturnsAccountWiew() je z technického hlediska integrační test, jelikož v něm probíhá komunikace s databází. Před spuštěním testu je zavolána metoda TestInitialize(), která vytvoří novou instanci modelu Account a uloží ji do databáze. V testu se následně ověřuje, zda model, který vrátil controller při akci Account(), odpovídá hledanému. Stojí za povšimnutí, jak jednoduché je od sebe jednotlivé vrstvy aplikace oddělit. I přesto, že controller hraje v aplikaci roli prostředníka mezi modelem a view, jsou mezi sebou jednotlivé vrstvy spojeny dostatečně volně na to, aby je bylo možné testovat izolovaně. 30

4. Testování aplikací vyvíjených na platformě ASP.NET MVC [ TestClass ] public class AccountControllerTests { private Account _ account ; [ TestInitialize ] public void TestInitialize () { using ( var db = new AccountDataContext ()) { _ account = new Account (" Bill Gates ", 250 }; db. Accounts. Add ( _account ); db. SaveChanges (); } } [ TestMethod ] public void Index_NoParams_ReturnsView () { var controller = new AccountController (); var result = controller. Index (); Assert. IsInstanceOfType ( result, typeof ( ViewResult )); } [ TestMethod ] public void Account_ValidAccountId_ReturnsAccountWiew () { var controller = new AccountController (); dynamic result = controller. Account ( _ account. Id); Assert. AreEqual ( _account.id, result. Model.Id); Assert. AreEqual ( _account. CustomerName, result. Model. CustomerName ); } Zdrojový kód 4.4: Testování controlleru AccountController 31

4. Testování aplikací vyvíjených na platformě ASP.NET MVC 4.4 Testování vrstvy View Po testování modelu a controlleru zbývá otestovat vrstvu view. Nyní je cílem ověřit správnost uživatelské interakce s ASP.NET MVC aplikací. Moderní webová aplikace se neskládá pouze z HTML kódu a příslušných CSS stylů. Pokročilé techniky Javascriptu a AJAXu proměnily moderní web z jednoduchého mechanismu pro poskytování obsahu na impozantní zážitek, který může proměnit webový prohlížeč na plnohodnotnou vývojovou platformu samu o sobě, jež má se samotným ASP.NET MVC jen máloco do činění [21, s. 370]. Samotnou vrstvu view můžeme rozdělit do několika podvrstev: vykresleného HTML obsahujícího počáteční obsah a strukturu stránky, JavaScriptu obsahujícího aplikační logiku a CSS pravidel, která stránku stylizují. Každý z těchto tří aspektů stránky musí být bezchybný, pokud chceme, aby byl uživatelský požitek z webové aplikace maximální [21]. A každý z nich vyžaduje rozdílný přístup při jejich testování. Pro ověření správné funkčnosti předchozích vrstev jsme používali textové testy, psané ve formě zdrojového kódu. Přínos tohoto druhu testů pro ověřování vrstvy view je značně omezen, vzhledem k tomu, že obsah, který prohlížeč obdrží, a způsob, jakým se ho rozhodne vykreslit, můžou být dvě rozdílné věci. Stejné HTML navíc může být vykresleno rozdílně napříč různými druhy webových prohlížečů, případně jejich verzemi. Ke skutečnému otestování uživatelského rozhraní webové aplikace je tedy nutné ji přímo zobrazit ve webovém prohlížeči a testovat ji ze stejného úhlu pohledu, z jakého ji uvidí i cílový uživatel. Tento způsob testování v sobě zahrnuje skutečné spuštění webového prohlížeče a za virtuálních kliknutí myši a stisků kláves napodobování akcí, které uživatelé webové aplikace nejčastěji provádějí [21]. O tomto způsobu testování již bylo psáno v kapitole 3.2. Vhodnými nástroji pro platformu ASP.NET MVC jsou Selenium (kapitola 3.2.1) a WatiN (kapitola 3.2.3). 32

4. Testování aplikací vyvíjených na platformě ASP.NET MVC [ TestMethod ] public void Account_WithdrawClick_NavigateToWithdraw () { const string baseurl = " http :// localhost : 65193 "; using ( var browser = new IE( baseurl + "/ account ", true )) { var withdrawdiv = browser. Div ( Find. ByClass (" withdraw ")); var withdrawtitle = withdrawdiv. Element ( Find. ByClass (" title ")). Text ; withdrawdiv. Links. First (). Click (); Assert. IsFalse ( string. IsNullOrWhiteSpace ( withdrawtitle )); Assert. AreEqual ( withdrawtitle, browser. Element ( Find. BySelector ("h2. title ")). Text ); } } Zdrojový kód 4.5: Testování uživatelského rozhraní Příklad testu pomocí nástroje WatiN je znázorněn ve zdrojovém kódu 4.5. Nejdříve je prohlížeči Internet Explorer předána instrukce, aby provedl navigaci na adresu http://localhost:65193/account a zobrazil tak detaily účtu na místním vývojovém webovém serveru, který běží na portu 65193. Jakmile je stránka načtena, je nalezen element, který odpovídá testované akci Withdraw. Tento element je identifikován HTML značkou <div class="withdraw" >. Poté je zjištěn textový název akce (podle HTML značky <span class="title" >) a uložen pro pozdější použití. Následuje jádro testu je provedeno virtuální kliknutí myši na první odkaz elementu withdraw, což má za následek přesměrování na stránku obsluhující výběr prostředků z účtu. Nakonec proběhne validace, zda byl uživatel přesměrován na správnou stránku to spočívá v kontrole nadpisu stránky, který má být stejný, jako je název požadované akce. 4.5 Potlačení závislostí při testování Při testování se můžeme dostat do situace, kdy je objekt, jehož chování ověřujeme, přímo závislý na jiném objektu a nejde jej izolovat. Názorným příkladem je controller ze zdrojového kódu 4.3 a jeho akce 33

4. Testování aplikací vyvíjených na platformě ASP.NET MVC Account, která získává model z databáze. Při testování této akce (zdrojový kód 4.4) se tedy také muselo komunikovat s databází. Navíc muselo být zajištěno, aby v době spuštění testu nebyla databáze prázdná a aby obsahovala konkrétní data. To nejen že vede ke zvýšení režie při tvorbě testů, má to ale i další nežádoucí účinek: ve skutečnosti testujeme navíc i přístup k datové vrstvě. Nežádoucí proto, že datová vrstva by jako samostatná jednotka měla být testována izolovaně. A pokud testována izolovaně je, tak dochází k duplikaci testů a testujeme něco, co již otestované je. Tento problém je možné potlačit nahrazením skutečných objektů zástupnými kopiemi, tzv. test doubles, dvojníky [25]. Smyslem těchto dvojníků je nahradit produkční objekty pro testovací účely. Poskytují navenek stejné chování jako produkční objekty, jsou ovšem rozdílně implementovány. Zástupné objekty můžeme rozdělit do několika kategorií [26], jejichž překlad se v českém jazyce doposud neustálil: 34 Dummy objekty jsou nejprostší z nich. Jsou používány pouze ke splnění kontraktu testované třídy, ve které ve skutečnosti nejsou nikdy použity. Nejčastěji se používají například k naplnění parametrů testované metody. Fake objekty funkčně implementují dané rozhraní, tato implementace je ale oproti produkčním objektům značně zjednodušená. Fake objekt slouží ke splnění kontraktu testované třídy v případě, kdy může dojít k volání jeho metod. Stub je již poněkud sofistikovanější objekt, který při volání metod uvnitř testu poskytuje předpřipravené odpovědi. Díky tomu věrně napodobuje produkční objekt. Tento druh objektů je možné generovat testovacím frameworkem. Spy se chová stejně jako stub, umí však navíc zaznamenávat určité informace na základě volání jednotlivých metod, tedy například jaké metody byly volány, kolikrát a s jakými parametry. Tento druh objektů je možné generovat testovacím frameworkem. Mock objekty jsou podobné stub objektům, mají však předprogramovaná očekávání. Očekáváním je myšlen souhrn předem

4. Testování aplikací vyvíjených na platformě ASP.NET MVC [ TestMethod ] public void Account_ValidAccountId_ReturnsAccountWiew () { var expectedaccount = new Account (" Bill Gates ", 250) ; var mockrepository = new Moq. Mock < IRepository >() ; mockrepository. Setup (r => r. Single < Account >( expectedaccount.id)). Returns ( expectedaccount ); var controller = new AccountController ( mockrepository. Object ); dynamic result = controller. Account ( expectedaccount.id); Assert. AreEqual ( expectedaccount, result. Model ); } Zdrojový kód 4.6: Potlačení závislostí dvojníky definovaných pravidel, kterými například vyžadujeme určitý počet volání nějaké metody s přesnou sadou parametrů a podobně. Pokud po proběhnutí testu není některé z očekávání splněno, je celý test označen za neúspěšný [27]. Tento druh objektů je možné generovat testovacím frameworkem. Při testování je vytvořen požadovaný druh zástupného objektu, který je předložen testovanému objektu. Tím dojde k požadovanému odstranění nežádoucích závislostí a izolování testovaného objektu. Příklad je znázorněn ve zdrojovém kódu 4.6, kde je ke generování zástupné kopie použit framework Moq. V příkladu je patrné, jak je zástupný objekt schopen zastupovat rozhraní IRepository. Metoda Setup() určuje, jaká volání má zástupný objekt očekávat, a metoda Returns() určuje návratovou hodnotu při očekávaném volání. Takto vytvořený test se obejde bez komunikace s databází a ověřuje pouze vnitřní logiku testovaného objektu, s potlačením externích závislostí. 4.6 Testovací frameworky pro ASP.NET MVC Testovací framework je prostředí pro vývoj a spouštění automatických testů. Tento framework je zodpovědný za definici formátu, v ja- 35

4. Testování aplikací vyvíjených na platformě ASP.NET MVC kém jsou jednotlivé testovací předpoklady a očekávání vyjadřovány. V této kapitole budou představeny dostupné frameworky pro jednotkové a integrační testování ASP.NET MVC aplikací. 4.6.1 MSTest MSTest 1 je testovací framework společnosti Microsoft sloužící k vytváření jednotkových a integračních testů. Vyznačuje se především výbornou integrací do vývojového prostředí Visual Studio, jehož je součástí. Vytvořené testy je možné spouštět přímo z Visual Studia nebo z konzolové utility, která provádí i jejich vyhodnocení. Framework disponuje širokou škálou atributů, kterými je možné označovat a konfigurovat testovací třídu a její metody. Mezi nejčastěji používané a nejdůležitější atributy patří: TestClass označení třídy, která obsahuje testovací metody TestMethod označení testovací metody ClassInitialize označení metody, která se automaticky vykoná před spuštěním prvního testu z dané třídy, typicky k alokaci zdrojů využívaných testovací třídou ClassCleanup označení metody, která se automaticky vykoná po dokončení posledního testu z dané třídy, typicky k uvolnění alokovaných zdrojů TestInitialize označení metody, která se automaticky vykoná před spuštěním každého testu z dané třídy, typicky k alokaci a konfiguraci zdrojů potřebných pro každý test v testovací třídě TestCleanup označení metody, která se automaticky vykoná po dokončení každého testu z dané třídy, typicky k uvolnění zdrojů ExpectedException označení metody, ve které má být pro úspěšné splnění testu zachycena výjimka předem definovaného typu 1. https://msdn.microsoft.com/en-us/library/ms243147(v=vs.90).aspx 36

4. Testování aplikací vyvíjených na platformě ASP.NET MVC TestCategory zařazení testu do kategorie, podle které budou ve vývojovém prostředí shlukovány TestProperty nastavení specifických metadat daného testu MSTest poskytuje celkem 26 druhů atributů a 29 typů testovacích tvrzení (assert). Příklad testu v MSTest frameworku: [ TestClass ] public class CalculatorTests { [ TestMethod, TestCategory (" Unit ")] public void Divide_SimpleInput_ReturnsQuotient () { var calculator = new Calculator (); var expected = 4; var actual = calculator. Divide (20, 5); Assert. AreEqual ( expected, actual ); } } [ TestMethod, TestCategory (" Unit ")] [ ExpectedException ( typeof ( System. ArgumentException ))] public void Divide_DivideByZero_ThrowsException () { var calculator = new Calculator (); calculator. Divide (20, 0); } Nevýhodou tohoto frameworku je jeho těsná vazba na VisualStudio, bez jehož instalace není možné testy spouštět. Microsoft navíc přestal MSTest dále vyvíjet a rozšiřovat. 4.6.2 xunit.net xunit.net 2 je bezplatný open-source nástroj pro vytváření jednotkových a integračních testů na platformě.net. Je součástí rodiny frameworků xunit a je vyvíjen původními tvůrci frameworku NUnit. Vytvořené testy je možné spouštět z vlastní aplikace s grafickým rozhraním, příkazového řádku nebo z vývojového prostředí Visual Studio po instalaci doplňku. 2. http://xunit.github.io/ 37

4. Testování aplikací vyvíjených na platformě ASP.NET MVC Zvláštností xunit.net je, že neobsahuje atribut pro označení testovací třídy. To umožňuje vývojářům psát testy přímo ve třídě, kterou testují. Neobsahuje ani atribut pro označení metod, které se mají vykonat před spuštěním nebo po dokončením testu. Vývojáři frameworku tvrdí, že používání těchto metod je obecně špatná praktika, která vede ke znepřehlednění testovacího kódu a jeho složitému ladění [28]. Oba atributy lze ale nahradit klasickými konstrukcemi jazyka C#, a to buď bezparametrovým konstruktorem nebo implementací rozhraní IDisposable a metody Dispose. Základní atributy frameworku xunit.net jsou: Fact označení testovací metody Theory označení testovací metody pro test řízený daty (datadriven test) InlineData umožňuje přímo specifikovat testovací data, která jsou předána testovací metodě skrze její parametry PropertyData umožňuje specifikovat vlastnost třídy, která bude předána testovací metodě skrze její parametry ClassData umožňuje specifikovat třídu, jejíž vlastnosti budou předány testovací metodě skrze její parametry ExcelData umožňuje specifikovat sešit aplikace Microsoft Excel, jehož obsah bude po řádcích předáván testovací metodě skrze její parametry Trait nastavení specifických metadat daného testu xunit.net poskytuje celkem 15 druhů atributů a 19 typů testovacích tvrzení (assert). Příklad testů v xunit.net frameworku: public class CalculatorTests { [Fact, InlineData (20, 4, 5), InlineData (20, 20, 1), InlineData (20, -1, -20)] public void Divide_SimpleInput_ReturnsQuotient ( double x, double y, double expected ) 38

4. Testování aplikací vyvíjených na platformě ASP.NET MVC { } var actual = this. Divide (x, y); Assert. Equal ( actual, expected ); } [ Fact ] public void Divide_DivideByZero_ThrowsException () { var calculator = new Calculator (); var exception = Record. Exception (() = > calculator. Divide (20, 0)); Assert. NotNull ( exception ); Assert. IsType < System. ArgumentException >( exception ); } Silnou stránkou tohoto frameworku je podpora testů řízených daty. Nevýhodou jeho použití může být absence určitých atributů a velice slabá uživatelská dokumentace. 4.6.3 NUnit NUnit 3 je bezplatný open-source framework pro vytváření a spouštění jednotkových a integračních testů. Podporuje všechny programovací jazyky z platformy.net. Stejně jako u frameworku xunit.net, je vytvořené testy možné spouštět z vlastní aplikace s grafickým rozhraním, příkazového řádku nebo z vývojového prostředí Visual Studio po instalaci příslušného doplňku. NUnit disponuje možností spouštět testy paralelně a vytvářet si vlastní atributy, případně i testovací tvrzení. Základní atributy frameworku NUnit jsou: TestFixture označení třídy, která obsahuje testovací metody Test označení testovací metody TestCase označení testovací metody a specifikování vstupních parametrů OneTimeSetUp označení metody, která se automaticky vykoná před spuštěním prvního testu z dané třídy, typicky k alokaci zdrojů využívaných testovací třídou 3. http://www.nunit.org/ 39

4. Testování aplikací vyvíjených na platformě ASP.NET MVC OneTimeTearDown označení metody, která se automaticky vykoná po dokončení posledního testu z dané třídy, typicky k uvolnění alokovaných zdrojů SetUp označení metody, která se automaticky vykoná před spuštěním každého testu z dané třídy, typicky k alokaci a konfiguraci zdrojů potřebných pro každý test v testovací třídě TearDown označení metody, která se automaticky vykoná po dokončení každého testu z dané třídy, typicky k uvolnění zdrojů Category zařazení testu do kategorie, podle které budou ve vývojovém prostředí shlukovány Order specifikuje, v jakém pořadí má být test oproti jiným testům spuštěn Property nastavení specifických metadat daného testu NUnit poskytuje celkem 42 druhů atributů a 30 typů testovacích tvrzení. Příklad testů v NUnit: [ TestFixture ] public class CalculatorTests { [ TestCase (20, 4, 5)] [ TestCase (20, 20, 1)] [ TestCase (20, -1, -20)] public void Divide_SimpleInput_ReturnsQuotient ( double x, double y, double expected ) { var actual = this. Divide (x, y); Assert. That ( actual, Is. EqualTo ( expected )); } } [ Test ] public void Divide_DivideByZero_ThrowsException () { var calculator = new Calculator (); Assert. Throws < System. ArgumentException >(() => calculator. Divide (20, 0)); } 40

4. Testování aplikací vyvíjených na platformě ASP.NET MVC NUnit je velice vyspělý framework, který poskytuje široké možnosti použití. Disponuje rozsáhlou komunitou uživatelů a kvalitní dokumentací. Je dostatečně podporován aplikacemi třetích stran, jako jsou vývojová prostředí nebo servery spojité integrace. Nevýhodou je jeho pomalý vývoj a tím pádem dlouhá doba adaptace na nové techniky testování. 4.6.4 SpecFlow SpecFlow 4 je open-source.net nástroj, který umožňuje psát specifikace testů prostřednictvím prostého textu, což vede ke zvýšení čitelnosti. SpecFlow je možné integrovat do vývojového prostředí Visual Studio pomocí doplňku. Testy je následně možné spouštět buď přímo z vývojového prostředí nebo konzolové aplikace. Specifikace pro jednotlivé testy jsou souhrnně označovány jako features a jsou definovány tzv. Gherkin syntaxí [29]. Tento jazyk definuje strukturu a základní syntaxi pro popis testů. Každý test je tvořen několika prvky Gherkin jazyka. Mezi základní prvky pro tvorbu testů patří: Feature název testované vlastnosti aplikace a její základní popis Scenario testovací scénář k dané vlastnosti aplikace (feature) krok scénáře každý scénář se může skládat z několika kroků. Tyto kroky definují předpoklady, vstupní podmínky, akce a verifikační kroky, z nichž se test skládá. Jsou označeny klíčovými slovy Given, When a Then. Posloupnost kroků stejného typu může být spojena pomocí klíčových slov And a But Given definuje předpoklad testu When definuje akci, která se má provést Then definuje cíl k verifikaci Příklad specifikace testu pomocí jazyka Gherkin: 4. http://www.specflow.org/ 41

4. Testování aplikací vyvíjených na platformě ASP.NET MVC Feature : Calculator In order to avoid silly mistakes I want to be told the quotient of two numbers Scenario : Divide two numbers Given I have entered 20 into the calculator And I have also entered 4 into the calculator When I press divide Then the result should be 5 on the screen Na základě výše uvedeného scénáře umí SpecFlow vygenerovat kostru testu v jazyce C#. Tato kostra může být libovolně upravena, aby pokryla konkrétní potřeby. [ Binding ] public class CalculatorSteps { private double result { get ; set ; } private double firstnumber { get ; set ; } private double secondnumber { get ; set ; } private Calculator calculator = new Calculator (); [ Given (@"I have entered (.*) into the calculator ")] public void GivenIHaveEnteredIntoTheCalculator ( int number ) { firstnumber = number ; } [ Given (@"I have also entered (.*) into the calculator ")] public void GivenIHaveAlsoEnteredIntoTheCalculator ( int number ) { secondnumber = number ; } [ When (@"I press divide ")] public void WhenIPressAdd () { result = calculator. Divide ( firstnumber, secondnumber ); } 42

} 4. Testování aplikací vyvíjených na platformě ASP.NET MVC [ Then (@" the result should be (.*) on the screen ")] public void ThenTheResultShouldBeOnTheScreen ( int expectedresult ) { Assert. AreEqual ( expectedresult, result ); } Výhodou SpecFlow je, že umožňuje vytvářet testy, které ověřují chování aplikace, bez nutné znalosti některého z programovacích jazyků platformy.net. Pomocí prostého textu a jazyka Gherkin je tak možné vytvářet testy z jiného úhlu pohledu, než při tradičním přístupu. Pomocí SpecFlow je také možné vytvářet akceptační testy využívající automatizaci prohlížeče. Nevýhodou SpecFlow je, že je přímo závislý na jiném testovacím frameworku pro jednotkové testování. Podporovanými jsou xunit.net, MSTest, NUnit a mbunit. Automatické generování kódu ne vždy pracuje dle představ, vždy je tedy nutná kontrola vygenerovaného zdrojového kódu. 4.6.5 QUnit QUnit 5 je framework pro testování JavaScriptu. Za jeho vývojem stojí tvůrci jquery. QUnit vyniká velice snadným použitím. Testy jsou implementovány v jazyce JavaScript a jsou umístěny v samostatném souboru, ve kterém je uvedena i reference na funkcionalitu, která je objektem testování. Tento soubor je následně spolu se samotným frameworkem inkludován v jednoduché testovací HTML stránce. Tato stránka slouží pouze pro spuštění testů a zobrazení jejich výsledku. Výrazy specifické pro nástroj QUnit: module seskupení testů do jednoho modulu test označení konkrétního testu teststart funkce, která je vykonána před každým testem ve skupině 5. https://qunitjs.com/ 43

4. Testování aplikací vyvíjených na platformě ASP.NET MVC testdone funkce, která je vykonána po každém testu ve skupině begin funkce, která je vykonána pouze před prvním testem done funkce, která je vykonána pouze po posledním testu QUnit poskytuje celkem 15 druhů testovacích tvrzení. Příklad testu v QUnit: /// < reference path =" calculator.js" /> test (" divide two numbers ", function () { var res = calculator. divide (20, 5); equals (res, 4); }); QUnit podporuje testování asynchronních funkcí. Neumožňuje ale automatické spouštění testů, k tomu je potřeba dalších nástrojů, které se na tuto akci specializují. Tuto službu poskytnou například bezplatné nástroje Chutzpah 6 nebo Karma 7. 4.6.6 Jasmine Alternativou pro QUnit je framework Jasmine 8. Jedná se o sadu nástrojů, které je možné použít k ověření správného chování skriptů implementovaných v jazyce JavaScript [30]. Tento nástroj je možné získat buď samostatně nebo jako doplněk do vývojového prostředí Visual Studio. Jasmine je kompatibilní se všemi platformami, na kterých běží JavaScript. Není závislý na jakémkoliv konkrétním prohlížeči nebo jiném testovacím frameworku. Stejně jako QUnit využívá k vyhodnocení testů jednoduchou HTML stránku, v níž jsou přiložené zdrojové i testovací skripty. Po zobrazení této stránky v prohlížeči dojde ke spuštění a vyhodnocení testů. Výrazy specifické pro nástroj Jasmine: describe seskupení testů dohromady it označení konkrétního testu 6. https://github.com/mmanela/chutzpah 7. https://karma-runner.github.io/0.13/index.html 8. http://jasmine.github.io/ 44

4. Testování aplikací vyvíjených na platformě ASP.NET MVC expect vyhodnocení testovacího tvrzení beforeeach funkce, která je vykonána před každým testem ve skupině aftereach funkce, která je vykonána po každém testu ve skupině xdescribe přeskočení skupiny testů xit přeskočení konkrétního testu V základní podobě nabízí Jasmine 14 druhů testovacích tvrzení, které je možné rozšířit o vlastní. Příklad testu v Jasmine: describe (" calculator division ", function () { it(" can divide real numbers ", function () { var calc = new Calculator ; expect ( calc. divide (20, 5)). toequal (4) ; }); }); Jasmine vyniká snadným použitím a orientací na testování dle zadaných specifikací. Nevýhodou je absence podpory paralelního spouštění testů. K automatizovanému spouštění testů je opět potřeba externí nástroj, Jasmine framework podporují například Chutzpah nebo Karma. 45

5 Informační systém ALVAO WebApp Společnost ALVAO s.r.o. se zaměřuje na optimalizaci metodik a vývoj softwarových nástrojů na podporu servisních procesů. Stěžejní produkty společnosti tvoří informační systémy pro řízení zdrojů a služeb hlavně v odděleních správy informačních a komunikačních technologií ICT: ALVAO Asset Management, ALVAO Service Desk a ALVAO Monitoring [31]. ALVAO Asset Management 1 informační systém sloužící k pokročilé evidenci nejen IT majetku. Základem systému je evidence počítačů, zařízení, objektů a nainstalovaného softwaru. ALVAO Service Desk 2 informační systém pro řízení úkolů. Jedná se o systém vyvíjený podle světových procesních standardů na řízení poskytování služeb (ITSM/ITIL). Díky tomu je systém vhodný pro řízení podnikového IT [32]. ALVAO Monitoring 3 nástroj pro sledování aktivity na jednotlivých počítačích ve firemní síti. Díky přehlednému zobrazení výsledků umožňuje snadnou kontrolu zaměstnanců. AL- VAO Monitoring dokáže měřit skutečnou aktivní práci uživatele a využití hardware a software [32]. Jednotlivé produkty je možné používat i samostatně, při společném používání však poskytují uživateli největší přidanou hodnotu. ALVAO Asset Management a ALVAO Service Desk mohou být používány prostřednictvím jak tlustého, tak i tenkého klienta. Tlustým klientem jsou jsou aplikace typu Win32 vyvíjené v C++ s použitím MFC 4 frameworku. Každá aplikace má vlastního tlustého klienta. Tenkým klientem je informační systém ALVAO WebApp. ALVAO WebApp umožňuje jednotné používání produktů ALVAO Asset Management a ALVAO Service Desk prostřednictvím webového prohlížeče. Z ALVAO Service Desk je dostupná téměř veškerá funkcionalita, 1. http://www.alvao.cz/produkty/asset-management-snadne-ovladani/ 2. http://www.alvao.cz/produkty/service-desk-integrace-na-microsoft/ 3. http://www.alvao.cz/produkty/monitoring-ktery-meri-presne/ 4. https://msdn.microsoft.com/en-us/library/d06h2x6e.aspx 47

5. Informační systém ALVAO WebApp Obrázek 5.1: Architektura systému ALVAO Service Desk, zdroj: [33] z ALVAO Asset Management pouze menší část. Architektura systému ALVAO Service Desk je typu klient-server a je zobrazena na obrázku 5.1. 5.1 Technické specifikace informačního systému Informační systém ALVAO WebApp je implementován na platformě ASP.NET MVC 4.0. Data ze systému jsou ukládána do databáze. Podporovaný databázový systém je Microsoft SQL Server ve verzi 2008 R2 nebo novější. Jsou podporovány všechny edice včetně Express. Pro provoz ALVAO WebApp je nutné mít nainstalován a správně zkonfigurován IIS 5 server a.net Framework 4.0 nebo vyšší. Podporovaný webový prohlížeč pro přístup na ALVAO WebApp je Internet Explorer 10 nebo novější. Ostatní prohlížeče nejsou ofici- 5. http://www.iis.net/ 48

5. Informační systém ALVAO WebApp álně podporovány, nicméně přístup z nich není nikterak omezen a funkcionalita zůstává zachována, pokud podporují stejné funkce jako Internet Explorer 10. 5.2 Architektura systému z hlediska vývoje Informační systém ALVAO WebApp je vyvíjen v jazyce C#. Pro zobrazení obsahu je použit Razor View Engine 6, který umožňuje kombinovat jazyky HTML a C#. Razor je dále doplněn o JavaScript, knihovnu jquery a příslušné CSS styly. Díky použití frameworku Bootstrap 7 je design informačního systému plně responzivní. Jako ORM 8 nástroj je použit Dapper 9. Jedná se o knihovnu, která rozšiřuje rozhraní IDbConnection. Ke komunikaci s databází dochází ve vrstvách model i controller. Při vývoji nebyla dodržena zásada, že vrstva controller má obsahovat pouze nutnou aplikační logiku. V obou vrstvách se s databází komunikuje přímo není přítomná žádná mezilehlá vrstva, která by komunikaci zprostředkovávala. Metody, které s databází komunikují, jsou často statické. Proces testování mají na starosti vyhrazení pracovníci, kteří ověřují funkcionalitu produktu manuálním testováním. 5.3 Návrh testů Cílem této práce bylo zavést do procesu vývoje ALVAO WebApp proces automatického testování. Byla vytvořena testovací strategie, která je dodržována členy vývojového týmu. Pro usnadnění celého procesu a možnost automatizace jednotlivých kroků byl vývojový proces rozšířen o proces průběžné integrace. Tato kapitola se bude věnovat procesu automatického testování. Informace o procesu průběžné integrace budou popsány v samostatné kapitole. 6. https://github.com/aspnet/razor 7. http://getbootstrap.com/ 8. Objektově relační mapování, technika k automatické konverzi dat mezi databází a objektově orientovaným programovacím jazykem 9. https://github.com/stackexchange/dapper-dot-net 49

5. Informační systém ALVAO WebApp 5.3.1 Volba nástrojů Jako testovací nástroj byl zvolen framework MSTest, který je popsán v kapitole 4.6.1. Tento nástroj byl vybrán především díky jeho vestavěné integraci do vývojovém prostředí Visual Studio a kvalitní a obsáhlé dokumentaci. Visual Studio je používáno celým vývojovým týmem, požadavek na snadnou integraci testovacího nástroje do tohoto vývojového prostředí hrál při výběru důležitou roli. Pro testování uživatelského rozhraní automatizací prohlížeče byl zvolen nástroj Selenium, popisovaný v kapitole 3.2.1. Tento nástroj byl zvolen převážně z důvodu podpory širokého množství webových prohlížečů, v nichž je aplikaci možné testovat. 5.3.2 Testovací strategie Cílem automatického testování ALVAO WebApp je maximální omezení v první řadě kritických chyb v produktu. Kritické chyby jsou takové chyby, které způsobují provozní problémy znemožňující používání produktu, zejména: zhroucení celého systému nebo jeho části během normálního používání ztrátu nebo porušení dat během normálního používání a současně neexistuje postup pro náhradní řešení problému. K již vytvořeným částem zdrojového kódu jsou vytvářeny testy v případě, že se jedná o místa, kde dochází k manipulaci s daty uživatele (tedy místa, která mohou být potenciálním zdrojem kritických chyb). Pokud se při testování aplikace objeví chyba v části aplikace, ke které existují testy, které ale neodhalí danou chybu, programátor se při opravě snaží rozšířit sadu testů tak, aby tuto chybu detekovaly (je-li to možné). K novým částem zdrojového kódu jsou testy vytvářeny vždy, s cílem pokrýt co největší část nového zdrojového kódu (code coverage). 50

5.3.3 Konvence při psaní testů 5. Informační systém ALVAO WebApp Testy jsou strukturovány dle tzv. syntaxe AAA: Arrange, Act, Assert. Základní myšlenkou je nejdříve vytvoření všech nutných závislostí potřebných pro vykonání testované metody (Arrange), poté spuštění testované metody (Act) a následně ověření, že požadavky testu byly splněny (Assert). Jednotlivé testy jsou na sobě nezávislé, nesmí záležet na pořadí jejich vykonání. Je potřeba zajistit, aby se po vykonání jednotlivých testů nacházel systém ve stejném stavu, jako před spuštěním procesu testování. Testy jsou pojmenovány podle konvence [UnitOfWork_StateUnderTest_ExpectedBehavior]: UnitOfWork co se testuje, například název metody nebo akce, která se má vykonat StateUnderTest za jakých podmínek se testuje, například vstupní parametry nebo specifikace vnitřního stavu objektu ExpectedBehavior očekávané chování: návratová hodnota, změna stavu objektu, vyvolání výjimky Testy jsou rozřazovány do jednotlivých kategorií. Každý test může být zařazen do více kategorií a musí spadat právě do jedné z kategorií Unit nebo Integration. 5.3.4 Pomocné třídy K usnadnění tvorby testů byly vytvořeny pomocné testovací třídy. Tyto třídy jsou umístěny ve složce Helpers testovacího projektu. DatabaseHelper DatabaseHelper je pomocná třída pro komunikaci s databází. Využívá se při integračních testech a obsahuje univerzální metody, jejichž volání není specifické pouze pro konkrétní testy. Hlavními metodami této třídy jsou metody Init a DatabaseCleanUp. Init inicializuje a ustanoví spojení s databází. Tuto metodu je nutné volat před spuštěním testů, které přistupují do databáze. 51

5. Informační systém ALVAO WebApp DatabaseCleanUp metoda, která odstraní všechna vložená data a vrátí databázi do původního stavu. Předchozí stav databáze je obnoven pomocí snapshotů 10. Dále tato třída obsahuje pomocné metody pro usnadnění vkládání dílčích dat, nad kterými probíhají testy. MockHelper Třída MockHelper obsahuje pomocné třídy a metody pro vytváření falešných objektů, zástupných kopií a podobně. Hlavními metodami této třídy jsou metody FakeHttpContext a RegisterRoutes. FakeHttpContext vytvoří HttpContext se zadanými parametry. Je vhodné jej ukládat do HttpContext.Current, pokud metoda, kterou testujeme, získává data z aktuálního HTTP kontextu. RegisterRoutes nastaví routovací pravidla. Pravidla je nutné nastavit vždy, pokud se v testovaném kódu získává URL na základě názvu akce a controlleru. WebServer Třída obsluhující lokální webový servere IIS. Obsahuje metody pro jeho snadné spuštění a ukončení. V IIS serveru je aplikaci nutné hostovat při automatických akceptačních testech. 5.3.5 Jednotkové testy Vzhledem k architektuře informačního systému není možné jednotkovými testy otestovat všechny nejkritičtější části aplikace. Tak jest převážně z toho důvodu, že v těchto částech aplikace jsou velice silné závislosti, případně se přímo v kritických metodách komunikuje s databází. Stávající kritické jednotky nebylo možné izolovat, jelikož komunikace probíhala prostřednictvím statických metod, které neimplementují žádné rozhraní. K takovým metodám prakticky není možné 10. https://msdn.microsoft.com/en-us/library/ms175158.aspx 52

5. Informační systém ALVAO WebApp vytvořit zástupné kopie. Vedení projektu se navíc zdráhalo rozsáhlých změn zdrojového kódu za účelem zvýšení testovatelnosti aplikace jednotkovými testy. Jednotkovými testy tedy byla pokryta jen část aplikace. Nová funkcionalita aplikace je již vyvíjena s důrazem na snadnou možnost izolace a tím pádem i vyšší testovatelnost. Z této nové funkcionality se jedná například o třídu AttachmentHelper, která zajišťuje práci s přílohami a ověřuje, zda-li je soubor daného typu možné přiložit ke zprávě. Tato třída je celá testována pouze jednotkovými testy. 5.3.6 Integrační testy Integračními testy jsou pokryty dvě nejdůležitější funkce celého systému vytváření úkolů a vytváření dílčích zpráv a poznámek k úkolům. Testy ověřují správné vytváření modelu, modifikaci dat a jejich následné uložení do databáze. V inicializačních a ukončovacích metodách těchto testů jsou volány pomocné metody z kapitoly 5.3.4. Integrační testy mimo jiné ověřují, zda-li má uživatel oprávnění vytvářet nové úkoly, zda jsou správně vyplněna všechna povinná pole úkolu, či zda má s daným úkolem oprávnění pracovat. Z hlediska vývoje jsou integrační testy náročné na jejich vlastní tvorbu, především proto, že je nutné znát a nastavit všechny potřebné závislosti. Těch je nemalé množství. Umožňují ale ověření funkčnosti velké části aplikace, proto mají tyto testy vysokou hodnotu. 5.3.7 Akceptační testy Uživatelské akceptační testy byly vyvíjené s použitím nástroje Selenium (kapitola 3.2.1). Při jejich inicializaci je nutné nejdříve spustit lokální server IIS, ve kterém testovaný informační systém běží. Tuto funkcionalitu obstarává pomocná třída WebServer (kapitola 5.3.4). Uživatelské akceptační testy byly vytvářeny pouze pro experimentální účely. K automatickému testování aplikace se nepoužívají, jelikož většinu funkcionality, která by těmito testy byla pokryta, lze ověřit i testy nižších úrovní a tím tak lépe lokalizovat případně nalezené chyby. Vizuální kontrolu vzhledu aplikace je navíc nutné provádět manuálně, tento krok nelze automatizovat. 53

5. Informační systém ALVAO WebApp Vytvořené akceptační testy provádějí především kontrolu autentizace uživatele a vytvoření nového úkolu uživatelem. 5.4 Proces sestavování a testování aplikace Proces vývoje byl rozšířen o proces průběžné integrace, který převzal kontrolu nad sestavováním aplikace. Zároveň sestavení i zautomatizoval. Z nástrojů pro spojitou integraci se jako nejvhodnější kandidát jevil nástroj TeamCity (kapitola 3.4.1). Při výběru byly zohledňovány vlastnosti jako podporované testovací frameworky, podporované nástroje pro sestavení aplikace, kvalita dokumentace a cena. TeamCity poskytuje bezplatnou verzi systému, pokud si uživatel vystačí s maximálně 20 konfiguracemi sestavení. ALVAO nyní využívá konfigurace 3: 54 Unit tests konfigurace pro spouštění jednotkových testů. Sestavení systému s touto konfigurací je vyvoláno změnou zdrojového kódu v projektu AlvaoWebApp. Pokud je testování aplikace automatickými testy neúspěšné, je zasláno emailové upozornění tomu členu vývojového týmu, který změnu zdrojového kódu způsobil. Unit tests + Integration tests konfigurace pro spouštění jednotkových a integračních testů. Sestavení aplikace s touto konfigurací je je vyvoláváno automaticky dvakrát denně, ale pouze v případě, že od uplynulého sestavení a otestování aplikace se ve zdrojovém kódu projektu AlvaoWebApp vyskytla nějaká změna. Pokud je otestování aplikace automatickými testy neúspěšné, je zasláno emailové upozornění těm členům vývojového týmu, kteří změny zdrojového kódu způsobili. Unit tests + Integration tests Weekly report konfigurace pro spouštění všech dostupných testů. Sestavení aplikace s touto konfigurací je prováděno jednou za dva týdny. Jakákoliv chyba odhalená automatickými testy v této konfiguraci je reportována všem členům vývojového oddělení, včetně vedení projektu. Účelem této konfigurace je především pravidelný a jednotný report neopravených defektů odhalených automatickými testy.

5. Informační systém ALVAO WebApp Obrázek 5.2: TeamCity, úvodní stránka 5.4.1 Vyhodnocení procesu testování Každý člen vývojového týmu společnosti ALVAO s.r.o. má přístup na TeamCity server, který je dostupný z místní adresy http://teamcity:8080/. Každý uživatel vidí aktuální stav testování, případně si může spustit tzv. osobní sestavení s libovolnou konfigurací, které provede i otestování aplikace. Tímto způsobem si jednotliví členové vývojového týmu mohou ověřit, že jejich změny ve zdrojovém kódu nezpůsobily nové chyby. Úvodní obrazovka obsahující základní přehled je zobrazena na obrázku 5.2. Zde je mimo jiné i vidět, kolikrát byly jednotlivé konfigurace sestavení spuštěny. V přehledu se vyskytují takzvané muted testy. Takto jsou označeny testy, jejichž neúspěch nezpůsobí celkové selhání procesu testování. Testy odhalující defekty v produktu, jejichž existence je již zaznamenána, jsou tímto způsobem označovány. Těchto testů je malé množství, jelikož je kladen důraz na rychlé odstranění známých chyb. Obrázek 5.3: TeamCity, průběžný vývoj testů 55