Webes tesztelés modell alapon

A webes applikációk tesztelésével több probléma van. Ezeken a felületeken a felhasználó eseményeket hoz létre, pl. gombokra kattint, szövegmezőket tölt ki a billentyűzet segítségével, szöveget jelöl ki, vágólapra másol, majd beilleszt, sőt, gondoljunk a Gmail-re, drag-and-drop funkciót is használhat. Ezekkel az eseményekkel egy baj van, túl sok van belőlük. Minél több eseményünk van, annál több sorrendiség létezik, így a lehetséges tesztesetek száma exponenciálisan növekszik.

Az előző számban „A modell alapú tesztelésről” című cikkben már láttuk, mire jó ez a tesztelési megközelítés. Folytassuk most az ottani gondolatmenetünket, és nézzük meg, hogyan tudjuk ezt weboldalak funkcionális tesztelésére használni!

Egy kis ismétlés

Dióhéjban a modell alapú tesztelésről annyit, hogy a tesztelendő rendszerünkről (legyen az jelenesetben egy webes applikáció) készítünk egy modellt, ami a program viselkedését ábrázolja. Ezt a modellt felhasználjuk arra, hogy automatikusan generáljunk futtatható teszteseteket. A modell lehet egy gráf (véges állapotautomata), döntési táblázat, de tulajdonképpen bármi, ami szemléltetni tudja a rendszer működését és lehet belőle teszteseteket generálni (legutóbb említettünk még nyelvtanokat és a Markov-láncokat is). Ettől jobban nem szeretném most részletezni a megközelítést, aki többet szeretne olvasni róla, ne legyen rest, kapja elő az előző szám cikkét, és vessen egy pillantást az első három bekezdésre. A továbbiakban látni fogjuk, hogyan segíthet nekünk az MBT egy weboldal tesztelésében.

Miért éppen web?

A webes applikációk tesztelésével több probléma van. Ugyanazokkal a problémákkal szembesülünk, mint egy GUI program tesztelésénél. Ezeken a felületeken a felhasználó eseményeket hoz létre. Pl. gombokra kattint, szövegmezőket tölt ki a billentyűzet segítségével, szöveget jelöl ki, vágólapra másol, majd beilleszt, sőt gondoljunk a Gmail-re, drag-and-drop funkciót is használhat. Ezekkel az eseményekkel egy baj van, túl sok van belőlük. Már egy kisebb programnál vagy weblapnál is rengeteget tudunk megkülönböztetni. Az eventek sorrendje meghatározhat egy tesztesetet, ami elvezet minket egy elvárt vagy egy kevésbé elvárt eredményhez. Minél több eseményünk van, annál több sorrendiség létezik, így a lehetséges tesztesetek száma exponenciálisan növekszik. De érdemes-e ezeket a kombinációkat tesztelni?

Motiváció

Ha a kedves olvasó Windows XP alatt dolgozik, próbálja ki a következőt: nyissa meg a Paint-et, majd rajzoljon bele valamit. Megteszi egy pár fekete vonal a fehér háttéren. Ezek után hozzunk létre egy kijelölést a Select gombbal és mozdítsuk el a kijelölt területet. Lehetőleg a fekete vonalainkból jelöljünk ki valamit, majd látni fogjuk, hogy nyomva tartott egérgombbal át tudjuk helyezni a kijelölt területet. Fűszerezzük meg ezt a feature-t egy másik eseménnyel, tartsuk nyomva az áthelyezés alatt a SHIFT gombot. Máris 3D-ben rajzolunk! Ekkor ugyanis a Paint nem frissíti a rajzterületet. Egy jól ismert hibát csalogattunk most elő, nagyon egyszerű események kombinációjával. (1. ábra)

Ha már előttünk az XP, lássunk egy másik hibát. Nyissuk meg a Computer Management programot, megtehetjük pl. úgy, hogy jobb egérgombbal kattintunk a My Computer-re, majd Manage. Itt is kattintsunk jobb egérgombbal a Computer Managment-re (local) a baloldalon, a fastruktúra legtetején, majd válasszuk ki a „Connect to another computer…” opciót. A felbukkanó ablakban válasszuk az „Another computer”-t, majd írjunk be olyan hosszú karaktersorozatot, amennyit csak enged a szövegmező! Kattintsunk az OK gombra. Természetesen egy nem létező számítógéphez akartunk kapcsolódni, ezért hibaüzenet fogad minket helyesen. Nyomjunk meg az OK gombot a hibaüzenetnél, majd vegyük észre, hogy a baloldalon a fastruktúrában egyetlen ikon van, az iménti nem létező gép nevével. Kattintsunk jobb egérgombbal és nézzük meg a tulajdonságait (Properties). Ekkor a program összeomlik. (2. ábra)

Az utóbbi példa Atif M. Memontól a Marylandi egyetem professzorától származik, aki egyik előadásában ( http://www.youtube.com/watch?v=6LdsIVvxISU ) említ egy webes hibát is. Egy amerikai légitársaság honlapján, ha a felhasználó bejelentkezett, majd közvetlen kijelentkezni próbált, azonnal egy „HTTP Error 500 Internal server error” hibával találta szembe magát, ha bármilyen más műveletet hajtott végre a kijelentkezés előtt és utána próbált meg kijelentkezni, ezzel a hibával nem találkozott.

Az MBT közbeszól

A fenti hibák mindegyike egy eseménysor hatására jött létre, amit a tesztelők figyelmen kívül hagytak. Nem is csoda, hiszen már egyszerű alkalmazásnál is szinte lehetetlen mindent kipróbálni, annyi esemény van benne. De akkor mégis tesztelőként, hogyan tudunk ilyen típusú hibákat találni?

Az egyik lehetséges mód a manuális tesztelés. Nem ritkán diákokat vagy szakembereket ültetünk a weboldal elé, majd kézzel végig kattintják azt, jobb esetben valamilyen követelmény-leírás alapján. Ezt a módszert nem kell tovább taglalnom. Rengeteg esetben elkerülhetetlen, sőt, vannak olyan esetek, amikor csak és kizárólag manuálisan lehet tesztelni, gondoljunk pl. egy weboldalon lévő captchára ( http://hu.wikipedia.org/wiki/Captcha ). A kézzel való teszteléssel több baj van, ezek általános hátrányok, nem csak a webes tesztelésre igazak. Az egyik legnagyobb baj, hogy a tesztesetek nem használhatók fel újra. Ha ismét tesztelni akarunk, újra és újra végig kell kattintanunk az esetet. Vegyük még figyelembe, hogy a verifikálás is „csak” szemmel megy, azaz elképzelhető, hogy a tesztelő egyszerűen nem veszi észre a hibát. Ráadásul szinte biztosan csak a legáltalánosabb esetekre születnek tesztek, sok esetben kizárólag a sikeres felhasználói tesztesetek készülnek el. Tipikusan kevés számú eset áll rendelkezésre, így minimalizálódik annak az esélye, hogy a fentiekhez hasonló hibákat fedezünk fel manuálisan.

De akkor hogyan? Próbáljunk a fenti hátrányokra megoldást találni. Az egyik út a Capture/Replay eszközök használata. Ezek az eszközök képesek a felhasználói interakcióinkat elkapni, majd eltárolni, később pedig újrajátszani. Ezzel máris megoldódott az újrafelhasználási problémánk, sőt, verifikálni is képesek, azaz még egy kérdést kipipálhatunk. Ilyen eszköz pl. a Selenium, amelyről most is szó lesz. A Selenium egy ingyenes, nyílt forráskódú szoftver, amely akár közvetlenül a Firefox-ba beépülve tudja elkapni a felhasználói interakciókat. Ezek után nem csak visszajátszani tudja a tesztlépéseket, hanem exportálni is többféle programnyelven! Ez azért fontos, mivel innentől kezdve nagyobb szabadság van a kezünkben, mert különböző programnyelvek eszközeivel írhatunk teszteseteket.

A futtatás a következőképpen alakul: létezik egy Selenium Remote Control névre hallgató szerver folyamat, ami azért felelős, hogy fogadja a tesztesetünktől érkező kéréseket. Ilyen kérések pl. egy gombra való kattintás, szövegbevitel, várakozás egy bizonyos ideig, egyszóval a tesztlépéseink. Majd ezeket a lépéseket továbbítja a megadott böngészőnek, ami sorba végrehajtja azokat. Így tudjuk automatikusan a már felvett tesztjeinket lefuttatni. (3. ábra)

A Selenium és a Graphwalker

Előző cikkemben az MBT eszköz a Graphwalker (http://graphwalker.org/) volt. A Graphwalker képes arra, hogy egy inputként megadott modellt (graphml formátumú véges gráfot) bejárjon és a megadott csomópontokban (állapotokban) egy bizonyos műveletet végezzen. Azaz, ha építünk egy végesállapot automatát (jelen esetben egy gráfot) a programunk viselkedéséről, akkor a Graphwalker egy-egy tesztesetet jár végig a gráfban. Nincs más dolgunk, mint összekötni a gráf pontjait, éleit egy-egy Java-ban implementált függvénnyel, ami a tesztlépéseket reprezentálja. Webes tesztelésnél ezt úgy hasznosíthatjuk, hogy az egyes függvényekbe a Selenium által generált lépéseket építjük be, pl. az első állapot egy webshopot ábrázoló gráfban lehet a bejelentkező képernyő, az állapotátmenet lehet a „Login” gombbal való bejelentkezés, a következő állapot pedig az üdvözlő képernyő.

Nézzük élesben

Legutóbb egy valós példát is néztünk, tegyük ezt most is! A célrendszerünk legyen az OpenCart, egy ingyenes webshop demo oldala (http://demo.opencart.com/). Rakjunk össze egy modellt (pl. az előző számban emlegetett yEddel), ami mindössze annyit reprezentál, hogy be tudunk jelentkezni, ki tudunk valamit választani, kosárba rakni, megvenni, majd ki is tudunk jelentkezni. Helyezzük a hangsúlyt a kijelentkezés tesztelésére. A modell a mellékelt ábrán látható. (4. ábra)

A weblap modelljén jól látható, hogy minden állapotból (kivéve a Startból) ki tudunk jelentkezni (a „Logout” gomb mindig látható az oldalon és rá tudunk kattintani, ha már bejelentkeztünk). A modell természetesen nem teljes, a kijelentkezéssel kapcsolatos átmenetekre koncentrálunk. Járjuk be a gráfot a Graphwalker-rel!

Ha azt állítjuk be, hogy minden élt vagy pontot érintsen, akkor garantáltan minden utat le tudunk tesztelni a gráfban. Vagyis olyan események sorrendjét is, amit más tesztelési módszerekkel nehezen.

Figyeljük meg, hogy pl. a bejelentkezés utáni közvetlen kijelentkezés is tesztelve lesz. Egyébként azt is választhatjuk, hogy véletlenszerűen járjuk be a modellt, össze-vissza bolyongva egy megadott ideig. Ezeknek a paramétereknek a variálásával növelhetjük a lefedettséget. Ha egy ilyen modellt összeállítunk, nincs más dolgunk, mint rögzíteni a tesztlépéseket a Selenium IDE-vel Firefox-ba. Így tudhatjuk meg, hogy hogyan mondjuk meg a Selenium RC-nek, hogy pl. hogyan „kattintson” rá a „Login” gombra. Ez egy olyan beépülő modul, amellyel rögzíteni tudunk közvetlen a Firefox-ból, és ki tudjuk exportálni Javába a tesztlépéseket. A megfelelő utasításokat bemásoljuk a Graphwalker által végrehajtott Java forrásba. Ezt a forrást az előző cikkben leírtak alapján lefordítjuk, majd a Graphwalker-t elindítjuk parancssorból. Így kapunk teljesen automatizált teszteseteket. Az eseménysorrendek előállításáért a Graphwalker felel, a webes alkalmazás irányítását a Selenium végzi. Ha egy elég komplex gráfot építünk (még átlátható eseményhalmaz, de sok átmenet), kellően „sok” állapottal, akkor a véletlenszerű bejárás során olyan hibákat találhatunk amilyeneket a cikk elején említettünk. A véletlen bejárásnak azért van jelentősége, mert ha azt választjuk, hogy minden élt vagy pontot érintsünk, akkor egy előre meghatározott algoritmus alapján mindig ugyanazokat az eseménysorokat fogjuk visszakapni (jóllehet ezzel is foghatunk hibákat), míg a véletlen bejárás mindig újabb és újabb utakat, eseménysorrendeket generál.

Vannak még kihívások

A fenti technika jól használható, ha nem túl bonyolult a weblapunk (relatív kevés esemény), ill. ha megfelelően implementált tesztlépéseink vannak. Már az OpenCart-nál is rengeteg funkciónk/eseményünk létezik. Ha mindent bele akarunk építeni egy modellbe, akkor bonyolult és átláthatatlanná válik. Ilyenkor érdemes funkciók szerint több modellt építeni.

Szót kell ejteni a Selenium kevésbé előnyös képességeiről is. Aki ismeri, az tudja, hogy ha rögzítünk vele valamit, sokszor visszajátszani sem tudjuk a Firefoxból. Ha kívülről Selenium RC-n keresztül próbálkozunk, akkor további nehézségekbe ütközünk. Egyszóval a kiexportált kódok után nagyon sokat kell még „kézzel” igazítani. Itt meg kell jegyeznem, hogy sok kereskedelmi szoftver lényegesen jobb ebben.

Szintén a Selenium számlájára írhatjuk a hordozhatóság problémáját, egyáltalán nem biztos, hogy ami Firefox-on futtatható teszt, az Chrome alatt is az.
További problémák még a váratlan események, pl. előfordulhat, hogy le kell kezelnünk a hirtelen felugró pop-up ablakokat stb.
Aztán felmerül még több elméleti kérdés is. Mekkora modellt kell építenünk? Bele kell vennünk az összes létező eseményt? Ha igen, az összes sorrendet le kell tesztelnünk? Minden esetben tudunk verifikálni? Egyszóval sok kérdés kering még a GUI és a webes felületű tesztelések körül egyaránt. Valamint fejlődniük kell még a tesztelési módszertanoknak és az eszközöknek is.

Végezetül

Azt bátran állíthatom, hogy weboldalak manuális tesztelésénél eredményesebb a fenti technika. A kezdeti nehézségek után (sok konfigurálás, kódjavítás) egy megbízható modellel sokat lehet nyerni. Mindenkinek ajánlom, hogy próbálja meg alkalmazni a modell alapú tesztelést weboldalak tesztelésére is, sok esetben megéri.

Szerző: Tóth Árpád