Élő webes alkalmazások rendszer-felügyeletének automatizálása cím- és tartalomteszteléssel

Átírás

1 Ercsényi Gábor Budapest február 15. Azonosító: E91 Élő webes alkalmazások rendszer-felügyeletének automatizálása cím- és tartalomteszteléssel Bevezetés Korunk új médiuma a World Wide Web. Ma már olyan eszköz, amelyben komoly üzleti és technológiai lehetőségek rejlenek. Napjainkban korábban elképzelhetetlennek tartott szolgáltatások alapulnak rajta: hírportálok, elektronikus áruházak, biztosítók és bankok is használnak webes felületet. Ezek megbízhatósága újszerű kérdéseket vet fel. Az alapprobléma Jelenleg számos olyan webes szolgáltatás létezik, mely számára szükségszerű a folyamatos elérhetőség és készenlét, ez például elengedhetetlen kritérium az e- kereskedelmi rendszerek számára. Az állandó futás nem elegendő, szükséges, hogy a működés is minél inkább hibamentes legyen. Sok esetben igen nagy mennyiségű, automatikusan generált weboldal- és egyéb erőforrás-halmaz gyakori, esetenként folyamatos ellenőrzésére van szükség. Bizonyos komplex rendszerek tesztelésének hiánya felmérhetetlen károkat okozhat, ennek manuális megoldása azonban sok esetben éppen a nagy számú erőforrás megléte miatt igen költséges vagy nem hatékony, illetve számos esetben egyenesen megoldhatatlan. Komoly gond a sessionökkel operáló webalkalmazásokkal van. Ezek esetében nem elég, ha a HTML oldalak és csatolt elemeik megtalálhatók és elérhetők a megfelelő

2 könyvtárakban. Nem mindegy ugyanis, hogy milyen sorrendben és milyen köztes session változók beállításával haladunk végig ezeken az erőforrásokon. A hagyományos hozzáállás szerint ez manuálisan történik. Igen nagykiterjedésű rendszerek esetében az ilyen tesztelések egy-egy alkalmazott számára órákig tarthatnak, illetve egyeseknek kizárólag ez töltheti ki a munkaidejét. Az erre kijelölt személyzet a webalkalmazás által szolgáltatott lapok sorozatát teszteli végig, egy képzeletbeli felhasználó útját követve az alkalmazásba való belépéstől az alkalmazás elhagyásáig. A cél az, hogy ezen tesztelésekhez szükséges idő megfelelő konfiguráció mellett nagyságrendekkel rövidüljön. A megvalósított rendszer Az tesztelést a World Wide Webet jelenleg uraló formátum, az oldalak több, mint 90%-át kitevő HTML fájlok tartalom-ellenőrzésével elősegíthetjük. Az itt bemutatott webtesztelő alkalmazás ezen kettös feladatot igyekszik automatizálni: egyrészt a webszolgáltatás folyamatos fennállását ellenőrzi, másrészt pedig a HTML-tartalom minőségét vizsgálja bizonyos karakter-füzérek megléte után kutatva vagy azok hiányát felmérve. A rendszer neve WebAlert. Alapvető működése szerint HTTP kérésekkel kérdezi le a megadott URL-ek állapotát, méghozzá úgy, hogy webböngészőhöz hasonló módon HTTP-kliensként viselkedik. Összeállít egy kérést a megfelelő adatokkal, majd azt elküldi a HTTP szervernek. Az pedig adott állapotától függöen reagál. Ez eredményezhet sikeres választ vagy jelenthet valamilyen ismert hibaüzenetet, illetve természetesen előfordulhat, hogy a szerver valamilyen ismeretlen oknál fogva nem is válaszol megadott időn belül. Az alkalmazás mindkét hiba-típust felismeri. A HTML dizájn-elemek hibáit a mai böngészők már automatikusan javítják, ez a rendszer az automatikusan generált oldalak dinamikus elemeire koncentrálva keresi a hibát. A WebAlert a Java / JavaServerPages (JSP) környezetben fejlesztett dinamikus web-alkalmazások tesztelésére optimalizált, de más rendszerek ellenőrzésére is alkalmas. Az adat-transzformációt leegyszerűsítve elmondható, hogy a WebAlert egy bemeneti XML fájlból készít egy kimeneti XML-t. A rendszer felparaméterezése ugyanis egy XML konfigurációs fájl segítségével zajlik. Ezen XML állomány egy adatbázisnak is felfogható, mely az aktuális futtatással kapcsolatos általános adatokon kívül tartalmazza az ellenőrizendő erőforrások listáját sessionökbe csoportosítva, a szükséges egyedi beállításokkal együtt. Az alkalmazás futásának eredménye pedig egy másik XML állomány, ami a tesztelés eredményeit tartalmazza, sessionökre és URL-ekre lebontva. Beállítható egy felhasználói cím-lista is, melyre az alkalmazás elküldi a teljes jelentést vagy annak rövidített változatát.

3 A WebAlert tesztelési konfigurációja A rendszer jellemzői Az WebAlert a Java es verziójának felhasználásával készült, objektum-orientált szemlélet szerint. Mind Java alkalmazás változata, mind Java webalkalmazás változata létezik. Utóbbi esetében a programot természetesen nem érdemes ugyanazon a kiszolgálón futtatni, amelyet tesztelni (is) kívánunk, hiszen a szerver elérhetetlensége esetén elképzelhető, hogy maga a WebAlert sem futtatható. A rendszer Java-alapú voltának mérhetetlen előnye a platform-függetlenség és a hordozhatóság. Alkalmankénti futtatása mellett könnyedén ütemezett futásra bírható [például a Unix világban a Cron használatával, vagy az MS Windows környezetben a Task Scheduler segítségével]. Alternatív felhasználási lehetőségként terheléstesztelésre is használható a párhuzamos szál-használat következtében.

4 A WebAlert vezérlési blokkvázlata az adat-áramlás elhagyásával Hibatípusok Az WebAlert többféle hibát képes megkülönböztetni. A hibák a fentiek alapján két nagy csoportba sorolhatók. i) keresett erőforrás nem érhető el ii) a keresett erőforrás tartalmilag hibás Az el nem érhetőség természetesen különböző okokra visszavezethető, ezért az i) pont további alpontokra osztható: a) kiszolgáló oldali hiba b) kliens oldali hiba c) átirányítás a) A szerver-oldali hibát [érvénytelen válasz, elérhetetlen szolgáltatás, stb.] a HTTPválaszban 5xx-es kódokkal jelölik. b) Az alapvetö HTTP válaszkódokat tekintve egyértélműen hibának számit a 4xx kódok mindegyike, azaz a kliens-oldali [nem létező / nem autorizált erőforrás, hibás kérés, stb.] Ezeket az WebAlert a megszokott HTTP hibaüzenetekkel jelzi is a felhasználó felé. c) A 3xx, azaz a redirekciós válaszkódok esetén a felhasználó választhat, hogy a rendszer ezt hibaként értékelje, avagy végezze el a redirekciót és azt tekintse sikeres

5 műveletnek. Minderre a konfigurációs XML ad lehetőséget az általános tesztelési adatok illetve a session- vagy URL-függő tesztelés-adatok esetében, tetszőleges kombinációban. Adott sessionöket és adott URL-eket is lehet tehát átirányítási hibaérzékennyé tenni. Ezen túlmenően fennáll az a lehetőség is, hogy csak azon redirekciókat tekintsük hibának, amelyek szerint a kéresek az eredeti hosztnevű erőforrástől eltérő hosztnevűre irányítódnának. Mindez ugyancsak session- és egyedi URL-szinten beállítható. A 2xx-es válaszkódok természetesen sikeres választ jelentenek. A ii) pont is felosztható. A tartalom szempontjából történő tesztelés esetén a következő hibák alakulhatnak ki 1) nem elvárt tartalom 2) hiba-sztring a tartalomban 1) valamely kívánt és elvárt tartalom vagy tartalomszegmens [reguláris kifejezéssel megadva] nem illeszkedik a letöltött tartalomra. Ennek oka is sokféle lehet: üres tartalom, az automatikusan generált HTML kívánttól eltérő tartalma, nem a megfelelő fájlra való hivatkozás, stb. 2) az általános hiba-kivételkifejezések valamelyike illeszkedik a tartalomra. Mivel a hibakifejezéseket érdemes úgy beállítani, hogy az ismert hibajelenségek jellemző sztringjeit tartalmazzák, ez a hiba akkor alakul ki, amikor az automatikusan generált HTML tartalmak kialakítása közben a webalkalmazás nem a megfelelő módon működik. Ez utóbbi nem jelent feltétlenül hibás program-kódot. Jól megírt rendszerek esetében is előfordulhat probléma abban az esetben, ha például a kapcsolódó adatbázisba érvénytelen vagy téves adatok kerülnek, esetleg egyes adatok érvényessége lejár. Ez legtöbbször nem a fejlesztők hibája, hanem általában a kiterjedt, sok alkalmazottat foglalkoztató webalkalmazás karbantartóinak feledékenysége. Ugyancsak gond adódhat olyan komplex rendszerek esetében, amelyek más cégek vagy vállaltok által üzemeltetett alkalmazásokhoz kapcsolódnak, és a hiba nem az általunk üzemeltetett rendszerben, hanem a partneréban következik be, mert az téves vagy elavult adatokat küld rendszerünkbe, hiperlinkjeiben esetleg hibás paraméterek segítségével hivatkozik webalkalmazásunkra. Logisztikai szolgáltatóval integrált webáruházak üzemeltetése során például gyakran előfordul, hogy a mondjuk cégen kívül karbantartott - termék-adatbázisban a feltöltő személyzet rossz cikkszám-azonosítót illeszt egy termékhez, mely így hibásan kerül hozzánk és ott futtatásbeli kivételt vált ki. A WebAlert támogatása Java-alapú alkalmazás-szerverek tesztelésekor Ennek kiküszöbölésére Java-alapú alkalmazás-szerverek [mondjuk Apache Tomcat] használatakor megoldható, hogy a hiba fellépésekor keletkező Java kivétel-üzenetek [azaz az exception trace] a generált oldalak részévé váljanak és megjelenjenek azok legalján. Beállítható az is, hogy ilyen esetekben a standard kivétel-osztályt felüldefiniálva egyedi kivételeket dobjon a rendszer, például abban az esetben, ha a fentiek szerint az adatbázisból kinyert adat hibás volta kiderül. Az ilyen üzenetekre

6 rákeresve könnyen megbizonyosodhatunk arról, hogy hiba lépett fel a program futása közben és annak tömör leírását azonnal rendelkezésünkre is bocsátja a webalkalmazás. Mindehhez Java/JSP feljesztő-környezet esetén az errorpage direktíva használata javasolt, amely bizonyos kivételek fellépése esetén az alkalmazás-szerveren belüli újragenerálást hajt végre, és ennek végeredményeként az eredeti helyett egy előre szerkeszthető hibaoldalra ugrik a vezérlés, amelyet szintén sajátos és a WebAlert számára egyértelműen felismerhető sztringekkel tudunk ellátni. Ez a módszer tehát egyfajta kiszolgálón belüli átirányítás, amelyet nem jelez a hagyományos HTTP-átirányítás során megszokott 3xx-es kód, azonban ily módon felismerhető és jelezhető. A Java / JSP környezet tehát lehetővé teszi a hiba / kivétel üzenet és leírás HTML oldalba való illesztését. Ilyen, generált hibaoldal forráskódját mutatja az oldal dizájnelemeinek egyszerűsítésével az alábbi példa: <%@ page iserrorpage="true" %> <html> <head> </head> <body> <%=""%> </body> </html> A HTML oldalakba láthatatlanul, azaz kommentárként beillesztett hibaüzenetekkel közelebb juthatunk az oldal automatikus tesztelésének megoldásához. A következő HTML-részlet a fenti kód alapján generált hibaoldalt mutatja. Kiemelve látható a felhasználó számára kiírt üzenet és a kivétel-leírás, azaz az exception trace informális szegmense. <head> </head> </html> <body>  </body> </html>

7 Bemeneti paraméterek röviden Általános A bemeneti paraméterek segítségével beállíthatóak a futással kapcsolatos általános feltételek, fájlnevek, címek. Ezek a rendszer futása során tesztelt minden sessionre és URL-re egyaránt érvényesek. Helyettesítési szabály A paraméterek egy másik halmaza azon szabályokat írja le, amelyek az összes megadott URL-re nézve érvényes helyettesítési szabályok. Ezek azért fontosak, hogy a hasonló kialakítású URL-címek esetében a felhasználó az összes ilyen cím egyenként való beállítása helyett kényelmesen, és áttekinthető módon, feltételrendszer segítségével legyen képes összeállítani a tesztelendő URL-ek csoportjait. A szabályok segítségével 1:N -szerű hozzárendeléseket állíthatunk be, azaz egy helyettesítendő kulcs-sztring megadása és helyettesítő sztringek halmaza alkot egy szabályt. Ez például egyes URL-csoportok nyelv-paraméterezésében jelenthet előnyt: LISO2 eredményezi: { de, en, hu } szabály a következő átalakításokat Nem kívánt elemek A paraméterek egy következő halmaza azon reguláris kifejezéseket foglalja össze, melyek a nem kívánt, azaz hiba-jellegű szövegrészletek jellemzői, és amelyekre a rendszer az összes megadott URL-ről letöltött HTML-tartalomban illesztést próbál végrehajtani. Ezek lehetnek például automatikusan generált HTML-ek fentebb tárgyalt hibaüzenetei. A kifejezések az áttekinthetőség érdekében listát alkotnak és egymással VAGY kapcsolatban állnak. A lista természetesen lehet üres is. URL Végül a legfontosabb csoport következik: az URL-ek listája. A lista sessionökre bontva csoportosított, így az összetartozó, egy virtuális felhasználó által bejárt URL halmazokat közölhetjük egymás után. Megadhatunk sajátos, csak az adott URL-re nézve érvényes paramétereket is.

8 Előfeldolgozás Az WebAlert tényleges futását megelőzi az előfeldolgozás, ez a konfigurációs XML feldolgozást jelenti. Az XML-fát DOM parserral bejárja és az alapján felépíti az általános teszt-adatok objektumát, valamint a szükséges URL-ek objektumszerkezetét, a megfelelő tulajdonságokkal. Ekkor kerül sor a helyettesítési szabályok végrehajtására is: a rendszer végignézi az összes URL-t, és illeszteni próbálja rájuk a helyettesítendő sztringet, ha ez sikerül, akkor annyi új URL-objektumot hoz létre, ahány helyettesítési célsztringet talál az adott helyettesítendő karakterfüzér csomópontjának utódaként. Ezekkel tehát az eredeti listát kibővítve kialakul a végleges URL-lista. A sessionök és cookie-k Napjainkban egyre több webalkalmazás session-alapú. Ez azt jelenti, hogy a felhasználó alkalmazásba való belépésekor számos, például felhasználó-függő adat állítódik be a rendszer belső változóiban szokás szerint az azonosító-jelszó pár megadásának hatására --, és a további működés is ezek függvényében zajlik egészen a kilépésig. A WebAlert rendszer a tesztelést ilyen sessionökre lebontva végzi. Minden session egy-egy felhasználói akció-sorozatot imitál, azaz úgy teszteli végig az adott sessionbe gyűjtött URL-eket, hogy a szerver-oldali sessionfüggö változók az elsőtől az utolsó URL teszteléséig konzisztensen elérhetőek lesznek, mindez session cookie-k felhasználásával történik. Az adott URL-csoport első tagjának tesztelésekor a szerver HTTP-válaszának fejlécében egy Set-Cookie változó-halmazt küld. Ezt a böngészők a cookies.txt-be mentik, a WebAlert ezt imitálva, egy belső változójában tárolja el ezt az információt. A második és további URL-eket már az előbbiekben elmentett cookie-k segítségével teszteli, a HTTP-kéresben ugyanis a Cookie paraméter értékeként éppen ezeket adja meg. Így a szerver azonosítani tudja a kérést, mivel érzékeli, hogy ugyanazt a változót kapta vissza a klienstől, mint amit az elsőben küldött válaszként. Egy 2 darab URL-ből álló, de ugyanazon sessionön belül kívánt lekérdezést vizsgálva például az első URL kérésekor a böngészőt imitáló WebAlert egy kitöltetlen, azaz üres sztring Cookie paramétert küld a HTTP-kérés fejlécben a kiszolgáló felé. A szerver a HTTP-válasz fejlécében pedig egy egy vagy több paraméternév=paraméterérték; -böl álló beállítás-csoportot küld vissza az álkliensnek. A második, ugyanazon sessionbe tartozó URL tesztelésekor az alkalmazás már ezen, frissen kapott azonosító név-érték párosokat állítja be a fejlécében, mely a szerver számára előteremti az azonosíthatóság feltételeit:

9 WebAlert Kiszolgáló HTTP-kérés 1. URL [Cookie = ] HTTP-válasz 1. URL [Set-Cookie = JSESSIONID=7hszjwss21; ] HTTP-kérés 2. URL [Cookie = JSESSIONID=7hszjwss21; ] HTTP-válasz 2. URL Tipikus HTTP üzenetek A rendszer HTTP üzeneteket vált a megfelelő szerverekkel. Az alkalmazás először a HTTP üzenetek fejlécére koncentrál, ezekből nyeri ki az adott erőforrásra vonatkozó meta-adatokat, ez után következik a tartalom, ha az elérhető. A rendszer számára nem fontos az összes, fejlécben található változó, Egy tipikus WebAlert HTTPkéresben a kérés fejléce a következő mezőket tartalmazza: GET/HTTP/1.1 JSESSIONID=7hszjwss21;Path=temp; Keep-Alive Java/1.4.1_02 shop.dummy.com text/html, image/gif /en/index.jsp Kérés típusa / protokoll / verziószám Cookie [a fentebb említett cookie-készlet] Connection [a kapcsolat típusa] User-Agent [a lekérdezés nyelve / típusa] Host [a lekérendő gazdagép neve] Accept [az elfogadható fájltípusok] URL File [a letőltendő fájl neve] A HTTP kérést a szerver fogadja és ha éppen kifogástalanul üzemel, akkor a következőhöz hasonlatos tipikus választ generálja: 200 OK [az ismert HTTP válaszkódok és üzenetek] Mon, 02 Feb :46 GMT Date [válasz dátuma] Tomcat Web Server/3.3 Final Server [az alkalmazás-szerver típusa] CP= NOI DSP COR NID ADM DEV OUR P3P text/html;charset=iso Content-Type [a tartalom típusa és kódolása] JSESSIONID=7hszjwss21;Path=temp; Set-Cookie [a fentebb leírt beállítandó cookie-k] MISS from shop.dummy.com X-Cache close Connection [a kapcsolat státusza] chunked Transfer-Encoding [átviteli kódolás] Utófeldolgozás A sikeresen letöltött oldalak a beállításoktól függően utófeldolgozásra kerülhetnek. Ha a felhasználó igényli ezt a műveletet, akkor a HTML tartalmakban tovább keres a rendszer újabb hivatkozások és további erőforrások, például képek, kaszkád stíluslapok (CSS), stb., pontosabban ezek címei után kutatva. Ehhez a HTML oldal szerkezetét kell az alkalmazásnak felismernie.

10 A HTML az egykori SGML nyelvből fejlődött ki. Az úgynevezett HTML tag-ek javarészt <object pname= pvalue > és </object> jelek segítségével fognak közre formázandó szövegeket. Az object név itt az ismert módon igen sokféle lehet, neve jelzi a böngészőnek, hogy milyen módon kell megformázni a közbülső mondanivalót. A tag-ek paramétereket is tartalmaznak, a példában pname a paraméter neve és pvalue az értéke, utóbbi macskakörmök közt. A többszörös egymásba ágyazás segítségével a gráfelméletből ismert fa-struktúra alakítható ki. Azonban a HTML nyelv mégsem ilyen egyszerű és tökéletes. A fa-struktúra kialakításába belezavarnak az előd SGML-böl ismert anomáliák, például a <BR> tag, amely egytagú és egyébként sortörést szimbolizál, valamint az olyan nem teljesen szabványos kódolási mód, mely megengedi a paraméter értékek macskakörmeinek elhagyását is. Az XML szabvány ennél pontosabb, esetében a most leírtak hibát okoznak feldolgozáskor. A nem teljesen szabványos elemek így persze valószínűleg bizonyos esetekben könnyen érthetők, egyszerűbben kezelhetők, és talán jobban is olvashatók, mint az XML szigorú rendszere, ám az XML ezáltal azzal az igen hasznos tulajdonsággal rendelkezik, hogy könnyedén bejárható és elemezhető. A HTML lapok tehát a formázást tekintve számos ilyen apró szabálytalanságot tartalmaznak, melyekből a mai böngészők már jó párat automatikusan kijavítanak, így az oldalakat letöltő internetezők kifogástalanul látják a megjelenített tartalmat. A program azonban leghatékonyabban fa-struktúrában képes a HTML oldal tartalmát feltérképezni. Ezért a WebAlert a HTML tartalmat XHTML-lé konvertálja. Az XHTML formátum a HTML leírónyelvnek az XML-es alapokra helyezésével létrejött konvenciója, a webes szabványokkal foglalkozó World Wide Web Consortium (W3C) ajánlása. Mivel ez a nyelv valódi fa-szerkezetű, ugyanúgy bejárható, mint egy megszokott XML-fa. A konvertálás után tehát a rendszer bejárja a fát és kigyűjti a hiper-hivatkozások és más fentebb említett erőforrások URL-jeit, majd a szintén a konfigurációs XML-ben leírtak alapján ezeket hozzáfűzi a tesztelendő URL-ek maradéklistájához a mélységi bejárás vagy a szélességi bejárás elvéhez hasonlatosan. A választási lehetőségnek oka van: nem mindegy, hogy egy adott site-on egy weboldal-sorozatot milyen sorrendben járunk be, funkcionális különbségek adódhatnak ugyanis, főként akkor, ha ezek a HTML tartalmak dinamikusan generálódnak. A hivatkozások után való keresés természetesen folytatódhat az ily módon bővült lista új tagjaira nézve is, mindaddig, amíg a rendszer el nem éri azt a szintet, amit beállítottunk a konfigurációs XML-ben. Amennyiben mélységi bejárást állítottunk be, a talált erőforrások listáját az adott sessionben éppen vizsgált alap-url tesztelése utánra időzíti a rendszer, azaz a hátralevő, még tesztelendő URL-ek listája elé helyezi el azokat. A mélységi bejárás elve szerint ugyanis első utunk a képzeletbeli fa gyökerétől indulva először a lehető legközelebbi, azaz a lehető legkevesebb csúcs érintésével megközelíthető levélhez vezet, majd vissza a legutoljára elhagyott elágazásig, és ismételten a legközelebbi még nem érintett levélhez törekedve, mindez rekurzívan zajlik.

11 Allista beillesztés az URL listába mélységi bejárás szerint A szélességi bejárást választva viszont a megtalált erőforrások a sessionben mindig az adott session még várakozó URL-listájának legvégére kerülnek. Egy fa szélességi bejárása ugyanis azt jelenti, hogy csak egy adott csúcs-szintet bejárva kezdjük el a következő utódcsúcs-szint bejárását. Itt az egy szinthez tartozó csúcsokon egy olyan csúcshalmazt értünk, melyek gyökértől való távolsága azonos. Allista beillesztés az URL listába szélességi bejárás szerint A listába felvett URL-ek az ős-erőforrás beállított jellemzőit örökölve ugyanolyan értékű tagjai lesznek a tesztelendő listának, mint az eredetileg, a felhasználó által beállítottak. A rendszer így tetszőleges mélységig képes bejárni a kiindulási URL lista elemeit, a lista pedig a bejárás során akár igen nagyra is duzzadhat az adott erőforráspopulációban rejlő hiper-hivatkozások számának függvényében. Itt mutatkozik meg igazán a párhuzamos szál-alapú feldolgozás előnye, hiszen nagy mennyiségű URL letesztelése igen időigényes folyamat lenne soros megközelítéssel.

12 A rendszer futása Az alkalmazás megkeresi a konfigurációs XML-állományt. Ennek útvonala Java alkalmazás futtatási mód esetén az alkalmazás egyetlen paramétere. Sikeres esetben megkezdődik a fájl feldolgozása. A konfigurációs XML feldolgozása a DOM parser segítségével történik. A gyökércsomóponttól haladva felépül az általános teszt-feltételek objektuma, a nem kívánt kifejezések listájával [hibaüzenetek, lásd errormessages], a sztring-helyettesítési szabályokkal [lásd substitutes], session-objektumok generálódnak. Elkészülnek a sessionök tesztelni kívánt URL objektumai. A rendszer minden ilyen URL-t előzetesen megvizsgál, hogy az helyettesíthető-e valamely adott szabállyal. Ha igen, akkor az URL-listához hozzáfűzi a helyettesítési szabályokkal nyert új tesztelendő URL-halmazt. Egy alap modul elindítja az összes session tesztelését párhuzamosan. Mivel sessionök függetlenek egymástól, ezért erre van lehetőség, s így nagy tesztelendő lista esetén a futási idő nagyságrendekkel rövidül a soros futtatáshoz képest. A sessionök tesztelésük elején időbélyeget kapnak. Egy session tesztelése a következőképp zajlik: egy külső fő-ciklus alapján a program lépésről lépésre végigmegy az adott URL listán és a megfelelő paraméterekkel felépíti a HTTP kapcsolatot. A HTTP-kérésre HTTP-válasz érkezik, ennek paraméterértékeit a rendszer eltárolja a megfelelő objektumokba, úgymint hibaállapot, kezdő URL, átirányított URL, időbélyeg, cookie, válaszkód, válaszüzenet, tartalom hossza, letöltés ideje, stb. Végrehajtódik a tartalom-elemzés, amennyiben a tartalom letöltődött. Ennek során a rendszer megállapítja, hogy az adott oldal tartalmaz-e hibákat illetve tartalmazza-e az elvárt szegmenseket. Kutatás a hiper-hivatkozások [linkek, képek és egyéb erőforrások] után. A sikeresen megtalált erőforrások a tesztelés sorrendiségének szempontjából a konfigurációs XML-ben beállítottak szerint a session URL-listjának végére vagy a soron következő pozícióba kerülnek. Ha a sessionben az összes URL és linkek által fellelt további URL rekurzívan feldolgozásra került, akkor a session feldolgozása is befejeződik, záró időbélyeget kap. Ha az összes session feldolgozásra került (ezt egy speciális feltétel vizsgálja), a párhuzamos szálak megszűnnek és megkezdődik a jelentésfájlok összeállítása szintén a konfigurációs XML-től függően. Az XML jelentésfájl összeállítása ugyancsak DOM parser segítségével zajlik. Ha a felhasználó igényelte, a jelentés elküldésre kerül.

13 A rendszer funkcionális modellje A rendszer adatáramlásait mutatja a funkcionális modell. A belépő adatok és a kilépő adatok közti transzformációk jól mutatják, mivel mi történik. Az ehhez kapcsolódó ábra természetesen nem mutatja az összes, rendszerben mozgó adatot, csak a rendszer szempontjából lényegeseket. A WebAlert egyszerűsített funkcionális modellje Az ábrán egyszerűen végigkövethetjük a főbb lépéseket. A rendszer alapvető metódusai a körökben találhatók. A modell szempontjából igazán a rendszerben található adattárak fontosak. Ezekből ebben a felbontásból négyet érdemes megkülönböztetni: - session lista: itt tároldódnak a konfigurációs XML-ből kinyert sessionök, és a hozzájuk kapcsolódó adatok - URL lista: itt tárolódnak az aktuálisan feldolgozás alatt álló session URL-jei és a járulékos adatok

14 - HTTP-válasz / tartalom: az aktuálisan tesztelt URL-re vonatkozó HTTP-válasz minden idetartozó adattal együtt, sikeres HTTP-kérés az éppen lekért erőforrás tartalma - eredmény lista: itt érhető el a HTTP-válaszok értékelésével kapcsolatos minden adat A konfigurációs XML A rendszer futtatásának felparaméterezése egy XML állomány segítségével történik. Ez a fájl 5 alapvető csomópontra osztható, mindegyik egy-egy XML-csomópontot jelöl [a csomópontok egymásba ágyazottak]: i) <main> ii) <errormessage> iii) <substitutes> iv) <session> v) <object> i) A main szekcióban a teszteléssel kapcsolatos alap-beállítások találhatók. A csomópont paraméter-listája a következő elemeket tartalmazza: outfilexml outfiletxt onlyfailed simplelist contentlength wait savexmlreport savetxtreport send Az outfilexml a kimeneti XML útvonalat és fájlnevet állítja be. Az outfiletxt paraméter az ANSI kimeneti fájl nevét tartalmazza. A kimeneti XML fájl mellett ugyanis készül egy szöveg-alapú is, ha ez a felhasználónak igénye. Az onlyfailed paraméter a jelentés egyik szűrő-beállítása: a szöveg-alapú jelentésfájlba és az es értesítőbe csak azon URL adatait menti, amelyek nem töltődtek le a kívánt módon. Ez akkor fontos, amikor a tesztelendő URL listánk túlzottan hosszú, így előzhetjük meg azon szöveg-alapú jelentések létrejötték, melyekben csak nehézkesen találnánk rá a nem vagy hibásan működő erőforrásra. true esetén csak a sikertelen eseteket jelenti a rendszer, false esetén mindent. A simplelist szintén szűri a szövegalapú valamint ben elküldött jelentést: az összes, HTTP-válasszal kapcsolatos információ helyett kizárólag bináris információt közöl, mégpedig azt, hogy az adott URL-en az erőforrás hibátlanul elérhető vagy

15 nem. Így a jelentésfájl és az -értesítő egy gyorsan áttekinthető, kétoszlopú listát tartalmaz. true esetén a jelentés egyszerűsített, false esetén nem. A contentlength paraméter azt adja meg, hogy a jelentésekben, az egyes URLek tesztelésekor felderített tartalmi hiba észlelése után a felhasználó a letöltött HTML tartalom hány karakterét kívánja a jelentésbe ágyazni. Negatív szám is megadható, ilyenkor a rendszer a tartalom-sztring végétől számítja a karaktereket, ez például Java alapú alkalmazás-szerver által generált HTML-tartalom tesztelése esetében igen hasznos, ezek esetében ugyanis az automatikusan generált tartalom végére kerüljön a hibaüzenet. 0 érték esetén nem csatolja a tartalmat a jelentésfájlba, kitöltetlen esetben az egész tartalom kijelzésre kerül. A wait az egyes URL-ek tesztelésekor kikényszeríthető megnövelt várakozási idő hosszát állítja be, ezredmásodpercben megadva. A savexmlreport jelzi a rendszer számára, hogy készüljön-e XML-alapú jelentésfájl. Ez nem minden esetben kötelező. true esetén generálódik a fájl, false esetén nem. A savetxtreport azt mutatja, hogy generálódjon-e szöveg-alapú jelentés-fájl. Ez szintén nem kötelező, azonban bizonyos esetekben szükség lehet rá, ha például olvashatóság szempontjából vagy séma hiányában kényelmetlen az XML-jelentést olvasni. true esetén generálódik a fájl, false esetén nem. A send paraméterrel az -jelentés küldése állítható be. true érték beállítása esetén a rendszer t küld a beállított címekre, false érték beállításakor nincs ilyen üzenet. Az utóbbi 3 paraméter beállítása között nincs kapcsolat. Beállíthatjuk mind a hármat true értékűre, ami azt eredményezi, hogy XML-alapú és szöveg-alapú jelentés is készül, valamint a felhasználó -értesítést is kap. Azonban megtehetjük azt is, hogy egyik paraméter sem true, ez esetben az eszköz, megfelelő további paraméterezés esetén használható webszerver-terhelés tesztelésekhez, ehhez a sessionokra nézve párhuzamos tesztelési algoritmus ad alapot. Az paraméter azon címeket tartalmazza, amelyekre az alkalmazás a jelentéseit küldi. Több címet vesszővel választhatunk el. ii) A <errormessage> szekcióban a fentebb említett, valamennyi URL tesztelésével kapcsolatos nem kívánt hibaüzenetre illesztendő kifejezések találhatók. Minden ilyen <errormessage> csomópont egy hibaüzenetet reprezentál, a könnyebb áttekinthetőség érdekében listaszerűen, melyek közt VAGY kapcsolat érvényes. Ha tehát valamely listatag kifejezés illeszkedik egy éppen vizsgált URL által szolgáltatott HTML-tartalomra, akkor az alkalmazás az adott URL-t hibásnak értékeli és így tárolja el a jelentésfájlokban. A <main> szekcióban említett contentlength beállítás helyes beállítása esetén a WebAlert üzemeltetője azonnal meg is tekintheti a hiba

16 leírását, amely annak kijavításában nyújt nagy előnyt. Az egyes URL-ek egyedi kifejezései egy exp nevű paraméterben állíthatók be. iii) A <substitutes> szekció a szintén korábban vázolt sztring-helyettesítési szabályok implementációja. Ez az XML-ben egy rész-fa, amely tetszőleges szélességben bővíthető: egy gyökér-csomópont, amelyben a helyettesítendő sztringet a tochange paraméter jelöli, tetszőleges számú sub azonosítójú utódcsomóponttal egészíthető ki, amelyben pedig a change paraméter mutatja azt a sztring-halmazt, amire a helyettesítendőt kicseréli a program. iv) Végül pedig a <session> szekció mutatja az URL-ek halmazát. A <session> csomópontok az ugyanazon sessionben tesztelendő URL-eket gyűjtik egybe. Minden session csomópontnak van neve, amely a jelentés fájlokban is azonosítja azokat. Ennek a csoportnak az opcionális paraméterei: redir redirisfail redirtodiffserver redirtodiffserverisfail linktest linkmaxlevel A redir paraméter az adott session összes URL tesztelésére vonatkozóan állítható. Ha true értéket kap, akkor az alkalmazás a 3xx kódú HTTP válaszok esetében automatikusan átirányít fejlécében található címre. Ha false az értéke, akkor nem követi a redirekciót. A redirisfail azt állítja be, hogy az előbbi esetben az WebAlert az átirányítást hibaként értékelje-e. true esetén a 3xx válaszkód hibának számít, false esetén nem. A redirdiffserver paraméter session szintén összes, aktuális sessionba tartozó erőforrásra vonatkozóan állítható. Ha true értéket kap, akkor az alkalmazás a 3xx kódú HTTP válaszok esetében automatikusan átirányít fejlécében található címre, minden esetben. Ha azonban ez false, akkor nem követi a redirekciót, amennyiben a cél URL-ben található hosztnév eltér az előző hosztnévtől. A redirdiffserverisfail a fentiekhez hasonlóan azt mutatja, hogy WebAlert az előzőektől eltérő hosztnevű szerverre való átirányítást hibaként értékelje-e, session szinten. true esetén minden ilyen eset hibának számít, false esetén nem. Más szerverre való nem tervezett átirányítás komoly gondokat és súlyos veszteségeket okozhat, ezért volt érdemes ezt a lehetőséget is beépíteni a rendszerbe. A linktest azt adja meg, hogy az adott sessionhöz tartozó összes URL-en belül végezzen-e további feldolgozást az alkalmazás hivatkozások után kutatva. A

17 hivatkozás alapján új URL-ek nyerhetők, melyek szintén ellenőrizhetők. Ha a felhasználó szeretne ilyen link-tesztelést, akkor meg kell adnia, hogy a feldolgozás sorrendisége mélységi vagy szélességi legyen-e. A paraméter három lehetséges értéke tehát: none, depth, breadth. A linkmaxlevel változó a hivatkozások alapján való tesztelés szintjeinek számát adja meg elkerülendő a túlzottan hosszú ideig tartó és adott esetben szükségtelen tesztelést. Ez a paraméter is a session összes URL-jére érvényes. v) A fában továbblépve egy szinttel a levelek fele, láthatjuk, hogy a <session>-ök <object> csomópontokat tartalmaznak, melyek mind egy-egy URL-t reprezentálnak. Ezeknek egyedi beállítási lehetőségei is vannak, a következő paraméterek segítségével: typ URL login password exp redir redirisfail redirtodiffserver redirtodiffserverisfail linktest linkmaxlevel A typ paraméter az ismert HTTP kapcsolat típust azonosítja. Az URL maga az elérni kívánt erőforrás-lokalizáló cím, ez tartalmazhat CGI paramétereket is a szabványos formában. Itt állítható be a helyettesítendő karakterfüzér, a fentiekben tárgyalt helyettesítési szabályok értelmében. A login kényelmi paraméter: ezt beállítva az URL egy login=érték típusú posztfixet kap. A password szintén kényelmi paraméter: ezt beállítva az URL egy password=érték típusú posztfixet kap. Csak a login-nal együtt érvényes. Az exp sztring csak az adott URL-re érvényes reguláris kifejezés. Ha ez nem illeszkedik a letöltött oldal tartalmára, akkor a program azt hibaként, egy elvárt elem hiányának értékeli és így dokumentálja a jelentésfájlokban is. A következő hat paraméter neve és jelentése hasonlatos a <session>-szinten található négy redirekcióval és két hivatkozás-teszteléssel kapcsolatos paraméterrel. Nevük is azonos, azonban ezek kizárólagosan az aktuális URL paraméterei, beállításuk tehát az adott session egyéb URL-jeire nem vonatkozik. A session beállításait felüldefiniálják, tehát az <object>-szintű azonos nevű paraméterek

18 prioritása magasabb a <session>-szintűeknél. Ezeket azonban nem kötelező megadni, ha a <session>-szinten már deklaráltak: redir redirisfail redirdiffserver redirdiffserverisfail linktest linkmaxlevel Példa konfigurációs XML-ek A könnyebb áttekinthetőség kedvéért DTD helyett egy igen leegyszerűsítetett példa XML kerül bemutatásra csak a legfontosabb csomópont-attribútumok feltüntetésével: Illetve egy valamivel bonyolultabb valamennyi paraméter bemutatásával:

19 A jelentés Kétféle jelentés fájlt tud generálni a rendszer, valamint -küldésre is képes 1) Egyszerű szöveg alapú, az áttekinthetőség és könnyű használhatóság érdekében. Ez a fájl TXT kiterjesztésű, és a konfigurációs XML-ben több lehetőség beállítható vele kapcsolatban: - kizárólag azon URL-ek tartalmazása, amelyek nem voltak letölthetőek vagy elfogadhatatlan tartalommal rendelkeztek, - egyszerűsített jelentésfájl generálása - normál jelentésfájl [alapértelmezés szerint] Az állomány sessionökre, azon belül URL-ekre lebontva tartalmazza a tesztelés eredményét, közölve a fentebb említett és eltárolt értékeket. Hibás tartalom esetén a konfigurációs XML-ben megadott hosszúságban mellékeli a tartalom egy részletét. 2) XML-alapú. Ez a fájl tulajdonképpen a konfigurációs XML sémájára épített, és azt kiegészítő dokumentum. A különbség annyi, hogy a <session> és az <object> csomópontok új leszármazott csomópontot kapnak: a rendszer hozzájuk csatolja a <response> csomópontot, aminek paraméterei éppen azok a változók, amiket az alkalmazás az adott session vagy az adott URL tesztelésekor nyert. Így tehát:

20 - status [hibaállapot] - cause [hibaok, ha van] - starturl [kezdö URL] - stopurl [átirányított URL] - timestamp [időbélyeg] - cookie - rescode [válaszkód] - resmesssage [válaszüzenet] - reslength [tartalom hossza] - restime [letőltés ideje] - content [tartalom-szegmens] Egy tipikus XML jelentés-részlet tehát [vö. a fentebb bemutatott konfigurációs XMLlel]: Az XML jelentésfájl nagy előnye, hogy tetszőleges XSLT sémával testre szabható, csak a kívánt adatok jelzésével, mindezt sajátos felosztásban és dizájnnal. 3) -jelentés. Ezzel a módszerrel a rendszer t küld a felhasználónak a szöveg-alapú jelentést felhasználva, illetve azt kiegészítve. A levél témájában és törzsének felső részében jelölve a tesztelés eredményét, valamennyi sessionre nézve, hibázás esetén közli a nem kielégítő sessionök és URL-ek számát, valamint az XML-alapú jelentésfájl URL-jét, amennyiben az létezik. Egy példa -jelentés a fentebb bemutatott példa konfigurációs XML alapján: SESSION: Shop Status: PASSED Start URL: Stop URL: Time stamp: Sun Feb 15 17:16:52 CET 2004 Session: no Set-Cookie available Res code: 200 OK Res length: 397 bytes Res time: 4270 ms Content: Satisfying Status: PASSED Start URL: Stop URL: Time stamp: Sun Feb 15 17:16:53 CET 2004 Session: JSESSIONID=eq9lv5fy21;Path=/bishop Res code: 200 OK

21 Res length: 1090 bytes Res time: 657 ms Content: Satisfying SESSION: Discount shop Status: PASSED Start URL: Stop URL: Time stamp: Sun Feb 15 17:16:53 CET 2004 Session: no Set-Cookie available Res code: 200 OK Res length: 98 bytes Res time: 263 ms Content: Satisfying Status: PASSED Start URL: Stop URL: Time stamp: Sun Feb 15 17:16:55 CET 2004 Session: no Set-Cookie available Res code: 200 OK Res length: 1138 bytes Res time: 539 ms Content: Satisfying Status: FAILED Cause: Not Found Start URL: Stop URL: Time stamp: Sun Feb 15 17:16:56 CET 2004 Session: no Set-Cookie available Res code: 404 Not Found Status: FAILED Start URL: Stop URL: Time stamp: Sun Feb 15 17:18:32 CET 2004 Session: no Set-Cookie available Res code: 200 OK Res length: 1448 bytes Res time: 785 ms Content: com.dummy_shop.beans.dummyshopexception: No such product exists! at com.dummy_shop.helpers.checkpricehelper.checkrequest(checkpricehelper.java:61) at en.buynow_4._jspservice(buynow_4.java:154) at org.apache.tomcat.util.net.tcpworkerthread.runit(pooltcpendpoint.java:494) at org.apache.tomcat.util.threads.threadpool$controlrunnable.run(threadpool.java:516) at java.lang.thread.run(thread.java:534) Továbbfejlesztési lehetőségek Az alkalmazás számos ponton továbbfejleszthető, illetve integrálgató más rendszerekkel. Az egyik lehetőség egyfajta önjavító mechanizmus, mely a hibásan formázott HTML fájlokat automatikusan kijavítaná. Az elrontott <ul> listák, <table> táblázatok a feldolgozás során könnyedén kijavíthatók automatikusan, arról nem is beszélve, hogy az XHTML-parse-olás következményeként ezen fájlok forráskódja áttekinthetőbbé válhat.

22 A hibás hivatkozások is önmódosíthatóak lehetnének, persze csak korlátozott mértékben. Egy kiegészítő alkalmazás a nem elérhető erőforrások útvonalát ellenőrizhetné, ha az adott kiszolgálón a megfelelő jogokkal bír ehhez. Amennyiben a hivatkozott helyett más, ám az útvonal-fa nem túl távoli csúcsán található hasonló vagy ugyanolyan nevű erőforrásra bukkan, akkor az eredeti hivatkozást esetleges megerősítést követően magától javítaná. Az javítás egy komolyabb fokozata lehetne az a megoldás, mely szerint a generált oldalakra hiba esetén hibakódot kiíró alkalmazásszerver egy hibakód-adatbázissal állna összeköttetésben. Ugyanezen adatbázishoz kapcsolódna a WebAlert is, mely a hibakódot felismerve azonnal felhasználó-barát üzenetekkel és egyéb járulékos információval szolgálhatna az adott alkalmazás aktuális hibájáról. Ebben az esetben a hibakód-adatbázis bonyolultságától függően a webszolgáltatások fejlesztői akár igen részletes hibajelentés segítségével tudnák lokalizálni a hibát, amely a kijavítás időtartamát jelentősen csökkentené. Megoldható az is, hogy az alkalmazás-szerver esetleges nem kívánt leállása esetén, az ezt mutató egyedi hibát egyértelműen felismerve egy integrált alkalmazás a kiszolgálót újraindítja vagy elvégzi a szükséges beavatkozó műveleteket, mindezt szintén automatikusan. További ötlet a jelentés XML-ek feldolgozása és adatbázisban vagy adattárházban való eltárolása. Így az áttekinthetetlenül nagy és/vagy sztochasztikusan működő rendszerek hibajelentései egy helyen, rendezetten és kereshetően válnának a hibakeresők hasznára. Így hiba-statisztikák, diagrammok készíthetők, sőt hibakonstellációkat, korrelációt, egymásra hatásokat és egyéb jelenségeket lehetne kinyomozni akár adatbányászati módszerekkel. Más URL tesztelő alkalmazások Léteznek hasonló rendszerek. Ilyenek például a Doctor HTML, a Coast.com, a Xenu Link Sleuth, az evalid, a CheckBot, az egykor árusított WebAnalyzer, stb. Ezek a WebAlerthez részben hasonló működésűek, azonban jelentős különbség a WebAlert egyszerű felépítése és funkcióinak olyan ötvözete, amely minden lehetőséget megad akár egy e-kereskedelmi rendszer kényelmes tesztelésre. A legtöbb hasonló rendszer: - nem teszteli a lekért tartalmat - vagy nem képes reguláris kifejezéseket kezelni - esetleg csak az azokon fellelhető hiper-hivatkozásokat keresi meg - különállóan kezeli az egyébként egy sessionbe tartozó letöltéseket, nem kezeli a session cookie-kat - nem tud azonosítóval és jelszóval ellátott URL-eket tesztelni vagy egyáltalán nem képes paraméterezett URL-t feldolgozni - nem platform-független - nem képes -üzenetben jelentést küldeni - konfigurációs felülete nem XML-alapú

23 - illetve a jelentés-fájl nem XML-alapú, és az így nehézkesen feldolgozható, kapcsolódó rendszerekbe nem továbbítható - bonyolult, nagyméretű és drága Az WebAlert esetében mindezen hiányosságokra egyszerre adott a megoldás.