Szervizbusz tesztelés

Az ügyfél egy olyan nagy cég, ahol évek óra használnak SOA architektúrát, és a SOA szolgáltatásokat a kliens alkalmazások szerviz buszon keresztül veszik igénybe. A szolgáltatások fejlesztése az évek során különböző fejlesztési környezetben történt, és ennek megfelelően különböző teszt, és dokumentációs környezet áll rendelkezésre a különböző szolgáltatásokhoz.

A különböző szoftverek fejlődése, valamint nagy cégek tulajdonos szerkezeteinek változása nyomán az eddig használt middle-ware (szerviz busz) alkalmazást ki kell cserélni. A tesztelés feladata az ellenőrizni, hogy az új szerviz busz éppen olyan jól működik, mint a régi.

Az ideális megoldás SOA rendszerek tesztelésére, az ha a teszt környezetben megfelelő teszt adatokkal, már az új infrastrukturális elemekkel minden szolgáltatást letesztelünk. Ez azonban több ok miatt sem megoldható.

Nincsen minden szolgáltatásra pontos dokumentáció, hogy mit is kell csinálnia a szolgáltatásnak. Nincs leírás, és nincsenek részletes, és minden lefutási ágra kiterjedő teszt esetek. A szervizek dokumentálására soapUI tesztek vannak, amelyek hol egyszerűek (egy szolgáltatás meghívása, és néhány ellenőrzés), hol összetettek (egymás utáni szerviz hívások, amelyek lefutása függ az előző hívás eredményétől, elágazások, ciklusok soapUI-ban megvalósítva).

A javasolt megoldás olyan tesztek kialakítása, amelyek minél egyszerűbbek, és amelyek lefutása összehasonlítható a régi és az új rendszeren.

A régi és az új rendszer nem tud egyszerre futni, és nem tesztelhető egyszerre egy szolgáltatás a régi és az új rendszeren. Nem csak azért, mert a régi szerviz busz és az új szerviz busz ugyanazokat a portokat és ip címeket használja, hanem azért sem, mert sokszor a szervizek is kliensként hívnak más szervizeket. ha a régi és az új szervizbuszt egymással párhuzamosan akarnánk üzemeltetni, akkor különböző porton és/vagy különböző ip címen kellene futni a két busznak, és a szolgáltatások, amikor kliensként használják a buszt, el kellene dönteniük, hogy melyiket használják. A szolgáltatások nem tudnak dinamikusan buszt választani, erre nincsenek felkészítve, és valószínűleg csak egy ilyen set-up kedvéért nem is lenne ésszerű.

A tesztelés során a régi (REFERENCE) rendszeren való futtatás időben elkülönül az új, megfigyelt (OBSERVED) rendszeren történő futtatástól. A futási eredményeket adatbázisban helyezzük el, és amikor mind a régi, mind pedig az új rendszeren megtörtént a futás, akkor összehasonlítjuk a futási eredményeket.

A megvalósítás olyan soapUI kiterjesztéssel készült el, amelyik minden egyes teszt lefutás után elmenti a futás eredményeit adatbázisba.

Ezeket a lefutásokat táblázatos formában soapUI-ból meg is lehet tekinteni, a szoftver a teszt eset jobb egérgombos menüjébe konfigurálja magát, és innen előhívható minden olyan futás, ami az adott tesztesetre vonatkozott. (List Run és List compares menük)

A futások nem csak tárolódnak, hanem a listából kettőt kiválasztva össze is lehet hasonlítani az egyes futásokat. Az összehasonlítások eredményei is megtekinthetők anélkül, hogy a soapUI grafikus kezelő felületét el kellene hagynunk.

A rendszer olyan alapvető, bár elsőre nem triviális funkciókkal is rendelkezik, mint egyes teszt lefutások 'noncomparable' megjelölése, ami akkor hasznos, ha egy lefutás külső ok miatt nem volt sikeres, és ezért nem lenne értelmes összehasonlítani más futás eredményével.

Az összehasonlító algoritmus sem bitről bitre hasonlítja össze a futási válaszokat, mert a gyakorlatban soha nem teljesen egyforma két válasz. Olyan mezők értékei, mint correlationId, vagy timestamp soha nem lesznek egyformák két különböző futásban. Hogy a válasz XML mely tag értéket, vagy mely XML tag-ok gyerekeinek a sorrendjét kell figyelmen kívül hagyni a soapUI property transfer test step lépését használja fel a program. Ezekben a teszt lépésekben a soapUI felületén nagyon könnyen ki lehet jelölni a válaszokban egyes részeket, és ezeket a program nem hasonlítja, vagy sorrent figyelembe vétele nélkül hasonlítja.

Az egyes futások összehasonlítása eredményei is bekerülnek az adatbázisban, és a futtatásokból, és az összehasonlításokból a soapUI-be beépített JasperReports eszközzel lehet riportokat készíteni.

Az ügyfél számára lehetővé vált egy olyan SOA architektúra tesztelése, amelyikben a szervizek fejlesztése, korábbi tesztelése és dokumentálása nem volt egységes. A rendszer jól használható olyan környezetben, ahol nem állnak rendelkezésre korábbi teszt futások, pontos dokumentáció. Még ha az egyes szervizek dokumentáltsága megfelelő is a módszertan az infrastruktúra csere esetére akkor is gyorsabb és költséghatékonyabb megoldást nyújt, mint az egyes szolgáltatások specifikációnak való megfelelést vizsgáló tesztek.