Automatické testování webových aplikací

Transcription

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Ð Û Å«Æ ±²³ µ ¹º»¼½¾ Ý Automatické testování webových aplikací DIPLOMOVÁ PRÁCE Bc. Martin Sokol Brno, 2013

2 Prehlásenie Prehlasujem, že táto diplomová práce je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj. Bc. Martin Sokol i

3

4 Pod akovanie Rád by som sa na tomto mieste pod akoval predovšetkým svojmu vedúcemu RNDr. Radkovi Ošlejškovi, PhD. za jeho trpezlivost a ústretovost. Moje pod akovanie patrí aj Vítovi Zatloukalovi, riaditel ovi divízie ecommerce spoločnosti oxy Online s.r.o., za jeho podporu a ústretový prístup, ako aj Hane Holoubkovej, vedúcej týmu testerov, za neocenitel né rady a praktické skúsenosti. Moja vel ká vd aka patrí aj rodine a d alším l ud om za ich pochopenie, podporu a trpezlivost. iii

5

6 Zhrnutie Práca zoznamuje čitatel a s problematikou vývoja a testovania softvéru, popisuje výhody ako aj nevýhody automatického testovania, pričom sa zameriava na testovanie užívatel ského rozhrania webových aplikácií. Ďalej poukazuje na rozličné problémy, ktoré sú s týmto procesom spojené a ponúka niektoré z možností ich riešenia. Práca zároveň obsahuje metodiku nasadenia komplexného testovania v spoločnosti oxy Online s.r.o. v

7

8 Kl účové slová Chyba, testovanie, testový scenár, automatické testy, užívatel ské rozhranie, webové aplikácie, priebežná integrácia, plán testov vii

9

10 Obsah 1 Úvod Testovanie softvéru Pojmy z oblasti testovania softvéru Problémy spojené s testovaním softvéru Testovanie bielej a čiernej skrinky Statické a dynamické testovanie Testy splnením a zlyhaním Funkčné a nefunkčné testovanie Dôvody vzniku chýb Úloha softvérového testera Úrovne testovania softvéru Nástroje na automatické testovanie Systém priebežnej integrácie Testovanie užívatel ského rozhrania Nástroje určené pre automatické testovanie webových aplikácií Zát ažové testy a testy výkonnosti Pozícia testovania z hl adiska vývoja softvéru Tradičné modely vývoja Agilné metódy Náklady na opravu chýb Proces testovania softvéru Ohlasovanie a sledovanie chýb Automatické testy Výhody automatizácie testov Automatické testy užívatel ského rozhrania Obmedzenia automatických testov Použitie návrhových vzorov Návrhový vzor Page Objects Rozsah testov Problémy pri automatizácii testov Plán testovania Proces nasadzovania automatických testov Predbežná analýza Určenie rozsahu pokrytia aplikácie automatickými testami Návratnost nákladov Časový plán Výber technológií a nástrojov ix

11 6.7 Identifikácia a analýza rizík Personálne zaistenie projektu Automatické testovanie aplikácie Proces zostavovania a testovania aplikácie Kontrola výsledkov automatických testov Zát ažové a výkonnostné testy Vyhodnocovanie výsledkov testov Záver

12 1 Úvod S rastúcim objemom programového kódu a počtom participujúcich vývojárov, ktorý sa na vývoji softvéru podiel ajú, rastie aj počet možných chýb, ktoré sa môžu vyskytnút v aplikácii. Podobne aj so vzrastajúcou zložitost ou softvérového projektu prirodzene narastajú aj nároky na jeho testovanie. Vývoj aplikácií so sebou prináša vznik chýb, či rôznych defektov, ktoré sa nevyhýbajú žiadnemu projektu. Ich príčiny sú rôznorodé, problémy môžu vzniknút už na samom počiatku vývoja softvéru, pri tvorbe špecifikácií, nesprávne, neúplné a neustále sa meniace špecifikácie sú najčastejším zdrojom problémov. Okrem toho chyby vznikajú aj vo fáze návrhu ako aj počas samotnej tvorby aplikácie. Testovanie softvéru má za úlohu odhal ovat vzniknuté chyby počas vývoja aplikácie. Proces testovania dokáže potvrdit existenciu chýb, avšak už nedokáže preukázat, že v testovanej aplikácii sa žiadne chyby nenachádzajú. Navrhnutím vhodných techník testovania je možné odhalit podstatnú čast chýb, avšak ide o pomerne náročný proces, či už z hl adiska času potrebného na testovanie, ako aj množstva vynaložených zdrojov. V tomto procese zohrávajú nezastupitel nú úlohu testeri, ktorí neustále dbajú na zaist ovanie kvality výsledného produktu. Náklady na opravu chýb logaritmicky rastú v dobou odhalenia chyby, je preto potrebné odhal ovat vzniknuté chyby čo najskôr v priebehu vývoja aplikácie. Ked že vzhl adom na zložitost softvéru nie je možné otestovat všetky možné kombinácie vstupov a stavov aplikácie, je nutné zvolit metódy testovania tak, aby s čo najmenším počtom testovacích prípadov bolo možné pokryt čo najširšiu funkcionalitu softvéru. Tomuto napamáhajú viaceré techniky vytvárania testovacích scenárov a testovania využitel ných nielen v prípade manuálneho, ale aj automatického testovania. Automatizácia vykonávania testovacích prípadov poskytuje možnost zefektívnenia a zrýchlenia procesu testovania, avšak nedokáže plne nahradit manuálne testovanie. Automatické testy sú vel mi dobre uplatnitel né v prípade jednotkového testovania, ked dokážu pomerne rýchlo otestovat funkčnost algoritmov vzhl adom k vel kému množstvu vstupných dát. Sú však do istej miery nepraktické v iných oblastiach, medzi ktoré patrí aj testovanie užívatel ského rozhrania, kde je práca testerov nenahraditel ná. Užívatel ské rozhranie aplikácie prechádza častými vývojovými zmenami a automatické testy sa nedokážu vysporiadat s touto skutočnost ou tak efektívne ako testeri. Automatické testovanie tak ponúka možnost zefektívnenia procesu tes- 1

13 tovania, avšak má aj svoje nedostatky. Je preto potrebné rozhodnút, do akej miery je možné automatizovat vykonávanie testov. Je nutné zvážit viacero faktorov, kedže isté funkcie aplikácie je možné jednoducho automaticky testovat, avšak v prípade iných už proces vytvárania a testovania nemusí byt natol ko efektívny. Proces zavádzania automatických testov sa vyznačuje vyššími vstupnými nákladmi, než je to v prípade manuálneho testovania, avšak v neskorších fázach dochádza ku znižovaniu nárokov na prostriedky. Automatické testovanie má zmysel predovšetkým v stabilných a dlhotrvajúcich projektoch, aby sa výhody plynúce z nasadenia automatických testov dokázali prejavit. 2

14 2 Testovanie softvéru 2.1 Pojmy z oblasti testovania softvéru V oblasti testovania softvéru sa využívajú rôzne pojmy pre popis určitých situácií spojených s nechceným stavom aplikácie. Pre situáciu, ktorá popisuje zlyhanie softvéru je možné použit viacero výrazov, ako napríklad vada, závada, problém, omyl, udalost, anomália, odchýlka, zlyhanie, nekonzistencia, vlastnost, či chyba. Jednotlivé pojmy majú mierne odlišný význam, avšak výber konkrétneho pojmu závisí aj od zavedenej konvencie v konkrétnej spoločnosti. Pojmy závada, zlyhanie a vada obvykle odkazujú na situáciu, ktorá je určitým spôsobom závažná, či dokonca nebezpečná. Anomália, udalost a odchýlka zvyknú označovat menej závažnú situáciu, neúmyselnú činnost. Problém, omyl a chyba sú pojmy s najširším významom. Je preto vhodné definovat pojem chyba: O softvérovej chybe hovoríme vtedy, ak je splnená jedna, prípadne viacero z nasledujúcich podmienok: - Softvér nerobí to, čo by podl a špecifikácií produktu robit mal. - Softvér robí niečo, čo by podl a údajov špecifikácie robit nemal. - Softvér robí niečo, čo produktová špecifikácia nespomína. - Softvér nerobí niečo, čo produktová špecifikácia nespomína, ale mala by spomínat. - Softvér je t ažko zrozumitel ný, t ažko sa s ním pracuje, je pomalý, alebo podl a názoru testera softvéru ho koncový užívatel nebude považovat za správny. [1, str. 14] Pri testovaní softvéru je potrebné uvedomit si rozdiely aj medzi pojmami presnost a správnost. Ciel om testovania je samozrejme otestovat aplikáciu presne aj správne, avšak v prípade časového plánu projektu, ktorý takéto dôkladné testovanie nedovol uje je potrebné zvolit, či dôraz bude kladený skôr na správnost, alebo presnost testovania. Rozhodnutie, či testovaný softvér má byt najmä správny alebo presný závisí od povahy výsledného produktu, napríklad aplikácia kalkulačky by mala byt správna aj presná, avšak v prípade testovania počítačovej hry by mohol byt kladený dôraz prevažne na jej správnost. V prípade, že časový plán nedovol uje dostatočne otestovat aplikáciu po všetkých smeroch, môžeme rozhodnút, že 3

15 bude prebiehat testovanie na správnost výpočtov a s presnost ou na niekol ko zvolených desatinných miest[1, str. 41]. Obr. 2.1: Presnost a správnost. (zdroj: [1, str. 41]) Rovnako je potrebné rozlišovat pojmy verifikácia a validácia, pre ktoré v slovenčine existuje jednotné pomenovanie kontrola, či overovanie. Avšak pôvodné výrazy majú mierne odlišný význam, ktorý je potrebné rozlišovat v procese testovania softvéru. V prípade verifikácie ide o proces rozhodovania, či aplikácia splňuje dané špecifikácie. Naproti tomu validácia predstavuje proces, či daný softvér vyhovuje samotným požiadavkám zákazníka[1, str. 42]. Testovanie ukazuje aj kvalitu softvéru, avšak niekedy dochádza k nesprávnemu výkladu tohto pojmu so spol ahlivost ou softvéru. Norma IEEE Std definuje pojem kvalita nasledovne: Stupeň, do akej miery systém, komponent alebo proces spĺňa špecifikované požiadavky, prípadne spĺňa zákazníkove alebo užívatel ove potreby a jeho očakávania. [17, str. 60] 1 V prípade spol ahlivosti ide o schopnost systému fungovat podl a daných požiadavkou v definovaných podmienkach za určitý čas, takže v prípade potreby zaistenia vysokej miery kvality a spol ahlivosti je potrebné vykonávat počas vývoja aplikácie patričnú verifikáciu aj validáciu. 1. quality. (1) The degree to which a system, component, or process meets specified requirements. (2) The degree to which a system, component, or process meets customer or user needs or expectations. 4

16 S testovaním úzko súvisí aj zaist ovanie kvality. Tieto pojmy predstavujú procesy, ktorých ciel om je verifikácia a validácia softvéru. Ciel om softvérového testera je odhal ovat chyby, odhal ovat ich čo najskôr a zaistit ich nápravu. V prípade osoby zodpovednej za zaist ovanie kvality softvéru je jej hlavnou úlohou vytvorenie vhodných štandardov a metód, ktoré zdokonalia proces vývoja a zabránia vzniku chýb[1, str. 43]. V prípade ohodnocovania závažnosti chýb sa používajú pojmy priorita a závažnost. Tieto pojmy sa často používajú ako synonymá, avšak v prípade testovania softvéru je vhodné ich rozlišovat, pretože majú mierne odlišný význam. Priorita určuje mieru dôležitosti danej položky na základe rôznych kritérií, určuje sa typicky na základe dôležitosti pre zákazníka, plánu projektu a podobne. Naproti tomu závažnost definuje mieru dopadu danej chyby určenej množstvom (potenciálne) postihnutých užívatel ov a frekvenciou jej výskytu. 2.2 Problémy spojené s testovaním softvéru Žiaden program nie je možné otestovat kompletne nakol ko aj pomerne jednoduché aplikácie obsahujú vel ké množstvo kombinácií hodnôt a stavov aplikácie, takže ich otestovanie by zabralo enormné množstvo času. Je preto potrebné rozhodnút, ktoré vstupné hodnoty budú testované, a ktoré naopak budú z testovania vynechané. Správne rozhodnutie je kl účovým faktorom v návrhu testov, nakol ko správne rozhodnút, ktoré hodnoty má zmysel otestovat, a pre ktoré naopak, testovanie zmysel nemá, pretože by dávali podobné výsledky ako už otestované hodnoty, je pomerne náročný proces a určitou výzvou pre každého testera. Nesprávne definovanie tried ekvivalencie má za následok neotestovanie všetkých relevantných kombinácií prípadov a neprejavenie sa chyba. Testovanie je tak postavené na riziku, že dôjde k úniku určitej chyby, avšak existuje viacero spôsobov, ktoré napomáhajú v procese správneho výberu testovacích dát.[2, 3, 4, 12] Test je úspešný, ak odhalí výskyt jednej alebo viacerých chýb v programe. [8, str. 157] Testovanie teda nemôže dokázat, že sa v aplikácii nevyskytujú žiadne defekty, môže iba preukázat prítomnost rôznych chýb softvéru. Dobrý testovací scenár je taký, ktorý dosahuje vysokú pravdepodobnost odhalenia zatial nenájdenej chyby. V prípade testovania aplikácie platí vzt ah, že s rastúcim počtom narastá aj percento objavených chýb (klesá počet neobjavených chýb) v aplikácii, avšak narastá množstvo prostriedkov, ktoré je potrebné investovat 5

17 Obr. 2.2: Krivka nákladov testovania softvéru. (zdroj: [4, str. 48]) do samotného procesu testovania. Je preto vhodné nájst hranicu, ked je testovanie aplikácie ešte dostatočne efektívne vzhl adom na množstvo neodhalených chýb a vynaložené prostriedky sú primerané, ako to ilustruje obrázok 2.2. Počas procesu testovania softvéru dochádza k úkazu nazývanému pesticídový paradox[1, str. 36], ktorý popisuje skutočnost, že tak ako v prípade škodlivého hmyzu dochádza po čase k vytvoreniu imunity na používané pesticídy, tak rovnako aj testovaný softvér sa stáva určitým spôsobom imúnny voči testovaniu, ktoré prestáva byt nad alej dostatočne účinné. V prípade vývoja aplikácie formou špirálového vývoja dochádza k opakovanému prechodu procesom testovania. Po každej takejto iterácii dochádza k oprave istého percenta chýb, až nakoniec testovanie žiadne d alšie chyby neodhalí. Je teda potrebné s touto skutočnost ou počítat v procese testovania a vytvárat neustále nové postupy, ktoré by dokázali odhalit nové chyby v aplikácii. Ďalšou významnou okolnost ou, ktorá st ažuje proces testovania softvéru sú neustále zmeny v špecifikáciách produktu. Viditel né to je v prípade vývoja aplikácie agilnou formou, ked dochádza k pomerne častým zmenám v návrhu. S meniacimi sa špecifikáciami sa musia vyrovnávat nielen testeri, ale predovšetkým už vytvorené automatické testy, ktoré sa stávajú nefunkčnými. Tieto testy by mali poskytnút určitý mechanizmus, ktorý by umožnil efektívnou a nenáročnou formou reagovat na neustále zmeny v 6

18 aplikácii. Tento stav je možné dosiahnut vhodným výberom nástrojov a technológií, avšak aj vhodným implementovaním abstrakcie využitím rôznych návrhových vzorov a podobne. 2.3 Testovanie bielej a čiernej skrinky Medzi jeden z možných spôsobov klasifikácie prístupov testovania produktu patrí rozdelenie na testy čiernej a bielej skrinky. Vychádza z úrovne znalostí kódu aplikácie a jej vnútorného fungovania[1, str. 49]. V prípade testovania aplikácie ako čiernej skrinky dochádza ku skúmaniu bez akejkol vek znalosti interných mechanizmov a fungovania aplikácie. Overuje sa iba výsledok, ako sa zadané vstupné hodnoty zmenili, či zodpovedajú očakávaným výstupom. Tento spôsob na jednej strane simuluje reálny spôsob použitia aplikácie, avšak na druhej strane generuje nadmerné množstvo testovacích prípadov určitých častí programu a zároveň nedostatočnému otestovaniu iných. V prípade testovania softvéru ako bielej skrinky sa skúma fungovanie algoritmov, interných mechanizmov a využíva analýzu programového kódu. Tento pohl ad umožňuje lepšie odhadnút, ktoré z vetiev algoritmu budú vykonávané častejšie, než iné a tým lepšie prispôsobit testovanie aplikácie. Testy založené na tomto princípe dôsledne testujú správanie sa aplikácie, avšak príliš nekorešpondujú s reálnymi spôsobmi využívania aplikácie. Možným riešením, s ciel om odstránit nevýhody oboch prístupov, je testovanie aplikácie ako šedej skrinky 2. Tento spôsob testovania spočíva v spojení oboch vyššie spomenutých princípov testovania, kde v prvom kroku dochádza k návrhu testov zameraných na zákazníka podl a reálneho využitia aplikácie, teda podobne ako je to v prípade testovanie čiernej skrinky. V druhom kroku sa však aplikujú postupy využívané v procese testovania bielej skrinky s ciel om dostatočného a efektívneho pokrytia kódu aplikácie[2, str. 88]. 2.4 Statické a dynamické testovanie Ďalšou klasifikáciou charakteristiky testovania je rozdelenie na statické a dynamické[1, str. 49]. Ako samotný názov napovedá, v prípade statického testovania je testovaný objekt statický, nemeniaci sa v čase, prebieha jeho skúmanie a kontrola. Naproti tomu v prípade dynamického testovania pre- 2. gray-box, využíva sa aj pojem sklenená skrinka (glass box). 7

19 bieha analýza skúmajúca správanie sa spusteného programu, reakcie systému na užívatel ské podnety. Je možné rozdelenie formy testovania podl a ich charakteristiky: Statické testovanie čiernej skrinky: v tomto prípade sa jedná o testovanie špecifikácií softvéru, dokumentu, obsahujúceho súbor rôznych požiadaviek, štúdií použitel nosti atd. Testovanie prebieha vo forme revízie výsledných špecifikácií tohto dokumentu s ciel om odhalenia prípadných chýb. Dynamické testovanie čiernej skrinky: testovanie aplikácie bez znalosti programového kódu. Ide o kontrolu korektnosti transformácie zadaných vstupov na očakávané výstupné hodnoty. Statické testovanie bielej skrinky: proces analýzy návrhu, architektúry, programového kódu programu s ciel om odhalit možné chyby bez spustenia programu. Zmyslom tohto testovania je včasné odhalenie chýb v aplikácii. Medzi takéto formy testovania spadajú formálne revízie. Dynamické testovanie bielej skrinky: v tomto prípade ide o formu testovania správania sa programu so znalost ou jeho interných mechanizmov, ked na základe tejto znalosti dochádza k selektívnemu výberu testovacích hodnôt podl a spôsobu fungovania algoritmu s ciel om pokryt testami možné priechody vetiev algoritmu. Medzi tieto formy patrí analýza programového kódu, toku dát, vetvenia a analýza podmienok. 2.5 Testy splnením a zlyhaním V prípade testovania aplikácie existujú dva spôsoby testovania testy splnením a testy zlyhaním[1, str. 57]. V prvom prípade sa testuje, či softvér vykazuje požadovanú funkčnost, ich ciel om nie je vyvolat pád aplikácie. V druhom prípade ide o testovanie krajných hodnôt, rôznych neštandardných situácií. Ciel om týchto testov je odhalenie slabých miest softvéru, ktoré by spôsobili neštandardné správanie sa softvéru, prípadne jeho nefunkčnost. V prípade testovania chybových správ aplikácie ide zároveň o testovanie splnením ako aj zlyhaním. V tomto prípade dochádza k testovaniu známych a očakávaných stavov aplikácie. Je tak potrebné definovat testové prípady, čo má obvykle za následok odhalenie aj takých stavov aplikácie, 8

20 ktoré vedú k chybám, s ktorými sa v procese vývoja neuvažovalo, prípadne neboli dostatočne ošetrené v programovom kóde. 2.6 Funkčné a nefunkčné testovanie Testovanie aplikácie zložitý proces, testeri musia byt schopný navrhnút a vykonat testy, ktoré by mali poskytnút prehl ad o kvalite softvéru, nakol ko je potrebné posúdit splnenie požiadaviek kladených na testovaný softvér. Testeri tak musia vybrat konečnú množinu testov poskytujúcich vysokú mieru dôvery, že dostatočne otestujú jednotlivé vlastnosti aplikácie. Výber vhodnej množiny testových prípadov je dôležitá, avšak pomerne náročná úloha. Je potrebné rozhodnút, ktoré vstupné hodnoty budú zahrnuté do testovania, a ktoré budú naopak z testov vynechané. K tomuto účelu slúži aj metóda rozdel ovania vstupov na triedy ekvivalentných prípadov, je základom mnohých d alších techník v procese testovania. Dovol uje systematicky znížit počet testov nakol ko poskytuje pomerne vysokú mieru dôvery, že výber prvkov z rovnakej triedy by opakovane dávala očakávané výsledky. Ďalšou výhodou je zvýšenie efektivity testovania náhodným výberom prvkov z danej množiny, nakol ko každý prvok z určitej triedy by mal dávat rovnaký výsledok. Funkčné testovanie sa zameriava na funkčné vlastnosti a schopností aplikácie, zaoberá sa skúmaním spracovania možných vstupných a výstupných hodnôt. Pre tieto účely existuje viacero techník, medzi ktoré patrí: Rozdelenie množiny vstupov a výstupov na platné a neplatné hodnoty. Testovanie okrajových hodnôt. Kombinatorická analýza ako jedna z metód slúžiaca k testovaniu vzájomného pôsobenia rôznych kombinácií vstupných parametrov. Ďalšou dôležitou stránkou funkčného testovania je kontrola vnútornej logiky toku riadenia softvéru založené na testovaní stavov a prechodu medzi nimi. V tomto procese sa často využíva metóda testovania založená na modeloch ako efektívnom spôsobe popísania fungovania vnútornej logiky algoritmu. Na rozdiel od funkčného testovania, ktoré má za úlohu pozitívne a negatívne otestovanie funkčnosti softvéru, sa nefunkčné testovanie zaoberá testovaním aplikácie z pohl adu rýchlosti, výkonu, bezpečnosti, spol ahlivosti, použitel nosti, dokumentácie atd [1, 2]. 9

21 2.7 Dôvody vzniku chýb Podl a rôznych štúdií[1, str. 15] medzi najčastejšie zdroje chýb patrí špecifikácia a z prevažne z dôvodu ich neexistencie. Ďalším zdrojom chýb je návrh systému, ktorý nemusí byt dostatočne podrobný, dochádza v ňom k neustálym zmenám, prípadne ho v dostatočnej miere nepochopia všetci členovia vývojového týmu. Chyby v programovom kóde sa podiel ajú na vzniknutých chybách v menšej miere, ich zdrojmi môže byt celková zložitost aplikácie, nedostatočná dokumentácia, nedostatok času kvôli termínom odovzdania, prípadne neúmyselnými chybami programátorov. Obr. 2.3: Zdroje chýb. (zdroj: [1, str. 15]) 2.8 Úloha softvérového testera Hlavnou náplňou softvérového testera je v prvom rade vyhl adávat chyby v aplikácii, dbat o to, že testovaný softvér splňuje špecifikácie a neobsahuje chyby. Testeri by nemali testovat iba funkcie, ktoré by za normálnych okolností mali fungovat, ale navrhovat testy tak, aby nimi dokázali odhalit možné chyby v aplikácii. Neobjavená chyba v priebehu testovania znamená predraženie celého projektu, je preto potrebné motivovat testerov, aby sa snažili uvažovat, ako by bolo možné dané chyby objavit v procese vývoja softvéru čo najskôr, a tým pádom znižovat celkové náklady potrebné na ich prípadnú opravu. Úlohou testera je aj skúmanie aplikácie z pohl adu zákazníka, dobrý tester by mal trvat na dosiahnutí maximálnej možnej kvalite softvéru, podobne ako by to robil samotný zákazník. 10

22 2.9 Úrovne testovania softvéru Testovanie aplikácie prebieha na viacerých úrovniach, od jednotkových testov jednotlivých metód, cez testy užívatel ského rozhrania až po rôzne testy bezpečnosti a výkonu. Každý z týchto testov má v procese vývoja a následného testovania aplikácie svoje miesto a opodstatnenie, každá z úrovní sa zameriava na činnosti z inej fázy tvorby softvéru: Jednotkové testy: testovanie metód ako izolovaných jednotiek, dôraz kladú na otestovanie vnútornej logiky jednotlivých funkcií a procedúr. Integračné testy: testovanie kooperácie rôznych modulov s ciel om odhalenia problémov spojených s rozhraním a vzájomnou interakciou. Systémové testy: testovanie aplikácie ako celku, patria sem testy užívatel ského rozhrania, zát ažové testy, testy bezpečnosti a d alšie. Akceptačné testy: proces zhodnotenia, či aplikácia spĺňa definované požiadavky. Obr. 2.4: Pyramída automatického testovania softvéru. (zdroj: [6, str. 312]) Efektívna stratégia automatického testovania softvéru spočíva v rozdelení procesu automatického testovania do niekol kých úrovní, pričom dôraz by mal byt kladený v prevažnej miere na rozsiahle jednotkové testovanie, 11

23 ktoré by malo tvorit pomyselný základ pyramídy, ako to ilustruje obrázok 4. Na automatické testy vyšších úrovní by mal byt kladený stále nižší dôraz. Odôvodnením tohto prístupu je istá krehkost automatických testov užívatel ského rozhrania, ked že aj malá zmena v aplikácii môže významne ovplyvnit ich funkčnost a zároveň vytváranie testov užívatel ského rozhrania je pomerne náročný a časovo zdĺhavý proces [6, 14, 15]. 12

24 3 Nástroje na automatické testovanie Existuje množstvo nástrojov umožňujúcich automatizované testovanie aplikácie na rôznych úrovniach, od jednotkových a integračných testov, cez testy užívatel ského rozhrania, až po rôzne testy bezpečnosti a výkonnosti aplikácie. Výber nástrojov pre automatické testy na nižších úrovniach (jednotkové a integračné testy) závisí najmä od zvolenej platformy. V prípade výberu nástrojov, ktoré umožňujú automatické testovanie užívatel ského rozhrania webových aplikácií je situácia odlišná, testovanie prebieha prostredníctvom webového rozhrania aplikácie a nie je teda platformne závislé. Pri rozhodovaní o výbere určitého nástroja do procesu testovania aplikácie je potrebné zvážit rôzne technické obmedzenia, podporu programovacích jazykov, možnost ich integrácie do procesu testovania, licenčné podmienky a tým okrem iného aj finančnú dostupnost, ale do istej miery aj ich užívatel skú prívetivost a v neposlednom rade aj ich aktuálnost. 3.1 Systém priebežnej integrácie 1 Automatizácia testov vyžaduje zavedenie systému umožňujúceho vytváranie, správu a monitorovanie opakovane prebiehajúcich úloh. Takýto server priebežnej integrácie by mal podporovat systém správy verzií zdrojového kódu a obsahovat nejakú formu plánovača obsluhujúceho automatické spúšt anie definovaných úloh. Obr. 3.1: Prostredie CI serveru Jenkins. 1. Continuous integration (CI) 13

25 Medzi takéto nástroje patrí aj Jenkins 2, ktorý podporuje správu verzií projektu, plánovanie, rôzne spúšt acie mechanizmy a prehl adné užívatel - ské prostredie umožňujúce sledovat stav jednotlivých úloh ako aj rôzne trendové grafy a štatistiky. 3.2 Testovanie užívatel ského rozhrania Na testovanie užívatel ského rozhrania existuje na trhu niekol ko dostupných nástrojov líšiacich sa svojou podporou programovacích jazykov, možnost ami ako aj obmedzeniami. Pri výbere vhodného nástroja pre testovanie užívatel ského rozhrania webovej aplikácie je potrebné vziat do úvahy niekol ko faktorov ako podporované programovacie jazyky, možnosti a obmedzenia nástrojov. Medzi takéto najvýznamnejšie rozdiely patrí spôsob, akým prebieha testovanie užívatel ského rozhrania, pričom existujú dva základné prístupy a každý z nich má svoje výhody a nevýhody. Prvým prístupom je vykonávanie testov s využitím reálneho prehliadača, ked nástroj priamo ovláda prehliadač a simuluje tak rôzne užívatel ské akcie, pričom o vykresl ovanie prostredia webovej stránky sa stará samotný prehliadač. Výhodou tohto prístupu je skutočnost, že aplikácia sa testuje v prostredí, v akom bude skutočne nasadená, ked že užívatelia budú využívat rovnako rozličné internetové prehliadače na ovládanie aplikácie. Tento prístup teda umožňuje odhalit isté odlišnosti v správaní sa aplikácie v rôznych konfiguráciách užívatel ského prostredia. Takisto je možné sledovat priebeh testu na obrazovke počítača a vyhodnocovat jeho beh priebežne, tak ako sa odohráva na obrazovke počítača. Nevýhodou tohto prístupu je nutnost využívat istú formu ovládačov pre každý z podporovaných prehliadačov a pravidelne ich udržiavat tak, aby bola zabezpečená požadovaná kompatibilita s ich novými verziami, nakol ko môže dôjst k istej nekompatibilite testovacieho frameworku s konkrétnou verziou prehliadača. Nevýhodou je aj istá pomalost testov, ked počas každého načítania stránky je potrebné kompletne vykresl ovat stránku ako aj st ahovat multimediálny obsah na stránke. Druhým prístupom v testovaní užívatel ského rozhrania webových aplikácií je vykonávanie testov prostredníctvom určitej formy javascriptového interpretera, teda bez priameho vykresl ovania užívatel ského rozhrania. Využitie tejto formy testovania má za následok rýchlejší beh testov, nakol ko nie je potrebné st ahovat multimediálny obsah a vykonávat vykresl ovanie celej webovej stránky v prehliadači, interpreter iba simuluje užívatel ské

26 akcie vo virtuálnom prostredí. Nevýhodou tejto metódy sú isté odlišnosti v spracovaní javascriptu interpreterom a reálnymi prehliadačmi, čo môže viest ku vzniku chýb v testoch. V prípade objavenia sa problémov s javascriptom, napríklad z dôvodu určitej nekompatibility v jeho spracovaní, nie je možné tieto chyby ignorovat a test skončí výnimkou, na rozdiel od predchádzajúcej metódy, ked problém v javascripte síce môže spôsobit problémy s funkcionalitou aplikácie, avšak samotný test môže d alej pokračovat v behu. 3.3 Nástroje určené pre automatické testovanie webových aplikácií V súčasnosti existuje niekol ko dostupných nástrojov umožňujúcich automatické testovanie webových aplikácií, vzhl adom k ich podobnému účelu ponúkajú podobnú funkcionalitu, avšak existujú medzi nimi aj určité odlišnosti: Selenium 3 : balík nástrojov umožňujúci automatizované testovanie webových aplikácií. Vyznačuje sa podporou širokého spektra programovacích jazykov, podporovaných prehliadačov a operačných systémov. Okrem typických prehliadačov používaných používatel mi webových aplikácií prináša aj podporu virtuálneho ovládača, ktorý je implementovaný ako Java aplikácia bez užívatel ského rozhrania a interpretuje javascript podobne ako ostatné prehliadače[20]. Najjednoduchšou aplikáciou z uvedeného balíka nástrojov je Selenium IDE. Je implementovaná ako doplnok do prehliadača Mozilla Firefox a umožňuje nahrávanie, vytváranie a opätovné spúšt anie jednoduchých testovacích skriptov. Jeho vel kou výhodou je jednoduchost, takže nový člen týmu zodpovedný za automatické testy sa tak môže pomerne jednoduchou formou zoznámit s touto technológiou aj bez hlbokých technických znalostí. Naopak, jeho hlavnou nevýhodou je práve jeho jednoduchost, nakol ko množina jeho funkcií je značne obmedzená a nedovol uje použitie podmienok, cyklov a tým ani vytváranie zložitejších testovacích scenárov. Zároveň je problematické redukovanie duplicitného kódu v testovacích metódach, čo vedie k zvýšenej náročnosti údržby jednotlivých testov. Tento nástroj sa teda vyznačuje dobrou mierou produktivity v prípade malej sady testov, avšak udržovatel nost klesá s jej zväčšujúcim sa objemom

27 Selenium Remote Control je staršia verzia Selenium API, ktorá už v súčasnosti nie je nad alej vyvíjaná, podpora zostala zachovaná už iba v rámci spätnej kompatibility a nedochádza k d alšiemu vývoju. Dovol uje písanie automatických testov vo forme skriptov, ktoré dokážu byt interpretované používanými prehliadačmi podporujúcimi javascript. Skladá sa zo serverovej časti, ktorá sa stará o automatickú inicializáciu a ukončovanie jednotlivých inštancií prehliadačov a takisto pre nich vystupuje vo forme proxy servera a z klientskej, ktorú tvorí súbor knižníc s podporou rozličných programovacích jazykov Tento nástroj okrem iného prináša aj možnost riešenia problémov s duplicitou programového kódu v prípade vhodne zvolenej abstrakcie v testoch užívatel ského rozhrania, napríklad implementovaním návrhového vzoru Page Objects, do automatických testov. Selenium WebDriver je nástupcom Selenium RC, prináša odlišné rozhranie, takže nie je spätne kompatibilný. Od predchádzajúcej implementácie sa líši v spôsobe komunikácie s prehliadačmi a kladie dôraz na lepšiu podporu dynamických webových stránok, kde môže dochádzat ku zmenám elementov bez potreby opakovaného načítavania stránky. Selenium Grid umožňuje paralelné spúšt anie sady automatických testov proti rôznym prehliadačom na rôznych klientských staniciach zároveň. Umožňuje distribuované vykonávanie testov a vytvára pomerne l ahko spravovatel né prostredie pre automatické testy. Výhodou tohto riešenia je jednoduchá konfigurácia testov, ked na začiatku testu dôjde k definovaniu požadovaných parametrov prehliadač, jeho verzia, operačný systém a podobne. Centrálny uzol sa sám postará o priradenie konkrétneho testu príslušnej stanici podl a požadovaných kritérií. Týmto mechanizmom je umožnený paralelný beh mnohých testov ako aj vyrovnávanie zát aže medzi pripojenými uzlami. WebTest 4 : testovací framework vytvorený v jazyku Java určený pre testovanie webových aplikácií. Na rozdiel od frameworku Selenium, proces testovania prebieha pod virtuálnym interpreterom webového prehliadača, čo umožňuje rýchlejší beh automatických testov, ked že nie je potrebné vykresl ovanie webovej stránky. Na druhej strane to však prináša určité problémy spojené so spracovaním javascriptu ako aj obmedzení spojených so spracovaním HTML stránok so zloži

28 tou štruktúrou. Umožňuje pomerne jednoduché vytváranie testovacích scenárov, disponuje nástrojom ponúkajúcim ich nahrávanie[21]. Watir 5 : vytvorený v jazyku Ruby, a podobne ako v prípade frameworku Selenium, testovanie aplikácie prebieha pod reálnym prehliadačom. Umožňuje tvorbu zrozumitel ných a l ahko udržovatel ných testov[22]. Windmill 6 : disponuje podporou tvorby testov v jazyku Python, JavaScript a Ruby. Obsahuje nástroj umožňujúci nahrávanie testovacích scenárov a tvorbu automatických testov aj bez znalosti programovacieho jazyka. Automatické testy sú spúšt ané v prostredí webových prehliadačov[23]. Twill 7 : umožňuje testovanie webových stránok prostredníctvom príkazového riadku, napísaný v jazyku Python, avšak nad alej už neprebieha aktívny vyvoj[24]. Celerity 8 : vytvorený v jazyku Ruby využívajúci prostredie Java pre beh interpretera webových stránok, posktuje API kompatibilné s frameworkom Watir[25]. Tellurium 9 : odvodený od nástroja Selenium, od ktorého sa líši v spôsobe výberu elementov na webovej stránke, s ciel om možnosti lepšej adaptácie na zmeny v aplikácii týkajúce sa štruktúry užívatel ského rozhrania[26]. JWebUnit 10 : vytvorený v jazyku Java, integruje existujúce nástroje HTMLUnit a Selenium do systému s unifikovaným rozhraním[27]. 3.4 Zát ažové testy a testy výkonnosti Zát ažové a výkonnostné testovanie je dôležitou súčast ou testovania softvéru, jeho ciel om je posúdenie robustnosti aplikácie a zvládanie vysokej zát aže. Pre účely tohto testovania sa používajú rôzne špecializované nástroje. Je možné získavat rozličné výstupy, ktoré môžu indikovat na chyby

29 v aplikácii, dokážu odhalit problémy spojené s odozvou a stabilitou systému pod vysokou zát ažou. Forma získaných výstupov je závislá od konkrétneho nástroja, z dôvodov lepšej interpretácie výsledkov a názornosti je niekedy vhodné spracovat získané výstupy do grafickej formy tabul ky, grafy, prehl ady a podobne. Medzi takéto nástroje patrí aj aplikácia jmeter 11, ktorá je špeciálne vytvorená pre tento účel. Jej ciel om je funkčné otestovanie aplikácie pod vysokou zát ažou ako aj testovanie výkonnosti

30 4 Pozícia testovania z hl adiska vývoja softvéru 4.1 Tradičné modely vývoja Tradičné modely vývoja softvéru, ku ktorým patrí napríklad model vodopád, sa vyznačujú rozdelením vývoja do jednotlivých etáp, ktoré po sebe bezprostredne nadväzujú, vel ký dôraz je kladený je výsledné špecifikácie produktu. Výhodou tohto modelu je skutočnost, že v prípade začatia prác na ktorejkol vek fáze sú všetky práce spojené s predchádzajúcimi fázami ukončené, čo však na druhej strane prináša problémy v prípade odhalenia nedostatkov v niektorej z neskorších fáz vývoja[2]. Medzi modely vývoja softvéru patrí aj V-model, je určitým rozšírením tradičného modelu vodopád, podobným spôsobom popisuje vzt ahy medzi jednotlivými vývojovými fázami ako aj súvisiacimi fázami testovania softvéru. Tento model dáva do súvisu jednotlivé etapy návrhu a tvorby softvéru s príslušnými fázami testovania, kde testovacie techniky spojené s návrhom aplikácie vytvárajú klesajúcu l avú stranu diagramu a vzt ahujú sa na proces verifikácie. Testovacie techniky spojené s požiadavkami alebo špecifikáciami sú spojené so stúpajúcou vetvou na pravej strane sa vzt ahujú na proces validácie. Je kladený rovnaký dôraz na proces samotného programovania ako aj testovania, pričom samotný proces testovania začína pomerne skoro, avšak k identifikácii chýb dochádza až v neskorších fázach. Medzi výhody spojené s použitím tohto modelu vývoja je jednoduchost jeho porozumenia a implementácie do procesu vývoja. Plánovanie a návrh testov sa uskutočňuje pred samotným procesom programovania aplikácie, čo umožňuje proaktívne objavovanie chýb už v ranných vývojových fázach. Je dobre využitel ný na menších a stredných projektoch, kde sú požiadavky dostatočne známe a nepredpokladajú sa výraznejšie zmeny špecifikácií, nakol ko tento vývojový model nie je dostatočne flexibilný a neumožňuje jednoduché zakomponovanie zmien v požiadavkách, ked že je potrebné vykonat úpravy aj vo všetkých predchádzajúcich vývojových fázach. 4.2 Agilné metódy Agilné metodiky boli vytvorené ako alternatíva k tradičným modelom vývoja softvéru s ciel om eliminovat ich nedostatky. Dôraz kladú na viacnásobné krátke iterácie, počas ktorých sa agilné týmy snažia o vytvorenie funkčnej verzie aplikácie v krátkych časových intervaloch. Dôraz je kla- 19

31 Obr. 4.1: V-model. (zdroj: [9]) dený na spoluprácu a osobnú komunikáciu v rámci takýchto týmov, ako aj interakciu so zákazníkom[2, str. 65]. Ciel om je vytvorit flexibilné týmy, ktoré by sa dokázali dobre vyrovnávat so zmenami požiadaviek zákazníka počas ktorejkol vek vývojovej fázy. Agilný tým je schopný rýchlo menit priority a smer vývoja podl a potreby, pričom sa snaží udržiavat softvér vo funkčnom stave postupným vykonávaním menších vývojových zmien v aplikácii. Kl účovým konceptom agilného vývoja je model zodpovednosti celého vývojového týmu za výslednú kvalitu produktu, nielen týmu testerov. Na rozdiel od spomenutého V-modelu, proces testovania v priebehu agilného vývoja prebieha paralelne s procesom samotného vývoja aplikácie počas každej iterácie. Vývojový tým je zodpovedný za vytváranie jednotkových testov, aby bolo možné ich automatické spúšt anie po každom novom zostavení aplikácie. Testovacie scenáre akceptačných testov sú sú- 20

32 čast ou procesu analýzy požiadaviek a sú tak pripravené pred samotným ukončením vývoja požadovanej funkcionality. Každá jednotlivá iterácia má za následok rozšírenie množiny regresných testov, avšak zachovanie rozsahu pokrytia aplikácie regresnými testami nie je z dlhodobého hl adiska udržatel né bez automatizácie testov. Obr. 4.2: Schéma agilného procesu vývoja. (zdroj: [9]) Proces agilného vývoja so sebou prináša skrátenie fázy testovania, nakol ko príprava testov prebieha paralelne s procesom vývoja aplikácie a so samotným testovaním aplikácie sa tak začína od momentu, ked to má praktický význam. Ciel om je včasné odhal ovanie chýb. Množina vytvorených testov (jednotkových a integračných testov, testovacích scenárov) sa rozši- 21

33 ruje po každej iterácii a vytvárajú tak množinu regresných testov aplikácie. Naopak nevýhodou tohto modelu sú problémy spojené s dokumentáciou požiadaviek, nakol ko k ich zmenám dochádza pomerne často, aj v procese vývoja, čím môže dochádzat k rôznym nedorozumeniam plynúcich z častých zmien v špecifikácii medzi členmi vývojového týmu. Je preto potrebné dbat na komunikáciu a týmovú spoluprácu. 4.3 Náklady na opravu chýb Chyby v aplikácii je možné odhalit na rôznych úrovniach v procese vývoja aplikácie, od zahájenia vývoja, cez plánovanie, programovanie, testovanie až zavedenie aplikácie do prevádzky. Množstvo prostriedkov, ktoré je potrebné vynaložit na opravu chyby, sa zvyšuje úmerne s časom, kedy je určitá chyba objavená, náklady spojené s opravou chyby na počiatku vývoja v procese analýzy a návrhu je niekol konásobne nižšia než v prípade odhalenia chyby zákazníkom po uvedení softvéru do plnej prevádzky, náklady pritom rastú exponenciálne.[1, str. 16] Obr. 4.3: Náklady na opravu chýb v priebehu času. zdroj: [4, str. 67]) Testovanie, ako proces, ktorý má tieto chyby odhal ovat, sa uskutočňuje na rôznych úrovniach s ciel om postupne zachytit všetky vzniknuté chyby. Rôzne úrovne testov sa tak snažia odhalit problémy spojené s rôznymi fázami vývoja softvéru. Avšak určité percento chýb je možné odhalit aj pred samotným uvedením softvéru do prevádzky, napríklad využitím formálnych revízií, pri ktorých sa skúma programový kód z pohl adu zachovania štandardov, konvencií, zásad programovania a výskytu rôznych iných nedostatkov. 22

34 4.4 Proces testovania softvéru Návrh softvéru je jednou z dôležitých etáp v procese jeho vývoja, pričom dobrý návrh aplikácie dokáže vopred predchádzat eventuálnym problémom v neskorších fázach, je teda vhodné venovat tomuto procesu dostatočnú pozornost. Podobne aj návrh testov môže významne ovplyvnit proces testovania softvéru, je teda potrebné analyzovat, aké typy testov budú spúšt ané, ktoré testy čo najefektívnejšie preveria funkčnost aplikácie a odhalia prípadné chyby, samotné testovanie by malo reflektovat očakávania a požiadavky zákazníka. Samotný proces návrhu testov tak môže začat kritikou návrhu softvéru, pričom obsahuje porovnanie rôznych možností ako aj ponúka alternatívy k uskutočneným rozhodnutiam s ciel om dosiahnut spoločného kompromisu a skvalitnenia návrhu projektu. Pre riešenie opakujúcich sa problémov spojených s návrhom softvéru sa využívajú rôzne návrhové vzory, ktoré tak poskytujú možné postupy riešenia problému. Rovnako aj v prípade procese testovania je možné využit rôzne testovacie vzory, ktoré tak poskytujú stratégie uplatnitel né v procese testovania softvéru. Tvorí ich súbor postupov, heuristík a rôznych d alších foriem riešení určitých problémov spojených s testovaním softvéru. Testovatel nost je veličina popisujúca mieru, do akej miery môže byt softvér kompletne a efektívne otestovaný. [2, str. 85] Faktorom ovplyvňujúcim výsledný produkt je aj miera jeho testovatel nosti, ktorá môže byt ovplyvnená už v procese návrhu softvéru výberom algoritmov, vytvorením dodatočnej funkcionality špeciálne určenej pre potreby testovania a podobne. Zvýšenie testovatel nosti aplikácie je možné uprednostňovaním jednoduchých komponentov z dôvodu ich jednoduchšej otestovatel nosti, umožnením viditel nosti interných štruktúr počas procesu testovania, zavedením interných mechanizmov umožňujúcich ovládat interné mechanizmy aplikácie ako aj poskytnutím dokumentácie projektu testerom, ktorí budú môct overit správnost výsledkov testov. 4.5 Ohlasovanie a sledovanie chýb Po odhalení chyby v aplikácii je nutné túto skutočnost oznámit, aby bolo možné začat na jej náprave, pričom toto oznámenie by malo byt presné a zrozumitel né pre ostatných členov projektového týmu. Záznam o chybe je charakteristický vecným popisom, ktorý obsahuje iba relevantné informácie týkajúce sa konkrétnej chyby bez zbytočných informácií, obsahuje 23

35 stručný a vecný popis problému, postupnost krokov, ktoré vedú k popisovanému problému, prípadne popisujú množinu vstupných hodnôt vyvolávajúcich túto chybu. Chyba by mala byt mala byt popísaná reprodukovatel ným spôsobom, teda mala by byt definovaná postupnost krokov, ktorá vedie ku vzniku danej chyby. Okrem dobre reprodukovatel ných chýb sa však objavujú aj chyby, ktoré sú na prvý pohl ad náhodné. Je však potrebné pokúsit sa o ich izoláciu a reprodukciu, prípadne aspoň o zúženie okruhu funkcionality v aplikácii, ktorej by sa daný problém mohol týkat. Oznamovanie chýb je možné rôznymi spôsobmi, napríklad ručné vypĺňanie formuláru správy o chybe, je však vhodné zaviest systém pre sledovanie chýb, ktorý ponúka množstvo výhod oproti ručnému ohlasovaniu. Každý záznam o chybe by mal obsahovat niekol ko položiek[2, str. 196]: Názov: mal by poskytovat stručné a jasné zhrnutie popisovaného problému, nemal by byt príliš popisný. Podl a tohto atribútu sa najčastejšie vyhl adávajú chyby, je tak možné nájst vzájomné podobné väzby medzi chybami. Popis: poskytuje všetky potrebné informácie, zhrnutie chyby, očakávaný a získaný výsledok, popis dopadu atd. Stav: indikuje stav, v akom sa popisovaná chyba nachádza, popisuje práce, ktorá sa vykonala, alebo ešte len má vykonat, s ciel om odstránenia chyby. Číslo chyby: jednoznačný identifikátor chyby, podl a ktorej je možné danú chybu nájst v systéme. Oblast funkcionality: informácia napomáhajúca v procese odhal ovania príčin vzniku danej chyby, odkazuje na čast produktu, ktorého sa testovaná funkcionalita týkala. Kroky vedúce k reprodukcii chyby: v prípade, že sa nejedná o nereprodukovatel ný typ chyby, táto sekcia obsahuje presný postup, akým je možné navodit popisovanú chybu. Jednotlivé kroky by mali byt dostatočne stručné a postup bez nadbytočných krokov. Priradenie: osoba zodpovedná za riadenie projektu priradzuje úlohu spojenú s riešením vzniknutej chyby niektorému z vývojárov, je preto vhodné viest záznam komu bolo riešenie danej chyby priradené. Závažnost a priorita: určenie miery dopadu chyby a dôležitosti danej položky. 24

36 Prostredie: špecifikácia hardvérov, softvérovej špecifikácie systému, na ktorom došlo k odhaleniu chyby, prípadne aj rôzne d alšie faktory potenciálne ovplyvňujúce vznik sledovanej chyby. Každá takáto chyba zaznamenaná v systéme prejde určitým vývojom, od jej odhalenia a zavedenia do systému, až po jej vyriešenie a uzavretie. Príklad takéhoto vývoja chyby ukazuje obrázok 4.4, ktorý okrem samotného stavu, či je vyriešená, obsahuje aj stavy umožňujúce sledovanie vývoja prác na jej oprave. Po opravení chyby programátorom je chyba pripravená k nasadeniu a prebehne testovanie aplikácie s ciel om zistit, či došlo k odstráneniu tejto chyby. V prípade, že nedošlo k úplnému odstráneniu chyby, chyba sa vráti programátorovi na prepracovanie. V opačnom prípade je potvrdené odstránenie chyby a dôjde k uzavretiu úlohy spojenej s jej opravou. K ohlasovaniu rôznych defektov slúžia rôzne systémy pre sledovanie chýb, pričom takéto nástroje nevyužívajú iba testeri, ale aj l udia zodpovední za vedenie projektu, prípadne samotní zákazníci, je preto potrebné, aby tieto systémy disponovali l ahkou použitel nost ou pre široké spektrum účastníkov. V prípade týchto systémov je kladený vel ký dôraz na ich spol ahlivost, nakol ko by mali byt k dispozícii prakticky nepretržite. Vhodné je aj to, ak umožňuje sledovat aktuálny stav chyby a je schopný komunikovat s rôznymi externými systémami z dôvodu možných exportov dát do tabul kového procesoru, prípadne externých systémov. Záznamy o chybách sú dôležité z hl adiska prehl adu o zlyhaniach softvéru, prijatých opatreniach a možnosti sledovania vývoja počtu v čase. Na obrázku 4.5 je zobrazený príklad takéhoto systému

37 26 Obr. 4.4: Životný cyklus úlohy typu chyba.

38 Obr. 4.5: Príklad obrazovky systému pre sledovanie chýb. 27

39

40 5 Automatické testy Manuálne testovanie je dôležitý, avšak pre samotných testerov pomerne nudný proces nakol ko sa jedná o neustále sa opakujúcu sa a únavnú činnost. Pre vykonanie manuálneho testu je zakaždým potrebné vynaložit rovnaké úsilie, nároky na zdroje teda rastú lineárne s počtom vykonávaných testov. Automatické testy sú naproti tomu znovupoužitel né, je možné ich opakované spúšt anie. Zavádzanie automatických testov sa oproti manuálnemu testovaniu vyznačuje vyššími vstupnými nákladmi spojenými s vytváraním testov, pričom náklady na otestovanie zostavenia aplikácie postupom času klesajú, ked že testovanie sa deje automaticky, typicky po zostavení novej verzie aplikácie[12]. Testy, ktoré sa snažia automatizovat vykonávanie určitého testovacieho scenáru neobsahujú iba automatické prevedenie požadovaných krokov, ale aj niekol ko d alších krokov s tým súvisiacich z dôvodu ich opakovaného efektívneho spúšt ania. Jednotlivé ich súčasti je možné popísat aj metódou SEARCH[2, str. 227] 1, jej názov je odvodený z prvých písmen anglických názvov jednotlivých krokov: Nastavenie/Setup: uvedenie do stavu, ked je možné vykonávat automatické testovanie. Vykonanie/Execution: najdôležitejší, vykonanie definovaných testových krokov. Analýza/Analysis: overenie výsledkov a zistenie úspešnosti testu. Reportovanie/Reporting: publikovanie výsledkov predošlej fázy vytvorením nejakej formy protokolu o vykonanom teste. Upratanie/Cleanup: uvedenie do stavu, ktorý umožní vykonávanie d alších testov. Dokumentácia/Help: podporuje udržovatel nost a robustnost testovacieho prípadu. 5.1 Výhody automatizácie testov V oblasti určenia rozsahu automatizácie testov je v súčasnosti prevládajúcim názorom nesnažit sa o úplnú automatizáciu testov, ale zvolit vhodnú 1. Pôvodne túto metódu popisovali K. Stobie a M. Bergman v článku uverejnenom v roku

41 mieru automatizácie testov. Niektoré činnosti spojené s testovaním softvéru nie je jednoduché automatizovat, nakol ko isté percento chýb je problematické odhalit bez toho, aby niekto sledoval obrazovku počítača a vyhodnocoval, či dané chovanie aplikácie je alebo nie je vyhovujúce. Na druhej strane, pri odhal ovaní istých typov chýb je použitie automatických testov pomerne efektívne. Je teda potrebné rozhodnút, ktoré testy budú automatizované, a pre ktoré to naopak nemá zmysel. Základným predpokladom, aby bolo zautomatizovanie určitého testu zmysluplné, je potreba jeho opakovaného spúšt ania. V rámci posudzovania výhod automatizácie je teda potrebné zobrat do úvahy náklady na zavedenie automatických testov, ich životnost ako aj ich samotný prínos. Zavedenie automatických testov do procesu testovania aplikácie sa vyznačuje vysokými prvotnými nákladmi. Podobne ako je to v prípade manuálneho testovania, aj pre automatické testy je potrebné najskôr vytvorit testovacie scenáre. Odlišnost ou oproti procesu manuálneho testovania je potreba samotnej tvorby automatických testov. Avšak po ich nasadení sú nároky na otestovanie aplikácie výrazne nižšie, ako je to v prípade manuálnych testov. Vzhl adom na efektivitu nemá význam vytvárat automatické testy, ktoré by testovali funkcionalitu aplikácie, u ktorej sa v najbližšej dobe predpokladajú výrazné zmeny v špecifikácii, prípadne jej úplné odstránenie a podobne. Je preto vhodné vytvárat iba také automatické testy, u ktorých je predpoklad ich opakovaného a častého spúšt ania. Prínosy zo zavedenia automatických testov plynú najmä z možnosti ich opakovaného spúšt ania a znovupoužitel nosti. Vyznačujú sa typicky rýchlejším behom v porovnaní s manuálnym testovaním. Majú výhodu aj z hl adiska presnosti a neúnavnosti, nakol ko pozornost testera môže byt po čase znížená a tak dôjst k prehliadnutiu nejakej chyby. Naproti tomu automatické nástroje overia všetky prvky na požadované hodnoty podl a definovaného testovacieho scenára[2, 4, 5, 12]. 5.2 Automatické testy užívatel ského rozhrania V procese testovania užívatel ského rozhrania weobvej aplikácie pomocou automatických nástrojov hrajú významnú rolu viaceré faktory, ktoré robia automatizáciou testov zložitou. Patria medzi ne špecifikácie, ktoré nie sú nikdy konečné, do aplikácie sa postupne pridávajú rôzne nové funkcie a dochádza k zmenám v už existujúcich. Mechanizmy určené pre automatické testovanie aplikácie musia teda s istým vývojom počítat a byt dostatočne 30

42 flexibilné, aby umožnili pružne a dostatočne rýchlo reagovat na zmenu v aplikácii. Automatické testy majú nezanedbatel nú výhodu v možnosti ich opakovaného spúšt ania. Každé opakovanie testu zakaždým vykonáva rovnaký algoritmus, takže zakaždým môžeme očakávat podobné výsledky v prípade zachovania rovnakých vstupných podmienok. V istých ohl adoch je toto správanie aj určitou nevýhodou, nakol ko tester nemusí otestovat aplikáciu vždy v presne určených krokoch. Užívatel môže zmenit poradie určitých operácií, ktoré za normálnych okolností nemajú na výsledok žiaden vplyv, ale v dôsledku chyby sa môže dopracovat k nečakaným výsledkom v dôsledku chyby v aplikácii. Tester dokáže otestovat aplikáciu aj nad rámec definovaného, čo automatické testy nedokážu, testujú iba tie presne prvky definované v testovacom scenári. V prípade testovania určitej funkcionality môže postupovat rovnakým algoritmom ako automatický test užívatel ského rozhrania, avšak tester si dokáže všimnút chybu, ktorú automatizovaný test nedokáže detegovat, nakol ko sú nad rámec testovanej funkcionality. Medzi takéto prípady patria napríklad problémy s grafikou a štýlmi na stránke, chýbajúce obrázky, nesprávne vykreslenie ovládacích prvkov a podobne. Automatizované testy užívatel ského prostredia teda nedokážu plne nahradit testerov, avšak sú istým prínosom. Automatické testy je možné spúšt at paralelne, jednoduchým pridaním výpočtovej kapacity je tak možné bud skrátit dobru trvania testov, alebo rozšírit množstvo testovacích prípadov, ktoré je možné otestovat za istú jednotku času. To dovol uje otestovat rôzne kombinácie hodnôt, ktoré by tester musel testovat neporovnatel ne dlhšiu dobu. Automatické testy majú svoje miesto v procese testovania aplikácie, nakol ko testujú definovanú funkcionalitu a tým umožňujú testerom využit čas na testovanie neobvyklých kombinácií vstupov, alebo testovat aplikáciu viac do hĺbky. 5.3 Obmedzenia automatických testov Medzi limitné faktory automatických testov užívatel ského rozhrania patrí slabá schopnost vysporiadania sa s neštandardnými situáciami v priebehu testovania, typicky v prípade vzniku neočakávanej chyby alebo iného neočakávaného správania sa aplikácie. Medzi limitujúce faktory automatických testov patrí okrem iného aj pomerne zlá schopnost pokračovat v automatickom teste v prípade výskytu chyby. Človek dokáže určit, kde sa vyskytla chyba, a ktoré nasledujúce kroky v testovacom scenári by ňou mohli 31

43 byt ovplyvnené. Požadovaný stav je schopný navodit aj inou alternatívnou cestou v prípade, že táto nie je vzniknutou chybou v aplikácii tiež ovplyvnená. Automatické testy takéto možnosti neponúkajú a testujú iba presne zadané hodnoty a stavy aplikácie. Pomerne vel kým problémom týchto testov je aj potreba úpravy identifikátorov relevantných elementov spojených s testovanou funkcionalitou. Pri oprave chýb alebo úprave funkcionality spojenej s prirodzeným vývojom aplikácie často dochádza k úpravám elementov na stránke, čo má za následok nefunkčnost testov. Jedným z riešení je využívanie jednoznačných identifikátorov pre jednotlivé elementy, čo zvyšuje robustnost automatických testov aj v prípade rôznych zmien v aplikácii. K d alším problémom, ktoré ovplyvňujú funkčnost automatických testov patrí dynamický web, ked dochádza k zmenám obsahu webových stránok aj bez ich celkového načítavania. Na rozdiel od testerov musia nástroje určené pre automatické testovanie užívatel ského rozhrania implementovat rôzne mechanizmy umožňujúce sa vysporiadat sa s týmto stavom, patrí medzi ne napríklad mechanizmus explicitného čakania na zobrazenie/ukrytie elementu na stránke a podobne[1, 2, 12]. 5.4 Použitie návrhových vzorov Používanie abstrakcie a rôznych návrhových vzorov tvorí samostatnú kapitolu vo vývoji softvéru[3]. Návrhové vzory majú svoje miesto pri vyvíjaní aplikácie, ich použitie so sebou prináša určité výhody, avšak na druhej strane aj rôzne obmedzenia plynúce z ich používania. Implementovanie návrhových vzorov má svoje miesto aj v prípade automatických testov aplikácie, nakol ko umožňujú zvýšit čitatel nost testov a naopak, znížit množstvo prostriedkov potrebných pre ich údržbu[2, str. 81] Návrhový vzor Page Objects Patrí medzi návrhové vzory, ktoré znižujú množstvo duplicitného kódu a tým zvyšujú udržovatel nost automatických testov, najmä v prípade aplikácií, v ktorých dochádza k pomerne častým zmenám. Okrem toho podporujú znovupoužitel nost a čitatel nost testov[16, 19]. Základnou myšlienkou tohto návrhového vzoru je využitie abstrakcie a modelovat webové stránky a/alebo ich jednotlivé časti ako samostatné objekty v testovacom kóde. Na jednej strane tak reprezentujú služby poskytované určitou stránkou webovej aplikácie, prípadne jej časti, a na druhej strane ako jediné obsahujú podrobnú znalost štruktúry HTML stránky, tvo- 32

44 ria tak istý medzistupeň medzi automatickými testami a testovanou aplikáciou. Týmto znižujú množstvo duplicít programového kódu v testoch na minimum a do značnej miery zjednodušujú zavádzanie neustálych zmien užívatel ského rozhrania do automatických testov podl a potrieb testovanej aplikácie, nakol ko úpravy je potrebné vykonat ideálne iba na jedinom mieste. To samozrejme šetrí vynaložené prostriedky, najmä množstvo času potrebného na údržbu testov a tým zefektívňuje celý proces testovania softvéru. Obr. 5.1: Schéma použitia návrhového vzoru Page Objects. Nakol ko tieto objekty zapuzdrujú úplnú znalost o štruktúre stránky webovej aplikácie, umožňujú testerom zodpovedným za vytváranie testovacích scenárov plne sústredenie sa na ich tvorbu bez potreby uvažovat nad implementačnými záležitost ami. Pomocou nich je možné efektívne modelovat cestu užívatel a aplikáciou. Na jednotlivé stránky je tak možné pozerat ako na čierne skrinky, ktoré poskytujú určitú funkcionalitu, transformujú zadané vstupy na určité výstupy. Ako príklad môže poslúžit prihlasovacia stránka do webovej aplikácie, kde môže byt niekol ko vstupných a niekol ko d alších funkčných prvkov, typicky tlačidlo pre odosielanie formulára a podobne. Takáto stránka poskytuje službu prihlásenia užívatel a, pričom ako vstupné hodnoty berie užívatel ské meno a heslo. Tester vytvárajúci testovací scenár nepotrebuje poznat vnútornú štruktúru konkrétnej stránky, dokonca tento poznatok nie je žiaduci, nakol ko v jednotlivých elementoch webovej stránky dochádza k početným zmenám v priebehu vývoja aplikácie, takže napríklad zmena v identifikátoroch jednotlivých elementov v žiadnom prípade neovplyvní vytvorené testovacie scenáre. Tento návrhový vzor definuje, že každý takýto objekt obsahuje 2 druhy metód služby poskytované príslušnou stránkou a GET metódy slúžiace 33

45 Algoritmus 5.1 Testovací scenár prihlásenia užívatel a bez použitia návrhového vzoru Page public void l o g i n T e s t ( ) { WebDriver driver = new F i r e f o x D r i v e r ( ) ; driver. get ( u r l ) ; WebElement headerelement = driver. findby ( By. xpath ( " hlocator " ) ) ; headerelement. c l i c k ( ) ; WebElement username = driver. findby ( By. id ( " namelocator " ) ) ; WebElement password = driver. findby ( By. id ( " passwlocator " ) ) ; username. c l e a r ( ) ; username. sendkeys ( " Franta " ) ; password. c l e a r ( ) ; password. sendkeys ( " passw " ) ; driver. findby ( By. xpath ( " submitbtnlocator " ) ). c l i c k ( ) ; asserttrue ( header. issigned ( ) ) ; driver. quit ( ) ; } pre získanie aktuálnych hodnôt zo stránky. Reflektujú teda elementy, s ktorými je schopný užívatel interagovat ako aj možnosti, ktoré je užívatel schopný na danej stránke vykonat. Každá metóda modelujúca poskytovanú službu definuje možnú užívatel skú akciu a ako výstupnú hodnotu vracajú určitý objekt, ktorého sa táto zmena priamo týka. Znamená to, že užívatel ské akcie, ktoré závisia na rôznych vstupných dátach, prípadne rozličných stavoch aplikácie budú modelované ako rozdielne metódy. Takýmto príkladom môže byt úspešné prihlásenie užívatel a po zadaní korektných prihlasovacích údajov a neúspešné prihlásenie po zadaní nesprávnych vstupných hodnôt. Objekty vytvorené podl a návrhového vzoru Page Objects sa vyznačujú nasledujúcimi vlastnost ami: Obsahujú dva druhy verejných metód: metódy reprezentujúce poskytované služby danou stránkou a GET metódy slúžiace pre získanie obsahu elementov webovej stránky aplikácie. Zapuzdrenie znalosti štruktúry HTML stránky a interných mechanizmov na stránke. 34

46 Algoritmus 5.2 Príklad triedy vytvorenej podl a návrhového vzoru Page Objects. public c l a s s LoginPage ( id=" login input " ) private WebElement username ( id = " pass input " ) private WebElement userpassword ( id = " submit btn " ) private WebElement submitbutton ; public HeaderPage loginas ( S t r i n g name, S t r i n g password ) { username. c l e a r ( ) ; username. sendkeys (name ) ; userpassword. c l e a r ( ) ; userpassword. sendkeys ( password ) ; submitbutton. c l i c k ( } ; } public S t r i n g geterrormessage ( ) { / /... } } / /... Žiadne kontroly vo vnútri týchto objektov. Metódy reprezentujúce ponúkané služby vracajú referenciu na objekt typu Page Objects. Môžu reprezentovat celú, alebo iba určitú čast stránky. Rozdielne akcie a výsledky sú modelované ako rozdielne metódy. Pri vytváraní automatických testov s využitím Page Objects je možné ret azit za sebou jednotlivé metódy reprezentujúce príslušné užívatel ské interakcie. Tento postup sa však neukazuje ako celkom vhodný, nakol ko po každej užívatel skej akcii je potrebné, či skôr vhodné, skontrolovat aktuálny stav aplikácie, viditel nost ovládacích prvkov, výskyt chýb na stránke a podobne. 35

47 Algoritmus 5.3 Testovací scenár prihlásenia užívatel a s použitím návrhového vzoru Page public void l o g i n T e s t ( ) { WebDriver driver = new F i r e f o x D r i v e r ( ) ; driver. get ( u r l ) ; HeaderPage header = new HeaderPage ( ) ; LoginPage loginpopup = header. openloginpage ( ) ; header = loginpopup. loginas ( " Franta ", " passw " ) ; asserttrue ( header. issigned ( ) ) ; driver. quit ( ) ; } Z hl adiska implementácie návrhového vzoru Page Objects je vhodné vytvorit hierarchickú štruktúru objektov podl a jednotlivých stránok, ktoré sa vyskytujú v testovanej aplikácii. Všetky vytvorené objekty by potom boli potomkami jedného základného objektu, ktorý by sa staral o konfiguráciu a inicializáciu týchto objektov. Okrem toho by tento objekt obsahoval funkcionalitu spoločnú pre všetky ostatné objekty tohto typu. Tento postup prináša nespornú výhodu v možnosti pomerne nenáročnej zmeny testovacieho frameworku v prípade potreby, nakol ko stačí zmenit implementáciu tohto objektu starajúceho sa o konfiguráciu, pričom zvyšok API zostane nezmenený. Ďalším vhodným postupom pri vytváraní takýchto objektov je nutnost implementovat iba tú funkcionalitu, ktorá je momentálne nevyhnutne potrebná pre tvorbu testovacieho scenára a nezaoberat sa implementáciou celej sady metód, ktoré daný objekt eventuálne môže poskytovat. V prípade potreby sa táto funkcionalita doplní počas tvorby samotného testovacieho scenára. V prípade, že niektorý objekt reprezentuje viacero stránok s obdobnou funkcionalitou, avšak obsahuje pomerne vel a metód, ktoré súvisia s určitým typom chovania, je vhodné z hl adiska lepšej udržovatel nosti a prehl adnosti testov vyčlenit súbor týchto metód a vytvorit tak samostatný objekt. 36

48 5.5 Rozsah testov Pri návrhu testovacích scenárov automatických testov je vhodné zamysliet sa nad ich rozsahom. Testovacie scenáre určené pre testerov je možné koncipovat ako pomerne rozsiahle s ciel om čo najdokonalejšie otestovat určitú funkcionalitu. Avšak v prípade automatických testov užívatel ského rozhrania dochádza k limitácii kvôli použitým technológiám a nástrojom. Je preto vhodné koncipovat testovacie scenáre ako kratšie jednotky, ktoré využívajú čo najmenej funkcionality aplikácie a zameriavajú sa v prevažnej miere iba na funkcionalitu nutnú pre vykonanie daného testovacieho scenára. Význam tohto kroku spočíva v udržaní čo najvyššej miery robustnosti testov nakol ko v priebehu času dochádza ku zmenám v aplikácii a je teda možné, že tieto úpravy ovplyvnia aj automatické testy. V prípade obmedzenia testov na čo najmenšiu množinu funkcií aplikácie postihnú problémy spojené so zmenami v aplikácii menšie percento testov, bude ich tak možné využívat aj nad alej aj bez potreby premietnutia príslušných zmien do automatických testov. Ďalším faktorom, ktorý je potrebné zvážit pri návrhu testov je aj možnost ich paralelného behu. V prípade vel kého množstva testovacích scenárov je možné zredukovat dobu potrebnú na vykonanie celej sady automatických testov doplnením výpočtovej kapacity. Avšak dlhotrvajúci testovací scenár nie je možné efektívne urýchlit podobným spôsobom a doba potrebná pre beh daného scenára bude limitnou pre celú sadu testov. Je preto vhodné vytvárat jednotlivé testovacie scenáre aj s ohl adom na možnost ich škálovatel nosti, teda uprednostňovat tvorbu kratších testovacích scenárov pred komplexnou logikou. Vhodnou hranicou dĺžky jednotlivých automatických testy je približne 20 krokov užívatel ských akcií na stránke. Táto hodnota je len približná, avšak určuje približnú hranicu, ked je ešte možné testovat určitú funkcionalitu aplikácie a zároveň jednotlivé testovacie scenáre netrvajú tak dlho, aby to malo zásadný dopad na dĺžku trvania sady testov v prípade paralelného behu testov. 5.6 Problémy pri automatizácii testov Vytváranie automatických testov užívatel ského rozhrania so sebou prináša niekol ko problémov[5]: Nadmerná zložitost testov: rovnako ako v aplikáciách, ani v automatických testoch nie že žiaduca ich vysoká cyklomatická zložitost. Testovacie scenáre by sa mali vyhýbat využívaniu komplexnej lo- 37

49 giky, mali by byt čo najjednoduchšie a čo najviac lineárne. Zložité ladenie: v prípade výskytu neúspešného testu by nemalo byt ladenie programu zložité, z testu by malo byt jasné, z akého dôvodu došlo ku chybe. Je vhodné využit nejakú formu nahrávania priebehu testu, prípadne vytvorenia určitej formy záznamu (snímok obrazovky, log) v prípade zlyhania testu, ktorý by ul ahčil identifikáciu a lokalizáciu problému. Falošné pozitíva: uvedená situácia nastáva v prípade výskytu zlyhania testu, avšak chyba sa nenachádza v aplikácii, ale v samotnom teste. Falošné negatíva: táto situácia je vážnejšia než predošlá, nakol ko pri analýze výsledkov sa testeri zaoberajú prakticky iba testami, ktoré nedopadli úspešne. V prípade, že v aplikácii sa nachádza chyba a test ju z nejakého dôvodu nedokázal odhalit a nevyskytne sa ani počas interného používania aplikácie pred nasadením, chyba môže mat vplyv na zákazníka. Nevhodné definovanie lokátorov elementov na stránke: vzhl adom ku skutočnosti, že v aplikácii prebiehajú ustavičné zmeny je potrebné definovat lokátory elementov spôsobom, ktorý by bol do istej časti týmto zmenám imúnny a dostatočne robustný. Nie je preto vhodné reflektovat v automatických testoch internú štruktúru stránky, u ktorej je vel ká pravdepodobnost zmien, ale využit jedinečné identifikátory, ktoré budú priradené konkrétnym elementom na stránke. Je potrebné začat s prípravou automatických testov dostatočne skoro v procese vývoja aplikácie: s prípravou zavádzania automatických testov je vhodné začat dostatočne skoro v rámci vývoja aplikácie a alokovat dostatočné zdroje, nakol ko výstupy vo forme prvých automatických testov sa objavujú až po istej dobe od začatia prác n automatických testoch. Rovnako je vhodné mysliet na nasadzovanie automatických testov už v procese návrhu definícia elementov, ktoré budú obsahovat jedinečné identifikátory, čo značne prispeje k zjednodušeniu procesu vytvárania a následnej údržby sady automatických testov. Vzájomné ovplyvňovanie sa testov: nemalo by dochádzat ku stavu vzájomného sa ovplyvňovania testov, napríklad v prípade ich paralelného behu. Takýto prípad je možný v prípade paralelného testovania aplikácie ako prihlásený užívatel. 38

50 6 Plán testovania 6.1 Proces nasadzovania automatických testov Zavádzanie automatických testov do vývoja a testovania aplikácie so sebou prináša podobné problémy, aké je nutné riešit v prípade riadenia samostatného projektu. Je potrebné jednoznačne definovat rozsah a ciele, pripravit časový harmonogram prác, zabezpečit personálne obsadenie, ako aj zhodnotenie rizík spojených s automatizáciou testov a pripravit kroky, ktoré by sa snažili do čo najväčšej miery eliminovat negatíva. Nasadzovanie automatických testov užívatel ského rozhrania sa uskutočnilo v spoločnosti oxy Online s.r.o., práce boli vykonávané na jednom z projektov spoločnosti. Šlo tak o pilotný projekt, ktorý mal preukázat, prípadne vyvrátit, prínos zavedenia procesu automatických testov užívatel ského rozhrania aplikácie. Tento proces mal poukázat na silné a slabé stránky nástrojov pre automatické testovanie webových aplikácií s dôrazom na mieru, s akou si dokážu poradit s pomerne častými zmenami špecifikácie a návrhu aplikácie. Samotná automatizácia testov, ako aj konkrétne automatizované testovanie užívatel ského rozhrania je len jeden krok v procese odhal ovania a opravy chýb. Tento proces nie je celkom možné automatizovat úplne, na vrchole pomyselnej pyramídy celej množiny automatických testov by sa mala nachádzat zodpovedná osoba, ktorá bude pravidelne kontrolovat výsledky automatických testov a v prípade potreby odhlasovat objavené chyby v aplikácii, alebo zaist ovat aktuálnost testov v prípade vzniku falošných negatívnych hlásení, či zmene návrhu samotnej aplikácie. 6.2 Predbežná analýza Pred samotným zahájením procesu zavádzania automatických testov užívatel ského rozhrania je vhodné vykonat predbežnú analýzu s ciel om odhalit silné, slabé stránky, rôzne obmedzenia, podmienky pre úspešnú realizáciu a podobne. K tomuto účelu môže poslúžit SWOT analýza[7]. V prípade procesu nasadzovania automatických testov v spoločnosti oxy Online s.r.o. boli identifikované nasledujúce faktory potenciálne ovplyvňujúce priebeh implementácie automatických testov: Vnútorné silné stránky: už zavedené mechanizmy spojené s ohlasovaním a monitoringom nájdených chýb v aplikácii; zavedené automatizované vytváranie nových zostavení aplikácie s podporou monitoringu; vytvorené 39

51 a dobre rozpracované testovacie scenáre určené pre manuálne testovanie; Vnútorné slabé stránky: pomerne vel ké množstvo neaktuálnych jednotkových testov; Vonkajšie hrozby: požiadavky zo strany zákazníka na zmeny v aplikácii budú vyžadovat, aby testy boli jednoducho rozširovatel né a upravovatel né; pomerne časté požiadavky na zmenu v chovaní aplikácie; možnost nekompatibility a vnútorné chyby zvolených nástrojov; Vonkajšie príležitosti: rozšírenie automatických testov na d alšie projekty v spoločnosti; možnost rozšírit, či inak využit pripravené testy užívatel ského rozhrania v procese testovania bezpečnosti. 6.3 Určenie rozsahu pokrytia aplikácie automatickými testami Pred samotnou tvorbou plánu nasadzovania a samotnej tvorby testov je potrebné určit rozsah aplikácie pokrytý automatickými testami. Stopercentná automatizácia testov nie je nutná, v mnohých prípadoch ani celkom dobre uskutočnitel ná, je teda potrebné rozhodnút, ktoré oblasti a funkcionalita aplikácie bude pokrytá sadou automatických testov. Jednou z možných techník je vytvorenie tabul ky, ktorá na jednej strane obsahuje zoznam typov stránok, ktoré sa vyskytujú v aplikácii a na strane druhej zoznam funkčných/ovládacích prvkov. Z takto vytvorenej matice vylúčime kombinácie prvkov, ktoré sa v aplikácii nenachádzajú a teda ich ani nie je možné testovat. V d alšom kroku je potrebné rozhodnút o testovatel nosti danej funkcionality na danej stránke, je teda potrebné určit, či má zmysel pre konkrétnu oblast automatické testy, alebo naopak, bude testovaná výhradne manuálne. V prípade rozsiahleho projektu je možné týmto spôsobom prehl adne rozdelit nasadzovanie automatických testov do niekol kých fáz. Táto forma vizualizácie rozsahu a pokrytia testov má však aj svoje nedostatky, nakol ko nedokáže zachytit náročnost implementácie plynúcu z množstva možných testovacích prípadov v konkrétnych prípadoch. Nie všetky bunky takto vytvorenej matice budú vyžadovat podobné množstvo prostriedkov, takže s týmto faktom je potrebné počítat neskôr, v prípade tvorby časového plánu a podobne. 6.4 Návratnost nákladov Pred implentáciou automatických testov je potrebné zhodnotit prínos plynúci z ich zavedenia. Manuálne testovanie má na svojom počiatku mierne 40

52 Obr. 6.1: Znázornenie pokrytia automatickými testami užívatel ského rozhrania. strmejší priebeh vyplývajúci z potreby prípravy testovacích scenárov, ale v neskoršom priebehu náklady rastú približne lineárne s počtom cyklov nasadenia novej verzie palikácie. Automatické sa v tomto ohl ade líšia, je pre nich typická vyššia finančná náročnost v úvodnej fáze vyplývajúca z potreby vytvárat testovacie scenáre, podobne ako v prípade manuálneho testovania, avšak opoti nemu je potrebná implementácia jednotlivých testovacích scenárov do formy automatických testov. Výhoda z ich zavedenia vyplýva najmä z faktu, že po vytvorení sady automatických testov sa kumulatívna náročnost na zdroje s prebiehajúcimi testovacími cyklami zvyšuje už iba mierne, nakol ko prebiehajú automaticky, s využitím vol nej výpočtovej kapacity typicky v noci a zásahy sús potrebné iba kvôli úpravám kvôli zmenám v testovanej aplikácii.[10, 11, 13] 6.5 Časový plán Proces plánovania a nasadzovania automatických testov užívatel ského rozhrania aplikácie prebiehal v rámci mojej stáže v spoločnosti oxy Online s.r.o. Bol vykonaný približný odhad času potrebného pre realizáciu jednotlivých etáp, ktoré pozostávali z analýzy možností dostupných nástrojov au- 41

53 Obr. 6.2: Pracnost a potrebné zdroje v prípade zavedenia manuálneho a automatickeho testovania. (zdroj: [11]) tomatického testovania užívatel ského rozhrania webových aplikácií, výber vhodného nástroja, či nástroj, naplánovanie tvorby automatických testov a samotná realizácia. Tá však pre krátkost času končila 1. fázou, ktorá si kládla za ciel pokrytie najpoužívanejších a najkritickejších funkcií aplikácie, 2. fáza nasadzovania automatických testov potom prebiehala po ukončení mojej stáže. V úvode bol vykonaný prieskum s ciel om zistit možnosti konkrétnych nástrojov, vrátane možností ich integrácie do procesu vývoja a testovania. V spoločnosti už bol zavedený proces priebežnej integrácie, takže proces neskoršieho nasadzovania automatických testov bol značne zjednodušený. Istý problém predstavovala neaktuálnost určitého množstva jednotkových testov, bolo preto potrebné postupné zvýšenie efektívneho pokrytia aplikácie týmito testami. Po výbere vhodných nástrojov sa pristúpilo k tvorbe testových scenárov a príprave procedurálnych doporučení týkajúcich sa implementačnej časti, akým bolo aj zavedenie návrhového vzoru Page Objects ako vhodného spôsobu tvorby testov z dôvodu očakávania pomerne častých zmien v aplikácii. Samotná implementácia zahŕňala okrem iného aj vytvorenie testovacieho prostredia, ktoré by umožňovalo konfiguráciu automatických testov z dôvodu požiadavky spúšt ania ich spúšt ania voči rôznym prehliadačom a ich rozličným verziám. Vývoj aplikácie prebiehal agilnou formou, bol kladený dôraz na kratšie 42

54 Obr. 6.3: Časový harmonogram nasadzovania automatických testov. vývojové cykly s ciel om skorého uvedenia požadovanej funkcionality do prevádzky. Bolo teda pravdepodobné, že v aplikácii bude pravidelne a pomerne často dochádzat k určitým zmenám v návrhu, čo so sebou prináša potrebu úprav už vytvorených automatických testov užívatel ského rozhrania. Plán riadenia tvorby testov musí teda počítat aj s touto skutočnost ou a je tak potrebná alokácia dostatku zdrojov, ktoré by umožnili tvorbu nových testovacích scenárov a zároveň úpravu už vytvorených s ciel om udržat celú sadu automatických testov aktuálnu a konzistentnú s testovanou aplikáciou. 6.6 Výber technológií a nástrojov Proces výberu konkrétnych technológií a nástrojov je závislé od viacerých faktorov, ktoré toto rozhodnutie ovplyvňujú. Je potrebné prispôsobit ich výber potrebám konkrétneho projektu, jeho potrebám, špecifikám ako aj požiadavkám na automatické testy a podobne. Významnú rolu zohrávajú aj licenčné podmienky, pod ktorými sú šírené nástroje pre automatické testovanie softvéru. V prípade nasadzovania automatických testov užívatel ského rozhrania v spoločnosti oxy Online s.r.o. boli zvolené nasledujúce kritériá: Aplikácia, ktorá mala byt rozšírená o automatické testy užívatel - ského rozhrania bola implementovaná v jazyku Java, takže na túto platformu bol kladený dôraz v prípade vol by konkrétneho nástroja. Bol preferovaný spôsob testovania pod reálnymi prehliadačmi pred testovaním vo virtuálnom interpreteri, nakol ko tento spôsob poskytuje pomerne reálny prehl ad o správaní sa aplikácie v prostredí, v 43

55 ktorom je používaná a je tak možné odhalit aj chyby špecifické pre konkrétny internetový prehliadač, ked že každý sa vyznačuje určitými špecifikami v spracovaní javascriptu a vykresl ovania webových stránok. Využitie reálnych prehliadačov má výhodu aj v lepšom vysporiadavaní sa automatických testov s výskytom javascriptových chýb ako aj s problémami na úrovni štruktúry HTML stránok. Zvolený nástroj by malo byt možné integrovat do CI servera z dôvodu integrácie automatických testov užívatel ského rozhrania do procesu vývoja aplikácie. Využitý nástroj by mal byt aktuálny a nad alej vyvíjaný z dôvodu podpory nových technológií ako aj opravy obsiahnutých chýb. Nemenej dôležitým faktorom bola aj podpora z hl adiska dobrej dokumentácie k nástroju ako aj jednoduchost jeho použitia. Jedným z d alších kritérií bolo aj možnost jednoduchej tvorby a úpravy testovacích scenárov, nakol ko vývoj samotnej aplikácie prebiehal využitím agilného princípu vývoja, čo má za následok výskyt pomerne častých zmien v priebehu vývoja aplikácie. V spoločnosti oxy Online s.r.o. už v minulosti prebehli isté procesy zavádzania automatického testovania užívatel ského rozhrania aplikácie s využitím nástroja Selenium IDE. Vzhl adom k vyššie uvedeným skutočnostiam bolo rozhodnuté, že najvhodnejším nástrojom, ktorý najlepšie spĺňa požadované kritériá, bude nástroj Selenium. Výhodou tohto nástroja bola aj skutočnost, že v spoločnosti už v minulosti prebehli isté pokusy o zavedenie automackého testovania využitím spomenutého nástroja. Na rozdiel od procesov v minulosti, pre automatizáciu testov užívatel ského rozhrania nebol využitý nástroj Selenium IDE, ale nástroj Selenium WebDriver v spojení so Selenium Grid, ktorý by umožnil lepšiu správu testovacieho prostredia ako aj poskytol možnosti lepšie možnosti škálovatel nosti. 6.7 Identifikácia a analýza rizík Proces nasadzovania automatických testov je náročný proces a prináša so sebou isté riziká[2, str. 154], je preto potrebné vykonat analýzu rizík s ciel om minimalizácie ich dopadu. Každý projekt má isté osobitosti, avšak k typickým rizikám procesu nasadzovania automatických testov užívatel - ského rozhrania okrem iného patrí: 44

56 Problematická úprava automatických testov pri zmenách aplikácie: možným riešením je využitie abstrakcie a návrhových vzorov za účelom navrhnutia takého modelu, ktorý umožní čo najpružnejšiu a najjednoduchšiu reakciu na zmenu v aplikácii. Príliš dlhý beh celej sady automatických testov: pomerne dlhý beh celej sady testov je prirodzenou daňou za možnost jej komplexného otestovania z pohl adu užívatel ského rozhrania, je však možné spúšt anie rovnakých testov na rôznych kombináciách internetových prehliadačov a operačných systémov. Je teda potrebné zvolit také nástroje, ktoré umožnia určitým spôsobom paralelizovat beh jednotlivých testov, prípadne ponúkajú iné mechanizmy ako optimalizovat dĺžku behu automatických testov. Nemožnost otestovat požadovanú funkcionalitu: nakol ko existuje množstvo nástrojov určených pre automatické testy, líšia sa v rôznych faktoroch a ponúkajú tak rozličné možnosti. Je teda potrebné volit tieto nástroje s ohl adom na ich špecifiká a použitel nost daného nástroja si prípadne overit na jednoduchom skúšobnom projekte. Zvolením balíka nástrojov Selenium, pre testovanie užívatel ského rozhrania aplikácie, bolo potrebné vyriešit isté obmedzenia, ktoré však obsahuje každý takýto nástroj. Medzi konkrétne problémy patrí obecne pomalost testov, nakol ko testovanie prebieha pod reálnym prehliadačom, bolo potrebné zvážit technické obmedzenia z toho plynúce. Riešenie ponúka samotný nástroj implementovaním jedného z obsiahnutých nástrojov (Selenium Grid) a vysporiadat sa tak s uvedenými obmedzeniam využitím výpočtového gridu a paralelizácie. Potreba riešenia častých zmien v aplikácii vyústila do implementovania návrhového vzoru Page Objects, ktorý umožňuje pružne reagovat na zmeny HTML štruktúry stránok. 6.8 Personálne zaistenie projektu Do procesu nasadzovania automatických testov aplikácie, zasahujú prevažne 3 skupiny osôb: vývojári, testeri a manažment. Testeri alebo pracovníci zaist ovania kvality sú zodpovední za vyhl adávanie a ohlasovanie chýb v aplikácii, úzko spolupracujú so všetkými členmi týmu pri návrhu, tvorbe ako aj vykonávaní testov. Vývojový pracovníci pracujú na opravy nájdených chýb, pričom spolupracujú s testermi a manažérom projektu. Okrem toho sú zodpovední za tvorbu nových funkcií softvérového produktu v rámci čoho spolupracujú s architektmi a manažérmi projektu. Ma- 45

57 nažéri, ako vedúci pracovníci projektu, majú za úlohu riadenie celého projektu, za jeho plánovanie a vykonávanie rôznych kl účových rozhodnutí spojených s vývojom aplikácie[1, str. 27]. Je tak potrebné určit osoby zodpovedné za proces nasadzovania automatických testov. Nie je nutné, aby do tohto procesu vstupovali všetci testeri, ked že sa u nich nepredpokladajú hlboké programátorské znalosti, ktoré by mohli byt potrebné v prípade implementácie pripravených testovacích scenárov. Okrem samotnej tvorby sady automatických testov je potrebné určit osobu, alebo osoby, zodpovedné za kontrolu verifikáciu výsledkov testov a prípadné ohlasovanie odhalených chýb. Tento krok je potrebný z dôvodu nemožnosti úplnej automatizácie procesu odhal ovania chýb, pretože najmä testy užívatel ského rozhrania sa vyznačujú pomerne vysokým percentom falošných negatívnych poplachov. Neúspešný test tak ešte nutne nemusí znamenat chybu v aplikácii, dokonca ani chybu v samotnom teste, ale určitú technickú chybu spôsobenú kdekol vek od vypršania časových limitov kvôli vyt aženosti stroja, až po problémy spojené so siet ovou komunikáciou. 46

58 7 Automatické testovanie aplikácie Nutným predpokladom zavedenia automatického testovania aplikácie je zavedenie systému priebežnej integrácie, ktorá umožňuje automatické vykonávanie rôznorodých činností od možnosti vytvárania rôznych verzií aplikácie, jej zostavovania, nasadzovania a následného testovania pripravenými automatickými testami. V spoločnosti oxy Online s.r.o. už bol takýto systém plne integrovaný, takže bolo pripravené zázemie pre automatické testovanie. V čase zahájenia prác na zavádzaní automatických testov užívatel ského rozhrania ako aj komplexnej metodiky automatizovaného testovania existoval pomerne vel ký počet jednotkových testov, avšak z väčšej miery neboli aktuálne. Testovanie funkčných požiadaviek tak bolo prevažne náplňou testerov, ktorí boli zodpovední za proces manuálneho testovania aplikácie. Tento stav je možné ilustrovat ako invertovanú pyramídu automatického testovania popisovanú v kapitole 1.9, ked jednotkové testy tvoria úzku základňu pyramídy a manuálne testovanie na vrchole pyramídy tvorí naopak široké spektrum činností. Tento stav však nie je žiaduci, nakol ko so sebou prináša určité problémy v podobe predĺženia času potrebného na odhalenie chyby ako aj nutnost zvýšeného úsilia testerov pri odhal ovaní chýb. Postupným procesom opráv jednotkových testov a nasadzovaním automatických testov užívatel ského rozhrania došlo k invertovaniu spomenutej pomyselnej pyramídy testovania a priblíženiu sa k stavu popisovaného spomenutým modelom, ktorý predstavuje efektívny spôsob automatického testovania softvéru. 7.1 Proces zostavovania a testovania aplikácie Zostavenie novej verzie aplikácie prebiehalo v krátkych časových intervaloch, približne každých 14 dní, s ciel om čo najrýchlejšej implementácie určitej funkcionality a jej uvedenia do používania ako aj opravenia objavených chýb. Každú novú verzia produktu bolo potrebné pred nasadením do prevádzky čo najdôkladnejšie otestovat. Proces testovania prebiehal na viacerých úrovniach, existovalo niekol ko verzií aplikácie: Lokálna kópia: každý programátor mal mal k dispozícii lokálnu verziu aplikácie, s ktorou pracoval počas procesu vývoja novej funkcionality, alebo opravy chýb. 47

59 Daily build : po procese zverejnenia aktuálnej verzie programového kódu v repozitári nasledovalo zostavenie aplikácie prostredníctvom CI servera, jednotkové testovanie, jej následné nasadenie a vykonanie integračných testov. Night build : server, ktorý bol automaticky zostavovaný a nasadzovaný každú noc, prebiehala na ňom okrem iného aj vybraná množina automatických testov užívatel ského rozhrania. Testovací server: primárny testovací server zostavovaný po rozhodnutí, že požadovaná funkcionalita je zavedená v repozitári, že všetky opravy chýb a nové funkcie sú implementované a je teda možné nasadenie novej verzie. Voči tomuto serveru prebiehajú všetky manuálne, automatické, ako aj zát ažové testy. V prípade dostatočného pokrytia aplikácie príslušnými testami je vysoká pravdepodobnost skorého odhalenia prípadnej chyby v aplikácii, chybu v riadiacej logike programu je odhalit krátko po odovzdaní finálnej verzie programového kódu do repozitára. Na to je však potrebné vytvárat a udržiavat množinu jednotkových testov. Na druhej strane, automatické testy užívatel ského rozhrania sú k dispozícii typicky už pred zahájením procesom manuálneho a d alších fáz testovania, umožňujú tak pomerne rýchlo odhal ovat prípadné chyby. Množina automatických testov tak tvorí aj súbor regresných testov, ktorých ciel om je odhal ovanie defektov po vydaní novej verzie, či vykonaní rôznych úprav. Stav, ked sa opakovane objavuje určitý typ chyby, nie je výnimočnou udalost ou v procese testovania softvéru tak dávajú prehl ad, že s novou funkcionalitou, či jej úpravou, sa do aplikácie nedostali rozličné defekty. 7.2 Kontrola výsledkov automatických testov Po vytvorení automatických testov a ich integrácie do procesu testovania je potrebná manuálna verifikácia výsledkov. Osoba poverená touto činnost ou pravidelne prechádza reporty automatických testov a overuje zlyhania automatických testov. V prípade, že je objavený neúspešný test, je potrebné skontrolovat dôvod a prípadne vykonat manuálne otestovanie daného testového scenára z dôvodu verifikácie danej chyby, nakol ko automatické testy užívatel ského rozhrania sa vyznačujú pomerne vysokým percentom falošných hlásení. 48

60 Obr. 7.1: Príklad reportu automatických testov. (zdroj: [18]) V prípade potvrdenia prítomnosti chyby nasleduje jej ohlásenie s ciel om jej odstránenia. Podobne ako v prípade manuálneho testovania, je potrebné posúdit reprodukovatel nost, závažnost a prioritu problému, popísat kroky vedúce k vyvolaniu danej chyby a prípadne poskytnút relevantné výstupy získané z automatických testov. V opačnom prípade je potrebné posúdit, či automatický test zlyhal z dôvodu rozličných technických problémov spojených s procesom testovania užívatel ského rozhrania, alebo ide o chybu v samotnom teste. Chyba v teste môže byt spôsobená rozličnými faktormi - zmenami návrhu, ale aj menšími zmenami v identifikátoroch, prípadne inými problémami týkajúcich sa testovacieho scenára, testovacích dát atd. Takýto test je predaný testerovi zodpovednému za tvorbu a úpravu automatických testov kvôli oprave a obnoveniu jeho funkčnosti. Zavedením serveru priebežnej integrácie je umožnené sledovanie rôznych trendových grafov, ako to ilustruje obrázok 7.2. Automatické testy užívatel ského rozhrania sa vyznačujú pomerne vysokou mierou falošných negatív, skončenie automatického testu chybou tak ešte nutne nemusí znamenat odhalenie defektu v zostavení aplikácie a automatické označenie celého buildu za chybné, je nutný proces manuálnej verifikácie. 7.3 Zát ažové a výkonnostné testy Okrem jednotkových, integračných testov a testov užívatel ského rozhrania prebiehal aj proces testovania aplikácie po stránke výkonu a zvládania zát aže. Tieto testy nie je jednoducho realizovatel né beh určitej formy automatizácie. Testy tak prebiehajú prostredníctvom skriptu, ktorý pracuje bez 49

61 Obr. 7.2: Prostredie CI serveru Jenkins s trendovým grafom vývoja počtu chýb. užívatel ského rozhrania, otvára vel ké množstvo relácií, otvára definované URL adresy a prípadne st ahuje určitý obsah zo servera. Takto je možné sledovat charakteristiky systému pod zát ažou. Obrázok 7.3 ilustruje výsledok behu jedného zo zát ažových testov. Porovnávaním s referenčnými vzorkami získanými z minulosti, ako aj analýzou výsledkov je možné detegovat prblémy s výkonom aplikácie. Tieto problémy sa môžu prejavovat rôzne, medzi najzávažnejšie prejavy patrí nedostupnost webu pri aj pomerne malej zát aži, prípadne problémy so stabilitou aplikácie. 7.4 Vyhodnocovanie výsledkov testov Prevádzka systému ohlasovania a sledovania odhalených chýb umožňuje rôzne štatistické spracovanie dát z databázy, čím umožňuje získanie prehl adu o vývoji počtu chýb, pomeru medzi otvorenými a vyriešenými chybami a podobne. Miesto vzniku chýb dokáže poukázat na rizikové oblasti aplikácie. Sledovanie chýb podl a typu testovacej aktivity, alebo spôsobe odhalenia, môže dopomôct v procese zefektívňovania postupov ich detekcie. Pre vedúcich pracovníkov zodpovedných za riadenie projektu sú zaujímavé ukazatele indikujúce priemerné časy potrebné na vyriešenie chyby, či uzavretie chyby, ktoré ukazujú na pružnost a efektívnost týmu. Tieto štatistiky by sa však nemali využívat na hodnotenie výkonnosti 50

62 Obr. 7.3: Príklad výstupu zát ažového testu. testerov, nakol ko spomenuté metriky neposkytujú objektívny pohl ad na túto problematiku. Počet odhalených chýb nieketorým z testov závisí od mnohých faktorov ako je zložitost testovnej funkcionality, kompletnost špecifikácie, miera prevencie chýb, schopnosti autora kódu a iných. Problémom je skutočnost, že do hodnotenia výkonnosti testerov podl a uvedených ukazatel ov vstupuje množstvo faktorov. Prípad, že tester objavuje mnoho chýb môže ukazovat na skutočnost, že si dobre plní svoju prácu, avšak podobne to môže ukazovat na nekvalitnú prácu vývojára[2, str. 203]. Obr. 7.4: Trend vývoja počtu chýb. Vyhodnotenie nasadenia automatických testov v spoločnosti oxy Online s.r.o. nie je jednoduché, nakol ko neustále prebiehal vývoj aplikácie a dochádzalo tak k rôznym zmenám v špecifikáciách. Vývoj automatických testov prebiehal postupne, s ciel om pokryt požadovanú funkcionalitu, čím neustále rozširujúca sa sada automatických testov vytvárala regresné testy, 51