5. fejezet - Integrációs tesztek

Az integrációs tesztek az egységteszteket követik. Az egység teszt szorosan kapcsolódik az implementációs fázishoz, és biztosítja, hogy a részegységek önmagukban már helyesen működnek. Így ha az integrációs tesztek során hibát észlelünk, az feltehetőleg a modulok együttműködéséből adódik.

Az integrációs teszteknek következő fázisait különböztetjük meg:

  1. technikai integrációs teszt (Integration Level Testing, ILT),

  2. rendszerteszt (System Level Testing , SLT),

  3. elfogadtatási teszt (User Acceptance Testing, UAT).

Ezek különböznek az integráltság szintjében, és részben a céljaikban is.

5.1. Integration Level Testing (ILT)

Célja az együttműködő egységek vizsgálata. Ezért a teszteléshez egy részrendszert állítunk össze a már önmagában tesztelt elemekből. Ezek többnyire csak technikai, nem funkcionális részrendszerek, ezért probléma lehet a megfelelő tesztesetek előállítása.

Az ILT szemlélete elsősorban verifikációs, tehát a hibák megtalálására irányul.

5.1.1. Integrációs stratégiák

A részrendszerek összeépítésére és a tesztesetek megtervezésére és futtatására különböző stratégiák alakultak ki.

5.1.1.1. "Big-bang" integráció

Feltételezzük, hogy a rendszer minden egység rendelkezésre áll, és ezekből egyből a teljes rendszer építjük fel, azaz valójában az ITL kimarad, és egyből a System Level Testing következik. Előnye, hogy a testeseteket könnyebben le lehet vezetni a követelmény analízisből és nagyon kevés segédkódot kell írni a tesztek végrehajtásához. Hátránya viszont, hogy nagyon nehéz a hibák okát megtalálni, mert egy hibajelenséget több hiba együttese is okozhat (a hibák következményei "összemosódnak"). Ezért legfeljebb nagyon egyszerű rendszerek esetén alkalmazható

5.1.1.2. Inkrementációs integrációs és tesztelési stratégia

Ebben az esetben a rendszer elemeit fokozatosan integráljuk, és minden egyes integrációs szinten teszteket hajtunk végre. A folyamat tehát az alábbi lépésekből áll:

  1. Néhány elemet (modult vagy részrendszert) kombinálunk.

  2. Olyan teszteket futtatunk, amelyek csak az összeépített elemeket igénylik.

  3. Ha minden teszt sikeres, újabb elemeket teszünk hozzá a rendszerhez.

  4. További teszteseteket tervezünk, amelyek az új elemek meglétét is igénylik.

  5. Minden eddigi tesztet újra lefuttatunk.

A fenti iterációt addig folytatjuk, amíg a teljes rendszert összeépítettük, és azon valamennyi teszt sikeresen lefutott.

Példa:

Figyeljük meg, hogy a kibővített rendszeren újra kell futtatnunk az előzőleg már sikeresen lefutott teszteket is, hiszen nem lehetünk biztosak abban, hogy az újabb modulok integrációja nem okoz hibát a korábbi modulok működésében. Ez a futtatandó tesztesetek számának exponenciális növekedését jelenti, ami egy bonyolult rendszer esetén nagyon erőforrás igényessé teszi a folyamatot.

Mivel a tesztelés tárgya mindig csak egy részrendszer, annak működtetéséhez tesztelési környezetet kell biztosítani, ami segédkódok írását jelenti. A biztosítandó tesztelési környezet attól függ, milyen integrációs módszert alkalmazunk. Elvben két lehetséges megközelítés közül választhatunk:

  1. top-down integráció

  2. bottom-up integráció

Többnyire a két megközelítés valamilyen ötvözetét használják a gyakorlatban.

5.1.1.3. Top-down integráció

Folyamata:

  1. A hierarchia legfelső szintjén álló elem tesztelésével kezdjük.

  2. Az egy szinttel lejjebb álló elemek viselkedését és iterface-ét szimuláló ideiglenes elemek (stub) szükségesek.

  3. Ha a teszt sikeres, az ideiglenes elemeket a valódiakkal helyettesítjük, az általuk használtakat pedig újabb ideiglenes elemekkel szimuláljuk.

Előnyei:

  1. Jól illeszkedik a top-down programfejlesztési módszerekhez.

  2. Egy modul a megírása után rögtön tesztelhető.

  3. Az esetleges tervezési hibák korán kiderülnek, és idejében orvosolhatók.

  4. Viszonylag korán rendelkezésre áll egy korlátozott képességű rendszer.

Hátrányai:

  1. Bonyolult lehet a szimulációt végző ideiglenes rutinok megírása.

  2. A hierarchia felső szintjein álló modulok sokszor nem szolgáltatnak outputot. A teszteléshez külön eredmény-generáló "betétek" szükségesek.

5.1.1.4. Bottom-up integráció

  1. Először a legalsó szinten levő modulokat teszteljük, majd a hierarchiában felfelé haladunk.

  2. Ehhez a felső szinteket szimuláló tesztelési környezetet (test driver) kell írni.

  3. Ha a teszt sikeres, a teszt driver-eket a valódi implementált elemekre cseréljük, és a következő szintet helyettesítjük test driver-ekkel.