1. Tesztelési rendszer ASP.NET-tel

   1. Bevezetõ

A napjainkban készülõ informatikai rendszerek egyre összetettebb megoldások. Ez elsõsorban az egyre jobban terjeszkedõ piacnak köszönhetõ: a papíralapú gazdaság kezd átalakulni elektronikusan tárolt, továbbított, ellenõrzött és feldolgozott informáicó-folyammá. Így egyre több helyen használják a számítógépeket, és természetesen felmerül az igény ezeknek programoknak az összekötésére is, a megbízható, valósidejû kommunikáció kialakítására. A piac terjeszkedésének másik nagyon fontos dimenziója a legkülönbözõbb intelligens eszközök térhódítása. Néhány éven belül megérkezünk az informatikai forradalom következõ, talán legjelentõsebb állomásához, amikor a mobiltelefonok és a kézi-számítógépek elõretolt állásaira támaszkodva életünk mindennapjaiban megjelennek az egymással kommunikálni képes intelligens eszközök (hûtõgépek, autók, házak, órák, stb.). Ezeknek az eszközöknek elsõdleges feladata természetesen nem változik (az óra ugyanúgy mutatja majd az idõt, és az autó is tetszésünk szerint vezethetjük, stb.), de rengeteg szolgáltatással kibõvülve mégis alapjaiban fogja megváltoztatni mindennapi életünket.

Paradox módon ezzel párhuzamosan megfigyelhetõ az informatikai iparág ’válsága’ is: az informatikai piac nem olyan ütemben terjeszkedik, mint az elõzetesen megjósolták: kevesebb szoftver elkészítésére érkezik megbízás, és érezhetõ az egyes piaci szektorok telítõdése is, a beruházások gyakorisága érthetõ okokból nem követi – és nem is követheti – a technológia hihetetlen mértékû fejlõdését, mert bár az új technológia mûszaki paraméterei egyértelmûen jobbak az elõzõnél, mégsem éri meg néhány évente új rendszert bevezetni, mert az átállás és a beruházás költsége nem térül meg. Fontos tényezõ az elkészült rendszerek minõsége is: a statisztikák szerint a megrendelt szoftverek nagyon kis (néhány százaléknyi) része készül el idõben, maradéktalanul kielégítve az igényeket.

A fentiekben vázolt problémák megoldása nagyon összetett feladat, hiszen többek között szükséges a társadalom informatizálása – amely akár már önmagában is több évtizedet igénybevehet –, a gazdasági élet átalakítása, a törvények, írott és íratlan szabályok módosítása, bizonyított elméleteken alapuló technológiai megoldások és módszertanok kidolgozása és gyakorlati alkalmazása.

A feladatok egy nagyon vékony szeletének egy apró részletét emeljük ki, és foglalkozunk vele részletesebben: bizonyos típusú alkalmazások tesztelésére mutatunk be gyakorlati megoldást a követelmények ismertetésével és egy lehetséges technológia, a Microsoft .NET alapú Internetes megoldás bemutatásával.

2. A rendszer keretei és bemutatása

A rendszer célja a szoftverfejlesztés egyik késõi fázisának, azaz a tesztelésnek a hatékony támogatása.

Ez több összefüggõ feladatot jelent:

• Az elõre elkészített tesztforgatókönyvek importálása, megjelenítése a tesztelõ számára, és a tesztelés eredményének lépésenkénti rögzítése.

• A rendszer mûködésével kapcsolatos visszajelzések küldésének támogatása – akár konkrét teszt-lépéssel, akár általános tapasztalatokkal kapcsolatban.

• A visszajelzések kezelésének támogatása: osztályozás, priorizálás.

• Visszajelzések nyomon-követése: státuszállítás, státuszfigyelés, archiválás, lekérdezések és statisztikák készítése.

• Az üzenetkezelési mechanizmus integrálása a szoftverkészítés során alkalmazott rendszerekbe.

3. Az ASP.NET, mint megoldás

Az ASP.NET választása kézenfekvõ több szempontból is. Egyrészt a tesztelés alanya eleve egy ASP.NET-es alkalmazás, másrészt a feladat tipikusan web-alapú megoldást kíván.

1. A tesztelés folyamata

Egy Webes alkalmazás tesztelése ASP.NET segítségével új lehetõségeket ad a programozó kezébe, amelyek eddig nem igazán voltak megvalósíthatók. A legfontosabb ezek közül a két alkalmazás (a tesztelõ és a tesztelendõ) integrálása, amely során az eredeti alkalmazásba belekerül egy „hiba” feliratú gomb, amely minden lapon ott van. A gomb megnyomására a tesztelõ alkalmazás veszi át az uralmat a program fölött, és a következõket hajtja végre automatikusan:

• Képernyõfotót készít, amit elküld a hiba leírásával egyetemben a koordinátornak.

• A koordinátor szortírozza és osztályozza a hibákat és kiosztja a programozóknak (mindezt a tesztelõ rendszer segítségével teszi).

• A programozók a kijavított változatot eljuttatják ismét a tesztelõkhöz (automatikusan) és az egész kezdõdik elõrõl.

Ez a rövid leírás természetesen csak egy ízelítõ volt a szoftver mûködésérõl, a teljes verzió a cikk végére került.

Fontos megjegyezni, hogy az így elkészült tesztelõ rendszer igen hatékonyan támogatja a tesztelési folyamatot, azonban ez nem csak az ASP.NET érdeme.

2. Webes alkalmazások

A bevezetõben már volt szó az Internet adta lehetõségekrõl és a Webes alkalmazások korszerûségérõl, ebben a pontban az ASP.NET elõnyeit emelnénk ki.

Az ASP.NET – amellett, hogy szinte minden területen egy újabb és egyben hatékonyabb verziót jelent – számos forradalmi újítást is tartalmaz, amelyek közül csak a szorosan témához kapcsolódókat emelnénk ki (pl. a Web szolgáltatásokat nem):

• Szerver oldali kontrolok: szerveren futó komponensek, amelyek reagálnak eseményekre, adatokat tárolnak, HTML kódot generálnak, hogy ellássák azokat a feladatokat, amelyeket korábban nem objektum-orientált szemlélettel kellett megoldani. Az elõrelépés ezen a területen legalább akkora, mint a C és C# között.

• Tartalom és kód elválasztása: egy másik fontos újdonság a kód és a tartalom elválasztása, azaz a forráskód nem a HTML fájlba van beágyazva, hanem jól áttekinthetõ formában külön írható.

Ez a két tulajdonsága az ASP.NET-nek (sok más mellett) lehetõvé teszi, hogy azonos hatékonysággal tudjunk dolgozni vele, mint a Visual Studio más részeivel, azaz a funkcionalitásra koncentráljunk, ne pedig a technológiából adódó lassító köröket rójuk.

Összefoglalva az ASP.NET messze felülmúlta elõdjét, és nagyon hatékony eszköz lett a fejlesztõk kezében.

2. A tesztelési rendszer specifikációja

   1. Tesztforgatókönyvek megjelenítése és az eredmények rögzítése

      1. A forgatókönyvek kezelése

A rendszer a forgatókönyveket projekthez kapcsolva tárolja. Minden forgatókönyv egy projekthez tartozik.

A projektek létrehozhatók, bizonyos tulajdonságaik módosíthatók illetve a projektek törölhetõk. A projekt törlésével minden hozzá tartozó forgatókönyv is törlõdik.

Egy projekthez a következõ tulajdonságok tartoznak:

• a projekt neve

• ID (szöveges, szóköz nélküli)

• a létrehozás idõpontja

• leírás

• a létrehozó neve

A forgatókönyvek importálással hozhatók létre (lásd Forgatókönyvek importálása), bizonyos adataik módosíthatók és törölhetõk.

A forgatókönyvekhez hozzátartoznak a következõ tulajdonságok:

• cím

• ID (szöveges, szóköz nélküli)

• leírás

• eredeti dokumentum

2. A forgatókönyvek felépítése

   1. Forgatókönyvek importálása

A tesztforgatókönyvek Word dokumentum formátumban kerülnek elõállításra, elõre definiált template felhasználásával, ami biztosítja a forgatókönyvek azonos szerkezetét. A dokumentum struktúráját elõre definiált stílusok határozzák meg.

2. A forgatókönyvek formátuma

A forgatókönyvek formátuma késõbb kerül rögzítésre, egyelõre a következõ információk állnak rendelkezésre: A forgatókönyv egy általános bevezetõvel kezdõdik, majd hierarchiába rendezett tesztlépésekkel folytatódik. A lépések a hierarchia legalján található rövid szövegekbõl állnak. A magasabb hierarchia szinteken levõ címek nem tekintendõk tesztlépésnek, sikerességük az alsóbb hierarchiaszintek eredményeitõl függ.

A legfelsõ hierarchia szint a forgatókönyveket témákra osztja. Ezeknek külön nevük van, és a megjelenítésnél (lásd késõbb) hivatkozni lehet rájuk.

3. A forgatókönyvek végrehajtása

A lépéseket szigorúan a megadott sorrendben kell végrehajtani, kihagyni lépéseket nem lehet. Minden tesztlépés kimenetele lehet sikeres vagy sikertelen, amit a felhasználó jelez.

4. A forgatókönyvek megjelenítése

A felhasználói felületet egy böngészõben kell megjeleníteni. Fontos, hogy a megjelenõ adat jól tûrje a böngészõ átméretezését.

A megjelenített tartalom függ az URL paraméterként megadott projekt- és forgatókönyv ID-tõl, valamint a megadott témától. A megjelenõ oldal végén a felhasználó el tudja küldeni a tesztelési eredményt. Ha nincs minden lépés végrehajtva, meg kell kérdezni, hogy tényleg el akarja-e küldeni.

A felhasználó minden tesztlépéshez visszajelzést tud küldeni (lásd Visszajelzések küldése). Az adatok felvétele és tárolása a tesztelési feladathoz tartozik.

5. Tesztelési eredmények

A tesztelési eredmények lépésenként tartalmazzák a felhasználó által bejelölt státuszt (sikeres vagy sikertelen), illetve az esetleg hozzá csatolt visszajelzést is. Tárolni kell ezenkívül a felhasználó nevét, azonosítóját, az teszt idõpontját. Feltételezhetõ, hogy a rendszer intranetes, ActiveDirectory-s könyezetben fut.

1. Tesztelési eredmények lekérdezése

A tesztelési eredményeket le lehessen kérdezni egy adott forgatókönyvet megjelölve. Egy forgatókönyvhöz egyszerû statisztikát lehessen készíteni.

2. Tesztelési eredmények exportja

A tesztelési eredményt Word formátumban exportálni kell, az eredeti dokumentumnak megfelelõen, a felhasználó státuszaival együtt. Végül generálni kell a láblécet, amely a felhasználó nevét, a teszt idõpontját foglalja magában.

2. Visszajelzések küldése

A rendszer elsõdlegesen intranetes alkalmazáshoz készül, de biztosítani kell, hogy kisebb módosításokkal más alkalmazásokban is felhasználható legyen.

Készíteni kell egy komponenst, amely ASP.NET alapú weboldalakra rátehetõ, jól látható, és ahonnan elérhetõ a hiba rögzítésére készített felület. A linket használva a következõ adatok kerülnek rögzítésre:

Automatikusan kitöltésre kerülnek a következõ nem módosítható mezõk:

• Felhasználó neve

• Felhasználó e-mail címe

• Idõpont

• A számítógép konfigurációja (IE verziószám, nyelv, operációs rendszer, ...)

• Programverzió – külsõ input

Automatikusan tárolásra kerülnek, de nem jelennek meg:

• A hiba helye: alrendszer / modul / típus szinten – külsõ input

• Képernyõfénykép

• A teljes HTML kód az aktuális változókkal, késõbb visszaállítható módon

A felhasználó tölti ki:

• Hiba rövid leírása

• Megjegyzés mezõ

• Az aktuális tesztlépéshez tartozik-e

• Súlyosság

• Kicsi

• Közepes

• Nagy

• Prioritás

• Alacsony (felülettel kapcsolatos, ...)

• Közepes (komoly hiba, de lehet tõle tovább dolgozni)

• Magas (a rendszer tesztelése nem lehetséges, azonnal javítani kell)

A hibát egy adatbázisban kell rögzíteni.

Amennyiben a hiba egy tesztlépéshez tartozik, akkor ezt az adatbázisban is rögzíteni kell, visszakereshetõ módon.

3. Visszajelzések kezelése

A visszajelzés adatait az tesztelési koordinátorhoz (pl. alprojektvezetõ) el kell juttatni. Ez a rendszer globális paramétere. A késõbbiekben a hibariportot és visszajelzést szinonímaként használjuk

A hibariporthoz a következõ információkat tárolja még a rendszer, amelyek az alább leírt folyamatok során kerülnek kitöltésre:

• elõállítás módja: csak akkor, ha nem a tesztelési dokumentációban átadott funkcióra vonatkozik. A koordinátor vagy a fejlesztõ dokumentálja.

• megjegyzések (tesztelés vezetõje)

• megjegyzések (fejlesztõk – megoldás leírása, ...)

• megjegyzések (tesztelés)

• státuszok, idõsorosan: (visszakereshetõ)

• módosító személye

• módosítások dátuma

• fejlesztõ(k)

• tesztelõ(k)

A hibákat a tesztelés vezetõje elõállítja, priorizálja, megjegyzéseket fûz hozzá és kategorizálja (beállítja a státuszát):

• bug: javítás alatt

• Az érintett fejlesztõnek elküldi javításra.

• változás-kérelem: döntés alatt

• Változáskérelem generálása. E-mail küldés a megfelelõ személynek.

• lezárt: elvetett (technológiából következik, már megoldott, ...)

• lezárt: nem elõállítható (az információk alapján nem állítható elõ a hiba)

A fejlesztõ a hibát a következõ státuszokkal küldheti vissza:

• kijavítva, ellenõrzés alatt

• megjegyzéssel kell ellátni a javítás módjáról

• tesztelõnek elküdeni

• nem kijavított

• egyeztetett az alprojekt vezetõjével, és a javítás vagy nem megoldható (technológia, architektúra), vagy változáskérelemmel jár, vagy elvetett lesz.

A kijavított hibát a fejlesztõhöz rendelt tesztelõ ellenõrzi, és amikor kijavítottnak találja, a státuszát átállítja:

• lezárt, ellenõrizve

• Ki, mikor ellenõrizte.

Változáskérelem eredményeként a hibariportok a következõ státusszal záródhatnak le:

• lezárt, változás-kérelem: elfogadott

• Hivatkozás a változáskérelemre, a specifikációra.

• lezárt, változás-kérelem: elutasított

• Hivatkozás az elutasításra.

4. Technikai igények

Az egész rendszernek valamilyen jelzésküldõ mechanizmussal kell rendelkeznie. Ez lehet az email, azonban az egyes funkciók hatékony megvalósításához különbözõ technológiákat kell felhasználni.

Így elvárás, hogy a rendszer a megfelelõ helyeken taszkokat generáljon az Outlook feladatlistájába, a módosításokat egy intranetes felületen keresztül lehessen végrehajtani, a fejlesztõk pedig a VS.NET fejlesztõeszköz taszklistájában kapják meg a javítandó bugokat.

3. Irodalomjegyzék

David S. Platt: Introducing Microsoft.NET, Microsoft Press, 2001

Introduction to Microsoft ASP.NET, MOC, 2001

www.asp.net

www.gotdotnet.com

msdn.microsoft.com/library