Na konci prvej časti série článkov o automatizovanom testovaní webových aplikácií som sľúbil, že v ďalšej časti popíšem model based, data driven testovanie, scripted automation a začneme s testovaním webových aplikácií pomocou Canoo WebTest.
b. Model based testing
Model based testing je spôsob testovania aplikácie vychádzajúci z modelu, ktorý popisuje funkcionality testovaného systému SUT – system under test . Model je však len abstraktná prezentácia vlastností a správania SUT. Testovacie prípady - Test Cases - odvodené od tohto modelu sú na tej istej úrovni abstrakcie ako model. Tieto abstraktné testovacie prípady sú známe pod menom abstract test suite. Abstract test suite nemôže byť priamo vykonaná ako skutočný test nad SUT, na to je potrebný executable test suite, ktorý je odvodený od abstract test suite, a už dokáže komunikovať so SUT. Tento mechanizmus je zabezpečený mapovaním abstraktných test case na konkrétne test case, ktoré sú už schopné priamej komunikácie s SUT.
Výhodou odvodenia testov od modelu a nie od zdrojového kódu SUT – je, že model-based-testing je black-box-testing – testovanie čiernej skrinky pri ktorom test posiela do čiernej skrinky vstupné hodnoty a kontroluje tie výstupné. To tvorí základ pre vytvorenie automatického testovacieho prostredia pre testovanie webových aplikácií. Stačí ak si predstavíme model, ktorý popisuje vlastnosti SUT, konkrétne vlastnosti webovej aplikácie, čiže v jej abstraktnej forme sú to aktívne HTML prvky webovej stránky. tlačítka [buttons], vstupné polia [inputs], výberové polia [select], JavaScripty, atď. Od tohto abstraktného modelu odvodený test suit a od neho odvodený test step [executable] – ktorý už konkrétne implementuje napríklad kroky ako clickButton , alebo setInputField , alebo setSelectField . Z týchto „puzzle“- krokov je potom možné poskladať celý test case.
c. Data driven testing
Automatizované testy prehrávajú sekvencie akcií-testovacích krokov, ktoré boli zachytené nejakým rekordérom krokov, alebo naprogramované programátorom testov. Test sa vždy týka určitej oblasti aplikácie a my môžeme povedať, že ak prejde sekvencia testovacích krokov od začiatku do konca bez chyby, test je v poriadku.
Ale je to naozaj tak? Alebo môžeme povedať, že test dopadol dobre len pre dáta, ktoré boli použité pri konkrétnej testovacej sekvencii-scenára a teda pre dá ta, ktoré boli zachytené v čase nahrávania/vytvárania testovacej sekvencie. Aby sme mohli obsiahnuť väčší záber nášho testu, potrebujeme spustiť rovnakú sekvenciu testovacích krokov, ale vždy s inými dátami. Ak aj celá táto sekvencia prebehne bez chýb - potom môžme povedať s oveľa väčšou istotou, že je test v poriadku a aplikácia sa chová tak, ako očakávame. Používanie rôznych údajov na rovnaký "testovací workflow" umožňuje Data driven testing.
Data driven testing teda znamená, že testovací skript vo forme formálneho zápisu testovacích krokov za svojho behu číta dáta z externého úložiska dát [súbor, alebo databáza ] a tieto dáta používa vo forme premenných v testovacom skripte. Testovací script je potom prehľadný a táto separácia dát a funkcionality testu prispieva k celkovému sprehľadneniu testov.
Postup vykonávania data driven testu je nasledovný. Testovacie kroky sa vykonávajú v cykloch. Počet cyklov je zhodný s počtom riadkov, ktoré obsahujú testovacie data – napríklad vo forme Excellovskej tabuľky:
- Získanie dát z úložiska – jeden riadok
- Použitie získaných dát [napr.: vyplnenie formulára na webe a jeho submit na server ]
- Kontrola výsledkov – response od servera
- Pokračovanie získania dát z úložiska – ďalší riadok
Ukážka dát uložených v súbore MS Excel, použitých ako premenné v Canoo WebTest testovacom skripte:
d. Scripted automation
Scripted automation – tento spôsob opakuje rovnaké testovacie kroky, bez manuálneho zásahu človeka. J e preto vhodný na tzv. regression testing . Regression testing sa používa na odhaľovanie skrytých problémov, ktoré sa môžu vyskytnúť počas vývoja nových verzií aplikácie. Sú zamerané na odhaľovanie problémov, ktoré sa vyskytnú v súvislosti s vývojom. Jednoducho povedané, je na to, aby odhaľoval chyby aplikácie, ktoré vznikli vývojom, resp. nový vývoj pokazil niečo, čo doteraz fungovalo. Testy by sa mali vykonávať počas každého nového buildu, respektíve byť jeho súčasťou. Ak tak napríklad po celodennej práci vývojového tímu „ nezbehne” nočný proces [get-latest-version*build*test] preto, že po síce úspešnom builde aplikácie zlyhali testy, ráno nemá význam pokračovať v ďalšom vývoji, kým sa neodstránia problémy, ktoré testy odhalili.
Čo si teda vybrať?
Mnohí developeri a aj ich nadriadení sa mylne domnievajú, že automatické testy robia tú istú činnosť ako živí testeri. Musia si však uvedomiť, že automaty robia len to, čo im naprogramovali autori testov. Snaha o úplnú automatizáciu testovania však môže viesť k znásobeniu prostriedkov vynaložených na testovanie, ak vznikne snaha nahradiť ľudský faktor robotom-testerom. Automatické testy by mali hlavne pomáhať testerom a developerom pri hľadaní problémov a nesnažiť sa ich nahrádzať.
Naozaj dobrá aplikácia v skutočnosti málokedy úplne odzrkadľuje reálny proces, ktorý sa snaží automatizovať. Textový editor je predsa viac než virtuálny písací stroj a tabuľkový procesor je viac ako len virtuálna kalkulačka. Ľudia a stroje majú rôzne schopnosti pre rôzne činnosti. Automaty nemôžu myslieť a človeka-testera určite nebude baviť celú noc testovať správnosť síce veľmi dôležitých, ale nudných výpočtov. V minulosti bolo vytvorené mnoho softvéru na to, aby asistoval človeku a nie na to, aby ho nahrádzal. Rovnako to platí aj o automatizovaných testoch – nemajú sa snažiť nahradiť testerov, ale pomáhať im.
Ktorý z horeuvedených typov automatický testov by bol teda najlepší? Myslím, že odpovedať na túto otázku nebude až také ťažké. Každý jeden dokáže automatizovať testovanie a uľahčiť nám prácu. Každý z nich je vhodný na niečo iné a ich vhodná kombinácia môže zabezpečiť testovaciu infraštruktúru presne podľa našich predstáv. Dobrou správou je, že Canoo WebTest využíva všetky horeuvedené typy testovania, pričom každý si môže vybrať pre neho optimálny, alebo ich vzájomne kombinovať a tak plne využiť všetky ich samostatné výhody.
Canoo WebTest - začíname
Canoo WebTest je open source nástroj na testovanie webových aplikácií. Na na prvé zoznámenie s ním snáď postačí, že vašou úlohou bude napísanie testovacieho xml-skriptu, ako napríklad:
<project name= "demo" default= "test" >
<target name= "test" >
<webtest name= " is 'WebTest' Google's top result " >
<invoke url= "http://www.google.com/ncr"
description= "go to Google" />
<verifyTitle text= "Google" />
<setInputField name= "q" value= "WebTest" />
<clickButton label= "I'm Feeling Lucky" />
<verifyTitle text= "Canoo WebTest Homepage" />
</webtest>
</target>
</project>
... po spustení ktorého sa objaví výsledok testu - report vo forme HTML stránky:
Princípom tohto testovacieho príkladu je otestovanie vyhľadávača Google, či sa po zadaní výrazu "Webtest" a kliknutí na button "I'm feeling lucky" zobrazí ako prvá stránka, stránka projektu Canoo WebTest. Táto skutočnosť sa otestuje krokom "verifyTitle", pričom sa očakáva, že title domovskej stránky projektu obsahuje reťazec "Canoo Webtest Homepage".
Nabudúce:
- Canoo WebTest - charakteristika
- Canoo WebTest - stavebné prvky
- Canoo WebTest - inštalácia
- Canoo WebTest - prvé spustenie
