Automatizált tesztelés II.

Az előző részben az automatizált tesztelés előnyeiről és hátrányairól, valamint az autotesztkörnyezet felépítésének mikéntjéről ejtettem szót. Kitértem a fejlesztés során felmerülő problémákra, egyszerűsítési lehetőségekre, alternatívákra. E második részben a tesztkörnyezethez szükséges keretrendszer tervezéséről, a tesztek megírásáról szeretnék minél több hasznos információt megosztani az olvasóval.  

A keretrendszer  

Ha úgy döntöttünk, hogy bevezetjük a tesztek automatizálását és a tesztelendő rendszerünk elosztott rendszert alkot, akkor érdemes elgondolkozni egy keretrendszer fejlesztésén, amely lehetőséget biztosít az ilyen környezetben történő párhuzamos és problémamentes automatizált tesztfuttatásra. Magas költségekkel kell számolnunk, mivel egy ilyen rendszer megtervezése és megvalósítása akár hónapokat is igénybe vehet.   

Korábban említettem, hogy a tesztkörnyezetet egy tesztkonfiguráció manager (test CM) és egyéb teszteket végrehajtó komponensek alkotják. Mivel ezek erősen elkülönülnek egymástól, megállapíthatjuk, hogy két program elegendő a keretrendszer kialakításához, melyek megírásánál érdemes arra törekedni, hogy minél kevesebb külső programot használjon, de inkább egyet sem. Ez utóbbi azért is fontos, mert ezeket a keretrendszer felkonfigurálásánál újra és újra fel kellene telepíteni a gépekre, amely nagyszámú teszteket végrehajtó komponens esetén rengeteg időt venne igénybe.   
A test CM-en lévő program lesz felelős a tesztek végrehajtásának vezérléséért, és kliens szerepet tölt be. A könnyű kezelhetőség végett minden releváns adatot ajánlott egy külön fájlban tárolni, és nem paraméterként átadni. Érdemes a napjainkban kialakult trendek közül választani, mint például az XML, amellyel rendkívül egyszerű dolgozni. (A parse-oláshoz számos előre megírt ingyenes XML library közül válogathatunk, mely igencsak megkönnyíti a dolgunkat.) Így ez a konfigurációs XML fájl lesz, ami tartalmazza majd a test seteket, scenariókat és azokon belül is a test case-eket, így biztosítva, hogy egy konkrét „tesztcsokrot” tudjunk lefuttatni mindenféle felhasználói közbeavatkozás nélkül. Minden tesztesetnek kötelezően adjunk nevet, hogyha véletlenül a függőségek vizsgálatát is belevennénk a fejlesztésbe, tudjunk hivatkozni rájuk. Alapvető adatok még a teszteket végrehajtó komponensek elérhetőségei, mint ip és port, valamint a lefuttatandó teszt neve, ami a többi futtatáshoz szükséges fájllal együtt a test CM-en található meg.  Példa konfigurációs fájlra:

<run name=”almafa”>
            <scenario name=”test”>
                        <testcase name=”B” exec=”run/script.sh” url=”socket://127.0.0.1:1111”>
                                   <depends name=”A”/>
                                   <resource path=”run”/> 
                                   <stdout to=”out.txt”/>
                                   <stderr to=”err.log”/> 
                                   <result from=”R1”/>
                                   <result from=”R2”/>
                        </testcase>
                        <testcase name=”A” exec=”ls -l” url=”socket://127.0.0.1:1112”/> …
            </scenario>…
</run> 

Mint a példán látható, egyéb megadható opciók lehetnek még a futtatáshoz szükséges fájlok helye (resource), a logok helye és neve (stderr), melyek a test CM-en jönnek létre a futtatás során. Beállíthatóak az eredmények, azaz a tesztek által generált fájlok, illetve mappák neve is (result). Egy vagy több másik teszteset nevének megadásával beállíthatjuk a függőségeket (depends), így ezek sikeres lefutásától lesz függő a beállított teszt végrehajtásának elindulása.   

Ha a keretrendszert nem csak egy-egy teszt lefuttatására szeretnénk használni, hanem több tesztesettel, és mondjuk ugyanazon teszteket végrehajtó komponensen, akkor mindenképpen ajánlott a függőségek vizsgálatának fejlesztése. Egyéb esetben minden teszteset egyszerre fut le az adott gépen, és ez különböző problémákhoz vezethet. Ez az egyszerű, pár soros metódus a konfigurációs fájl feldolgozása után ellenőrzi, hogy az egyébként irányított gráfot alkotó tesztesetek tartalmaznak-e kört. Ha igen, még a tesztek lefuttatása előtt megszakítja a program működését, és figyelmezteti a felhasználót, hogy mely tesztesetek érintettek az ügyben. Ez azért fontos, mert az érintett tesztek kör esetén soha nem futnának le. Ezzel a funkcióval rengeteg hibát kerülhetünk el.   

Mindeközben a teszteket végrehajtó komponenseken szerverként figyel a tesztek futtatását végző program, és várja, hogy a test CM-től megkapja a végrehajtáshoz szükséges információkat, ami akkor történik meg, ha függőségi vizsgálat esetén egy irányított körmentes gráfot kaptunk. Ezután a komponensek lefuttatják a teszteket, és a stdout-ot és stderr-t folyamatosan küldik át a test CM-nek, így hiba esetén mindig tudjuk majd, hol bukott el a teszt.  

Tesztek  

A keretrendszer működése független a tesztek megírásától, minden futtatható állományt vagy parancsot elfogad tesztesetnek. Innentől egyértelmű, hogy a teszteket bármilyen programozási nyelven írhatjuk, erre semmilyen megkötés nincsen. Sőt, a programozást abszolút elkerülhetjük, ha olyan rendszert tesztelünk, melynek tesztelését le tudjuk vezényelni különböző teszteszközökkel, amennyiben azok rendelkeznek felvétel és visszajátszás funkcióval. Ekkor a tesztet lefuttatjuk manuálisan, miközben minden lépést felveszünk a speciális teszteszközzel, majd az elmentett tesztet adjuk meg a konfigurációs fájlban, így az a futtatás során minden lépést újra végrehajt majd a tesztelést végrehajtó komponenseken.   

Cikkem előző részében említettem, hogy ha nem használunk felvétel funkcióval rendelkező teszteszközöket, akkor írjuk meg úgy a teszteket, hogy minél kisebb komponensekre bontsuk fel azokat. Így nem csak a karbantartás jár alacsonyabb költségekkel, hanem sokkal tesztelőbarátabbá tehetjük az egész rendszert.  

Tesztelőbarát, de hogyan?  

Még ha a legkisebb komponenseket a fejlesztők írják is, a teszteket mindenképpen a tesztelőknek kell előállítaniuk a hatékonyság érdekében (értem ezalatt, hogy a fejlesztői fázisban ne fordulhasson elő, hogy a fejlesztőt tesztelők tartják fel tesztek megírásával kapcsolatban). Hogyan történhet meg mindez, ha tesztelőink nem rendelkeznek elegendő tapasztalattal és tudással a programozás terén? Az előző cikkemben taglalt GUI fejlesztése lehetővé teszi, hogy tesztelőink könnyedén előállíthassák a követelményeket lefedő teszteket anélkül, hogy programozniuk kellene. Ehhez mindössze arra van szükség, hogy a GUI lehetőséget biztosítson a tesztek összeállítására, méghozzá úgy, hogy a fejlesztők által már korábban megírt tesztlépéseket elég legyen csak összefűzni egyetlen tesztesetté a grafikus felületen. A GUI-n korábban kialakított tágabb jogkörrel rendelkező manager felhasználó pedig most válik igazán fontossá, mivel ő lesz az, aki jóváhagyja majd az összeállított teszteket, elkerülve ezzel a káoszt, ha a tesztelő netán nem megfelelően végezné a munkáját és rosszul összeállított tesztek futtatásába kezdene.   

A magazin előző és mostani számában megjelenő cikkeim többnyire azoknak a vállalatoknak nyújtanak hasznosabb információkat, ahol még csak mostanában jött szóba a tesztjeik automatizálása, és már a tervezést fontolgatják. Remélem, hogy e rövid cikksorozattal elértem célomat, és az érdeklődő olvasókat sikerült útbaigazítanom jövőbeli keretrendszerük felépítésével és működésével, valamint tesztjeik hatékony automatizálásával kapcsolatban.

Szerző: Horváth Nóra