SoapUI tesztkörnyezet kialakítása

Egy olyan szerviz-fejlesztési projekt tesztvezetési feladatait vállaltam, ahol az automata teszteket SoapUI-val készítik. A csatlakozás után pár hétre olyan egyszerű kérdésekre sem tudtam a választ, hogy „Hány teszteset van?”, „Mennyi teszt készült az n. sprinthez?”, „Mennyi teszt futott le az n. sprintben?”, „Melyik teszteket futtatjuk regressziós tesztnél?”. Valamilyen megoldást kellett keresni.

Azt szeretném megmutatni, milyen gyakorlati lehetőségeket vizsgáltunk meg, és találtunk a SoapUI-s tesztautomatizálás menedzseléséhez.

Gondok a SoapUI-val

Az alábbiak a SoapUI ingyenes és open-source verziójáról szólnak, de a fizetős változat sem sokkal barátságosabb ezeken a területeken.

A bevezetőben említett kérdések kétféle csoportba rendezhetők. Az egyik csoport a teszt-tervezés és teszt-készítés számait firtatja, a másik csoport a teszt-futtatás számaira kiváncsi. A SoapUI egyik kérdéskörben sem igazán segítőkész.

A SoapUIban fa strukturában épülnek fel a tesztek: Munka/Projekt/Tesztkészlet/Teszteset/Tesztlépés formában. A „Munka” fizikailag egy xml állomány, amin belül az xml szabályainak megfelelően tárolja a fa-szerkezet többi elemét. Egy „Munka” több projektet, egy Projekt több Tesztkészletet, egy Tesztkészlet több Tesztesetet és ez több Tesztlépést tartalmazhat. A SoapUI nem ad eszközt ezek számosságának a kinyerésére.

A SoapUI az előbb látott szerkezet bármelyik elemét képes futtatni. Az utolsó futás eredménye megtekinthető a felületen, de egyrész visszamenőleg nem megtekinthetők, másrészt, ha ezt az eredményt tárolni akarom (tesztjegyzőkönyv-höz), akkor külön-külön kell menteni az eredményt, a bemeneti értékeket és a válaszokat is. Ez elég sok plusz munkát igényel a tesztelőktől.

Mi történik akkor, ha csak a tesztek egy csoportját szeretném futtatni? Például regressziós teszteket, vagy csak egy adott szerviz tesztjeit. Ehhez mindenképpen valamilyen nyilvántartást kell vezetni, ahol fel vannak sorolva a szükséges tesztesetek és hogy hol találjuk meg ezeket. Ha ez kész, akkor ezzel már lehet trükközni. Erre még visszatérünk.

Hogyan oldható meg, hogy tesztjeink karbantarthatók maradjanak? Mi történik, ha több teszt által használt tesztadat, végpont, interfész, fejléc megváltozik? Mindegyikben egyesével át kell írni? A SoapUI ugyan ismeri az interfész fogalmát és a globális változókat, de ezeket csak munkameneten belül kezeli. Több ezer tesztet nem hasznos egy munkameneten (xml állományon) belül tartani.

Hogyan lehet a SoapuUI-s teszteket könnyen csoportosítani? Például szervízenként, tesztadatonként, végpontonként vagy az alapján, hogy melyeket futtassuk regresszióban. Bár szervezhetem mappákba a munkaállományokat, de ez nem elégséges minden csoportosításhoz.

Hogyan készítsünk tesztforgatókönyvet, ami nemcsak a teszteket tartalmazza felsorolva, hanem azt is, hogy melyik teszt mit csinál és mit ellenőriz? Erre kézenfekvő valamilyen táblázatok létrehozása és karbantartása, de ez oda vezet, hogy az adminisztráció egy idő után túl sok erőforrást von el.

Hogyan kezeljük a tesztesetek munkafolyamatát, munkafolyamat állapotait? Ilyesmikre gondolok: hibás teszteset, fejlesztés alatt álló teszteset, elévült teszteset…

Egy másik problémaforrás a verziókövetés. Ez tesztautomatizálásnál általános gond. A probléma az, hogy a teszteknek tudniuk kell, hogy milyen programverziót tesztelnek. Például lehetséges, hogy az éles környezetben lévő verziónak a hibajelensége a belső, fejlesztői környezeten már nem reprodukálható. A fejlesztők verziókezelőt használnak a verziók nyomonkövetésére. Ezt a módszert a tesztautomatizálásnál is érdemes használni.

Ötletelés

Sok ötlet felmerült a gondok megoldására. Ezek az ötletek mind működőképesnek tünnek, általában a felmerült költségek miatt nem valósultak meg. Talán egy olyan projektnél, ahol előre kalkulálnak ezekkel a költségekkel, akár jobb megoldást is adhatnak, mint amit végül sikerült megvalósítanunk. Volt egy fontos kritérium: minden információ házon belül kell, hogy maradjon, ezért más cég által biztosított felhős megoldás szóba sem jöhetett.

1. Profi, megvásárolható, támogatott megoldás. Pl.: HP (Microfocus) UFT és HP ALM, ahol az UFT-ben lehet írni API teszteket és az ALM-mel lehet nyilvántartani a tesztadatokat, teszteseteket, teszt futtatásokat és teszteredményeket.
2. Saját eszköz készítése. Valójában ez nem lehetetlen vállalkozás. Egy megfelelő eszköz a tervezéstől a késztermékig, egy néhány fős csapattal 2-3 hónap alatt elkészíthető. Nem fog annyit tudni, mint a „nagyok”, de projekt-célszerszámként tökéletes lehet.
3. Meglévő eszközhöz saját kiegészítő gyártása. Esetünkben a SoapUI-hoz lehetne tervezni és fejleszteni egy nyilvántartó és futtató környezetet. Egy ilyen eszköz (szerintünk) 1 hónap alatt lefejleszthető lenne egy néhány fős csapattal. Csodálkozom is, hogy nem láttam, nem olvastam még ilyenről.
4. Létező eszközök megfelelő összekötése, beállítása a SoapUI-al, hogy elérjük a kívánt célt.

Az utolsó ötletet valósítottuk meg. A megfelelő eszközök: BaseX, Jenkins és ennek két pluginja Junit és a Test Results Analyzer, GIT és Oracle adatbázis. Az Oracle kivételével minden eszköz ingyenes és open source termék. Az Oracle eleve rendelkezésre állt (használhattunk volna e helyett is open source megoldást.)

A megvalósítás elemei

GIT verziókezelő

Azért a GIT-et választottuk, mert a projekten a fejlesztők GIT-et használtak. GIT repoban való tárolással megoldhatók a verziókezelés problémái, ha a tárolt teszteket ugyanúgy verziózzuk, mint a fejlesztők a kódjukat. Sajnos a GIT másik előnyét, hogy egy állománnyal egyszerre többen is tudjanak dolgozni, nem tudjuk kihasználni. XML-ek egyesítése sajnos nem egy üzembiztos lépés. Meg kell oldani, hogy a tesztelők diszjunkt munkákkal foglalkozzanak egyidőben.

BaseX

A BaseX egy open source, XML (noSQL) adatbázismotor és XQuery 3.1 feldolgozó. A BaseX RESTful felületet is biztosít az adatokhoz való hozzáféréshez. Számunkra a BaseX a tesztek nyilvántartásához és a tesztfutások eredményének a kiértékeléséhez biztosít megoldásokat.

Az összes SoapUI munka-xml állomány beolvasható egy BaseX adatbázisba (pár másodperc alatt). A cikk elején lévő, tesztesetekre vonatkozó kérdéseket, XQuery lekérdezésként megfogalmazva megkaphatjuk a válaszokat. Ugyanez elvégezhető, a futási eredményként kapott Junit formátumú xml-eken is, megkapva a szükséges riportokat, futási logokat.

A saját gyakorlatunk itt az lett, hogy az XQuery lekérdezések CSV állományokat hoznak létre, amiket táblázatkezelő segítségével az ügyfél által könnyen áttekinthető formára alakítunk.

Jenkins

A Jenkins-el valósítják meg nálunk a fejlesztők a CI folyamatokat (code review, unit test, build, smoke test). Első gondolatom az volt, hogy ha a tesztelők kapnak egy tesztfuttató Job-ot, akkor legalább az eredmények meglesznek visszamenőleg. Később rájöttünk, hogy a Jenkins segítségével kényelmesebbé tehetjük a napi munkát, ha rábízunk néhány olyan feladatot, amit amúgy is megcsinálunk mindig.

A Jenkinssel való tesztfuttatás menete, hogy a futtatni kívánt esetekből készítünk egy listát (CSV állományt) a BaseX-el. A SopaUI-nak van egy parancssori tesztfuttatója: TestRunner. A Jenkins job a CSV összes rekordját paraméterként a TestRunner parancsnak adja, így az összes szükséges tesztet futtatja.

A Jenkins Junit és Test Results Analyzer pluginjainak a segítségével a kapott eredményt táblázatos formában is meg tudjuk tekinteni és el tudjuk menteni.

Innen még-egy lépés és a Jenkinsel nagyrészt automatizálható a folyamat. Előre megírt Xquery lekérdezésekkel, megfelelő paraméterezéssel a Jenkins el tudja készíteni a BaseX adatbázist, elő tudja állítani a futtatásra kijelölt esetek listáját, végrehajtja a futtatást, az eredményből ismét készít egy BaseX adatbázist, majd ebből előállítja a kívánt riport CSV állományokat. A regressziós tesztfuttatás ezzel a módszerrel teljesen automatizálható.

Oracle adatbázis

A lényeg, hogy ez egy relációs adatbázis, nem fontos, hogy Oracle legyen. Nálunk ez volt kéznél.

Bármilyen tesztautomatizálásnál kulcskérdés a karbantarthatóság. Úgy kell szervezni a teszteket, hogy ha módosítani kell valamit, azt ne sok-sok teszten kelljen végrehajtani, hanem lehetőleg csak egy helyen. Érdemes a tesztadatokat és a környezeti konfigurációs beállításokat adatbázisba szervezni. Ha a tesztek innen olvassák be ezeket az értékeket és módosítani kell, akkor elég csak az adatbázisban módosítani.

Tesztautomatizálásnál arra is jó egy ilyen relációs adatbázis, hogy a tesztek át tudjanak adni egymásnak tesztadatot.

A SoapUI képes csatlakozni (JDBC-n) relációs adatbázisokhoz, így fentiek könnyen megvalósíthatók.

SoapUI

Ahhoz, hogy a többi eszközzel a legjobb legyen az együttműködés, a tesztesetekkel szemben vannak formai és tartalmi elvárások:

• A project, test suit és test case elnevezés „összeolvasva” egyértelműen egy szerviz szolgáltatásának egy teszt-módjára kell, hogy utaljon. (A tesztlépésekre nincs ilyen elvárás meghatározva.)
• A project, test suit és test case elnevezésének a kezdete mindenhol egy azonosító. Ha egy project-ben szereplő, test suitban szereplő, test case azonosítóit egybeírom, annak egyértelműen egyetlen tesztesetet kell azonosítania. (Tehát például lehet két tesztesetnek azonos azonosítója, ha más test suitban vagy más projectben vannak.)
• A tesztesetek description részét tölteni kell, le kell írni benne magyarul, mit tesztel a teszteset. Ez bekerül (Xquery-s lekérdezés segítségével) a tesztforgatókönyvbe.
• Az assertions neveinek egyértelműen utalni kell rá, hogy mit ellenőriznek pontosan. Ez is bekerül a tesztforgatókönyvbe.
• Az elnevezésekben nem lehet olyan karakter, amit nem lehet állománynévként használni. (Ez azért fontos, mert a riport állományok nevei megegyeznek a SoupUI-on belüli elnevezésekkel.)
• A tesztesetek property részében eltárolunk néhány információt, ami alapján a teszteset csoportosítható. Ilyen információk: Jira story azonosító, regressziós eset, javításra váró eset, még nem elkészült eset, nem futtatható eset. Ezekre a property-kre az XQuery-s lekérdezésekben lehet szűrőfeltételeket megadni
• Tesztesetet nem törlünk ki. (Inaktívra állítjuk, ha már nincs rá szükség.)

Tippek és trükkök

Egyszerűbb más hibájából tanulni, ezért megosztok néhány gyakorlati tanácsot, amibe mi belefutottunk, miközben kialakítottuk a tesztkörnyezetet.

Bár a BaseX – Xquery segítségével van lehetőség az XML adatbázis módosítására és ebből a módosított adatbázisból ki lehet írni az XML állományokat, de az így előállított XML-eket a SoapUI nem fogja tudni kezelni. Sajnos, ha sok tesztesetben kell átírni valamit, akkor ily módon nem tudunk spórolni a munkán.

A Jenkins-es futtatánál ügyelni kell arra, hogy minden egyes eredmény külön mappába kerüljön. Nálunk ezt úgy oldottuk meg, hogy a fő mappa a build neve, az almappák a project_testsuit_testcase azonosítók. A másik megoldás (ezen éppen dolgozunk), hogy az eredményeket egy BaseX adatbázisba írjuk, ne állományokba.

A BaseX-et nemcsak webszerverként, hanem lokálisan is érdemes a tesztelők gépére telepíteni, mert az asztali IDE kényelmesebb, mint a webes felület.

A JDBC driver telepítéséhez, rendszergazdai jog kell, vagy a SoapUI portable változata.

Összefoglaló

A SoapUI egy remek eszköz API tesztek készítésére és futtatására, viszont a tesztek és tesztfuttatások menedzselése nem megoldható benne. Nekünk néhány ingyenes, open source termék használatával sikerült kialakítanunk egy számunkra elfogadható tesztelési környezetet. Szívesen olvasnék ebben a témában egyéb ötletek is. Ha van ilyened, oszd meg velünk!