Úvod
Vývoj softvéru vždy bol a je komplexný proces. Ako rastie zložitosť softvérového riešenia, spolu s ním rastú aj nároky na overovanie jeho funkčnosti a správnosti použitých algoritmov. Pre optimálnu organizáciu a maximálnu efektivitu vývoja dnešných a zajtrajších aplikácií potrebujú softvéroví developeri automatizovanú infraštruktúru, ktorá im pomôže a unifikuje ich úsilie o to, aby bol dodaný produkt u zákazníka bezchybný. Takáto infraštruktúra - automatické testovacie prostredie má slúžiť ľudom, ktorí stoja pri analýze požiadaviek zákazníka, ľudom, ktorí robia vývoj aplikácie, ľudom zodpovedným za kvalitu. Zákazník okrem toho, že získava dobre otestovanú aplikáciu získava aj nástroj na vlastné testy, ktoré sú špecifické v jeho prostredí, naviac s jeho vlastnými požiadavkami.
Takéto automatické testovacie prostredie by malo poskytovať všetkým zúčastneným stranám objektívny nástroj na „meranie správnosti" riešenia a rýchlu odpoveď na otázku, či sa vyvíjaný projekt uberá správnou cestou. Jeho výstupom by mal byt všetkým zrozumiteľný dokument, ktorý jasne ukazuje čo funguje, čo nefunguje a pri problémoch umožní vystopovať ich príčiny.
Každá testovacia infraštruktúra by mala byt postavená na ľudskej inteligencii. Ľudská inteligencia je základom pri vytváraní zložitého popisu nejakej činnosti a teda aj činnosti, ktorej úlohou je otestovanie systému. Na druhej strane, všetko čo môže byt automatizované by aj automatizované byť malo, aby ostal čas pre ľudskú inteligenciu, ktorá sa nebude musieť zapodievať opakujúcimi sa nekreatívnymi úlohami - tými nech sa zaoberá „automat".
V úvode je treba povedať, že tento text si nekladie za cieľ poskytnúť plnohodnotný návod na vytvorenie testovacieho prostredia pre tím programátorov a testerov. Cieľom tohto textu je podeliť sa so skúsenosťami z testovania webových aplikácií, ktoré som získal za posledných šesť rokov mojej práce spojenej aj s „pre-release" testami, ktoré sa v mojej praxi vykonávali. Testy na funkčnosť sa robili vždy pred odovzdávaním novej verzie aplikácie do produkčného prostredia u zákazníka. V roku 2002 som sa prvý krát stretol s open-source nástrojom, umožňujúcim takéto testy - Canoo WebTest a odvtedy som sa stal jeho nadšeným používateľom a propagátorom. Bude to teda text hlavne o tomto open-source projekte a mojich skúsenostiach s ním.
Prečo testovať a prečo automatizovať testovanie
Testovanie je kľúčom k lepšej kvalite aplikácie. Manuálna kontrola je flexibilnejšia a najmenej nákladná ak sa vykoná len raz. Náklady na vývoj začnú rapídne narastať ak vznikne potreba opakovať rovnaké testy znova a znova.
Z môjho pohľadu, pohľadu vývojára, je testovanie dôležité, pretože potrebujem validovať svoju prácu. Potrebujem podporu na to, aby som mohol po dokončení svojej práce neskromne povedať: „Áno, je to naprogramované správne. Funguje to. Je to hotové." , alebo aj „Nie, novou verziou sme nepokazili nič, čo doteraz fungovalo" . Na takéto silné vyhlásenia vývojára je však potrebné mať 100%-tnú istotu, že je to pravda. Najmä na vyhlásenia typu, že všetko čo doteraz fungovalo ostalo rovnako funkčné aj po mojich zásahoch v kódoch aplikácie. Na overenie takéhoto vyhlásenia je preto potrebné testom prejsť tie aplikačné časti, ktorých sa týkali moje zmeny kódu. A takáto požiadavka môže byť sama o sebe veľmi zložitá ak vezmeme do úvahy, že dnešné aplikácie sú svojim rozsahom obrovské a už len predstava o pretestovaní ich kritických častí nám naháňa zimomriavky. Ak sa naviac na vývoji aplikácie podieľa celý tím vývojárov, je pri každom ukončenom vývoji požiadavka na komplexný test aplikácie priam nutná. Presne tento scenár životného cyklu vývoja - ukončený testom aplikácie pred jej nasadením je dobrou pohnútkou na vytvorenie automatizovanej testovacej infraštruktúry, ktorú som spomínal v úvode.
Počas normálneho vývoja aplikácie by sa na jej testovanie malo poskytnúť viac ako 60% z celkového času vývoja. Z uvedeného vyplýva, že pri zvyšovaní zložitosti aplikácie rastú čas a náklady na vývoj, pričom bez použitia automatizovanej testovacej infraštruktúry sa výrazne predlžuje čas dodania hotového riešenia.
Testovanie je stále sa opakujúce a z pohľadu človeka nudné. A to je jeden z ďalších dobrých dôvodov, prečo testovanie automatizovať a využiť jeho repetitívnosť v náš prospech. Inými slovami - raz vytvor testovací scenár - ten použi n-krát počas vývoja - sleduj ako aplikácia plní/neplní požiadavky analýzy.
Štyri vzory testovania – stavebné kamene automatizovaného testovania
V nasledujúcich podkapitolách uvediem štyri vzory testovania. Každý z nich môže samostatne zastrešiť určité potreby praxe. Každá z nich má však svoje plusy a mínusy, ale, ako to už býva, najlepším riešením je kombinácia všetkých štyroch.
a. Capture/replay
Capture/replay [zachyť/prehraj] - je najlacnejší spôsob využitia automatizovaných testov, resp. vytvorenia automatizovanej testovacej infraštruktúry. V súčasnosti existuje mnoho riešení pre rôzne internetové prehliadače v podobe open-source, alebo freeware. Príkladom veľmi pekného Capture/replay nástroja je TestGen4Web - ako plugin, alebo extension do internetového prehliadača Mozilla FireFox.
Ukážky z TestGen4Web projektu :
Pri tomto spôsobe vytvárania testovacieho prípadu - Test Case, Test Scenario [testovacia sekvencia], plug-in v internetovom prehliadači zachytáva klikanie a vypĺňanie formulárov vo webovej aplikácii. Postupnosť krokov - test case - sa zapíše do xml súboru, ktorý slúži ako vstupný súbor pri opakovaní testu.
Týmto spôsobom dokážeme vytvoriť za krátku dobu veľa testovacích scenárov, ktoré sa dajú používať na rýchle pretestovanie aplikácie. Nevýhodou tohto spôsobu vytvorenia testovacej infraštruktúry je to, že údržba takto vytvorených test case je značne náročná a pri zmenách dizajnu aplikácie takmer vždy nutná. Výsledky testov sa zisťujú vizuálne [Play done with *no* errors].
Veľmi dobre sa v mojej vývojárskej práci osvedčil tento plug-in ako „navigátor“ na určité miesto v aplikácii, kde bolo potrebné otestovať nejakú zmenu, alebo ak som sa rýchlo potreboval dostať na vytúžený „break-point“, ktorý sa aktivoval až po vyplnení niekoľko desiatok vstupných údajov a prekliknutí v aplikácii. Vytváral som množstvá test scenárov, ktoré sa líšili obsahom a každý z nich ma navigoval na iné, špecifické miesto v aplikácii, na ktoré som sa potom nemusel pracne „preklikávať“ znova a znova.
Ukážka xml súboru s testovacími krokmi projektu TestGen4Web:
Použitie systému „Capture/replay“ je na prvý pohľad veľmi výhodné. Existuje veľa free nástrojov, ktoré nám umožňujú ľahko zachytávať a ukladať testovacie sekvencie. Údržba takto vytvorených testov však vyžaduje veľké úsilie a nie je jednoduchá. Preto použivanie týchto zdanlivo jednoduchých riešení vyžaduje ich cielené a premyslené a nie masové použitie.
Ďalšou výbornou možnosťou vo forme pluginu pre browser Mozilla FireFox je open-source projekt Selenium. Plug-in Selenium je testovací nástroj pre webové aplikácie. Testy sa spúšťajú priamo v internetovom prehliadači, presne ako by to robil používateľ webu. Umožňuje uloženie testovacích krokov do súboru na jeho opätovné spúšťanie.
Ukážka z open-source projektu Selenium [recorder testovacích krokov]:
Ukážka z open-source projektu Selenium [rôzne spôsoby interpretácie testovacích krokov]:
Významnou časťou projektu Selenium je Selenium Remote Control (RC). Je to testovacia nadstavba, pomocou ktorej je možné písanie automatických web-testov v programovacích jazykoch ako Java, PHP, Python, Perl, .NET.
Selenium RC sa skladá z dvoch častí.
- Server, ktorý spúšťa a ukončuje podporované browsre a poskytuje HTTP proxy pre requesty z týchto browserov
- Klientské knižnice s testerom preferovaným programovacím jazykom [samotný plugin umožňuje ukladanie nahrávaných testovacích krokov do syntaxe preferovaného jazyka]
Autor pracuje ako developer vo firme www.together.sk
Nabudúce:
- Model based testovanie
- Data driven testovanie
- Scripted automation
- Canoo WebTest - začíname
