Vysoká škola ekonomická v Praze. Automatizované testování

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Katedra informačních technologií

Student Vedoucí bakalářské práce

: Lukáš Pouzar : Ing. Alena Buchalcevová, Ph.D

TÉMA BAKALÁŘSKÉ PRÁCE

Automatizované testování

ROK : 2007

Prohlášení Prohlašuji, že jsem bakalářskou práci zpracoval(a) samostatně a že jsem uvedl(a) všechny použité prameny a literaturu, ze kterých jsem čerpal(a).

V Praze dne 11.01.2007

...................................................... podpis


Abstrakt Testování software je časově a finančně náročný proces, který je součástí vývojového procesu. Společnosti, které používají rozsáhlé informační systémy, se snaží uvedenou náročnost testování snížit, proto často využívají tzv. automatizovaného testování. Cílem práce je vytvořit přehled o vybraných způsobech automatizovaného testování. Tento přehled bude vytvořen na základě popisu čtyř vybraných nástrojů, které umožňují testování zautomatizovat. Každý nástroj používá k automatizaci testování různé postupy. U vybraných nástrojů bude popsáno jejich hlavní zaměření v rámci automatizovaného testování, jakým způsobem probíhá jejich instalace, jak vytvářejí potřebné testy, jak vypadá jejich grafické uživatelské rozhraní, jakým způsobem reportují výsledky o stavu proběhlého testu a zda jsou volně šiřitelné či nikoliv. Podle těchto údajů budou nástroje zhodnoceny.


Abstract Testing of software, the part of the developing process, is time-consuming and expensive process. Companies, that use wild range of information systems are trying to decrease the mentioned costingness, therefore they often use so-called automated testing. The aim of this work is to create overview of chosen method of automated testing. This overview will be created on basis of the description of four chosen tools which allow testing to automate. Each tool uses different methods for automate the testing. At each tool, there will be described its major specialization in the area of automated testing, what kind of installation is used, how the needed test is creating, how the graphical user interface looks like, in which way they report results of testing and whether the tool is open source or not. According to this information the tools will be evaluated.


Obsah 1

2

3

Úvod ............................................................................................... - 1 1.1

Výběr tématu ....................................................................................- 1 -

1.2

Cíl a přínos .......................................................................................- 1 -

1.3

Omezení práce.................................................................................- 1 -

Testování software ....................................................................... - 1 2.1

Procesní vývoj ..................................................................................- 1 -

2.2

Fáze projektu....................................................................................- 2 -

2.3

Zdroje testování................................................................................- 2 -

2.4

Řízení testování ...............................................................................- 3 -

2.5

Testovací proces ..............................................................................- 3 -

2.6

Testovací role ...................................................................................- 4 -

2.7

Základní vstupy a výstupy v rámci testování....................................- 5 -

2.8

Druhy chyb .......................................................................................- 6 -

2.9

Druhy testování ................................................................................- 7 -

2.9.1

Druhy testování podle zaměření ....................................................... - 7 -

2.9.2

Druhy testování podle způsobu provedení........................................ - 8 -

Automatizované testování ........................................................... - 9 3.1

4

Doporučený postup pro automatizované testování..........................- 9 -

3.1.1

Zdokonalení testovacího procesu ..................................................... - 9 -

3.1.2

Definování požadavků .................................................................... - 10 -

3.1.3

Výběr vhodného nástroje ................................................................ - 10 -

3.1.4

Udržitelnost testů ............................................................................ - 10 -

3.1.5

Snadnost analýzy výsledků............................................................. - 11 -

3.1.6

Popis testů ...................................................................................... - 11 -

3.1.7

Opakovatelnost ............................................................................... - 11 -

3.1.8

Datově řízené testy (Data-Driven Tests)......................................... - 11 -

Mercury QuickTest Professional 9.0 ........................................ - 11 4.1

Instalace .........................................................................................- 12 -

4.2

Prostředí QuickTestu......................................................................- 12 -

4.3

Testování s QuickTestem...............................................................- 14 -

4.4

Testovací proces ............................................................................- 14 -

4.4.1

Vytvoření testu ................................................................................ - 14 -


6

7

Proces vytvoření testu ............................................................. - 15 -

4.4.1.2

Práce s testovacími objekty ..................................................... - 15 -

4.4.1.3

Práce s Keyword View ............................................................. - 16 -

4.4.1.4

Checkpoint (Kontrolní bod) ...................................................... - 16 -

4.4.1.5

Hodnoty vyjádřené v parametrech ........................................... - 18 -

4.4.2

Spouštění testů ............................................................................... - 19 -

4.4.3

Analýza výsledků ............................................................................ - 19 -

4.5

5

4.4.1.1

Zhodnocení nástroje QuickTest .....................................................- 20 -

Mercury WinRunner 8.0 ............................................................. - 20 5.1

Instalace .........................................................................................- 21 -

5.2

Prostředí WinRunneru....................................................................- 21 -

5.3


5.3.1

Rozpoznání všech objektů v aplikaci .............................................. - 22 -

5.3.2

Vytvoření vhodného testovacího skriptu ......................................... - 22 -

5.3.3

Ladění testů .................................................................................... - 22 -

5.3.4

Spuštění testů ................................................................................. - 22 -

5.3.5

Analýza výsledků testu ................................................................... - 22 -

5.3.6

Oznámení chyb............................................................................... - 23 -

5.4

Možnosti jako QuickTest ................................................................- 23 -

5.5

Zhodnocení nástroje WinRunner....................................................- 23 -

Canoo WebTest........................................................................... - 23 6.1

Instalace .........................................................................................- 24 -

6.2

Přostředí Canoo WebTestu............................................................- 24 -

6.3


6.3.1

Sestavení kroků testu ..................................................................... - 24 -

6.3.2

Převedení kroků do formy XML....................................................... - 24 -

6.3.3

Použití ANT..................................................................................... - 25 -

6.3.4

Spuštění testů ................................................................................. - 26 -

6.3.5

Zobrazení výsledků......................................................................... - 26 -

6.4

Další možnosti................................................................................- 26 -

6.5

Rozšíření prostředí.........................................................................- 26 -

6.6

Kontroly ..........................................................................................- 27 -

6.7

Zhodnocení nástroje Canoo WebTest............................................- 28 -

SoapUI.......................................................................................... - 28 -


8

7.1

Instalace .........................................................................................- 28 -

7.2

Prostředí.........................................................................................- 28 -

7.3

Webová služba (Web Service) .......................................................- 30 -

7.4


7.4.1

Vytvoření nového projektu .............................................................. - 30 -

7.4.2

Načtení WSDL ................................................................................ - 31 -

7.4.3

Vložení požadavku do testovacího případu .................................... - 31 -

7.4.4

Upravení dat v požadavku .............................................................. - 31 -

7.4.5

Nastavení kontrol ............................................................................ - 31 -

7.4.6

Spuštění testu ................................................................................. - 31 -

7.4.7

Zobrazení výsledků......................................................................... - 32 -

7.5

Zátěžový test (Load test)................................................................- 32 -

7.6

Zhodnocení nástroje soapUI ..........................................................- 32 -

Závěr ............................................................................................ - 32 8.1

Shrnutí hlavních myšlenek .............................................................- 32 -

8.2

Zhodnocení popsaných nástrojů ....................................................- 33 -


1 Úvod 1.1 Výběr tématu O testování software se zajímám více než dva roky, a proto jsem se snažil zvolit téma bakalářské práce z této oblasti. Rozhodl jsem se nakonec vytvořit práci o automatizovaném testování, protože jsem měl v poslední době možnost vyzkoušet některé nástroje pro tvorbu automatizovaných testů.

1.2 Cíl a přínos Cílem mé práce je vytvořit přehled o vybraných způsobech automatizovaného testování na základě popisu nástrojů, které umožňují testování zautomatizovat. Každý nástroj používá k automatizaci testování různé postupy, jež budou popsány. Přínosem práce je přehled, který na jednotlivých nástrojích ukazuje různé způsoby automatizování testů. Nástroje jsou zhodnoceny podle snadnosti instalace, vzhledu uživatelského rozhraní, snadnosti tvorby testů, finanční dostupnosti a způsobu reportování výsledků.

1.3 Omezení práce V práci nebudou zmíněny nástroje, které vytvářejí automatizované testy pro zátěžové a bezpečnostní testování.

2 Testování software Testování software je proces používaný k ověření správnosti, úplnosti, bezpečnosti a kvality vyvíjeného počítačového software. Testování je nedílnou součástí procesního vývoje, který se dá rozdělit do několika částí.

2.1 Procesní vývoj Procesní vývoj nám nejlépe popisuje model RUP (Rational Unified Process), který je založen na iterativním přístupu, jenž spočívá v rozdělení celého projektu na čtyři fáze, z nichž každá se skládá z několika iterací. Výsledkem každé této iterace je spustitelná verze. [e-RUP]

-1-


Obrázek 1 – Iterativní vývoj [e-RUP]

2.2 Fáze projektu Životní cyklus projektu je v metodice RUP rozdělen do fází: Zahájení, Příprava, Konstrukce a Předávání. Po dokončení každé fáze se provede zhodnocení, zda byly splněny požadované cíle. Další fázi projektu je možné zahájit pouze v případě splnění všech požadovaných kritérií. V každé fázi figuruje testování a na základě jeho výsledků se rozhoduje, zda se zahájí další fáze. Fáze Zahájení: V této fázi je potřeba vymezit rozsah vytvářeného systému a pro hlavní činnosti vytvořit modely případů užití, což je také hlavním cílem. Zde se určí, zda je vůbec možné určitou funkčnost otestovat. Fáze Příprava: V případě fáze Přípravy se musí navrhnout stabilní model architektury systému, jenž bude základem pro jeho implementaci. Model se sestaví ze základních požadavků na systém a tyto požadavky budou otestovány. Fáze Konstrukce: Tato fáze je převážně zaměřena na implementaci a dochází tedy k otestování první funkční verze systému. Fáze Předávání: Cílem této fáze je předání konečné verze uživatelům, kteří budou systém používat. Dochází pouze k drobným úpravám na základě připomínek již zmiňovaných uživatelů a opětovnému testování.

2.3 Zdroje testování K tomu, abychom mohli vůbec testovat, je zapotřebí mít připravené testovací prostředí a kvalitní testery.

-2-

Automatizované testování Vhodné prostředí pro testování Je zapotřebí zajistit dostatečné programové vybavení a hardware, aby testeři mohli pracovat efektivně. Musí se také udržovat daný software a aktualizovaný hardware. Testeři K testování je zapotřebí tvrdě pracující tým lidí s potřebnými znalostmi a schopnostmi. Může být daleko těžší najít kvalitního testera než kvalitního vývojáře.

2.4 Řízení testování Pro zajištění správného otestování software je také důležité dobré řízení testování. Pro řízení testování je potřeba pět základních věcí. [BLA02] Důkladný testový plán Detailní testový plán umožňuje předvídat a zabraňovat krizím. Plán popisuje, co se bude testovat, kdo bude testovat, kdy bude testovat a v jakém rozsahu se testování provede. Dobře zorganizovaný systém Dobrý systém testování dokáže nalézt mouchy, které mohou poškodit produkt na trhu nebo zredukovat jeho přijmutí domácími uživateli. Musí být celkově konzistentní a co nejvíce přehledný, aby nebylo obtížné se ho naučit a používat. Databáze sledování stavu chyby V průběhu testování se objeví spousta chyb a není možné si je všechny uchovat v hlavě. Databáze může tedy shrnovat chyby v přehledných grafech, které řeknou manažerům, z jaké části je testování hotové, o stabilitě vyvíjeného produktu a komplikacích subsystémů. Snadná změna databáze pro řízení testování V každé metodice se za chodu hledají místa, která se dají vylepšit a je tedy zapotřebí vše předem nastavit tak, aby bylo možné ji stále vylepšovat snadným způsobem.

2.5 Testovací proces Samotné testování musí mít určitou strukturu, aby bylo co nejefektivnější a nejdůkladnější. Nejlépe se toho docílí pomocí níže uvedeného testovacího procesu. [BLA02] Organizace testování v rámci fáze zahájení projektu Zahrnuje vytvoření již zmiňovaného plánu testů, časového rozvrhu a zajištění požadovaných zdrojů.

-3-

Automatizované testování Návrh nebo tvorba testů Zahrnuje identifikování testovacích cyklů, testovacích případů, vstupní a výstupní kritéria a očekávané výsledky. Očekávané výsledky nebo testovací podmínky jsou definovány testovacím týmem spolu s projektovým business analytikem. Potom testovací tým určí testovací případy a potřebná data. Testovací podmínky jsou odvozeny z business designu a z dokumentů požadavků. Návrh nebo tvorba testovacích procedur Zahrnuje nastavení procedur jako systém řízení chyb a reportování stavů a nastavení datových tabulek pro automatizované testování. Vytvoření testovacího prostředí Zahrnuje zajištění potřebného hardware, software a datových vstupů. Při přípravě testovacího prostředí se podle vytvořených testů zajistí všechna potřebná data. Je nezbytné si zajistit všechny přístupy do testovaných aplikací. Pokud se testy týkají funkčnosti závislé na určitém hardware, tak je dopředu zapotřebí si jej rovněž zajistit, aby testy proběhly bez zbytečného časového zdržení. Spuštění testů Spouští se vytvořené testy dle kol určených plánem testů. Po ukončení testů jednoho kola se čeká na opravení nalezených chyb a následně se spouští testy v dalším kole. Spuštění operací akceptačního testu Ověření, zda software splňuje to, co požadoval zadavatel. Ukončení Ukončení nastává tehdy, pokud bylo dosaženo předem definovaných ukončení jednotlivých fází.

2.6 Testovací role Pro jednoznačné určení činnosti, kterou má tester vykonávat, se v daném týmu vymezují pro každého role a jeho zodpovědnost za danou oblast. V testovacím týmu by neměly chybět dále uvedené role. [e-RUP] Tester Jeho hlavní úlohou je provádět testy dle vytvořeného testovacího skriptu a reportovat jejich stav. V případě chybového stavu testu by měl chybu reportovat na Test koordinátora a po jejím opravení provést retest.

-4-

Automatizované testování Test designér Osoba v pozici této role má na starosti vytváření samotného testovacího skriptu. Měla by mít přístup k funkční specifikaci a nejlépe k nějakému nástroji, který zajistí sdílení nově vytvořeného testovacího skriptu. Dále určuje, jaká budou zapotřebí testovací data, se kterým se bude následně pracovat. Test analytik Náplní jeho práce je tvorba testovacího plánu, vytvoření určité testovací strategie, odhad případných rizik, která mohou ovlivnit kvalitu testování a vytvoření testovacích scénářů případně i skriptů. Test koordinátor Hlavní role koordinátora testů spočívá v tom, že určuje, kdo bude s vytvořeným testem či objevenou chybou pracovat dál. Nejlepší je mít v týmu pouze jednoho koordinátora, který tak rovnoměrně rozděluje potřebnou činnost mezi ostatní v týmu. Stejně tak je to vhodné na straně vývojového týmu. Pokud se tedy objeví chyba, je nejvhodnější ji reportovat na koordinátora vývoje a ten ji už přepošle dále. Mezi jeho další důležité činností patří kompletace podkladů k přípravě testů, kompletace požadavků na testování, zavedení kategorií i priorit chyb. Dále má na starosti plánování všech druhů testů, které jsou popsány výše.

2.7 Základní vstupy a výstupy v rámci testování Testování se neobejde bez vstupů, jako jsou například testovací data, a bez výstupů, které popisují vybraným způsobem průběh testování. Testovací plán Definuje hlavní přístupy, jejichž pomocí se provede testování a následné vyhodnocení výsledků. Dále vymezuje vstupní a výstupní kritéria, testovací prostředí, role a to vše v časové návaznosti. Na jeho tvorbě se podílí Test koordinátor a Test analytik. Testovací scénář Scénář je sled akcí či podmínek, které identifikují testovanou komponentu, prostředí, testovací dokumentaci a aktuální výstup. Obsahuje sled konkrétních testovacích skriptů, které dokáží realizovat celý testovací případ. Vytváří jej Test analytik a Test designér.

-5-

Automatizované testování Testovací skript Precizně popisuje postup, jakým tester nebo nástroj pro automatizované testování prochází danou část aplikace nebo systému a jak provádí jeden nebo více testovacích případů. Je vytvářen buď Test analytikem, nebo Test designérem. Testovací data Jedná se o vstupy, které jsou použity v testovacím skriptu. Jsou to všechna data, s nimiž se ověří požadovaná funkčnost aplikace nebo systému. Testovací data připravuje Test designér. Testovací prostředí Testovací prostředí je prostředí, které se připravuje pro provedení testů. Je důležité dbát na použití hardware a software, se kterými testovaná aplikace nebo systém souvisí. Do testovacího prostředí je také zapotřebí nahrát potřebná testovací data, na kterých se testy budou provádět a tedy zajistit si příslušná práva. Testovací nástroje Všechny nástroje, které určitým způsobem pomáhají při testování. Mohou to být nástroje pro řízení testování, pro spouštění skriptů manuálního či automatizovaného testování nebo nástroje pro testování bezpečnosti či zátěže aplikace nebo systému. Testovací případ Smyslem testovacího případu je určit podmínky, které mají ověřit požadovanou funkcionalitu systému. De facto je to množina vstupů a očekávaných výstupů vytvořená pro jednotlivé funkcionality tak, aby se podařilo projít danou testovanou cestou nebo se potvrdilo splnění požadavků. Testovací případ ověřuje jedno nebo více kritérií, aby zajistil, že aplikace je po stránce funkčnosti a struktury připravena na implementaci do produkčního prostředí.

2.8 Druhy chyb Pokud se v průběhu testování objeví chyby, je nutné je co nejdříve reportovat a samozřejmě opravit. Každá chyba by měla mít v metodice testování nastavenu svou prioritu podle její závažnosti. Nízká závažnost Všeobecně se jedná o chybu, která neovlivňuje funkčnost aplikace nebo systému a její opravení není nezbytné. V praxi se za chybu považuje například chybějící písmeno ve slově nebo odlišná poloha tlačítka.

-6-

Automatizované testování Střední závažnost Zde už se jedná o závažnější chybu, než bylo definováno v chybě předchozí. Touto závažností se označuje chyba, která porušuje určitou funkčnost v obchodním procesu. Příkladem je chybějící tlačítko s odkazem na stránku s tiskem právě sjednané smlouvy, ale tisk se dá vyvolat jiným způsobem, a tedy lze obchodní proces dokončit. Vysoká závažnost Takto bývá označována chyba, která zásadním způsobem porušuje požadovanou funkčnost a nedá se jiným způsobem obejít či nahradit. V případě této chyby nelze dokončit testovací skript a čeká se tedy na opravení chyby. Je tedy nutné tuto chybu odstranit, co nejdříve.

2.9 Druhy testování Testovací proces je možné aplikovat na různé druhy testování software. Druhy testování lze rozdělit podle toho, jakým způsobem jsou jednotlivé testy prováděny, nebo podle toho, na co se testy zaměřují.

2.9.1 Druhy testování podle zaměření Technické testování Toto testování má na starosti tým vývojářů. Jedná se o tzv. Unit testy, kdy se testují jednotlivé části kódu, které vytváří určitou funkčnost. Snahou je izolovat každou část programu a ukázat, že jednotlivé části fungují správně. Funkční testování Cílem tohoto testování je zajistit, aby každá část aplikace odpovídala funkcemi business požadavkům. Zahrnuje validační testování, což je důrazné testování nových Front end polí a obrazovek. Je důležité dbát na GUI standardy MS Windows; validní, nevalidní a limitní vstupní data; vzhled jednotlivých polí a obrazovek a celkovou konzistenci dané aplikace. Dále zahrnuje specifické funkční testování, které je označováno jako nízko-úrovňové testování, jenž se týká testování jednotlivých procesů a datových toků. Integrační testování Tento test ověřuje, zda všechny části rozhraní systému vzájemně správně fungují a že v datových tocích nejsou žádné trhliny. Závěrečný integrační test (po opravení všech chyb) ověřuje, zda systém pracuje jako jeden celek.

-7-

Automatizované testování Systémové testování Testování prováděné na kompletním a již integrovaném systému k vyhodnocení systémového souladu s jeho specifikovanými požadavky se nazývá Systémové testování. Systémové testování patří do oblasti Black box testování (tester nevidí vyvinutý kód) a jako takové nepožaduje žádné znalosti navrženého kódu. Zátěžové testování Testování zajišťuje, aby odezva systému byla přijatelná. Přijatelná odezva by měla trvat maximálně 4 sekundy. Multi uživatelské testování Testování usiluje o prokázání, že je možné pro přípustné množství uživatelů pracovat se systémem ve stejném čase. Během testování se usiluje o shození systému. Souvisí tedy se zátěžovým testováním. Regresní testy Regresní test se vykonává po ukončení všech kol testování. Cílem je zjistit, zda nové požadované změny nezasáhly do jiných oblastí systému a fungují tedy správně. Systém se jeví jako stabilní celek. Tyto testy je možné automatizovat, protože se po každém vydání programu (releas) opakují. Operační akceptační testy Je to testování, které vykonává tým lidí z podpory pro systémové instalace a IT po implementaci systému. Business Akceptační testy Business akceptační testy jsou plánovány a spouštěny zadavateli požadavků. Jejich hlavní úlohou je zjistit, že systém funguje tak, jak bylo požadováno a jakékoliv podpůrné materiály jako procedury a formuláře mají přesný a vhodný účel, který byl zamýšlen. Test je označován jako vysoko-úrovňové testování, které zajišťuje to, že systém nemám ve funkcionalitě žádné trhliny.

2.9.2 Druhy testování podle způsobu provedení Manuální testování Manuální testování je nejvíce rozšířeným testováním kvůli své snadnosti a variabilitě. Jedná se o způsob testování, kdy se podle vytvořeného testu postupuje krok za krokem a manuálně se vyplňují pole nebo se kliká na tlačítka případně odkazy.

-8-

Automatizované testování Automatizované testování Tento způsob testování se používá nejvíce v případě potřeby otestování velkého množství dat a také v případě testování rozsáhlejších aplikací. Automatizované testování je testování, které je vytvořené nástrojem, který dokáže sám krok za krokem procházet aplikaci podle vytvořeného testu. Tester v tomto případě pouze vytvořený test spustí a po ukončení testu vyhodnotí výsledky.

3 Automatizované testování Automatizované testování je použití nějaké aplikace, která dokáže spouštět vytvořené testy, porovnávat aktuální výstupy s očekávanými výstupy, nastavovat testovací podmínky a dokáže výsledky testu reportovat. Automatizované testování se dá všeobecně popsat jako automatizování manuálního procesu v případě, kdy se používá formalizovaný testovací proces. Automatizované testování je finančně náročné a je to tedy spíše doplněk než náhrada k manuálnímu testování. Finančně výhodné se stává až v případě dlouhodobého užívání jako například při pravidelných regresních testech.

3.1 Doporučený postup pro automatizované testování 3.1.1 Zdokonalení testovacího procesu Pokud se společnost rozhodne automatizovat testování, tak je zapotřebí zdokonalit testovací dokumentaci. Důležité je stanovit, která data budou v testech použita. Dokumentace jsou většinou psané pro uživatele, u kterých se předpokládá již základní zkušenosti s testovanou aplikací, a proto jsou dokumenty nepřesné. Pro automatizované testování se musí přesně stanovit očekávané výsledky, protože testeři neznají důkladně danou aplikaci a většinou nemají čas shánět přesné informace. Z těchto důvodů je zapotřebí dbát na úplnou a kvalitně vypracovanou dokumentaci. Další možností, která povede k zlepšení testovacího procesu, je použití více počítačů, na kterých se budou spouštět a provádět testy. Zatímco na jednom počítači může být spuštěn automatizovaný test, tak na druhém se může jiný test vytvářet. Zajisté také záleží na způsobu vyvinutí aplikace, jenž by měl být co nejjednodušší, pak i testování je snazší. Dále záleží na způsobu instalace, na době odezvy a na logu aplikace. Instalace by měla být co nejjednodušší, doba odezvy samozřejmě co nejkratší, aby neprodlužovala dobu spuštěných automatizovaných testů. Logy by měly být podrobné a také co nejvíce přehledné. -9-


3.1.2 Definování požadavků Pro použití automatizovaného testování je nezbytné si promyslet a stanovit cíle, kterých se zautomatizováním testů dosáhne. Mezi tyto cíle může patřit: •

Urychlení testů pro zrychlení vydání aplikace

•

Umožnit testování s vyšší frekvencí

•

Redukovat náklady testování snížením manuální práce

•

Zlepšit pokrytí testu

•

Zajistit konzistenci

•

Zvýšit spolehlivost testování

•

Udělat testování více zajímavým

•

Rozvinout programovací schopnosti

Existují zajisté i další cíle, kvůli kterým se firma rozhodne pro automatizované testování, ale tyto patří mezi základní.

3.1.3 Výběr vhodného nástroje Nástroje pro automatizované testování mohou mít tři různá rozhraní. Prvním je rozhraní příkazové řádky (Comand Line Interface), druhým je rozhraní pro programování aplikace (Application Programming Interface) a posledním je grafické uživatelské rozhraní (Graphical User Interface). Nástroje s grafickým uživatelským rozhraním využívají vlastnost zvanou „nahraj a přehraj“. Nástroj tedy na pozadí zaznamenává kroky, které jsou prováděny na testované aplikaci, a vygeneruje testovací skript, jenž je možné spustit. Testované aplikace jsou vyvinuty různými programovacími jazyky, se kterými musí umět nástroj pracovat. Z tohoto důvodu jsou nástroje s grafickým uživatelským rozhraním velmi drahé. Nástroje ostatních rozhraní lze používat většinou zdarma, ale zase je pomocí nich složitější vytvoření automatizovaných testů. U testera se už očekávají znalosti některého programovacího jazyka, ve kterém se test bude sestavovat.

3.1.4 Udržitelnost testů Při tvorbě automatizovaných testů by se mělo dbát na jejich využitelnost v delším časovém období. Je zapotřebí promyslet a sestavit testy tak, aby se mohly co nejjednodušeji upravit v případě nějaké změny testované aplikace, pro niž jsou testy vytvářeny. Testy by měly být navrženy tak, aby se po jejich ukončení mohlo říci, že aplikace je kompletně otestována, a pokud nebyly nalezeny chyby, že je aplikace funkční. Jde vlastně o jakousi

- 10 -

Automatizované testování důvěru ve vytvořené testy, proto musí být navrženy co nejlepším způsobem. Automatizované testy, které nedokáží odhalit chyby, mohou způsobit neúspěch celého projektu.

3.1.5 Snadnost analýzy výsledků Postrachem často bývá otázka, co dělat, když automatizovaný test selže. Test totiž mohl selhat z důvodu chybného testovacího případu nebo kvůli chybě, která se v testované aplikaci nachází. Je tedy důležité proškolit testery, aby tyto případy dokázali co nejrychleji rozlišit. Dalším způsobem může být zdokonalení reportování chyb, jež opět analýzu výsledků lépe specifikuje.

3.1.6 Popis testů Protože se automatizované testy píší pro použití v průběhu delšího časového horizontu, tak je zapotřebí vytvářet popis testů. To je vhodné jak v případě použití testu po několika testech, tak i v případě výměny testera.

3.1.7 Opakovatelnost Testy se tvoří tak, aby je bylo možné použít pro různá data a tím se rozšířila i použitelnost testu. V automatizovaných testech se často používá funkce generování náhodného čísla, jež dosazuje vždy jinou hodnotu v průběhu testu. Pokud je zapotřebí zadávat aktuální čas, tak se používá funkce, která jej podle systémového času doplní a není tedy nutné každý den testy upravovat.

3.1.8 Datově řízené testy (Data-Driven Tests) Datově řízené testy jsou testy, které si v průběhu testu načítají hodnoty z určeného místa. Většinou se jedná o tabulky, které obsahují potřebná data pro daný test. Nástroj si vždy hodnotu načte a předá testované aplikaci. To je obrovská výhoda zautomatizovaných testů, protože tak otestujeme jedním testem všechny potřebné hodnoty a časová úspora je tedy zřejmá.

4 Mercury QuickTest Professional 9.0 Mercury QuickTest Professional je nástroj, který se používá pro automatizaci funkčních a regresních testů. Automatizované testování tohoto nástroje je postaveno na tzv. Keyworddriven (řízení podle klíčových slov) testování, aby se rozšířily testovací možnosti a bylo možné testy lépe udržovat. Keyword-driven testování je technika, která odděluje většinu programátorské práce od běžných testovacích kroků tak, že testovací kroky mohou být vyvíjeny dříve a často mohou být udržovány jen s minimální úpravou, dokonce i tehdy, když aplikace nebo testování potřebuje výrazně změnit. [MQT06]

- 11 -

Automatizované testování S využitím přístupu Keyword-driven testování mají experti přes automatizované testování přístup k základnímu testu a objektovým vlastnostem prostřednictvím integrovaných skriptů a ladícího prostředí, které je synchronizováno s Keyword View. QuickTest Professional nám umožňuje testovat standardní aplikace ve Windows, objekty webového rozhraní, prvky ActiveX a aplikace vytvořené v programovacím jazyku Visual Basic. Dále vyhovuje standardu Unicode, což umožňuje testování aplikací v mnoha jazycích. Unicode reprezentuje požadované znaky, které využívají 8bitové nebo 16bitové kódování, aby bylo možno zpracovat a zobrazit mnoho různých jazyků a znakových sad. QuickTest se nejlépe hodí na testování tenkých klientů aplikace nebo systému. Klient je program, který přistupuje ke službě (server), která obvykle běží vzdáleně, a která poskytuje určitou službu. Příkladem může být webový prohlížeč, který je klient. Při zadání adresy webové stránky do adresného řádku a jejím potvrzení prohlížeč vyžádá z webového serveru požadovanou stránku a zobrazí ji. Klient je tedy v síťové architektuře klient-server brán jako konzument služeb, které poskytuje server. Tenký klient jako aplikace komunikuje a provádí většinu významných procesů business logiky s aplikací, která je spuštěna na jiném počítači v síti (serveru).

4.1 Instalace Ze stránek společnosti Mercury (http://www.mercury.com) lze stáhnout 14 denní trial verzi programu Mercury QuickTest Professional. Instalace programu je velmi snadná, a pokud zvolíme doporučené možnosti, tak program vše potřebné (vzdálené spouštění z Quality Center, povolení portu 139 v používaném firewallu a nastavení Internet Exploreru) nastaví zcela sám. Dále můžeme v průběhu instalace stáhnout Microsoft Skript Debugger pro pozdější úpravu kódu, který nám QuickTest při vytváření skriptů sám vygeneruje. Po úspěšné instalaci je zapotřebí restartovat systém jinak není možné aplikaci spustit.

4.2 Prostředí QuickTestu Při spuštění QuickTestu se zobrazí obrazovka Add-in Manager (správce doplňků), kde lze zvolit, jaké doplňky budou použity při spouštění nebo nahrávání testů. Defaultně je vybrán doplněk pro testování webových aplikací, pro něž je QuickTest primárně určen. Samotné prostředí QuickTestu je tvořeno třemi okny. Prvním je okno Testu, jenž lze prohlížet ve dvou záložkách a to Keyword View a Expert View.

- 12 -


Obrázek 2 – QuickTest – Expert View

Obrázek 3 – QuickTest – Keyword View

- 13 -

Automatizované testování Dalším oknem je okno Data Table (datová tabulka), kde jsou vidět potřebná data, se kterými bude daný test spuštěn, a to buď v lokálním, nebo globálním módu, jak ukazují příslušné záložky tohoto okna. Posledním oknem je okno Active Screen. Zde se zobrazují objekty, respektive celé obrazovky grafického uživatelského rozhraní s objekty jednotlivých kroků testu. Pokud je dostupná daná testovaná obrazovka online, tak se zobrazí kompletně celá i s pozadím. Pokud je nedostupná, tak se zobrazí pouze objekty, které má uložené QuickTest v repository. V tomto okně je také zvýrazněn objekt, jenž v daném kroku testu ověřujeme a vidíme i jeho hodnotu, kterou požadujeme v testu.

4.3 Testování s QuickTestem QuickTest Professional rozpoznává a učí se objekty v aplikaci tak, že můžeme navrhovat automatizované testy, které provádí stejné typy operací a business procesů, které dělá uživatel. Následně můžeme tyto testy spouštět kvůli kontrole, jestli daná aplikace funguje podle její požadované funkčnosti. QuickTest nám umožňuje dva pohledy na kroky, které si vytvořil podle toho, jak jsme procházeli danou aplikací nebo systémem. Můžeme tedy vkládat nebo případně mazat kroky dvojím způsobem a to buď v tabulkově orientovaném a uživatelsky příjemnějším pohledu Keyword View, nebo v Expert View, které je spíš určené pro uživatele zběhlé v programování, protože zde si QuickTest zapisuje kroky pomocí jazyka VBScript. Každý krok v našem testu zahrnuje automaticky generovanou dokumentaci, která poskytuje podrobný popis, co daný krok dělá.

4.4 Testovací proces Testování v QuickTestu zahrnuje tři hlavní fáze a to: Vytvoření testu, Spuštění testu a Vyhodnocení výsledků.

4.4.1 Vytvoření testu Test vytváříme buď vytvořením repository (skladu) objektů a přidáním kroků ručně nebo nahráním potřebné oblasti v aplikaci, kterou testujeme. Jednotlivé kroky můžeme vytvořit využitím tabulky, grafickým pohledem Keyword View používajícím funkci Keyword-driven nebo v Expert View, pokud chceme programovat kroky přímo v Visual Basic skriptu. Každý test se skládá z jedné nebo více akcí. Každá akce obsahuje kroky, které kopírují postup práce uživatele s aplikací ve Windows nebo s webovou stránkou. Větší účelnosti

- 14 -

Automatizované testování testovacího procesu můžeme dosáhnout úpravou testu pomocí speciálních testovacích vlastností a s využitím programovacích příkazů. Obvykle každý test začíná jednou akcí a my tyto akce můžeme rozdělit do několika akcí, které nám popisují samotnou logiku požadované funkce aplikace. Je to podobné jako vytváření oddělených modulů nebo logických jednotek pro testování různých oblastí aplikace nebo webové stránky. 4.4.1.1 Proces vytvoření testu Přidání kroků do testu Nejdříve je nutné vytvořit repository objektů a použít tyto objekty k ručnímu přidání Keyword-driven kroků v pohledu Keyword View nebo Expert View. Repository objektů by měl obsahovat všechny objekty, které chceme testovat v dané aplikaci nebo webové stránce. Potom stačí nahrát údaje, které zadáváme na naší aplikaci nebo webové stránce. Když se pohybujeme v nějaké aplikaci nebo webové stránce, tak QuickTest ukazuje každý krok, který vykonáme jako řádek v Keyword View. Za krok považujeme vše, co se vytváří nebo mění v aplikaci nebo na stránce, jako například klik na odkaz nebo obrázek, vyplnění formuláře apod. V Expert View jsou tyto kroky zobrazeny jako řádky v testovacím skriptu, který je napsán ve Visual Basic. Vložení checkpointů (kontrolní body) do testu Checkpoint ověřuje určité hodnoty nebo charakteristiky stránky, objektu nebo textového řetězce, a umožňuje nám ověřit, zda aplikace nebo webová stránka funguje správně. Nahrazení fixních hodnot parametry neboli parametrizace testu Když testujeme aplikaci nebo webové stránky, můžeme test parametrizovat ke zjištění, jak se aplikace chová s odlišnými daty. Můžeme vložit data do datové tabulky, definovat proměnné a hodnoty, definovat testovací parametry a hodnoty, nebo nechat QuickTest, aby generoval náhodná čísla pro daného uživatele a testovací data. 4.4.1.2 Práce s testovacími objekty Když QuickTest spouští test, tak simuluje uživatele tím, že pohybuje kurzorem myši po aplikaci, kliká na různé objekty a zadává vstupy z klávesnice. QuickTest se musí naučit stejně jako uživatel rozhraní aplikace, aby byl schopen s ní pracovat. Dělá to tak, že se naučí objekty dané aplikace a jejich odpovídající hodnoty a uloží tyto popisy objektů do repository objektů. Ačkoliv se QuickTest učí testovací objekty, ukládá je v lokální repository. Můžeme si vybrat, zda ponecháme uložené objekty v lokální repository, nebo zda je uložíme do sdílené repository. Uložením objektů do lokální repository nám umožní jejich dostupnost pouze pro

- 15 -

Automatizované testování danou akci a ne pro jiné akce. Uložením do jedné nebo více sdílených repository objektů nám umožní jejich vícenásobné použití i v jiných akcích. Pokud potřebujeme, tak můžeme pracovat s kombinací lokální a sdílené repository. Jestliže se odlišuje jedna nebo více hodnot vlastnosti objektu v aplikaci od hodnot vlastnosti QuickTestu, které používá k identifikaci objektů, tak test skončí chybně. Nicméně když se hodnoty vlastností objektů v aplikaci změní, můžeme upravit danou hodnotu vlastnosti objektu v objektové základně tak, že můžeme dále používat existující testy. Sdílená repository objektů ukládá testovací objekty do souboru, který je přístupný pro více testů v modu pouze pro čtení. Lokální repository ukládá objekty v souboru, který je přiřazen pouze k jedné dané akci tak, že pouze tato akce může přistupovat k uloženým objektům. Jednotlivé kroky můžeme vytvořit vybráním položek a operací v Keyword View, kam vložíme požadované informace. 4.4.1.3 Práce s Keyword View Keyword View umožňuje vytvářet a prohlížet kroky vytvořeného testu v modulech a v tabulkách. Každý krok je řádek skládající se z jednotlivých částí, které můžeme jednoduše upravovat. Každý krok je automaticky dokumentován po dokončení testu, a díky tomu můžeme vidět popis testu ve srozumitelných větách. Tyto popisy lze tedy použít jako instrukce i pro manuální testování, pokud je ho zapotřebí. Keyword View lze použít pro přidání dalších kroků do testu a rovněž k modifikování již existujících kroků. Vybereme testovací objekt, který chceme použít pro náš krok, vybereme metodu operace, kterou chceme vytvářet a definujeme všechny nezbytné hodnoty pro vybrané operace a objekty. K tomu není zapotřebí žádné znalosti z oblasti programování, protože veškeré programovací techniky za nás v pozadí automaticky vytváří QuickTest. 4.4.1.4 Checkpoint (Kontrolní bod) Checkpoint je ověřovací bod, který porovnává hodnotu pro určitou vlastnost objektu s hodnotou, kterou pro tuto vlastnost očekává. To nám umožňuje kontrolu správné funkčnosti testované aplikace. Když přidáme do skriptu checkpoint, tak QuickTest ho přidá do řádku v Keyword View a také přidá příkaz Check CheckPoint do Expert View. Checkpoint automaticky dostává název podle názvu testovacího objektu, na kterém byl vytvořen. V tomto případě je možné název změnit nebo ho ponechat. - 16 -

Automatizované testování Do testu můžeme checkpoint přidat v průběhu nahrávání nebo během editace našeho testu. Vhodnější způsob je definování checkpointu až po nahrání testu. Po spuštění testu se v průběhu provede kontrola a její výsledek je možné vidět v okně s testovými výsledky. Standardní checkpoint Kontroluje různé objekty jako button (tlačítko), radio button (přepínač), combo box (rozbalovací seznam), check box (zaškrtávací tlačítko), edit box (editační pole) apod. Například můžeme zkontrolovat, zda je radio button aktivovaný po vybrání nebo můžeme zkontrolovat hodnotu edit boxu. Pokud tedy v daném kroku chceme vložit checkpoint například na vstupní data v editačním poli, tak se zobrazí okno Vlastnosti checkpointu. V okně je vidět název objektu, jeho třída, typ, vlastnost a hodnota. Vybereme-li hodnotu, tak ji můžeme snadno parametrizovat. Nastavíme vlastnosti parametru tak, aby se hodnoty načítaly z Data table a ověříme tak různé možnosti vstupních dat. Dále je možné nastavit v sekundách dobu, kterou bude QuickTest čekat, než daný checkpoint začne ověřovat.

Obrázek 4 – QuickTest – Vlastnosti kontrolního bodu

Obrázkový checkpoint Kontroluje hodnotu obrázku v aplikaci nebo webové stránce. Například můžeme zkontrolovat, zda vybraný zdrojový soubor obrázku je správný. Bitmapový checkpoint Kontroluje plochu webové stránky nebo aplikace jako bitmapu. Například při výběru přibližování v mapě zkontroluje, zda se nahraný bitmapový checkpoint shoduje s přiblíženou mapou v aplikaci nebo webové stránce.

- 17 -

Automatizované testování Tabulkový checkpoint Kontroluje informace v tabulce. Například můžeme použít tabulkový checkpoint při ověřování hodnoty v prvním poli tabulky. Textový checkpoint Kontroluje textový řetězec, který je zobrazen na nějakém místě v okně aplikace či webové stránky. Můžeme to využít například při zjišťování, zda je nějaký text mezi jinými texty. Stránkový checkpoint Kontroluje charakteristiku webové stránky. Můžeme pomocí něj zjistit, jak dlouho se daná stránka nahrává, nebo zda obsahuje odkazy na neexistující stránky. Databázový checkpoint Kontroluje obsah databáze, ke které přistupuje naše aplikace. Například pomocí databázového checkpointu porovnáme data z databáze s daty zobrazujícími se v jednotlivých polích aplikace. XML checkpoint Kontroluje datový obsah XML dokumentů v XML souborech nebo XML dokumentech na webové stránce. 4.4.1.5 Hodnoty vyjádřené v parametrech Parametr je proměnná, které je přiřazena hodnota z externího datového zdroje nebo generátoru. V testu můžeme parametrizovat hodnoty v krocích nebo checkpointy. QuickTest používá 4 typy parametrů Parametry testu/akce Parametry testu umožňují použít hodnoty pouze z daného testu na rozdíl od parametrů akce, které nám umožní použít hodnoty z ostatních akcí v našem testu. Parametry datové tabulky QuickTest nám umožňuje pustit daný test tolikrát, kolik je vyplněných řádek v tabulce. Každý test proběhne vždy s danou hodnotou uvedenou v řádku tabulky a bude probíhat do té doby, dokud nebudou všechny hodnoty vyčerpány. Parametry proměnného prostředí Tyto parametry umožňují použít proměnné hodnoty z jiných zdrojů v průběhu běžícího testu. Záleží na nás, jak si tyto hodnoty navolíme a určíme, v jakém kroku se mají čerpat. Parametry náhodného čísla

- 18 -

Automatizované testování Umožňují nám vložit náhodná čísla jako hodnoty do našeho testu.

4.4.2 Spouštění testů Poté, co máme vytvořený test, tak ho můžeme spustit. QuickTest umožňuje několik různých nastavení pro spuštění testu. Lze tedy vybrat typ prohlížeče a adresu, na které se test provede. Výhodou je, že pokud se po nějaké době změní například adresa serveru, na kterém jsme test nahrávali, tak zde stačí pouze adresu přepsat a daný test již bude plně funkční. Dále lze nastavit seznam aplikací, na kterých bude QuickTest testy provádět a ostatní aplikace nebude vidět. QuickTest po spuštění testu projíždí jednotlivé kroky od prvního až po poslední. QuickTest otevírá webovou stránku nebo aplikaci a vykonává každou operaci včetně všech checkpointů jako je kontrola nějakého textové řetězce, objektů, tabulek apod. Testy můžeme spouštět jak kompletní, tak od určitého kroku do určitého kroku. Dále můžeme v průběhu testu QuickTest pozastavit, ručně doplnit hodnoty do aplikace nebo webové stránky, a dále spustit QuickTest, který bude pokračovat a dokončí test za nás. Spouštění testů od určitého kroku se používá hlavně při ladění testu pro určení, zda funguje správně a kontroluje všechny objekty, které požadujeme. QuickTest také umožňuje spouštět tzv. batch (dávkové) testy, které spustí vybrané testy hned po sobě. Dávka testů se dá měnit i v případě, že již běží. Bezpochyby největší výhodou automatizovaných batch testů je jejich spuštění přes noc, protože se tester vrátí druhý den do práce a vidí výsledkové okno několika desítek proběhlých testů a může jejich výsledek vyhodnotit.

4.4.3 Analýza výsledků Když skončí průběh testu, tak se nám objeví okno s výsledky průběhu testu, které obsahuje popis kroků vykonaných během testu. Pro test, který neobsahoval parametry z datové tabulky, se objeví pouze jeden průběh, v ostatních případech se objeví výsledek s průběhem pro každý test zvlášť. V okně s výsledky můžeme najít celkové hodnocení testu, zda byl úspěšný nebo zda někde selhal, dále data, která byla použita v průběhu testu, ve stromové struktuře vidíme, v jakém kroku nastal problém a detailní popis každého kroku testu. Výsledky testu jsou ukládány do souboru results.xml, kde si je lze v textové formě rovněž prohlédnout.

- 19 -


Obrázek 5 – QuickTest - Výsledkové okno

4.5 Zhodnocení nástroje QuickTest QuickTest Professional je uživatelsky příjemný a snadno naučitelný nástroj i pro nezkušené uživatele, jelikož dokáže přesně zaznamenávat jednotlivé kroky bez znalosti programování. Tyto kroky jsou vždy vytvářeny dvěma způsoby a to graficky v hierarchické stromové struktuře a v skriptovacím programovacím jazyku VBScript, kdy je každý krok zaznamenán příkazem v jedné řádce. QuickTest je nástroj určený spíše pro webové rozhraní, kde si poradí s kontrolou všech objektů, tabulek, textů, obrázků, databází, XML a jejich vlastností. Po spuštění testu se zobrazí okno s výsledky, které jsou opět v přehledné grafické stromové struktuře.

5 Mercury WinRunner 8.0 WinRunner je dalším testovacím nástrojem pro automatizované testování od společnosti Mercury. Pomáhá automatizovat testovací proces od vytvoření testu až k jeho spuštění. Můžeme s jeho pomocí vytvářet přizpůsobivé a znovupoužitelné testovací skripty, které prověří potřebnou funkcionalitu testované aplikace. [MWR04] Opět se jedná o nástroj jako QuickTest, který simuluje uživatele, jenž pohybuje kurzorem myši po aplikaci, kliká na objekty grafického uživatelského rozhraní (GUI) a vkládá vstupní hodnoty pomocí klávesnice. Na rozdíl od QuickTestu se WinRunner hodí spíše k vytváření automatizovaných testů pro Windows aplikace. To ovšem neznamená, že nedokáže provést testy ve webovém rozhraní, ale nedokáže je provést kvůli omezeným možnostem tak kvalitně jako QuickTest.

- 20 -


5.1 Instalace Mercury WinRunner si lze nainstalovat v případě zkušební seat licence na dobu 14 dní. Instalace programu je opět snadná jako v případě programu QuickTest, a pokud zvolíme typické možnosti, tak program si vše potřebné (hlavně doplňky Visual Basic, PowerBuilder, ActiveX a WebTest) nainstaluje zcela sám. Po úspěšné instalaci je zapotřebí restartovat systém, jinak nebude možné WinRunner spustit.

5.2 Prostředí WinRunneru Při startu aplikace se nám opět zobrazí Add-in Manager, ve kterém si můžeme zvolit doplňky, pomocí nichž budeme tvořit testovací skripty. Po spuštění WinRunneru se objeví obrazovka se třemi okny. První okno s názvem Debug Viewer (prohlížeč ladění), obsahuje záložky Watch List (seznam sledovaných proměnných), Breakpoints List (seznam bodů přerušení) a Call Chain (volané řetězce).

Obrázek 6 – WinRunner – Uživatelské prostředí

- 21 -

Automatizované testování V druhém okně se zapisují kroky, které jsme vytvořili v námi testované aplikaci. Lze mít otevřených několik testů najednou. Jednotlivé kroky jsou zaznamenávány v jazyku TSL (Test Script Language), jenž má syntaxi podobnou jazyku C. Třetí okno zobrazuje nově vytvořené a použité funkce v daném testu.

5.3 Testovací proces Testovací proces v případě WinRunneru probíhá v 6 fázích.

5.3.1 Rozpoznání všech objektů v aplikaci Winrunner se musí naučit rozeznat objekty v testované aplikaci, aby mohl spouštět vytvořené testy. Preferovaný způsob, jak ho naučit objekty závisí na zvoleném GUI map módu (mód mapy grafického uživatelského rozhraní).

5.3.2 Vytvoření vhodného testovacího skriptu, který ověří funkcionalitu aplikace WinRunner zapisuje testovací kroky automaticky, když provádíme akce v aplikaci nebo můžeme programovat kroky přímo pomocí TSL.

5.3.3 Ladění testů Pro zajištění plynulého průběhu testu bez žádných přerušení, nabízí WinRunner možnost spuštění vytvořeného testu v módu Ladění, při kterém se test spouští krok po kroku a my tak vidíme, kde se vyskytuje případně chyba, jenž vede k přerušení celého testu.

5.3.4 Spuštění testů K ověření funkčnosti aplikace se spustí vytvořený test, který prochází postupně nahrané kroky případně spouští definované funkce.

5.3.5 Analýza výsledků testu Po proběhlém testu se nám zobrazí okno s výsledky, ve kterém vidíme, zda test proběhl s chybou případně bez chyby.

- 22 -


Obrázek 7 – WinRunner – Výsledkové okno

5.3.6 Oznámení chyb V případě používání nástroje pro řízení testovacího procesu (Mercury Quality Center) se mohou snadno reportovat chyby přímo z výsledkového okna WinRunneru.

5.4 Možnosti jako QuickTest WinRunner stejným způsobem jako QuickTest používá ke kontrole kontrolní body (Checkpoints) a stejně tak i parametrizuje vytvořené testy kvůli jejich větší variabilitě.

5.5 Zhodnocení nástroje WinRunner Mercury WinRunner je nástroj podobný Mercury QuickTest, ale narozdíl od QuickTestu je spíše zaměřen na testování Windows aplikací. Vytvoření testu je velice snadné, ale jednotlivé kroky testu se zobrazují pouze v kódu jazyka TSL, takže jeho případná úprava vyžaduje znalosti programování. Po spuštění testu se zobrazí stav testu ve výsledkovém okně. Bohužel ve výsledcích nejsou vidět podrobně jednotlivé kroky testu jako v případě QuickTestu.

6 Canoo WebTest Canoo WebTest je nástroj pro automatizované testování aplikací patřící do oblasti nástrojů volně (zdarma) šiřitelných. Jak už napovídá samotný název, pomocí tohoto nástroje se testují pouze webové aplikace a poskytuje řadu funkcí, jimiž se vše potřebné ověří. [e-CAN]

- 23 -


6.1 Instalace Aplikaci je možné stáhnout ze stránek www.canoo.com. U poslední verze Canoo WebTest 2.1 lze stáhnout samotný nástroj WebTest, jeho dokumentaci, zdrojové soubory jazyka Java pro úkoly pomocí ANTu. K používání Canoo WebTestu je zapotřebí mít nainstalovanou Javu verze JDK 1.4 nebo vyšší, ANT verze 1.6 nebo vyšší a rozbalovací nástroj. Samotná instalace probíhá rozbalením stažených zdrojových souborů a potřebným nastavením. Nejdůležitějším nastavením je nastavení cesty domovského adresáře WebTestu v Ovládacích panelech MS Windows. Po tomto nastavení lze již spouštět potřebné testy.

6.2 Přostředí Canoo WebTestu Narozdíl od předchozích nástrojů WebTest nemá grafické uživatelské rozhraní a tedy příkazy, které chceme vykonávat, je zapotřebí psát v nějakém editoru, na který jsme zvyklí a který je pokud možno přehledný pro psaní kódu. Pokud nemáme dostupný žádný z editorů pro kódování, dá se určitě použít poznámkový blok, který je součástí MS Windows, nicméně pak tvorba testu není přehledná.

6.3 Testovací proces 6.3.1 Sestavení kroků testu Nejvhodnější vysvětlení způsobu práce nástroje Canoo WebTest je na nějakém příkladě. Předpokládejme tedy, že budeme chtít otestovat přístup na nějaké stránky, kde je zapotřebí vyplnit uživatelské jméno a heslo. Bude tedy zapotřebí se držet těchto kroků: 1.

Spustit adresu, kde se budou vyplňovat uživatelské údaje.

2.

Zkontrolovat tedy, zda název stránky je Login Page.

3.

Vyplnit uživatelské jméno Lukas.

4.

Vyplnit heslo Tramvaj.

5.

Potvrdit kliknutím na tlačítko OK.

6.

Zkontrolovat, zda je nyní přístupná požadovaná domácí stránka.

6.3.2 Převedení kroků do formy XML Výše uvedený seznam kroků tvoří sekvenci kroků, které dávají smysl pouze v případě, že je chceme spustit pro jednoho daného uživatele. Je to vlastně testovací scénář, kterého se tester drží při ověřování potřebné funkčnosti. Canoo WebTest nabízí určitou abstrakci tohoto scénáře ve formě XML. Převedení uvedených kroků do Canoo WebTestu je snadné: - 24 -

Automatizované testování <webtest name="normal" > &config; <steps> <setInputField description="Vyplnit uživatelské jméno" name="username" value="Lukas" /> <setInputField description="Vyplnit heslo" name="password" value="Tramvaj" />

XML pro Canoo WebTest se řídí vlastnostmi danými v souboru WebTest.dtd, kde jsou definovaná potřebná omezení. WebTest využívá výhody XML dokonce dále. Na třetím řádku se spouští příkaz &config, což je entita XML, která odkazuje na obsah souboru. XML parser tedy spouští daný obsah souboru v rámci tohoto testu. To je jedna z možností, kterou můžeme použít pro sdílení potřebných nastavení pro všechny kroky. V souboru je nastavení protokolu, hostujícího serveru a portu, které je sdíleno.

6.3.3 Použití ANT Z uvedeného příkladu můžeme dále rozpoznat hlavně podle elementu target, že Canoo WebTest používá ANT, který umožňuje programátorům používajícím jazyk Java, jenž WebTest používá, psát komplexní sestavovací schémata. ANT je celý implementován v jazyce Java, a to zaručuje jeho přenositelnost mezi různými platformami. Každá operace, kterou lze volat, s některými výjimkami, je implementována za pomoci standardních javovských knihoven, tedy bez využití nativních programů hostitelského operačního systému. Dalším aspektem je syntaxe sestavovacího souboru, který je samotnou utilitou zpracováván. Pro vytváření sestavovacích schémat pro utilitu ANT je, jak je možno vidět, využit formát XML. Toto využití formátu XML dovoluje zkontrolovat samotné sestavovací schéma. Element target je obalem pro logicky oddělitelnou část sestavovacího schématu, které dává jméno, popisuje ji a definuje podmínky, kdy může být provedena. Je to vlastně jakýsi vyšší funkční celek v sestavovacím schématu.

- 25 -


6.3.4 Spuštění testů Canoo WebTest tedy využívá schopnosti ANT k rozdělení testu do modulů, které mohou být volány jednotlivě nebo jako celek. Tímto způsobem můžeme volat jakýkoliv test odděleně. Samozřejmě je možné spojovat testy do testovacích scénářů, které mohou být zase součástí větších testovacích scénářů. Nakonec dostaneme strom testovacích scénářů, kde každý uzel a podstrom může být spuštěn. Spuštění několika testových kroků je implementováno pomocí HtmlUnit API, jenž je opět volně šiřitelný balík.

6.3.5 Zobrazení výsledků Po spuštění testů se vygeneruje html soubor s výsledky testů. Výsledky testů jsou v přehledné formě prezentovány pomocí stylu css. Každý test obsahuje odkaz na další html soubor, kde jsou vidět jednotlivé kroky, které opět obsahují odkaz na detail o úspěšnosti testu. Testy, které proběhly úspěšně, jsou zvýrazněny zeleně a testy s chybou červeně.

6.4 Další možnosti Canoo WebTest umožňuje definovat moduly, jenž mohou být znovu použity v různém množství testů. Příkladem je sekvence validačních kroků, které se používají skoro na každou webovou stránku. Tyto kroky mohou obsahovat kontrolu pro výpis copyright, u něhož se předpokládá, že bude zobrazen na každé stránce. WebTest může být také použit pro zautomatizování průběhu projektu. Pokud budou testy pokrývat všechny požadavky, potom každý spuštěný test nám dá zpětnou vazbu o současném stavu plnění daného projektu. Historie reportů testů nám odráží produktivitu testovacího týmu v termínech. Poslední report vždy zobrazuje současný stav projektu v nejvíce spolehlivé míře, což jsou běžící a již otestované případy užití.

6.5 Rozšíření prostředí Ze stránky webtestrecorder.canoo.com je možné stáhnout rozšíření WebTest Recorder pro prohlížeč Mozilla Firefox, který dokáže zaznamenávat prováděné akce na testované stránce. Díky tomuto doplňku se tedy nemusí manuálně vypisovat vlastnosti objektů do dané XML struktury, protože se v této struktuře generují samy do postranního pruhu v prohlížeči Firefox. Toto rozšíření dokáže zaznamenat všechny tyto akce: - invoke (například zadání webové adresy), - clickLink (kliknutí na libovolný odkaz na stránce), - 26 -

Automatizované testování - clickButton (kliknutí na tlačítko), - setInputField (vyplnění textového pole), - setSelectField (vybrání položky ze seznamu), - setCheckbox (zaškrtnutí Checkboxu), - setRadioButton (zaškrtnutí RadioButtonu), - setFileField (vyplnění pole s cestou k souboru). Další možností rozšíření je kontrola určitých objektů: - verifyTitle (kontrola názvu objektu), - verifyText (přesná kontrola uvedeného textu), - verifySelectField (kontrola vybrané položky v poli), - verifyInputField (kontrola řetězce v daném poli), - verifyTextArea (přesné ověření celé textové oblasti). A poslední možností doplňku je XPath explorer (průzkumník jazyka XPath), v němž je možné si ověřit, tedy i vidět všechny zvolené uzly právě vygenerovaného XML.

Obrázek 8 – Canoo Webtest Recorder

6.6 Kontroly Kontrola PDF Canoo WebTest umí používat kroky, které umožňují vykonávat různé testy na PDF souborech, na něž je odkazováno z testovaných webových stránek. Dané kroky dokáží ověřit textový obsah, použití druhu fontu, odkazy, záložky, informace o zabezpečení dokumentu a používají různé filtry, které umožňují dále manipulovat se získanými informacemi. Kontrola Excelu Jednou z dalších kontrol jsou testy, jejichž kroky provádí různé testy na souborech vytvořených pomocí aplikace MS Excel, a na které se odkazuje testovaná webová stránka. Tyto kroky dovolují ověřit textový obsah souboru, použité styly, zkontrolovat součty a opět používají různé filtry, které umožňují dále manipulovat se získanými informacemi. - 27 -

Automatizované testování Kontrola Emailu Jedná se o kroky, které ověřují informace odeslané emailem z testované aplikace a zase mohou s danými informacemi dále pracovat.

6.7 Zhodnocení nástroje Canoo WebTest Canoo WebTest je nástroj pro automatizované testování webových aplikací, který je narozdíl od předchozích nástrojů volně šiřitelný. Pro někoho může být nevýhodou, že nástroj nemá grafické uživatelské prostředí, ale jinak pomocí svých funkcí dokáže pokrýt celou oblast testování. Jako náhrada za uživatelské prostředí může posloužit rozšíření WebTest Recorder, které tvorbu testů usnadňuje. Po spuštění testu se nám výsledky zobrazí v html souboru, kde je vidět průběh testu a u jednotlivých kroků je označen stav, zda proběhl úspěšně či nikoliv.

7 SoapUI SoapUI je desktopová aplikace, která dokáže zkontrolovat, spustit a samozřejmě tvořit funkční a zátěžové testy webových služeb (web services) přes protokol HTTP (Hyper Text Transfer Protokol). Opět se jedná o nástroj pro automatizované testování, jenž patří mezi volně šiřitelné. [e-SOA] Aplikace je vyvíjena hlavně pro vývojáře nebo testery, kteří webové služby (java, .net, atd.) poskytují nebo vyžívají. Funkční a zátěžové testování mohou být vytvářeny přímo v prostředí soapUI nebo pomocí příkazového řádku.

7.1 Instalace Poslední verze soapUI 1.6 final lze stáhnout z webové stránky www.soapui.org. Po stáhnutí zapakovaného balíčku se nemusí aplikace instalovat, ale stačí soubory rozpakovat do libovolně zvoleného adresáře. Dále je zapotřebí mít nainstalovanou a tedy i nastavenou Javu 1.5 nebo vyšší. Nyní je již možné soapUI spustit z daného umístění. SoapUI nabízí i možnost stažení si aplikace, která se instaluje a též nainstaluje potřebnou verzi Javy. Pokud si nejsme jistí naší verzí Javy, je tedy nejvhodnější stáhnout si instalátor, který vše udělá za nás.

7.2 Prostředí SoapUI je aplikace, která dodržuje zavedené koncepty uživatelského rozhraní, jako například Eclipse. Většina funkcí má své klávesové zkratky. Po spuštění nástroje se objeví obrazovka, která má po levé straně navigační pruh (Main Navigator), ve kterém jsou hiearchicky setříděny jednotlivé projekty a jejich složky:

- 28 -

Automatizované testování •

Projects: soapUI pracovní prostor o Project: pro každý projekt v pracovním prostoru Interface: pro každé rozhraní v projektu Operation: pro každou operaci v rozhraní Request: pro každý požadavek vytvořený pro danou operaci TestSuite: pro každý testovací scénář v projektu TestCase: pro každý testovací případ v testovacím scénáři TestSteps: obsahem testovacího případu TestStep: pro každý krok LoadTests: obsahem testovacího případu LoadTest: pro každý zátěžový test.

Po vybrání některé složky se v navigačním pruhu zobrazují její vlastnosti (Workspace Properties) v přehledné formě.

Obrázek 9 – soapUI – Uživatelské prostředí

V dolní části obrazovky je umístěn vodorovný pruh (Log), ve kterém jsou zaznamenávány všechny prováděné akce s uvedeným časem.

- 29 -

Automatizované testování Poslední částí obrazovky soapUI je pracovní plocha (Desktop). Zde se zobrazují všechna okna, která byla vyvolána z navigačního pruhu na levé straně. Okna mají standardní funkce jako maximalizace, minimalizace, změna velikosti, posun a zavření.

7.3 Webová služba (Web Service) Webové služby jsou aplikace, které užívají standardní přenosy, kódování a protokoly k výměně informací. Umožňují počítačovým systémům na jakékoliv platformě komunikovat v intranetu, extranetu a v internetové síti. Webové služby jsou postaveny na základě standardů, jenž popisují syntaxi a sémantiku softwarové komunikace. XML poskytuje běžnou syntaxi pro vytváření dat, protokol SOAP (Simple Object Access Protocol) poskytuje sémantiku pro výměnu dat; a jazyk WSDL (Web Services Description Language) poskytuje mechanismus pro popsání funkčnosti webové služby. SOAP SOAP je předpis, kterým se řídí vlastní komunikace mezi klientem a serverem. Komunikace probíhá přes protokol HTTP a je uskutečňována výměnou dat XML ve specfickém tvaru. O celou tuto záležitost se stará zprostředkovatel SOAP. WSDL Popis rozhraní webové služby (kde je služba k dispozici, jaké má vstupní/výstupní parametry) je možné formálně specifikovat pomocí popisu v jazyce WSDL ve formátu XML. Obsahuje jméno služby, seznam a popis jejích metod. Do popisu metod patří názvy a datové typy všech parametrů spolu s informací o datovém typu návratové hodnoty. Soubor nakonec obsahuje URL adresu příjemce (listeneru), který s pomocí serveru SOAP celou komunikaci na straně serveru zprostředkovává.

7.4 Testovací proces Testování webové služby probíhá následujícím způsobem.

7.4.1 Vytvoření nového projektu Nejdříve se vytvoří projekt, kterému dáme libovolný název. Nejlépe se hodí název odpovídající názvu testované webové služby.

- 30 -


7.4.2 Načtení WSDL K tomu, aby se dal nově vytvořený projekt použít pro ověření některé funkčnosti webové služby, je zapotřebí zjistit strukturu a metody, které daná webová služba používá. Toho docílíme tím, že do daného projektu načteme odkaz na WSDL testované služby. Aplikace SoapUI dokáže z daného WSDL načíst všechny operace a sama pro tyto operace vytvoří požadavky (Requests), jež uloží na dané místo ve stromové struktuře, jak je uvedeno výše. Poslední verze soapUI umožňuje v požadavku posílat kromě dat v XML také libovolné množství příloh a HTTP hlavičky, kde se vyplní název hlavičky a její hodnota.

7.4.3 Vložení požadavku do testovacího případu Nyní je možné vytvářet samotný automatizovaný test pro webovou službu. Podle uvážení a tedy toho, co chceme ověřit, si vybereme jeden nebo více požadavků a přidáme je do testovacího případu. Požadavky se uloží opět do příslušné části stromové struktury a tím vznikne krok, případně kroky, v rámci testovacího případu.

7.4.4 Upravení dat v požadavku Jak již bylo řečeno, požadavek obsahuje XML, jehož struktura se automaticky vygenerovala podle WSDL. Samozřejmě je nutné dané XML vyplnit daty, které potřebujeme ověřit v testované webové službě. Místa, která můžeme doplňovat, jsou označena otazníky uprostřed tagu. Například: ?. Otazník lze nahradit buď skutečnou nebo proměnnou hodnotou. Dále nám nástroj soapUI v XML označí řádky podle WSDL, které se nemusí nutně vyplňovat. Takže lze jednoduše rozeznat, která data jsou nutná k vyplnění a která ne. Nepovinné řádky, které se rozhodneme nevyplňovat, je zapotřebí smazat.

7.4.5 Nastavení kontrol SoapUI umí u daného požadavku ověřit jeho schéma (Schema Compliance), obsah (Simple Contains), vybraná data pomocí XPath (XPath Match), validaci SOAP (SOAP Fault Assertion) a co nemá obsahovat (Simple NotContains).

7.4.6 Spuštění testu Spustit lze samostatný krok nebo vybrané kroky v testovacím případě. Při spouštění celého testovacího scénáře lze nastavit, aby se jednotlivé testovací případy, které jsou v něm

- 31 -

Automatizované testování obsažené, spouštěly najednou nebo postupně. Toto nastavení logicky nelze provést v případě spouštění testovacího případu, kdy se kroky vždy spouští postupně.

7.4.7 Zobrazení výsledků Výsledky proběhlého testu jsou jednoduše zvýrazněny u provedených kontrol, jenž byly vybrány a provedeny. Kontrola, která proběhla s úspěšným výsledkem, je označena zeleně, a kontrola s neúspěšným výsledkem je označena červeně.

7.5 Zátěžový test (Load test) Do každého testovacího případu lze vytvořit zátěžový test pro webovou službu. SoapUI umožňuje funkční zátěžové testování, které validuje funkcionalitu pod zátěží použitím standardních metod testovacího případu. Zátěžový test v soapUI může být spuštěn užitím různých strategií pro způsob spuštění testovacích případu. Všechny strategie mají možnost nastavit počet vláken (thread-count), jenž definuje, kolik testovacích případů má být spuštěno současně. U každé strategie se měří nejkratší čas trvání kroku, jeho nejdelší čas, průměrný čas, poslední čas, kolikrát byl krok spuštěn, počet transakcí za sekundu vykonaných v kroku a počet chyb v testovacím kroku. Naměřené údaje se dají zobrazit v přehledné formě pomocí grafů a to buď způsobem statistického grafu, který zaznamenává průměrné hodnoty za všechny běhy zátěžového testu nebo graf pro naposledy proběhlý test.

7.6 Zhodnocení nástroje soapUI SoapUI je kvalitně zpracovaný nástroj, jenž slouží k ověření správné funkčnosti webových služeb. Opět se jedná o nástroj, který lze používat zdarma. Jeho grafické uživatelské prostředí přehledně zobrazuje všechny funkce a potřebná data, která potřebujeme. Lze si rychle a snadno vytvořit základní testy, aniž bychom museli ovládat některý z programovacích jazyků a se stejnou obtížností si můžeme vytvořit i zátěžový test pro webovou službu. Po spuštění testů vidíme výsledky ve stručné ale postačující formě.

8 Závěr 8.1 Shrnutí hlavních myšlenek V současné době se společnosti snaží o zefektivnění testování software v rámci vývoje. Lidské zdroje jsou finančně nákladné, proto využívají ke snížení nákladů nástroje, které umožňují testování automatizovat.

- 32 -

Automatizované testování Automatizování testů nemusí nutně přinést očekávané snížení nákladů. Je zapotřebí důkladně zanalyzovat, zda vůbec automatizaci použít či nikoliv. Určitě se vyplatí tvořit automatizované testy pro ta ověření, která se pravidelně opakují. Tím se náklady na lidské zdroje výrazně sníží. Všeobecně se jako podmínka pro automatizování testů považuje jeho delší používání. Samotné automatizování je totiž na zdroje náročné a to jak na lidské zdroje, tak i na softwarové zdroje. Proto si společnost musí zvážit, zda nejdříve investuje větší částky do automatizace, než by vložila do manuálního testování. Snížení nákladů se projeví až v delším časovém horizontu, kdy se vlastně bude jednat pouze úpravu již vytvořených automatických testů v případě změny funkčnosti počítačového systému nebo o jejich spouštění a vyhodnocení výsledků.

8.2 Zhodnocení popsaných nástrojů Softwarové firmy zabývající se tvorbou nástrojů pro automatizované testování se snaží pokrýt všechny oblasti testování, aby tyto nástroje bylo možno použít téměř v každém případě. V současné době lze automatizovat testování aplikací systému MS Windows, webových aplikací, webových služeb, bezpečnosti a zatížení systému. Ve své práci jsem nepopsal nástroje pro testování bezpečnosti a zatížení, protože se tyto testy provádí vždy automaticky a firmy se tedy nemusí rozhodovat, zda testy automatizovat či nikoliv. Zaměřil jsem se tedy na čtyři nástroje, u kterých si společnost může zvážit podle možností jednotlivých nástrojů, zda náklady vyložené na vytvoření automatizovaných testů se v delším časovém úseků více vyplatí než používání manuálního testování. Jako zástupce z jednotlivých oblastí automatizovaného testování jsem si vybral dva komerční nástroje od společnosti Mercury a to QuickTest Professional a WinRunner. Zbylé dva nástroje Canoo WebTest a soapUI jsou zástupci volně šiřitelných nástrojů. V práci jsem uvedl u každého nástroje jeho specializaci, což je hlavní faktor, který určí možnosti výběru nástroje. Mercury WinRunner je specializován na desktopové aplikace, Mercury QuickTest a Canoo WebTest se zaměřuje na testování webových aplikací a soapUI je určen pro ověřování webových služeb. U všech nástrojů byl popsán způsob instalace, grafické uživatelské rozhraní, proces tvorby testů, způsob reportování výsledků a jeho specializace.

- 33 -

Automatizované testování Pořadí

Instalace

GUI

Tvorba testů

Cena

QuickTest,

WinRunner,

Canoo WebTest,

soapUI

QuickTest

soapUI

WinRunner

WinRunner

soapUI

3.

soapUI

Canoo WebTest

Canoo WebTest

4.

Canoo WebTest

1.

QuickTest

2.

Výsledky QuickTest

WinRunner,

soapUI,

QuickTest

WinRunner Canoo WebTest

Tabulka 1 – Zhodnocení popsaných nástrojů

V tabulce je uvedeno pořadí jednotlivých nástrojů za určitou popisovanou kategorii. Nástroje jsou tedy seřazeny podle nejvhodnějšího využití za každou kategorii. Samozřejmě se nedá určit podle tohoto hodnocení, že například QuickTest Professional je nejvhodnějším nástrojem pro automatizované testování. Záleží na každé společnosti, které z výše uvedených kriterií považuje za nejdůležitější, proto je velice důležité promyslet všechny možnosti pro automatizování testů. Pokud hraje důležitou roli cena, bude lepší použít pro testování webových aplikací Canoo WebTest, ale společnost musí počítat s vyššími náklady na vytvoření testů, které je rozhodně náročnější než v případě použití komerčních nástrojů jako je QuickTest nebo WinRunner, u kterých dokáže každý vytvořit testy bez znalosti jakéhokoliv programovacího jazyka.

- 34 -


Terminologický slovník API

(Application Programming Interface) Rozhraní aplikačních programů

CSS

(Cascading Style Sheets) Kaskádové styly: 1. Kaskádové formátovací styly aplikované v souvislosti s dokumenty v HTML 2. Aplikuje formátování na uzly XML dokumentu. Nemá takovou funkcionalitu jako XSL-FO a soubory .css nejsou formátu XML, proto se obtížně zpracovávají.

GUI

(Graphical User Interface) Grafické uživatelské rozhraní

HTTP

(HyperText Transfer Protocol) Protokol pro přenos dokumentů v Internetu (používá se nejčastěji na WWW)

IT

(Information Technology) Informační technologie

JDK

(Java Development Kit) Základní prostředí pro vytváření a spouštění programů v Javě

PDF

(Portable Document Format) Formát pro přenositelné dokumenty

RUP

(Rational Unified Process) Metodika vývoje SW

SOAP

(Simple Object Access Protocol) XML protokol 2. generace překonává slabiny předchozích dvou. Prostřednictvím mechanismu jmenných prostorů (XML Namespaces) je snadno rozšiřitelný. Kvůli podpoře binárních dat byl definován i protokol SOAP s attachementy.

TSL

(Test Script Language) Skriptovací jazyk pro testy vytvořené nástrojem Mercury WinRunner

VBS

(Visual Basic Script) Skriptovací jazyk Visual Basic.

WSDL (Web Services Description Language) XML dokument popisující rozhrání webové služby a detaily nutné k připojení ke službě (síťový protokol, požadavky na kódování dat, apod.) XML

(Extensible Markup Language) Značkovací jazyk obsahující příkazy definující syntax (strukturu) dokumentu, definovaný doporučením W3C (WWW Consortium). Navazuje na něj řada dalších standardů/technologií např. DTD (Document Type Definition), XSTL (XSL Transformations), SOAP (Simple Object Access Protocol). - 35 -

Automatizované testování XSLT

(Extensible Stylesheet Language Transformations) XSL Transformations – Transformuje XML dokumenty buď často zase do jiných dokumentů XML, nebo do jiných formátů, jako je HTML, PDF, RTF, databázových formátů, atd.

- 36 -


Seznam pramenů Publikace [PAT02]

Patton, R.: Testování software Computer Press, 2002, ISBN 80–7226–636–5

[BLA02]

Black, R.:

Managing the Testing process John Wiley & Sons, 2002, ISBN 0471223980

[MQT06]

Mercury:

Mercury QuickTest Proffesional Basic Features User´s Guide, v9.0 Mercury Interactive Corporation, 2006

[MWR04]

Mercury:

Mercury WinRunner User´s Guide, v8.0 Mercury Interactive Corporation, 2004

Internet [e-RUP]

Metodika RUP, 2006 http://objekty.vse.cz/RUP

[e-CAN]

Oficiální stránky Canoo, 2006 http://www.canoo.com/

[e-SOA]

Oficiální stránky soapUI, 2006 http://www.soapui.org/

- 37 -


Seznam obrázků Obrázek 1 – Iterativní vývoj [e-RUP] ............................................................................... - 2 Obrázek 2 – QuickTest – Expert View .......................................................................... - 13 Obrázek 3 – QuickTest – Keyword View ...................................................................... - 13 Obrázek 4 – QuickTest – Vlastnosti kontrolního bodu................................................ - 17 Obrázek 5 – QuickTest - Výsledkové okno .................................................................. - 20 Obrázek 6 – WinRunner – Uživatelské prostředí ........................................................ - 21 Obrázek 7 – WinRunner – Výsledkové okno................................................................ - 23 Obrázek 8 – Canoo Webtest Recorder ......................................................................... - 27 Obrázek 9 – soapUI – Uživatelské prostředí................................................................ - 29 -

- 38 -

Vysoká škola ekonomická v Praze. Automatizované testování

Recommend Documents