Chtěl bych navázat na poslední článek o SOAP UI a dnes se konečně dostávám k tomu, jakým způsobem SOAP UI podporuje testování.

Už jsme si řekli, jaký je nejjednodušší způsob testování webservis pomocí SOAP UI. Přiznejme si ale, že tento způsob není testersky úplně čistý. Minimálně princip opakovatelnosti testů zde není zcela naplněn. Dobrou zprávou je, že SOAP UI obsahuje funkce podporující testování.

Na začátku si řekneme s jakými pojmy SOAP UI v oblasti testování pracuje. Je příjemné, že tyto pojmy jsou nám blízké i z testerské teorie. Takže jen ve stručnosti:

Test Suite představuje seskupení testů, které spolu nějakým způsobem souvisí. To, jaké testy budou do Test Suit zařazeny , záleží jen na nás. Test Suite tak fungují jako obdoba adresářové struktury.

Test Case nebo také nám již známý Testovací případ. Jde o samostatný test, ověřující konkrétní funkci nebo vlastnost. U SOAP UI je základem každého Testovacího případu request, který obsahuje data navozující požadovanou testovanou situaci. Každý TestCase se skládá z Test Steps, tedy testovacích kroků, a každý obsahuje minimálně jeden krok, který slouží k odeslání již zmíněného requestu. Ale kroků může být v testovacím případě mnohem více.

Test Step říká, jaké činnosti mají být v rámci Test Casu vykonány a v jakém pořadí.  Jak už jsem řekl, každý TestCase obsahuje minimálně jeden krok, který spouští zasílání requestu. Bez tohoto kroku by test webservisy postrádal smysl. Kroků ale může být v testu více. Jednak je samozřejmě možné zasílat více requestů (tedy v testů je více kroků pro zaslání requestu), ale SOAP UI obsahuje také kroky, které umožňují Test Case rozšířit o další vlastnosti jako je například schopnost přihlásit se a odhlásit k serveru poskytujícímu webovou službu. Je zde také možnost průběh zpracování Test Casu větvit pomocí podmínek nebo napojit test na zdroj dat pro testování řízené daty (o tomto tématu si povíme v dalším článku).   

Vytvoření TestSuite a TestCase

A jak se tedy s testy v SOAP UI pracuje. Prvním krokem je vytvoření Test Suite. To je možné několika způsoby, ale my si tu ukážeme ten nejjednodušší (jsem zastáncem nejjednodušších řešení) a tím je vytvoření Test Suite při vytváření projektu.

Dialogové okno pro vytvoření projektu obsahuje mimo jiné také CheckBox Create TestSuite, po jehož zaškrtnutí je současně s projektem vytvořena i příslušná TestSuite.

SOAP UI vytvoří automaticky TestSuite i příslušné TestCasy a to na základě struktury webservisy. Ještě než k tomu dojde, zeptá se SOAP UI na další atributy nutné pro vytvoření testů. K tomu slouží samostatné dialogové okno, které se zobrazí po potvrzení výše uvedeného dialogu vytvoření projektu.

SOAP UI dává možnost vytvořit samostatný test pro každou operaci ve struktuře webservisy nebo vytvořit souhrnný test (tedy jeden test přes všechny operace), kde pro každou operaci bude vytvořen samostatný request. Je také možné vybrat si jen některé operace, pro které má být test vytvořen.  

SOAP UI po potvrzení dialogu vytvoří TestSuit a v ní příslušný počet TestCasů. Jejich jména odpovídají jménu webservisy a jejích operací.

Dnes se tu nebudu více věnovat možnostem, které nabízí TestStepy. Článek by se tím výrazně prodloužil a pro běžné provádění testů nám onen výchozí krok spouštění requestů stačí.

Spouštění testů

Testy je možné spustit buď hromadně z Test Suite nebo jednotlivě. Po dvojkliku na TestSuite ve stromové struktuře v levém panelu se otevře okno, které slouží právě ke spouštění testů. V levém horním rohu tohoto okna je ikona v podobě zelené šipky, která spustí běh všech TestCasů obsažených v TestSuite. Napravo od této ikony je ikona v podobě křížku sloužící k zastavení běhu testů a napravo od ní jsou další dvě ikony, které umožňují nastavit způsob, jakým jsou jednotlivé testy spouštěny. Může jít buď o spouštění v sekvenci, kdy další test je spuštěn teprve po skončení testu předchozího, nebo lze testy spustit paralelně.

Okno TestSuite zobrazí i výsledek testů. Tady musím říct, že pokud test spustíte v té podobě, v jaké jej SOAP UI vygeneruje, pak informace o jeho výsledku nemá velkou vypovídací hodnotu. Informuje nás vlastně jen o tom, že request byl úspěšně odeslán a byla přijmuta response. Neříká nic o tom, jestli data na výstupu odpovídají datům očekávaným. To je celkem logické, protože SOAP UI nemůže vědět, jaká data na výstupu očekáváme. Samozřejmě je způsob, jak mu tuto informaci dát a my se k němu za chvíli dostaneme.

Test je možné spustit také z jednotlivých TestCasů. Dvojklikem na konkrétním TestCasu ve stromové struktuře se otevře okno příslušnho TestCasu. To vypadá odlišně než okno TestSuite. Jeho hlavní část tvoří editor TestStepů. Ty se zde dají přidávat, editovat i mazat. Jak už jsme řekl, k TestStepů se dostaneme v dalším článku. Nyní chceme z tohoto okna spustit test. K tomu opět slouží známá ikona zelené šipky v levém horním rohu okna.

I v tomto případě je zobrazen výsledek testu a také zde platí omezení týkající se vypovídací hodnoty tohoto výsledku. Bližší informace o průběhu testu se dají nalézt ve spodní části okna v TestCase Logu.

Aserce

Aserce představují jeden (ale ne jediný) ze způsobů, jak předat SOAP UI informaci o očekávaném výsledku testu. Aserce jsou vázané na request. Říkali jsme si, že při vytváření testů jsou zároveň vytvářeny i příslušné requesty. Pro každý takový request je možné nadefinovat aserce a ty tak mohou být pro každý test jiné. Což je přesně to, co pro testování potřebujeme.

Abychom mohli v testu aserce vytvořit, musíme si otevřít okno requestu, který k tomuto testu náleží. Tento request je ve stromové struktuře přístupný pomocí TestStepu SOAP.

Zobrazené okno už známe. Je to klasické okno requestu, které jsme používali pro jednoduché testy webservis. V levé části je samotný request, v pravé response.

V levém horním rohu okna, vedle ikony zelené šipky (která zde neslouží ke spuštění testu, ale pouze k odeslání requestu), je ikona s křížkem a prolínajícími se kruhy. Po kliknutí na tuto ikonu je zobrazený jednoduchý dialog, sloužící k výběru aserce. Asercí totiž existuje celá řada. Raději se rovnou přiznám, že u většiny z nich nevím přesně (nebo prostě nevím vůbec), k čemu slouží a musel bych jejich význam hledat. Proto vám zde představím jako příklad použití asercí tu, kterou přeci jen znám.

Aserce Contains je zřejmě tím, co vás napadne jako první, pokud budete o způsobu vyhodnocování výsledků testu webservis uvažovat. Hlídá totiž obsah response. Je to velice jednoduchý nástroj kontroly. Pokud do této aserce vložím text, který v responsi na mnou zaslaný request očekávám, SOAP UI jednoduše zkusí tento text v response najít a pokud ho najde, prohlásí test za úspěšně dokončený. Hledaný text se vkládá skutečně jako prostý text. Je možné navíc zapnout/vypnout zohledňování velkých/malých písmen. Navíc lze používat regulární výrazy.

Vložením aserce se náš test stává vyhodnotitelným. Což je znázorněno i SOAP UI. Ikona requestu testu ve stromové struktuře je od této chvíle zbarvená a to barvou, která odpovídá výsledku posledního zpracování requestu, tedy zelená pro úspěch, červená pro neúspěch.

Vložením asercí do testů vytváříme plnohodnotné testování pomocí SOAP UI. Pokud nyní spustíme TestSuite, zobrazené výsledky jednotlivých testů nám již řeknou více o jejich skutečném průběhu. A ve spojení s logem budeme přesně vědět, který test skončil s chybou a s jakou. 

Až v příštím článku přidáme použití zdroje dat, získáme reálný nástroj automatizovaného testování pro testy řízené daty.