MASARYKOVA UNIVERZITA FAKULTA}w¡¢£¤¥¦§¨  INFORMATIKY !"#$%&'()+,-./012345

Automatizácia funkˇcných testov s nástrojom Ranorex

DIPLOMOVÁ PRÁCA

Bc. Michal Tkáˇc

Brno, 2016 Prehlásenie

Prehlasujem, že táto diplomová práca je mojím pôvodným autor- ským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pra- mene a literatúru, ktoré som pri vypracovaní používal alebo z nich ˇcerpal,v práci riadne citujem s uvedením úplného odkazu na prí- slušný zdroj.

Bc. Michal Tkáˇc

Vedúci práce: Ing. Petr Adámek

ii Pod’akovanie

Rád by som sa pod’akoval vedúcemu práce, Ing. Petrovi Adámkovi, za cenné rady, ochotu a ˇcas,ktorý si na mˇnavždy pri tvorbe tejto diplomovej práce našiel. Takisto d’akujem kolegom za skvelý kolek- tív a pohodu pri každodennej práci.

iii Zhrnutie

Ciel’om tejto práce je zoznámenie sa s problematikou automatizá- cie funkˇcnýchtestov webových a desktopových aplikácií. Selenium a White sú aktívne využívané nástroje v procese automatizácie v spo- loˇcnostiEmbedIT a nástroj Ranorex je vhodný kandidát na ich nahra- denie. Všetky klady a zápory nástrojov sú podrobne zanalyzované a porovnané. Pre tento úˇcelboli implementované vhodné ukážkové príklady a na nich sú demonštrované rozdiely medzi jednotlivými nástrojmi.

iv Kl’úˇcovéslová

Funkˇcnétestovanie, automatizácia testov, užívatel’ské rozhranie, kon- tinuálna integrácia, webová aplikácia, desktopová aplikácia, Selenium, White, Ranorex.

v Obsah

1 Úvod ...... 3 2 Testovanie softvéru ...... 5 2.1 Validácia a verifikácia ...... 5 2.2 Testovacie metódy ...... 6 2.3 Manuálne vs. automatizované testovanie ...... 9 2.3.1 Kedy a preˇcoje automatizácia vhodná? . . . . . 11 2.3.2 Problémy automatizácie ...... 13 2.3.3 Údržba kódu a testov ...... 16 2.4 Testovanie v rámci životného cyklu softvéru ...... 17 2.4.1 V-model ...... 18 2.4.2 Typy testov ...... 20 2.4.3 Funkˇcnétestovanie ...... 22 3 Nástroje na automatizáciu funkˇcnýchtestov ...... 24 3.1 Selenium ...... 24 3.1.1 Selenium Remote Control (RC) ...... 25 3.1.2 Selenium IDE ...... 27 3.1.3 Selenium Grid ...... 29 3.1.4 Selenium WebDriver ...... 31 3.2 White ...... 37 3.3 Ranorex ...... 40 4 Ukážkové príklady ...... 45 4.1 Selenium ...... 45 4.1.1 Použité technológie ...... 45 4.1.2 Štruktúra projektu ...... 47 4.2 White ...... 48 4.2.1 Použité technológie ...... 48 4.2.2 Štruktúra projektu ...... 49 4.3 Ranorex ...... 51 4.3.1 Použité technológie ...... 52 4.3.2 Štruktúra projektu ...... 53 5 Porovnanie jednotlivých nástrojov ...... 56 5.1 Štruktúra projektu ...... 56 5.1.1 Existujúce riešenie ...... 56 5.1.2 Ranorex ...... 56 5.2 Kombinované testovanie ...... 57

1 5.2.1 Existujúce riešenie ...... 57 5.2.2 Ranorex ...... 57 5.3 Identifikácia elementov ...... 58 5.3.1 Existujúce riešenie ...... 58 5.3.2 Ranorex ...... 58 5.4 Spúšt’anie testov ...... 59 5.4.1 Existujúce riešenie ...... 59 5.4.2 Ranorex ...... 60 5.5 Reportovanie výsledkov ...... 60 5.5.1 Existujúce riešenie ...... 60 5.5.2 Ranorex ...... 62 5.6 Cena ...... 64 5.6.1 Existujúce riešenie ...... 64 5.6.2 Ranorex ...... 64 5.7 Zhrnutie ...... 65 6 Záver ...... 68 A Príloha ...... 72 A.1 Testovací scenár ...... 72

2 1 Úvod

Tak ako sa vesmírna raketa s posádkou nezaobíde bez všetkých bez- peˇcnostnýchprevierok a kontrol, tak ani softvér sa nezaobíde bez ˇconajdôkladnejšieho otestovania. Ako povedal Bill Gates pre online portál InformationWeek: „Máme tol’ko testerov, kol’ko máme vývojárov. A testeri trávia všetok svoj ˇcastestovaním a vývojári trávia polovicu ich ˇcasutestovaním. Sme viac organizácia zameraná na testovanie a kvalitu softvéru ako sme softvérová organizácia.“ [1] Tieto slová potvrdzujú, že pri vývoji softvéru treba vynaložit’ nemalé prostriedky na testova- nie jeho kvality. Samozrejme, pri testovaní nesmieme zabúdat’ ani na bezpeˇcnost’. Pretože ako vraví Gene Spafford: „Jediný systém, ktorý je naozaj bezpeˇcný,je ten, ktorý je vypnutý a odpojený, uzamknutý v titáno- vom trezore, pochovaný v betónovom bunkri a je obklopený nervovým ply- nom a vel’mi dobre platenou ozbrojenou ochrankou. Dokonca ani vtedy by som zaˇnnestavil svoj život.“ [2] To, že sa v softvéri nájde chyba, môže ušetrit’ nemalé finanˇcnéprostriedky, a dokonca aj nejeden l’udský život. Ciel’om tejto diplomovej práce je preštudovat’ nástroj Ranorex, ktorý slúži na automatizáciu funkˇcnýchtestov, následné zanalyzo- vanie a porovnanie tohto nástroja s už existujúcim riešením v spo- loˇcnostiEmbedIT a zistenie, ˇcije vhodný pre nahradenie aktuálnych riešení využívajúcich nástroje Selenium a White. Práca je rozdelená na dve ˇcasti. Prvá ˇcast’ (Kapitola 2) sa zaoberá teoretickými znalost’ami testo- vania, definovaním pojmov validácia a verifikácia, zoznámením ˇci- tatel’ov s druhmi testovacích metód, kde je dôraz kladený najmä na rozdiel medzi automatizovaným a manuálnym testovaním a nako- niec je predstavené testovanie v rámci životného cyklu softvéru. Na konci tejto kapitoly sú definované rôzne druhy testov, ktoré sa vy- užívajú v rámci životného cyklu softvéru. Druhá ˇcast’ (Kapitola 3 - 5) sa zaoberá nástrojmi na automatizáciu funkˇcnýchtestov. V kapitole 3 sa nachádza podrobný popis nástrojov Selenium, White a Ranorex. Prvé dva sú využívané v existujúcom riešení spoloˇcnostiEmbedIT a nástroj Ranorex je možný nástupca, ktorý by prevzal rolu automatizovania testov. Kapitola 4 prezentuje ukážkové príklady. Obsahuje použité tech-

3 1. ÚVOD nológie, ktoré sú potrebné na požadovanú funkˇcnost’ daného ná- stroja a popisuje štruktúru jednotlivých riešení. Dalšiaˇ kapitola (Kapitola 5) obsahuje porovnanie jednotlivých ná- strojov zamerané na štruktúru projektov, kombinované testovanie, identifikáciu elementov, spúšt’anie testov, reportovanie výsledkov tes- tov a nakoniec cenu, ktorá predstavuje náklady na automatizáciu s využitím automatizaˇcnýchnástrojov, prípadne doplnkových, ktoré sú pri danom nástroji nevyhnutné. V závere práce sú zhrnuté rozdiely a taktiež doporuˇcenie,ˇcije Ranorex vhodný na automatizáciu funkˇcnýchtestov v spoloˇcnosti EmbedIT. V prílohe sa nachádzajú iba kl’úˇcovéˇcastiimplementácie, pretože kompletné zdrojové kódy a skripty nemôžu byt’ zverejnené.

4 2 Testovanie softvéru

Testovanie je neoddelitel’nou súˇcast’ou vývoja softvéru v každej jeho fáze s ciel’om vytvorenia požadovaného, kvalitného a bezpeˇcného produktu. Podl’a ISTQB (International Software Testing Qualificati- ons Board) testovanie softvéru je [3]:

• proces spúšt’ania a pracovania s programom alebo aplikáciou s ciel’om nájdenia chyby alebo aj • proces validácie a verifikácie toho, že program alebo apliká- cia, alebo produkt: 1. sp´lˇnabiznisové a technické požiadavky, ktoré sprevá- dzali jeho dizajn a vývoj; 2. pracuje tak, ako je oˇcakávané; 3. môže byt’ naimplementovaný s rovnakou charakteristi- kou. V tejto kapitole je vysvetlené, ˇcoznamenajú pojmy validácia a ve- rifikácia, sú v nej zadefinované testovacie metódy a nachádza sa tu taktiež rozdelenie testov do jednotlivých kategórií.

2.1 Validácia a verifikácia

Tieto dva, na pohl’ad podobné pojmy, bývajú ˇcastozamenené. Aby sme tomu predišli, pod’me si ich zadefinovat’. Organizácia IEEE- SA (Institute of Electrical and Electronics Engineers Standards Asso- ciation) vypracováva globálne štandardy pre široké spektrum prie- myslu, zahrˇnujúceenergetiku, telekomunikácie, prepravu, biome- dicínu, zdravotnú starostlivost’, informaˇcnétechnológie, robotiku, automatizáciu domácností, nanotechnológiu a mnoho d’alších. Nie je formálne autorizovaná žiadnou vládou, ale je to komunita, ktorá každý rok vedie vyše 200 hlasovaní o štandardoch. Je to proces, pri ktorom sa hlasuje, ˇcidané návrhy štandardov sú technicky dôvery- hodné.

5 2. TESTOVANIE SOFTVÉRU

Podl’a štandardu IEEE 610, ktorý je slovník terminológie softvé- rového inžinierstva, sú tieto pojmy definované ako [4]:

• Validácia: proces vyhodnocovania softvéru s ciel’om overe- nia ˇciprodukt danej vývojovej fázy (pozn. autora: napríklad dokumentácia so špecifikáciou) sp´lˇnapodmienky, ktoré boli stanovené na zaˇciatkutejto fázy.

• Verifikácia: proces vyhodnocovania softvéru poˇcasalebo na konci vývojového procesu s ciel’om overenia, ˇcisp´lˇnašpecifi- kované požiadavky.

Zjednodušene, validácia teda overuje, ˇcivytvárame správny pro- dukt (odpovedajúci požiadavkám) a verifikácia, ˇcivytvárame pro- dukt správne (odpovedajúci špecifikácii). Ciel’om týchto dvoch poj- mov je odhalit’ chyby poˇcasvývoja a preukázat’ požadované vlast- nosti, pretože test, ktorý neodhalí nesprávne správanie sa systému, je neúspešný.

2.2 Testovacie metódy

V procese testovania sa dajú použit’ rôzne metódy. Patria do rôz- nych kategórií, z ktorých sa niektoré dajú medzi sebou kombinovat’. Prvou takouto kategóriou je rozdelenie testovania z hl’adiska zdro- jového kódu, kde patria nasledujúce metódy [5]:

• Statická: Je to revízia, kontrola samotného zdrojového kódu. Castoˇ bý- va implicitná, pretože sa nachádza priamo v programovacích nástrojoch alebo textových editoroch na kontrolu štruktúry zdrojového kódu a v kompilátoroch na kontrolu syntaxe ako statická programová analýza. Patria sem nástroje ako PMD, Findbugs, Checkstyle, ale aj revízia kódu (code review).

• Dynamická: Testuje vlastnosti systému poˇcasjeho behu. Môže byt’ vyko- návaná aj vtedy, ak ešte nie je celý softvér naimplementovaný s ciel’om overenia funkˇcnostijednotlivých ˇcastí— modulov.

6 2. TESTOVANIE SOFTVÉRU

Druhá kategória predstavuje rozdelenie metód z hl’adiska prí- stupu k informáciám na [6]:

• Black box (ˇciernaskrinka): Pri tejto metóde nemáme žiadnu znalost’ o tom, ako vyzerá a pracuje vnútro aplikácie. Tester pozná systémovú architek- túru, ale nemá prístup k zdrojovému kódu. Typicky teda in- teraguje s užívatel’ským rozhraním zadávaním vstupov a vy- hodnocovaním výstupov bez toho, aby vedel, ako vstupy pro- gram spracovával. Najväˇcšímivýhodami tejto metódy je, že program môže mat’ akokol’vek vel’a riadkov, tester sa v nich nebude musiet’ zorientovávat’. Je tu aj výhoda jasne defino- vaných užívatel’ských rolí, ked’ testeri nemajú pohl’ad na pro- gram ako vývojár a môže ich byt’ vel’ké množstvo, pretože nemusia vediet’ programovat’. Staˇcí im len znalost’, ako pro- gram pracuje zvonku. Táto metóda má aj nevýhody, ako na- príklad neefektívne testovanie, lebo tester má len limitované poznatky o celej aplikácii a pokrytie validácie programu na- slepo, pretože sa nemôže zamerat’ na konkrétne riadky kódu.

• White box (biela skrinka): Zameriava sa na detailné preskúmanie internej logiky a štruk- túry kódu. Tester potrebuje poznat’ nielen ako program fun- guje, ale aj preˇcotak funguje. Musí mat’ prehl’ad o celej apli- kácii z vonkajšej aj z vnútornej perspektívy. Je to kvôli tomu, aby zistil, ktorá ˇcast’ kódu sa nespráva tak, ako sa má. Me- dzi výhody tejto metódy patrí efektívnejšie otestovanie ap- likácie, pretože tester tým, že pozná kód, vie, na ktorú ˇcast’ programu sa má zamerat’ a aké sú najvhodnejšie dáta. To napomáha tomu, aby pokryl ˇconajväˇcšiuˇcast’ funkcionality scenármi. Náklady na jedného testera sú ale v prípade tejto metódy zvýšené. Už nestaˇcíobyˇcajnýužívatel’ s vedomos- t’ami o tom, ako má program fungovat’, musí mat’ aj znalosti z programovania a analytické myslenie. Dalšouˇ nevýhodou je obtiažnejšie udržiavanie aktuálnosti scenárov.

• Grey box (šedá skrinka): Táto metóda kombinuje benefity tých predošlých. Tester má

7 2. TESTOVANIE SOFTVÉRU

len limitovanú predstavu o tom, ako program interne fun- guje. Na druhej strane má ale prístup k dokumentácii a da- tabáze. Vd’aka tomuto môže pripravit’ a použit’ lepšie testo- vacie dáta a scenáre. Môže ich aj porovnat’ s databázou, ˇcisa v užívatel’skom rozhraní správne prezentujú a naˇcítavajúna- príklad z ˇcíselníkov. Výhodami teda sú jednoduchšie orien- tovanie sa v aplikácii vzhl’adom na prístup k dokumentácii a databáze, detailnejšie a viac cielenejšie testovacie scenáre na kl’úˇcovévlastnosti systému a hlavne napomáha k udržaniu hranice medzi testerom a vývojárom. Možnost’ prístupu ku kódu je limitovaná, a teda nemôžeme skontrolovat’ priamo zdrojový kód, ako je daná funkcionalita naimplementovaná. Takisto aj testovanie každého možného vstupu je nereálne, pretože by zabralo viac ˇcasu,ako je akceptovatel’né. Aj na- priek týmto pár spomenutým nevýhodám sa použitie danej metódy odporúˇcahlavne pri testovaní webových aplikácií. Naopak, neodporúˇcasa pri validácii algoritmu. Kombinácia týchto dvoch kategórií nám ponúkne nasledovné po- stupy [7]: • Statické testovanie typu black box: Ide o revíziu dokumentácie, ktorá môže pochádzat’ z rôz- nych zdrojov, napríklad užívatel’ských štúdií alebo obchod- ných požiadaviek. • Statické testovanie typu white box: Dôkladne sa kontroluje dizajn a kód aplikácie práve vtedy, ked’ je statická, nespustená. • Dynamické testovanie typu black box: Testovanie aplikácie bez znalosti jej zdrojového kódu. Dôraz sa kladie na korektnú transformáciu vstupov na požadované výstupy. • Dynamické testovanie typu white box: Ciel’om tejto kombinácie metód je zistenie chyby v aplikácii poˇcasjej behu a so znalost’ou zdrojového kódu. Tretia kategória rozdel’uje metódy podl’a formy vykonávania na [8]:

8 2. TESTOVANIE SOFTVÉRU

• Manuálne: Ak je test vykonávaný ˇclovekom,kde je potrebný l’udský úsu- dok alebo rôzne prístupy, ktoré nie je potrebné zaznamenat’ a pravidelne opakovat’.

• Automatizované: Vykonávané softvérom, opakované spúšt’anie vel’kého množ- stva testov alebo testov s vel’kým množstvom generovaných dát. Automatizáciu je možné použit’ aj pri preverovaní zá- t’aže systému.

Metódy v tejto kategórii boli vysvetlené len struˇcne.Ked’že auto- matizácia je hlavnou témou tejto diplomovej práce, sú podrobnejšie vysvetlené v nasledujúcej podkapitole (Podkapitola 2.3).

2.3 Manuálne vs. automatizované testovanie

Mnoho l’udí sa môže domnievat’, že na to, aby zaˇcaliautomatizovat’ testy, im staˇcíkúpit’ alebo stiahnut’ obl’úbený automatizaˇcnýnástroj a nahrat’ jednotlivé testy v podobe krokov ich scenárov. Myslia si, že to im zaruˇcímožnost’ spúšt’at’ ich opakovane kedykol’vek. Realita je ale ovel’a odlišnejšia a v praxi to takto nefunguje. Tak ako vývojár musí poznat’ teóriu, ako naprogramovat’ softvér správne a efektívne, tak aj automatizácia si vyžaduje poznat’ tento proces lepšie a hlbšie, ako len zvládnut’ používat’ niektorý nástroj. Pozrime sa najprv na manuálne testovanie. Je to zruˇcnost’, ktorú musí mat’ ˇclovekpracujúci v tomto odbore. Pri overení funkˇcnosti programu existuje neskutoˇcnevel’a možných scenárov, no je na uvá- žení testera, ktoré scenáre sa reálne budú kontrolovat’, aby bola efek- tívne a dostatoˇcnepokrytá validácia funkcionality softvéru. Ja sám som sa pri pohovoroch na testerské pozície stretol s tro- chu netradiˇcnýmiotázkami, ktorých ciel’om bolo overit’, ˇcidisponu- jem touto zruˇcnost’ou. Jednou z nich bola otázka, ako zistím, ktorý z troch vypínaˇcovpred uzavretou miestnost’ou patrí ktorému z troch svetiel v miestnosti, ak sa môžem dovnútra pozriet’ len raz po za- pnutí vypínaˇcov. Riešenie je také, že ˇclovekmusí rozmýšl’at’ aj nad inými vlast- nost’ami svetiel, ako je napríklad teplo. Ak prvý vypínaˇczapneme

9 2. TESTOVANIE SOFTVÉRU na pár minút a potom ho vypneme, d’alší zapneme a tretí necháme vypnutý, ked’ vojdeme do miestnosti, tak hned’ vieme, že druhý vy- pínaˇc,ktorý sme zapli, patrí svetlu, ktoré svieti. Zostáva nám teda priradit’ k svetlám prvý a tretí vypínaˇc. Ak ˇclovekpristupuje k problematike aj z iného pohl’adu, vypí- naˇc,ktorý bol minútu zapnutý, svetlo zohrial. Takže to, ktoré je teplé, bude patrit’ prvému vypínaˇcu. Naopak, automatizované testovanie je tiež zruˇcnost’, ale vel’mi odlišná od manuálneho. Každý jeden scenár, ktorý zvažujeme auto- matizovat’, musí byt’ podrobený dôkladnej analýze, ktorá zistí, ˇcije na to vhodný. Kvalita zautomatizovania ale nie je závislá na kvalite testu [9]. To, ˇcije test vykonávaný jedným, alebo druhým spôsobom, neovplyvˇnujejeho efektivitu ani jeho výstižnost’. Nezáleží na tom, ako dokonale ho zautomatizujeme, pretože ak samotný test niˇcne- overuje, tak aj výsledok po automatizácii, niˇcrýchlejšie neoverí. Au- tomatizáciu ovplyvˇnujeiba to, ˇcije ekonomickejšie nevykonávat’ test manuálne a ako rýchlo sa scenár vyvíja. Je zbytoˇcnéimplementovat’ testy, ak sú spustené len párkrát, pretože ˇcasvenovaný ich napro- gramovaniu by bol ovel’a dlhší ako manuálne overenie.

Obr. 2.1: Keviatov diagram [9]

Na obrázku 2.1 je pomocou Keviatovho diagramu znázornená závislost’ vyššie uvedených vlastností testov. Sú to efektivita, výstiž-

10 2. TESTOVANIE SOFTVÉRU nost’, ekonomickost’ a vývojovost’ scenára. Címˇ je väˇcšiamiera vlast- ností, tým je aj oblast’ nachádzajúca sa medzi spojenými ˇciaramiväˇc- šia, ˇcoznaˇcí,že je lepšia jedna alebo druhá metóda testovania. Clovek,ˇ ktorý vytvára automatizované testy, môže, ale nemusí byt’ samotný tester. Spoloˇcnost’ môže paralelne zamestnávat’ dva tími l’udí, jedni sú testeri a druhí vývojári automatizovaných tes- tov. Clenoviaˇ druhej skupiny nemusia mat’ až takú mieru vedomostí o aplikácií ako testeri, pretože tí im robia podporu. Vytvárajú im sce- náre, starajú sa o ne a pomáhajú im s problémami, ktoré sa môžu vyskytnút’. Tak ako miera kvality testovania závisí od kvality a skúseností testerov, tak aj kvalita automatizácie závisí od zruˇcnostíjej vývojá- rov. Tí musia mat’ k dispozícii nástroj, ktorým budú môct’ ˇconaj- jednoduchšie a najdôkladnejšie pokryt’ verifikáciu aplikácie. Imple- mentácia musí byt’ prehl’adná, aby sa v nej ˇconajrýchlejšie zoriento- val prípadný nový ˇclentímu, ale hlavne, aby údržba scenárov bola ˇconajjednoduchšia. Prípadná zmena v niektorom scenári, ktorá sa musí premietnut’ už aj v zautomatizovanom teste, môže byt’ upra- vená vel’mi rýchlo, no pri nevhodnej štruktúre a procese automati- zácie sa môže stat’ vel’mi nákladnou. Ak sa procesu implementácie automatizovaných testov nebude klást’ dostatoˇcnámiera pozornosti, môže sa stat’, že tento proces sa po ˇcasestane viac nákladnejším.

2.3.1 Kedy a preˇcoje automatizácia vhodná? Automatizované testy môžu ušetrit’ vel’mi vel’a ˇcasu,zdrojov, ale aj nemalé finanˇcnéprostriedky. V nevhodných prípadoch použitia ale môže dôjst’ k opaˇcnémuefektu a nemusí sa vôbec oplatit’. V nasledu- júcich bodoch sú uvedené príklady, kedy je automatizácia vhodnejšia ako manuálne testovanie [9]:

• Nové prostredie na testovanie: Hned’ ako vývojári poskytnú nové prostredie na testovanie, musia všetky regresné testy zverifikovat’ ˇciaplikácia funguje správne. Až potom je možné, aby bola posunutá do d’alšej vývojovej fázy. Na to, aby sme všetky regresné testy vykonali manuálne, potrebujeme v závislosti na ich poˇcteprimeraný

11 2. TESTOVANIE SOFTVÉRU

poˇcettesterov. Ak ale máme tieto regresné scenáre zautoma- tizované už pre predošlú verziu aplikácie, hned’ po dodaní nového prostredia môžu byt’ spustené a vyhodnotené do nie- kol’kých hodín. • Castejšieˇ a poˇcetnejšietestovanie: Azda najväˇcšímbenefitom automatizácie je možnost’ vyko- návat’ viac testov za kratší ˇcasako manuálne a to taktiež zaru- ˇcuje,že sa môžu spúšt’at’ ovel’a ˇcastejšie.Vždy, ked’ je to po- trebné, si ich, napríklad, môže na vyžiadanie nechat’ spustit’ vývojár, aby si overil, ˇcipridanie nového kódu, alebo zmena pôvodného neovplyvnili ostatnú funkˇcnost’ aplikácie. • Nemožnost’ vykonat’ test manuálne: Pri manuálnom testovaní sa testeri zameriavajú na oˇcividné veci, ktoré sú im viditel’né. Ak sa ale na pozadí akcie vyko- náva ešte d’alšia, toto môžu skontrolovat’ iba automatizované testy. Taktiež by, napríklad, bolo nereálne, aby tester vytvoril v rovnakom ˇcase súˇcasne100 zmlúv. Toto sa ale dá docielit’ nástrojmi, ktoré týchto 100 užívatel’ov nasimulujú. • Lepšie využitie zdrojov: Dokola sa opakujúce scenáre, ktoré by mali testeri manuálne otestovat’, je lepšie nahradit’ zautomatizovanými. Testeri sa tak vyhnú nudným scenárom a môžu sa lepšie a hlbšie zame- rat’ na ostatné veci, ako napríklad revalidácii alebo vytvára- niu nových scenárov. Stroje, ktoré by boli inak cez noc neak- tívne, môžu spúšt’at’ testy a pracovat’ „zadarmo“. • Konzistencia pri opakovaní testov: Automatizované testy majú zaruˇcené,že minimálne vstupy sú vždy rovnaké. Výstupy sa môžu líšit’ v závislosti na apli- kácii, ak sa, napríklad, vyskytne dlhšie naˇcítavanieelementu. Majú teda urˇcitúmieru konzistencie, ˇcosa pri manuálnych testoch zaruˇcit’ nedá. Testy sa môžu vykonávat’ aj multiplat- formne, ˇcoopät’ nemôže zaruˇcit’ konzistenciu tých manuál- nych. • Znovupoužitie zautomatizovaných testov: Pri implementácii automatizovaných testov sa urˇcitemno-

12 2. TESTOVANIE SOFTVÉRU

hokrát stretneme s použitím a znovuvyužitím už existujú- ceho kódu. Preto je potrebné, aby štruktúra bola navrhnutá správne a aby kód bol maximálne prehl’adný. Taktiež aj ma- nuálne testy sa ˇcastoopät’ používajú, preto aj u nich je dôle- žité, aby boli spol’ahlivé. V tomto prípade ale dochádza k ove- l’a nižšiemu výskytu opätovného použitia ako pri automati- zácii.

• Kratší ˇcasna nasadenie do produkcie: Ked’ sú testy naimplementované, je možné ich ovel’a rýchlej- šie vyhodnotit’ ako tie manuálne. To nám dáva možnost’ skrá- tit’ d´lžku regresného testovania, a tým pádom aj skoršieho nasadenia do produkcie.

• Zvýšená dôveryhodnost’ výsledkov: Ak sú automatizované testy naimplementované správne a tes- tujú tú funkcionalitu, ktorú majú, zvyšuje to istotu, že všetky, ktoré prebehli správne, potvrdzujú správnost’ aplikácie a ne- vyústia k neoˇcakávanýmchybám, ktoré sa môžu objavit’ v na- sledujúcom životnom štádiu vývoja aplikácie.

2.3.2 Problémy automatizácie Nie každý jeden manuálny test môže byt’ automatizovatel’ný. Ako bolo spomenuté už v porovnaní, každý jeden scenár musí byt’ vel’mi dobre preverený, ˇcije vhodný k automatizácii. Medzi ˇcastéprob- lémy, ktoré sa pri tomto procese vyskytujú a ústia do neúspechu au- tomatizácie, patria nasledovné príklady:

• Nereálne oˇcakávania: V odvetví automatizácie sa v posledných rokoch objavilo mno- ho nástrojov, ktoré sl’ubujú, že práve ony dokážu všetko, sú tie najlepšie a pre ne sa treba rozhodnút’. Manažéri pri výbere ˇcastopodl’ahnú reklame daného nástroja, no ked’ ho automa- tizaˇcnýtím vyskúša, ˇcije pre ich potrebu dostaˇcujúci,je vel’ká pravdepodobnost’, že v mnohých prípadoch bude neposta- ˇcujúci.Je teda nevhodné mysliet’ si, že nástrojom sa bude dat’ úplne všetko zautomatizovat’ [9].

13 2. TESTOVANIE SOFTVÉRU

• Slabá testovacia prax: Ak uvažujeme nad vytvorením automatizaˇcnéhotímu, kto- rý bude implementovat’ existujúce scenáre, ktoré sú vel’mi chabé a už samotné manuálne testy vel’mi t’ažko odhal’ujú chyby a slabiny aplikácie, je nevhodné nad touto možnost’ou premýšl’at’. Lepšie riešenie je dat’ scenáre do poriadku a po- silnit’ verifikáciu programu v tomto smere, pretože: „automa- tizovanie chaosu iba vytvára ešte väˇcšíchaos“ [9].

• Oˇcakávanienájdenia množstva nových chýb: Dobrý test by mal nájst’ chyby už pri prvom spustení. Po oprave tejto chyby sa ale nová nájde s menšou pravdepodob- nost’ou, pretože kroky testu sa nemenia. Preto sa týmto spô- sobom nájde ovel’a menej nových chýb, ktoré sa v aplikácii môžu vyskytnút’ [9].

• Chybný pocit bezpeˇcnosti: Ked’ automatizované testy nenájdu žiadnu chybu, nezname- ná to, že žiadna sa v aplikácii nevyskytuje. Samotné testy môžu byt’ chybné, neúplné alebo sa nemusia zameriavat’ na tú konkrétnu ˇcast’ programu, ktorá chybu obsahuje. Ak sa teda chyba v programe nachádza a zlé testy ju neodhalia, máme falošný pocit správnosti aplikácie a chyby môžu byt’ odhalené, ked’ už bude neskoro [9].

• Údržba automatizovaných testov: Vždy, ked’ sa softvér men, ˇciuž zásadnou zmenou, alebo len menšími zásahmi v rámci vývojového cyklu, na automatizo- vaných testoch sa vždy musí vykonat’ údržba, aby sa zme- nám prispôsobili. Ak ˇcasstrávený údržbou prevyšuje ˇcaspo- trebný na manuálne otestovanie aplikácie, automatizácia je neefektívna a, pravdepodobne, bude zrušená. V mojom tíme je zaužívané, že na údržbu je vyˇclenených20% z každého pracovného dˇna.Na základe toho sa potom vypoˇcítavajúod- hady, kol’ko pracovných dní zaberie zautomatizovanie no- vých scenárov [9].

• Technické problémy: Všetky komerˇcnénástroje na automatizáciu sú tiež len apli-

14 2. TESTOVANIE SOFTVÉRU

kácie, ktoré samy môžu obsahovat’ skryté chyby. Tie sa sna- žia byt’ opravované v aktualizáciách, no opät’ sa môžu vy- skytnút’ nové chyby. Dalšímˇ príkladom je aj nekompatibi- lita nástroja s vyvíjanou aplikáciou alebo s programami tre- tej strany, ktoré môžu byt’ nevyhnutné k používaniu v rámci automatizácie [9].

• Organizaˇcnéproblémy: Ked’že automatizácia nie je triviálny proces, jedným z mož- ných problémov, ktoré sa môžu vyskytnút’, je problém orga- nizácie. Vedenie spoloˇcnostimusí automatizáciu plne podpo- rovat’ a musí byt’ zakomponovaná aj do koreˇnovorganizácie. Musí jej byt’ vyˇclenenýdostatoˇcnýˇcasna výber vhodného ná- stroja, na experimentovanie a uˇceniesa novým veciam [9].

• Nestabilný dizajn: Niektoré aplikácie môžu mat’ vel’mi nestabilný dizajn, na- príklad tie, ktoré využívajú dáta získavané v reálnom ˇcase. Pokial’ nemôžeme zaistit’ simulovanie výpoˇctovna základe vstupov, automatizácia takejto aplikácie bude vel’mi obtiažna, pretože nepoznáme výstupy, voˇciktorým má byt’ aplikácia kontrolovaná. Ak nepoznáme testovací environment a dáta aplikácie, automatizácia bude tiež takmer nereálna. Záleží aj od miery konfigurácie produktu, na základe ktorej sa mení dizajn. Ak je vel’mi premenlivý, môžeme nasimulovat’ nie- ktoré konfigurácie, ale naimplementovanie všetkých možnos- tí by boli vel’mi nereálne, pretože by to vyústilo v komplexný projekt, ktorý bude mat’ vel’kú mieru údržby [10].

• Neskúsení testeri: Ak nie sú vývojári automatizovaných testov dostatoˇcneobo- známení s aplikáciou, nie je vel’mi efektívne ich využitie na projekte, pretože testy, ktoré vytvoria, budú len také dobré, akí sú dobrí ich tvorcovia. Taktiež noví ˇclenoviatímu by mali byt’ najskôr manuálni testeri, pretože je viac pravdepodobné, že budú robit’ rovnaké chyby ako užívatelia. Automatizácia by mala byt’ vyhradená pre expertov [10].

15 2. TESTOVANIE SOFTVÉRU

• Doˇcasnítesteri: Pokial’ je plánované do procesu automatizácie nasadit’ nie- ktorých l’udí iba doˇcasne,nie je to dobrý nápad, pretože po- ˇciatoˇcnáinvestícia v podobe školení a ich tréningu bude zby- toˇcná.Ovel’a lepšie je použit’ ich ako manuálnych testerov, priˇcomtrvalých zamestnancov zaradíme do tvorby automa- tizácie [10].

• Nepostaˇcujúciˇcasa zdroje: Ak potrebný ˇcasna manuálnu verifikáciu aplikácie prevyšuje dostupný ˇcas,alebo nie je dostatok zdrojov, netreba oˇcakávat’, že automatizácia pomôže. Poˇciatoˇcnáinvestícia na plánova- nie, školenie a implementáciu zaberie z krátkodobého hl’a- diska viac ˇcasu,ako môže ušetrit’ [10].

2.3.3 Údržba kódu a testov Tak ako sa vývoj aplikácie nezaobíde bez dobrého implementaˇcného návrhu, tak ani automatizované testy sa nezaobídu bez dobrej štruk- túry projektu v ktorom sa vytvárajú a bez jednoduchého a prehl’ad- ného kódu. Nasledujúce príklady opisujú, na ˇcoje potrebné mysliet’ už od zaˇciatkuautomatizácie [10]:

• Úrdžba aplikácie je vykonávaná nepretržite: Ked’že vyvíjaný softvér sa stále mení, pribúda nová a mení sa už hotová funkcionalita, je potrebné mysliet’ na alokova- nie dostatoˇcnéhoˇcasuna údržbu existujúcich testov. Bez nej by sa po zmene funkcionality automatizované testy stali bez- významné riadky kódu, ktoré by niˇcnetestovali a ˇcasstrá- vený ich vytváraním by bol zbytoˇcný.

• Zmeny musia byt’ vopred známe: Potreba informovania o zmenách vopred je vel’mi nevyhnut- ná. Ak sa zmeny zistia poˇcaspriebehu testov, nemusí íst’ nut- ne o novú funkcionalitu, ale môže íst’ o chybu. Preto je po- trebné konzultovat’ tieto zmeny s kompetentnými osobami ˇconajskôr, aby sme si boli istí, že testy sú na novú alebo zme- nenú funkcionalitu pripravené.

16 2. TESTOVANIE SOFTVÉRU

• Krížová referencia testovacích scenárov: Pre lepšiu štruktúru a prehl’ad je potrebné používat’ konzis- tentné názvy tried a metód pre prípad, že by sme k nim potre- bovali pristupovat’ a využívat’ ich v rámci d’alšieho scenára. Potom sa v prípade zmeny jednej ˇcastibudú dat’ rýchlo vy- hl’adat’ jej referencie a môžu byt’ upravené d’alšie scenáre.

• Plánovanie v rámci prevencie výskytu nových chýb: Nie je dôležité iba vediet’ l’ahko nájst’ a vykonat’ zmeny v kó- de, ale aj zaistit’, že zmenami sa neovplyvnia aj d’alšie testy. Ak by sme, napríklad, naimplementovali identifikáciu ele- mentov jednotlivých formulárov prostredníctvom súradnico- vého systému, pri zmene formulára by sa tieto súradnice, pravdepodobne, zmenili a už by pozície elementov nesúhla- sili. Je potrebné mysliet’ na ˇconajvšeobecnejší návrh, ktorý by v prípade zmeny nevyústil k nefunkˇcnostimnožstva d’alších testov.

Princípy a skúsenosti, ktoré boli vyššie popísané, by mali jasne definovat’, kedy je automatizácia výhodnejšia oproti manuálnemu testovaniu.

2.4 Testovanie v rámci životného cyklu softvéru

Podl’a ISTQB výkladového slovníka [11] softvérový životný cyklus je: „Casovᡠperióda, ktorá zaˇcínavtedy, ked’ je softvérový produkt zapo- ˇcatý,a konˇcí,ked’ softvér už viac nie je k používaniu dostupný. Softvérový životný cyklus typicky zahrˇnujekoncepˇcnúfázu, štádium definovania po- žiadaviek, dizajnovú fázu, implementaˇcnúfázu, testovaciu fázu, inštalaˇcnú a skúšobnú fázu, operaˇcnúa udržiavaciu fázu a obˇcasvýsluhovú fázu. Tieto štádiá sa môžu prekrývat’ alebo byt’ vykonávané iteratívne.“ Aby sme mohli garantovat’ funkˇcnýsoftvér, ktorý bol vyvinutý na základe poˇciatoˇcnýchpožiadaviek, musíme pochopit’, že testova- nie musí byt’ zaintegrované do životného cyklu softvéru. Toto platí vždy, ˇciuž ide o cyklus sekvenˇcný,inkrementálny, iteratívny alebo špirálový. Vždy musí byt’ dodržané striktné definovanie a dodržia- vanie testovacích a ostatných procesov. Pozrime sa na to, ako fungujú nasledovné dva príklady.

17 2. TESTOVANIE SOFTVÉRU

Prvý je model sekvenˇcnéhoživotného cyklu. Kl’úˇcovýpredpo- klad v tomto prípade je, že požiadavky sú definované v zaˇciatkoch projektu a následne sú zmeny týchto požiadaviek po zvyšok vývoja limitované. Ked’že týchto požiadaviek sa vývoj musí držat’, nezá- vislý testovací tím môže použit’ analýzu na vytvorenie ˇconajlepšej testovacej stratégie. Ak by poˇcastohoto štádia zistili nezrovnalosti v požiadavkách, upozornili by na to a analytici by vykonali nápravu. Konajú teda preventívne, chyby aplikácie sa objavia až pri d’alšej fáze, ked’ zaˇcnúsystémové testy. Druhý model predstavuje inkrementálny životný cyklus, v kto- rom môžeme použit’ jednu z agilných metodológií, napríklad Scrum. V tomto prípade testerský tím nemusí nikdy dostat’ kompletný zo- znam požiadaviek. Namiesto toho obdržia zoznam požiadaviek na zaˇciatkukaždého sprintu, ktorý trvá typicky 4-6 týždˇnov. Vždy sa teda zamerajú na urˇcitúoblast’, ktorú budú poˇcassprintu testovat’. Chyby v aplikácii sú teda schopní detekovat’ vel’mi skoro, už na konci prvého cyklu. Nezáleží na tom, aký životný cyklus použijeme, no hlavne to platí pre agilný vývoj, je potrebné mat’ dobre zvládnutý manažment zmien. Ak sa zavedie nejaká zmena, je potrebné aby, sa premietla aj do testov.

2.4.1 V-model Na obrázku 2.1 je znázornený diagram rozdelenia jednotlivých tes- tovacích vrstiev systému poˇcasjeho vývoja. Tento model sa používa pri sekvenˇcnomživotnom cykle. Ked’že má tvar písmena V, dostal aj príznaˇcnýnázov. Môžeme na ˇnomvidiet’, že testovací tím sa podiel’a na projekte už od jeho zaˇciatku.Jednotlivé vrstvy modelu si môžeme rozdelit’ nasledovne [11]:

• Testovanie súˇciastok(jednotkový test): Verifikuje funkcionalitu špecifickej, malej ˇcastikódu na úrov- ni metód, tried, objektov. Zameriava sa na testovanie týchto ˇcastíz pohl’adu izolovaných komponentov. Je to typ testov, ktoré sú obvykle písané samotnými programátormi v rámci práce na kóde, aby sa uistili, že požadovaná funkcia pracuje tak, ako má. Jedna funkcionalita môže mat’ viacero testov

18 2. TESTOVANIE SOFTVÉRU

Obr. 2.2: V-model

z dôvodu zachytenia ˇconajviac hraniˇcnýchprípadov. Samo o sebe nemôže zverifikovat’ kompletnú funkcionalitu soft- véru, ale je používané na uistenie, že jednotlivé komponenty pracujú nezávisle. Ked’že ich väˇcšinouvykonávajú develo- peri, chyby sa nemusia reportovat’, ale môžu byt’ hned’ od- stránené.

• Integraˇcnétestovanie: Je fáza, v ktorej sa spájajú jednotlivé moduly a testujú sa ako skupina, ˇcinavzájom správne fungujú. Jej ciel’om je zverifi- kovat’ funkˇcnost’, výkonnost’ a spol’ahlivost’ aplikácie. Odha- l’uje chyby v rozhraniach, zlú komunikáciu medzi modulmi, operaˇcnýmsystémom a modulmi, hardvérom alebo rozhra- niami jednotlivých systémov.

• Systémové testovanie: Overuje, ˇcisystém funguje ako celok a správne pracuje so sys- témom. Verifikuje aplikáciu z pohl’adu zákazníka podl’a pri- pravených scenárov. Simulujú sa nimi jednotlivé kroky, ktoré môžu v praxi nastat’. Obvykle sa vykonávajú vo viacerých

19 2. TESTOVANIE SOFTVÉRU

cykloch, priˇcomchyby, ktoré boli odhalené, sa vždy zadajú do reportovacieho nástroja a v d’alšom cykle sa testujú opät’, ˇciboli správne opravené. Bez tejto úrovne testov by sa neza- obišiel žiadny vývoj a na ich realizáciu by sa malo mysliet’ ˇco najskôr. Výsledky týchto testov slúžia ako výstupná kontrola pred uvol’nením softvéru zákazníkovi.

• Akceptaˇcnétestovanie: Je proces, pri ktorom sa kladie väˇcšídôraz na to, ˇciapliká- cia funguje podl’a zákazníkových predstáv a umožˇnujemu vykonávat’ požadované operácie, ako na odhal’ovanie chýb. Klient overí a zdokumentuje výsledky kontrol. Ak boli úspeš- né, je pripravený vyvinutý softvér akceptovat’.

2.4.2 Typy testov Pre dôkladné overenie plnej funkˇcnosticelého systému, ktorý je vy- vinutý s ˇconajmenšou možnou pravdepodobnost’ou vyskytnutia sa chýb u zákazníka, alebo, napríklad, aj nezvládaniu jej behu na ur- ˇcitomsystéme, sa v rámci testovacích vrstiev vykonáva ovel’a viac podrobnejších a špecifickejších testov, ako napríklad [12]:

• Smoke test: Skladá sa z jednoduchých testov, ktoré overia základnú fun- kcionalitu aplikácie, funkˇcnost’ webových služieb alebo ko- munikáciu s databázou, aby sa zistilo, ˇcije pripravená na d’alšie, h´lbkové testovanie. Jeho beh má byt’ ˇconajrýchlejší a obvykle je automatizovaný. To umožˇnujejeho spustenie au- tomaticky, hned’ po nasadení novej verzie aplikácie. Na zá- klade jeho výsledkov sa môže bud’ pokraˇcovat’ v h´lbkovom testovaní, alebo sa musí príˇcinapádu testu odstránit’.

• Regresný test: Odhal’uje chyby, ktoré mohli nastat’ po naimplementovaní novej funkcionality. Týmito testami sa overí, ˇcistará funkci- onalita zostala bez zmeny a funguje rovnako. Kontroluje sa nimi taktiež to, ˇciboli korektne opravené staré chyby, alebo sa náhodou opät’ neobjavili. H´lbka týchto testov záleží na fáze vývoja a na vel’kosti zásahu do vyvíjaného softvéru. Môžu

20 2. TESTOVANIE SOFTVÉRU

byt’ vykonávané vo viacerých cykloch v rámci jedného vý- voja alebo sprintu. Preto sa ˇcastoautomatizujú, aby sa skrá- til ˇcasich behu, a teda celého ich vyhodnotenia, a môžu byt’ spustené tak ˇcasto,ako je potrebné.

• Inkrementálny integraˇcnýtest: Vykonáva sa po tom, ako je k už existujúcim a otestovaným modulom pridaný d’alší.

• Test obnovy: Úˇcelomtohoto testu je zistenie, ˇcije vôbec možné obnovit’ aplikáciu po páde systému a aká dlhá doba je na to potrebná. Pád programu môže nastat’, napríklad, po výpadku elektriny, hardvérovej chybe alebo d’alšej neoˇcakávanejˇcinnosti.

• Bezpeˇcnostnýtest: Má za úlohu odhalit’ prípadné bezpeˇcnostnédiery v systéme, ktoré by mohli narušitelia alebo užívatelia zneužit’ k získa- niu citlivých dát. Každý systém musí sp´lˇnat’ šest’ základných bezpeˇcnostnýchkonceptov, ktorými sú: dôvernost’, celistvost’, autentifikácia, autorizácia, dostupnost’ a nepopieratel’nost’.

• Zát’ažový test: Je zameraný na škálovatel’nost’ aplikácie. Pri tomto teste pro- gram pracuje s vel’kými objemami dát alebo s vel’kým množ- stvom užívatel’ov, priˇcomsa zát’až na systém postupne zvy- šuje, až dôjde k pádu aplikácie alebo jej zahlteniu. Testujeme, akú zát’až už aplikácia nevydrží.

• Výkonnostný test: Vykonáva sa na zistenie, ako systém pracuje vzhl’adom na odozvy a stabilitu pod urˇcitouzát’ažou. Generuje sa vel’ké množstvo požiadaviek a sleduje sa, ako je ovplyvnený výkon aplikácie. Tá musí byt’ po urˇcitúdobu pod pretrvávajúcou zát’ažou, priˇcomby nemalo dôjst’ k jej pádu. Z dát je možné vyˇcítat’, ako rýchlo je systém schopný odpovedat’ na požia- davky, a to potom vedie k nájdeniu úzkeho miesta aplikácie. Následne sa môže vykonat’ náprava.

21 2. TESTOVANIE SOFTVÉRU

• Test kompatibility: Castouˇ chybou aplikácií sa stáva nekompatibilita s iným soft- vérom, operaˇcnýmsystémom alebo ciel’ovým prostredím, kto- ré sa môže vel’mi líšit’ od toho, na ktorom sa produkt vy- víja. Toto môže nastat’, napríklad, vtedy, ked’ developeri vy- víjajú a testujú softvér na najnovšom prostredí. To ale nemu- sia všetci užívatelia používat’, pretože to ich pôvodné je za- staralé. • Inštalaˇcnýtest: Overuje, ˇcije systém na zákazníkovom hardvéri korektne na- inštalovaný a plne funkˇcný. • Alfa test: Vykonáva sa pred koncom vývoja aplikácie a uskutoˇcˇnujesa na strane dodávatel’a. Vývojári a analytici sledujú užívatel’ov, sú to obvykle testeri z rovnakej spoloˇcnosti,pri jej používaní a robia si pri tom poznámky, ˇcoby bolo ešte vhodné vylepšit’. Je to koneˇcnétestovanie, ktoré vedie k internému akceptova- niu tejto aplikácie. • Beta test: Nastáva po alfa teste a môže sa považovat’ za formu exter- ného akceptovania aplikácie. Táto verzia je poskytnutá urˇcitej limitovanej skupine užívatel’ov na strane zákazníka a preverí fungovanie systému v skutoˇcnýchpodmienkach. Ciel’om tých- to užívatel’ov je poskytnút’ spätnú väzbu, priˇcomby ich pri- pomienky ešte mohli pozmenit’ niektoré nedostatky apliká- cie. • Dlhodobý test: Odhal’uje chyby aplikácie až po jej dlhodobom používaní. Zákazník má obvykle k dispozícii nástroj, do ktorého môže chyby zadávat’ a vývojári ich môžu v rámci dlhodobej údržby opravit’.

2.4.3 Funkˇcnétestovanie Funkˇcnétestovanie je v ISTQB slovníku [13] definované ako: „Tes- tovanie založené na analýze špecifikácie fukcionality komponetu alebo sys-

22 2. TESTOVANIE SOFTVÉRU tému.“. Ide o testovanie typu black box, pretože testujeme aplikáciu z pohl’adu vonkajšieho rozhrania. Funkˇcnétesty môžu zahrˇnovat’ rôzne typy testov v rôznych fázach vývoja a majú na výslednú bez- poruchovost’ systému významný vplyv. Najˇcastejšiesa funkˇcnétesty využívajú v integraˇcných,systémových a akceptaˇcnýchúrovniach testovania a ide hlavne o smoke a regresné testy.

23 3 Nástroje na automatizáciu funkˇcnýchtestov

Na svete existuje mnoho nástrojov, ktoré nám umožˇnujúautomati- zovat’ funkˇcnétesty. Pri výbere toho správneho musíme vziat’ do úvahy niekol’ko faktorov. V prvom rade si musíme definovat’, akým typom je naša aplikácia. Firma EmbedIT sa zaoberá vytváraním kl’úˇcovýchaplikácií pre všetky spoloˇcnostiskupiny Home Credit a Air Bank, ktorých hlav- nou obchodnou ˇcinnost’ou je poskytovanie finanˇcnýchproduktov v 10 krajinách sveta s viac ako 140 000 000 transakciami za jeden deˇn[14]. Náš tým sa procesne podiel’a na vývoji automatizovaných testov. Primárnymi produktmi, ktorých testy sú automatizované, sú webové a desktopové aplikácie. Zaoberat’ sa teda budeme týmito dvomi typmi aplikácií. Medzi d’alšie faktory, ktoré ovplyvˇnujúvýber vhodného automa- tizaˇcnéhonástroja, patrí finanˇcnánároˇcnost’, ktorá predstavuje cenu tohoto nástroja, prípadne d’alších, doplˇnujúcich,ktoré sú potrebné k plnej funkˇcnostiautomatizaˇcnéhonástroja. Poˇciatoˇcnéˇcasovéa or- ganizaˇcnénáklady na vytvorenie automatizácie, užívatel’ská príveti- vost’ nástroja a aj podpora programovacieho jazyka tu taktiež urˇcite patria. V tejto kapitole sa budeme zaoberat’ predstavením troch nástro- jov. Selenium a White sú aktuálne používané v procese automati- zácie vo firme EmbedIT a Ranorex je možný kandidát na prevzatie tejto úlohy. Nástroj Selenium umožˇnujetestovanie webových apli- kácií, White podporuje testovanie desktopových aplikácií a Ranorex podporuje testovanie oboch, webových aj desktopových aplikácií.

3.1 Selenium

V roku 2004 si mladý programátor, Jason Huggins, zo spoloˇcnosti ThoughtWorks uvedomil, že ˇcas,ktorý trávil vykonávaním tých is- tých manuálnych testov po každej zmene, sa dá využit’ ovel’a lepšie. Preto vytvoril javaskriptovú knižnicu, ktorá dokázala vykonávat’ in- terakcie s webovou stránkou, ˇcomu umožnilo spúšt’at’ a opakovat’ dokola tie isté testy na viacerých prehliadaˇcoch.Táto knižnica do- stala názov Selenium Core, ktorá predstavuje všetku dostupnú fun-

24 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ kcionalitu servera Selenium Remore Control (RC) a integrovaného vývojového prostredia Selenium IDE. Selenium RC bolo prelomové, pretože žiadny iný produkt nebol schopný poskytnút’ ovládanie pre- hliadaˇcaprogramovacím jazykom vlastného výberu. Pretože tento nástroj bol založený na jazyku JavaScript, nebolo možné využit’ všetky požadované funkcie, kvôli bezpeˇcnostnýmli- mitáciám Javaskriptu prehliadaˇcov. Postupom ˇcasusa webové apli- kácie stávali ovel’a silnejšie, pretože využívali všetky špeciálne vlast- nosti, ktoré prehliadaˇceposkytovali. Preto mal tento nástroj niekol’ko chýb a bolo potrebné ho vylepšit’. Odvážny inžinier spoloˇcnostiGoogle, Simon Stewart, sa v roku 2006 pustil do projektu s názvom WebDriver. Bolo to dôsledkom toho, že Google využíval k automatizácii práve Selenium, no museli vymýšl’at’ rôzne obchádzania problémov, aby dosiahli požadovanú funkcionalitu. Preto chcel vytvorit’ testovací nástroj, ktorý by komu- nikoval priamo s prehliadaˇcompoužívaním prirodzenej metódy pre prehliadaˇca operaˇcnýsystém. Tým by sa vyhol obmedzeniam a vy- p´lˇnalmedzery, ktoré Selenium malo. O dva roky neskôr sa udiala vel’ká vec. Selenium, ktoré malo ma- sívnu komunitu a komerˇcnúpodporu a WebDriver, nástroj budúc- nosti, sa zlúˇcilia vytvorili tak základ pre budúcnost’ automatizácie testov webových aplikácií. Ked’že licencia je vol’ná, je možné tento nástroj vylepšovat’ a vol’ne používat’ [15].

3.1.1 Selenium Remote Control (RC) Niekedy je tento nástroj oznaˇcovanýaj ako Selenium 1, ked’že vytvo- ril základ pre Selenium WebDriver (Selenium 2). Stále je aktívne pod- porovaný, ale len v rámci údržby, pretože nový vývoj bol zastavený. Stále však poskytuje ˇcast’ funkcionality, ktorou Selenium 2 nedispo- nuje, ako, napríklad, podpora starších prehliadaˇcov. Pri implemen- tácii testov môžeme použit’ jazyky, ako, napríklad, Java, JavaScript, Ruby, PHP, Python, Perl a C#. Tvoria ho dva komponenty, ktorými sú:

• Selenium Server: Spúšt’a a zatvára prehliadaˇce,interpretuje a spúšt’a seleniov- ské príkazy prichádzajúce z testovacieho programu a slúži

25 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

ako HTTP proxy (zástupca), zachytávajúci a verifikujúci HTTP správy vymieˇnanémedzi prehliadaˇcoma testovanou apliká- ciou.

• Klientské knižnice: Poskytujú rozhranie medzi Selenium RC servrom a progra- movacím jazykom.

Obrázok 3.1 zobrazuje zjednodušenú architektonickú schému.

Obr. 3.1: Selenium RC [15]

Ked’že Selenium RC server je jednoduchý Java .jar súbor, nie je potrebné ho inštalovat’, staˇcíiba stiahnut’ zip súbor z internetu a roz- balit’ ho do požadovaného adresára. Jednotlivé klientské knižnice pre konkrétny jazyk sú tiež dostupné k stiahnutiu. Predtým ako spustíme testy, je potrebné server naštartovat’. To vykonáme prostredníctvom príkazového riadku, ked’ nad adresá- rom, kde sa server nachádza, zavoláme príkaz java -jar selenium-server- standalone-<ˇcísloverzie>.jar.

26 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

Potrebné je aj stiahnutie niektorého testovacieho frameworku, a- ko, napríklad, JUnit alebo TestNG pre Java a NUnit pre .NET, ak vy- užívate jeden z týchto dvoch jazykov. Na zaˇciatku testu si musíme inicializovat’ prehliadaˇcpomocou parametrov host, port, browser a url. Záleží vždy na danom jazyku, aká metóda sa na inicializáciu volá. Ked’ máme prehliadaˇcnainicia- lizovaný a priradený nejakej premennej, tak nad premennou voláme seleniovské príkazy, ako sú, napríklad, getText, type alebo click. Pri vyváraní testov môžeme využívat’ aj iterácie a podmienené príkazy.

Obr. 3.2: Ukážka testu v jazyku Java [15]

Na základe priebehu testu sú po jeho dobehnutí vytvorené re- porty. Z nich môžeme vyvodit’, ˇcitest dobehol správne.

3.1.2 Selenium IDE Pri tvorbe automatizovaných testov môžeme využit’ nástroj Selenium IDE (Integrated Development Environment). Ide o doplnok pre pre- hliadaˇcFirefox, ktorý slúži na samotné automatizovanie a taktiež ako základ pre nauˇceniesa seleniovských príkazov. Obsahuje kontextové menu, v ktorom si najprv vyberieme element z aktuálnej stránky v prehliadaˇcia potom k nemu priradíme príkaz vybratím z mož- ností, ktoré daný element ponúka. Pri nahrávaní scenára sa každá užívatel’ská akcia uloží ako troj- ica:

27 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

• Príkaz (command): akcia, ktorá sa má vykonat’ • Ciel’ (target): identifikácia elementu, pre ktorý sa má daný príkaz vykonat’ • Hodnota (value): je nastavená príkazom do ciel’a, môže byt’ aj prázdna.

Obr. 3.3: Ukážka testu v Selenium IDE [15]

Každý element obsahuje vlastný zoznam príkazov, ktoré na ˇnom môžu byt’ vykonané. Spolu tvoria celý testovací jazyk a sú rozdelené do troch skupín: • Akcie (actions): príkazy, ktoré manipulujú so stavom apliká- cie. Vykonávajú operácie, ako, napríklad, klik na odkaz, vý- ber možnosti a d’alšie. Ak sa daná akcia nevykoná, test skonˇcí chybou.

28 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

• Prístupy (accessors): skúmajú stav aplikácie a ukladajú vý- sledky do premenných. Používajú sa aj na automatické ge- nerovanie overovaní.

• Overovania (assertions): sú nieˇcoako prístupy, ale verifikujú, že aktuálny stav aplikácie zodpovedá stavu oˇcakávanému. Môžu byt’ použité v troch módoch: over, zverifikuj, poˇckaj. Ak by sme ich aplikovali na text, vyzerali by ako over text, zverifikuj text a poˇckajna text.

Obrázok 3.3 zobrazuje jednotlivé kroky testu s akciami, ktoré sa majú vykonat’. Najprv si prehliadaˇcotvorí stránku www.google.com, potom do vyhl’adávania napíše text „selenium IDE rocks!“, klikne na tlaˇcítkovyhl’adat’, klikne na link, d’alší link a overí, ˇcisa na stránke nachádza text: „I think record playback is a wonderful thing“. Selenium IDE môžeme použit’ na vytváranie automatizovaných testov a samotné spúšt’anie testov môžeme vykonávat’ na nástroji Selenium RC. Pre tento úˇcelje v paneli nástrojov možnost’ File -> Export Text case, ktorý nám daný text vyexportuje, no ešte predtým je potrebné si vybrat’ nami požadovaný programovací jazyk. Medzi hlavné nevýhody tohoto nástroja patrí možnost’ jeho pri- dania iba do prehliadaˇcaFirefox. Vytvorené testy ale môžu byt’ ná- sledne spúšt’ané aj na iných prehliadaˇcochprostredníctvom príkazo- vého riadku. Dalšouˇ nevýhodou je jeho jednoduchost’ a malý poˇcet príkazov, ktoré môžu byt’ použité. Ak by sme chceli vytvárat’ zlo- žitejšie testy s použitím, napríklad, podmienok alebo cyklov, nie je to možné. Takisto nie je možné odstránit’ duplicitu v kóde, pretože každý test si vytvára nové kroky a nepoužíva už vytvorené. Vd’aka týmto nedostatkom je vhodné jeho použitie iba na jedno- duché testy a ako prototypovací nástroj, v ktorom sa môžeme nauˇcit’ základy, ako, napríklad, seleniovské príkazy.

3.1.3 Selenium Grid Ked’ sme úspešne vytvorili automatizované testy, prichádza na rad ich spúšt’anie. Jedným z riešení je použitie nástroja Selenium Grid. Ten umožˇnujespúšt’at’ testy na rôznych strojoch s použitím rôznych prehliadaˇcovparalelne. Na jeho použitie sú dva hlavné dôvody:

29 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

• spúšt’anie testov voˇciviacerým prehliadaˇcom,rôznym ver- ziám prehliadaˇcova prehliadaˇcovbežiacich na rôznych ope- raˇcnýchsystémoch

• skrátenie ˇcasuvykonávania testov

Obr. 3.4: Schéma fungovania nástroja Selenium Grid [16]

Ak by sme teda využívali na testovanie 4 poˇcítaˇcealebo virtuálne stroje, pri poˇcte100 testov by sa ˇcasich behu znížil na štvrtinu. Toto môže byt’ užitoˇcnéhlavne pri agilnom vývoji, kedy potrebujeme vy- konat’ vel’ké množstvo testov v ˇconajkratšom ˇcase. Selenium Grid sa skladá z jedného centrálneho uzla, do ktorého vstupujú d’alšie uzly. Centrálny uzol získava test a informácie, na

30 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

ktorom prehliadaˇcia platforme má daný test bežat’. Vie konfiguráciu každého uzla, ktorý bol zaregistrovaný do centrálneho a na základe danej informácie vyberie ten, ktorý je dostupný a má testom poža- dovanú konfiguráciu. Po tom, ako bol uzol vybratý, sú seleniovské príkazy inicializované testom zaslané do centrálneho uzla, ktorý ich odošle na uzol, ktorý bol testu priradený. Aktuálne sa používa verzia 2.0, ktorá je dost’ odlišná od prvej. V tej novšej bol Selenium Grid zlúˇcenýso Selenium RC serverom. Vd’aka tomu je teraz potrebné stiahnut’ si iba samotný .jar súbor, ktorý obsahuje oba nástroje, Selenium RC server a Selenium Grid.

3.1.4 Selenium WebDriver Nástroj Selenium 2.0 na rozdiel od prvej verzie obsahuje integrované WebDriver API (Application Program Interface), ktoré bolo navr- hnuté tak, aby poskytovalo jednoduchšie a struˇcnejšieprogramova- cie rozhranie, a aby taktiež odstránilo niektoré obmedzenia, ktoré ob- sahovalo Selenium RC API. Preto je aj nazývané Selenium WebDriver. Touto integráciou sa dosiahla lepšia podpora dynamických webo- vých stránok, na ktorých sa môžu bez ich obnovenia menit’ elementy. Jeho ciel’om je poskytnút’ dobre navrhnuté a objektovo orientované API, ktoré poskytuje vylepšenú podporu pre moderné, pokroˇcilétes- tovanie. Práve tento nástroj je používaný vo firme EmbedIT a slúži na automatizáciu testov webových aplikácií. Selenium WebDriver vytvára priame volania do prehliadaˇcapou- žitím natívnej podpory každého z nich. To, ako sú tieto priame vola- nia vytvárané a funkcie, aké podporujú, závisí od použitého prehlia- daˇca.Na rozdiel od Selenium 2.0, Selenium RC pracoval s každým prehliadaˇcomrovnakým spôsobom. Po naˇcítaníprehliadaˇcaboli do neho vložené javascriptové funkcie a potom Selenium RC použil svoj javascript k riadeniu testov v prehliadaˇci. Selenium Server môžeme, ale aj nemusíme použit’. Záleží to len od toho, ako chceme Selenium WebDriver aplikovat’. Ak budeme vy- užívat’ iba WebDriver API, tak server nie je potrebný. Toto platí aj v prípade, že prehliadaˇca testy pobežia na rovnakom stroji a testy budú využívat’ iba WebDriver API, pretože spustí prehliadaˇcna- priamo. Prípady, v ktorých je naopak Selenium Server potrebné po- užit’, nastanú, ak:

31 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

• využívame Selenium Grid na distribuovanie testov nad poˇcí- taˇcmialebo virtuálnymi strojmi;

• chceme vytvorit’ pripojenie na vzdialený stroj, ktorý má inú verziu prehliadaˇcaako ten náš;

• nepoužívame Java väzby, napríklad, pri jazykoch Python, C# alebo Ruby a chceli by sme použit’ HtmlUnit Driver.

Prvý krok, ktorý musíme vykonat’, ak chceme na automatizáciu našich testov používat’ Selenium WebDriver, je jeho pridanie do pro- jektu. Spôsob pridania záleží na jazyku, v ktorom projekt programu- jeme. Ak používame jazyk Java, staˇcípridat’ závislost’ do náležitého pom.xml súboru. Maven potom za nás vykoná stiahnutie všetkých závislostí. V tejto pridanej závislosti si definujeme aj verziu nástroja Selenium, ktorá bude stiahnutá.

Obr. 3.5: Pridanie závislosti do pom.xml [15]

Ak je programovacím jazykom C#, musíme z internetu stiahnut’ .zip súbor s .dll súbormi, ktoré naimportujeme do projektu. Pre ja- zyky Python a Ruby pridáme Selenium cez príkazový riadok, no ak použijeme jazyk PHP alebo Perl, je potrebné nájst’ postup prida- nia v dokumentácii tretích strán, pretože oficiálne nie sú zverejnené. Ked’ máme projekt nastavený, môžeme zaˇcat’ s vytváraním automa- tizovaných testov.

32 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

3.1.4.1 Inštancia prehliadaˇca Jedna z prvých funkcií, ktorú pri programovaní testov použijeme, je vytvorenie inštancie prehliadaˇca.Znovu záleží na type prehliadaˇca, aký konštruktor použijeme:

• HtmlUnit Driver: Je aktuálne najrýchlejšia a najodl’ahˇcenejšiaimplementácia nástroja WebDriver. Je založená na HtmlUnit, ˇcoje imple- mentácia prehliadaˇcabez GUI (Graphical User Interface), za- ložená na Jave. Ak na tvorbu testov použijeme iný jazyk ako Java, je potrebné použit’ taktiež Selenium Server. Výhody:

– najrýchlejšia implementácia nástroja WebDriver; – ˇcistéJava riešenie, vd’aka ktorému je aj platformne ne- závislé; – podporuje JavaScript.

Nevýhody:

– emuluje JavaScript správanie sa ostatných prehliadaˇcov, no dost’ podstatne sa od toho originálneho odlišuje.

• Firefox Driver: Firefox profil, ktorý je použitý, je zjednodušený oproti tomu nainštalovanému na danom stroji. Obsahuje iba seleniovské rozšírenie SeleniumDriver.xpi. Je možné využívat’ ho na plat- formách Windows, Mac, Linux. Výhody:

– beží na reálnom prehliadaˇcia podporuje JavaScript; – rýchlejší ako Internet Explorer Driver.

Nevýhody:

– pomalší ako HtmlUnit Driver.

33 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

• Internet Explorer Driver: Ked’že je riadený pomocou .dll, je dostupný iba pre platformu Windows. Výhody:

– beží na reálnom prehliadaˇcia podporuje JavaScript.

Nevýhody:

– funguje iba s operaˇcnýmsystémom Windows; – v porovnaní s ostatnými je pomalší; – XPath nie je vo viacerých verziách natívne podporované, Sizzle je vložené automaticky, ˇcoje významne pomalšie ako ostatné prehliadaˇcea pomalšie ako CSS selektory v rovnakom prehliadaˇci; – CSS nie je v niektorých verziách natívne podporované. Namiesto toho je vkladané Sizzle; – CSS selektory v IE 9 a 10 (Internet Explorer) sú natívne, no tie konkrétne prehliadaˇcenepodporujú CSS3.

• ChromeDriver: Je udržiavaný a podporovaný v rámci samotného Chromium projektu. WebDriver pracuje s prehliadaˇcomcez binárny sú- bor ChromeDriver. Preto je potrebné mat’ nainštalovaný Chro- meDriver a taktiež prehliadaˇcChrome. ChromeDriver musí byt’ pridaný do systémového adresára, aby ho WebDriver do- kázal nájst’. PrehliadaˇcChrome je vyhl’adávaný v jeho pred- volenom adresári. Výhody:

– beží na reálnom prehliadaˇcia podporuje JavaScript; – pretože Chrome je WebKit založený prehliadaˇc,Chro- meDriver nám môže povolit’ verifikáciu, ˇcinaša stránka funguje v prehliadaˇciSafari. Je ale potrebné mysliet’ na to, že Chrome využíva vlastný V8 JavaScript prostrie- dok ako Nitro, ktoré používa Safari, preto sa vykonáva- nie môže líšit’.

34 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

Nevýhody: – pomalší ako HtmlUnit Driver. Dalšieˇ dostupné ovládaˇce,ktoré je možné použit’, sú Opera Dri- ver, iOS Driver a, samozrejme, Android Driver.

3.1.4.2 Implementácia krokov testu Po nastavení projektu a inicializovaní jedného z dostupných ovláda- ˇcovmôžeme zaˇcat’ programovat’ jednotlivé kroky testov. Jednotlivé operácie, ktoré budeme vykonávat’, sa vykonávajú na jednotlivých elementoch, ktoré sa nachádzajú na danej stránke. Na ich lokalizá- ciu priamo používame WebDriver alebo WebElementy samotné. Me- tódy, ktoré vyhl’adajú elementy sú, Find Element alebo Find Elements. Prvá vráti WebElement objekt alebo v prípade, že element nenájde, vráti hodnotu null. Druhá vracia zoznam WebElementov alebo hod- notu null. Pri tomto vyhl’adávaní používame takzvané By stratégie, ktoré sú parametrom spomínaných vyhl’adávajúcich funkcií. Pri identifiko- vaní elementov na stránke existuje niekol’ko stupˇnovich lokalizácie od najefektívnejšej a najpreferovanejšej, až po tú najmenej efektívnu. Ako prvú sa ponúka použit’ funkciu By.id(), kde je jej parametrom unikátny ID identifikátor, ktorý nemá žiadny iný element. Žial’, vý- vojári ˇcastopoužívajú neuniverzálne alebo autogenerované ID ele- mentov, ˇconás vedie k d’alšiemu možnému lokalizovaniu, a to je podl’a mena triedy By.className(). To vyhl’adá elementy, ktoré majú požadovaný názov triedy. Ked’že, pravdepodobne, nájde týchto ele- mentov viac, ktoré majú rovnaký názov triedy, vráti ich ako zoznam. Tretí spôsob je použit’ meno štítku alebo taktiež tag By.tagName() konkrétneho elementu. Medzi d’alšie možnosti patrí vyhl’adanie pod- l’a mena atribútu By.name(), textu odkazu By.linkText(), ˇciastoˇcného textu odkazu By.partialLinkText(). Použitie identifikácie podl’a CSS, ˇconemusí v niektorých prehliadaˇcochfungovat’. Identifikácia podl’a XPath (jazyk pre navigáciu v XML dokumente) By.xpath() je taktiež možná. K tomuto spôsobu môžeme použit’ nástroj FireBug, ktorý je rozšírením pre prehliadaˇcFirefox a automaticky vytvára XPath ozna- ˇcenéhoelementu. Poslednou možnost’ou, ako identifikovat’ element, je použitie JavaScriptu.

35 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

Obr. 3.6: Ukážka testu s využitím nástroja Selenium WebDriver [15]

Po vyhl’adaní správnych elementov môžeme zaˇcat’ využívat’ ope- rácie, ktoré sú na týchto elementoch vykonávané a interagujú tak so stránkou. V dokumentácii je vymenovaných množstvo operácií, ako, napríklad, vyp´lˇnanieformulárov, prepínanie medzi stránkami, odchytávanie a práca s popup dialógmi a rôzne d’alšie, ktoré k fun- govaniu môžu, napríklad, aj simulovat’ vstupné zariadenia, ktorými sú klávesnica a myš. Ked’že operácie, ktoré sa vykonávajú na pozadí stránky po in- terakcii s jej elementami, môžu trvat’ nejaký ˇcas,je preto obˇcaspo- trebné na tento element alebo operáciu poˇckat’ pomocou explicit-

36 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

ného alebo implicitného ˇcakania.Explicitné ˇcakanieˇcakána nejakú podmienku, ktorá sa má splnit’, aby mohla byt’ povolená d’alšia in- terakcia. Druhé, implicitné ˇcakanie,ˇcakáˇcas,ktorý požadujeme. Vzhl’adom na to, že testy majú odhal’ovat’ nesprávne správanie sa aplikácie, nie je celkom postaˇcujúce,ak sa po páde testu chyba zapíše iba na výstupnú konzolu, prípadne do logu. Výnimky nemu- sia byt’ vždy úplne konkrétne a my tak nedokážeme presne urˇcit’, ˇcoje príˇcinapádu testu. Preto je vhodné použit’ vytvorenie záznamu obrazovky poˇcaspádu testu. Túto funkcionalitu implementuje Re- moteWebDriver, ktorý je potomok triedy WebDriver.

3.2 White

Na automatizáciu desktopových aplikácií, ktoré sú založené na Win- Form a WPF platformách, sa vo firme EmbedIT používa framework White. Okrem nich tento framework podporuje aj Win32, Silverlight a SWT (Java) platformy. Bol vytvorený v rámci projektu TestStack, ktorý združuje niekol’ko open source projektov. Založený je na .NET frameworku a nepotrebuje použitie žiadnych proprietárnych skrip- tovacích jazykov. Projekty, ktoré využívajú White, môžu používat’ l’ubovol’ný .NET jazyk, IDE a nástroje. Poskytuje konzistentné ob- jektovo orientované API, skrývajúce komplexné knižnice Microsoft UI Automation a Window messages [17].

Obr. 3.7: White architektúra [17]

Obrázok 3.7 znázorˇnujeschému, ako nástroj White funguje. Pre jeho funkˇcnost’ je ale nutné, aby bežal na inom procese, ako je ten testovanej aplikácie.

37 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

Ked’že tento framework predpokladá, že užívatelia, ktorí s ním budú pracovat’, majú vývojárske skúsenosti, preto neposkytuje žia- den nástroj na nahrávanie jednotlivých krokov testu. Je doporuˇcené, že ak testeri nemajú programátorský základ, aby radšej využili iný nástroj. Na to, aby sme mohli zaˇcat’ používat’ White, si musíme overit’, ˇcináš projekt používa aspoˇn.NET 4.0 framework verziu. Ak je pod- mienka splnená, White pridáme do projektu prostredníctvom NuGet správcu balíˇckov, ktorý je urˇcenýpre platformu Microsoft a je vol’ne dostupný. Po jeho pridaní môžeme White používat’. Príkaz Application app = Application.Launch("foo.exe"); spustí apli- káciu a vytvorí jej inštanciu v premennej application. Po tom, ako si nainicializujeme aplikáciu a spustí sa, musíme si zaregistrovat’ okno, ktoré predstavuje danú aplikáciu. To vykonáme príkazom Window win = application.GetWindow("bar", InitializeOption.NoCache);. V tomto momente máme okno aplikácie zaregistrované a uložené do premen- nej. White používa UIAutomation API na nájdenie elementov na da- nom okne. UIAutomation komunikuje so zobrazeným oknom pro- stredníctvom správ okna. Toto hl’adanie je vykonávané iterovaním nad všetkými elementami v okne. Ak má okno príliš vel’a UIItems (elementy okna), môže byt’ táto identifikácia vel’mi pomalá. Na to, aby sme neˇcakalidlhú dobu, White na vylepšenie výkonu podpo- ruje poziˇcne-orientovanélokalizovanie elementov. Ked’ máme nainicializované okno, môžeme sa zamerat’ na iden- tifikáciu jednotlivých UIItem elementov. Tie sa inicializujú prostred- níctvom funkcie window.Get("save"). Typ Button môže byt’ nahradený l’ubovol’ným z typov UIItem elementov. Tak ako pri identifikácii elementov s použitím nástroja Selenium sme používali rôzne identifikátory v závislosti od najlepšej po naj- menej vhodnú identifikáciu, tak aj pri nástroji White si môžeme de- finovat’ typ identifikátora, prostredníctvom ktorého bude požado- vaný element nájdený. To dosiahneme použitím triedy SearchCrite- ria, ktorá definuje nasledovné spôsoby. Primárne najlepší spôsob je vyhl’adávanie podl’a AutomationId SearchCriteria.ByAutomationId("name"). Ten by mal obsahovat’ jedi- neˇcnýidentifikátor elementu. Ak ale AutomationID elementu nie je definovaný, môžeme použit’, napríklad, funkcie By.ClassName(),

38 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

By.ControlType(), By.ByText(). Ak by sme ale stále mali elementov vel’a, je možné túto funkciu zret’azit’ s d’alšou podmienkou, ako, naprí- klad, AndAutomationId(), AndByClassName(), AndByText(), AndControl- Type(), AndIndex().SearchCriteria.ByText("DataGridView").AndIndex(0) vyhl’adá najprv elementy s textom „DataGridView“ a potom vrátia ten prvý.

Obr. 3.8: UI Automation Verify

Nástroj, ktorý je vel’mi dôležitý a bez ktorého by sme nevedeli urˇcit’ presné parametre metód na vyhl’adávanie elementov, je ná- stroj UI Automation Verify. Je vol’ne dostupný na internete a slúži ako Windows GUI ovládaˇc.Pozostáva z jedného okna, ktoré je roz- delené na 4 ˇcasti.Pre nás sú potrebné len 2. Nal’avo je zobrazená stromová štruktúra všetkých okien a podokien a napravo sú zobra- zené vlastnosti. V nich môžeme nájst’ hodnoty jednotlivých vlast- ností elementov, ktoré použijeme ako parameter vo vyhl’adávacích funkciách, ktoré boli predstavené v predošlom odstavci. Musíme si dat’ ale pozor na zavádzajúce oznaˇcenievlastnosti Name, ktorej pri- slúcha inak oznaˇcenávyhl’adávacia metóda, ktorou je .ByText(). Po inicializácii elementu na ˇnommôžeme vykonávat’ rôzne ope- rácie a tvorit’ tak kroky jednotlivých testovacích scenárov.

39 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

Pri automatickom vykonávaní testu musíme vziat’ do úvahy, že klávesnica a myš sú poˇcasjeho behu používané a vykonávajú sa po- mocou nich operácie. Na poˇcítaˇci,virtuálnom stroji alebo na serveri teda nemôžeme vykonávat’ žiadnu inú aktivitu, pretože by to viedlo k pádu testu.

3.3 Ranorex

Ranorex je nástroj na automatizáciu GUI desktopových, webových a mobilných aplikácií. Je vyvinutý spoloˇcnost’ou Ranorex GmbH, ktorá je zameraná na vývoj inovatívnych automatizaˇcnýchriešení. Ranorex nemá svoj vlastný skriptovací jazyk, ale namiesto toho využíva štandardné programovacie jazyky, ktorými sú C# a VB.NET. Aj vd’aka tomuto dôvodu nepodporuje iné desktopové platformy ako Windows alebo Windows Server. Webové aplikácie môžu byt’ testované v prehliadaˇcochInterner Explorer, Mozilla Firefox, Google Chrome a Apple Safari na rovnakom princípe ako tie desktopové. Na to, aby sme mohli automatizovat’ testy na mobilné aplikácie, potrebujeme byt’ na mobil pripojený prostredníctvom Wi-Fi alebo USB, a podporované platformy na testovanie sú Android a iOS. Ked’že Ranorex nie je vol’ne dostupný tak ako Selenium a White, je potrebné si ho predplatit’. Podrobný zoznam všetkých dostupných licencií sa nachádza v kapitole 5. Je ale možné stiahnut’ si 30-dˇnovú skúšobnú verziu, ktorej odkaz na stiahnutie vám bude zaslaný na email uvedený pri registrácii. Ranorex sa skladá z viacerých nástrojov, ktorými sú Ranorex Re- corder, Ranorex Spy, Ranorex Test Suite, Ranorex Studio a automa- tizaˇcnéknižnice pre .NET, ktoré spolu tvoria jeden z ˇcastopoužíva- ných nástrojov pre automatizáciu. Hlavným dôvodom je jeho jed- noduchost’, testeri nemusia byt’ programátorsky zdatní, aby vedeli vytvárat’ automatizované testy. Pod’me si tieto nástroje bližšie pred- stavit’ [18]. Ranorex Recorder slúži na nahrávanie a spúšt’anie užívatel’ských operácií, ktoré sú vykonávané klávesnicou a myšou v rámci manu- álneho testu aplikácie. Recorder tiež dokáže validovat’ aktuálny stav aplikácie, vlastností elementov, ako, napríklad, „Text“ alebo „Visibi- lity“ a porovnávat’ obrázky UI elementov. Dostupný je ako samos-

40 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ tatný nástroj alebo je integrovaný v Ranorex Studiu. Pri nahrávaní by sme mali dbat’ hlavne na tieto 4 rady:

• nespúšt’at’ viacero inštancií testovanej aplikácie, ak to nie je potrebné pre samotný test;

• poˇciatoˇcnénastavenie je také, že samotné pohyby myši nie sú nahrávané, preto je potrebné vykonávat’ klikanie v situ- áciách, ako, napríklad, pri navigovaní cez menu, alebo je po- trebné na nahrávanie pohybu myši využit’ Recorder Hotkeys (Hotkeys sú preddefinované operácie, ktoré sú vyvolané stla- ˇcenímšpecifických kláves, tlaˇcidielalebo kolieska myši);

• je potrebné mysliet’ dopredu, z akých krokov sa bude test skladat’;

• pokúsit’ sa vytvárat’ malé nahrávky, aby ich bolo možné po- užit’ modulárne v inom teste.

Obr. 3.9: Ranorex Recorder ako samostatný nástroj [18]

Po ukonˇcenínahrávania sú všetky nahraté kroky zobrazené v ta- bul’ke s rôznymi záznamami, ktoré majú priradené, ako, napríklad, typ operácie, typ tlaˇcítka,pozícia, repozitárová položka, ktoré mô- žeme editovat’, prípadne pridat’ alebo odobrat’ urˇcitýkrok. Repo- zitárové položky sú UI elementy, ktoré sú generované a ukladané do repozitára pre možnost’ znovupoužitia. Každý krok má takisto aj malú snímku obrazovky.

41 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

Obr. 3.10: Ranorex Recorder editor [18]

Ranorex Spy je samostatný nástroj z Ranorex rodiny, ktorý posky- tuje všetku potrebnú funkcionalitu na skúmanie a analýzu aplikácií, vrátane ich UI elementov. Po spustení tohoto programu sa v jeho l’a- vej ˇcastizobrazí stromová štruktúra všetkých práve bežiacich apli- kácií na desktope alebo mobilnom zariadení. Po vybraní si jedného uzla sa nám o ˇnomv pravej ˇcastizobrazí viac detailnejších informá- cií, a taktiež malá snímka daného elementu. V hornej ˇcastinástroja sa zobrazuje cesta k vyhl’adanému elementu, takzvaná RanoreXPath, ktorá je editovatel’ná. Vo vrchnej strane nástroja sa nachádza tlaˇcítkoTrack, ktoré po aktivácii samo vyhl’adáva cesty elementov, na ktoré ukazuje ukazo- vatel’ myši. Pod ním sa nachádza podokno, ktoré slúši na editáciu ciest elementov. Tu si môžeme zadefinovat’, z akých parametrov sa bude cesta skladat’. Vyberat’ si môžeme z daných vlastností elemen- tov a staˇcílen jednoducho kliknút’ na zaškrtávací box a parameter je následne pridaný do RanoreXPath editoru. Medzi hlavné funkcie Ranorex Spy nástroja patrí vyhl’adávanie

42 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

Obr. 3.11: Nástroj Ranorex Spy [18]

viac ako 30 typov UI elementov, ktoré sa v Ranorex slovníku nazý- vajú adaptéry, mód editácie RanoreXPath, editácia cesty elementov, vytváranie snímok elementov a pridávanie elementov do repozitára. Ranorex Test Suite je nástroj na tvorbu a editáciu testovacích prí- padov kombinovaním už vytvorených testovacích modulov. Nemu- síme tak stále dookola vytvárat’ rovnaké kroky, ale staˇcí,aby sme si z niektorých vytvorili modul a ten potom spojili v nejakom testova- com prípade. Ranorex Studio slúži ako vývojové prostredie, v ktorom sa vytvára kód, krokuje a taktiež sa využíva na test manažment. Na úvodnej stránke sa po spustení zobrazí mnoho užitoˇcnýchmožností, ako, na- príklad, tlaˇcítkopre nový projekt, vzorové projekty, otvorenie existu- júceho projektu, naposledy otvorené projekty, termín validity licen-

43 3. NÁSTROJENAAUTOMATIZÁCIUFUNKCNÝCHTESTOVˇ

cie, najnovšie správy od Ranorex vývojárov a tiež príspevky z blogu. V tomto nástroji je teda možné vyvíjat’ automatizované testy.

Obr. 3.12: Nástroj Ranorex Studio [18]

Automatizaˇcnéknižnice pre .NET nám poskytujú možnost’ integ- rovat’ tvorbu automatizovaných testov priamo vo vývojovom pro- stredí Visual Studio. Staˇcí,aby sme naimportovali potrebné závis- losti a knižnice sú dostupné k používaniu. Tak môžeme vytvárat’ robustnejšie testovacie prípady, ktoré by nahrávaním scenárov ne- plnili rovnako potrebnú funkˇcnost’. Je teda na nás, pre aký spôsob sa rozhodneme. Môžeme sa vybrat’ jednoduchšou cestou, ktorá je dostupnejšia pre menej zdatných v programovaní, alebo si prípady sami naprogramujeme.

44 4 Ukážkové príklady

Pokroˇciláautomatizácia si vyžaduje dobre navrhnuté zázemie, t.j. projekt, v ktorom sa programujú scenáre testov. Je vel’mi dôležité tento projekt navrhnút’ tak, aby poskytoval všetky potrebné mož- nosti, ktoré sú dôležité pre automatizáciu testov požadovaných apli- kácií. Je nutné mysliet’ taktiež aj do budúcnosti, pretože poˇcettestov bude vzrastat’ a zle navrhnutá štruktúra projektu by vyžadovala prí- liš vysokú réžiu na údržbu. Pri automatizovaní aplikácií oboch typov, webových aj deskto- pových, dodržiavame Page Object Pattern [15], ˇcoje mapovanie jed- nej webovej stránky alebo okna aplikácie na minimálne jednu triedu, ktorá ich v projekte predstavuje a poskytuje potrebnú funkcionalitu na manipuláciu s nimi. V tejto kapitole budú predstavené existujúce projekty vo firme EmbedIT, ktoré pre automatizáciu testov používajú nástroje Selenium a White. Taktiež bude navrhnutá optimálna štruktúra pre automati- záciu s využitím nástroja Ranorex.

4.1 Selenium

Projekt vytvorený na automatizáciu webových scenárov využíva Se- lenium WebDriver. Dôvod, preˇcobolo využité práve Selenium, je taký, že je vol’ne dostupné, má celosvetovo vel’kú podporu, je multi- platformné a postaˇcujúcepre potrebné úˇcely. Testujeme primárne na prehliadaˇciFirefox a k tomu využívame Firefox Driver. Selenium ale nie je jediná technológia, ktorú pri automatizácii webových aplikácií využívame.

4.1.1 Použité technológie Aj ked’ samotné Selenium poskytuje vývojové prostredie, v ktorom sa dajú vytvárat’ testy, nie je postaˇcujúce.Preto používame nástroj úplne postaˇcujúcipre naše využitie — IntelliJ IDEA. Jeho základná verzia je zdarma. Toto IDE je zrejme najlepšie vývojové prostredie pre Java aplikácie a je takisto preferované v rámci vývoja v spoloˇc- nosti EmbedIT. V ˇnom sa programujú, krokujú a spúšt’ajú všetky

45 4. UKÁŽKOVÉPRÍKLADY

testy. Ako východzí používame programovací jazyk Java. Na to, aby sme mohli spúšt’at’ testy aj na serveroch a využívat’ tak ich ˇcasneˇcinnostina beh testov, na kontinuálnu integráciu použí- vame nástroj Jenkins, ktorý je vol’ne licencovaný. My v tomto nástroji vytvárame úlohy (job) a taktiež multiúlohy (multijob). Slúži na ich vy- tváranie, nasadzovanie a spúšt’anie. Obsahuje aj pracovný adresár, kde sa ukladajú, napríklad, snímky obrazoviek poˇcaspádu apliká- cie. Na konci testu je taktiež možné vygenerovat’ správu o výsledku úlohy a toto všetko sa vykonáva automaticky. Spustenie jednotlivých úloh sa dá podl’a potreby nastavit’ a naplánovat’, vrátane pravidel- ného opakovania a zasielania notifikácií o výsledkoch. Pri vývoji automatizovaných testov je dôležité zohl’adnit’ aj to, aký verzovací nástroj je použitý. Je mnoho názorov, preˇcoje SVN alebo Git lepšie, my sme sa spoˇciatkurozhodli používat’ verzovací nástroj SVN. Je o nieˇcojednoduchší a postaˇcujenašej práci. V budúc- nosti ale plánujeme prejst’ na Git, ktorý používajú aj vývojári testo- vanej aplikácie. Oba totiž Jenkins podporuje. JUnit je použitý ako framework na jednotkové testy. Podporuje totiž rôzne potrebné funckie, ako, napríklad, Assertion, ErrorCollector a d’alšie. Na správu knižníc, modulov a projektu využívame Maven, pod- porný infraštruktúrny nástroj. Jednotlivé moduly projektu sú integ- rované cez tento nástroj. Pozitívum je aj to, že štruktúra nástroja Ma- ven je už pripravená na vývoj testov. Pre úˇcelynašich automatizo- vaných testov sme ale pripravili špeciálnu end-to-end-test-support knižnicu, aby sme si vytvorili sadu funkcionality, ktorá nám ul’ah- ˇcujeprácu. Taktiež použivame aj framework Spring, ktorý je s nástrojom Ma- ven štandardný pre vývoj aplikácií v našej spoloˇcnosti.Pri tvorbe au- tomatizovaných testov využívame DependencyInjection, JdbcTemplate a ResourceBundle. Na identifikáciu a overovanie elementov na stránke používame rozšírenie FireBug pre prehliadaˇcFirefox. Toto sú všetky technológie a nástroje, ktoré využívame na au- tomatizáciu webových testov. Pod’me si ale priblížit’ štruktúru pro- jektu, ktorý obsahuje samotné testy.

46 4. UKÁŽKOVÉPRÍKLADY

4.1.2 Štruktúra projektu Ako už bolo spomenuté, projekt obsahujúci automatizované testy sa skladá zo 4 modulov. Tie ho rozdel’ujú na logické celky, ktoré majú medzi sebou rôzne závislosti a navzájom sa využívajú.

Obr. 4.1: Závislosti medzi modulmi

Prvým modulom je API, ktorý nemá žiadne interné závislosti na iné moduly. Nachádzajú sa v ˇnomtriedy, ktoré reprezentujú we- bové stránky aplikácie. Môžu byt’ mapované 1:N, ˇcižejedna we- bová stránka musí mat’ minimálne jednu triedu. Ak máme pre jednu stránku viac tried, musia zodpovedat’ logickému rozdeleniu danej webovej stránky. Nachádzajú sa tu taktiež enumerácie, konštanty, objekty na transfer dát (DTO) a utility, ktoré sa využívajú k získava- niu ret’azcov kvôli lokalizácii jazyka, generovanie dátumu narodenia a iných potrebných údajov. Druhý modul je DAO, ktorý reprezentuje prácu s databázou a je závislý iba na module API. Je to z toho dôvodu, aby sme v ˇnommohli vytvárat’ už vyššie spomínané DTO objekty. Rôznymi metódami zís- kavame pomocou definícií SQL dotazov dáta z databázy a použí- vame ich k testovacím úˇcelom. Dalšíˇ je modul WS (Web Services) a využívaný je ku komunikácii s webovými službami prostredníctvom XML. Taktiež je závislý iba na API a jeho štruktúra je podobná tej z modulu DAO. Posledný je modul Test, ktorý reprezentuje testovacie scenáre. Aj ked’ všetky testujú inú funkcionalitu, zameriavajú sa na urˇcitémo- duly. Testy, ktoré testujú rovnaké moduly, sú teda vložené do spoloˇc- nej testovej triedy. Tento modul je závislý na ostatných troch. Ked’že

47 4. UKÁŽKOVÉPRÍKLADY

má priame závislosti na DAO a WS, má tým aj nepriamu závislost’ na modul API. Nachádzajú sa tu aj zoznamy usporiadaných testov, ktoré spúšt’ajú pridané testy podl’a poradia, generátory dát, ako, na- príklad, náhodného textového ret’azca urˇcitejd´lžky, bankových úˇc- tov, rodných ˇcísela d’alších užitoˇcnýchinformácií. To bolo v skrate predstavenie štruktúry projektu zameraného na automatizované testovanie webových aplikácií spoloˇcnostiEmbedIT. Ked’že rôzne krajiny, v ktorých Home Credit pôsobí, majú o nieˇco odlišnú funkcionalitu, tak aj tieto projekty sa od seba nieˇcomálo lí- šia. Pod’me si teraz predstavit’ projekt automatizácie testov deskto- pových aplikácií.

4.2 White

Projekt, v ktorom sa automatizujú desktopové aplikácie, využíva ná- stroj TestStack White. Tak ako pri predošlom projekte, aj tu bol tento nástroj vybraný z toho dôvodu, že je vol’ne dostupný, má vel’kú pod- poru a spolu s ostatnými nástrojmi je plne postaˇcujúcina automati- záciu testov desktopových aplikácií.

4.2.1 Použité technológie Testy automatizujeme vo vývojovom prostredí Visual Studio 2010 a 2012. Preto sme museli upravit’ projekt tak, aby ho bolo možné spúšt’at’ a programovat’ v oboch verziách, a teda používame starší .NET framework 4.0. Visual Studio 2010 totiž novší nepodporuje. Visual Studio musíme všetci využívat’ minimálne vo verzii Pro- fessional, ktorá je síce platená, no máme dostatok vol’ných licencií. V nižších verziách tohto nástroja, verzii Express, totiž nie je dostupná funkcionalita na testovanie. Testy môžeme spúšt’at’ lokálne alebo aj vzdialene, cez nástroj Jen- kins tak ako pri nástroji Selenium. To nám umožˇnujevytvárat’ mul- tiúlohy, v ktorých sa nachádzajú webové aj desktopové testy apli- kácií. Na desktopové automatizované testy musíme používat’ ser- very s operaˇcnýmsystémom Windows Server alebo obyˇcajnépoˇcí- taˇces operaˇcnýmsystémom Windows. Na danom stroji musí bežat’ aplikácia MSTest, ktorá testy spúšt’a a nemusíme tak na ne inštalo-

48 4. UKÁŽKOVÉPRÍKLADY

vat’ Visual Studio. Pri spúšt’aní testov je ale dôležité vybrat’ správnu verziu aplikácie. Ako verzovací program používame SVN s doplnkom AnkhSVN do vývojového prostredia. V blízkej budúcnosti by sme mali taktiež prejst’ na GIT. Identifikácia elementov sa vykonáva v nástroji Visual UI Auto- mation Verify, ktorý je zdarma a zobrazuje všetky potrebné údaje, ktoré sú pre identifikáciu prvkov potrebné. Tieto technológie sa využívajú na automatizáciu desktopových aplikácií a v nasledujúcej podkapitole si priblížime štruktúru samot- ného automatizaˇcnéhoprojektu.

4.2.2 Štruktúra projektu Tak ako webový projekt, aj ten desktopový sa skladá z modulov. Ešte pred pár dˇnamimal tento projekt celkom inú štruktúru a jednotlivé kategórie boli rozdelené medzi úplne odlišné moduly. Pri vytváraní novej štruktúry sme sa snažili ˇconajlepšie priblížit’ tej webovej, aby sme mali projekty ˇconajviac jednotné. Starý regresný projekt sa využíval už takmer dva a pol roka. Všetci z automatizácie sme sa na ˇnomzaˇcínaliuˇcit’ a vytvárat’ svoj prvý kód. Postupom ˇcasusme do procesu automatizácie zaˇcleniliaj zruˇc- nejších testerov, ktorí mali programátorský základ. Zaškolili sme ich na proces automatizácie a sami zaˇcalivytvárat’ webové aj deskto- pové testy. Ked’že sme nemali rôzne pomocné nástroje, ako, naprí- klad, Crucible, ktorý slúži na revíziu vytvoreného kódu, projekt sa stal t’ažšie udržiavetel’ným a tvorilo sa v ˇnomvel’a duplicity. Nová štruktúra programu slúži na zjednodušenie práce a mini- malizovanie kódu, ktorý je potrebný na automatizovanie testov. Na- ším ciel’om bolo vytvorit’ ˇconajvšeobecnejšiu funkcionalitu, v ktorej bude jednoduchá orientácia a vyhneme sa tak aj duplicitnému kódu. Do procesu sme zapojili aj nástroje Crucible, prostredníctvom kto- rého poskytujeme kontrolu a spätnú väzbu tvorcom zautomatizova- ných scenárov. Využívame aj nástroj JIRA, v ktorom sa dá sledovat’ celý proces automatizácie scenára od jeho vytvorenia a pridania do regresného katalógu, až po naimplementovanie a schválenie, ked’ je už pripravený na spúšt’anie. Projekt sa skladá z piatich modulov, ktoré sa využívajú s danými

49 4. UKÁŽKOVÉPRÍKLADY

Obr. 4.2: Štruktúra desktopového projektu

závislost’ami, ktoré sú zobrazené na obrázku 4.2. Prvým je modul Common, ktorý je spoloˇcnýpre všetky destiná- cie, pre ktoré sú projekty vytvorené. Ide o Cesko/Slovensko,ˇ Cínuˇ a Bielorusko. Do všetkých projektov sa pridáva cez externú závis- lost’ v SVN nástroji a nachádzajú sa tu všetky potrebné triedy, ktoré sú rovnaké v rámci projektov. Sú to triedy ako porovnávaˇcobrázkov, generátor dát, kolektor chýb, trieda na prácu s databázou, trieda na vytváranie snímok pracovnej plochy, Tesseract OCR a aj triedy Whi- teWrapper a WrapperPool na prácu s knižnicou White. V abstraktných triedach GenericForm a GenericTest sa nachádza všetka potrebná fun- kcionalita, ktorá je spoloˇcnápre ich potomkov, vrátane nastavovaní a inicializovaní napríklad databáz. Všetky ostatné moduly ho k svo- jej funkˇcnostivyužívajú. Druhý modul sa nazýva API a závislost’ má iba na module Com- mon. Nachádzajú sa tu triedy, ktoré reprezentujú okná aplikácie, tak- tiež sú mapované v pomere 1:N, ˇcižejedno okno sa môže skladat’ z viacerých tried. Všetky tieto triedy sú potomkami triedy BaseForm, ktorá zas dedí z triedy GenericForm a nachádzajú sa v nej všetky spoloˇcnémetódy a premenné, ktoré sú už ale rozdielne pre každú implementáciu odlišnej krajiny. V adresári Wrappers sa nachádzajú všetky potrebné triedy na uchovávanie si hodnôt, Utilities ponúkajú doplˇnujúcufunkcionalitu, Resources obsahujú jazykové lokalizácie a v module sa nachádzajú taktiež enumerácie. Tretí je modul Dao, ktorého triedy obsahujú konštanty definícií

50 4. UKÁŽKOVÉPRÍKLADY

SQL dotazov a taktiež metódy, ktoré s nimi pracujú. V tomto module môžeme tiež vytvárat’ objekty z tried Wrappers z modulu API, a preto má naˇnaj závislost’. Štvrtým modulom je Test, v ktorom sa nachádzajú všetky testové triedy. Tie sú logicky usporiadané do adresárov podl’a ˇcastiapliká- cie, ktorú testujú. Samotná testovacia trieda sa ešte skladá z testova- cích metód, ktoré predstavujú jednotlivé scenáre. Všetky testovacie triedy dedia z triedy HomerBaseTest, ktorý taktiež zastrešuje všetku spoloˇcnúfunkcionalitu, ktorá je unikátna pre danú destináciu. Súbor App.config obsahuje konfiguráciu, podl’a ktorej sa celý test riadi. Na- chádza sa v nej cesta k aplikácii, názov databázy, užívatel’ské meno a heslo na prihlásenie do aplikácie a taktiež do databázy. Ak chceme spúšt’at’ testy v poradí, ktoré si urˇcíme,tak na to slúžia organizéry testov, takzvané OrderedTest súbory. Ak totiž spúšt’ame testy, ktoré majú rovnakú anotáciu, budú sa vykonávat’ náhodne. Posledným modulom je WebTest, ktorý prináša možnost’ testovat’ webové aplikácie priamo z tohto projektu. Zatial’ ale nie je naimple- mentovaný, pretože sa snažíme vyhnút’ kombinovaným scenárom. Inak by vznikla duplicita tried, ktoré reprezentujú webové stránky v desktopovom aj webovom projekte a boli by obtiažne udržiave- tel’né. V budúcnosti sa ale budeme musiet’ aj s týmto problémom vysporiadat’. Toto bolo predstavenie desktopového projektu na automatizáciu testov, ktorý je vel’mi ˇcerstvýa veríme, že nám prinesie ešte väˇcšiu radost’ a chut’ do práce s prehl’adnejším projektom a kódom.

4.3 Ranorex

Nástroj Ranorex je celosvetovo populárny a používajú ho aj také firmy, ako, napríklad, Siemens, Lufthansa, Cisco, Continental, Mo- torola, Toshiba, Adidas a mnoho d’alších zvuˇcnýchmien. V tejto podkapitole bude predstavený návrh projektu, keby sa zaviedol v automatizaˇcnomprocese firmy EmbedIT a nahradil tak existujúce riešenia.

51 4. UKÁŽKOVÉPRÍKLADY

4.3.1 Použité technológie

Hlavným nástrojom, ktorý by bol použitý, je Ranorex, ktorý ale nie je vol’ne dostupný. Je to platený nástroj a museli by sme zakúpit’ li- cencie na každý poˇcítaˇcalebo server, na ktorom by sme testy vyvíjali a spúšt’ali. Naskytujú sa dve riešenia, ako by vyzeral proces automatizácie regresných scenárov. Prvý by využíval nástroj Ranorex ako tvorcu testov, to znamená že, všetky by sa vytvárali iba pomocou tohoto ná- stroja vo vývojovom prostredí Ranorex Studio IDE. Prostredníctvom neho by sme najprv kroky scenárov nahrali cez Ranorex Recorder. Ak by sme niektoré potrebovali upravit’, urobili by sme zmeny v na- hratých krokoch. Na identifikáciu elementov by sme používali Ranorex Spy a mohli si s ním vytvárat’ rôzne repozitáre, ktoré by sa používali pre dané okná a boli by tak lepšie udržiavatel’né. Ranorex Test Suite by sme využívali na kombinovanie nových scenárov s už existujúcimi. Využívali by sme vytvorené kroky star- ších scenárov v tých nových a vyhli by sme sa tak redundantnému kódu a zlej udržiavatel’nosti. Druhá alternatíva by primárne využívala Visual Studio k tvorbe automatizovaných testov v nástroji Ranorex. Importovali by sme si doˇnvšetky potrebné závislosti a všetky testy by v tomto riešení boli naprogramované. Podl’a môjho názoru by tak vznikla väˇcšiavol’- nost’ a priestor pre kreativitu a dokonalejšie otestovanie aplikácie. Identifikácia elementov by bola taktiež vykonávaná prostredníc- tvom Ranorex Spy a mohli by sme využívat’ RanoreXPath identifiká- tory alebo by sme si vždy vytvorili repozitáre. Tie by reprezentovali nami požadované okná a Ranorex Spy by nám tak vytvoril automa- tickú identifikáciu elementov, ktorú by sme potom v projekte l’ahko pridali, nainicializovali a používali. Keby sa vyskytla nejaká zmena v identifikátore a prestali by fungovat’, po znovuotvorení v Ranorex Spy by sme si ich mohli l’ahko menit’. Pre obe alternatívy tvorby automatizácie by platilo, že nahraté testy by sme zoskupovali do skupín podl’a modulov, ktoré testujú a jednoducho by sa tak dalo vybrat’, ˇcochceme v danom momente otestovat’. Na vzdialené spúšt’anie testov by sme nad’alej využívali Jenkins,

52 4. UKÁŽKOVÉPRÍKLADY ktorý Ranorex podporuje a dá sa naˇnl’ahko napojit’. Takisto podpo- ruje aj automatické reportovanie v nástroji JIRA, takže by sme mali zautomatizované aj zadávanie chýb. Reporty by sme si upravili na náš požadovaný formát, ked’ by sme si upravili poskytnutú šablónu. Posielali by sme si ich na repor- tovací server a taktiež aj na mail, aby sme okamžite poznali výsledky behu testov.

4.3.2 Štruktúra projektu Pri návrhu podoby projektu s využitím nástroja Ranorex sa dá vy- mysliet’ o nieˇcolepšia architektúra, aby sme pomocou nej mohli tes- tovat’ aj kombinované scenáre oboch typov aplikácií v jednom teste. Jednotný programovací jazyk C# ul’ahˇcujevyhýbanie sa duplicitným triedam, ktoré predstavujú jednotlivé okná alebo stránky. Prvá štruktúra by mohla vyzerat’ ako na obrázku 4.3.

Obr. 4.3: Štruktúra Ranorex projektu — možnost’ 1

Bol by vytvorený jeden projekt, ktorý by obsahoval automatizá- ciu oboch typov aplikácií a bol by rozdelený na 9 modulov. Prvý modul Common by slúžil na úˇcelytak, ako doteraz slúži v existujúcich projektoch. Zastrešoval by spoloˇcnúfunkcionalitu, kto- rá sa zhoduje na všetkých destináciách.

53 4. UKÁŽKOVÉPRÍKLADY

V d’alších moduloch by sa projekt zaˇcalrozdel’ovat’ podl’a typu aplikácie. Nasledujúce dva moduly by sa nazývali Repo_WEB a Repo_- FAT, v ktorých by sa nachádzali identifikátory elementov, vygenero- vané priamo nástrojom Ranorex Spy. Takisto by sa tu nachádzali aj obrázky, ktoré Ranorex taktiež dokáže vyhl’adávat’ a porovnávat’. Každý z nich by sa tak zameriaval na svoj typ aplikácie. Dalšieˇ dva moduly by sa nazývali API_WEB a API_FAT. Obsa- hovali by podobnú funkcionalitu ako v existujúcich riešeniach. Na- chádzali by sa v nich triedy, ktoré reprezentujú okná alebo stránky, Wrappers by uchovávali dáta, Utilities by poskytovali doplˇnujúcu funkcionalitu a v neposlednom rade Resources by reprezentovali ja- zykovú lokalizáciu. Nasledovali by dva moduly DAO_WEB a DAO_FAT. Poskytovali by funkcionalitu na komunikáciu s databázou, SQL dotazy a funkcie na prácu s databázou. Taktiež by používali Wrappers z API ako DTO objekty. Nakoniec by sme vytvorili tri moduly, z ktorých by každý repre- zentoval rôzny typ testu, vrátane kombinovaného. Ich názvy by boli Test_WEB, Test_DUAL a Test_FAT. Kombinované testy by tak mali z modulu Test_DUAL referenciu na oba typy a mohli by kombinovat’ využívané triedy. Druhá možnost’, akou by sme sa mohli uberat’, je vol’ba men- šieho poˇctumodulov. Vyššie spomínané moduly by tak neboli dup- likované pre webové a desktopové testy, ale mali by vždy spoloˇcný modul, v ktorom by bolo iba prostredníctvom adresárov rozlíšené, o aký typ aplikácie ide. To by ale mohlo viest’ k enormnému nárastu vel’kostí modulov a mohli by sa stat’ menej prehl’adnými. Tretia možnost’ by mohla využívat’ doplnkový nástroj SVN a jeho externú závislost’. Pomocou nej by sa vytvoril spoloˇcnýmodul, ktorý by reprezentoval kombinovaný test aplikácií a obsahoval by repre- zentantov okien aj stránok. Museli by sme si ale dávat’ vel’ký pozor na prípadnú duplicitu, pretože by sme nepretržite museli mat’ pre- hl’ad, ˇcisa daná trieda nádohou už v spoloˇcnommodule nenachá- dza, alebo ˇciv ˇnomnebude niekedy v budúcnosti potrebná. Projekty by boli teda rozdelené na dva samostatné celky s využitím externého modulu. Toto boli jednotlivé návrhy architektúry projektu na automatizá- ciu webových a desktopových aplikácií pomocou nástroja Ranorex.

54 4. UKÁŽKOVÉPRÍKLADY

Obr. 4.4: Štruktúra Ranorex projektu — možnost’ 2

V d’alšej kapitole (Kapitola 5) sa pozrieme na bližšie špecifikované rozdiely všetkých troch nástrojov.

55 5 Porovnanie jednotlivých nástrojov

Na svete existuje množstvo nástrojov na automatizáciu aplikácií, no všetky sa od seba nejakým spôsobom líšia. Ciˇ už typom aplikácie, ktorú môžu testovat’, cenou, za ktorú sa dajú predplatit’, alebo rôz- nymi inými vlastnost’ami. Momentálne sa vo firme EmbedIT vyvíjajú webové a desktopové aplikácie, na ktoré vytvárame automatizované testy v nástrojoch Se- lenium a White. Mojou úlohou bolo porovnat’ ich s nástrojom Rano- rex a zistit’, ˇciby nebol prípadný prechod práve na Ranorex v našom automatizaˇcnomprocese vhodnejší. Táto kapitola sa zaoberá porovnaním týchto troch nástrojov. V pr- vom rade bude porovnaná štruktúra programov, kombinované tes- tovanie webových a desktopových aplikácií, identifikácia elementov, spúšt’anie testov, generovanie reportov o výsledkoch a v neposled- nom rade taktiež cena, za ktorú je možné dané nástroje používat’.

5.1 Štruktúra projektu

5.1.1 Existujúce riešenie Aktuálne projekty sú rozdelené na dva na sebe nezávislé celky tak, ako to bolo popísané v predošlej kapitole. Aktuálne vieme automa- tizovat’ oba druhy aplikácií aj kombinovane, ked’ v desktopovom projekte vytvoríme stránky a pomocou nástroja PhantomJS webové scenáre zautomatizujeme. Snažíme sa tomu ale zatial’ vyhýbat’, aby sme nevytvárali redundantné objekty z dôvodu používania iného ja- zyka pre každý z projektov.

5.1.2 Ranorex Ranorex ponúka možnost’ vyriešit’ vyššie popísaný problém dup- licít, ked’že testy pre oba typy aplikácií sú vytvorené v jazyku C#. Mohli by sme teda použit’ jednu z troch navrhnutých alternatív pre celkovú podobu projektu s využitím nástroja Ranorex. Azda najlep- šia by bola tá prvá, ktorá obsahuje 9 modulov a každý reprezentuje jednu funkcionalitu — bud’ webovú, alebo desktopovú.

56 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV 5.2 Kombinované testovanie

5.2.1 Existujúce riešenie

Pri implementovaní scenárov sa môže obˇcasvyskytnút’ taký, ktorý kombinuje testovanie webovej a desktopovej aplikácie. Kvôli tomuto dôvodu sme vytvorili nasledovné riešenie tejto situácie. V projekte, ktorý testuje desktopové aplikácie, sme pridali samos- tatný modul WebTest, ktorý slúži práve na automatizáciu kombino- vaných scenárov. Na to, aby sme v tomto projekte mohli testovat’ we- bové aplikácie bez použitia nástroja Selenium, sme použili rozšírenie PhantomJS, ktoré nám umožˇnujes použitím JavaScript API vytvárat’ automatizovanú navigáciu na stránkach, interakciu s elementmi, vy- tváranie snímok obazovky, simuluje užívatel’skú interakciu a prináša aj rôzne d’alšie možnosti. Toto riešenie sa ale zatial’ snažíme využívat’ ˇconajmenej. Je to preto, lebo používame dva rôzne programovacie jazyky, a teda všetky existujúce stránky, ktoré sme vytvorili v projekte na automatizáciu webových testov by sme museli znovu naimplementovat’ aj v pro- jekte na automatizáciu desktopových aplikácií, aby mohli byt’ vy- užité pri kombinovanom testovaní. To by sa znaˇcneodzrkadlilo na udržiavaní duplicitných tried a pribudla by nám tak práca naviac.

5.2.2 Ranorex

Ked’že nástroj Ranorex dokáže automatizovat’ webové aj desktopové aplikácie, ul’ahˇcujeto možnost’ kombinovaného testovania. Nie je potrebné využívat’ d’alšie potrebné doplˇnujúceknižnice. Daný kom- binovaný scenár je tak možné l’ahko naimplementovat’, no na druhej strane takéto scenáre môžu byt’ vel’mi dlhé, a tak aj nároˇcnéna udr- žiavanie. Musíme vziat’ do úvahy aj to, že ak budeme implementovat’ we- bové a desktopové scenáre v Ranorexe, bude vhodnejšie vytvorit’ dva separátne projekty, pretože postupom ˇcasuby mohol spoloˇcný projekt narást’ do takých rozmerov, že by prestal byt’ prehl’adný. Ak by sme ich aj rozdelili, dali by sa naprieˇcnimi využívat’ spo- loˇcnétriedy. V nich by boli naimplementované stránky, ktoré sú spo- loˇcnéako pre desktopové, tak aj pre webové projekty a prostredníc-

57 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV tvom externej závislosti cez verzovací systém by takéto triedy mohli byt’ zdiel’ané, a tým by sme sa vyhli ich duplicite. V tomto prípade nám to dovol’uje fakt, že na oboch projektoch využívame rovnaký programovací jazyk C#.

5.3 Identifikácia elementov

5.3.1 Existujúce riešenie Pri webových testoch je identifikácia elementov založená na XPath. Tie, ktoré majú priradené identifikátory, ako, napríklad, name alebo id, sa dajú vytvorit’ priamo z HTML kódu stránky. Ak vyhl’adávame elementy, ktoré majú zložitejšiu XPath, možeme k tomu použit’ ná- stroje, ako FireBug, ktorý je doplnkom do prehliadaˇcaFirefox. Staˇcí klik a XPath je vygenerovaná. Nanešt’astie, niekedy sú tieto XPath príliš dlhé a komplikované a je potrebné ich zjednodušit’. To už je ale na znalostiach a skúsenostiach programátora automatizovaného testu. Desktopové alikácie sú na tom o nieˇcohoršie. White prináša mož- nost’ identifikovat’ elementy z procesov a na to používame prog- ramy, ako, napríklad, Visual UI Automation Verify. Tento program nám zobrazí vlastnosti elementov, ako sú AutomationID, name a d’al- šie. Pomocou týchto identifikátorov sme schopní identifikovat’ ele- menty. Ked’že ˇcast’ funkcionality desktopových aplikácií bola naprogra- movaná v jazyku Visual Basic 6.0, vlastnosti elementov nie sú do- stupné a musíme použit’ OCR nástroj. Ním je Tesseract OCR a pro- stredníctvom neho identifikujeme elementy. V mnohých prípadoch ale nie je spol’ahlivý pri identifikácii textu. Z tohoto dôvodu musíme ˇcastovytvárat’ vel’mi komplikované regulárne výrazy, ktoré budú odpovedat’ identifikovanému textu.

5.3.2 Ranorex Ranorex používa na identifikáciu elementov vlastný nástroj, Rano- rex Spy, ktorý vytvára RanoreXPath výrazy. Tento proces taktiež po- zostáva z identifikovania vlastností z procesov. Spomínaný nástroj je vel’mi silný, dokážeme si v ˇnomtvorit’ vlastné XPath ret’azce, upra-

58 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV

vovat’ ich, modifikovat’ váhu výrazu, a to všetko prostredníctvom UI tohoto nástroja. Nanešt’astie, niektoré tieto výrazy sú tiež kompliko- vané a je potrebné ich optimalizovanie. Ranorex má svoje vlastné rozšírenie na identifikáciu textu, ktorý sa nedá získat’ inak. Môže sa stat’, že niektorý text nesprávne identi- fikuje, ˇcoje ojedinelé a je omnoho spol’ahlivejší ako Tesseract OCR. Porovnávanie obrázkov prostredníctvom nástroja Ranorex je tak- tiež možné. Staˇcípridat’ obrázok, ktorý sa má vyhl’adat’ vo formáte .bmp alebo .png a Ranorex sa ho pokúsi nájst’. Táto funkcionalita je tiež vel’mi spol’ahlivá, ˇcopridáva d’alšiu výhodu tomuto nástroju.

5.4 Spúšt’anie testov

5.4.1 Existujúce riešenie

Webové testy sú naprogramovené v jazyku Java s použitím JUnit frameworku. Umožˇnujenám to spúšt’anie individuálnych testov, ce- lých testových tried alebo testových skupín. Precízna selekcia je do- siahnutá používaním testovacích anotácií alebo argumentov v prí- kazovom riadku mavenu nasledovne: mvn test -Dtest=. Ked’že sú tieto testy napísané v jazyku Java, ktorý je multiplatformný, ich vykonávanie sa odohráva na linuxových strojoch. Desktopové testy môžu byt’ spúšt’ané lokálne s použitím nástroja Visual Studio IDE alebo vzdialene prostredníctvom testovacieho do- plnku Test Agent, ktorý je nainštalovaný na vzdialenom poˇcítaˇcialebo serveri. Pri tomto druhom spôsobe sa spúšt’ajú z nástroja Jenkins prostredníctvom príkazového riadku na danom stroji nasledovne: MSTest /testcontainer:TestProject.dll /resultsfile:testResults1.trx. Testy mô- žu byt’ taktiež spustené individuálne v rámci, skupín v ktorých sú priradené, alebo prostredníctvom takzvaných orderedtest zoznamov, kde sa vykonávajú v presne danom poradí. Testovacie skupiny totiž v tomto prípade spúšt’ajú testy náhodne. V oboch prípadoch môžu byt’ testy spustené prostredníctvom vý- vojového prostredia alebo cez príkazový riadok, no možnost’ kroko- vania priebehu testu je dostupná len prostredníctvom IDE.

59 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV

5.4.2 Ranorex Pri spúšt’aní testov s nástrojom Ranorex je potrebné vytvárat’ sku- piny, ktoré budú spúšt’ané prostredníctvom Ranorex Test Suite. Kaž- dá skupina nami definovaných testov by tak predstavovala logický celok, ktorý by bol spúšt’aný lokálne, ale aj vzdialene na patriˇcných strojoch. Pri generovaní skupín sa vytvára spúšt’atel’ný súbor .exe, ˇco znaˇcí,že testy môžu byt’ spúšt’ané iba na strojoch s operaˇcnýmsys- témom Windows. Pri spúšt’aní cez príkazový riadok staˇcízadat’ pa- rametre .exe /argument, kde argument predstavuje definované meno report a cesta, kde má byt’ uložený, možnost’ komprimovania reportu na formát .zip, definovat’ stupeˇn reportu, špecifický dátový rozsah alebo vykonat’ konfiguráciu testo- vanej skupiny testov. Ak by sme potrebovali spustit’ iba jeden samostatný test, musel by byt’ taktiež pridaný do skupiny, ktorá by obsahovala len ten je- den test. Azda najdôležitejší je fakt, že testy nedokážu byt’ spúšt’ané paralelne, pretože potrebujú k fungovaniu operácie, ktoré vykonáva klávesnica a myš.

5.5 Reportovanie výsledkov

5.5.1 Existujúce riešenie Všetky webové automatizované testy využívajú našu end-to-end-test- support library knižnicu, ktorá sa stará o spúšt’anie testov, zbieranie chýb a vytváranie snímok vždy, ked’ test spadne. Desktopové aplikácie používajú triedu ScreenshotTaker, ktorá sa nachádza v module Common a vytvára snímky pri spadnutí testu, no iba na vzdialenom poˇcítaˇcialebo serveri. V tomto momente teda vytvárame snímky iba pri páde apliká- cií, pretože sa snažíme šetrit’ úložné miesto a predíst’ zmäteniu pri evaluácii. Tam, kde je to možné, sa snažíme využívat’ kolektor chýb, ktorý výrazne zrýchl’uje proces regresného testovania tým, že test sa ne- ukonˇcíokamžite, ked’ sa aktuálna hodnota nebude zhodovat’ s tou oˇcakávanou,ale bude pokraˇcovat’ d’alej a na jeho konci sa len uis- tíme, ˇcitakýchto výskytov nebolo viac a máme tak otestované, že

60 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV aplikácia funguje až na malé detaily. Ked’ sú testy spúšt’ané prostredníctvom nástroja Jenkins, posled- ná fáza obsahuje zavolanie nášho nástroja custom report creator tool, ktorý vygeneruje dokument obsahujúci detailné vyhodnotenie kaž- dého testu a obsahuje taktiež históriu ich úspešnosti. Výsledky testov sú v nástroji Jenkins zobrazené prostredníctvom doplnku Surefire report. Každý vykonaný test si uchováva ˇcasbehu a dáta, ktoré použil. Testy ukonˇcenéchybou majú taktiež snímku, chybovú hlášku a výpis zásobníka. V tomto výpise sa nachádzajú aj priame odkazy na snímky, na ktoré budeme po kliknutí presmero- vaní.

Obr. 5.1: Úvodná strana

Obr. 5.2: Detail výsledkov

61 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV

Obr. 5.3: História výsledkov

5.5.2 Ranorex

Medzi jednu z najlepších funkcií Ranorexu patrí reportovanie. Pre každý beh testu je vygenerovaná stránka, ktorá zobrazuje jednotlivé kroky testu s výsledkami. Nakonfigurovaný môže byt’ tak, aby vy- tváral snímku pre každý krok, iba pre požadované kroky alebo len ked’ test spadne na chybu. Ked’ spúšt’ame testy z nástroja Jenkins, žiadny report ani snímka nebudú priamo viditel’né. Je potrebné si bud’ report stiahnut’ do po- ˇcítaˇca(musíme mat’ ale prístup na server), alebo si vytvoríme web- server, ktorý bude automaticky výsledky publikovat’. Report zobrazuje každý krok a taktiež je možné ho analyzovat’ do h´lbky prostredníctvom rozbal’ovacieho tlaˇcítka.V tomto zobrazení sa dajú vidiet’ doplˇnujúceinformácie, ako napríklad: systémové in- formácie o ˇcase,názov stroja, operaˇcnýsystém, rozlíšenie obrazovky, jazyk, trvanie, celkový poˇcetchýb, celkový poˇcetvarovaní alebo glo- bálne parametre. Ak test využíva lokálne parametre, napríklad z ex- terného súboru, sú v reportovom kroku zobrazená aktuálne použité parametre, ako to môžeme vidiet’ na obrázku 5.5. Detailne zaznamenané správy, ktoré sú generované nahrávaním alebo modulom kódu, zobrazujú ˇcasovúznámku, reportovaciu vrs- tvu, kategóriu a text správy. Po kliknutí na Jump to item tlaˇcítkonás to zavedie priamo na daný riadok kódu. Pri možnosti Open in Spy môžeme analyzovat’ RanoreXPath výraz, ktorý bol v kroku použitý.

62 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV

Obr. 5.4: Ranorex report [18]

V rámci nástroja Ranorex sme schopní používat’ rôzne úrovne reportovania, od krokovacej správy až po chybovú informáciu. Sme taktiež schopní definovat’ si svoju vlastnú reportovaciu úroveˇnk tým preddefinovaným. Tie totiž dokážu pomôct’ pri vytváraní struˇcných a lepšie ˇcitatel’ných reportoch. Od Ranorex verzie 4.0.0 bol formát vlastných reportov zmenený z jedného súboru na šablónovú zložku uchovávajúcu si všetky po- trebné súbory. Vygenerovaný je teda súbor s príponou .rxlog. JIRA je nástroj, do ktorého zadávame chyby a ponúka REST we- bové služby. Je teda možné zasielat’ chyby automaticky. Knižnice na

63 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV

Obr. 5.5: Ranorex report — detail [18] komunikáciu s nástrojom JIRA sú nástrojom Ranorex podporované, no nie sú oficiálne, a preto nie sú poskytované pod jeho záštitou.

5.6 Cena

5.6.1 Existujúce riešenie Oba existujúce projekty využívajú vol’ne dostupné nástroje na auto- matizáciu. Výnimkou je iba Visual Studio IDE, ktoré musí mat’ ver- ziu minimálne Professional. Vzhl’adom na tento fakt sú náklady na automatizáciu minimalizované. Licencie na Visual Studio IDE majú iba vývojári, ktorí sa aktívne zapájajú v automatizaˇcnomprocese desk- topových aplikácií a na samotné vzdialené spúšt’anie testov nie sú využívané. To rieši MSTest, ktorý je zdarma a je nainštalovaný na strojoch, na ktorých sa testy vzdialene spúšt’ajú.

5.6.2 Ranorex Na rozdiel od existujúcich riešení je Ranorex platený nástroj. Existuje 30-dˇnováskúšobná verzia, ktorá poskytuje plnú funkcionalitu tohto nástroja, aby ho bolo možné odskúšat’ tak, ako je to v našom prípade. Platená verzia existuje vo dvoch verziách, Runtime alebo Pre- mium. Prvá slúži iba na spúšt’anie testov, je zdiel’aná, ˇcoznamená, že nie je viazaná na konkrétny poˇcítaˇca môže byt’ distribuovaná, no

64 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV vždy môže byt’ aktívna iba na jednom zo strojov. Použitá môže byt’ na fyzických alebo na virtuálnych strojoch. Nie je ˇcasovoobmedzená a zah´rˇnaúdržbu na jeden rok a jej cena je 690 eur bez DPH. Druhá verzia je rozdelená na dva produkty, zdiel’aný, ktorý môže byt’ distribuovaný ako v predošlom prípade s cenou 1990 eur bez DPH, a viazaný, ktorý je uzamknutý na jeden fyzický stroj a stojí 3490 eur bez DPH. Oba produkty pridávajú k možnosti spúšt’ania testov aj ich tvorbu a údržbu. Licencie platia taktiež neobmedzene a k jednému roku údržby sú pridané aj dostupné aktualizácie a pro- fesionálna podpora.

Obr. 5.6: Ceny licencií [18]

Ak by sme nahradili existujúce riešenie nástrojom Ranorex, bolo by to dost’ finanˇcnenároˇcnéa tým, že sa vel’mi rýchlo vyvíja, by sme boli nútení kupovat’ stále nové a nové aktualizácie, a taktiež by sme potrebovali licencie na stroje, ktoré slúžia na vzdialené spúšt’anie tes- tov.

5.7 Zhrnutie

Prvou charakteristikou, na ktorú bolo porovnanie zamerané, bola štruktúra projektov. Ak by sme chceli použit’ Ranorex v automatizaˇc-

65 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV nom procese, museli by sme vytvorit’ nový projekt, kde by sme kom- pletne zmenili celú štruktúru. Projekt, ktorý je zameraný na automa- tizáciu webových testov, využíva programovací jazyk Java, takže by sme ho úplne celý museli prepísat’ do jazyka C#. Elementy, ktoré boli v starých projektoch identifikované, by sme museli opät’ identi- fikovat’ pomocou RanoreXPath alebo ich všetky postupne pridat’ do repozitárov. Taktiež by sme museli prerobit’ funkcie, ktoré s elemen- tami pracujú a použit’ len funkcionalitu, ktorú nám ponúka Ranorex. Dalšouˇ charakteristikou bola možnost’ kombinovaného testova- nia oboch typov aplikácií. Ak by sme využili Ranorex a projekty by sa spojili do jedného, bola by to vel’ká výhoda, pretože by sme sa mohli vyhnút’ duplicitným triedam, ktoré je potrebné vytvárat’ v oboch existujúcich riešeniach. Nasledovala identifikácia elementov. V súˇcasnostina ˇnuvyuží- vame FireBug pre web a Visual UI Automation Verify pre deskto- pové aplikácie. U oboch z nich je potrebné manuálne zistenie tej najoptimálnejšej identifikácie. Ranorex prináša nástroj Ranorex Spy, ktorý automaticky identifikuje elementy a prináša možnost’ pridá- vat’ ich do repozitárov. Tak z nich môžeme v kóde získavat’ identi- fikátory prvkov, ˇcoje d’alšie pozitívum, ktoré Ranorex ponúka. Do- káže aj lepšie identifikovat’ text pomocou OCR. Spúšt’anie testov je v existujúcom riešení vykonávané na strojoch s operaˇcnýmsystémom Linux pre webové testy a Windows Server a Windows 7 pre desktopové testy. Ranorex takúto možnost’ nepri- náša. Podporuje iba Windows, ˇconekorešponduje s firemnou politi- kou multiplatformnosti. Reportovanie výsledkov je riešené prostredníctvom nami vytvo- rených programov a plne postaˇcujúpre úˇcelyidentifikovania chýb. Príchodzí report zobrazuje, ktoré testy skonˇcilichybou a my potom na nástroji Jenkins vieme identifikovat’, kde a preˇcochyba nastala. Je to docielené aj vd’aka snímkam obrazovky poˇcaspádu testu. Ra- norex prináša report, ktorý je prehl’adný, no niekedy až príliš pod- robný. Orientácia v ˇnommôže byt’ chaotická, ˇcozvýši ˇcasidentifiko- vania chyby a následne aj jej zadania do nástroja JIRA. V neposlednom rade bola porovnávaná cena jednotlivých nástro- jov. Pri súˇcasnomstave automatizácie využívame iba platený IDE nástroj Visual Studio. Ak by sme zaˇcalivyužívat’ Ranorex, ktorý nie je vol’ne dostupný, museli by sme investovat’ do nemalého poˇctuli-

66 5. POROVNANIEJEDNOTLIVÝCHNÁSTROJOV cencií. Napomáha k tomu aj fakt, že pri vzdialenom spúšt’aní by mu- seli byt’ na každom stroji nainštalované základné licencie na spúšt’a- nie testov. Musel by sa tiež zvýšit’ poˇcetstrojov, pretože tie s operaˇc- ným systémom Linux nie sú podporované.

67 6 Záver

Ciel’om tejto diplomovej práce bolo podrobné preštudovanie auto- matizaˇcnéhonástroja Ranorex, zanalyzovanie a jeho následné porov- nanie s už existujúcimi nástrojmi, ktoré sú využívané v procese au- tomatizácie testov webových a desktopových aplikácií v spoloˇcnosti EmbedIT. Pozitíva, ktoré by priniesol nástroj Ranorex, sú: lepšia možnost’ kombinovaného testovania webových a desktopových aplikácií v jed- nom projekte bez vytvárania duplicitných tried, lepšia identifiká- cia elementov v prípade použitia repozitára a lepšie rozpoznávanie textu pomocou OCR. Medzi negatíva, ktoré by nastali pri prechode na nástroj Ranorex, patrí nová štruktúra projektu, pretože existujúce projekty by sa mu- seli kompletne prepísat’ a prispôsobit’ novej štruktúre. Pri spúšt’aní testov by sme mohli využívat’ iba platformu Windows a všetky stroje s operaˇcnýmsystémom Linux by boli nevyužité. Report, ktorý je ge- nerovaný testami, by bol príliš detailný a t’ažšie by sa v ˇnomorien- tovalo. V neposlednom rade medzi negatíva tohoto nástroja patrí aj cena licencií, ktoré by museli byt’ pravidelne obnovované. Po porovnaní a následnom zhodnotení pozitív a negatív nedo- poruˇcujemnahradit’ existujúce nástroje Selenium a White nástrojom Ranorex. Prinieslo by to mnoho komplikácií, ktoré by boli zvládnu- tel’né, no ˇcasa peniaze, ktoré boli investované do vývoja existujúcich automatizovaných testov, by boli zbytoˇcné. Moja práca pomohla k identifikácii hlavných problémov, ktorým by sme museli ˇcelit’ pri prechode na nástroj Ranorex. Predstavovala tak základ pre vedenie firmy, aby sa rozhodli, ˇcipoužívaním no- vého nástroja docielia zlepšenie a zjednodušenie automatizaˇcného procesu. Navrhol som štruktúru nového projektu, ktorý by využíval ná- stroj Ranorex, a taktiež som vylepšil existujúci projekt slúžiaci na au- tomatizáciu desktopových aplikácií.

68 Literatúra

[1] InformationWeek. Q&A: Bill Gates On Trustworthy Computing [online]. 2002 [cit. 2016-01-02]. Do- stupné z: .

[2] BOWEN, Rich, Daniel LOPEZ RIDRUEJO a Allan LISKA. Apa- che administrator’s handbook. Indianapolis: Sams, 2002, 422 s. ISBN 06-723-2274-9.

[3] ISTQB Exam Certification. What is Software Tes- ting? [online]. 2015 [cit. 2016-01-02]. Dostupné z: .

[4] IEEE standard glossary of software engineering terminology [on- line]. New York, N.Y.: Institute of Electrical and Electronics Engineers, 1990, 83 s. [cit. 2016-01-02]. ISBN 15-593-7067-X. Dostupné z: .

[5] HLAVA, Tomáš. Statické a dynamické testy. Testování soft- waru [online]. 2011 [cit. 2016-01-02]. Dostupné z: .

[6] Tutorialspoint. Software Testing - Methods [online]. 2015 [cit. 2016-01-02]. Dostupné z: .

[7] CHMURCIAK,ˇ Dávid. Automatizace regresního testování webové aplikace [online]. Brno, 2013 [cit. 2016-01-02]. Diplomová práca. Masarykova univerzita, Fakulta informatiky. Vedúci práce Barbora Bühnová Dostupné z: .

69 6. ZÁVER

[8] MOSLEY, Daniel J. a Bruce A. POSEY. Just enough software test automation. 1. vyd. Upper Saddle River: Prentice Hall, 2002, 288 s. ISBN 01-300-8468-9.

[9] FEWSTER, Mark a Dorothy GRAHAM. Software test automa- tion: effective use of test execution tools. 1. vyd. Reading: Addison- Wesley, 1999, 600 s. ISBN 02-013-3140-3.

[10] HAYES, Linda G. The automated testing handbook. 2. vyd. Richard- son: Software Testing Institute, 2004, 182 s. ISBN 09-707-4650-4.

[11] BLACK, Rex a Jamie L. MITCHELL. Advanced software testing Vol. 3. 1. vyd. Santa Barbara: Rocky Nook, 2011, 608 s. ISBN 978- 1-933952-39-0.

[12] Webová integrace. Manažment kvality a testovanie softvéru ako sú- ˇcast’ webovej integrácie [online]. 2012 [cit. 2016-01-05]. Dostupné z: .

[13] Štandardný glosár termínov používaných v softvérovom testo- vaní [online]. 2. 2007, 42 s. [cit. 2016-01-02]. Dostupné z: .

[14] EmbedIT. About us [online]. 2015 [cit. 2016-01-02]. Dostupné z: .

[15] SeleniumHQ: Browser Automation. Selenium Documentation [online]. 2012 [cit. 2016-01-02]. Dostupné z: .

[16] Sauce Labs. Selenium Grid: Do You Have What it Takes? [on- line]. [cit. 2016-01-06]. Prevzaté z: .

[17] White Home. TestStack Documentation [online]. 2015 [cit. 2016- 01-02]. Dostupné z: html>.

70 6. ZÁVER

[18] Ranorex. User Guide [online]. 2015 [cit. 2016-01-02]. Dostupné z: .

71 A Príloha

A.1 Testovací scenár

Nasledujúci scenár slúžil k tvorbe vzorových testov pre túto diplo- movú prácu, ktoré sa nachádzajú v zložke zdrojových kódov.

72