Bankovní institut vysoká škola Praha

Bankovní institut vysoká škola Praha Informatika a kvantitativní metody

Automatizační testovací nástroje Diplomová práce

Autor:

Bc. Marek Feňko Informační technologie a management, EKMAN ITMP

Vedoucí práce:

Praha

Ing. Vladimír Beneš, Ph.D.

Duben, 2014

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

V Praze, dne

Marek Feňko

Anotace Testování je nedílnou součástí každého vývojového procesu softwaru. Tato diplomová práce se věnuje automatizačním testovacím nástrojům a jejich využití v praxi. Úvodní část práce se zabývá základními principy a podstatou automatizace a uvádí přehled nástrojů dostupných na trhu. V dalších kapitolách se nachází popis efektivní automatizace a nejpalčivější problémy, se kterými se můžeme při automatizaci setkat. Výsledkem práce jsou konkrétní postupy a rady při automatizovaném testování. Klíčová slova: automatizace, software, tester, testovací nástroje, testy

Annotation Testing is an important part of every software development lifecycle. This thesis deals with automated testing tools and their implementation in practice. Introduction describes general principles, benefits and disadvantages of automation. Second chapter provides overview of testing tools which are available on the market. Conclusion refers to efficient automation and describes frequent problems and challenges. Outcome of the thesis is summarized in last chapter which is dedicated to best practice. Key words: automation, software, tester, testing tools, tests

Obsah Úvod ........................................................................................................................................................ 6 1

2

3

4

5

Automatizované testy obecně ........................................................................................................ 7 1.1

Co jsou automatizované testy ................................................................................................. 7

1.2

Dělení automatizovaných testů .............................................................................................. 7

1.3

Proč (ne)automatizovat ........................................................................................................... 9

1.4

Přínosy automatizace ............................................................................................................ 10

1.5

Problémy automatizace ........................................................................................................ 10

1.6

Manuální vs. automatizované testy ...................................................................................... 11

1.7

Doporučená pravidla automatu ............................................................................................ 13

Nástroje na trhu ............................................................................................................................ 16 2.1

Quick Test Professional ......................................................................................................... 19

2.2

SilkTest .................................................................................................................................. 20

2.3

TestComplete ........................................................................................................................ 21

2.4

Selenium ................................................................................................................................ 22

2.5

SilkPerformer......................................................................................................................... 23

2.6

JMeter ................................................................................................................................... 24

2.7

SoapUI ................................................................................................................................... 25

2.8

IBM Rational Functional Tester ............................................................................................. 26

Nástroj HP Quick Test Professional ............................................................................................... 27 3.1

Licenční informace ................................................................................................................ 27

3.2

Představení GUI prostředí ..................................................................................................... 27

3.3

Keyword View vs Expert View ............................................................................................... 28

3.4

Object repository .................................................................................................................. 29

3.5

Tabulky a outputs .................................................................................................................. 31

3.6

Debugging tests ..................................................................................................................... 32

3.7

Napojení na jiný software ..................................................................................................... 33

Ukázka skriptu QTP ....................................................................................................................... 35 4.1

Record úpravy ....................................................................................................................... 35

4.2

Keyword view úpravy ............................................................................................................ 38

4.3

Expert view úpravy ................................................................................................................ 42

Best practices ................................................................................................................................ 47 5.1

Inteligentní čekání ................................................................................................................. 47

5.2

Rozdělení skriptu ................................................................................................................... 48

5.3

Přetížení funkce ..................................................................................................................... 49

5.4

Vlastní report......................................................................................................................... 50

5.5

Zdroj exekuce ........................................................................................................................ 52

5.6

Vypnutí zaznamenání informací do reportu ......................................................................... 52

5.7

Ověřování vyplněných hodnot .............................................................................................. 53

5.8

Hromadný přepis Repository ................................................................................................ 54

5.9

Zavírání QTP .......................................................................................................................... 56

5.10

Otevření testu najednou ....................................................................................................... 58

5.11

Zobrazování hesel v testech .................................................................................................. 60

5.12

Nastavení prostředí a QTP..................................................................................................... 61

5.12.1

Oznamovací bubliny ...................................................................................................... 61

5.12.2

Nastavení jazykové verze .............................................................................................. 62

5.12.3

Smart identification ....................................................................................................... 63

Závěr ...................................................................................................................................................... 65 Seznam použité literatury ..................................................................................................................... 67 Seznam použitých zkratek ..................................................................................................................... 70 Seznam obrázků .................................................................................................................................... 71 Seznam tabulek ..................................................................................................................................... 73

Úvod Ţijeme v době, ve které si ţivot bez počítačů neumíme představit. Víme, ţe základními komponenty počítače jsou software a hardware. Avšak aby mohl software správně fungovat, nejprve ho musíme otestovat a předcházet tak moţným chybám a problémům. Testování je nedílnou součástí vývoje softwaru a provází jej celým ţivotním cyklem. Lidé si testování chtěli usnadnit, a tak stejně jako v jiných odvětvích, i zde pouţili automat, aby dělal práci za ně. Na toto téma je zaměřena i tato diplomová práce, konkrétně na automatizační testovací nástroje. Pracuji jako IT Test Specialist a nástrojům k automatizaci testování se tedy profesně věnuji aktivně uţ dva roky. Za ten čas jsem se seznámil s mnoţstvím literatury a byl přítomen na mnoha prezentacích o problematice popisující výhody a nevýhody automatizovaného testování. Na konkrétní postupy a rady, jak psát automatizační skripty nebo jak řešit případné vzniklé problémy, jsem ale narazil ve výrazně niţším mnoţství. Stejně tak toto téma uţ přede mnou několik studentů zpracovávalo, šlo však opět o popis automatizace jako celku, případně byly představeny dostupné nástroje na trhu. Z tohoto pohledu lze tedy mou práci povaţovat za prvotinu. V prvních kapitolách čtenáře obeznámím s tématem, s principy automatizace, ukázkami skriptů a jejich moţností. Nejcennější kapitoly jsou však v druhé polovině práce, kde lze nahlédnout do vybraných poznatků mé práce v oboru. Do tématu bych chtěl zároveň přispět právě popisem efektivní automatizace s konkrétními radami k překonání nejpalčivějších problémů různých typů, na které lze při automatizaci narazit. Během analytické fáze této práce jsem vyuţil především metodu pozorování, kdy jsem dlouhou dobu sledoval a studoval danou problematiku, a to hlavně v literatuře a během své profese. V další části, v průběhu syntetické fáze, jsem pouţil metodu srovnání, a to především s věcným hlediskem. Dále jsem v práci pouţil abstrakci, která mi poslouţila k vyloučení nepodstatných věcí, abych se dostal k jádru problému. Tyto metody mi na zvolené téma přišly jako nejlepší moţnost s ohledem na mé zkušenosti a moţnosti.

6

1 Automatizované testy obecně 1.1 Co jsou automatizované testy Testování je metoda pro ověření určitých předpokladů. Lidé testují od nepaměti vše, co si potřebují ověřit. Jinak tomu není ani v problematice počítačového software. Testování je velmi důleţité, patří ke všem částem ţivotního cyklu projektu. „V rámci fází analýzy, návrhu a implementace probíhá testování průběţně a velmi často. Ve fázi zavádění jsou potom provedeny akceptační testy“ (2). Software musí být testovaný, abychom měli jistotu, ţe funguje podle předpokladu v zamýšleném prostředí. Testování musí být také efektivní v hledání jakýchkoliv defektů (1). Existuje mnoho definicí automatizovaných testů. S velmi obecnou definicí lze říci, ţe automatizace testování je v podstatě jakékoliv pouţití nástroje k zjednodušení testování (4). Můţeme také říct, ţe „automatizací testování rozumíme pouţití softwaru k podpoře nebo provádění činností spojených s testováním, jako je řízení testování, provádění a vyhodnocování testovacích případů a scénářů“ (2). V rámci práce se však budeme drţet ještě uţší definice, ţe automatizace testování je pouţití určitého softwaru, který volá sluţby programu, nebo přímo vyuţívá GUI rozhraní a poté přímo vyhodnocuje správnost chování systému (3).

1.2 Dělení automatizovaných testů Automatizované testy můţeme rozdělit do několika kategorií podle různých hledisek. Základní hledisko, které platí pro testy i obecně, je pouţitelnost testu k určitému záměru. Automatizované testy se však nedají ve všech těchto typech testů efektivně pouţít. Takto můţeme testy dělit na (5): jednotkové testy, integrační testy, funkční testy, systémové testy. zátěţové testy, výkonnostní testy, testy pouţitelnosti, 7

akceptační testy, regresní testy, beta testy. Další hledisko, které se při automatizaci testů pouţívá, je dělení podle funkčnosti na (6): funkční testy – testují, co produkt dělá. Mezi funkční testy pak můţeme zařadit (7): o

Unit Testing

o

Smoke testing / Sanity testing

o

Integration Testing (Top Down,Bottom up Testing)

o

Interface & Usability Testing

o

System Testing

o

Regression Testing

o

Pre User Acceptance Testing(Alpha & Beta)

o

User Acceptance Testing

o

White Box & Black Box Testing

o

Globalization & LocalizationTesting

nefunkční testy – testují, jak dobře se produkt chová při různých situacích. Můţeme tam zařadit (7): o

Load and Performance Testing

o

Ergonomics Testing

o

Stress & Volume Testing

o

Compatibility & Migration Testing

o

Data Conversion Testing

o

Security / Penetration Testing

o

Operational Readiness Testing

o

Installation Testing

o

Security Testing (ApplicationSecurity, Network Security, System

Security) 8

Velmi rozšířené dělení je podle fáze testu na (8): Developer testing/unit testing – programový kód (třídy, metody) je ověřen programátorem, většinou metodou čtyř očí. Odhalení chyby v této fází je téměř bez nákladu. FAT – funkční testy, které probíhají u dodavatele. Integrační testy – testuje se spolupráce komponent vně systému ale i integrace s okolními aplikacemi. SIT – systémové testy, kde je testovaná aplikace jako celek z pohledu zákazníka podle připravených scénářů. UAT – akceptační testy, testy probíhají na straně zákazníka podle poţadavku a na jeho prostředí. Odhalení chyb v této fázi můţe znamenat celkový neúspěch projektu, hlavně kvůli nedodrţení termínu. Automatizované testy a hlavně software pro testování se však nejčastěji dělí podle toho, na jakém principu technicky fungují (1): Back end testy – posílaní instrukcí, nejčastěji ve formě xml do aplikací bez grafického rozhraní a následné zachytávání odpovědi, které posílá zpět jako odpověď. Front end testy – testují přes uţivatelské GUI rozhraní, coţ je více podobné uţivatelskému testování. Dalo by se s notnou dávkou nadsázky říci, ţe jde kopírování chování manuálního testera. Oba principy mají své výhody a nevýhody a jsou zaměřeny na otestování jiné funkcionality softwaru.

1.3 Proč (ne)automatizovat Zdálo by se moţná, ţe si stačí zakoupit software pro automatizaci, spustit nahrávaní a pak jen pouštět testy dokola. Bohuţel tak jednoduché není. Uţ jen z důvodu, ţe ne všechno se vyplatí automatizovat. Kdy se automatizované testy oplatí dělat, je velice diskutované téma, které ve svých publikacích řeší mnoho autorů. V následující části práce se pokusím shrnout přínosy ale i nevýhody automatizovaných testů a přiblíţit nejlepší doporučení pro automatizované testy.

9

1.4 Přínosy automatizace Přínosy automatizace v testování mají přinést hlavně celkovou efektivitu oproti ručnímu testování. V souhrnu mohou automatizované testy s menším úsilím zvýšit kvalitu softwaru a produktivitu testování. Níţe uvádíme výčet toho nejlepšího, co automatizace nabízí. Automatizované testy jsou v první řadě velice explicitní – jednoznačné. To přináší velkou šanci na reprodukci chyby, protoţe přesně víme, co automatizovaný test udělal, aby se dostal k výsledku (9). Automatizované testy jsou prováděny počítačem a nejsou tedy náchylné na selhávání kvůli lidským faktorům, jako je únava (9). S tím souvisí i menší chybovost při zadávání opakovaných vstupů a celkové zvýšení morálky. Testeři mají čas se věnovat více kvalifikovaným úkolům (1). Jedna z největších devíz automatizovaných testů je jejich rychlost. Tyto testy nemají skoro ţádnou prodlevu mezi vstupem a kontrolou. Taktéţ spouštění toho samého testu s jinými parametry nebo na jiné platformě, je při manuálním testování velice únavné. Přitom automatizovaný test zvládne bez problémů exekuci libovolného počtu testů v kratším čase a nikdy se neunaví (9). To vede k vetší důvěře v systém, protoţe testy probíhají častěji (1). Automatizované testy nám dávají moţnost otestovat věci, které by se nám manuálně vůbec nepovedlo uskutečnit. Mezi takovéto testy patří spuštění stovky testů najednou v obrovském rozsahu a tím zjistit chování systému, nebo spuštění desítek transakcí současně (9). To souvisí s další výhodou, a to spuštění těchto zatěţujících testů kdykoliv i během noci nebo víkendu, kdy to nebude mít velké důsledky (1). Nesmíme také zapomenout na znovupouţitelnost automatizovaných testů, která se vyuţívá hlavně při nový verzi programu při regresním testování, při minimálním úsilí (1).

1.5 Problémy automatizace Existuje celá řada problémů, které mohou nastat ve snaze o automatizaci. S většinou problémů se však dá vypořádat, níţe je tedy popis nejčastějších a nejpalčivějších problémů. Nerealistická očekávání, ţe automaty vyřeší všechny problémy. Obecně, špatný testing nedokáţe pozdvihnout automatizace k dobrému testingu. Kdyţ je v testingu chaos, tak „automatizace přinese jen rychlejší chaos“ (1).

10

Jedna z největších hrozeb automatizovaných testu spočívá v údrţbě. Kdyţ se software mění často, znamená to obrovské náklady na údrţbu. Můţe to vést aţ k tomu, ţe automatizace se stane méně efektivní neţ manuální testování (1). Automatizovanými testy nedokáţeme najít triviální chyby rozvrţení a pouţitelnosti. Spíše naopak, automatizovaný test můţe být zastaven kvůli tak jednoduché a nečekané věci jako je dialogové pop-up okno a ohlásit chybu, i kdyţ je test správný (9). Při manuálním testování pouţíváme implicitní znalosti a dokáţeme posoudit i něco, co funguje podle očekávání, ale něco jiného je v nepořádku. Umoţňuje nám to najít chyby, které bychom automatizovanými testy nikdy nenašli, chyby které vyplynuly z testování, ale které nesouvisí s funkcionalitou, kterou bylo poţadováno ověřovat (9). Očekávaní, ţe automatizované testy najdou mnoho nových chyb je naivní. Automatizovaný test je vţdy uţ jednou spuštěný test, kvůli jeho naprogramování. Z toho vyplývá, ţe znovuspuštěný test uţ většinou tolik chyb nenajde. Lehce se stává, ţe automatizace dává falešný pocit bezpečí. Je potřeba si uvědomit, ţe i kdyţ automatizované testy proběhnou bez chyb, neznamená to, ţe software je bez chyb. Automatizované testy oproti manuálním mají vetší tendenci chyby přehlíţet. A v neposlední řadě, automatizované testy se nevyhýbají ani technickým problémům. Ne kaţdý software je schopný automatizovat kaţdou technologii. Je důleţité vybrat správný software na tu správnou technologii. S tím souvisí i navrţení a postavení systému, které by mělo brát ohled i na testování. Často je nutné mít také detailní technické znalosti k dané technologii pro úspěšné napsání automatizovaného skriptu nebo školení od dodavatele.

1.6 Manuální vs. automatizované testy Kdy poskytne automatizace výhodu oproti manuálnímu testování? Firmy při výběru mezi automatizaci nebo manuálním testováním vybírají na základě nákladů. Nákladový faktor je na prvním místě při rozhodování o tom, zda společnost chce pouţívat automatizaci nebo zůstat u manuálního testování. Bez ohledu na to, jestli zvolíme ruční nebo automatizované testování, budeme potřebovat aktiva a zdroje, které nás budou stát peníze.

11

Mezi tyto aktiva patří: čas S příchodem automatizace testů se všeobecně předpokládá úspora času. Ušetření času při automatizaci je způsobeno snadnou opakovatelností testovacích scénářů. Jakmile jsou totiţ vytvořeny testovací scénáře, lze automatizované testy spouštět znovu a znovu bez dodatečných nákladů. Automatizované testy jsou také o mnoho rychlejší neţ manuálně prováděné. Sníţení času exekuce regresních testů můţe být zkráceno z týdnů na hodiny. Jedná se tedy o významnou úsporu času, která se promítá přímo do úspor nákladů. lidé S opakováním spouštěných testů souvisí i druhý faktor, a to lidé. Při automatizovaném testování řídi testy příslušný software a pro samotnou exekuci není nutný zásah člověka. Z toho vyplývá, ţe podobně jako u času, dochází k významné úspoře lidské práce a tím i nákladů. infrastruktura Při pohledu na infrastrukturu se mezi manuálním a automatizovaném testování nic podstatného nemění. Obě varianty potřebují stejné prostředí, kde se testy budou provádět. V některých případech se pro automatizované testy uţívá samostatné prostředí (kvůli hromadění syntetických dat), ale není to nutností. nástroje Z pohledu nástrojů jsou na tom automatizované testy hůř. Důvod je zřejmý – je třeba mít testovací nástroj. Je důleţité zmínit, ţe je nutno také brát v úvahu, zda se jedná o komerční nástroj, či nástroj, který je zdarma. U nástroje zdarma však náklady porostou se správným nastavením a přizpůsobením nástroje, které je obtíţnější. školení Posledním aktivem je školení, kde opět převyšuje v nákladech automatizační varianta. Je to z důvodu zaškolení uţivatelů na automatizační software, nebo nákup specializovaných vyškolených testerů. Přiloţený obrázek Manuální vs. Automatizované testy ilustruje výhody aktiv podle typu testu, kde červená znamená vetší náklady a modrá naopak niţší náklady (21).

12

Obrázek 1: Manuální vs. Automatizované testy (Zdroj: (21))

1.7 Doporučená pravidla automatu Automatizaci by měla předcházet analýza návratnosti automatizovaného testování. Náklady na tvorbu a aktualizace testu jsou o mnoho vyšší u automatizovaného testu neţ u manuálního. Na opačném konci náklady na provedení testu jsou v manuálním testování vyšší. Z toho vyplývá, ţe automatizované testy se oplatí, pokud se vícekrát opakují. Od určitého počtu n iterací jsou náklady na n-tý manuální test vyšší neţ náklady na n-tý automatizovaný test. Popis v obrázku níţe: (10)

Obrázek 2: Porovnání nákladů manuálního a automatizovaného testování (Zdroj: (10))

13

Je potřeba však dát pozor na aktualizaci automatizačních testů na základě změn systému. (10) Je moţné, ţe systém se bude měnit tak často, ţe náklady na údrţbu testu budou znamenat, ţe se přímky nákladů přetnou aţ za předpokládaným počtem iterací nebo dokonce nikdy. Z toho tedy vyplývá, ţe i samotný počet opakování spuštění testu má vliv na návratnost automatizace. Velice známé jsou v automatizaci takzvané Testovací pyramidy. Ukazují nám, jaké mnoţství automatizovaných testů je v jaké fázi vývoje softwaru nejvíce doporučováno. Z něj vyplývá, ţe nejvíce automatizovaných testů bychom měli věnovat uţ při vývoji aplikace při unit (jednotkových) testech. Další velká část, kterou by měla automatizace zastřešovat, jsou různé integrační testy. A poslední nejmenší část, kterou bychom měli automatizovat, jsou GUI testy. Ukázka popisu dole na obrázku:

Obrázek 3: GUI testy (Zdroj: (11))

Často se tato pyramida v organizacích však nedodrţuje. Pak vzniká přesně opačný efekt, takzvaný kornout zmrzliny, kde automatizujeme málo jednotkových testů, pak více integračních a nejvíce GUI testů. S tím souvisí také, ţe máme následkem toho hromadu manuálních GUI testů, kterými musíme doplnit deficit testování v niţších vrstvách. Samozřejmě platí, ţe čím dřív/níţ chybu najdeme, tím bude oprava chyby levnější.

14

Obrázek 4: GUI test 2 (Zdroj: (9))

Automatizované testování není moţné provést bez manuálního testování. I kdyţ se rozhodneme automatizovat, je potřeba vţdy alespoň jednou v kaţdém testovacím scénáři otestovat test i manuálně, a tím ověřit výsledky testu (9). Pro úspěšnou automatizaci je také nezbytné vybrat správný nástroj, respektive nástroje, na automatizaci. Při výběru automatizačního nástroje je důleţité vybírat nejen podle technologie, ale i podle pracovníků, kteří budou nástroj obsluhovat. Je rozdíl mezi technicky zdatným programátorem a business lidmi (1).

15

2 Nástroje na trhu Výběr vhodného nástroje je neméně důleţitý pro úspěšnou automatizaci testu. Výběr by měl začínat podle toho, jaké testy chceme provádět. Můţeme rozřadit nástroje na ty, které testují pomocí GUI vrstvy a pak ty, které testují pomocí HTTP protokolu. S tím souvisí jejích zaměření, kde s pomocí GUI nástrojů testujeme GUI testy, které by se jinak prováděly manuálně, zatímco pomocí HTTP-levelu se dělají interface testy a performance testy. Máme dále na výběr nástroje, které lze pořídit zdarma (převáţně open source) a komerční nástroje. Všeobecně platí a z vlastní zkušenosti mohu potvrdit, ţe open source nástroje jsou obtíţně nastavitelné a je někdy aţ nemoţné je nastavit např. v bankovních institucích, kde je bezpečnost na vysoké úrovni. Naproti tomu komerční nástroje jsou sice snadno nastavitelné, ale oproti tomu drahé na pořízení i na následnou údrţbu (závisí na licenční politice). K výběru nástrojů, které popíšeme, jsme pouţili případovou studii z roku 2013 od společnosti Gartner, která vydává kaţdoročně zmapovaný trh různých IT oboru a mezi nimi také integrační softwarové testování.

16

Obrázek 5: Softwarové testováni (Zdroj: (20))

Jako top lídry oboru označil Gartner společnosti HP a IBM, které poskytují nástroje jako QTP a RFT, kterým se budeme dále věnovat. Rovněţ v případově studii rozebral trh open source nástrojů, kde vyzdvihnul nástroje Selenium, SoapUI, kterým se také budeme věnovat. Do výběru jsme dále zahrnuli ještě jeden open source nástroj JMeter a dále dvě společnosti SmartBear a Borland. Všechny jsou oblíbené a působí také na našem trhu. Podle kritérií zaměření a komerčnosti jsme dále vypracovali matici, která přehledně mapuje trh vybraných nástrojů.

17

Tabulka 1: Matice (Zdroj: autor)

Nástroje

GUI

HTTP

OpenSource

Commercial

QTP

X

X

-

X

SilkTest

X

-

-

X

TestComplete

X

-

-

X

Selenium

X

-

X

-

SilkPerformer

-

X

-

X

JMeter

-

X

X

-

SoapUI

-

X

X

-

RFT

X

-

-

X

18

2.1 Quick Test Professional HP Quick Test Professional (dále jen QTP) je nově nyní označován jako HP Unified Functional Testing software. HP Unified Functional Testing software je novější název a také k původnímu QTP přidává HP Service Test. Je to komerční automatizační nástroj od společnosti Hewlett Packard. Patří do rodiny produktů jako je HP Quality Center a HP Quality Management, se kterými je dobře integrovaný, ale dá se pouţít plnohodnotně i samostatně. QTP se zaměřuje na GUI funkční testování a Service Test na HTTP-level testy sluţeb. HP Unified Functional Testing software tedy zastřešuje oba přístupy automatizovaného testování. To je výhoda pro společnost, která chce testovat automatizovaně oběma přístupy a nemusí integrovat vícero nástrojů do svého prostředí, stačí pouze jeden nástroj. QTP se zaměřuje na standardní desktopové a webové aplikace. Podporují technologie jako JAVA, .NET, WPF, SAP, Oracle, Flex, Siebel, Delphi, Terminal Emulator, Silverlight, Web Services, Mobile technology (Windows mobile, android emulátor). QTP je primárně určený na Windows platformu. Webové aplikace se doporučuje automatizovat v Internet Explorer, Mozilla Firefox, Google Chrome. Prohlíţeče Opera a Safari nejsou podporovány. Testy se klasicky dají nahrávat, kdy se zachytává sekvence v jazyku VBScript. Tato se dá následně spouštět. Na daný test existují dva pohledy. Prvním je Keyword pohled, který je určen pro začínající testery a je zaloţen na klíčových slovech, oproštěn od zdrojového kódu. Druhým je Expert pohled, kde je zobrazen přímo VBScript, který lze editovat, případně přímo vytvářet. QTP se budeme dále věnovat v další kapitole práce, kde software popíšeme více do hloubky (15). Pouţití: funkční GUI a http testování Cena: 6000 dolarů / rok za 1 concurrent licenci

Obrázek 6: GUI (Zdroj: (15))

19

2.2 SilkTest SilkTest je komerční automatizační nástroj od společnosti Borland. Zaměřuje se na funkční GUI testy. SilkTest podporuje automatizaci desktopových a webových aplikací. Webové aplikace se dají testovat i na mobilních prohlíţečích bez nutnosti úpravy testů. Pro testování mobilních aplikací existuje Silk Mobile, který však není součásti SilkTestu a nakupuje se samostatně. Silk nabízí dvě varianty: SilkTest Classic a SilkTest Work Bench. SilkTest Classic tvoří testy v objektově orientovaném jazyku podobnému C++. SilkTest Work Bench obsahuje navíc Visuální testování, které je spíše pro juniorní uţivatele a skripty jsou psané ve VB.NET. Silk dále nabízí Silk4J a Silk4Net. Silk4J podporuje integraci s Eclipse nástrojem a skriptování v Java. Silk4Net zas podporuje integraci s Visual Studio nástrojem a skriptování ve VB .NET a C# .NET. SilkTest podporuje automatizování technologií jako AJAX, Web 2.0, Java, .NET, Silverlight, terminálové a SAP systémy. SilkTest je určený pro Windows platformu. Webové aplikace se doporučuje testovat v Internet Explorer, Mozilla Firefox, Google Chrome. SilkTest nabízí také funkce rozpoznávání obrazu, kdy porovnává náš uloţený obraz s nalezeným. Také nabízí integraci s cloudovým řešením přes Cloud Amazonu, kde si můţeme vytvořit virtuální infrastrukturu, jakou potřebujeme na web/HTML5 testování (16).

Obrázek 7: Borland Silk Test (Zdroj: (16))

Pouţití: GUI testování (web, desktop) Cena: Named 4500 dolarů, Concurrent/Floating 9000 dolarů za licenci, Runtime 4000 dolarů

20

2.3 TestComplete Komerční

nástroj

pro

automatizaci

od

společnosti

SmartBear.

Umoţňuje

automatizované testování pro weby, mobilní platformy i desktopové aplikace. Pro kaţdý typ platformy se dokupuje samostatný modul. Technologie, se kterými dokáţe TestComplete pracovat, jsou rozděleny podle zmíněných modulů. Desktopový modul podporuje technologie: WPF, C++, Delphi, Java, Qt a Windows Store Apps. TestComplete pracuje jak s 32-bitovými, tak i s 64-bitovými architekturami. Webový modul: HTML5, Flash, Silverlight, AIR, Apache Flex, AJAX. Podporuje pět webových prohlíţečů, napříč kterými dokáţe testovat: Chrome, Firefox, Internet Explorer, Safari, Opera. Mobilní modul dokáţe pouţívat technologie: Native Android 4.x, Object/Gesture recognition. Webový modul umoţňuje testovat mobilní aplikace na emulovaném Google Chrome mobilním prohlíţeči na desktopu. TestComplete umoţňuje nahrávání činností a následně jejich spuštění. Zvláštností však je moţnost pouţití skriptovacích jazyků JavaScript, VBScript, DelphiScript, C++ Script, C# Script podle preferencí automatizovaného testera. Umoţňuje také napojení na různé vyhodnocovací a udrţovací aplikace třetích stran, přičemţ nejjednodušší je integrace s TestComplete IDE od stejné společnosti.

Obrázek 8: Smartbear (Zdroj: (12))

Pouţití: GUI testování (web, desktop, mobil) Cena: 1000 – 2600 dolarů za platformu + kaţdý modul 999-2598 dolarů

21

2.4 Selenium Open Source nástroj na automatizované testování. Podle Gartner studie z července roku 2013 tvoří Selenium přibliţně 33 procent ze všech open source nástrojů k automatizaci. Začátky nástroje sahají do roku 2004, přičemţ za nástrojem stojí spíše jednotlivci jako Jason Huggins, Simon Stewart a mnoho dalších. Selenium je zaměřeno na automatické testování webových aplikací. Selenium se skládá ze čtyř softwarových nástrojů: Selenium 2 (WebDriver), Selenium 1 (předchůdce Selenium 2, který poskytuje některé odlišné funkce navíc), Selenium IDE (nahrávací nástroj pro vytvoření testovacích případů) a Selen-Grid (umoţňuje spouštění testu paralelně a na vzdálených serverech). Selenium 2 a Selenium 1 podporují všechny známé prohlíţeče a skoro všechny jejich verze: Google Chrome, Internet Explorer, Firefox, Safari, Opera, HtmlUnit, phantomJS. Selenium 2 navíc od Selenium 1 podporuje systém Android. Selenium můţeme pouţívat na operačních systémech Windows, Linux a Mac. Selenium IDE, který slouţí na tvorbu testovacích scénářů je doplněk/plugin k prohlíţeči Firefox. Funguje jako klasické nahrávání úkonů, které se ukládá a které je poté moţné následně spustit. Je tu však omezené mnoţství dodatečné editace. Selenium 2 a Selenium 1 nám umoţňují psát testovací scénáře, a to v různých jazycích jako je HTML, C#, JAVA, Python či PHP. Selen-Grid poskytuje vylepšené moţnosti pro exekuci na vzdálených serverech a pro paralelní spouštění testů (13).

Obrázek 9: GUI testování (Zdroj: (13))

Pouţití: GUI testování (web) Cena: zdarma 22

2.5 SilkPerformer Komerční nástroj od společnosti Borland. Jak název napovídá, slouţí pro tvorbu http automatizovaných testů, vyuţívaný především při performance testování. Pomocí SilkPerformer se dají testovat jak desktopové aplikace, tak web a také mobilní aplikace. SilkPerformer má tři verze: Web, Standard a Premium. Webová verze obsahuje technologie, které postačují pouze pro web. Standard a Premium verze jsou stejné aţ na to, ţe Premium verze obsahuje navíc technologie ERP/CRM, Terminal service, Legacy/Mainframe. SilkPerformer je určený na Windows platformu. Nejznámější podporované technologie jsou http, AJAX, Flex, Java, .NET, Silverlight, SOAP, SMTP/POP/IMAP/MAPI, FTP, TCP/IP & UDP, DLL, ODBC a Oracle OCI. Pro mobilní testy nabízí SilkPerformer plnou podporu jak pro webové mobilní aplikace, tak i pro nativní aplikace pro mobilní telefony. Mezi podporované platformy v této oblasti patří všichni aktuální hráči na trhu, tedy Android, iOS, Windows Phone a BlackBerry. Samozřejmostí je generování reportů, analýz a vypovídajících grafů z exekuce. SilkPerformer nabízí také monitoring serverů a statistik, který slouţí pro snadné odhalení problému. Tyto sluţby se však prodávají ve formě přídavného modulu. SilkPerformer umoţňuje integraci cloud řešení, kdy dokáţe simulovat masivní spouštění testů bez investování do nákupu hardwaru v případě jeho nedostatku. Integrace s aplikacemi třetích stran pro SilkPerformer není problém a podporuje napojení na Visual Studio, JUnit/NUnit nebo BMCsoftware a dynaTrace software na odhalování překáţek úzkých míst softwaru jak pro Java i .NET aplikace (16).

Obrázek 10: Silk Performer (Zdroj: (16))

Pouţití: HTTP testování (web, desktop, mobile) Cena: 25000 dolarů za 100 virtuálních licencí na rok + Server Modul 1881 dolarů

23

2.6 JMeter OpenSource nástroj, který spadá pod Apache software foundation. Tento automatizační nástroj byl vyvinut k testování funkčnosti a hlavně měření výkonu webových aplikací. Dá se zároveň rozšířit pro testování desktopových aplikací. JMeter je nástroj, který dokáţe simulovat velkou zátěţ na server respektive skupinu serverů. Podporuje volání a tím testování technologií: Web (HTTP, HTTPS), SOAP, FTP, Database (JDBC), LDAP, MOM (JMS), Mail (SMTP, POP3, IMAP), Commands/Shell scripts, TCP. JMeter má GUI rozhraní, u něhoţ se předpokládá a doporučuje znalost skriptovacích jazyků JavaScript nebo VBS. Nevyuţijeme-li GUI, dají se skripty psát v jazyce JAVA, ve kterém je i napsán samotný nástroj. JMeter dokáţe naslouchat komunikaci mezi prohlíţečem a testovanou aplikací. Tuto komunikaci ukládá podle námi definovaných pravidel. Následně se například HTTP requesty dají upravit podle námi zvolených poţadavků a JMeter je potom dokáţe reprodukovat, případně posílat modifikované podle námi určených parametrů. Samozřejmostí je i napsání vlastních příkazů, které potom posíláme. Výsledky JMeter ukládá do textové podoby, no pomocí GUI nástrojů dokáţe vykreslovat také různé grafy ať uţ propustnosti či chybovosti podle zvolené zátěţe. JMeter umoţňuje rozšiřování sebe sama různými add-ony a tím ze sebe udělat robustní nástroj. Z vlastní zkušenosti však mohu říct, ţe nastavit JMeter do poţadované podoby je o mnoho náročnější a vyţaduje více znalostí, neţ jak je tomu u komerčních nástrojů, kde je téměř vše dopředu zajištěno (14).

Obrázek 11: ApacheJMeter (Zdroj: (14))

Pouţití: HTTP testování (web-performance) Cena: zdarma 24

2.7 SoapUI SoapUI je OpenSource automatizační nástroj od společnosti SmartBear. SoapUI je druhý nejvíce rozšířený OpenSource automatizační nástroj s podílem okolo 27 procent na trhu. Spolu se Seleniem tvoří tedy přes 60 procent OpenSource nástrojů pro automatizaci. SoapUI existuje také jako SoapUI ve verzi Pro, která obsahuje hlavně plnou podporu od společnosti SmartBear a také vetší moţnost reportovacích a analytických nástrojů. SoapUI se pouţívá pro automatizaci SOA a webových aplikací. Software je pouţitelný pro platformu Windows, Linux a Mac. SoapUI podporuje technologie SOAP/WSDL, REST, HTTP, AMF, JDBC a JMS. SoapUI obsahuje také příkazovou řádku, přes kterou se dají testy pohodlně spouštět například přes plánovač úloh. SoapUI se dá snadno integrovat s různými nástroji jako Maven, Hudson, Bamboo, JUnit, ANT, NetBeans, Eclipse, IntelliJ. SoapUI má přívětivé grafické rozhraní, dokáţe klasické nahrávání komunikace mezi klientem (webový prohlíţeč) a serverem. Nahrávanou komunikaci potom můţeme dále upravit a pouţít. Testy se dají psát také v Javascriptu. Z nabízených nezvyklých funkcí poskytuje SoapUI také moţnost security testingu, kdy dokáţe simulovat sql injections, xml bomb, fuzzing scan a další uţívané metody (17).

Obrázek 12: SOAPUI (Zdroj: (17))

Pouţití: HTTP testování Cena: SoapUI zdarma, SoapUI Pro 399 dolarů

25

2.8 IBM Rational Functional Tester IBM s produktem Rational Functional Tester označil Gartner, jako jednoho z lídrů automatizace testování. Rational Functional Tester je komerční nástroj, který nabízí automatizaci GUI desktopových a webových aplikací. Rational Functional Tester běţí klasicky na systémech Windows, ale také na Linuxové platformě. Umí pracovat s technologiemi jako Java, .NET, Web-based, Siebel, SAP, terminal emulator-based, Flash, PowerBuilder, Ajax, Adobe Flex, Silverlight. Webová podpora je na prohlíţeče Mozilla Firefox, Internet Explorer a Google Chrome. Nabízí, stejně jako ostatní nástroje, také klasické nahrávání uţivatelských akcí, které se posléze dají upravovat a spouštět. Na výběr je moţná úprava ve dvou jazycích a to Java nebo Visual Basic .NET, výběr je však mandatorní. Je dobře integrovatelný s jinými IBM Rational produkty jako Rational Team Concert, Rational ClearCase, Rational Quality Manager či Rational TestManager (18).

Obrázek 13: IBM Rational (Zdroj: (19))

Pouţití: GUI testování (desktop, web) Cena: 6 620 dolarů pevná licence /12 700 dolarů plovoucí licence na 12 měsíců

26

3 Nástroj HP Quick Test Professional HP Quick Test Professional jsme si uţ krátce představili v předchozí kapitole. Následně ho projdeme více do hloubky. Představíme si, co umí, jaké má výhody a také jaké nevýhody. Jak jsme uţ psali, HP Quick Test Professional je nově označován jako HP Unified Functional Testing software. Ve společnosti HP přistoupili ke kroku, kde ke klasickému QTP, které se pouţívá na GUI softwarové testování, přidali ještě nástroj HP Service Test, který dokáţe testovat http vrstvu. HP Unified Functional Testing software tedy tvoří kompletní testovací automatizační sadu, ke které není potřeba uţ nic dokupovat (15).

3.1 Licenční informace Pro HP Unified Functional Testing a tedy i Quick Test Professional se dají koupit dva druhy licencí. Permanent seat/trvalá licence na konkrétní počítač, na který se nástroj instaluje. Nebo network-based concurrent licence/síťová licence, kterou lze pouţít pro více uţivatelů na více počítačích. Síťová licence však poskytuje také jen jednu licenci v daný okamţik. Pro tuto licenci potřebujeme server, kam se nainstalují licence a na které vidí všechny ostatní počítače, jejichţ uţivatelé chtějí pouţívat QTP. Nástroj se na tyto počítače nasadí a při spuštění softwaru se tento podívá na licenční server, zda je aktuálně nějaká licence volná. Licence se obvykle kupují na dané období, většinou na jeden rok. Obě licence v sobě zahrnují bezplatný upgrade softwaru, který si však musejí stáhnout a ze stránek nainstalovat uţivatelé sami. Také je od společnosti HP na dané období poskytnutý support/podpora pro zákazníky. Kdyţ dané období skončí, je moţné buď prodlouţit licence, v rámci kterých se získává právě podpora a upgrade pro software, nebo neprodluţovat a uţívat software dále. Samotný software je totiţ uţ koupený a lze ho neomezeně pouţívat dále (15).

3.2 Představení GUI prostředí Quick Test Professional má velice intuitivní grafické prostředí. Na úvodní stránce se dá najít vše důleţité a uţitečné. Samozřejmostí je upravit si obrazovku podle sebe a to jak hlavní okna, tak i toolbars, kde se dají přidat a odebírat tlačítka podle preferencí.

27

Obrázek 14: Část úvodní klasické obrazovky (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Na úvodní obrazovce máme čtyři hlavní části. První část je vrchní, kde máme různé lišty jako je MenuBar, Toolbars, kde si nastavujeme a voláme hlavní příkazy, co se má vykonat. Druhá část je Solution Explorer panel, kde se shromaţdují akce v podstatě části skriptů, které dohromady tvoří testovací skript. Také se zde dá zobrazit repository/repozitář testů a resources/zdroje pro daný test. Třetí část je dokumentová část, kde se zobrazuje samotný vybraný skript ve dvou pohledech (Keyword, Expert) a také se vybírá, jestli bude zobrazen dokument nebo podpůrné funkční dokumenty. Čtvrtá část je data table, umístěn standardně vespodu. Ten se uţívá pro vstupní a výstupní hodnoty. Také se pouţívá při debuggingu/ladění, kdy se zde dají zobrazit vybrané hodnoty (25).

3.3 Keyword View vs Expert View Quick Test Professional nabízí dva způsoby psaní skriptu. Jeden je více určen pro juniorní uţivatele, kteří neumí programovat a nazývá se Keyword view. Druhý je pak spíše programátorskou variantou a říká se mu Expert view. Keyword view nás oprošťuje od výběru přesně pouţité metody a nezatěţuje nás syntaxí, dělá vše v pozadí místo nás. Ukazuje nám jen základní nutné informace, a to Item, který představuje výběr objektu, funkce či údaje, se kterým aktuálně pracujeme. Pak následuje Operation, kde je výběr aktuální akce, co chceme s daným Itemem provádět, jako click, select. Nechybí Value, který nám ukazuje vybranou hodnotu nebo hodnotu, se kterou něco aktuálně děláme. Pak je tam vysvětlující Documentation, který v krátké větě říká, co skript

28

v daném kroku dělá. Dále ještě nabízí nedefaultní Assignment, coţ je přiřazení hodnoty z/do proměnné a Comment, kde si můţeme napsat vlastní komentář ke kroku skriptu. (25)

Obrázek 15: Ukázka Keyword view (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Expert view je spíše pro více programátorsky zaměřené uţivatele. Syntaxe je psaná v jazyce VBScript. Tento pohled dělá kaţdý krok jako VBScript řádek. V objektově orientovaných krocích definuje hierarchii objektu. Někdy dokáţe expert view čtyři kroky keyword view, napsat v jednom řádku a tím tvoří skript přehlednější a celistvější. Tento pohled nám také umoţňuje uţití různých if, case, while, for klíčových slov pro rozhodování a cyklení. (25)

Obrázek 16: Ukázka Expert view (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Obě varianty jde uţívat společně s nahráváním testů. Často se pro zrychlení celého procesu nejprve nasnímá celý test a pak se jen jednoduše upravuje v poţadovaném view. Testeři, kteří v nástroji dělají delší dobu uţ Keyword view vůbec nepouţívají. Psaní v tomto pohledu trvá delší čas a často není ani moţné něco sloţitějšího v tomto pohledu provést (25).

3.4 Object repository Quick Test Professional pracuje při exekuci testů s objekty. Testovací objekty jsou uloţené reprezentace skutečných objektů v testované aplikaci. Software dokáţe vytvářet celkovou sadu vlastností a hodnot objektů v aplikaci. Snaţí se přitom vybrat ty informace,

29

které jednoznačně identifikují jednotlivé objekty v aplikaci. Kaţdý testovací objekt patří do testovací objektové hierarchie. Při kaţdém testu, který děláme, tedy pouţíváme objekty. Object repository je místo, kde tyto objekty uskladňujeme a také je odtud později bereme a pouţíváme. Object repository je dvou typů, jedno lokální a druhé sdílené. Lokální repository je moţné pouţít jenom pro jednu specifickou akci. Pouţívá se spíše jenom pro zálohování nebo pro zkoušení při vytváření testů. Sdílené repository můţe být oproti tomu pouţíváno pro více akcí. To je výhodné hlavně při změně objektu, kdy stačí změnit jen jeden testovací objekt na jednom místě a všechny akce opět fungují. Quick Test Professional dokáţe během nahrávání testů vytvářet objekty automaticky. Ukládá je však do lokální repository, odkud je pak v případě potřeby přesune do sdílené, nedokáţe však pouţít dopředu vytvořené sdílené repository. Doporučuje se vytvářet co nejméně testovacích objektů kvůli pozdější údrţbě. Také se doporučuje pojmenovávat testovací objekty co nejlépe kvůli jejich pozdějšímu rychlému nalezení. Samozřejmostí je pak výběr informací na rozlišení testovacích objektů co nejlépe podle dané technologie. (26)

30

Obrázek 17: Object repository (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

3.5 Tabulky a outputs Testovanou aplikaci často potřebujeme otestovat s různými vstupy, abychom zajistili její chování při různých parametrech. Abychom si nemuseli vytvářet pokaţdé nový test, máme v QTP při kaţdém testu takzvanou Data Table. Data Table můţeme naplnit hodnotami, a to tak, ţe kaţdý řádek bude představovat jeden běh testu, přičemţ test skončí, aţ kdyţ doběhne do posledního řádku. Potom stačí nastavit výběr proměnné z Data Table. Vyhodnocení běhů takového testu se přehledně vyhodnotí podle běhů řádku samostatně. Výběr řádku Data Table můţeme pouţit jak pro vkládání z tabulky, tak pro porovnání hodnot. Dokonce dokáţeme i zapisovat data zpět do tabulky. Nemusíme samozřejmě pouţívat jenom QTP Data Table ale můţeme pouţít i externí tabulky, kupříkladu v XLS nebo CSV souboru. Také se dají posílat parametry pro spuštění testu přímo z aplikací třetí strany, jako HPQC, kdy nastavíme parametr testu před spuštěním,

31

s kterým se má test spustit a podle kterého se má chovat. V praxi je to velice často vyuţívaná metoda, například při změnách prostředí, které se nastaví právě skrze parametr (26).

Obrázek 18: Data Table (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

3.6 Debugging tests Testy, jak bylo popsáno v předchozích kapitolách, se dají v QTP dělat třemi způsoby. Dají se nahrávat recordem, dají se psát v keyword view, nebo psát ve VBS v expert view. Po běhu testu máme k dispozici přehledný report s vyhodnocením kaţdého kroku samostatně. Také si v rámci vytváření testu dokáţeme napsat checkpointy, ať uţ textové, či obrazové, které nám slouţí k vyhodnocení. Kdyţ potom alespoň jeden z checkpointů nedopadne dle očekávání, tak je celý test reportovaný jako neúspěšný. V případě potřeby dokáţeme celý test nahrávat jako video a následně si pustit celý průběh testu. V praxi je to však spíše pro ladění problémů,

nevyhodnotitelných

pomocí

jednotlivých

obrázků,

neţ

pro

standardní

vyhodnocení. Mezi nevýhody patří velikost videa, zdlouhavé vyhodnocení a nahrávání je hardwarově náročné, můţe tedy způsobovat i jiné chování při exekuci testu (nestihne se vykreslit tlačítko na obrazovce apod.) (26). Debugging, neboli ladění skriptu, je v nástroji také řešeno. V průběhu testu jej můţeme kdykoliv pozastavit buď tlačítkově, nebo zkratkou Ctrl+Alt+F5. V tu chvíli se nám zobrazí spodní debuggovací obrazovka, kde si můţeme ověřit naplněnost aktuálních hodnot. Test se také dá dopředu naplánovat, kdy se má zastavit na námi určeném místě skriptu. Samozřejmostí je i odkrokování kaţdé akce zvlášť na náš příkaz a tak si odladit skript. Nevýhodou je potom naopak editace skriptu v případě pozastavení testu, která v QTP není

32

moţná. To znamená, ţe při kaţdé poţadované změně je nutné test ukončit, upravit a začít debuggovat nanovo (26).

Obrázek 19: Debugging (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

3.7 Napojení na jiný software Test management je v HP řešený v rámci softwaru HP Quality Center. Tento software dokáţe zaznamenávat poţadavky na testy, samotné testy s různými informacemi a parametry, jejich spouštění a také defekty z proběhlých testů. Quick Test Professional je snadno integrovatelný a předpřipravený pro integraci s HP Quality Center. Napojení se dá nastavit přímo při spuštění nástroje a dá se uloţit natrvalo.

Obrázek 20: Napojení QTP na HPQC (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

33

Testy se dají ukládat včetně object repositories a všech parametrů a dokonce s přídavnými informacemi. Tyto testy se dají přímo z HP Quality Center spouštět s vybranými parametry. To umoţňuje, ţe ten samý test se můţe najednou spustit s různými nastaveními. Kaţdý spuštěný test se zaznamenává a po běhu testu, je v příloze uloţený report testu. Report si však můţe prohlídnout pouze uţivatel, který má přístup k softwaru QTP. To však neplatí o spuštění testu, kde stačí přístup jenom k HPQC softwaru (26). Testy QTP se dají lehce plánovaně spouštět i bez dodatečného softwaru - pomocí .BAT souboru a Windows Task Scheduleru, kde se dá naplánovat spuštění testu i na hodinu, kdy není moţné provést exekuci ručně.

34

4 Ukázka skriptu QTP V následující kapitole si ukáţeme, jak lze zautomatizovat test pomocí HP Quick Test Professional. Verze námi pouţitého softwaru bude HP Unified Functional Testing 12.00 a webový prohlíţeč Internet Explorer 11.04. Jako

ukázku

automatizace

jsme

si

vybrali

nákup

v internetovém

obchodu

www.bedog.cz. Pro výběr ukázky jsme si vybrali webovou aplikaci kvůli tomu, ţe jde o nejvíce automatizovanou platformu všemi různými nástroji. Také se na ni dají ukázat téměř všechny pomůcky automatizace opomínané v předchozí kapitole. Je to tedy ideální kandidát na ukázku automatizace. V tomto testu provedeme objednávku produktu, kdy nejprve zkontrolujeme správnost vstupu na stránku bitmapovým checkpointem a dále provedeme nákup námi připraveného produktu. Z HP Data table vybereme doručovací informace, kdy v případě emailu schválně provedeme test jeho nesprávného vyplnění, coţ by měl internetový obchod kontrolovat v rámci svých validací. Nakonec nasnímáme úspěšnou objednávku checkpointem. Z předchozí kapitoly víme, ţe software nám dává na výběr z třech moţností, jak dělat testy. V ukázce si předvedeme všechny tři moţnosti automatizace. Nejprve se pokusíme celý test nasnímat pomocí Recordu, který QTP nabízí. Ukáţeme si přímo, v čem je nevýhoda Recordu, kde další úpravy provedeme pomocí Keyword view. Nakonec skript upravíme do výsledné podoby pomocí Expert view. Tím zajistíme ukázku všech tří moţností vytvoření testu.

4.1 Record úpravy Moţnost Recordu nám nabízí nasnímání celého testu, kde nám QTP automaticky samo zaznamenává kroky, potřebné repository, checkpointy a jiné potřebné náleţitosti ke skriptu. Před úplným začátkem musíme spustit software, kde vybereme správný Add-in, v našem případě Web.

35

Obrázek 21:QTP (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

V dalším kroku si vytvoříme nový test, kde budeme zaznamenávat úpravy. Následně je takto čistý test připraven pro automatizaci. V horním toolbaru vyvoláme nabídku Record, nebo pomocí rychlé nabídky příslušným tlačítkem.

Obrázek 22: Spuštění Record (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

36

V tuto chvíli se nám zobrazí na monitoru malá lišta s moţnostmi týkajícími se nahrávání. Případné kliknutí na ni, stejně jako kliknutí do nástroje, se do testu nezaznamenává. Odteď můţeme simulovat celý test, jako kdybychom ani neautomatizovali. Zapneme Internet Explorer a provedeme celou objednávku krok po kroku. Kaţdý náš krok by se měl zaznamenat sám automaticky. V případě, ţe chceme uloţit nějaký checkpoint, musíme vyvolat checkpoint na liště nahrávaní. Tam si uloţíme, co chceme kontrolovat v testu a co se má vyhodnocovat. V našem případě tak provedeme ihned při vyvolaní okna internetového obchodu, kde si zkontrolujeme pomocí obrázku v horní liště stránky logo prodejce, které se bude v testu kontrolovat. Poslední checkpoint necháme na jiný způsob vykonáni, abychom si ukázali, jak lze jinak vytvořit.

Obrázek 23: Provádění Checkpointu Record (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Takhle provedeme celý simulovaný test aţ do konce. V případě, ţe jsme došli aţ k poslednímu bodu testu, jednoduše ukončíme nahrávání na nahrávací liště. Kdyţ se následně podíváme do nahraného testu, uvidíme následující, viz obrázek Record Expert view.

37

Obrázek 24: Record Expert view (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Náš test by teoreticky měl být hotový, Record automaticky zaznamenával veškerou naši činnost. Zkusíme test tedy hned pustit, ať si ověříme jeho funkčnost. Po spuštění testu nám však test hned při prvním kroku zkolabuje a report nám ohlásí neúspěšnost testu. Při bliţší kontrole reportu uvidíme, ţe test měl problém s nalezením browseru. Při pohledu zpět do vytvořeného testu zjistíme, ţe vůbec nevyvoláváme spuštění Internet Exploreru. Je to jedna z nevýhod nahrávaní komunikace, kdy Record nedokáţe zaznamenat spuštění aplikace a musí se dopsat do skriptu ručně. Také kdyţ se potřebujeme podívat do repository, tak jedině do lokální, protoţe Record nedokáţe zapisovat do sdílené repository. Výsledkem nahrávání v repository jsou sloţky a objekty, které je třeba roztřídit a vloţit do sdíleného repository pro znuvupouţitelnost. Právě nemoţnost provádění všeho pomocí Recordu odrazuje i začínající uţivatele od jeho pouţívání ve větším měřítku.

4.2 Keyword view úpravy Následující úpravy uţ budeme dělat v Keyword view. Aktuálně vypadá po nahraném skriptu Keyword view následovně, viz obrázek Record Keyword view.

38

Obrázek 25: Record Keyword view(Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Jak jsme zmínili, test padne při prvním kroku. Zkusíme tedy tento problém vyřešit a přidat spuštění brokeru, respektive Internet Exploreru. V kroku Keyword view v nabídce Itemu musíme vybrat kategorii „Utility Objects“, dále v Objectech je třeba vybrat „SystemUtil“ a v Operation vybereme „Run“, protoţe chceme spustit browser. Dále v nabízených Arguments máme moţnost vyplnit parametry, s kterými chceme objekt spustit. Ve File

vybereme

cestu

Explorer\IEXPLORE.EXE“

k browseru, a

dále

v našem

params,

případě

kde

„C:\Program

napíšeme

Files\Internet

internetovou

stránku

„www.bedog.cz“, dále vyplníme op s „open“ pro otevření Internet Exploreru a nakonec mode vybereme „3“, pro maximalizaci okna. Po spuštění testu po těchto krocích se nám test správně rozběhne spuštěním browseru a se správnou adresou, ale při kontrole bitmapového checkpointu test opět zahlásí chybu a tím dojde k failed statusu celého testu.

39

Obrázek 26: Result Checkpoint Failed (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Z vlastní zkušenosti se automaticky dívám do repository, kde mám uloţený obrázek, se kterým porovnávám načtený obrázek v testu. Podívám se na nastavení a přidávám 5 procentní pixelovou toleranci, která je v našem případě přijatelná. Po opětovném spuštění testu test prochází bitmapovým checkpointem bez problémů.

40

Obrázek 27: Nastavení Pixelové tolerance (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

V tomto reţimu pohledu si zkusíme dále udělat vybírání dat z HP Data Table. Konkrétně data, která vyplňujeme při registraci. Úplně jednoduše vyplníme Data Table našimi hodnotami od příjmení aţ po telefonní číslo, vše popořadě v jednom řádku, viz obrázek Naplnění Data table.

Obrázek 28: Naplnění Data table (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

41

Následně v kroku, kde vyplňujeme tyto informace, v sloupci Value změníme výběr stringu na výběr z Data table, kde vybereme příslušný sloupec, kde se tato informace vyskytuje. Toto uděláme s kaţdým stringem, který vyplňujeme. Následným přidáním řádku bychom docílili spuštění testu dvakrát s různými informacemi o kupujícím.

Obrázek 29: Přirazení Data table (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Keyword view pouţívají hlavně začínající uţivatelé, jedna z nevýhod je především rychlost psaní testu, kde v tomto pohledu musíme na všechno klikat a následně vybírat z moţností nebo vyplňovat. Abychom si ukázali rychlost Expert view jako protistranu, zkusíme udělat vyvolání aplikace Internet Exploreru, který jsme předtím dělali v Keyword view a zabral nám mnoho vyplňování. Stačí napsat jeden řádek, kde nám ještě pomáhá IntelliSense, který nám sám nabízí, jakou máme moţnost výběru, takový kód je napsaný rychle a přehledně. SystemUtil.Run "C:\Program Files\Internet Explorer\IEXPLORE.EXE", "www.bedog.cz", "", "open", 3

4.3 Expert view úpravy V pohledu Expert view doděláme test do výsledné podoby. Momentálně vypadá skript v Expert view následně, viz obrázek Expert view po změnách Keyword view.

42

Obrázek 30: Expert view po změnách Keyword view (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Zbývá nám vytvořit test špatně vyplněné emailové adresy a checkpointu na konci úspěšné objednávky. Špatně vyplněnou adresu, nejprve podvrhneme a to tak, ţe změníme výběr adresy ze sloupce, kde je, a podhodíme jiný sloupec, například se jménem. Celý test si do této situace pustíme s breakpointem po odeslání údajů se špatnou emailovou adresou. Po spuštění se nám test zastaví na obrazovce, kde potřebujeme nasnímat do repository chybovou hlášku, na kterou budeme chtít udělat checkpoint. Otevřeme si lokální repository a nasnímáme chybovou hlášku pomocí Object Spy.

43

Obrázek 31: Object Spy (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Přidáme nasnímanou chybu do repository s vystihujícím názvem po pozdější editaci. Následně nasnímaný objekt přesuneme přetaţením do skriptu na určené místo. Pravým tlačítkem myši nad přidaným objektem vyvoláme nabídku, kde vybereme Insert Standard Checkpoint. Ten upravíme podle námi poţadovaných vlastností - budeme hledat text „Neplatný e-mail“ s timeoutem 10 sekund. Automaticky se vytvoří v repository a také se přidá do skriptu. Poté doplníme do skriptu řádek se správně vyplněnou hodnotou z Data table a další řádek s klikem na pokračování. Tím je test špatně vyplněné emailové adresy hotový. Úplně stejně uděláme také test poslední obrazovky o úspěšné objednávce. Výsledný skript vypadá následně, viz obrázek Expert view s e-mail checkpointem.

44

Obrázek 32: Expert view s e-mail checkpointem (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Po spuštění testu a jeho dokončení se nám zobrazí následující report, viz obrázek Report Passed.

45

Obrázek 33: Report Passed (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

46

5 Best practices V následující části práce si ukáţeme jak řešit některé problémy automatizace testů, na které se dá při jejích vykonávání narazit. Ukáţeme si konkrétní praktické ukázky, které vycházejí z mojí zkušenosti při automatizaci testů. Všechny tyto rady jsou určeny pro začínající, ale i pro pokročilé developery. Doporučení by jim měli pomoci k správnému směru, jak dělat a udrţovat automatizované testy co nejefektivněji.

5.1 Inteligentní čekání Při automatizaci testů provádí za člověka test naprogramovaný počítač. Ve většině případů je počítač také rychlejší a test, který by člověku zabral i půl hodiny, je počítač schopný provést v řádu několika málo minut. S tím souvisí jeden z největších problémů při automatizaci, a to jak rychle má provádět test operace za sebou bez toho, aby to nebylo moc rychle na to, ţe test bude neúspěšný právě díky rychlosti provádění operací. Při své dosavadní praxi jsem se setkal s některými metodami, které si představíme. Asi nejjednodušší, ale velice efektivní, je nastavení pevného času při vykonávání operace, který se nemění za ţádných okolností. Efektivnost tohoto řešení spočívá v jeho jednoduchosti, kde se nemůţe nic pokazit. Zároveň při tomto řešení ztrácíme nejvíce času, protoţe musíme nastavit největší pauzu, kterou povaţujeme ještě za přijatelnou k správnosti testu. V QTP se provádí úplně jednoduše, kde před poţadovanou operací nastavíme příkazem wait 30 například čekání třicet sekund. O něco rafinovanější a sloţitější řešení je opakování hledání určitého objektu aţ dokud se korektně nezobrazí, nebo pokud nevyprší nastavené opakování. V této metodě máme také moţnost pomoci si pauzou z předchozí metody, ale jedná o kratší pauzu, v řádu jednotek sekund. Příklad můţe vypadat následovně: attempt=0 While Window("Window").WinList("ListBox").Exist(1) = False and attempt < 30 obj.MouseClick abs_x,abs_y,LEFT_MOUSE_BUTTON attempt = attempt + 1 wait 1 Wend

47

Ještě náročnější na realizaci jsou kódy připravené právě pro konkrétní místo, nebo místa skriptu, vyznačující se společnou vlastností, která se dá pouţít. Jako příklad bych uvedl přesýpací hodiny v systémech Windows, které se v některých případech objevují v rámci čekání, a kdyţ aplikace přestane načítat, zmizí. Toho se dá vyuţít na inteligentní čekání, závislé na existenci těchto přesýpacích hodin. Samozřejmě se vyuţívají metody výše uvedené jako podpora. Příklad můţe vypadat následovně: Sub hourglass attempts = 0 While getCursorID() = "65543" and attempts < 1200 wait 1 attempts = attempts + 1 Set cor = CreateObject("Mercury.DeviceReplay") cor.MouseMove RandomNumber(1,800), RandomNumber(1,600) Wend End Sub

5.2 Rozdělení skriptu Za názvem podkapitoly rozdělení skriptu se skrývá úspěšné dělení skriptu do funkcí, které přináší velkou efektivitu. Osobně se mi velice osvědčil systém, který si představíme. Při psaní nových skriptů je dobré znovupouţít kódy, které jsme napsali v jiném skriptu. QTP sice nabízí rozdělit test na více částí a ty pak jednotlivě volat z jiných skriptů. Je to však hodně zdlouhavé nastavování a není přímo jasné, kde se část kódu nachází a jestli se pouţívá. Osobně preferuji vytvoření Function Library, pro kaţdou automatizovanou aplikaci zvlášť. Tam se ukládají funkce a části kódu, které se provádějí často v rámci jedné aplikace pro ni typické. Libraries pak lze připojit a volat ze všech testů dané aplikace. Osvědčilo se mi mít ještě jedno oddělené Function Library napříč všemi projekty, kde jsou uloţené funkce, které jsou pouţitelné napříč všemi projekty. Uvedeme si příklad takového pouţití. Představme si, ţe máme dlouhodobě testovat eshop z naší ukázky. Jeden z testů, který provádíme, je registrace nového uţivatele při nákupu. Registraci uţivatele provádíme tak často v rámci testu, ţe je skvělý adept na přidání do Function Library dané aplikace. V rámci registrace právnické osoby poţadujeme vyplnění IČO. Náhodně generované IČO se však dá pouţít i v jiných aplikacích a také je veliká pravděpodobnost, ţe se nám bude do budoucna hodit. Proto je funkce na generování skvělým 48

adeptem na přidání do globální Function Library. Výhoda Function Libraries je také v tom, ţe při změně aplikace stačí měnit kód jenom v rámci jedné metody, která se pouţívá, a nemusíme kaţdý test opravovat zvlášť. Psaní nových skriptů se tak stává rychlejší s rozšiřováním globální Function Library.

5.3 Přetížení funkce Testy, které se v QTP dělají, jsou psány v jazyku VBScript. Jedna z nevýhod VBScriptu je, ţe nepodporuje přetěţování funkcí. Přetíţení funkce je metoda, umoţňující volání funkce s různým počtem parametrů. Taková funkce se následně chová různě, v závislosti na těchto parametrech. Skutečnost, ţe toto není ve VBScriptu moţné, způsobuje při psaní testů omezení. Zejména v tom, ţe pokud chceme přidat parametr do funkce (která je sdílená s mnoha jinými testy) v globální Function Library, je třeba upravit všechna volání této funkce ve všech testech, které tuto uţívají. Navíc tato místa je třeba vyhledávat ručně, protoţe funkce na sobě nemají informaci o tom, odkud jsou volány. Namísto přetíţení se však ve VBScriptu dá pouţít Dictionary objekt. Dictionary objekt byl vyvinut společnosti Microsoft a je součást VBScriptu. Dictionary si můţeme představit jako dvojrozměrné pole, které se běţně pouţívá při programování. Výhodou je, ţe nemusíme dopředu definovat délku pole a kaţdý záznam má jedinečný klíč, pomocí kterého se dá zavolat. Dim params „vytvoření proměnné Set params = CreateObject("Scripting.Dictionary") params.Add "Kategorie", "webová stránka" „přidáni klíče a položky params.Add "Podkategorie", "e-shop" params.Add "Kategorie", "psi" Existují také metody na zjištení existence klíče, nebo smazání určitého klíče. If params.Exists("Kategorie") then Msgbox "klíč existuje" Else msgbox "klíč neexistuje" End if params.Remove("Kategorie") „odstranění klíče params.RemoveAll „odstranění všech klíčů 49

Při volání funkce tedy stačí vţdy jen jeden parametr, a to Dictionary, kde se pak pouze podíváme na vybrané parametry, které nás zajímají a vůbec nevadí, ţe jsou některé nevyplněné nebo nepouţité. Přidání nového parametru do funkce v globální Function Library tedy nezpůsobí ţádné problémy v uţ stávajících voláních funkce, jelikoţ parametr je jen jeden. Nevýhoda, kterou s sebou Dictionary přináší, je nutnost znát přesný název klíčů Dictionary, kde je vţdy nutné se podívat do funkce pro připomenutí, případně mít vţdy aktuální dokumentaci. Určitě doporučuji pouţívat Objekt Dictionary hned od začátku automatizace při funkcích, které se mohou časem rozšiřovat. Pozdější přepisování funkcí na parametrizaci pomocí Dictionary je velice obtíţné a časově náročné kvůli ručnímu prohledávání všech funkcí.

5.4 Vlastní report Quick Test Professional nabízí vlastní report, jak jsme si ukazovali v ukázce, kde vyhodnocuje všechny checkpointy. Také nabízí moţnost nahrání celého testu na video, které se poté dá prohlédnout. Licence je poměrně drahá a otevření takového reportu vyţaduje nainstalování tohoto softwaru na počítač uţivatele. Ve většině velkých firem s desítkami zaměstnanců, kteří se věnují testování, mají QTP nainstalované jenom vybraní jedinci, kteří se automatizaci věnují na plný úvazek. Také testy se většinou pouští v noci a vyhodnocování probíhá aţ ráno. S vyhodnocením testu je tedy tím pádem problém, protoţe prohlédnout si plnohodnotný report nemůţou všichni testeři ale jen ti, kteří mají QTP. To ale většinou nejsou ti, kteří by se výsledkům testů měli primárně věnovat. Všichni uţivatele vidí výsledky testů, ale nevidí jejích průběh, tedy kdyţ je test Failed, tak nevidí proč. Tento problém se dá řešit přídavnými informacemi, které v průběhu testu uloţíme mimo základní report. Například uloţené screenshoty obrazovky, které si stačí prohlédnout a je okamţitě jasné, kde nastala chyba i bez otevírání reportu. V následujících skriptech si ukáţeme, jak uloţit screenshot obrazovky s chybou do nástroje HP Quality Center, odkud se testy dají spouštět. screenshot = getScreenshot (Desktop, "C:\Temp\QTPScreenshots") addTestSetAttachment "ERROR","The expected result did not appear.", screenshot

50

Function getScreenshot(object, folderName ) „presny cas pro unikatnost mDate = Now fileName = mDate & ".png" object.CaptureBitmap folderName & fileName, True getScreenshot = folderName & fileName End Function Function addTestSetAttachment (attName, attDescription, screenshot) „vypnutí zobrazení provedených akcí v reportu Reporter.Filter = rfDisableAll If isRunningFromHPQC Then „příprava místa pro uložení attachmentu v HPQC Set AttachmentFactory = QCUtil.CurrentRun.Attachments Set ObjAttch = AttachmentFactory.AddItem(null) „nahrazení nepovolených znaků v názvu attachmentu attName = replace(attName, "/", "") attName = replace(attName, "\", "") attName = replace(attName, ":", "") attName = replace(attName, "*", "") attName = replace(attName, "?", "") attName = replace(attName, """, "") attName = replace(attName, "<", "") attName = replace(attName, ">", "") attName = replace(attName, "|", "") ObjAttch.Name = attName ObjAttch.Description = attDescription ObjAttch.FileName = screenshot ObjAttch.Post End if

51

„zapnutí zobrazení provedených akcí v reportu Reporter.Filter = rfEnableAll End Function

5.5 Zdroj exekuce Mnohdy se můţe hodit informace, odkud a z jakého důvodu je test spouštěný. Příkladem vyuţití této informace je pak to, ţe například neukládáme informace o běhu testu a jinak nezahlcujeme paměť, pokud provádíme exekuci testu pouze pro ladící účely. Také to naopak nabízí moţnost zaznamenávat více informací o běhu testu do reportu při ostré exekuci, které se dají následně pouţít. Kdyţ ladíme test a pouštíme si ho ručně dokola, tak nepotřebujeme ukládat rozsáhlé informace o průběhu testu. V předchozí podkapitole, kterou jsme si ukazovali, jsme pouţili také jednu takovou funkci, a to „isRunningFromHPQC“. Byla pouţita z důvodu, abychom zbytečně neukládali attachmenty, kdyţ nepouštíme test z HPQC. Function isRunningFromHPQC If QCUtil.IsConnected Then Reporter.ReportEvent micDone, "Connected", "Connected to server" & QCUtil.QCConnection.ServerName isRunningFromHPQC = True Else Reporter.ReportEvent micDone, "Connected", "Not connected to Quality Center" isRunningFromHPQC = False End If End Function

5.6 Vypnutí zaznamenání informací do reportu Po běhu automatizovaného testu máme k dispozici přehledný report. Tento report nám zobrazuje kaţdé vyhodnocení checkpointu a podle nich také vyhodnocuje celý průběh testu. Stačí, kdyţ je jeden checkpoint failed/neúspěšný a námi testovaný test je automaticky také neúspěšný. Při testování však můţeme narazit na checkpoint, který bychom chtěli kontrolovat bez ovlivnění výsledného reportu, nebo jen z nějakého důvodu nechceme zapisovat výsledek akce do reportu. Typickým příkladem, kde by se tato funkcionalita dala vyuţít, je při čekání na 52

připravenost aplikace pro následnou další akci. Muţe to být například obrázek nebo text, kdy víme, ţe při jeho zobrazení je v aplikaci načteno uţ vše potřebné a my můţeme pokračovat v testu dál. Na checkpoint lze navázat čekací podmínku s několika pokusy nebo jiným inteligentním čekáním, kdy checkpointem ověříme načtení. Všechny neúspěšné pokusy v průběhu načítání stránky by však způsobily výslednou neúspěšnost celého testu, je třeba je tedy z reportu odstranit. Vypnutí zapisování akcí do reportu se zapíná ve skriptu příkazem „Reporter.Filter = rfDisableAll” a vypíná „Reporter.Filter = rfEnableAll”. Tuto funkcionalitu jsme pouţili uţ dříve v ukázce vlastního reportingu, kdy jsme nechtěli ukládat akce vlastního ukládání attachmentu do reportu kvůli vetší přehlednosti. Moţnost vyuţití checkpointu s vypnutým zapisováním do reportu můţe vypadat následovně. Reporter.Filter = rfDisableAll attempts = 0 Do wait 1 attempts = attempts + 1 Loop until Browser("Browser").check Checkpoint("Checkpoint") or attempts > 10 Reporter.Filter = rfEnableAll

5.7 Ověřování vyplněných hodnot V mé praxi automatizace jsem se často setkal s problémem, kdy testy končily statusem Failed, ale v skutečnosti byly v pořádku. Hlavním důvodem bylo, ţe se někdy špatně vyplnilo nějaké políčko. Řešení je poměrně jednoduché - stačí pouze kontrolovat po kaţdém vyplnění hodnoty, zda se správně zapsala, a popřípadě ji tam zkusit dát ještě jednou. Je to snadno a rychle řešitelný problém, který přináší velkou efektivitu při řešení. Můţe se to řešit více funkcemi, například funkcí, která zadá a ověří, zda se správně vyplnila hodnota a pokud ne, zkusí ji vyplnit ještě jednou. Sub setAndVerify (object, objValue) attempts = 0 Do If object.exist(1) then 53

Object.select trim(objValue) End If If isEmpty(object.getROProperty("value")) then empty = True attempts = attempts + 1 Else „ lcase z duvodu automaticke zmeny aplikaci po nasetovani If lcase(object.getROProperty("value")) <> lcase(objvalue) then empty = True attempts = attempts + 1 Else empty = False End If End If Loop until (empty = False) or (attempts > 5) End Sub

5.8 Hromadný přepis Repository Kdyţ automatizujeme delší čas nějakou robustní aplikaci, naše repository se neustále zvětšuje. O nutnosti správného a přehledného pojmenováni repository pro lehké doplnění a dohledávání jsme uţ mluvili. Při zvětšujícím se repository budeme pouţívat většinou stejný identifikátor pro všechny objekty na jejich rozlišení. Při automatizaci webu to bývá mnohdy html_id, které by měl mít kaţdý objekt vţdy unikátní. Za trvání vývoje aplikace se však můţe stát (a z vlastní zkušenosti mohu potvrdit, ţe se to stává poměrně často), ţe se některé identifikátory stanou nepouţitelné. Bývá to způsobeno především u aplikací, kde HTML je generováno frameworkem. Je nutné najednou pouţívat jiný nebo jinou skupinu identifikátorů neţ doposud. To v repository znamená přepis všech identifikátorů, tedy vypnutí starých a nastavení nových. Je to velice pracná a monotónní práce, která můţe trvat i několik hodin, podle počtu objektů v repository. Navíc často dochází k překlepům, které způsobují zbytečné chyby. Existuje však rychlejší cesta úprav repository. Nejprve je důleţité otevřít Object repository manager, kde máme moţnost vyexportovat repository do .XML formátu. Následně můţeme uloţené repository otevřít v přehledném textovém editoru. Tam hromadně najít a nahradit identifikátor jiným. Následně je nutno změněné repository zpět naimportovat. 54

Stejně se dá postupovat i při hromadnému přidání nového parametru do repository, případně při jiných hromadných úpravách.

Obrázek 34: Export repository (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

V případě hromadné změny value/hodnoty určitého parametru není nutný export a úprava mimo QTP. Object repository QTP dokáţe dělat hromadné změny také. Nedokáţe však smazat/přidat určitý parametr nebo ho nahradit, ale jenom upravit jeho value/hodnotu.

55

Obrázek 35: Export .xml (Zdroj: autor)

5.9 Zavírání QTP Automatizované testy spouštíme většinou v dobu, kdy nebudou blokovat prostředí a ostatní procesy v testingu. Také se pouštějí nejčastěji v celých sadách a na výsledky testu se díváme aţ po nějaké době, tedy po předpokládaném běhu všech testů. Spouští se kupříkladu v noci, kdy nezatěţují a nepřekáţí a vyhodnocení probíhá aţ v pracovních hodinách dalšího dne. Velice důleţité tedy je, aby doběhly všechny testy a aby případně zaseknutý test skončil a spustily se testy následující. V případě zaseknutí testu nějakou chybou není přítomen tester na jeho vypnutí, a proto je potřeba udělat patřičné kroky k jeho vypnutí automaticky. Souvisí s tím i vypnutí softwaru po doběhu testu, protoţe stejně jako zaseknutý test i nástroj samotný blokuje licenci. Můţe se nám tedy snadno stát, ţe si vyčerpáme všechny licence po doběhu testů, na spuštění na jiném PC nám uţ nezbude licence a budeme muset ručně vypínat procesy na serverech, kde testy běţely. 56

Nastavení vypínání nástroje QTP po běhu testů se nastavuje v instalačním umístnění softwaru, většinou tedy „C:\Program Files (x86)\HP\Unified Functional Testing\bin“, kde najdeme soubor „mic.ini“. V tomto souboru najdeme řádek obsahující parametr s hodnotou „CloseToolAfterRuns=0“ a nastavíme hodnotu parametru na „CloseToolAfterRuns=1“. Nastavení parametru nám zabezpečí zavírání softwaru po běhu testu, spuštěného z jiného místa neţ přímo ručně z editoru nástroje. Tedy například z Windows Scheduleru jako naplánovanou úlohu, nebo i z jiných nástrojů, jako je HP Quality Center.

Obrázek 36: Změna CloseToolAfterRuns (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

Zavírání po doběhu testu nám však nevyřeší problém spuštění testu po zaseknutém testu z různých příčin. Moţností vypnutí takového testu, aby neblokoval spuštění nového testu, je uţ v zavolání jeho exekuce. Testy se obvykle spouštějí pomocí Windows Scheduleru, kde se dá nastavit přesný čas spuštění testu. Windows Scheduler spouští dávkový soubor, který obsahuje spuštění daného testu a můţe vypadat následovně: Dim aplikace Dim test Set aplikace = CreateObject("QuickTest.Application") aplikace.Launch aplikace.Visible = True aplikace.Open "C :\ Tests\Test1" 57

Set test = aplikace.Test test.Run , False Trik, který spočívá ve vypnutí testu pro spuštění nového testu, je před spuštěním nového testu zavolat ukončení všech spuštěných instancí QTP. Opět to lze udělat pomocí dávkového souboru, který by měl obsahovat volání *.VBS souboru, obsahujícího následující text: Set objWMIService = GetObject(“winmgmts:\\.\root\CIMV2″) Set processes = objWMIService.ExecQuery (“Select * from Win32_Process Where Name = „QTPro.exe‟”) For Each process in processes process.Terminate() Next Před kaţdým spuštěním naplánovaného testu stačí zavolat tento dávkový soubor. Můţeme si tedy naplánovat spuštění jednoho dávkového souboru, který nejprve zavolá vypnutí všech instancí QTP a pak dalšího, který bude následně volat exekuci vybraných testů.

5.10 Otevření testu najednou Při programování určité funkcionality, a nejedná se pouze o automatizované skriptování, ale v obecné rovině o jakékoliv programování v jakémkoliv jazyce na různých platformách, si programátor často pomáhá uţ předem naprogramovaným kódem, ze kterého popřípadě můţe část kódu překopírovat, či se pouze inspirovat hotovým řešením. Z tohoto pohledu to pro QTP ale není nijak lehká úloha. Základní problém, který přitom nastává, je ten, ţe software nedovoluje zobrazení více testu najednou. Kopírování nebo náhled do uţ provedených testů se tedy stává velice obtíţným, kde nejprve právě prováděný test musíme uloţit, otevřít nový test podívat se nebo vykopírovat určitou část a znovu otevřít dřívější test a aţ následně vloţit kód. Je to velice časově náročná věc, která často odrazuje uţivatele od jakékoliv myšlenky kopírování či jen náhledu. Řešení problému není tak náročné, ale pro nového a nezkušeného uţivatele je často skryté. Se softwarem Quick Test Professional se při instalaci nainstalují také pomocné programy. Jeden z těchto programů je také QuickTest Script Editor. Editor najdeme ve stejném umístnění jako primární software. QuickTest Script Editor dokáţe otevřít kaţdý test a také Function Library, bez ohledu na to, co je otevřeno v primárním okně QTP. Takto si můţeme otevřít dva testy a dívat se do nich, respektive kopírovat mezi nimi zároveň. Editor 58

umoţňuje dělat i změny a ukládat je, ale nenabízí moţnost podívat se například do Repository, umoţňuje jenom prohlédnout kód hlavního skriptu. Také se nabízí moţnost otevřít si jiný test v softwaru, kde máme uloţené testy, jako je HP Quality Center, je to však velice nepraktické kvůli zdlouhavému překlikávání a rovněţ dělá problém pomalé načítání. Kostrbatost tohoto řešení (uţívání dvou aplikací v rámci jednoho nástroje) si však uvědomili i ve společnosti Hewlett Packard, kde od verze softwaru 11.50, která se přejmenovala na Unified Functional Testing, přišli s novým řešením. V nové verzi Quick Test Professional se dá vytvořit nový typ pohledu, a to Solution. Do Solution se dá následně přidat neomezené mnoţství Testů, Function Libraries, nebo také vytvářet nové testy a nové Libraries. Testy jsou přidávány se všemi jejich součástmi a repositories, jsou to tedy plnohodnotné testy. S novou verzí také zmizel zmiňovaný program QuickTest Script Editor, který se v instalaci uţ nenachází.

Obrázek 37: Solution (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

59

5.11 Zobrazování hesel v testech Quick Test Professional testy jsou často uloţeny na v nějakém serverovém úloţišti, nejčastěji v rámci HP Quality Center. Výhoda tohoto umístění je v tom, ţe se dají snadno spouštět kýmkoliv, kdo má přístup do zmiňovaného nástroje. Přináší to však i nevýhody v podobě toho, ţe všichni vidí i obsah uloţených testů. S tím souvisí i bezpečnostní hledisko problém, ţe všichni vidí uloţená hesla, která se v testech pouţívají. Abychom odstranili tento nedostatek, musíme hesla v testech zakódovat tak, aby je nebylo moţno lehce přečíst z textu. Jedno z řešení je vytvoření speciálních funkcí, které by zaheslovaly a následně odheslovaly dané přístupové údaje. Problémem by však nadále zůstala moţnost přečíst si v nástroji tyto funkce a pouţít je v samostatném skriptu (jde v podstatě o běţný VBScript) pro získání citlivých údajů. Software nám však nabízí nástroj Password Encoder, který je jedním z podpůrných nástrojů, instaluje spolu s hlavním nástrojem a je i umístěn v adekvátním umístění v nabídce Start v záloţce QTP v podmenu Tools. Pouţívání je velice jednoduché, stačí zadat text, který chceme zamaskovat, a encoder nám uţ text sám převede do výsledné nečitelné skupiny znaků. Tu si následně můţeme vykopírovat.

Obrázek 38: Password Encoder (Zdroj: Password Encoder, Hewlett Packard, vlastní úprava)

Vloţení tohoto kódu do testu se provádí pomocí metody setSecure, která v sobě obsahuje odmaskování. Příslušný algoritmus ale není uţivateli znám. Takto vloţený kód v testu není nijak čitelný. Pokud bychom tedy chtěli heslo zpětně získat, ţádný „Password Decoder“, který by byl součástí nástroje QTP, neexistuje. Dá se to však obejít – pokud zamaskované heslo vloţíme metodou setSecure do standardního pole, které neobsahuje místo textu hvězdičky/tečky, zobrazí se nám v příslušném poli odmaskované heslo. Není zde ţádná kontrola, kam je heslo vkládáno. K tomu, abychom toto mohli provést, potřebujeme však mít 60

nainstalovaný nástroj QTP, a tedy ze softwaru kde jsou testy pouze zobrazeny (např. HP Quality Center), se nic nedozvíme. Metoda je tedy v určitém měřítku pro pouţití bezpečná.

5.12 Nastavení prostředí a QTP Prostředí, kde se automatizované testy spouští, je velice důleţité mít správně nastaveno. Předchází to neúspěšným výsledkům testů z důvodu jiných neţ chybou aplikace, kterou má test odhalit. Také samotné nastavení nástroje QTP je důleţité mít správně provedené. V závěru práce se pokusím ukázat nastavení, na které se často zapomíná, dokáţe udělat hodně škody, a které se velice těţko odhaluje jako příčina problému.

5.12.1 Oznamovací bubliny Spouštění testu v prostředí Windows s sebou nese některá úskalí. Kdykoliv se můţe stát, ţe se spustí jiný proces, který ten náš bude blokovat. Nebo se v okamţiku kliknutí na nějaký objekt před daným objektem zobrazí jiný a automatizovaný test si myslí, ţe vše provedl v pořádku, a ţe odhalil chybu, která vznikla neprovedením dané akce. Jedním z těchto prvků, který způsobuje neúspěch testů, jsou oznamovací bubliny Windows, které informují uţivatele o změnách prostředí, zobrazují hrozby, moţnosti systému a také nabízí aktualizace a podobně. Často se stává, ţe se nám bublina zjeví v nevhodnou chvíli a screenshot, který uděláme, buď obsahuje bublinu, maskující potřebné informace (nepravděpodobné vzhledem k umístění, ale moţné), nebo ji naopak neobsahuje, ale způsobí chybu a my se nedozvíme, ţe ji způsobila oznamovací bublina, protoţe screenshot se vytváří aţ určitý čas po výskytu chyby, kdy bublina ze systému uţ zmizela. Proto doporučuji zakázat zobrazování bublin ve Windows celkově. Pro vypnutí bublin musíme spustit Registry Editor, který spustíme například v nabídce Start. V moţnosti pro spuštění (Run/Spustit) spustíme „regedit“ a objeví se nám okno Registry

Editor.

V něm

najdeme

záloţku

„HKEY_CURRENT_USER\Software\

Microsoft\Windows\CurrentVersion\Explorer\Advanced“, kde vytvoříme novou hodnotu DWORD a pojmenujeme ji „EnableBalloonTips“ a nastavíme ji na hodnotu „0“. Následně můţeme zavřít Registry Editor a restartovat systém. Tím jsme zakázali vypnutí oznamovacích bublin v systémech Windows.

61

Obrázek 39: Vytvoření EnableBalloonTips (Zdroj: Registry Editor, Microsoft, vlastní úprava)

5.12.2 Nastavení jazykové verze Quick Test Professional přebírá některá nastavení z nastavení systému Windows. Jednou z věcí, kterou tento nástroj přebírá z nastavení systému, je nastavené jazykové verze systému pro Text Services. Nastavení jiné jazykové verze systému, neţ uţívá testovaná aplikace, způsobuje problémy. Zejména při rozpoznávaní diakritiky v textech. Nesjednocení způsobuje, ţe namísto znaků s diakritikou pouţívá QTP znaky bez diakritiky. Nastavením poţadované jazykové verze se dá jednoduše způsobeným problémům předejít.

62

Obrázek 40: Nastavení jazyka Text Services (Zdroj: Text Services, Microsoft, vlastní úprava)

5.12.3 Smart identification Identifikaci objektů z repository jsme uţ probírali v dřívějších kapitolách. O tom, co však QTP dělá, kdyţ nenajde přesně objekt v repository, jsme však nemluvili. Kdyţ software nemůţe najít přesný objekt v repository, protoţe tam takový není, tak se snaţí vybrat co nejpodobnější objekt. V nástroji se nastavení jmenuje „Smart Identification“ a podle základního nastavení je automaticky zapnuto. Smart Identification si vţdy nenajde podobný objekt a někdy správně zahlásí, ţe objekt neexistuje. Princip, na kterém toto rozpoznávání funguje, však není dokonalý. Chyby nastávají zřídka, ale o to jsou nepříjemnější a závaţnější. Modelový příklad, kdy nastává problém, je v případě hledání textu, kupříkladu „Order has been accepted“. Kdyţ se však objeví nápis „Order has not been accepted“, Smart Identification uvidí skupinu znaků s velkým procentem shody a vyhodnotí text jako správný. To je ale v tomto případě fatální chyba, která můţe mít velké následky. V reportu se ukáţe sice výstraha typu warning, ţe byl pouţit Smart Identification, ale celý test je Passed, coţ je mnohdy jediná informace, která nás při vyhodnocení kladně ukončených testů zajímá. 63

Z těchto důvodu doporučuji rovnou při prvním nastavení Smart Identification vypnout, i sám osobně jsem se potkal s problémy, způsobenými touto vymoţeností. Smart Identification se vypíná buď pro konkrétní objekt v repository, pro jednotlivý běh testu, nebo globálně pro celý test, a to následovně. V hlavní nabídce v toolbar liště najdeme Tools a tam „Object Identification“. Tam pro kaţdou skupinu objektu musíme vypnout poloţku „Enable Smart Identification“. Po následném uloţení máme vypnutý Smart Identification v testu.

Obrázek 41: Vypnutí Smart identification (Zdroj: Quick Test Professional, Hewlett Packard, vlastní úprava)

64

Závěr Ţijeme v době, kterou lze bez okolků nazvat dobou počítačů. Většina z nás si svou práci bez uţití počítače ani nedokáţe představit, denně ho také vyuţíváme při svoji práci. Softwarové společnosti vyvíjejí technologie, které lidem všemi různými způsoby usnadňují práci. Počítač dnes proto najdeme v kaţdé domácnosti i firmě, ať uţ ve státním, či firemním sektoru. Dnešní společnost klade stále vyšší nároky na software, který pouţívá, ať uţ doma, či v pracovním prostředí. Můţe jít o rychlost, přesnost, jednoduchost uţití, explicitnost atd. Proto je důleţité, aby byl daný software před uvedením na trh důkladně otestovaný. Testování představuje proces, ve kterém tester nachází a reportuje nedostatky aplikace za účelem jejich následného odstranění. Zároveň ověřuje, nakolik je software připravený na ostré spuštění. Cílem mé práce bylo analyzovat principy automatizovaného testování, ukázat jak efektivně automatizovat a v neposlední řadě dát čtenářům rady k překonání největších a palčivých problémů při automatizovaném testovaní. Na trhu existuje nespočetné mnoţství testovacích nástrojů a můţeme si vybrat z komerčních či volně dostupných, které s sebou přináší mnohdy různá rizika. Téţ si můţeme vybrat z dvou základních druhů z pohledu testování GUI vrstvy či HTTP rozhraní. Podrobněji jsem se tomu věnoval v druhé kapitole této práce. V ukázce automatizace skriptu představuji základní úkony automatizace v nástroji Quick Test Professional. Ty by měly pomoci začínajícím test developerům k pochopení základních funkcí a k jejich snadnému osvojení. Sám pracuji jako IT Test Specialist v nadnárodní společnosti, a proto jsem své zkušenosti pouţil na vykreslení největších problémů, se kterými se v praxi setkávám. Moje práce dává odpovědi na otázky, jak řešit následující problémy automatizovaných testů: inteligentní čekání, rozdělení skriptu, přetíţení funkce, vlastní report, místo spouštění, 65

vypnutí zaznamenání reportu, ověřování vyplněných hodnot, hromadný přepis repository, zobrazování hesel v testech, zavíraní QTP, otevření testu najednou. Všem těmto problémům a jejich řešením jsem se podrobně věnoval v poslední kapitole. Představují také největší přínos práce, kde jsou v praktických příkladech ukázky a návody, jak se těmto problémům vyhnout a jak je řešit.

66

Seznam použité literatury 1. SCOTT, Alister. Pride and Paradev. Brisbane: Leanpub, 2013. Dostupné z: https://leanpub.com/pride-and-paradev 2. BUCHALCEVOVÁ, Alena a Jan KUČERA. Hodnocení metodik vývoje informačních systému z pohledu testování. Systémová integrace. 2008, č. 2, s. 42 – 43. ISSN 12109479. 3. ROWE, Steve. What Is Test Automation? In: MSDN blog [online]. Dec 19, 2007 [cit. 2014-04-12]. Dostupné z: http://blogs.msdn.com/b/steverowe/archive/2007/12/19/what-is-test-automation.aspx 4. BACH, James. Lessons learned in Test automation. In: [online]. Dec 19, 2007 [cit. 2014-04-12]. Dostupné z: http://www.satisfice.com/blog/archives/118 5. ZAFAR, Rehman. What is software testing? What are the different types of testing? In: Codeproject [online]. Mar 20, 2012 [cit. 2014-03-30]. Dostupné z: http://www.codeproject.com/Tips/351122/What-is-software-testing-What-are-thedifferent-ty) 6. DEBONO, Mark. Functional vs Non Functional Testing. In: Reqtest [online]. Apr 17, 2012 [cit. 2014-03-13]. Dostupné z: http://www.reqtest.com/blog/functional-vs-nonfunctional-testing/ 7. SOFTWARE TESTING STUFF. Functional Testing Vs Non-Functional Testing. Softwartestingstuff.com [online]. [cit. 2014-03-02]. Dostupné z: http://www.softwaretestingstuff.com/2007/10/functional-testing-vs-nonfunctional.html 8. HLAVA, Tomáš. Fáze a úrovně provádění testu. In: [online]. August 21, 2011 [cit. 2014-02-25]. Dostupné z: http://testovanisoftwaru.cz/tag/fat/ 9. FEWSTER, Mark and Dorothy Graham. Software Test Automation. Effective use of test execution tools. New York: Pearson Education, 1994. ISBN 0-201-33140-3. 10. LINK, Johannes. Unit Testing in Java: How Tests Drive the Code (The Morgan Kaufmann Series in Software Engineering and Programming). USA: MKP, 2013. ISBN 1-55860-868-0. 11. WATIRMELON. Introducing the software testing ice-cream cone (anti-pattern). In: Watirmelon [online]. 31 Jan 2012 [cit. 2014-03-22]. Dostupné z: 67

http://watirmelon.com/tag/ice-cream-cone/ 12. SMART BEAR. Automate Your Functional Tests. Smarbear.com [online]. 2014 [cit. 2014-02-22]. Dostupné z: http://smartbear.com/products/qa-tools/automated-testingtools/ 13. SELENIUMHQ. Selenium-IDE. Selenium.org [online]. © 2008-2012, last modified on 21.04.2014 [cit. 2014-04-22]. Dostupné z: http://docs.seleniumhq.org/docs/02_selenium_ide.jsp#chapter02-reference 14. Apache jmeter. Apache.org [online]. ©1999 - 2013[cit. 2014-03-02]. Dostupné z: https://jmeter.apache.org/ 15. HP. Hp.com [online]. ©2014 [cit. 2014-03-05]. Dostupné z: http://www8.hp.com/us/en/software-solutions/unified-functional-testing-automatedtesting/demos-documents.html#!&pd1=1 16. BORLAND. Silk test. Borland.com [online]. ©1994-2009 [cit. 2014-03-09]. Dostupné z: http://www.borland.com/products/silktest/read/ 17. SOAPUI. The Swiss-Army Knife of Testing. Soapui.org [online]. ©2014 [cit. 201403-29]. Dostupné z: http://www.soapui.org/About-SoapUI/what-is-soapui.html 18. IBM. Rational Functional Tester. In: IBM [online]. [cit. 2014-04-13]. Dostupné z: http://www-03.ibm.com/software/products/en/functional 19. HELPPI, Ville-Veikko. Best Practice #1: Increase efficiency and productivity with Test Automation. In: Testdroid [online] Oct 16, 2013. [cit. 2014-03-13]. Dostupné z: http://testdroid.com/testdroid/5851/increase-efficiency-and-productivity-with-testautomation 20. IBM. IBM's Test Automation Strategy: Build your test automation architecture around IBM Rational Quality Manager. In: IBM [online]. [cit. 2014-04-13]. Dostupné z: https://www.ibm.com/developerworks/rational/library/10/build-test-automationaround-rational-quality-manager/ 21. IBM. Supplement for supported software for Rational Functional Tester version 8.5. In: IBM [online]. [cit. 2014-03-16]. Dostupné z: http://www01.ibm.com/support/docview.wss?uid=swg27038243 22. IBM. IBM Rational Functional Tester (Data Sheet-USEN) In: IBM [online]. 20 Dec 2013 [cit. 2014-02-16]. Dostupné z: http://www-01.ibm.com/common/ssi/cgibin/ssialias?infotype=PM&subtype=SP&appname=SWGE_RA_RA_USEN&htmlfid= RAD14072USEN&attachment=RAD14072USEN.PDF 68

23. WILSON, Nathan and Thomas E. Murphy. Magic Quadrant for Integrated Software Quaily Suites. In: [online]. July 11, 2013 [cit. 2014-04-13]. Dostupné z: http://www.gartner.com/technology/reprints.do?id=11H9N7L3&ct=130716&st=sb%2520 24. HP QuickTest Professional. [online]. © 1992 – 2009 [cit. 2014-03-30] Dostupné z: http://www.asi-test.com/Docs/QTTutorial.pdf 25. HP QuickTest Professional. [online]. © 2003 [cit. 2014-03-31] Dostupné z: http://students.depaul.edu/~slouie/QTUsersGuide.pdf

69

Seznam použitých zkratek GUI

– Graphic User Interface

HPQC

– HP Quality Center

HTML

– HyperText Markup Language

HTTP

– Hypertext Transfer Protocol

QTP

– Quick Test Professional

RFT

– Rational Functioanl Tester

SOA

– Service Oriented Architecture

SOAP

– Simple Object Access Protocol

TCP

– Transmission Control Protocol

UFT

– Unified Functional Testing

VBscript

– Visual Basic Scripting Edition

70

Seznam obrázků OBRÁZEK 1: MANUÁLNÍ VS. AUTOMATIZOVANÉ TESTY (ZDROJ: (21)) ................................................................................... 13 OBRÁZEK 2: POROVNÁNÍ NÁKLADŮ MANUÁLNÍHO A AUTOMATIZOVANÉHO TESTOVÁNÍ (ZDROJ: (10))......................................... 13 OBRÁZEK 3: GUI TESTY (ZDROJ: (11)) ........................................................................................................................... 14 OBRÁZEK 4: GUI TEST 2 (ZDROJ: (9)) ............................................................................................................................ 15 OBRÁZEK 5: SOFTWAROVÉ TESTOVÁNI (ZDROJ: (20)) ........................................................................................................ 17 OBRÁZEK 6: GUI (ZDROJ: (15)) .................................................................................................................................... 19 OBRÁZEK 7: BORLAND SILK TEST (ZDROJ: (16)) ............................................................................................................... 20 OBRÁZEK 8: SMARTBEAR (ZDROJ: (12)) ......................................................................................................................... 21 OBRÁZEK 9: GUI TESTOVÁNÍ (ZDROJ: (13)) .................................................................................................................... 22 OBRÁZEK 10: SILK PERFORMER (ZDROJ: (16)) ................................................................................................................. 23 OBRÁZEK 11: APACHEJMETER (ZDROJ: (14)) .................................................................................................................. 24 OBRÁZEK 12: SOAPUI (ZDROJ: (17)) ........................................................................................................................... 25 OBRÁZEK 13: IBM RATIONAL (ZDROJ: (19)) ................................................................................................................... 26 OBRÁZEK 14: ČÁST ÚVODNÍ KLASICKÉ OBRAZOVKY (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ...... 28 OBRÁZEK 15: UKÁZKA KEYWORD VIEW (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) .................... 29 OBRÁZEK 16: UKÁZKA EXPERT VIEW (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ........................ 29 OBRÁZEK 17: OBJECT REPOSITORY (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ........................... 31 OBRÁZEK 18: DATA TABLE (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ..................................... 32 OBRÁZEK 19: DEBUGGING (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ..................................... 33 OBRÁZEK 20: NAPOJENÍ QTP NA HPQC (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) .................. 33 OBRÁZEK 21:QTP (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ................................................ 36 OBRÁZEK 22: SPUŠTĚNÍ RECORD (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ............................. 36 OBRÁZEK 23: PROVÁDĚNÍ CHECKPOINTU RECORD (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ...... 37 OBRÁZEK 24: RECORD EXPERT VIEW (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ........................ 38 OBRÁZEK 25: RECORD KEYWORD VIEW(ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ..................... 39 OBRÁZEK 26: RESULT CHECKPOINT FAILED (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ................ 40 OBRÁZEK 27: NASTAVENÍ PIXELOVÉ TOLERANCE (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA)......... 41

71

OBRÁZEK 28: NAPLNĚNÍ DATA TABLE (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ....................... 41 OBRÁZEK 29: PŘIRAZENÍ DATA TABLE (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ...................... 42 OBRÁZEK 30: EXPERT VIEW PO ZMĚNÁCH KEYWORD VIEW (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ..................................................................................................................................................................... 43 OBRÁZEK 31: OBJECT SPY (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ...................................... 44 OBRÁZEK 32: EXPERT VIEW S E-MAIL CHECKPOINTEM (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) .. 45 OBRÁZEK 33: REPORT PASSED (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ................................ 46 OBRÁZEK 34: EXPORT REPOSITORY (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) .......................... 55 OBRÁZEK 35: EXPORT .XML (ZDROJ: AUTOR) ................................................................................................................... 56 OBRÁZEK 36: ZMĚNA CLOSETOOLAFTERRUNS (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ........... 57 OBRÁZEK 37: SOLUTION (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ........................................ 59 OBRÁZEK 38: PASSWORD ENCODER (ZDROJ: PASSWORD ENCODER, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) ................................ 60 OBRÁZEK 39: VYTVOŘENÍ ENABLEBALLOONTIPS (ZDROJ: REGISTRY EDITOR, MICROSOFT, VLASTNÍ ÚPRAVA) ............................... 62 OBRÁZEK 40: NASTAVENÍ JAZYKA TEXT SERVICES (ZDROJ: TEXT SERVICES, MICROSOFT, VLASTNÍ ÚPRAVA)................................... 63 OBRÁZEK 41: VYPNUTÍ SMART IDENTIFICATION (ZDROJ: QUICK TEST PROFESSIONAL, HEWLETT PACKARD, VLASTNÍ ÚPRAVA) .......... 64

72

Seznam tabulek

TABULKA 1: MATICE (ZDROJ: AUTOR) ............................................................................................................................ 18

73