4. fejezet - Teszt tervezési technikák

Az előző fejezetben áttekintettük a statikus tesztelési technikákat. Ezek a módszerek nem igénylik a tesztelendő rendszer futtatását, sőt bizonyos esetekben még a forráskód meglétét sem.

A dinamikus tesztelési technikák viszont a tesztelendő rendszer futtatását igénylik. Ebben a fejezetben a dinamikus tesztek tervezési kérdéseivel foglalkozunk. Definiáljuk a szükséges fogalmakat, megismerjük a teszt tervezési technikák megközelítési módjait, áttekintjük a legelterjedtebb specifikáció alapú, struktúra alapú és gyakorlat alapú tesztelési technikákat, majd megvizsgáljuk az egyes technikák közötti választás szempontjait.

A dinamikus tesztelési technikák elsősorban a komponens teszt, azon belül is főleg a unit-teszt (egységteszt) fázis eszköze.

Mivel a teszteléssel kapcsolatos magyar nyelvű irodalom máig is igen kevés, az érdeklődőbb hallgatók elsősorban az angol nyelvű szakirodalom tanulmányozása során juthatnak új ismeretekhez. Ennek megkönnyítésére a fontosabb fogalmak első előfordulása során annak angol nyelvű megnevezését is közöljük.

4.1. Alapfogalmak

A dinamikus tesztek tervezése alapvetően az alábbi három lépésből áll:

  1. A tesztelés alanyának, céljának meghatározása (test condition)

  2. Tesztesetek (test cases) specifikálása

  3. Teszt folyamat (test procedure) specifikálása

A tesztelési folyamathoz kapcsolódnak még a teszt készlet (test suite), hibamodell és lefedettség (test coverage) fogalmak is.

4.1.1. Tesztelés alanya (test condition)

A tesztelés alanya lehet rendszer egy olyan jellemzője, amely ellenőrizhető egy vagy több teszt esettel. Ilyen lehet például:

  1. funkció,

  2. tranzakció,

  3. képesség (feature),

  4. minőségi jellemző,

  5. strukturális elem.

4.1.2. Teszteset

Egy teszteset az alábbi összetevőkből áll:

  1. végrehajtási prekondíciók (preconditions)

  2. input értékek halmaza

  3. elvárt eredmény

  4. végrehajtási posztkondíciók (postconditions)

Egy teszteset célja egy meghatározott vezérlési út végrehajtatása a tesztelendő program egységben, vagy egy meghatározott követelmény teljesülésének ellenőrzése.

Egy teszteset végrehajtása esetén a rendszert egy megadott kezdő állapotban kell hozni (prekondíciók), megadott input értékek halmazával végre kell hajtatni a tesztelt elemet, majd a teszt futásának eredményét össze kell hasonlítani az elvárt eredménnyel és ellenőrizni kell, hogy a végrehajtás után a rendszer az elvárt állapotba (posztkondíciók) került-e.

Példaként tételezzünk fel egy olyan program modult, amely a felhasználótól bekér néhány adatot, és megnyomja a „Számolj”gombot. A modul a megadott adatokat és adatbázisban tárolt egyéb értékeket felhasználva elvégez valamilyen számítást, majd az eredményeket adatbázisba menti. Ennek a modulnak egy tesztesete tartalmazza:

  1. a felhasználói adatokat (input értékek halmaza),

  2. a számítás helyes eredményét (elvárt eredmény),

  3. prekondícióként azt, hogy a felhasználó megnyomta a „Számolj” gombot, és az adatbázis tartalmazza a számításhoz szükséges értékeket,

  4. posztkondícióként, hogy a számítás eredményei bekerültek az adatbázis megfelelő tábláiba.

4.1.3. Teszt specifikáció

Egy teszteset végrehajtásához szükséges tevékenységek sorozatának a leírása. Szokás teszt forgatókönyvnek (manual test script) is nevezni.

4.1.4. Tesztkészlet

Egy tesztkészlet tesztesetek és hozzájuk tartozó teszt specifikációk halmaza. Csoportosítható egy teszt alanyra, vagy egy vizsgált hibára.

A tesztkészletet megfelelő módon archiválni kell, mert egy tesztkészletet a fejlesztés során többször is végre kell hajtani, sőt, a rendszer későbbi változtatásainál is szerepet kap, annak ellenőrzésére használható, hogy a változtatás hatására nem keletkezett-e újabb hiba.

4.1.5. Hibamodell

Azon (feltételezett) szoftver hibák halmaza, amelyre a teszt tervezés irányul. A tesztesethez kapcsolódó példához a hibamodell azt rögzítheti, hogy az alábbi hibák következhetnek be:

  1. számítási hibák,

  2. adatbázis lekérdezési hibák (rossz adatokat használunk fel a számításhoz),

  3. az adatbázisba módosításának hibák (a számítás eredménye rosszul kerül be az adatbázisba).

A hibamodell a tesztesetek tervezéséhez ad támpontokat.

4.1.6. Teszt folyamat

Egy rendszer teljes tesztelésének megtervezéséhez (ami a teszt menedzsment egyik feladata, így a következő fejezetben foglalkozunk vele részletesebben), az alábbiakat foglalja magában:

  1. a szükséges tesztelési célok meghatározása,

  2. minden tesztelési célhoz a szükséges tesz készlet definiálása

  3. az egyes teszt készletekben foglalt tesztek ütemezésének és a végrehajtásuk dokumentálásának megtervezése.

A teszt folyamat terve a rendszer specifikációjának egy fejezete lehet, de összetettebb rendszerek esetén általában külön teszt specifikáció készül.

4.1.7. Teszt lefedettség

A teszt lefedettség a számszerű értékelése annak, hogy a tesztelési tevékenység mennyire alapos, illetve hogy egy adott időpontban hol tart. A „Már majdnem kész vagyok, főnök!” és a „Három hete ezen dolgozom, főnök!” meglehetősen szubjektív mértékek. (Nem tudom megállni ezen a ponton, hogy ne idézzem a szoftverfejlesztés egyik alapvető „természeti törvényét”: egy szoftver projekt a rendelkezésre álló idő 90%-ában 90%-os készültségi fokon áll…)

Amióta felismertük, hogy a tesztelés a fejlesztési folyamat fontos (és sajnos erőforrás igényes, tehát költséges) része, folyamatosan keressük a folyamat előrehaladásának a mérési lehetőségeit.

A teszt lefedettség számszerűsítése alkalmas a tesztelési tevékenységet értékelésére az alábbi szempontok szerint:

  1. Lehetőséget ad a tesztelési tevékenység minőségének mérésére.

  2. Lehetőség biztosít arra, hogy megbecsüljük, ennyi erőforrást kell még a fejlesztési projekt hátralevő idejében tesztelési tevékenységre fordítani.

Az egyes tesztelési technikák más és más lefedettségi mérőszámokat alkalmaznak. A specifikáció alapú technikák esetén arra adhatnak választ, hogy a követelmények milyen mértékben lettek tesztelve, a struktúra alapú technikák esetén pedig, hogy a kód milyen mértékben lett ellenőrizve.

A lefedettségi mérőszámok tehát arra nézve adnak információt, hogy milyen készültségi szinten áll a tesztelési tevékenység, és a tesztelési terv részeként meghatározzák, hogy milyen feltételek esetén tekinthetjük a tevékenységet késznek.