BlogCanoo WebTest: testovanie webových aplikácií - 1. Úvod

Canoo WebTest: testovanie webových aplikácií – 1. Ú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 desať 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 praktický seriál 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.

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.

Dobrý článok? Chceš dostávať ďalšie?

Už viac ako 6 200 ITečkárov dostáva správy e-mailom. Nemusíš sa báť, nie každé ráno. Len občasne.

Súhlasím so spracovaním mojich osobných údajov. ( Viac informácií. )

Tvoj email neposkytneme 3tím stranám. Posielame naňho len informácie z robime.it. Kedykoľvek sa môžeš odhlásiť.

Roman Hesteric
Roman Hesterichttp://www.priklady.eu
Pracuje ako QA Architekt v Swiss Re. Predtým CTO pre Java a .Net aplikácie. Autorizovaný spolupracovník na projekte Canoo Webtest. Držiteľ certifikátov MCTS a MCPD pre SharePoint server. V IT pracuje 25 rokov, od starého dobrého Turbo Pascalu od Borlandu, cez Javu, až po C#. Administrátor matematického portálu www.priklady.eu

Čítaj ďalej: