Dnes bych se v tomto miniseriálu na téma SoapUI rád věnoval možnosti využití zdroje dat pro automatizaci testů. Navazuji přitom na předchozí díl, kdy jsem nastínil možnost využití SoapUI jako nástroje autmatizovaného testování. Dnes bych tut oblast rád rozšířil o práci se zdrojem dat. Hned na úvod bych ale rád řekl dvě věci. Tou první, nepříjemnější, je fakt, že funkčnost umožňující pracovat se zdrojem dat je přístupná pouze v placené verzi SoapUI Pro. Cena licence na tuto verzi není úplně zanedbatelná - 349 $ na rok. Druhou věcí, kterou bych tu rád zmínil, je fakt, že ikdyž se tu budu zaobírat použitím zdroje dat, postihnu přitom jen ten nejjednodušší způsob, jak tuto problematiku u SoapUI řešit. Berte to tedy jen jako takové uvedení do problému, než že by šlo o vyčerpávající popis.

Na co zdroj dat?

Existuje jeden způsob testování, který se označuje jako testování řízené daty. Já už tady v některých článcích tento přístup k testování zmínil. Jednoduše řečeno, je tu nějaký obecný průchod testu, u kterého se pro různá vstupní data očekává různý výstup. Z hlediska přípravy testů to předpokládá, že existuje obecný skript, tedy sled kroků nebo šablona vstupních dat, který se ve stejné podobě použije pro skupinu testů. Tyto testy se od sebe liší pouze vstupními daty a očekávanými výsledky. Pravě to je častá situace při testování webservis.

Aby tento způsob byl efektivní, používají se nástroje umožňující na jedné straně definovat obecnou podobu testu a na straně druhé spojit tento test pomocí nějakých proměných se zdrojem dat tak, aby bylo možné automatické provedení testu nad celým zdrojem dat včetně vyhodnocení testů. Nevím jestli jsem se vyjádřil dostatečně jasně. Nicméně myslím, že se situace vyjasní, až si ukážeme konkrétní použití daty řízených testů v SoapUI.

Vytvoření zdroje dat

Výchozím bodem pro vytvoření zdroje dat, je existence TestSuity v té podobě, jak byla popsána v minulém dílu. SoapUI by mělo vypadat přibližně takto:

TestCase obsahuje jeden krok, který (jak jsme si řekli minule) je vygenerován spolu s TestCasem a obsahuje spuštění requestu. Tento krok zde v tuto chvíli nepotřebujeme a můžeme ho odstranit (jednoduchým označením kroku a stiskem klávesy Delete).

Vytvoření zdroje dat je tu reprezentováno vložením příslušného kroku do TestCasu. V nástrojové liště záložky TesStep je v pravé části ikona , která odpovídá kroku Create a new DataSource. Po jejím odkliknutí se zobrazí dialog pro zadaní jména datového zdroje a následně okno DataSource pro samotnou správu datového zdroje. Toto okno má dvě důležité části. Na levé straně vidíte panel Properties a napravo do něj panel Configuration. Práce s nimi je celkem jednoduchá. V první řadě je (pro mnou popisovaný nejednodušší postup) nutné v horní části panelu Configuration přepnout Combobox DataSource na hodnotu Grid. Tím dáme SoapUI nasrozuměnou, že zdrojem dat bude tabulka, která bude zde v tomto okně vytvořena. V tomto Comboboxu můžete vidět, že k dispozici je celá řada typů zdrojů dat. Od externího souboru, XML nebo Excelovské tabulky až po vstup z databáze. Ale jak už jsem řekl, dnes se zaměříme na nejrychlejší a nejsnadnější způsob (alespoň z mého pohledu), jak TestCase propojit se zdrojem dat.

V panelu Properties vidíte tuto ikonu . Ta slouží k přidávání properties, což jsou vlastně sloupce v tabulce dat. Po kliknutí na tuto ikonu je zobrazen dialog pro vložení jména sloupce a následně je slopec vytvořen. Lépe řečeno v panelu Properties přibude příslušný řádek a v panelu Configuration odpovídající sloupec. S tabulkou v panelu Configuration se pracuje celkem standardně a myslím, že běžnému uživateli nebude činit problém ji vyplnit.

Jako ukázku znovu použijeme webservisu GeoIPService, která na zadanou IP adresu vrací kód země odpovídající příslušné doméně. Zdroj dat, který použijeme, bude mít dva sloupečky: IPAdresa, KodZeme. Testovací data, která použijeme budou následující: 77.75.72.3, CZE; 74.125.232.210, USA. Okno DataSource bude vypadat takto:

Tím jsme si vytvořili zdroj dat, který následně použijeme pro testy.

Propojení TestCasu a zdroje dat

Abychom mohli TestCase propojit se zdrojem dat, musíme v editoru kroků znovu vytvořit krok, spouštějící odeslání requestu. K tomu slouží ikona . Po jejím odkliknutí se zobrazí sled dialogů, které jsme si tu už v předchozím díle představili a průchod skrz ně je vcelku jednoduchý. Výsledkem je, že je vytvořen krok odeslání requestu a je otevřeno okno s tímto requestem.

Všimněte si, že request je zobrazen v módu Form. Přepnutí módů je možné pomocí založek ne levé straně okna requestu. Každopádně právě mód Form je ten, který v tuto chvíli potřebujeme. V tomto módu je request zobrazen ako formulář s tím, že zobrazuje pouze ty elementy, které umožňují vložení hodnoty. V našem případě tedy pouze element IPAddress.

Pokud nad polem ve formuláři kliknu pravým tlačítkem myši zobrazí kontextové menu, ve kterém je první položkou Get Data. Tato položka menu obsahuje další úrovně. V té další je potřeba zvolit typ kroku, který pro získání dat použijeme.  V našem případě jde logicky o krok DataSource. Po najetí na tuto možnost se otevře další úroveň menu. Ve výsledku bude kontextové menu vypadat takto:

Jak vidíte, poslední úroveň menu obsahuje seznam sloupců, které jsme si vytvořili v datovém zdroji. My v této ukázce zvolíme sloupec IPAdresa. Po této volbě se do formuláře vloží tato hodnota ${DataSource#IPAdresa}. V tuto chvíli je request propojen s datovým zdrojem.

Pokud si teď zkusíme TestCase spustit, zjistíme, že skutečně proběhne a použije i data z datového zdroje, ale proběhne pouze jednou, přestože tabulka obsahuje dva řádky. Fakt, že proběhl pouze jednou zjistíme pohledem do logu TestCasu.

Abychom TestCasu vysvětlili, že má použít všechna data ve zdroji, musíme mu přidat ještě jeden krok. V nástrojové liště je mu přidělena tato ikona a jmenuje se DataSource Loop. Slouží k opakování běhu requestu nad daným zdrojem dat. Při vkládání do TestCasu nemá kromě jména žádné další parametry. Ovšem takto by test skončil chybou. Je nutné, po vložení kroku DataSource Loop do TestCasu, na tento krok dvakrát kliknout a tím si otevřít okno jeho parametrů.

Jak vidíte, parametry jsou tu dva. První říká, který DataSource krok se má pro opakování použít, a druhý pak který request se má opkaovat. Je zřejmé, že lze vytvářet složité (nebo složitější) testy, kteté obsahují více jak jeden datový zdroj a více jak jeden request. My ovšem v našem případě nemám moc z čeho vybírat. Proto zvolíme jediný možný zdroj dat a jediný možný request a parametry uložíme.

Pokud teď TestCase spustíme, proběhne již dvakrát a v každém opakování jsou použitá data, odpovídající příslušnému řádku datového zdroje. Od této chvíle bude TestCase provádět tolik běhů, kolik odpovídá počtu řádků ve zdroji dat.

Aserce s propojením na zdroj dat

Jak už jsme si řekli v minulém díle, TestCase bez asercí nemá příliš význam. Právě aserce nám dokáží ohlídat, jestli test dopadl úspěšně nebo ne. Aby bylo možné vyhodnotit test, který je napojený na zdroj dat, musí být také aserce nasměrována na stejný zdroj. Toho dosáhmene poměrně snadno. Otevřeme si okno requestu (stačí dvojklik na příslušném kroku v TestCasu). Ve spodní části tohoto okna je záložka Assertions. Kliknutím pravým tlačítkem myši v této záložce si zobrazíme kontextové menu obsahující volbu Add Assertion. Po jejím odklinutí se zobrazí dialog pro výběr typu aserce. Zvolíme typ XPath Match.

Po odeslání se zobrazí okno pro nastavení parametrů aserce. V něm uvidíte tuto ikonu   Po kliknutí na ní se zobrazí dialog pro výběr elementu v response, který bude hlídán.

Tady bych rád něco poznamenal. Zřejmě se vám stane, že neuvidíte tuto strukturu, kterou tu mám já. Je to dáno tím, že náš request, nad kterým aserci nastavujeme, neobsahuje konkrétní IP adresu, ale onu proměnou, která ho propojuje se zdrojem dat. Aby bylo možné aserci nastavit, je potřeba si request spustit s konkrétní IP adresou, abychom získali validní response. Z toho plyne, že aserce by měly být nastaveny dřív než propojíme request s daty. Ovšem mně se pro potřeby tohoto článku zdálo lepší tyto činnosti otočit.

V zobrazeném dialogu zvolíme element CountryCode. Do okna parametrů aserce se nám vloží příslušné nastavení.

V dolní části okna vidíte panel Expected Result a v něm je v tomto případě hodnota CZE. My ale chceme, aby se právě Expected Result měnil na základě datového zdroje. Proto ho musíme s tímto zdrojem spojit. K tomu slouží tlačítko v pravé části okna, které je označené jako Select Content. Po kliknutí na něm se zobrazí nám již známá struktury menu.

V poslední úrovni menu zvolíme tentokrát možnost Property[KodZeme]. Do panelu Expected Result se nám vloží kód ${DataSource#KodZeme}. V tuto chvíli máme aserci spojenou se zdrojem dat.

Toto je tedy, podle mého názoru, nejjednodušší způsob, jak s pomocí SoapUI realizovat automatizované daty řízené testy. Budu rád, pokud tento dnešní článek někomu z vás pomůže.