Tesztkörnyezet specifikáció

Azért döntöttem e mellett a téma mellett, mert úgy gondoltam, hogy életem első cikkében valami olyasmiről írnék, ami a szoftvertesztelési stratégia kialakításakor is az első feladatok között szerepel. Az effektív tesztkörnyezet kialakítása, megtervezése rendkívüli jelentőséggel bír, hisz e nélkül a környezet nélkül nem tudunk hozzáfogni a teszteléshez, mondhatjuk, hogy ez az első lépések egyike a szoftvertesztelési politikánk kialakításakor.

 Miért is van szükség külön tesztelői környezetre? Azért, mert a fejlesztői környezetben bármikor változhat a környezet tulajdonsága és a tesztelni kívánt szoftver paraméterei is, hiszen a fejlesztői csapat folyamatosan változtathatja a forráskódot. Az éles környezetben pedig azért nem célszerű tesztelni, mert akkor a cégen kívüli szereplők (végfelhasználók, versenytársak, stb.) is láthatják, hogy mire is készülünk valójában, milyen újítást kívánunk bevezetni, valamint az éles környezetben akár maradandó károsodást is okozhatunk. A téma részletesen taglalása előtt, első lépésként íme egy felsorolás, hogy mit is tartalmaz, milyen elemekből épül fel ez a cikk:

• „Tesztkörnyezet” jelentése
• Mi jellemez egy jól használható tesztkörnyezetet?
• Mi szükséges egy jól használható tesztkörnyezet kialakításához?
• Milyen hardver környezet szükséges a teszteléshez?
• Milyen operációs rendszeren történjen a tesztelés, milyen típusú processzorral rendelkezzen a számítógép?
• Szerepkörök meghatározása
• Költségelemzés készítése tesztkörnyezet kialakításához

Az írásom a következőképpen épül fel; a cikk első fele elmélet, a második fele pedig egy fiktív gyakorlati esetet taglal. Elsőként a következő kérdésre, -mely a cikk kulcskérdése is egyben- keresem a választ:

Mit jelent a „Tesztkörnyezet”?

• Tesztkörnyezet: Az a környezet, ami hardvert, beműszerezést, szimulátorokat, szoftvereszközöket és egyéb tesztelést segítő elemeket tartalmaz annak érdekében, hogy a tesztelést le lehessen folytatni.
• A tesztkörnyezetek különböző szolgáltatásokat nyújtanak a tesztek módszeres elvégzéséhez.
•  „Up to Date” rendszer – a módosítások ide is átvezetésre kerülnek, valid adatok vannak benne, patch-ek mint az élesen, adatbázisa is naprakész stb.)

A tesztkörnyezetek több komponensből épülnek fel, melyek a következők: 

• teszteket végrehajtó komponens (test driver, test harness, test bench),
• tesztkonfiguráció manager komponens (test CM), 
• tesztelendő egység „beműszerezésére” szolgáló komponens (instrumentation) 
• tesztelt egység külső szoftver környezetét szimuláló csonkok (stubs). 
  

Nézzük meg részletesen, hogy az egyes komponensek mire is valók! 

Test driver, test harness, test bench

• A tesztelő komponensek valamilyen formában biztosítják az előbb leírt tesztkörnyezetet egy adott hardver (rendszer architektúra) ill. szoftver környezetben (op.rendszer, programozási nyelv).
• A szolgáltatások köre általában a következő:
  • Automatizált tesztelés – mechanikus lépések, gyors végrehajtása
  • Debugger –részletek nyomon követése
  • Teljesítménytesztek és profilok készítése
  • Statikus analízis
  • Eredmények dokumentálása és megjelenítése. 
    

Fel kell mérnem, hogy mire van szükségem. El kell döntenem, hogy pontosan milyen szolgáltatások szükségesek számomra, ezt pedig csak alapos felmérés útján tudom eldönteni. 

Teszt konfiguráció management (CM)

• A teszt konfiguráció management célja:
  • szabályozottan biztosítsa a megfelelő szoftver egységek tesztelését
  •  a megfelelő teszt esetekkel
  •  megfelelően dokumentálja.
• Ez a szolgáltatás teremti meg a teszteket végrehajtó komponens működésének feltételeit, illetve magáért a működtetésért is felelős.
• Az alábbi folyamatok adminisztrációját kell elvégeznie:
  • cél egység “beműszerezése”,
  • tesztelő által megadott tesztesetek és teszt paraméterek alapján a teszt beállítása,
  • teszt elvégzése és az eredmények értékelése, kezelése.

 Instrumentation

• A teszteléshez a szoftveregységet felszereljük a működéséről tájékoztató, a teszt megkívánta helyzetek azonosításához, lefedettségi adatok szolgáltatásához valamint a teszt közbeni beavatkozáshoz szükséges kapcsolódási pontokkal, „jeladókkal”. 
• Ez a “műszerezettség” teremti meg a kapcsolódási pontokat a tesztvégrehajtó komponens és a tesztelt egység között. 
• Kétféle beműszerezésről beszélhetünk: 
  • a forráskód beműszerezése (debuggolást segítő, adatokat naplózó, kontextusokat azonosító program kódot írunk a szoftver forráskódjába) 
  • a végrehajtható kód beműszerezése (fordításkor történik, a forráskód változtatása nélkül) 

A forráskód műszerezés széles körben alkalmazható és nagy szabadságot biztosít a teszteléskor, de nehéz karbantartani, megnöveli a fordítás/tesztelés ciklus idejét és nem utolsó sorban módosítja az eredeti kódot, aminek mellékhatásai lehetnek.

A végrehajtható kód műszerezése. Ilyen jellegű műszerezés pl. a végrehajtható kódot a forráskóddal összekapcsoló debug információk elhelyezése. Léteznek úgynevezett patch szintű eszközök, melyek a forráskód nélkül, a végrehajtható kód futásakor lépnek működésbe (dynamic action linking). A végrehajtható kód műszerezés csak korlátozottan használható, de ugyanakkor működés közben csak minimálisan zavaró.  

Stubs

• A hierarchia legfelső szintjén álló elem teszteléséhez az eggyel lejjebb álló elemek viselkedését és interface-ét szimuláló ideiglenes elemek (stub) szükségesek.
• A csonkok ugyanolyan interfésszel rendelkeznek, mint a komponens, de nagyon korlátozott funkcionalitással. 
• Megadható,hogy teszteléskor az egyes meghívásokkor milyen visszatérési értékei legyenek a szimulált függvénynek. 
• A csonkok szimulálják a funkciókat az integrációs tesztelésnél. 

A stubok validálásnál jól használhatóak, a felhasználó látja, hogy hoppá, én nem ezt akartam. Így lehetőség van a gyors és “fájdalommentes” változtatásokra. A stuboknak az adott funkciót viszont teljes értékűen kell szimulálnia, a tesztelés szempontjából.  Miután áttekintettük, hogy mit is jelent a tesztkörnyezet, a következő kérdést kell boncolgatnunk: 

Mi jellemez egy jól használható tesztkörnyezetet?

• Fejlesztők / tesztelők munkavégzésének támogatása
• Fejlesztői / QA tesztelői / UAT / verzióváltó környezet szétválasztása
• Éles rendszerekkel megegyező konfigurációjú
• Fejlesztői / tesztelői segédalkalmazások elérhetősége
• Mentés / visszaállítás lehetőségének biztosítása
• Az éles rendszertől teljesen független környezet
• Kiemelt biztonságú környezetű
• Felhasználók azonosíthatóságának megtartása
• Adattranszformáció / adat neutralizálás / adatvariancia a tesztadatokra
• Licence-kezelés biztosítása és megfelelősége 
  

Vizsgáljuk meg a fenti listánkat kicsit részletesebben, kifejtem, hogy pontosan mire is gondoltam az egyes elemeknél:

• Fejlesztők munkavégzésének támogatása: A fejlesztés esetenként külsős fejlesztők bevonásával történik. A rendszernek hozzáférést kell biztosítania külsős (jellemzően Interneten keresztül kapcsolódó) és belsős fejlesztők számára. 
• Verzióváltó (élessel megegyező, úgynevezett mirror) környezet kialakítása 
• Fejlesztői / tesztelői / UAT környezet szétválasztása: A fejlesztők nem nyúlhatnak bele  a tesztelői, illetve az UAT környezetbe. Célszerű mind a 3 környezetet más domain-be rakni/helyezni. 
• Éles rendszerekkel megegyező konfigurációjú környezetek kialakítása: A fejlesztéshez elengedhetetlen a kialakítandó környezetek megegyezősége az éles rendszerekhez. Az éles rendszerben bekövetkező változások követésére is lehetőséget kell biztosítani. 
• Fejlesztői segédalkalmazások elérhetősége: A fejlesztői alkalmazásokat elérhetővé kell tenni a környezetben. 
• Verziókövető (Subversion, Git, CVS, stb..): Verziókövetésre használt alkalmazás, a fejlesztések forráskódjait és azok változását tárolja. 
• Hibakezelő (Trac, Mantis, Jira, stb..): Hibajegy kezelő rendszer, melyet a fejlesztés teljes életciklusában elérhetővé kell tenni 
• Mentés lehetőségének biztosítása: A teszt környezetek kezdeti és eseti mentésének biztosítására van szükség. A mentésből történő visszaállítás a fejlesztés során mint előző stabil verzióra történő visszaállás lehetséges. 

A fejlesztői igények mellet az üzemeltetés és rendszertechnika a következő igényeket támasztja a kialakítandó rendszerrel szemben:

• Az éles rendszertől teljesen független környezet: Mivel a fejlesztői környezetben az éles rendszerrel adott esetben megegyező konfigurációjú szerverek találhatóak, szükséges a teljes leválasztás, a teszt szerverek semmilyen kommunikációt nem folytathatnak az éles környezettel. 
• Kiemelt biztonságú környezet: A tesztkörnyezet biztonságának legalább az éles környezet biztonságát el kell érnie, mivel üzletileg kritikus alkalmazások felépítéséről támadáshoz hasznos információ nyerhető ki kompromittálódásuk esetén.
• Felhasználók azonosíthatóságának megtartása: A fejlesztői környezetben is szükséges a felhasználók folyamatos azonosíthatóságának és jogosultságuk szabályozásának lehetősége. 
• Adattranszformáció a tesztadatokra: Az éles rendszerből átvett adatok transzformációja szükséges, mely biztosítja az adatok védelmét és az előállt tesztadatok felhasználhatóságát anélkül, hogy üzleti információk tényleges felhasználása történne. 
• Licence-kezelés biztosítása és megfelelősége: A fejlesztői környezetekben felhasznált licenceknek teljesen legálisnak és fejlesztési célokra felhasználhatóknak kell maradniuk. 

A cikk második felében egy fiktív gyakorlati példát veszünk alapul. Ebben a példában egy olyan céget feltételezünk, ahol kevés, de erős gépeink vannak, van egy igen speciális környezetünk (AS/400), valamint fontos, hogy a tesztkörnyezet biztonságos és jól elkülöníthető legyen az éles rendszertől. Mindezek mellett tegyük fel, hogy szeretnénk, ha a tesztkörnyezet felépítése során alkalmazott megoldásoknak hivatalos támogatásuk legyen azért, hogy amennyiben bármilyen probléma merül fel, akkor azt minél hamarabb meg lehessen oldani, illetve, tegyük fel, hogy az adatokat deperszonalizálni szükséges ahhoz, hogy azokat felhasználhassuk tesztelésre. 

Első lépésként mindenképpen tisztáznunk kell, hogy mi szükséges egy jól használható tesztkörnyezet kialakításához! Erre a kérdésre a legegyszerűbb úgy válaszolni, ha magunkban egy kicsit átfogalmazzuk ezt a kérdést a következő módon: “Mi szükséges ahhoz, hogy egy jól használható tesztkörnyezetet alakítsak ki saját magamnak/csoportomnak?”. Ezzel az átfogalmazással sokkal könnyebb lesz válaszolnunk az eredeti kérdésre:

Mi szükséges egy jól használható tesztkörnyezet kialakításához?

• Koncepció kialakítása:
  • Mit szeretnénk tesztelni? 
  • Kik használják a környezetet? 
  • Mennyi tesztelés / fejlesztés folyik párhuzamosan?
  • Hogyan illeszkedik a tesztelési folyamathoz a kialakítandó környezet? 
  • Entry / Exit kritérium(ok) meghatározása 
  • Test és Test Management eszközök kiválasztása, összehangolása 
• Szükséges erőforrás felmérése:
  • Hardver 
  • Szoftver 
  • Üzemeltetési 
• Költségelemzés készítése 

Milyen hardver környezet szükséges a teszteléshez?

• Tesztelés / Fejlesztés függő 
• Hardver specifikus 
  • Speciális hardver szükséges (Pl.:  AS/400) 
  • Szoftver tesztelhetősége függ a hardvertől (Pl.: Firmware) 
• Szoftver specifikus 
  • Speciális szoftver környezet szükséges hozzá (Pl.: Front End for Core systems) 

A fennálló helyzet miatt (kevés, de erős gépek) a virtualizáció felel meg szerintem a leginkább az adott helyzetben. 

Miután ezt már eldöntöttem, a következő kérdésre kell megtalálnom a választ: 

Milyen operációs rendszeren történjen a tesztelés, milyen típusú processzorral rendelkezzen a számítógép?

•  Egy jól használható tesztkörnyezet kialakításakor célszerű virtuális gépekre építve biztosítani a fejlesztéshez szükséges erőforrások megfelelő kihasználását, mely a környezetek újrafelhasználásának lehetőségeit is magában rejti. 
• Abban az esetben, ha az adott komponens nem virtualizálható (az operációs rendszere nem támogatja) lehetőség van fizikai gépek bevonására a tesztelés érdekében.   

Lehetséges virtualizációs megoldások a példánkban:

• VMWare alkalmazások 
• Microsoft Virtual Server és PC 
• Oracle VirtualBox 
• Xen alapú megoldások (Pl.: Citrix Xen Server) 
• Paralells Workstation és Server stb. 

Hosszas mérlegelés után én a VMWare megoldását választanám. Természetesen meg kell jegyeznem, hogy úgy a legegyszerűbb eldönteni, hogy melyik megoldást választom, ha összefoglalom egy táblázatban, hogy az adott megoldás/termék mit tud, és utána összehasonlítom őket egymással. Nem szabad azonban arról sem megfeledkeznünk, hogy az is számít, hogy az adott cégnél milyen tudás található meg. Mindezek fényében a cég igényeit, a saját és a cég tudását figyelembe véve véleményem szerint ez a szoftveralkalmazás (VMWare ) a legelőnyösebb. Fontos, hogy mindig mérlegeljünk, hogy mi mit szeretnénk, és csak azután kezdjük el megvizsgálni a szóba jöhető alkalmazásokat.  

Az általam elképzelt tesztelői környezet vázlatát a következő ábra mutatja:

Virtuális teszt környezetek létrehozása

Adott virtuális tesztkörnyezet létrehozására két lehetőségünk van: 

• Éles környezet konvertálása: A VMWare Converter programjának segítségével lehetséges a meglévő környezet másolása és virtuális környezetbe helyezése. A konvertálás után minimális rendszergazdai beavatkozással (vírusirtó konfigurálás, IP-beállítások) a környezet rendelkezésre áll. Hátránya, hogy az éles környezettel megegyező licencek szükségesek a használatához. 
• Új környezet telepítése: Az éles rendszerek implementációs terve és telepítési jegyzőkönyve alapján lehetőség van a rendszer telepítésére a tesztkörnyezetben is. Ebben az esetben lehetőség van fejlesztői licencek megadására amennyiben az adott alkalmazásokhoz létezik ilyen. A fejlesztői licencek költsége lényegesen alacsonyabb, mint a produktív licenceké, ezáltal a költség alacsonyan tartható. Ebben az esetben a fejlesztők feladata eldönteni, hogy a környezet megfelel-e a fejlesztés számára, a fejlesztői licencek használata nem befolyásolja-e a működést. 

Mindkét esetben szükséges az éles rendszerek adatainak transzformációja, a tesztkörnyezetben nem megengedett éles adatok felhasználása és tárolása sem. 

A virtuális gépek egy fejlesztői/tesztelői  VLAN-ba kerülnek, ezzel garantálva az éles rendszertől történő elválasztást. 

A VLAN kialakítása során a VMWare Farm dedikált hálózati kártyái és a VMWare Farm által létrehozott virtuális switch-ek is ebbe a hálózatba kerülnek elhelyezésre.
A hálózatból más hálózatokba forgalom csak a tűzfalon keresztül történhet a következők szerint:

Tekintsük át, hogy pontosan milyen szoftverek szükségesek számunkra a fentiekben lerajzolt környezet megvalósításához: 

Szoftver követelmény:

• VMWare ESX Server 
• VMWare Virtual Center 
• VMWare Lab Manager 
• VMWare Virtual Desktop Infrastructure VMWare Backup Agent Server 
• Windows XP 
• Windows 2003 Server + AD 
• Teszt és Tesztmanagement eszközök 
• EPO DB2 Server 

Hardver követelmény: 

• AS/400 
• IBM Blade Server 

Tekintsük át a felsorolt listát kicsit részletesebben: 

• VMWare ESX Server: A virtuális gépeket futtató hoszt szervereken fut, az erőforrások biztosításáért felel. Farm működésben kerül kiépítésre, a fizikai szerverek erőforrásai ezáltal egy közös pool-t képeznek. Az egyes környezetek kialakítása során lehetőség van erőforrás priorizálásra, szükség esetén egyes környezetek állandó futásra is felkészíthetőek. 
• VMWare Virtual Center: A virtuális gépeket felügyelő központi menedzsmentalkalmazás. Segítségével alakítjuk ki a környezeteket és szabályozzuk a farm erőforrás elosztását. 
• VMWare Lab Manager (VMWare Virtual Center szerveren fut): A virtuális gépek indítását és leállítását, mentések igénylését lehetővé tevő alkalmazás, elsősorban a végfelhasználók (jelen környezetben a fejlesztők) számára. Segítségével elkerülhető a rendszergazdák közreműködése a már meglévő teszt környezetek használata során. 
• VMWare Virtual Desktop Infrastructure (Prezentációs Szerveren fut): A virtuális desktopok elérését szabályozó alkalmazás. Ennek segítségével érik el a felhasználók a részükre kijelölt virtuális desktopot. 
• VMWare Backup Agent Server: A környezetek mentéséhez szükséges segédalkalmazás. Integrálva a jelenleg üzemelő IBM Tivoli mentési rendszeréhez lehetővé teszi a fejlesztői környezetek ütemezett és alkalmi mentését. 
• Active Directory: Ez a szerver a fejlesztői környezet jogosultságkezeléséért felel. Segítségével a fejlesztői környezetben az éles környezettől eltérő jogosultsági rend kialakítására van lehetőség. 
• EPO: Az EPO szerver a tesztkörnyezet vírusmentesítéséért felel. A biztonsági beállításai megegyeznek az éles környezet beállításaival. 
• Teszt és Teszt management eszköz: A tesztelők munkájához szükséges alkalmazásokat szolgáltató szerver. Itt kell megjegyeznünk a következő fontos információkat: 
• Virtuális Desktopok 
  • Minden tesztelő számára kialakításra kerül egy dedikált virtuális desktop. A desktopokon telepítve található a fejlesztéshez szükséges összes fejlesztőeszköz, illetve elérhető a számukra kijelölt aktuális tesztkörnyezet. 
  • A desktopok elérése a DMZ-be helyezett szervereken keresztül lehetséges, ezzel biztosítva a megfelelő biztonsági szintet. 
• Azonosító szerver 
  • Az azonosító szervere segítségével szabályozzuk a rendszer tesztelők által történő elérését. Az azonosító szerver a következőket kell hogy támogassa: 
  • Erős azonosítás, lehetőleg token segítségével 
  • One-time logon lehetősége 
  • Felügyelt munkavégzés lehetőségének támogatása 
  • Munkavégzés rögzítésének támogatása 
  • Az azonosító szerver használata elsősorban az interneten keresztül történő bejelentkezéshez kerül kialakításra, javasolt azonban a belső fejlesztők munkavégzéséhez is biztosítani a rendszer adta lehetőségeket. 
  • Az azonosító szerver kialakítására lehetőséget nyújt az RSA cég számos megoldása, vagy azzal egyenértékű komponensek. 
• Prezentációs szerver 
  • A prezentációs szerver feladata a virtuális desktopok böngészőn keresztül történő elérhetőségének biztosítása. Elvárások a szerverrel szemben: 
    • Integráció az azonosító szerverrel 
    • SSL támogatás 
    • Integráció a VMWare Virtual Desktop Infrastrucutre-el 
    • Felügyelt munkavégzés lehetőségének biztosítása 
    • Munkavégzés rögzítésének biztosítása 
    • Browser alapú GUI biztosítása 
    • Kliens oldali ellenőrzés futtatása, minimum követelmények kikényszerítése (vírusirtó megléte stb.) 
    • Fájlmásolás lehetőségének biztosítása 
    • A prezentációs szerverre lehetőség a Microsoft Forefront Security Internet Application Gateway vagy más gyártó hasonló megoldása. 
• AS/400 teszt partíciók 
  • Mivel az AS/400 virtualizációja VMware segítségével nem lehetséges, a meglévő teszt partíciók a VLAN-ba közvetlenül bekötésre kerülnek.   
• Szerepkörök felosztása:Fontos, hogy ne csak a környezeteket és eszközöket definiáljuk, hanem a szerepköröket is, azaz azt, hogy ki mihez is férhet hozzá pontosan. A teljesség igénye nélkül vegyük át, hogy melyek lehetnek ezek a szerepkörök:

• Fejlesztői 
• QA Tesztelői
• Üzleti tesztelői 
• Üzemeltetési Technikai felhasználói

Fontos megjegyezni és észben tartani, hogy mindenképpen tervezzük meg a célunk eléréséhez vezető lépéseket! Vegyük át ezeket a lépéseket az alábbiakban!

Tesztkörnyezet kialakításának lépései:

Három fő lépést kell megkülönböztetni: 

• Tesztkörnyezet tervezés 
• Kockázatokra való felkészülés 
• Költségelemzés 

Ahhoz, hogy egy jól használható tesztkörnyezetet lehessen megtervezni, létrehozni és üzemeltetni, a fenti lépések folyamatos iterálása szükséges.

Így a cikk vége felé szeretnék egy kis kiindulási segítséget nyújtani a költségelemzés elkészítéséhez a fenti példát alapul véve:A költségelemzést három részre kell bontani. Példánkban ez a következő költségeket jelenti: 

• Hardver költség 
  • AS/400 hardver költség 
  • IBM Blade szerver költség 
• Szoftver költség 
  • VMWare ESX Infrastructure licence-költség 
  • Microsoft termékek licence-költsége 
  • IBM termékek licence-költsége 
• Humán erőforrás költség
  • Üzemeltetés / Rendszertechnika erőforrás költség a kialakításhoz / üzemeltetéshez 

A költségelemzés elvégzése után készen is van a tesztkörnyezet specifikáció kialakítása, megtervezése. Mindezek után már csak a gyakorlati megvalósítás van hátra! 

A cikkem végéhez érve remélem, hogy sikerült egy kis kiindulási segítséget nyújtanom azoknak, akik most szeretnének kialakítani egy tesztkörnyezetet, illetve azoknak, akik szeretnék hatékonyabbá tenni a már meglévő tesztkörnyezetüket. Mindenképpen szeretném megjegyezni, hogy minden esetet külön-külön kell megvizsgálnunk, hiszen nem lehet minden környezetet egy sémára ráhúzni a különböző követelmények és lehetőségek miatt. Ez a cikk csak annyit szeretne elérni, hogy segítséget nyújtson a kialakítás megkezdéséhez egy jó kiindulási alapot szolgáltatva, iránymutatást nyújtva, ami alapján mindenki el tud indulni és ki tudja alakítani a saját testre/(cégre)szabott tesztkörnyezetét. Jó munkát és sok sikert kívánok!

Szerző: Szenfner János