ISTQB

CTFL - Alapszintű képesítés

Készült:
 A szoftvertesztelés alapjai (2009),
 Hivatalos magyar nyelvű tanterv (2012)
 Szoftvertesztelés egységesített kifejezéseinek gyűjteménye (2014)
 Training360 online tanfolyam (2013)
alapján.
1 A tesztelés alapjai
1.1 Miért szükséges a tesztelés? (K2)
1.1.1 Szoftverrendszerek környezete (K1)
 A tesztelés függ a körülményektől (6. tesztelési alapelv):
Különböző körülmények esetén különböző módon hajtják végre a tesztelést.
 Kockázat (risk): Egy lehetséges probléma; az a tényező, amely a jövőben negatív
következményeket okozhat. Általában, mint hatás és valószínűség jelenik meg.
o Két dolgot kell figyelembe venni: egyrészt, hogy mekkora a bekövetkezés
valószínűsége, és hogy mik a lehetséges hatások.
o A problémák egy része a szoftverhasználat során jelentéktelen, de akadnak olyanok
is, amelyek költségesek, károsak, idő, pénz és üzleti hírnév elvesztését eredményezik,
de akár sérülést vagy halált is okozhatnak.

1.1.2 A szoftverhibák okai (K2)

Tévedés, hiba Hiba Meghibásodás

(error, mistake) (bug, defect, fault) (failure)

Határidő Lehet kódban vagy Okozhatja külső hatás

Komplexitás dokumentációban is.
Ismeretek hiánya Nem minden
programhibából lesz
meghibásodás

 Emberi eredetű hiba (error, mistake): Emberi tevékenység, amely során helytelen eredmény
jön létre.
 Program hiba (bug, defect, fault): A program olyan belső hibája, amely azt eredményezheti,
hogy a szoftver nem tudja teljesíteni az elvárt viselkedést, azaz a program meghibásodásához
vezethet.
 Meghibásodás (failure): Bármely programhibának lehetnek olyan következményei, amelyek
azt eredményezik, hogy a rendszer nem azt teszi, amit kellene.
A komponens, illetve a rendszer eltér az elvárt eredménytől vagy szolgáltatástól.
 Egy ERROR DEFECT-hez vezethet, mely FAILURE-t okozhat.
 Meghibásodást okozhatnak a környezeti viszonyok is: a sugárzás, a mágnesesség, az
elektromos mezők és a szennyezés a hardvertulajdonságok megváltoztatásával
hibaeseményeket okozhatnak, vagy befolyásolhatják a szoftver futását.

1.1.3 A tesztelés szerepe a szoftverfejlesztésben, karbantartásban és üzemeltetésben

(K2)
 A rendszerek és a dokumentáció szigorú tesztelése hozzájárulhat a használat során fellépő
problémák kockázatának csökkentéséhez valamint a szoftverrendszer minőségének
javításához azáltal, hogy a talált hibákat a rendszer kibocsátása előtt kijavítják.
 Tesztelés során a teljes rendszert vizsgáljuk:
o Szoftver

1
 o Hardver
o Dokumentáció
 A szoftvertesztelésre szükség lehet akkor is, ha a szoftvernek szerződésben foglalt, vagy jogi
előírásoknak, ipari és kódolási szabványoknak kell megfelelnie.

1.1.4 A tesztelés és a minőség (K2)

 A tesztelés lehetőséget teremt a szoftver-minőség mérésére a talált hibák alapján, mind a
funkcionális, mind a nem-funkcionális szoftverkövetelmények valamint a jellemzők terén
(például megbízhatóság, használhatóság, hatékonyság, karbantarthatóság és hordozhatóság).
A tesztelés méri és javítja a szoftver minőségét.
 Visszacsatolás a szoftver aktuális állapotáról.
 Növeli a bizalmat a szoftver minősége iránt.
 Minél többet tesztelünk, annál kisebb a valószínűsége, hogy (súlyos) hibák maradnak a
rendszerben, ezáltal csökken a kockázati szint.
 Akkor megfelelő a szoftver minősége, ha csak keveset, vagy egyáltalán nem találunk
programhibát (kellően szigorú tesztelésnél érvényes).
 Minőség (quality): Az a szint, amikor a komponens, rendszer vagy folyamat megfelel a
meghatározott követelményeknek és/vagy a felhasználó/ügyfél igényeinek és elvárásainak.
[IEEE 610]
 A korábbi projektek tapasztalatait fel kell használni. A régebbi projektekben talált hibák
kiváltó okainak megértésével a folyamatok javíthatók, így kiküszöbölhetjük ezen hibák újbóli
megjelenését, ezáltal javul a jövőbeni rendszerek minősége.
 A minőségbiztosítás egyik kiemelt területe a tesztelés.

1.1.5 Mennyi tesztelés elegendő? (K2)

 Az, hogy mennyi időnk és
MINŐSÉG mennyi pénzünk van a
tesztelésre, az
meghatározza a
minőséget.
 Ha sok időnk van, és
magas a minőség, ahhoz
sok pénz kell
Funkció

IDŐ PÉNZ

2
  Ha magas a minőség, és sok pénzünk van, akkor sok időt kell a tesztelésbe beleölni.
 A minőség rántja magával a másik két feltételt: ha minőségi terméket akarunk előállítani,
akkor megfelelő mennyiségű időt és pénzt kell áldozni rá.
 Nem lehetséges a kimerítő teszt (2. tesztelési alapelv):
Mindenre kiterjedő tesztelés – a triviális eseteket leszámítva – nem lehetséges. Helyette
kockázat elemzéseket és prioritásokat kell alkalmazni, növelve a hatékonyságot.
 Kimerítő teszt (exhaustive testing): Olyan tesztelés, amely során a tesztkészletünk magában
foglalja a bemeneti értékek és előfeltételek összes kombinációját.
 Ahhoz, hogy eldönthessük, mennyi tesztelés elegendő, figyelembe kell vennünk a kockázati
szintet, beleértve a technikai- és vállalati termékek, projektek kockázatát valamint a
projektek időre és költségvetésre vonatkozó megkötéseit
 A tesztelésnek elegendő információt kell biztosítania a projekt résztvevői számára:
o Mikorra várható, hogy a termék kiadható?
o Kibocsátható-e a szoftver egy adott pillanatban?
o Melyek a problémás területek?
o Mi az, ami jól működik?

1.2 Mi a tesztelés (K2)

1.2.1 Szoftvertesztelés definíciója
 Általános értelemben a tesztelés tesztek végrehatását jelenti (automatikus, manuális)
 Tágabb értelemben magába foglalja:
o Teszttervezés
o Tesztirányítás
o Tesztelési feltételek meghatározása
o Teszteset tervezés
o Tesztek végrehajtása
o Eredmények kiértékelése
o Jelentés, riport készítés (dokumentálás)
o Lezárás
 Tesztelés (testing): az összes szoftverfejlesztési életciklushoz kapcsolódó akár statikus, akár
dinamikus folyamat, amely kapcsolatban áll a szoftver termékek tervezésével, elkészítésével
és kiértékelésével, hogy megállapítsa, hogy a szoftver termék teljesíti-e a meghatározott
követelményeket, megfelel-e a célnak. A tesztelés felelős a szoftvertermékkel kapcsolatos
hibák megtalálásáért.
o A tesztelés inkább folyamat, mint egyszeri tevékenység
o Az egész szoftverfejlesztési életcikluson végighúzódik
o A tesztbázis olyan dokumentumokat is tartalmaz, mint a követelmények és
tervspecifikációk.
o Követelmény (requirement): olyan feltétel vagy képesség, amely a felhasználó
számára azért szükséges, hogy megoldjon egy problémát vagy elérjen egy célt. Ezen
feltételnek vagy képességnek a rendszer vagy rendszer komponens által is
megvalósíthatónak kell lennie, úgy, hogy közben a szerződés, szabvány, specifikáció
és egyéb formális dokumentumban támasztott követelményeknek is megfeleljen.
[IEEE 610]
o Akár statikus, akár dinamikus:

3
  dinamikus, amikor futtatjuk a szoftverkódot
 statikus pl. a dokumentumok felülvizsgálata
o Felülvizsgálat (review): egy termék vagy projekt státuszának értékelése. Célja, hogy
feltérképezze az eltéréseket a tervezett eredményekhez képest, valamint ajánlást
tegyen a továbblépéshez. Több típusa van, például: menedzsment felülvizsgálat,
informális felülvizsgálat, technikai felülvizsgálat, inspekció, átvizsgálás.
[IEEE 1028 alapján]
o Tervezés: Menedzselni kell a tesztelést
o Előkészítés: El kell döntenünk, hogy milyen jellegű tesztelést végzünk, ki kell
választanunk a tesztelési feltételeket, és meg kell tervezni a teszteseteket.
o Teszteset (test case): bemeneti értékek, végrehajtási előfeltételek, várt eredmények
és végrehajtási utófeltételek halmaza, amelyeket egy konkrét célért vagy a tesztért
fejlesztettek (például egy program forgatókönyv végrehajtása, vagy egy
követelménynek való megfelelés). [IEEE 610 alapján]

1.2.2 Tesztelési cél

 Tesztelési cél (test objective): A műszaki teszttervezés, illetve a tesztvégrehajtás célja
 Különböző tesztelési célkitűzések léteznek:
o megtalálni a programhibákat
o növelni a minőséggel kapcsolatos megbízhatóságot, információt nyújtani;
o megelőzni a hibákat
 Az életciklus kezdetén átgondolt műszaki teszttervek (a tesztbázis ellenőrzése a tesztelés
tervezésével) segíthetnek annak megelőzésében, hogy hibák kerüljenek a kódba. A
dokumentumok (például a követelmények) felülvizsgálata is segít annak megelőzésében,
hogy hibák kerüljenek a kódba.

1.2.3 Tesztelési szempontok

A tesztelés különböző szempontok szerint történhet, melyek más-más célokra vonatkoznak.
 A fejlesztői teszt (development testing) (például a komponens-, integrációs- és
rendszerteszt) fő célja lehet például az, hogy a lehető legtöbb meghibásodást kiváltsa, ezzel a
szoftverhibákat felismerhetik és javíthatják.
 Az átvételi teszt (acceptance testing) fő célja annak igazolása lehet, hogy a rendszer az
elvárásoknak megfelelően működik, illetve megbizonyosodni arról, hogy a rendszer teljesíti-e
a követelményeket. Bizonyos esetekben a tesztelés fő célja a szoftver minőségének elemzése
lehet (hibák javítására irányuló szándék nélkül) azért, hogy a projekt-résztvevők megtudják,
hogy adott időpontban milyen kockázattal járna a rendszer kiadása.
 A karbantartási teszt (maintenance testing) során gyakran arra vonatkozó tesztet végeznek,
hogy a változtatások során nem kerültek-e be újabb hibák a rendszerbe.
 A működési teszt (operational testing) fő célja a rendszer olyan jellemzőinek elemzése lehet,
mint például a megbízhatóság vagy rendelkezésre állás. [IEEE 610]

1.2.4 Tesztelés és hibakeresés

A hibakeresés (debugging) és a tesztelés két különböző fogalom:
A tesztelés kimutathatja a programhibák által okozott meghibásodásokat. A hibakeresés pedig egy
fejlesztői tevékenység, mely során felderítik a hibák okát, kijavítják a kódot és ellenőrzik, hogy a hibát
megfelelően orvosolták-e. Ezt követően egy tesztelő által végrehajtott ellenőrző teszttel
bizonyosodnak meg arról, hogy a javítás eredményes volt. A feladatok más-más felelősségi körbe

4
tartoznak: a tesztelést a tesztelők, a hibakeresést a fejlesztők végzik.

1.3 Általános tesztelési alapelvek (K2)

1. alapelv – A tesztelés hibák jelenlétét jelzi (Testing shows presence of defects)

Bár tesztelés kimutathatja a hibák jelenlétét, de azt nem képes igazolni, hogy nincsenek hibák. A
teszteléssel csökken annak az esélye, hogy a szoftverben felfedezetlen hibák maradnak, de ha nem
találnak hibát, az nem annak a bizonyítéka, hogy a rendszer tökéletes (értsd: valóban nincs benne
hiba)

2. alapelv – Nem lehetséges kimerítő teszt (Exhaustive testing is impossible)

Kimerítő tesztelés – azaz mindenre (a bemenetek és előfeltételek minden kombinációjára) kiterjedő

tesztelés – a triviális eseteket leszámítva – nem lehetséges. A kimerítő teszt helyett kockázatelemzést
és prioritásokat kell alkalmazni, ezáltal növelve a teszttevékenységek összpontosításának
hatékonyságát.
Kockázat alapú megközelítés: minél kevesebb teszttel fedjük le a szoftver minél nagyobb részét,
különös tekintettel a fontos részekre.

3. alapelv – Korai teszt (Early testing)

A tesztelést a szoftver vagy rendszerfejlesztési életciklusában a lehető legkorábban el kell kezdeni, és

előre meghatározott célokra kell összpontosítani.
Minél hamarabb megtalálunk egy hibát, annál olcsóbb javítani.

4. alapelv – Hibák csoportosulása (Defect clustering)

A rendszerben a hibák eloszlása nem egyenletes, a megtalált hibák többsége néhány modulban van,
vagy legalábbis ezen modulok felelősek a működési hibák többségéért.
Pareto-elv: A hibák 80%-a a modulok 20%-ában van.
A tesztelés során a kritikus modulokra kell koncentrálni.

5. alapelv – A féregirtó paradoxon (Pesticide paradox)

Ha mindig ugyanazokat a teszteket hajtjuk végre, akkor az azonos a tesztkészlet egy idő után nem fog
új hibákat találni. A „féregirtó paradoxon” megjelenése ellen a teszteseteket rendszeresen felül kell
vizsgálni, és új, eltérő teszteseteket kell írni annak érdekében, hogy a szoftver vagy a rendszer
különböző részei kerüljenek futtatásra, és ezáltal további programhibákat találhassanak.

6. alapelv – A tesztelés függ a körülményektől (Testing is context dependent)

A tesztelést különböző körülmények esetén különbözőképpen hajtják végre. Például egy olyan
rendszert, ahol a biztonság kritikus szempont, másképp tesztelnek, mint egy e-kereskedelmi oldalt.

7. alapelv – A hibátlan rendszer téveszméje (Absence-of-errors fallacy)

A hibák megtalálása és javítása hasztalan, ha a kifejlesztett rendszer használhatatlan, és nem felel

meg a felhasználók igényeinek, elvárásainak.

5
1.4 A tesztelés alapvető folyamata (K2)
A tesztelés leglátványosabb része a tesztek végrehajtása. A hatékonyság érdekében azonban a
teszttervekben elegendő időt kell biztosítani a tesztterv elkészítésére, a tesztesetek tervezésére, a
végrehajtásra való felkészülésre és az állapot értékelésére.

A tesztelés alapvető folyamata a következő fő tevékenységekből áll:

 tervezés és irányítás (planning and control);
 elemzés és műszaki tervezés (analysis and design);
 megvalósítás és végrehajtás (implementation and execution);
 a kilépési feltételek értékelése és jelentés (evaluating exit criteria and reporting);
 teszt lezárása (test closure activities).

Bár logikailag egymás után következnek, a folyamat tevékenységei átfedhetik egymást, és

párhuzamosan is folyhatnak.

1.4.1 Teszttervezés- és irányítás (K1)

 A teszttervezés során ellenőrzik a tesztfeladatokat, definiálják a teszt célját és a
tevékenységeket annak érdekében, hogy elérjék a kitűzött célokat és elvégezzék a
feladatokat.
o Teszt terv (test plan): A tesztelés hatáskörét, megközelítését, erőforrásait valamint a
tevékenységek tervezett ütemezését tartalmazó dokumentum. Ezen kívül
meghatározza a tesztelési elemeket, a tesztelendő funkciókat, feladatokat, a
tesztelést végrehajtó személyek függetlenségét, a tesztelési környezetet, a műszaki
teszttervezési technikákat, a belépési és kilépési feltételeket, valamint kockázatokat.
A teszttervezési folyamat meghatározó dokumentuma (IEEE 829 alapján)
 Hogy megkönnyítsük dolgunkat, használhatunk szervezeti vagy programszintű tesztelési
alapelveket és tesztelési stratégiát.
o Tesztelési alapelv (test policy): magas szintű dokumentum, amely a szervezet elveit,
megközelítésmódját, valamint céljait mutatja be a tesztelésre vonatkozóan.
o Tesztelési stratégia (test strategy): magas szintű dokumentum, amely a
végrehajtandó tesztelési szinteket írja le, valamint azok részleteit tartalmazza a
szervezetre vagy a programra (egy vagy több projektre) vonatkozóan.
 Tesztterv kidolgozása:
o A tesztelés hatókörének, kockázatainak meghatározása és a tesztelés céljainak
kitűzése.
o Tesztelési megközelítés meghatározása (technikák, tesztelemek, lefedettség, a
tesztelésben résztvevő csapatok kijelölése és kapcsolattartás a csapatok, valamint az
egyének között). Átgondoljuk, hogy hogyan fogjuk a tesztelést végrehajtani, mit és
milyen alaposan tesztelünk.
 Tesztelési megközelítés (test approach): a tesztelési stratégia megvalósítása
egy konkrét projektre. Jellemzően a projekt céljain és a kockázatelemzésen
alapuló döntéseket, a tesztelési folyamatok kiindulópontjait, az
alkalmazandó műszaki teszttervezési technikákat, belépési és kilépési
kritériumokat valamint a tesztelés fajtáit tartalmazza.
 Lefedettség (coverage): Annak százalékos mérőszáma, hogy az adott
lefedettségi elemet milyen arányban hívta meg a teszteszköz.

6
 o Tesztelési irányelv és/vagy a tesztelési stratégia megvalósítása. A tervezés során
biztosítani kell, hogy amit végre akarunk hajtani, az megfelel a meglévő
irányelveknek és stratégiának.
o A teszteléshez szükséges javak meghatározása, pl. csapat összetétele,
tesztkörnyezethez szükséges szoftverek, hardverek, stb.
o A teszt elemzésének, a műszaki tervezés feladatainak, a teszt megvalósításának,
végrehajtásának és értékelésének ütemezése. Szükségünk lesz ütemtervre
o Kilépési feltételek meghatározása.
 Kilépési feltétel (exit criteria): általános és speciális feltételek halmaza,
amelyet minden érintettel egyeztetve egy folyamat hivatalos befejezési
feltételének tekintünk. A célja, hogy megakadályozzuk az olyan feladatok
befejezettnek tekintését, amelyeknek még vannak függőben levő, be nem
fejezett részei. A kilépési feltételeket a tesztelés leállításának tervezéséhez és
jelentéséhez használjuk.
 Tesztirányítás: Folyamatos tevékenység. A lényeges előrehaladást össze kell hasonlítanunk a
tervezettel, és a tesztelés aktuális állásáról jelentést kell tennünk a projekt menedzsereknek
és az ügyfélnek.
o Tesztirányítás (test control): a tesztelési tervtől való eltérések esetén javító
tevékenységeket alkalmazandó teszt menedzselési feladat annak érdekében, hogy a
teszt projekt nyomon követhető legyen
o Tesztelés felügyelete (test monitoring): a tesztelési projekt státuszát rendszeresen
vizsgáló, a tesztelési tevékenységet kezelő tesztmenedzsment feladat. A
tesztmonitorozás részét képezi az elvárt eredményeket az aktuális eredményekkel
összehasonlító jelentés készítése. Lásd még: tesztmenedzsment.
 A tesztirányítás alapvető feladatai:
o A felülvizsgálatok és a tesztelés eredményeinek elemzése, mérése.
Tudnunk kell, hogy mennyi felülvizsgálatot és tesztet végeztünk el, és hogy hány volt
sikeres, hány bukott meg, mennyire volt súlyos a programhiba, milyen típusú volt,
stb.
o Felügyeleti és dokumentációs folyamat, tesztlefedettség és kilépési feltételek.
A teszt eredményeket az egész csapat számára elérhetővé kell tenni
o Információnyújtás a tesztelésről
Rendszeres és rendkívüli jelentéseket kell adnunk a projekt szponzorának, ügyfélnek
és a többi kulcsszereplőnek.
o Javítások kezdeményezése
o Döntéshozatal
Eredményekre és információkra alapozva döntéseket hozunk, vagy mások számára
tesszük lehetővé a döntéshozatalt. Ilyen pl. a teszt folytatása vagy leállítása.

1.4.2 Tesztelemzés és terv (K1)

A teszt elemzés és tervezés az a tevékenység, mely során az általános tesztelési célokból
kézzelfogható tesztelési feltételeket és teszteseteket alakítanak ki.

A teszt elemzéshez és tervezéshez a következő fő feladatok tartoznak:

 Tesztbázis felülvizsgálata: A tesztelt szoftver specifikációjának vizsgálata. Segítségével
dolgozzuk ki a teszteket.
o Tesztbázis (test basis): az összes olyan dokumentum, amelyből a komponensekre
vagy rendszerekre vonatkozó követelmények származnak. Ezek azok a

7
 dokumentumok, amelyeken a tesztesetek alapulnak. Ha egy ilyen dokumentumot
csak formális változáskezelési folyamat során módosíthatnak, a tesztbázist ún.
fagyasztott tesztbázisnak nevezik. [TMap alapján]
 A tesztbázis és a tesztelés tárgyának értékelése tesztelhetőség szempontjából. A
tesztelhetőség különböző tényezőktől függ: egyrészt, hogy felállítható-e a rendszer egy a
működési környezettel azonos környezetben, másrészt, hogy megérthető-e, valamint
tesztelhető-e a rendszer bármely lehetséges konfigurációja, illetve a használatának összes
lehetséges módja.
 A tesztelési feltételek meghatározása és priorizálása a tesztelemek, a specifikáció, a
viselkedés és a struktúra elemzése alapján.
o Tesztelési feltétel (test condition): a rendszer egy olyan eleme, vagy eseménye,
amelyet egy tesztesettel ellenőrizni lehet, például funkció, tranzakció, jellemző,
minőségi attribútum vagy strukturális elem.
 Tesztesetek megtervezése és priorizálása. A kiválasztás során a tesztelési feltéteket vesszük
alapul, valamint mélyebben belemegyünk a részletekbe.
 A tesztelési feltételek és a tesztesetek támogatásához szükséges tesztadatok
meghatározása. Tesztadatok pl.: egyes tesztesetek specifikus bemeneti adatai; dinamikus
adatbázisok, statikus adattáblák, stb. Funkcionális teszt esetén a lehető legkisebb
adatbázissal próbálunk dolgozni, hogy a teszteredményeket könnyebben ellenőrizhessük.
Érdemes az adatbázisokat úgy megtervezni, hogy újból felhasználhatók legyenek.
 A tesztkörnyezet kialakításának megtervezése valamint a szükséges infrastruktúra és
eszközök meghatározása. Ez magában foglalja a tesztelési eszközöket, egyéb felhasznált
eszközöket (táblázatkezelő, szövegszerkesztő, projekttervező eszközök) és nem IT-s
eszközöket is.
 Tesztbázis és tesztesetek összekapcsolása (traceability):

1.4.3 Teszt megvalósítása és végrehajtása (K1)

A teszt megvalósítása és végrehajtása során a tesztelési feltételeket alapul véve kialakítjuk a
teszteseteket és a tesztelemeket, felállítjuk a tesztkörnyezetet. Ez azt jelenti, hogy miután
összeállítottunk egy magas szintű műszaki teszttervet, elkezdhetjük a tesztek létrehozását. A
tesztelési feltételeket alakítjuk tesztesetekké és tesztelési eljárásokká, illetve olyan tesztelemekké,
mint pl. a tesztszkriptek a futtatás automatizálásához. Ezen kívül szükségünk van egy környezetre,
amelyben a tesztjeinket futtathatjuk, és a tesztadatokat létrehozhatjuk.

 Műszaki tesztterv (test design specification): a tesztelési feltételeket és követelmények

teljesítését definiáló dokumentáció, amely tartalmazza a tesztelés megközelítését és a magas
szintű teszteseteket (IEEE 829 alapján)
 Teszteljárás specifikáció (test procedure specification): a tesztelés futtatásának
tevékenységsorozatát rögzítő dokumentum. Tesztszkript illetve manuális tesztszkript néven is
ismert.
 Tesztadat (test data): olyan adat, amely a tesztelés előtt is létezik (például egy adatbázisban)
és amely kölcsönhatásban van a tesztelés alatt álló rendszerrel, vagy a
rendszerkomponenssel.

A teszt megvalósításának és végrehajtásának fő feladatai:

 Megvalósítás:
o Tesztesetek fejlesztése, kivitelezése és priorizálása.

8
 o Tesztelési eljárások fejlesztése és priorizálása, tesztadatok létrehozása valamint
opcionálisan a tesztelési alapkörnyezet elkészítése és automatizált tesztszkriptek
írása.
o Tesztkészletek létrehozása a tesztelési eljárásokból a hatékony tesztvégrehajtás
érdekében.
 Tesztkészlet (test suite): rendszerre vagy rendszerkomponensekre készített
tesztesetek halmaza, amelyben gyakran az egyik teszt utófeltétele egyben a
másik teszt előfeltétele
 Tesztvégrehajtás (test execution): a rendszeren vagy annak komponensén
végzett tesztelés folyamata, amelyből megkapjuk az aktuális eredményeket.
o Annak ellenőrzése, hogy a tesztkörnyezetet megfelelően kialakították.
 Végrehajtás:
o A tesztelési eljárások a megtervezett sorrend szerinti végrehajtása manuálisan vagy
tesztvégrehajtási eszközökkel.
o A tesztvégrehajtás eredményeinek naplózása és a tesztelt szoftver, a teszteszközök
és a tesztelési környezet azonosítóinak és verzióinak feljegyzése.
 Tesztelési napló (test log, test record): a tesztvégrehajtáshoz kapcsolódó
részletek időrendi rögzítése
o A kapott és az elvárt eredmények összehasonlítása.
o Az eltérések incidensként való jelentése és elemzése a kiváltó ok felderítése
érdekében (például hiba volt a kódban, meghatározott tesztadatokban, a teszt
dokumentumban, vagy a teszt végrehajtásában történt tévedés).
 Incidens (incident): bármely olyan történés, amely vizsgálódást tesz
szükségessé [IEEE1008]
o A tesztelési tevékenység ismétlése minden eltérésnél a lépések megtétele után.
Például: az előzetesen sikertelen teszt újrafuttatása a javítás ellenőrzésére (ellenőrző
teszt), a javított teszt végrehajtása és/vagy tesztek végrehajtása annak ellenőrzésére,
hogy nem kerültek-e hibák a szoftver változatlanul hagyott területeibe, illetve hogy a
hiba javításával nem jelentek-e meg további hibák (regressziós teszt).
 Ellenőrző teszt/újratesztelés (confirmation testing/re-testing): tesztelés,
amikor azokat a teszteseteket futtatjuk, amelyek a legutóbbi tesztfuttatásnál
elbuktak. Célja a hibajavítás sikerességének ellenőrzésére.
 Regressziós teszt (regression testing): Egy korábban már letesztelt program,
módosítást követő tesztelése, annak biztosítása érdekében, hogy a
módosulás nem okozott hibát a szoftver nem módosított részeiben. A teszt
végrehajtása a szoftver vagy a szoftverkörnyezet változtatásakor történik.

1.4.4 A kilépési feltételek értékelése és jelentés (K1)

A kilépési feltételek értékelése az a tevékenység, mely során a teszt végrehajtását a meghatározott
célok fényében kiértékeljük. Ezt minden tesztelési szintre el kell végezni.

Tesztterv kilépési feltétele (elvárt) és a tesztelési napló (tényleges)

összehasonlítása. Teljesítettük?

I
N
Szükséges további tesztelés?

N
I 9
Teszt összefoglaló készítése (összesített eredmény, statisztikák, stb.)
A kilépési feltétel értékelésének fő feladatai:
 A tesztelési naplók és a tesztelési tervezetben foglalt kilépési feltételek összehasonlítása.
 Annak megállapítása, hogy szükséges-e további tesztek futtatása, vagy a kilépési feltételek
megváltoztatása.
 Teszt összefoglaló jelentés elkészítése a projektben résztvevőknek.
o Teszt összefoglaló jelentés (test summary report): a tesztelési tevékenységeket és
eredményeket tartalmazó dokumentum. Ebben a dokumentumban található a
kilépési feltételeknek megfelelően ellenőrzött tesztelési elemek kiértékelése is.

1.4.5 Teszt lezárása (K1)

A teszt lezárása során adatokat kell gyűjteni a végrehajtott tesztekre vonatkozóan a tapasztalatok, a
tesztelési környezet, a tények és számok véglegesítése / értelmezése céljából. Például akkor, ha
kiadnak egy szoftverrendszert, végrehajtanak (vagy törölnek) egy teszt projektet, eljutnak egy
fontosabb szakaszig vagy végeznek egy karbantartó frissítéssel.

A teszt lezárásának fő feladatai:

 Annak ellenőrzése, hogy a tervezett átadandókból mit sikerült ténylegesen átadni, az
incidens jelentések lezárása vagy a változtatásokról szóló feljegyzések elkészítése a le nem
zárt jelentésekhez, valamint a rendszer átvételéről szóló dokumentáció elkészítése.
 A tesztver – tesztszkriptek, tesztelési környezet, és tesztelési infrastruktúra – véglegesítése
és archiválása későbbi felhasználásra.
o Tesztver (testware): A tesztelési folyamat során keletkezett különböző termékek,
például dokumentáció, programkód, inputok, elvárt eredmények, eljárások, fájlok,
adatbázisok, környezetek, illetve bármilyen egyéb szoftver
 A tesztelési környezet átadása a karbantartást végző szervezet részére.
 A tapasztalatok feldolgozása a jövőbeni termékekhez vagy projektekhez valamint a
tesztelési folyamat érettségének fejlesztéséhez.

1.5 A tesztelés pszichológiája (K2)

A tesztelés és a felülvizsgálat a szoftverfejlesztéstől eltérő gondolkodásmódot kíván. A megfelelő
gondolkodásmód birtokában a fejlesztők képesek a saját kódjaik tesztelésére, általában azonban ezt
a feladatot tesztelőre bízzák, hogy az erőforrások jobban összpontosuljanak. Ez további előnyöket is
jelent, nevezetesen független, képzett, professzionális tesztelési erőforrásokat. Független tesztelést a
tesztelés bármely szintjén lehet alkalmazni.

Bizonyos fokú függetlenséggel (a szerzői elfogultság kizárásával) gyakran hatékonyabban találják meg
a hibákat és a meghibásodásokat. A függetlenség azonban nem helyettesíti a jártasságot, a fejlesztők
saját kódjukban sok hibát hatékonyan megtalálnak.

 Független tesztelés (independence of testing): a felelősségi körök elválasztása, amely az

objektív tesztelést segíti

A függetlenség néhány szintje a következőképpen definiálható:

 A tesztelt szoftver fejlesztője (fejlesztői) által tervezett tesztek (alacsony szintű függetlenség).
 Más(ok) által tervezett tesztek (például valaki a fejlesztői csapatból).

10
  Más szervezeti csoporthoz (például egy független tesztelő csapathoz) tartozó személy(ek)
vagy tesztelési szakértők (például használhatósági vagy teljesítményteszt) által tervezett
tesztek.
 Más szervezethez vagy céghez tartozó személy(ek) által tervezett tesztek (outsourcing vagy
egy külső testület tanúsítványa).

Az embereket és a projekteket a célok viszik előre. Az emberek hajlamosak hozzáigazítani terveiket a

menedzsment vagy más projektrésztvevők által meghatározott célokhoz, erre példa a hibák
megtalálása vagy annak ellenőrzése, hogy a szoftver jól működik. Ezért fontos a tesztelési célok
pontos, érthető meghatározása.

A tesztelés során tapasztalt meghibásodások feltárását gyakran a termék vagy a szerző elleni
kritikának fogják fel. Emiatt a tesztelést gyakran destruktív tevékenységnek tekintik, annak ellenére,
hogy valójában konstruktív a termék kockázatának kezelésében. Egy rendszer programhibáinak
kutatása kíváncsiságot, szakszerű pesszimizmust, kritikus szemléletet, a részletekre való odafigyelést,
a fejlesztőkkel való jó kommunikációt és a hibasejtéseket megalapozó tapasztalatot kíván.

 Hibasejtés (error guessing): olyan műszaki teszttervezési módszer, amely során a tesztelők
tapasztalata alapján próbáljuk megsejteni a tesztelendő szoftverben levő hibákat, illetve ez
alapján próbálunk megfelelő teszteket tervezni

A hibák, programhibák konstruktív szemléletű közlésével elkerülhetők a tesztelők és elemzők,

tervezők és fejlesztők közötti ellentétek. Ez érvényes a felülvizsgálatra és a tesztelésre is.

A tesztelőnek és a tesztelés vezetőjének a hibákkal, előrehaladással és kockázatokkal kapcsolatos

tárgyilagos, konstruktív kommunikáció érdekében jó interperszonális képességekkel kell
rendelkeznie. A hibákkal kapcsolatos információ a szoftver vagy dokumentum szerzőjének segíthet a
képességei fejlesztésében. A tesztelés során megtalált és javított hibák a későbbiekben időt és pénzt
takarítanak meg, és csökkentik a kockázatokat.

Kommunikációs problémák előfordulhatnak, különösen akkor, ha a tesztelőket csak a hibákról szóló

rossz hírek hozóinak tekintik. Léteznek viszont különböző módszerek arra, hogyan javítsuk a tesztelők
és a többiek közti kommunikációt és kapcsolatot:

 Együttműködő szándékkal indítsunk hadakozás helyett – felhívni a figyelmet a közös célra: a

minél jobb minőségű rendszerre.
 Semlegesen, tárgyilagosan kell előadni az eredményeket, a kidolgozó személy kritizálása
nélkül; vagyis például objektív és tárgyilagos incidens jelentés illetve felülvizsgálat eredmény
jelentés készítése.
 Meg kell próbálni megérteni azt, hogy hogyan érez a másik fél, és miért olyanok a reakciói,
amilyenek.

2 Tesztelés a szoftver életciklusán át (K2)

2.1 Szoftverfejlesztési modellek (K2)
A tesztelés nem egy különálló, elszigetelt tevékenység, megvan a maga helye a szoftverfejlesztés
életciklusában. A különböző fejlesztési életciklus modelleknél különböző tesztelési megközelítésekre
van szükség.

11
Minden fejlesztési ciklusban a tesztelés egy része a verifikációs, egy másik pedig a validációs
tesztelésre összpontosít:
 Verifikáció (verification): az adott követelmények teljesülésének vizsgálata és konfirmálása
„A rendszer megfelel-e a specifikációnak” - [ISO 9000]
 Validáció (validation): „Helyes-e a specifikáció”
Annak vizsgálata, és konfirmálása, hogy a szoftver tervezett felhasználási céljának megfelelő
követelmények teljesülnek-e - [ISO 9000]

2.1.1 V-modell (szekvenciális fejlesztési modell) (K2)

 Elődje a Vízesés modell:

 V modell:

12
 Bár a V-modellnek többféle változata létezik, az általános V-modellnél négy tesztelési szintet
alkalmaznak, melyek a négy fejlesztési szinthez tartoznak:
 Tesztelési szint (test level): közös szervezés és menedzsment alatt álló
tesztelési tevékenységek csoportja. A tesztelési szint felelősségi körökhöz
kapcsolódik a projekten belül. Tesztelési szintekre példa a komponens-
tesztelés, integrációs teszt, rendszerteszt és felhasználó teszt. [TMap
alapján]
o komponens (egység) teszt: a külön-külön tesztelhető szoftverkomponensekben kutat
programhibák után, és ellenőrzi azok működését.
o integrációs teszt: a tesztek a komponensek közötti, a rendszer különböző részei
közötti, vagy maguk a rendszerek közötti kölcsönhatásokat vizsgálják.
o rendszerteszt: a rendszer/termék egészének a viselkedését vizsgálja.
o átvételi teszt: validációs tesztelés, mely figyelembe veszi a felhasználók igényeit, a
követelményeket. (Segít eldönteni, hogy átvegyék-e a rendszert vagy nem)
 A gyakorlatban a projekttől és a szoftverterméktől függően a V-modellnek lehet ennél több,
kevesebb, vagy eltérő fejlesztési és tesztelési szintje. Például a komponensteszt után
következhet komponens integrációs teszt vagy a rendszerteszt után rendszer integrációs
teszt.
 Egy kereskedelmi dobozos (COTS) szoftvertermék rendszerbe történő integrációja esetén a
vevő adott esetben megelégedhet azzal, hogy rendszerszinten csupán az integrációs tesztet
végzi el, az átvételi tesztet pedig majd egy későbbi szinten hajtja végre.
o Dobozos szoftver (COTS – commercial off-the-shelf software): egy, az általános piaci
igényeknek megfelelő szoftver termék, pl.: nagyszámú vevő. Hasonló elérhetőséggel,
illetve megjelenéssel rendelkezik minden vásárló számára

 A fejlesztés során létrehozott szoftvertermékek (mint vállalati forgatókönyvek vagy használati

esetek, követelmény-specifikációk, tervdokumentumok és kód) gyakran képezik a tesztelés

13
 alapját egy vagy több tesztelési szinten. Az általános szoftvertermékekre referencia az
integrált képességi-érettségi modell (CMMI) vagy a szoftver életciklus folyamatokat leíró
szabványban („Software life cycle processes”, IEEE/IEC 12207). A verifikációt és a validációt
(és a korai műszaki teszttervezést) a szoftver termékek fejlesztése alatt lehet elvégezni.

2.1.2 Iteratív-inkrementális fejlesztési modellek (K2)

 Az iteratív-inkrementális fejlesztés a követelmények meghatározásának, a tervezésnek, a
rendszer felépítésének és tesztelésének folyamata, melyet több rövidebb fejlesztési
ciklusban hajtanak végre.
 Iteratív fejlesztési modell:
o A teljes projektet időben feldaraboljuk iterációkra
o Minden iteráció egy kis projekt
o Az iterációk végén van kiszállítható termék
 Példák: prototípus készítés
o Gyors alkalmazásfejlesztés (RAD)
 A funkcionalitásokat párhuzamosan fejlesztik az adott időkerethez igazodva
 Majd integrálják őket
o Rational Unified Process (RUP): Rugalmas keretrendszer, amely 4 fázist tartalmaz:
 Vizsgálat
 Kidolgozás
 Létrehozás
 Átadás
o agilis fejlesztési modellek.
 Az iteráció során létrehozott rendszert több szinten lehet tesztelni, a fejlesztés részeként. A
már előzőleg kifejlesztettekhez kiegészítés hozzáadásával növekvő részrendszer jön létre,
amelyet szintén tesztelni kell. A regressziós teszt szerepe minden iterációnál egyre
fontosabb. A verifikációt és validációt minden kiegészítésnél végre lehet hajtani.
 Inkrementális fejlesztési modell (incremental development model): fejlesztési életciklus,
ahol a projekt kis lépésekre van bontva, amelyek mindegyike egy kis részt tesz hozzá az
általános projekt követelményekhez. A követelményeket priorizálják és a megfelelő
inkrementális egységben a prioritási sorrend szerint szállítják. Ezen életciklus modell néhány
(de nem minden) verziójában minden alprojekt egy „mini V-modell” szerint működik a saját
tervezési, implementálási és tesztelési fázisaival

2.1.3 Tesztelés egy életciklus modellen belül (K2)

Minden életciklus modellben megfogalmazhatók a megfelelő tesztelés jellemzői.
 Minden fejlesztési tevékenységhez tartozik egy tesztelési tevékenység.
 Minden tesztelési szint rendelkezik az adott szintre jellemző tesztelési célkitűzésekkel.
 A tesztek elemzését és tervezését az adott tesztelési szinthez tartozó fejlesztési tevékenység
során kell megkezdeni.
 A tesztelőket be kell vonni a dokumentációk felülvizsgálatába, amint elkészültek az első
vázlatok a fejlesztési életciklusban.

14
2.2 Tesztelési szintek (K2)
2.2.1 Komponensteszt (K2)
 A komponensteszt hibákat keres az önállóan tesztelhető szoftverekben (pl. modulok,
programok, objektumok, osztályok), és ellenőrzi működésüket. A fejlesztési életciklus
körülményeitől és a rendszertől függően a rendszer többi részétől elkülönítve is végezhető.
Használhatók csonkok, meghajtók és szimulátorok.

B
E

C A
F
D

o Komponensteszt (component testing): az egyes szoftver komponensek (egységek,

modulok) tesztelése
o Csonk (stub): Egy szoftver komponens speciális célú vagy részleges megvalósítása. A
csonkot arra használjuk, hogy támogassuk a komponens(ek) fejlesztését vagy
tesztelését. Helyettesíti a meghívott komponenst. [IEEE 610]
o Meghajtó (driver): egy szoftver komponens, vagy teszt eszköz, amely kiváltja azt a
komponenst, amely egy másik komponens, vagy a rendszer vezérlését, és/vagy
felhívását végzi
 A komponensteszt magában foglalhatja a funkcionalitás valamint meghatározott nem-
funkcionális jellemzők tesztelését, mint például az erőforrásokkal kapcsolatos viselkedés
(például memóriaszivárgás), robosztussági teszt illetve strukturális teszt (pl. elágazás
lefedettség). A teszteseteket termékekből készítik, mint pl. komponens specifikációja, a
szoftverterv, vagy adatmodell-specifikáció.
o Robosztusság (robustness): annak fokmérője, hogy egy komponens vagy rendszer
mennyire képes az elvárt működésre érvénytelen bemenetek vagy szűkös környezeti
erőforrások mellett. [IEEE 610]
o Robosztussági teszt (robustness testing): egy szoftvertermék robosztusságának
meghatározására vonatkozó tesztelés.
 A komponensteszt során általában hozzáférnek a tesztelt kódhoz (fehérdoboz teszt), és
felhasználják a fejlesztési környezet által nyújtott támogatást, mint például egy egységteszt
keretrendszer vagy hibakereső eszköz; és a gyakorlatban általában bevonják a fejlesztőt, aki
a kódot írta. A hibákat általában már a megtaláláskor javítják anélkül, hogy az incidensről
jegyzőkönyv készülne.
 A komponensteszt egyik megközelítése, hogy a teszteseteket a kódolás előtt készítik el és
automatizálják. Ezt nevezik „először a teszt” megközelítésnek vagy teszt-vezérelt
fejlesztésnek. Ez a megközelítés rendkívül iteratív, és arra épül, hogy ciklikusan fejlesztik a
teszteseteket, majd létrehozzák és integrálják a kód kisebb részeit, s addig folytatják a
komponensteszteket, míg azok sikeresen lefutnak.
o Tesztvezérelt fejlesztés (test-driven development): Szoftverfejlesztési módszertan,
amelyben a teszteseteket azelőtt készítik el (és többnyire automatizálják), mielőtt a
szoftver fejlesztési folyamata befejeződne, és le lehetne futtatni a teszteket.

15
2.2.2 Integrációs teszt (K2)
 Az integrációs teszt során a komponensek közötti interfészeket, egy rendszer más részeivel
– mint az operációs rendszer, fájlrendszer, hardver – való kölcsönhatásait vagy a rendszerek
közötti interfészeket tesztelik.
o Integráció (integration): a komponensek, vagy rendszerek nagyobb egységbe
történő összeolvasztásának folyamata
o Integrációs teszt (integration testing): olyan tesztelés, amelynek célja az integrált
egységek közötti interfészekben, illetve kölcsönhatásokban lévő hibák megtalálása.

B E G

C D F

 Az integrációs tesztnek több szintje lehet, és különböző méretű lehet a tesztelési tárgya is.
Például:
o A komponens integrációs teszttel a szoftverkomponensek közötti kölcsönhatásokat
tesztelik; a komponensteszt után végzik;
o A rendszer integrációs teszttel a különböző rendszerek közötti kölcsönhatásokat
tesztelik; a rendszerteszt után végezhetik. Ebben az esetben előfordulhat, hogy a
fejlesztő szervezet csak az interfész egyik oldalát kontrollálja, így a változtatások
ronthatják a stabilitást. A munkafolyamatként kivitelezett vállalati folyamatok,
rendszerek egész sorát foglalhatják magukba. A platformokat átölelő problémák nagy
jelentőséggel bírhatnak.
 Minél nagyobb az integráció mértéke, annál nehezebb egy adott komponenshez vagy
rendszerhez visszavezetni a meghibásodásokat, ez pedig magasabb kockázati faktort
jelenthet.
 A „nagy bumm” (big bang) módszer: Az összes komponenst vagy rendszert szimultán
integráljuk, majd pedig egységes egészként teszteljük
o Előnye: az integrációs teszt megkezdésekor már nincs szükség befejezetlen részek
szimulálására
o Hátránya: időigényes végrehajtani, és a késői integráció miatt nehéz feltárni a
meghibásodások okát.
 Inkrementális tesztelés: Minden programot egyesével integrálunk, és minden lépés után
végrehajtunk egy tesztet.
o Előnye: a programhibákat korábban találjuk meg, még a kisebb összeállításokban
o Hátránya: időigényes lehet, mivel a fejlesztés során csonkokat és meghajtókat kell
kifejleszteni és használni.
 Felülről lefelé haladó: a tesztelés felülről lefelé halad, követve a vezérlési folyamatot vagy a
felépítési struktúrát. A komponenseket vagy a rendszereket csonkok helyettesítik.

16
  Alulról felfelé haladó: A tesztelés a vezérlési folyamat alján kezdődik és felfelé halad. A
komponenseket vagy rendszereket meghajtók helyettesítik.
 Funkcionális inkrementális: az integrációt és a tesztelést a funkciókra vagy a funkcionalitásra
alapozva végezzük, a funkcionális specifikációk dokumentációja alapján
 Egyes nem-funkcionális jellemzők tesztelése (pl. teljesítmény) is része lehet az integrációs
tesztnek.
 Az integráció minden fázisában a tesztelők kizárólag magára az integrációra koncentrálnak.
Például A modul és B modul egyesítésénél a két modul közötti kommunikáció tesztelésére
figyelnek, nem pedig az egyes modulok működésére. A funkcionális és a strukturális
megközelítés egyaránt alkalmazható.
 Ideális esetben a tesztelők ismerik a rendszer felépítését, és befolyással bírnak az integráció
tervezésére. Ha az integrációs teszteket még a komponensek vagy rendszerek kifejlesztése
előtt megtervezik, akkor ezeket a leghatékonyabb tesztelésnek megfelelő sorrendben lehet
kifejleszteni.

2.2.3 Rendszerteszt (K2)

 A rendszerteszt egy teljes rendszer/termék viselkedésével foglalkozik, mely viselkedést a
fejlesztési projektben vagy programban határozták meg. A rendszerteszt magában foglalhat a
kockázatokon és/vagy követelmény-specifikációkon, vállalati folyamatokon, használati
eseteken alapuló vagy a rendszer viselkedésére, az operációs rendszerrel való
kölcsönhatásokra, rendszer-erőforrásokra vonatkozó további magas szintű leírásokon
alapuló teszteket.
o Rendszerteszt (system test): integrált rendszer tesztelése, abból a célból, hogy
ellenőrizzük a követelményeknek való megfelelőséget. [Hetzel]
o Követelmény (requirement): olyan feltétel vagy képesség, amely a felhasználó
számára azért szükséges, hogy megoldjon egy problémát vagy elérjen egy célt. Ezen
feltételnek vagy képességnek a rendszer vagy rendszer komponens által is
megvalósíthatónak kell lennie, úgy, hogy közben a szerződés, szabvány, specifikáció
és egyéb formális dokumentumban támasztott követelményeknek is megfeleljen.
[IEEE 610]
 A rendszerteszt során a rendszer funkcionális és nem funkcionális követelményeit is
vizsgálni kell. A követelmények szöveges-, és/vagy modellek formájában is megjelenhetnek. A
tesztelőknek olyan követelményeket is figyelembe kell venniük, melyek csak részben, vagy
egyáltalán nincsenek dokumentálva. A funkcionális követelmények rendszertesztje a
tesztelendő rendszer szempontjából legmegfelelőbb specifikáció alapú (fekete doboz)
technikák alkalmazásával kezdődik. Például döntési tábla hozható létre a vállalati
szabályokban leírt hatások kombinációira. Ezután strukturális technikák (fehérdoboz)
alkalmazhatók a tesztelés alaposságának elemzésére egy strukturális elem, mint pl. a
menüstruktúra vagy a weboldal-navigáció tekintetében.
o Funkcionális követelmény (functional requirement): olyan követelmény, amely a
szoftverrel szemben támasztott funkcionális elvárást írja le.
o Nem funkcionális követelmény (non-functional requirement): olyan követelmény,
amely a funkcionalitáshoz nem, de a megbízhatósághoz, hatékonysághoz,
használhatósághoz, karbantarthatósághoz és hordozhatósághoz kapcsolódik.
 Rendszertesztek esetén elengedhetetlen az ellenőrzött tesztkörnyezet. Ennek a lehető
legjobban kell hasonlítania a végfelhasználási vagy termelési környezetre, hogy minél kisebb
esély legyen arra, hogy a környezet-specifikus meghibásodásokat nem találja meg a teszt.

17
 o Tesztkörnyezet (test environment): a tesztelést támogató eszközök együttese,
beleértve minden hardver és szoftver eszközt (IEEE 610).

2.2.4 Átvételi teszt (K2)

 Az átvételi teszt gyakran a vevők vagy egy rendszer használóinak feladata; de más
projektrésztvevők is bevonhatók ezen tevékenységbe.
o Átvételi teszt (acceptance testing): A felhasználó, vagy a megrendelő által a
végterméken végzett fekete doboz teszt, amely azt hivatott eldönteni, hogy megfelel-
e a termék a megfogalmazott (üzleti) elvárásoknak, illetve folyamatoknak
 Az átvételi teszt célja a rendszerbe, a rendszer egyes részeibe vagy a rendszer adott nem-
funkcionális jellemzőibe vetett bizalom megteremtése. Az átvételi teszt elsődlegesen nem a
hibák megtalálására irányul. Az átvételi teszt célja a rendszer kibocsáthatóságának és
használhatóságának az elemzése, de nem minden esetben ez a tesztelés utolsó szintje. Egy
rendszer átvételi tesztje után következhet például egy nagyobb méretű rendszer-integrációs
teszt.
 Az átvételi teszt több szinten is megjelenhet, például:
o Egy dobozos szoftvertermék átvételi tesztje történhet az installálásakor vagy
integrálásakor.
o Egy komponens használhatóságának átvételi tesztje történhet a komponensteszt
folyamán.
o Új funkcionális kiegészítés átvételi tesztje megelőzheti a rendszertesztet.
 Felhasználói átvételi teszt: Általában a rendszer (megrendelő) vállalati felhasználók általi
használatra való alkalmasságát ellenőrzi.
 Működési (átvételi) teszt: A rendszer elfogadása a rendszeradminisztrátorok részéről, ide
tartozik:
o mentés/helyreállítás tesztelése;
o összeomlás utáni visszaállítás;
o felhasználói menedzsment;
o karbantartás feladatai;
o biztonsági rések periodikus ellenőrzése.
 Szerződésre és előírásokra vonatkozó átvételi teszt: Megrendelésre kifejlesztett szoftverek
esetében a szerződésre vonatkozó átvételi tesztet a szerződés átvételi kritériumaira hajtják
végre. Az átvételi kritériumokat a szerződés megkötésekor kell meghatározni. Az előírásokra
vonatkozó átvételi tesztet végezhetik betartandó előírások alapján, ilyenek lehetnek például
közigazgatási-, jogi- vagy biztonsági rendelkezések.
 Alfa és béta (valós környezetben történő) teszt: A piacra dolgozó vagy dobozos szoftvereket
előállító fejlesztők gyakran szeretnének visszajelzéseket kapni a potenciális, vagy meglévő
piaci ügyfeleiktől, még mielőtt a szoftverterméket kereskedelmi forgalomba hoznák. Az alfa
tesztelést a fejlesztő szervezetnél végzik. A béta, vagy valós környezetben történő tesztelést
a felhasználók saját munkaállomásokon folytatják. Mindkettőt potenciális ügyfelek végzik,
nem pedig a termék fejlesztői.
o Alfa teszt (alpha testing): Szimulált, vagy tényleges tesztelés, amelyet potenciális
felhasználók, vagy egy független tesztcsapat végez a fejlesztés helyszínén, de a
fejlesztői szervezettől függetlenül. Gyakran használják dobozos szoftverek belső
átvételi tesztjeihez
o Béta teszt (betha testing): a szoftvernek egy szűkebb felhasználói körben való külső
tesztelése a végső kiadás előtt annak érdekében, hogy meghatározzuk, hogy a

18
 szoftver megfelel-e a felhasználók piaci igényeinek. Gyakran megfelel a dobozos
(OTS) szoftverek külső átvételi tesztjének
 Az egyes szervezetek különböző megnevezéseket használhatnak, mint működési átvételi
teszt és helyszíni átvételi teszt, azokra a rendszerekre, melyeket az ügyfélnek történő átadás
előtt és után is tesztelnek.

2.3 Teszttípusok (K2)

 A teszttevékenységek egy csoportjának lehet az a célja, hogy meghatározott indokból vagy
adott tesztelési cél alapján ellenőrizzék a szoftverrendszert (vagy a rendszer egy részét).
 Egy teszttípus egy meghatározott tesztelési célra összpontosít, ami lehet egy, a szoftver által
végrehajtandó függvény tesztelése; egy nem funkcionális minőségi jellemző, mint pl.
megbízhatóság vagy használhatóság, a szoftver, vagy rendszer struktúrája, illetve felépítése;
kapcsolódhat változtatásokhoz: annak ellenőrzése, hogy a hibákat kijavították (ellenőrző
teszt) illetve nem szándékolt változtatások kutatása (regressziós tesztelés).
o Teszttípus (test type): egy meghatározott tesztelési objektumon végrehajtott,
rendszerkomponensre vagy rendszerre fókuszáló tesztelési tevékenységek csoportja.
Példa teszttípusokra: funkcionális teszt, használhatósági teszt, regressziós teszt, stb.
Egy teszttípus több tesztelési szinten is végrehajtható.
 A szoftver modell fejleszthető és/vagy használható a strukturális és funkcionális
tesztelésben, például: a funkcionális tesztelésben egy eljárási folyamatfüggési modell, egy
állapotátmenet modell vagy egy egyszerűen megfogalmazott specifikáció; a strukturális
tesztelés esetében egy vezérlési folyam modell vagy menüstruktúra modell használható.

2.3.1 Funkció tesztelése (funkcionális teszt) (K2)

 Egy rendszer, alrendszer vagy komponens által végrehajtandó funkcionalitások különböző
projekt-termékekben fogalmazható meg, mint pl. követelmény-specifikáció, használati eset
vagy funkcionális specifikáció, de előfordulhat, hogy nincsenek is dokumentálva. A
funkcionalitások alatt azt értjük, „amit” a rendszer tesz.
o Funkcionalistás (functionality): a szoftver termék azon képessége, hogy – bizonyos
feltételek fennállása esetén - képes a meghatározott igények szerinti működésre.
o Funkcionalitási teszt (functionality testing): a rendszer funkcionalitását vizsgáló
teszt.
 A funkcionális tesztek minden tesztelési szinten végrehajthatók (pl. a komponensek
tesztjeinek alapja lehet egy komponens specifikáció).
 A funkcionális teszt meghatározott viselkedést vizsgál, gyakran feketedoboz tesztelésként
utalunk rá.
o Funkcionális teszt (functional testing): a rendszer funkcionális specifikációján alapuló
teszt.
o Feketedoboz teszt (blackbox testing): a program belső szerkezetére történő
hivatkozás nélküli funkcionális, vagy nem funkcionális tesztelés.
 A funkcionális tesztelés alapja lehet:
o Követelmény: a rendszer funkcionális követelményeinek specifikációi képezik a
műszaki teszttervezés alapját. A kockázati kritériumok alapján érdemes felállítanunk
a követelmények prioritási sorrendjét, ez alapján pedig a tesztek prioritási
sorrendjét.
o Használati esetek

19
 o Üzleti folyamat: a vállalati folyamatokra vonatkozó ismereteket használjuk fel.
 A funkcionális teszt az ISO 9126-os szabvány alapkán összpontosíthat az alkalmasságra,
együttműködő képességre, biztonságra, pontosságra és megfelelőségre.
o Biztonsági teszt: védve van-e a rendszer a rosszindulatú külső (pl. vírus) ellen (tűzfal)
 Biztonság (security): A szoftver termék azon képessége, hogy elfogadható
szintű kockázatot biztosítson az emberekkel, üzlettel, tulajdonnal vagy a
környezettel, a megadott használati környezetben. [ISO 9126]
o Együttműködő-képességi teszt: hogyan tud a rendszer együttműködni más
rendszerekkel
 Együttműködő képesség (interoperability): a szoftver azon jellemzője, hogy
egy, vagy több adott komponenssel, illetve rendszerrel milyen az egymásra
hatásuk [ISO 9126 szerint].
 Funkcionális tesztelés során általában specifikáció alapú technikákat alkalmazunk, de
használhatunk tapasztalat alapú technikákat is.

2.3.2 Nem funkcionális szoftverjellemzők tesztelése (nem funkcionális tesztelés) (K2)

 A nem funkcionális teszt magában foglalja többek között a teljesítmény tesztet, a terheléses
tesztet, a stressz tesztet, a használhatósági tesztet, a karbantarthatósági tesztet, a
megbízhatósági tesztet és a hordozhatósági tesztet. Azt teszteli, hogy a rendszer „hogyan”
működik.
 A nem funkcionális teszt minden tesztelési szinten végrehajtható. A nem funkcionális teszt
kifejezés azokat a teszteket takarja, melyek a különböző mennyiségi mutatókkal leírható
rendszer- és szoftverjellemzők méréséhez szükségesek, mint pl. válaszidő a
teljesítménytesztnél, vagy memóriahasználat. Ezek a tesztek bizonyos minőségi modellhez
kapcsolhatók, mint pl. a „Software Engineering – Szoftvertermékek Minősége” (ISO 9126)
által definiált mutatók.
 Típusai:
o Teljesítmény teszt (performance testing): Tesztelési folyamat mellyel a szoftver
termék teljesítményét lehet meghatározni.
 Teljesítmény (performance): Egy komponens vagy rendszer azon
tulajdonsága, hogy bizonyos funkciókat milyen hatékonyan hajt végre
(tranzakciók ideje, száma, válaszidő, stb.) [IEEE 610 szerint]
o Terheléses teszt (load testing): A teljesítmény teszt azon típusa, amely a komponens
vagy rendszer viselkedését vizsgálja növekedő terhelés alatt (például a felhasználók
számának, vagy kérések számának növelésekor). A teszt célja hogy kiderüljön, hogy a
komponens vagy rendszer hogyan reagál a magas terhelésre (lefagy, nő a válaszidő,
stb.).
o Stressz teszt (stress testing): Egy olyan teljesítmény tesztelési típus, amikor úgy
vizsgálunk egy komponenst vagy rendszert, hogy az előre elvárt vagy annál nagyobb
terheléssel, vagy csökkentett erőforrás rendelkezésre bocsátással teszteljük. Például
korlátozott szerver memória hozzáférés. Lásd még teljesítmény teszt, terheléses
teszt. [IEEE 610]
o Használhatósági teszt (usability testing): a tesztelés meghatározza, hogy a szoftver
termék mennyire érthető meg, mennyire könnyű megtanulni használatát és milyen
könnyen kezelhető, ezáltal mennyire felhasználóbarát meghatározott feltételek
mentén.

20
 o Karbantarthatóság (maintainability): egy alkalmazás azon tulajdonsága, hogy milyen
egyszerűen lehet hibákat javítani benne, új vagy megváltozott követelmények illetve
környezet miatt szükséges módosításokat eszközölni. [ISO 9126]
o Megbízhatóság (reliability): a szoftvertermék azon képessége, hogy a szükséges,
előírt funkcionalitást meghatározott időtartam vagy meghatározott műveletszám
mellett az előre megállapított követelmények szerint képes ellátni. [ISO 9126]
o Hordozhatóság (portability): Egy szoftvertermék átmozgatásának mértéke
(hardverről egy másikra, vagy egyik szoftver környezetből egy másikba). [ISO 9126]
 Az ISO 9126 szabvány hat minőségi mutatót ad meg, amelyek további alosztályokra
bonthatók, minden alosztályban számos jellemzővel:
o Funkcionalitás: öt aljellemzőre oszlik: alkalmasság, pontosság, biztonság,
együttműködés és megfelelőség.
o Megbízhatóság: érettség (robosztusság), hibatűrés, visszaállíthatóság és
megfelelőség
o Használhatóság: érthetőség, tanulhatóság, működtethetőség, megjelenés és
megfelelőség
o Hatékonyság: időbeli viselkedés (teljesítmény), erőforrás kihasználtság és
megfelelőség
o Karbantarthatóság: elemezhetőség, változtathatóság, stabilitás, tesztelhetőség és
megfelelőség
o Hordozhatóság: adaptálhatóság, telepíthetőség, koegzisztencia, helyettesíthetőség
és megfelelőség

2.3.3 A szoftver struktúrájának/felépítésének tesztelése (strukturális teszt) (K2)

 A strukturális (fehérdoboz) teszt minden tesztelési szinten végrehajtható. A strukturális
technikák legjobban a specifikáció alapú technikák után használhatók annak érdekében, hogy
egy adott típusú struktúra lefedettségének elemzésével támogassák a teszt lefedettségének
mérését.
o Fehérdoboz teszt (white-box testing, glass box testing): a szoftver belső
struktúrájának elemzésén alapuló tesztelés
o Kódlefedettség (code coverage): Elemző módszer, amely meghatározza, hogy a
szoftver mely részei lettek végrehajtva (lefedve) a teszt végrehajtása során, és
melyek nem. Például: utasítás lefedettség, döntési lefedettség, feltétel lefedettség.
 A lefedettség azt mutatja meg, hogy egy tesztkészlet milyen mértékben érintett egy
struktúrát, és ezt az értéket a lefedett elemek százalékában fejezik ki. Ha a lefedettség nem
100%, további teszteket tervezhetnek, hogy a kimaradt elemeket is teszteljék, ezzel növelve a
lefedettséget.
 A különböző elemek - mint pl. függvények, utasítások és döntések - kód lefedettségének
mérésére minden tesztelési szinten alkalmazhatnak eszközöket, de a gyakorlatban
elsősorban a komponenstesztnél és a komponens integrációs tesztnél teszik ezt. A
strukturális teszt alapja lehet a rendszer felépítése, mint például hívási hierarchia.
 A strukturális teszt megközelítéseket alkalmazhatják a rendszer-, rendszer integrációs- vagy
átvételi teszt szinteken (például vállalati modelleknél vagy menüstruktúráknál).

21
2.3.4 Változásokhoz kapcsolódó tesztelés (ellenőrző teszt (újratesztelés) és regressziós
teszt) (K2)
 Egy hiba felismerése és javítása után a szoftvert újra kell tesztelni, ezáltal meggyőződve arról,
hogy a hiba eltűnt. Ezt hívják ellenőrző tesztnek. A hibakeresés nem tesztelési, hanem
fejlesztési tevékenység.
o Ellenőrző teszt/újratesztelés (confirmation testing/re-testing): tesztelés, amikor
azokat a teszteseteket futtatjuk, amelyek a legutóbbi tesztfuttatásnál elbuktak. Célja
a hibajavítás sikerességének ellenőrzésére.
 A regressziós teszt egy már letesztelt program módosítása után történő ismételt tesztelése, a
változtatás(ok) eredményeként bekerült vagy feltárt hibák megtalálásának érdekében. Ezek a
hibák lehetnek a tesztelt szoftverben vagy egy másik, a tesztelt szoftverrel kapcsolatban lévő,
vagy attól független szoftverkomponensben. A regressziós tesztet akkor alkalmazzák, ha a
szoftvert vagy környezetét megváltoztatják. A regressziós teszt mértéke azon alapul, hogy
találnak-e hibákat az előzőleg jól működő szoftverben.
o Regressziós teszt (regression testing): Egy korábban már letesztelt program,
módosítást követő tesztelése, annak biztosítása érdekében, hogy a módosulás nem
okozott hibát a szoftver nem módosított részeiben. A teszt végrehajtása a szoftver
vagy a szoftverkörnyezet változtatásakor történik.
 A teszteknek megismételhetőknek kell lenniük, ha ellenőrző tesztre vagy regressziós teszt
támogatására kívánják őket alkalmazni.
 A regressziós teszt minden tesztelési szinten végrehajtható, és alkalmazható a funkcionális,
nem-funkcionális és strukturális tesztre. A regressziós tesztkészleteket sokszor futtatják le, és
többnyire lassan fejlődnek ki, így a regressziós tesztnél fontos lehet az automatizálás.

2.4 Karbantartási teszt (K2)

 Bevezetésüket követően a szoftverrendszereket gyakran évekig vagy évtizedekig használják.
Ez idő alatt a rendszert vagy a környezetét gyakran javítják, megváltoztatják, vagy bővítik. A
karbantartási tesztet létező, működő rendszeren hajtják végre, a tesztelésre a szoftver vagy
rendszer módosítása, migrációja, vagy kivonása ad okot.
o Karbantartás (maintenance): az alkalmazás átadása után végzett módosítások: hiba
javítások, teljesítmény vagy más jellemzők feljavítása illetve megváltozott
környezetre/követelményekre való alkalmazása. [IEEE 1219]
o Karbantartási teszt (maintenance testing): módosítások vagy megváltozott
környezet miatt a működő rendszeren végrehajtott teszt.
 A módosítások lehetnek tervezett kiegészítő változtatások (pl. a kiadáshoz kapcsolódóan),
javító vagy vészhelyzeti változtatások, a környezet változása, mint pl. az operációs rendszer
vagy adatbázis frissítése, vagy az operációs rendszer újonnan kialakult vagy nemrég
felfedezett sebezhető pontjainak védelme.
 A migrációra (pl. egy platformról egy másikra) vonatkozó karbantartási tesztnek tartalmaznia
kell az új környezet, illetve a megváltoztatott szoftver működési tesztjeit.
 A rendszer lecseréléséhez kapcsolódó karbantartási teszt magában foglalhatja az
adatmigráció tesztelését vagy, ha hosszú adat-megőrzési periódus szükséges, az archiválás
tesztelését.

22
2.4.1 Hatáselemzés és regressziós teszt
 A karbantartási teszt általában két részből áll:
o Változtatások kezelése
o Regressziós tesztelés – annak a tesztelése, hogy a karbantartási munkák kihatással
voltak-e a rendszer többi részére.
 A karbantartási teszt, a változtatások tesztelése mellett a javítások által nem érintett részek
széles körű regressziós tesztjét is magában foglalja. A karbantartási teszt mértéke függ a
változtatások okozta kockázattól, a meglévő rendszer méretétől és a változtatás mértékétől.
A változtatásoktól függően a karbantartási tesztet bármely illetve minden tesztelési szinten,
bármely és minden teszttípusra elvégezhetik.
 Hatáselemzés alatt értjük annak meghatározását, hogy a változtatások milyen befolyással
lesznek a már létező rendszerre; ez segít annak eldöntésében, hogy mennyi regressziós
tesztet kell végezni.
o Hatáselemzés (impact analysis): a szoftverváltozás kihatásának elemzése a
fejlesztési dokumentáció, a teszt dokumentáció, illetve a komponensek tekintetében,
a követelmények változásainak implementálása érdekében
 A karbantartási tesztet jelentősen megnehezíti, ha a specifikációk elavultak, vagy egyáltalán
nem állnak rendelkezésre.
 Tervezett módosítások: A karbantartási munkák 90%-át teszik ki.
o Tökéletesítő módosítások: a szoftvernek a felhasználói elvárásokhoz való igazítása,
pl. funkciók telepítése, vagy teljesítmény növelése.
o Adaptív módosítások: a szoftvernek a környezet változásaihoz való igazítása, pl. új
hardverhez, új rendszerszoftverhez, új szabályrendszerhez.
o Tervezett javító módosítások: Programhibák későbbre halasztható javítása.
 Ad hoc javító módosítások: Az azonnali megoldást kívánó programhibák javításával
kapcsolatosak, pl. hálózat összeomlás, hirtelen leállás, stb.

23
3 Statikus technikák (K2)
3.1 A statikus technikák és a tesztelési folyamat (K2)
 A dinamikus teszttel ellentétben – melyhez a szoftver futtatása szükséges –a statikus teszt
technikák a kód- vagy a projekt dokumentációk manuális vizsgálatára (felülvizsgálatok) és
automatizált elemzésére (statikus elemzés) támaszkodnak.
o Dinamikus teszt (dynamic testing): olyan teszt, amely magába foglalja egy
komponens, vagy rendszer szoftverének végrehajtását.
o Statikus teszt (static testing): Egy komponens vagy rendszer tesztelése specifikáció,
vagy implementáció szinten a szoftver futtatása nélkül. Például felülvizsgálat vagy
statikus forráskód elemzés.
 A felülvizsgálatot teljesen manuálisan is végre lehet hajtani, de léteznek a felülvizsgálatot
támogató eszközök. A legfőbb manuális tevékenység a projekt-termékek megvizsgálása és
észrevételezése. Bármely szoftver projekt-termék felülvizsgálható, úgy, mint a követelmény-
specifikációk, tesztterv-specifikációk, kód, teszttervek, tesztspecifikációk, tesztesetek,
tesztszkriptek, felhasználói útmutatók vagy weboldalak.
o Felülvizsgálat (review): egy termék vagy projekt státuszának értékelése. Célja, hogy
feltérképezze az eltéréseket a tervezett eredményekhez képest, valamint ajánlást
tegyen a továbblépéshez. Több típusa van, például: menedzsment felülvizsgálat,
informális felülvizsgálat, technikai felülvizsgálat, inspekció, átvizsgálás. [IEEE 1028]
 A felülvizsgálatok előnyei:
o Hibák korai megtalálása és javítása
o Fejlesztési termelékenység javítása
o Fejlesztési időtartamok csökkenése
o Tesztelési költségek és idő csökkenése
o A teljes élettartam költségeinek csökkenése
o Kevesebb hiba
o Jobb kommunikáció
o A felülvizsgálatokkal megtalálhatóak a hiányosságok, például a követelményekben,
melyeket a dinamikus teszttel valószínűleg nem találnának meg.
 A felülvizsgálatoknak, a statikus elemzésnek és a dinamikus tesztnek azonosak a céljaik – a
hibák azonosítása. Ezek a módszerek kiegészítik egymást: különböző technikák különböző
típusú hibák hatékony megtalálását segítik elő. A dinamikus teszttel összehasonlítva, a
statikus technikák inkább a meghibásodások okát találják meg, nem magukat a
meghibásodásokat.
 Az alábbi típushibákat könnyebb felülvizsgálattal megtalálni, mint dinamikus teszteléssel:
o Szabványoktól való eltérések
o Követelményekkel kapcsolatos hibák
o Tervezési hibák
o Karbantarthatóság hiánya
o Hibás interfész-specifikációk.

24
3.2 A felülvizsgálat folyamata (K2)
 A felülvizsgálatok típusai a nagyon informálistól (pl. ha a felülvizsgálatot végzőknek
nincsenek írásos utasításai) a nagyon formálisig (jól strukturált és szabályozott) terjednek. A
felülvizsgálati folyamat formalitása összefügg az olyan tényezőkkel, mint a fejlesztési
folyamat állapota, jogi, rendelkezési követelmények illetve az audit nyomvonal
szükségessége.
o Informális felülvizsgálat (informal review): olyan felülvizsgálat, amely nem formális
(dokumentált) eljáráson alapul
o Formális felülvizsgálat (formal review): dokumentált eljárásokkal és
követelményekkel (pl. inspekcióval) jellemzett felülvizsgálat
 Formális felülvizsgálat: audit.
 A felülvizsgálat végrehajtási módja a megegyezés szerinti célkitűzéstől függ (pl. hibák
megtalálása, megismerése vagy megvitatása és döntések meghozása konszenzus alapján).

3.2.1 Formális felülvizsgálat fázisai (K1)

Egy tipikus formális felülvizsgálat fázisai:
1. Tervezés: a felülvizsgálati feltételek meghatározása, a személyek kiválasztása, feladatok
kiosztása;
2. Belépési és kilépési feltétel meghatározása formálisabb felülvizsgálat esetén (pl. inspekció);
a megtekintendő dokumentumrészek kiválasztása (10 és 20 oldal között).
 Belépési feltétel (entry criteria): általános és speciális feltételek halmaza, amely
engedélyezi egy adott feladat végrehajtását. Az a cél, hogy ne indítsunk olyan
feladatokat, amelyek több elvesztegetett ráfordítást jelentenének, mint az elbukó
belépési feltételek kijavítása [Gilb és Graham]
3. Kezdő lépések: dokumentumok kiosztása; a célok, az eljárás és a dokumentumok
elmagyarázása a résztvevőknek;
4. Belépési feltétel ellenőrzése (formálisabb felülvizsgálatoknál).
5. Egyéni felkészülés: minden résztvevő maga végzi a felülvizsgálati találkozó előtt.
6. A lehetséges hibák, kérdések, megjegyzések feljegyzése.
7. Felülvizsgálati megbeszélés: vita, vagy naplózás, dokumentált eredményekkel vagy
feljegyzésekkel (formálisabb felülvizsgálatoknál). A megbeszélés résztvevői egyszerűen
feljegyezhetik a hibákat, javaslatokat tehetnek azok kezelésére, vagy döntéseket hozhatnak a
hibákról.
Minden hibát a súlyosságának feltűntetésével kell naplózni:
 Kritikus: kárt okoz.
 Jelentékeny: kárt okozhat.
 Elhanyagolható: nem valószínű, hogy kárt okoz.
8. Vizsgálat/értékelés, illetve feljegyzés a fizikai találkozó alatt, vagy a csoportos elektronikus
kommunikáció nyomon követése.
9. Átdolgozás
10. A megtalált hibák kijavítása, amit általában a szerző végez.
11. Ellenőrzés: a hibák javításának ellenőrzése, metrikák gyűjtése
 Metrika (metric): méréseknél használatos skála vagy módszertan. [ISO 14598]
12. A kilépési feltétel ellenőrzése (formálisabb felülvizsgálatoknál).

25
3.2.2 Feladatok, felelősségi körök (K1)
Egy tipikus formális felülvizsgálat a következő feladatköröket tartalmazza:
 Menedzser: dönt a felülvizsgálatok végrehajtásával kapcsolatban, kijelöli az időpontokat a
projekt ütemtervében, s dönt arról, hogy a felülvizsgálat célkitűzéseit teljesítették-e.
 Moderátor (inspekció vezető): vezeti a dokumentum(ok) felülvizsgálatát, ezzel együtt a
felülvizsgálat tervezését, a megbeszélés lebonyolítását és a találkozó utáni visszaellenőrzést.
A moderátor szükség esetén közvetít a különböző álláspontok között, és gyakran rajta múlik a
felülvizsgálat sikere.
o Moderátor (moderator): egy inspekció, vagy felülvizsgálat levezetéséért felelős
kulcsember vagy vezető.
 Szerző: a felülvizsgálandó dokumentum(ok) írója vagy fő felelőse.
 Felülvizsgálati résztvevők: meghatározott technikai vagy vállalati háttérrel rendelkező
személyek (nevezik őket vizsgálónak, vagy felülvizsgálónak is), akik a szükséges felkészülés
után meghatározzák és bemutatják a termék felülvizsgálatának eredményeit (pl. hibákat). A
felülvizsgálókat úgy kell kiválasztani, hogy különböző szempontokat és szerepköröket
képviseljenek; minden felülvizsgálati megbeszélésen részt kell venniük.
o Felülvizsgáló (reviewer): az a felülvizsgálaton (átvizsgáláson) résztvevő személy, aki
azonosítja és leírja a termékben vagy projektben azonosított eltéréseket. A
felülvizsgálókat célszerű úgy kiválasztani, hogy többféle nézőpontot, szerepkört
képviseljenek.
 Jegyzőkönyvvezető (vagy írnok): minden, a találkozó alatt felmerült ügyet, problémát és
nyitott kérdést dokumentál.
o Jegyzőkönyvvezető (scribe, recorder): Az a személy, aki rögzíti a felülvizsgálat során
megemlített összes hibát és azokat a javaslatokat, amik a folyamat javítására
irányulnak, naplózási formában. A jegyzőnek biztosítani kell, hogy a naplózás
olvasható és érthető legyen.

A felülvizsgálatok hatékonyabbá tehetők a dokumentumok különböző szempontok szerint történő

vizsgálatával, és ellenőrző listák használatával. Ilyen lehet például a felhasználói, karbantartói,
tesztelői vagy a műveletekre vonatkozó ellenőrző lista; vagy a tipikus követelmény-problémák
ellenőrző listája.

3.2.3 Felülvizsgálatok típusai (K2)

Egy dokumentum több felülvizsgálat tárgya is lehet. Ebben az esetben a felülvizsgálatoknak
különböző sorrendjük lehet. Például végezhetnek informális felülvizsgálatot egy technikai
felülvizsgálat előtt, vagy az ügyfelekkel végzett átvizsgálás előtt inspekciót hajthatnak végre a
követelmény-specifikáción. Az általános felülvizsgálat típusok fő jellemzői, opciói és céljai a
következők:

 Informális felülvizsgálat:
o nincs formális eljárás;
o lehetséges páros programozás vagy technikai irányítás a tervek és a kód
felülvizsgálatára;
o a dokumentáció opcionális;
o a hatékonyság a felülvizsgálatot végzőtől függően változó lehet;
o fő cél: költségkímélő módszerrel némi eredményt elérni.
 Átvizsgálás:

26
 o Átvizsgálás (walkthrough): egy dokumentum szerzője által végzett lépésenkénti
bemutató abból a célból, hogy információt gyűjtsön, valamint közös álláspontot
alakítson ki. [Freedman és Weinberg, IEEE 1028].
o Főbb jellemzői:
 a találkozót a szerző vezeti;
 forgatókönyvek, képzeletbeli futtatások, egyenrangú csoport;
 nem zárt szakaszok;
 opcionális: a felülvizsgálatot végzők találkozó előtti felkészülése,
felülvizsgálati jelentés, az eredmények listája, jegyzőkönyvvezető (a szerző
nem lehet ez a személy);
 a gyakorlatban a formája a nagyon informálistól a nagyon formálisig
terjedhet;
 fő célok: megismerés, megértés, hibák megtalálása.
 Technikai felülvizsgálat:
o Technikai felülvizsgálat (technical review): csoportos megbeszélés, amely a
technikai megközelítés tekintetében törekszik közös álláspontra jutni [Gilb és
Graham, IEEE 1028]
o Főbb jellemzői:
 dokumentált, definiált hibakeresési folyamat, egyenrangú kollégák és
technikai szakértők részvételével;
 egyenrangú felülvizsgálatként is végrehajtható, a menedzsment részvétele
nélkül;
 ideális esetben képzett moderátor vezeti (nem a szerző);
 találkozó előtti felkészülés;
 opcionális: ellenőrző lista használata, felülvizsgálati jelentés, eredmények
listája és a menedzsment részvétele;
 a gyakorlatban a formája a nagyon informálistól a nagyon formálisig
terjedhet;
 fő célok: megvitatás, döntéshozatal, alternatívák értékelése, hibák
megtalálása, technikai problémák megoldása és annak ellenőrzése, hogy a
specifikációk megfelelnek-e a szabványoknak.
 Inspekció:
o Inspekció (inspection): az egyenrangú felülvizsgálat egy típusa, amely a dokumentum
vizuális vizsgálatán alapul, hogy megtaláljuk a hibákat, vagy pl. a szabványokhoz
képest meglevő különbségeket, illetve a magasabb szintű dokumentációktól való
eltéréseket. A leginkább formális felülvizsgálati módszer, amely emiatt mindig
dokumentált eljáráson alapul. [IEEE 610, IEEE 1028 szerint]
o Főbb jellemzői:
 képzett moderátor vezeti (nem a szerző);
 általában egyenrangú vizsgálat;
 definiált szerepkörök;
 metrikákat is magában foglal;
 formális eljárás, a bemeneti és kimeneti feltételekre vonatkozó szabályok
és ellenőrző listák alapján;
 találkozó előtti felkészülés;
 inspekció jelentés, eredmények listája;
 formális visszaellenőrző eljárás;
 opcionálisan: folyamatjavítás

27
  Az átvizsgálást, technikai felülvizsgálatot és az inspekciót végre lehet hajtani egyenrangú
csoporton belül – ugyanazon szervezeti szinthez tartozó kollégák részvételével. Ezt a típusú
felülvizsgálatot nevezik „egyenrangú felülvizsgálatnak”.
o Egyenrangú felülvizsgálatnak (peer review): A szoftverfejlesztés alatt végzett
tevékenységek felülvizsgálata nem a tevékenységet elvégző által, melynek célja, hogy
hibákat fedezzen fel illetve javító javaslatokat hozzon. Példák: inspekció, technikai
felülvizsgálat, átvizsgálás.

3.2.4 Felülvizsgálatok sikerességi tényezői (K2)

A felülvizsgálatok sikerességi tényezői közé tartoznak a következők:
 Minden felülvizsgálatnak van világosan meghatározott célkitűzése.
 A felülvizsgálati célok eléréséhez a megfelelő személyeket kell bevonni (tesztelők bevonása)
 Hibák megtalálását eredménynek kell tekinteni, és tárgyilagosan kezelni őket.
 Foglalkozni kell az emberi és pszichológiai tényezőkkel (pl. a szerző számára pozitív
tapasztalatként jelenjen meg a felülvizsgálat).
 Olyan felülvizsgálati technikák alkalmazása, melyek illeszkednek a szoftver projekt-termékek
típusához és szintjéhez valamint a felülvizsgálatot végzőkhöz.
 Ha lehetséges, a hibák azonosításának hatékonyabbá tételéhez ellenőrző listák, vagy
szerepkörök alkalmazhatók.
 A felülvizsgálati technikákról képzést tartanak, különösen a formálisabb technikák esetében,
mint pl. az inspekció.
 A menedzsment támogatja a felülvizsgálati eljárást (pl. a projekt ütemtervében megfelelő
időt biztosít a felülvizsgálati tevékenységekre).
 Hangsúlyt fektetnek a tanulásra és a folyamat javítására.

3.3 Statikus elemzés eszközökkel (K2)

 A statikus elemzés célja megtalálni a hibákat a szoftver forráskódjában és a
szoftvermodellekben. A statikus elemzést az eszköz által vizsgált szoftver futtatása nélkül
végzik, míg a dinamikus tesztnél futtatják a szoftverkódot. A statikus elemzés felderíthet
olyan hibákat, melyeket teszttel nehéz megtalálni. A felülvizsgálatokhoz hasonlóan a statikus
elemzéssel inkább programhibákat, mint meghibásodásokat találhatunk.
o Statikus elemzés (static analysis): A szoftver elemek (például követelmények vagy
kód) elemzése azok futtatása nélkül.
 A statikus elemzés eszközei a programkódot (pl. vezérlési folyam és adatfolyam) valamint a
generált kimenetet (mint pl. HTML vagy XML) elemzik.
 Maga a fordítóprogram is tekinthető statikus elemzési eszköznek, mivel szimbólumtáblát
készít, rámutat a helytelen használatra és ellenőrzi az egyezményes kódnyelvnek
(szintaxisnak) való megfelelést.
o Fordítóprogram (compiler): egy olyan szoftver eszköz, amely a magas szintű
programnyelvi kifejezéseket a gépi kódú megfelelőjére fordítja.
 A statikus elemzés előnyei:
o A hibák korai felismerése, a teszt végrehajtása előtt.
o Hibák megelőzése fejlesztési tapasztalatok használatával.

28
 o Korai figyelmeztetések a kód vagy a terv gyanús tényezőiről a metrikák. számításával,
például a magas komplexitás mérése.
o Olyan hibák azonosítása, melyeket dinamikus teszttel nehéz megtalálni.
o Függőségi viszonyok és összeférhetetlenségek felismerése a szoftvermodellekben,
például linkek.
o A kód és a terv jobb karbantarthatósága.
 A statikus elemző eszközök által felismert tipikus hibák:
o meghatározatlan értékű változóra való hivatkozás;
o összeférhetetlen interfész modulok és komponensek között;
o soha nem használt változók;
o nem elérhető (halott) kód;
o hibás vagy hiányzó logika (potenciálisan végtelen ciklus)
o túl nagy komplexitás
o programozási szabványok megsértése;
o biztonsági rések;
o szintaxis megsértése a kódban vagy a szoftvermodellekben.
o nem megfelelő kommentezés
 A statikus elemző eszközöket általában a fejlesztők használják (előre meghatározott
szabályoknak és programozási szabványoknak való megfelelés ellenőrzése céljából) a
komponens- és integrációs teszt előtt és után, illetve a tervezők a szoftver-modellezés
során. A statikus elemző eszközök számos figyelmeztető üzenetet generálhatnak, melyeket
megfelelően kell kezelni az eszköz hatékony használata érdekében.

3.3.1 Kódolási szabványok

 A kódolási szabványok programozási szabályokból, elnevezési konvenciókból és elrendezési
specifikációkból tevődnek össze.
 Javasolt, hogy már létező szabványokat alkalmazzunk, mert egyrészt rengeteg munkát
spórolhatunk meg vele, másrészt így nagyobb eséllyel állnak rendelkezdésünkre ellenőrző
eszközök.

3.3.2 Kódmetrikák
 Statikus kódelemzés sokán a kód szerkezeti jellemzőiről nyerünk információkat, például a
megjegyzések gyakoriságáról, a beágyazás mélységéről, a ciklomatikus számról és a sorok
számáról a kódban.
 Sokféle szerkezeti mérőszám létezik, amelyből megtudhatjuk, hogy mennyi munkával jár a
kód megírása, a kód megértése változások estén, vagy a kód tesztelése egyes eszközök vagy
technikák használatával.
 Tapasztalt programozók tudják, hogy a kód 20%-a okozza a problémák 80%-át, és
komplexitás-analízis segítségével megtalálható ez a 20%. Komplexitás-metrikák segítségével
azonosítjuk a magas kockázatú, komplex területeket.
o Komplexitás (complexity): a szoftver tervének, illetve belső struktúrájának
összetettsége megértés, karbantartás, valamint verifikálás szempontjából.
 A ciklomatikus komplexitás (McCabe) metrikája a programban lévő döntéseken alapul. Ez
fontos a tesztelőknek, mivel ez alapján fel tudják becsülni, hogy mennyi tesztelés szükséges
ahhoz, hogy a gyakorlatban elkerülhetőek legyenek a programhibák. Másképp kifejezve a kód
komplexebbnek azonosított részeit küldik felülvizsgálatokra és kiegészítő dinamikus
tesztelésre.

29
 o Ciklomatikus komplexitás (cyclomatic complexity): a független útvonalak száma a
programban. A ciklomatikus komplexitás definíciója: L – N + 2P, ahol
 L = az élek/kapcsolatok száma a gráfban
 N = a csomópontok száma a gráfban
 P = a nem kapcsolódó részek (független komponensek) a gráfban, pl egy
meghívott gráf és alprogram
 Példa:
IF A =354
THEN IF B > C
THEN A = B
ELSE A = C
ENDIF
ENDIF
Print A
 Ábrázolása

 A programból generált vezérlési folyam hét csomópontot és nyolc élet tartalmaz, és nem
szerepel meghívott gráf sem alprogramként, ezért P=1, így a ciklomatikus komplexitás
képletét használva 8 – 7 + 2 = 3 eredményt kapjuk.
o Vezérlési folyam (control flow): az események (útvonalak) sorrendje a végrehajtás
során
 Kiszámolhatjuk még döntési pontok alapján is az eredményt, itt két döntési pont van, ezért a
ciklomatikus komplexitás 2 + 1 = 3.

3.3.3 Kódszerkezet
 A kód szerkezetével kapcsolatban több szempontot is érdemes figyelembe venni
o a vezérlési folyam szerkezetét
o az adatfolyam szerkezetét
o az adatszerkezetet
 A vezérlési folyam szerkezete határozza meg az utasítások végrehajtásának sorrendjét.
Elérhetetlen (halott) kódok azonosítására is kiválóan alkalmazható.
 Az adatfolyam szerkezete egy adatelem útját követi nyomon, ahogy a kód hozzáfér és
módosítja. Sokszor az adatokon alkalmazott tranzakciók sokkal bonyolultabbak, mint az őket
végrehajtó utasítások. Az adatfolyam-szerkezeti mérőszámok alkalmazásával azonban
kimutatható, hogy miként viselkednek az adatok, miközben átalakítja őket a program. Olyan
programhibákat is meg lehet találni, mint a meghatározatlan értékű változóra való
hivatkozások, és felfedezhetők a program által sosem használt változók is.

30
 o Adatfolyam (data flow): Az adatobjektumok állapotsorrendjének, valamint
lehetséges változásainak absztrakt megjelenítése, ahol az objektum állapota
létrehozás, használat, illetve megszüntetés lehet
 Az adatszerkezet nagy mennyiségű információt biztosít az adatkezelő programok írásának
nehézségeiről, valamint a program megfelelő működését kimutatni hivatott tesztesetek
műszaki tervezésének nehézségeiről. Azaz egy program néha azért bonyolult, mert bonyolult
adatszerkezettel rendelkezik, és nem pedig az adatfolyam bonyolult irányítása miatt.

31
4 Műszaki teszttervezési technikák (K3)
4.1 A teszt fejlesztési folyamata (K2)
Az ebben a fejezetben bemutatott eljárást különböző módokon lehet végrehajtani, a kevéssé, vagy
egyáltalán nem dokumentált jelentő nagyon informális módtól a nagyon formálisig (mint azt lentebb
tárgyaljuk). A formalitás szintje a tesztelés tényezőitől függ, ide tartozik a szervezet, a tesztelés és a
fejlesztési folyamat érettsége, az időbeli megkötések és a résztvevő személyek.

4.1.1 A tesztdokumentáció formalitása

A nagyon formális teszteléshez átfogó, ellenőrzött dokumentáció tartozik. Az ilyen dokumentációtól
elvárható, hogy részletesen tartalmazza a pontosan meghatározott inputokat és tesztelés várható
eredményeit. A nagyon informális teszteléshez nem akár egyáltalán nem is tartozik dokumentáció,
vagy csak az egyes tesztelőknek vannak jegyzeteik. A formalitás megfelelő mértéke a felhasználástól
függ, az alapossága az időkorlátoktól. Igény esetén tudni kell növelni a formalitás mértékét.

4.1.2 Tesztelemzés: a tesztelési feltételek megállapítása

 A tesztelemzés során történik a tesztbázis dokumentáció elemzése annak érdekében, hogy
meghatározzuk, hogy mit kell tesztelni, azaz megállapításra kerülnek a tesztelési feltételek.
A tesztelési feltétel olyan elem, vagy esemény, melyet egy vagy több teszteset ellenőriz (pl.
egy függvény, tranzakció, minőségi jellemző vagy strukturális elem).
 Mivel nem tesztelhetünk le mindent, ki kell választani a lehetséges tesztek egy részhalmazát.
Ez a részhalmaz, akár nagyon is szűk lehet, azonban fontos, hogy segítségével nagy
valószínűséggel megtalálható legyen a rendszerben lévő programhibák többsége. Szükségünk
van egy ésszerű koncepcióra, ami alapján szelektálhatunk, ilyenek a tesztelési technikák (azaz
műszaki teszttervezési technikák)
o Műszaki teszttervezési technika (test design technique): a tesztesetek készítésére,
származtatására és kiválasztására alkalmazott eljárás.
 A tesztelési technikák segítséget nyújtanak abban, hogy egy adott rendszerhez az összes
lehetséges teszteset közül kiválasszuk a tesztek egy megfelelő halmazát. A különböző
technikák különböző szempontok alapján vizsgálják a szoftvert.
 A tesztelési feltételektől elvárható, hogy visszavezethetők legyenek tesztbázisbeli
forrásaikhoz, vagyis nyomonkövethetők legyenek.
o Nyomonkövethetőség (traceability): a dokumentáció és a szoftver összefüggő
egységeinek vizsgálata pl. a követelmények és a hozzájuk tartozó tesztesetek közötti
kapcsolatra.
 A nyomonkövethetőség kialakítása a tesztelési helyzetektől vissza a specifikációkig és
követelményekig lehetővé teszi a hatáselemzést a követelmények változása esetén, valamint
a teszthalmazra meghatározható követelmény-lefedettséget is. A tesztelemzés során a
részletes tesztelési megközelítést kivitelezzük, hogy azután kiválaszthassuk az alkalmazandó
műszaki teszttervezési technikákat, többek között a felismert kockázatok alapján.

4.1.3 Műszaki tesztterv: a tesztesetek meghatározása

 A teszt műszaki tervezése során a tesztesetek és tesztadatok megalkotása és meghatározása
történik. Egy teszteset a következőkből áll: bemeneti értékek halmaza, végrehajtási
előfeltételek, elvárt eredmények és végrehajtás utáni feltételek, melyeket bizonyos
tesztelési feltétel(ek) lefedésére fejlesztenek. A „Szoftverteszt Dokumentáció Szabvány”

32
 (IEEE 829) tárgyalja a (tesztelési feltételeket is tartalmazó) műszaki tesztterv (test design)
specifikációk és a teszteset specifikációk tartalmát.
o Műszaki tesztterv specifikáció (test design specification): a tesztelési feltételeket és
követelmények teljesítését definiáló dokumentáció, amely tartalmazza a tesztelés
megközelítését és a magas szintű teszteseteket (IEEE 829 alapján)
 Egy teszteset specifikációjának részeként meg kell határozni az elvárt eredményeket,
melyeknek tartalmazniuk kell kimeneti értékeket, az adatok és állapotok változásait, valamint
a teszt minden más következményét is. Ha az elvárt eredmények nincsenek meghatározva,
akkor lehet, hogy egy kézenfekvő, de hibás eredmény jó eredményként lesz értelmezve. Az
elvárt eredményeket lehetőleg a teszt végrehajtása előtt meg kell határozni.
o Teszteset specifikáció (test case specification): egy tesztelemre vonatkozó, a
teszteseteket meghatározó dokumentáció (cél, bemenetek, tesztelési
tevékenységek, várt eredmények, végrehajtás előfeltételei) [IEEE 829 alapján].

4.1.4 A teszt megvalósítása: a tesztelési eljárás vagy szkript specifikálása

 A teszt megvalósítása alatt a tesztesetek kifejlesztése, megvalósítása, priorizálása és
tesztelési eljárás specifikációba rendezése történik. A tesztelési eljárás (vagy a manuális
tesztszkript) részletezi a tesztvégrehajtás műveleteinek sorrendjét. Ha a teszteket
tesztvégrehajtási eszközzel futtatjuk, akkor a műveletek sorrendjét a tesztszkriptben kell
meghatározni (ami egy automatizált tesztelési eljárás).
o Teszteljárás specifikáció (test procedure specification): a tesztelés futtatásának
tevékenységsorozatát rögzítő dokumentum. Tesztszkript illetve manuális tesztszkript
néven is ismert.
o Tesztszkript (test script): legtöbbször tesztelés eljárás specifikációra használt
kifejezés, elsősorban automatizált tesztelés esetén.
 A különböző tesztelési eljárásokból és automatizált tesztszkriptekből ezután tesztvégrehajtási
ütemterv készül, mely meghatározza a különböző tesztelési eljárások és esetenként
automatizált tesztszkriptek végrehajtási sorrendjét, valamint hogy mikor és ki hajtja őket
végre. A tesztvégrehajtási ütemtervnél figyelembe kell venni olyan tényezőket, mint a
regressziós teszt, priorizálás, technikai és logikai függőségi viszonyok.
o Tesztvégrehajtási ütemterv (test execution schedule): a tesztelési eljárások
végrehajtásának ütemezése. A tesztelési eljárások egymásutániságuknak
megfelelően, sorrendbe rendezve jelennek meg.

4.2 Műszaki teszttervezési technikák kategóriái (K2)

 A műszaki teszttervezési technikák célja a tesztelési feltételek és a tesztesetek
meghatározása.
 Két fő kategória van: a statikus és a dinamikus. A dinamikus technikákat további három
kategóriára oszthatjuk: specifikáció alapú (feketedoboz vagy viselkedési), struktúra alapú
(fehérdoboz vagy strukturális), valamint tapasztalat alapú technikák.

4.2.1 Specifikáció alapú (feketedoboz) technikák

 Hívhatjuk bemenet/kimenet-vezérelt technikának is, mert úgy tekintünk erre a tesztre, mint
egy bemenetekkel és kimenetekkel rendelkező fekete dobozra, és nem foglalkozunk a doboz
belsejében lévő rendszernek vagy komponensnek a struktúrájával.
 A tesztelő arra összpontosít, hogy mit csinál a szoftver és nem arra, hogy miként teszi.

33
  Feketedoboz/specifikáció alapú teszttervezési technika (black-box/specification-based test
design technique): azon módszer, amelynél a szoftver specifikáció alapján, a program belső
szerkezetének ismerete nélkül tervezünk funkcionális vagy nem funkcionális teszteket.
o A funkcionális tesztelés arra összpontosít, amit a rendszer csinál, vagyis annak a
jellemzőire és funkcióira.
o A nem funkcionális tesztelés pedig arra, hogy mennyire jól csinál valamit a rendszer,
vagyis a teljesítményre, a felhasználhatóságra, a hordozhatóságra, a
karbantarthatóságra, stb.
 A tesztelés minden szintjén alkalmazhatóak, ahol van valami specifikáció

4.2.2 Struktúra alapú (fehérdoboz) technikák

 A szoftver belső struktúráját használják fel a tesztesetek elkészítéséhez.
 Rendszerint fehérdoboz vagy üvegdoboz technikának nevezzük őket, alkalmazásuk során
fontos a szoftver megvalósításának, vagy működési módjának ismerete.
 Strukturális technikával vizsgálhatjuk például a szoftverben található hurkokat.
 Fehérdoboz/struktúra alapú teszttervezési technika (white-box/structure-based test design
technique): Olyan eljárás, amely a teszteseteit egy komponens vagy rendszer belső
struktúrájának analíziséből származtatja.
 A tesztelés összes szintjén alkalmazhatjuk. A fejlesztők a komponenstesztelés és a
komponensintegrációs tesztelés során alkalmazzák, de a rendszer és átvételi teszteken is
alkalmazhatjuk.
 Lehet funkcionális és nem funkcionális is.

4.2.3 Tapasztalat alapú tesztelési technikák

 A tapasztalat alapú technikákban a közreműködők ismeretei, képességei és háttere az, ami
elsődlegesen hozzájárul a tesztelési feltételek és a tesztesetek megalkotásához.
 Fontos minden résztvevő tapasztalata, mert különböző nézőpontokat visznek a tesztelésbe,
és a műszaki teszttervezés folyamatába. Ismereteik lehetnek a valószínűsíthető hibákról, és
azok elosztásáról.
 Tapasztalat alapú teszttervezési technika (experience-based test design technique): Olyan
teszttervezési módszer, amely során a tesztelők tapasztalata, tudása és megérzései alapján
származtatunk, illetve választunk teszteseteket.
 A specifikáció alapú és a struktúra alapú technikák kiegészítéseként alkalmazzuk, továbbá
akkor, ha nem állnak rendelkezésre specifikációk, vagy ha vannak, akkor azok hiányosak.

4.3 Specifikáció alapú, vagy feketedoboz technikák (K3)

4.3.1 Ekvivalencia partícionálás (K3)
 Az ekvivalencia osztályozás (ekvivalencia partícionálás, EP) egy jó átfogó specifikáció alapú
feketedoboz technika, amely a tesztelés minden szakaszán alkalmazható, és gyakran
érdemes először ezt használni. (Kimerítő tesztelés lehetetlen.)
o Ekvivalencia partícionálás (equivalence partitioning): Olyan feketedoboz tesztelési
módszer, amely során olyan teszteseteket készítünk, amelyek az ekvivalencia
partíciók egyes reprezentánsait tesztelik. Jellemzően minden egyes ekvivalencia
partíciót érdemes legalább egyszer lefedni.

34
  A technika azon az elgondoláson alapul, hogy a tesztelési feltételek egy halmazát azonosnak
tekinthető csoportokra vagy halmazokra osztjuk (azaz partícionáljuk). Ezeket a rendszer
azonosan (ekvivalensen) kezeli. Innen az ekvivalencia osztály elnevezés.
o Ekvivalencia osztály/partíció (equivalence partition): bemeneti, vagy kimeneti
értéktartomány, amelyre a specifikáció alapján a rendszernek ugyanúgy kell
viselkednie
 Ekvivalencia partíciók (vagy osztályok) léteznek az érvényes adatokra és az érvénytelen –
elutasítandó – adatokra is. A partíciók alkalmazhatók továbbá kimenetekre, belső értékekre,
idővel kapcsolatos értékekre (pl. egy esemény előtt vagy után) valamint interfész
paraméterekre (pl. integrációs teszt alatt). A partíciók lefedésére tesztek tervezhetők
 Az ekvivalencia partícionálás alkalmazása során minden egyes osztályból elég csak egyetlen
feltételt tesztelnünk, mivel azt feltételezzük, hogy egy osztályon belül minden feltételt
azonos módon kezelt a szoftver.
 A szoftvernek tudnia kell megfelelően kezelni az érvénytelen osztályba eső értékeket is úgy,
hogy hibaüzenetet küld.

4.3.2 Határérték elemzés (K3)

 A határérték elemzés (BVA – boundary value analysis) az osztályok közötti határok
tesztelésén alapul.
o Határérték (boundary value): egy olyan bemeneti, vagy kimeneti érték, amely egy
ekvivalencia partíció szélén, vagy attól a legkisebb távolságra helyezkedik, például
egy tartomány minimum, vagy maximum értékei
o Határérték elemzés (boundary value analysis): a program változóinak, illetve
paramétereinek szélsőérték- elemzésén alapuló feketedoboz teszttervezési technika.
 Az ekvivalencia partíciók határain kisebb az esély a helyes viselkedésre, ezért ott a tesztek
nagy eséllyel találnak hibákat. Egy partíció maximális és minimális értékei a határértékek.
Az érvényes partíciók határértéke érvényes határérték; míg az érvénytelen partíciók határa
az érvénytelen határérték. A tesztek tervezhetők úgy, hogy lefedjék az érvényes és az
érvénytelen határértékeket is. A tesztesetek tervezésénél minden határértékhez választani
kell egy tesztet.
 A határérték elemzés minden tesztelési szinten alkalmazható. Viszonylag egyszerű az
alkalmazása, hibakeresési képessége jó; a részletes specifikációk hasznosak.
 Léteznek nyílt határok, amikor nem tudjuk megmondani a tartomány minimum vagy a
maximum értékét, ekkor először a specifikációt átolvasva kell határértéket keresni, ha nincs
semmi, akkor tapasztalat alapú megközelítést alkalmazunk.

4.3.3 Döntési tábla teszt (K3)

 A döntési táblák jól használhatók logikai feltételeket tartalmazó rendszerkövetelmények
felvételére és a belső rendszerfelépítés dokumentálására. Alkalmazhatók a rendszer által
megvalósított komplex vállalati szabályok rögzítésére.
o Döntési tábla (decision table): Olyan táblázat, amely a bemenetek, és/vagy a
különböző kiváltó okok és a hozzájuk kapcsolt eredmények, és/vagy hatások
kapcsolatát mutatja
o Döntési tábla teszt (decision table testing): Feketedoboz teszttervezési módszer,
amely során olyan teszteseteket tervezünk, amelyek a döntési táblában szereplő
különböző okok és bemenetek kombinációit igyekszik tesztelni

35
  Döntési táblák létrehozásakor elemzik a specifikációt, és meghatározzák a rendszer
feltételeit és műveleteit. A bemeneti feltételek és műveletek leggyakrabban oly módon
vannak megadva, hogy csak igaz, vagy hamis értékek lehetnek (Boolean).
 A döntési tábla tartalmaz kiváltó okokat, melyek gyakran az összes bemeneti feltétel igaz
illetve hamis értékeinek kombinációi, valamint a feltételek kombinációihoz tartozó
eredményeket. A tábla minden oszlopa egy üzleti szabályhoz tartozik, amely megadja a
feltételek egy egyedi kombinációját, ez pedig az ahhoz a szabályhoz tartozó műveletek
végrehajtását eredményezi. A döntési tábla tesztnél leggyakrabban alkalmazott lefedettségi
szabvány szerint legalább egy tesztnek kell lennie oszloponként, amely általában minden
kiváltó ok kombinációt lefed.
 A döntési tábla teszt legfőbb előnye az, hogy a feltételek olyan kombinációit hozza létre,
melyeket a tesztelés során esetleg nem érintenének. Minden olyan helyzetben alkalmazható,
ahol a szoftver által végrehajtott művelet különböző logikai döntéseken alapul.

4.3.4 Állapotátmenet teszt (K3)

 A rendszer az adott jellemzőitől vagy a megelőző eseményektől (az állapottól) függően
különböző válaszokat adhat. Ebben az esetben a rendszer helyzetét állapotátmenet
diagrammal lehet bemutatni. Ennek segítségével a tesztelő vizsgálhatja a szoftvert a
különböző állapotaiban, az állapotok közötti átmeneteket, az állapotváltozásokat
(átmeneteket) kiváltó bemeneteket és eseményeket valamint a műveleteket, melyek az
átmenetek következményei.
o Állapotátmenet teszt (state transition testing): Egy feketedoboz teszttervezési
technika, amiben úgy tervezzük meg a teszteseteket, hogy érvényes és érvénytelen
állapotátmeneteket generáljanak.
o Állapotdiagram (state diagram): Egy komponens vagy rendszer állapotait ábrázoló
diagram, ami mutatja az állapotváltozást okozó eseményeket vagy körülményeket is.
[IEEE 610]
 A tesztelt rendszer vagy objektum állapotai elkülöníthetők, beazonosíthatóak és véges
számúak.
 Az állapottábla megmutatja az állapotok és a bemenetek közötti összefüggéseket, s ebben a
lehetséges érvénytelen átmenetek külön megjelölhetők. A tesztek tervezhetők az állapotok
egy tipikus sorrendjének lefedésére, minden állapot lefedésére, minden átmenet
végrehajtására, az átmenetek adott sorrendjeinek végrehajtására vagy az érvénytelen
átmenetek tesztelésére.
 Az állapotátmenet modellnek négy alapvető része van:
o állapotok, amelyeket a szoftver felvehet
o átmenetek az egyik állapotból a másikba
o események, melyek átmeneteket okoznak
o tevékenységek, melyeket az átmenetek eredményeként hajtunk végre.
 Az állapotátmenet tesztet gyakran használják a beágyazott szoftver-iparban és
általánosságban a műszaki automatizálásban. Ez a technika jól alkalmazható a meghatározott
állapotokkal rendelkező vállalati objektumok modellezésére vagy képernyő-dialógus
folyamok (pl. internetes alkalmazások vagy üzleti forgatókönyvek) tesztelésére.
 Példa: Lift

S4 Emelet - nyitva Emelet - csukva S3

36
 o Összes átmenet lefedése, a lehető legkevesebb lépéssel:
S1, S1, S2, S2, S3, S3, S4, S4, S3, S2, S1
o Érvénytelen átmenetek száma: 6

4.3.5 Használati eset teszt (K2)

 A használati eset a rendszer egy adott szereplője (felhasználója) általi használat leírása.
Minden használati eset a szereplő és a rendszer egy adott cél érdekében történő
kölcsönhatását írja le. A szereplő általában egy személy, de az is lehet, hogy egy másik
rendszer. A használati eset lépések sorozatát tartalmazza. Azt írjuk le, hogy a szereplő mit
tesz és mit lát.
 Minden használati eset, ezek a használati eset lezárása után megfigyelhető eredményeket és
a rendszer végső állapotát tartalmazzák. A használati esetnek általában van egy fő (vagyis
legvalószínűbb) forgatókönyve, valamint esetenként alternatív mellékágai.
o Használati eset teszt (use case testing): olyan fekete doboz teszttervezési technika,
amelyekben a műszaki tesztterveket (test design) különböző felhasználói
forgatókönyvek futtatására készítették.
 A használati esetek leírják az „eljárási folyamatot” a rendszer valószínűsíthető használata
alapján, így a használati esetekből származtatott tesztesetek a leghasznosabbak az eljárási
folyamatban található hibák felderítésére a rendszer valós használata közben. A használati
esetek (gyakran forgatókönyvekként említik őket) nagyon hasznosak átvételi tesztek
tervezésére, amelyekben az ügyfél/felhasználó részt vesz. Alkalmazhatók a különböző
komponensek kölcsönhatása és interferenciája által okozott integrációs hibák felderítésére,
melyeket az egyéni komponensteszt nem találna meg.

4.4 Struktúra alapú, vagy fehérdoboz technikák (K3)

 A struktúra alapú teszt / fehérdoboz teszt a szoftver, vagy rendszer ismert struktúrájára
alapul, mint ahogy a következő példákban is látható:
o Komponens szint: a struktúra maga a kód, vagyis utasítások, döntések, elágazások.
o Integrációs szint: a struktúra lehet egy hívási fa (egy diagram, melyben modulok
hívnak más modulokat).
o Rendszer szint: a struktúra lehet egy menüstruktúra, egy vállalati folyamat vagy egy
weboldal struktúra.
 A tesztlefedettség egy tesztkészlet által végrehajtott tesztelés mértékének specifikus mérése.
o Lefedettség (coverage): annak százalékos mérőszáma, hogy az adott lefedettségi
elemet milyen arányban hívta meg a teszteszköz
 Lefedettségi mérőszám:
A végrehajtott lefedettségi elemek száma
Lefedettség = x 100 (%)
Az összes lefedettségi elem száma

 A 100%-os lefedettség nem ugyanaz, mintha valami 100%-ban tesztelt. A lefedettségi

technikák egy többdimenziós fogalomnak csak az egyik dimenzióját mérik.

4.4.1 Utasítás szintű teszt és lefedettség (K3)

 A komponenstesztnél az utasítás szintű lefedettség annak értékelése, hogy valamely
teszteset készlet a futtatható utasítások hány százalékát érintette. Az utasítás szintű tesztnél

37
 a származtatott tesztesetek meghatározott utasításokat hajtanak végre, általában az utasítás
lefedettség növelése érdekében.
o Utasításlefedettség (statement coverage): A tesztkészlet által kipróbált futtatható
utasítások százaléka.
 Alacsonyabb tesztelési szinteken alkalmazzák
 Eszköztámogatás szükséges
 A tesztelés minősége a lefedettség növelésével javítható
 Tipikus elvárás: 70-100%
 Képlete:

A végrehajtott utasítások száma

Utasításlefedettség = x 100 (%)
Az összes utasítás száma

4.4.2 Döntési teszt és lefedettség (K3)

 A döntési lefedettség – amely összefüggésben áll az elágazás teszttel – annak értékelése,
hogy valamely teszteset készlet a döntési eredmények (pl. egy If utasítás Igaz vagy Hamis
lehetőségei) hány százalékát hajtotta végre. A döntési tesztnél a származtatott tesztesetek
speciális döntési eredményeket hajtanak végre, általában a döntési lefedettség növelése
érdekében.
o Döntési lefedettség (decision coverage): A tesztkészlet végrehajtása során a döntési
eredmények meghívásának százalékos végrehajtási aránya. 100%-os döntési
lefedettség 100%-os elágazási lefedettséget és 100%-os utasítás lefedettséget jelent.
 Nem elég a feltételes utasításokat lefedni, hanem azok mindkét ágát (igaz, hamis) végre kell
hajtani.
 Alacsonyabb tesztelési szinteken alkalmazzák
 Eszköztámogatás szükséges
 A döntési teszt a vezérlési folyam tesztelés egy formája, mivel a döntési pontokkal egy
sajátos vezérlési folyamot hoz létre. A döntési lefedettség magasabb rendű az utasítás
lefedettségnél: 100%-os döntési lefedettség esetén garantált a 100%-os utasításlefedettség,
aminek fordítottja nem igaz.
 Képlete:

A végrehajtott döntési események száma

Döntési lefedettség = x 100 (%)
Az összes döntési esemény száma

4.4.3 Egyéb struktúra alapú technikák (K1)

 Elágazás lefedettség: szoros kapcsolatban van a döntési lefedettséggel, 100%-os lefedettség
esetén ugyanazt az eredményt adják.
 A strukturális lefedettségnek a döntési lefedettségnél magasabb rendű szintjei is vannak,
mint például a feltétel lefedettség vagy a többszörös feltétel lefedettség.
 A lefedettség fogalma alkalmazható más tesztelési szinteken is (pl. az integrációs szinten),
ahol a modul-, komponens- vagy osztály lefedettség kifejezhető azzal, hogy valamely
teszteset készlet a modulok, komponensek vagy osztályok hány százalékát érintette.

38
 A kód strukturális tesztjében hasznos az eszköztámogatás.

Lefedettség példák
1. példa:
A=? A=?
B=?
if A > B B=?
then
C=A–B if A > B
else I H
C=B–A
C=A-B C=B-A
endif
print C
Print C

 Utasításlefedettség:
o 1. teszteset: A = 4, B = 2  A feltétel igaz lesz, ezért C-nek úgy ad értéket, hogy A-ból
kivonja a B-t, és kiírja, hogy a C 2.
Az igaz ág fut le, a 6 utasításból 5-öt érintettünk, ezért a lefedettség 83 %-os.
o 2. teszteset: A = 4, B =4  A hamis ág fut le, a maradék 1 utasítás is lefut, így már
100%-os a lefedettség.
 Döntési lefedettség:
o 1 teszteset: A > B  az igaz ág fut le, így a döntési lefedettség 50%,
o 2 teszteset: B > A  a hamis ág fut le, így már megvan a 100%

2. példa:
… C=0
C=0
if A > B then
if A > B
C=A–B H
I
else
if B > A then C=A-B if B > A
C=B–A H I
endif
C=B-A
endif
print C
… Print C

 Utasításlefedettség:
o 1. teszteset: A = 4, B = 2  A feltétel igaz lesz, az igaz ág fut le, a 6 utasításból 4-et
érintettünk, ezért a lefedettség 66 %-os

39
 o 2. teszteset: B = 3, A = 2  A nem nagyobb, mint B, a hamis ágra megyünk, ahol
megvizsgáljuk, hogy B tényleg nagyobb, mint A, ezért C = B – A lefut, és C kap egy 1-
es értéket. Így már 100%-os a lefedettség.
o Ha csak a 2. tesztesetet futtatom, akkor a lefedettség 83%.
 Döntési lefedettség:
o 1. teszteset: A > B  az első if igaz ága letesztelve (4 esetből 1): 25%
o 2. teszteset: B > A  első if hamis ága, és második if igaz ága: 75%
o 3. teszteset: B = A  első if hamis ága, és második if hamis ága: 100%

4.5 Tapasztalat alapú technikák (K2)

4.5.1 Hibasejtés
 Szisztematikus módszer
 Elkészül a lehetséges hibák listája, tesztesetek készülnek ez alapján, aztán végrehajtják őket.
 A hibasejtés technikáját mindig egy formálisabb technika kiegészítéseként kell alkalmazni
o Hibasejtés (error guessing): olyan műszaki teszttervezési módszer, amely során a
tesztelők tapasztalata alapján próbáljuk megsejteni a tesztelendő szoftverben levő
hibákat, illetve ez alapján próbálunk megfelelő teszteket tervezni
 A hibasejtés sikere nagyban függ a tesztelő szaktudásától és intuíciójából, valamint a
hasonló alkalmazásokkal és technológiákkal kapcsolatos tapasztalataitól.
 A tesztelés kulcsa a lista, ami elkészíthető:
o Tapasztalat alapján
o Korábban megtalált hibák alapján
o Hasonló rendszerek gyenge pontjainak ismerete alapján
o Ellenőrző listák

4.5.2 Felderítő teszt

 Aktív megközelítés, melyben a tesztelők munkájának a tervezés minimális, a végrehajtás
pedig maximális részét teszi ki. A tervezés során egy teszt ötleteket tartalmazó
dokumentum készül, melyben röviden meghatározzák a tesztelés hatókörét, céljait és az
alkalmazandó tesztelési megközelítéseket.
o Felderítő teszt (exploratory testing): informális teszttervezési módszer, amely során
a tesztelő aktívan felügyeli a tesztek tervezését, a futtatás során szerzett
információkat összegyűjti és hasznosítja új és jobb tesztek tervezése érdekében
[Bach szerint]
 A tesztelést a teszt végrehajtása közben naplózzuk is.
 A felderítő teszt fő célja a tanulás.
 Időkeretes tevékenység
 A tesztelés során a tesztelő szabad kezet kap, azt teszteli, ami gyanús. hibás, fontos, stb.
 Ez a megközelítés akkor különösen hasznos, ha kevés, vagy hiányos specifikáció áll
rendelkezésre, kevés az idő, vagy ha más, formálisabb tesztet szándékoznak bővíteni,
kiegészíteni. Segítséget nyújthat a tesztelési folyamat ellenőrzésében, hogy
megbizonyosodjanak a legjelentősebb hibák megtalálásáról.
o Hibatámadás (attack, fault attack): célzott próbálkozás a tesztelés tárgyának
minőségének, különösképpen a megbízhatóságának meghatározására azáltal, hogy
speciális meghibásodásokat próbálunk meg szándékosan előidézni

40
4.6 Tesztelési technikák kiválasztása (K2)
A tesztelési technika kiválasztásánál számos tényezőt vesznek figyelembe, ilyenek a rendszer típusa,
a szabályzó rendelkezések, ügyfél követelményei, illetve a szerződésben foglalt követelmények, a
kockázat szintje és típusa, a tesztelési cél, a rendelkezésre álló dokumentáció, a tesztelők
ismeretei, az idő és a költségvetés, a fejlesztési életciklus, a használati eset modellek és a
tapasztalat a talált hibák típusairól.

Egyes tesztek jobban használhatók adott szituációkban illetve tesztelési szinteken; mások minden
tesztelési szinten alkalmasak.

5 Tesztmenedzsment (K3)
5.1 Tesztelő szervezet (K2)
5.1.1 Tesztelő szervezet és a függetlenség (K2)
 A tesztek és felülvizsgálatok útján való hibakeresés hatékonysága független tesztelők
alkalmazásával növelhető. A függetlenség változatai:
o Nincsenek független tesztelők. A fejlesztők tesztelik saját kódjukat.
o Független tesztelők vannak a fejlesztői csapaton belül.
o Független tesztelő csapat vagy csoport van a szervezeten belül, amely a
projektmenedzsment vagy a vállalati vezetés (menedzsment) felé tesz jelentést.
o Független tesztelők az üzleti szervezettől vagy a felhasználói körből.
o Független, különböző tesztelési célokra szakosodott tesztelői szakértők, mint pl.
használhatósági tesztelők, biztonsági tesztelők vagy tanúsítvány tesztelők (akik a
szoftvertermék szabványoknak és előírásoknak való megfelelését tanúsítják).
o Kiszervezett, vagy szervezeten kívüli független tesztelők.
 A nagyméretű, komplex, vagy biztonság-kritikus projekteknél általában a legjobb megoldás a
többszintű tesztelés alkalmazása, ahol néhány vagy az összes tesztelési szintet független
tesztelők hajtják végre. A fejlesztők részt vehetnek a tesztelésben, különösen az alacsonyabb
szinteken, objektivitás híján azonban korlátozott a hatékonyságuk. A független tesztelőknek
hatáskörébe tartozhat a tesztelési folyamatok és szabályok igénylésére és meghatározása, de
ezen folyamatokkal kapcsolatos feladatokat csak akkor végezhetik el, ha arra megbízásuk van
a vezetőségtől.
 A függetlenség előnyei közé tartoznak a következők:
o A független tesztelők más, különböző hibákat látnak meg, és elfogulatlanok.
o Objektivitás
o Nagyobb rálátás a projektre: egy független tesztelő ellenőrizni tudja azokat a
feltételezéseket, amelyeket különböző szereplők tettek a rendszer specifikációja és
megvalósítása során.
o Destruktív hozzáállás
 Hátrányok:
o Izoláció a fejlesztői csapattól (amennyiben teljesen független).
o A független tesztelők szűk keresztmetszetként jelenthetnek meg az utolsó
ellenőrzési pontnál. A fejlesztők elveszthetik a minőség iránti felelősségérzetüket.

41
 o Csúszáskor a tesztelő csapat lehet a bűnbak.
 A tesztelés feladatait végezhetik tesztelő feladatkört betöltők vagy más beosztásúak is,
mint pl. egy projekt-menedzser, minőségbiztosító, fejlesztő, vállalati szakértő vagy az üzleti
terület szakértője, infrastrukturális vagy IT műveletek szakembere.
o Tesztelő (tester): egy képzett szakértő, aki a rendszer vagy rendszerkomponens
tesztelésében vesz részt.
o Tesztmenedzser (test manager): a tesztelési tevékenységekért, erőforrások
menedzseléséért valamint a tesztelés vizsgálatáért felelős személy. A tesztmenedzser
irányítja, adminisztrálja, tervezi és menedzseli a tesztelés tárgyának vizsgálatát.

5.1.2 A tesztvezető és a tesztelő feladatai (K1)

 A tesztvezetőt esetenként tesztmenedzsernek vagy teszt koordinátornak nevezik. A
tesztvezető szerepét betöltheti egy projektmenedzser, fejlesztési menedzser,
minőségbiztosítási menedzser vagy a tesztelő csoport menedzsere. Nagyobb projekteknél két
beosztás is lehet: tesztvezető és tesztmenedzser. Általában a tesztvezető tervezi, felügyeli és
irányítja a tesztelési tevékenységeket
 Tipikus tesztvezetői feladatok lehetnek:
o A tesztelési stratégia és terv koordinálása a projektmenedzserekkel és másokkal.
o A projektekhez tartozó tesztelési stratégia, illetve a szervezeti szintű tesztelési
alapelvek elkészítése vagy felülvizsgálata.
o A tesztelési perspektívákat alkalmazza más projekttevékenységekre, mint pl. az
integrációs tervezésre.
o A tesztek tervezése – a tesztelési szempontok figyelembevételével és a tesztelési
célkitűzések, kockázatok ismeretében – ide tartozik a tesztelési megközelítések
kiválasztása, a tesztelés időtartamának, ráfordításainak és költségeinek becslése,
erőforrások beszerzése, tesztelési szintek és ciklusok meghatározása, incidens
menedzsment tervezése.
o A tesztek specifikációjának, előkészítésének, kivitelezésének és végrehajtásának
kezdeményezése, a teszteredmények monitorozása és a kimeneti feltételek
ellenőrzése.
o A tervezés átalakítása a teszteredmények és a tesztelés előrehaladása alapján (amit
gyakran állapotjelentésekben dokumentálnak), a problémák kiküszöböléséhez
szükséges lépések megtétele.
o A tesztelési környezet megfelelő konfiguráció menedzsmentjének létrehozása a
nyomon követhetőség érdekében.
o Megfelelő metrikák bevezetése a teszt-előrehaladás mérésére, valamint a tesztelés
és a termék minőségének értékelésére.
o Annak eldöntése, hogy mit, milyen mértékig és hogyan kell automatizálni.
o A tesztelést támogató eszközök kiválasztása és az eszközök használatával
kapcsolatos képzés megszervezése a tesztelők részére.
o Döntéshozatal a tesztkörnyezet kialakításáról.
o Teszt összefoglaló jelentés készítése a tesztelés során gyűjtött információk alapján.
 Tipikus tesztelői feladatok lehetnek:
o Teszttervek felülvizsgálata és részvétel a kidolgozásukban.
o Felhasználói követelmények, specifikációk és tesztelhetőségi modellek elemzése,
felülvizsgálata és elemzése.
o Tesztspecifikációk készítése.

42
 o Tesztkörnyezet kialakítása (együttműködésben a rendszeradminisztrátorokkal és a
hálózat menedzserekkel).
o Tesztadatok előkészítése, felvétele.
o Tesztek kidolgozása minden tesztelési szinten, tesztek végrehajtása és naplózása,
eredmények értékelése, az elvárt eredményektől való eltérések dokumentálása.
o Szükség esetén tesztelési adminisztrációs vagy menedzsment eszközök, valamint
tesztmonitorozási eszközök használata.
o Tesztek automatizálása (ebben támogatást nyújthat egy fejlesztő vagy egy
tesztautomatizálási szakértő).
o Komponensek és rendszerek teljesítményének mérése (ha lehetséges).
o Mások által kifejlesztett tesztek felülvizsgálata.
 A tesztelemzéssel, műszaki teszttervezéssel, speciális teszttípusokkal illetve
tesztautomatizálással foglalkozó személyek általában szakértők a saját területükön. A
tesztelési szinttől és a termékkel kapcsolatos kockázatoktól függően különböző személyek
vehetik át a tesztelői feladatokat, bizonyos fokú függetlenség megtartásával.
 Általában a komponens és integrációs szintű tesztelők a fejlesztők, az átvételi tesztelők
vállalati szakértők és felhasználók, a működési átvételi tesztelők pedig operátorok lehetnek.

5.2 Teszttervezés és becslés (K2)

5.2.1 Teszttervezés (K2)
 A tervezést dokumentálhatják projekt- vagy magas szintű teszttervben, illetve tesztelési
szintenként külön teszttervben, mint pl. rendszertesztelés és átvételi teszt. A tesztterv vázát a
„Szoftverteszt Dokumentáció Szabvány” (IEEE 829) tartalmazza.
o Tesztterv (test plan): A tesztelés hatáskörét, megközelítését, erőforrásait valamint a
tevékenységek tervezett ütemezését tartalmazó dokumentum. Ezen kívül
meghatározza a tesztelési elemeket, a tesztelendő funkciókat, feladatokat, a
tesztelést végrehajtó személyek függetlenségét, a tesztelési környezetet, a műszaki
teszttervezési technikákat, a belépési és kilépési feltételeket, valamint kockázatokat.
A teszttervezési folyamat meghatározó dokumentuma (IEEE 829 alapján)
 A tervezést befolyásolja a szervezet tesztelési stratégiája, a tesztelés tárgyköre, céljai,
kockázatok, megkötések, kritikusság, tesztelhetőség és az elérhető erőforrások. Minél
előrehaladottabb fázisban van a projekt és a teszttervezés, annál több információ áll
rendelkezésre és annál részletesebb lehet a terv.
 A teszttervezést folyamatosan végzik, az életciklus minden fázisában és minden tevékenység
során. A tesztelési tevékenységekből kapott visszajelzések alapján felismerhető a kockázatok
változása, és ennek megfelelően alakítható a tervezés.

5.2.2 Teszttervezési tevékenységek (K2)

 A teszttervezési tevékenységek a következők lehetnek:
o A tesztelési tárgykör, kockázatok és célok meghatározása.
o A tesztelés általános megközelítésének definiálása (teszt stratégia), ezzel együtt a
tesztelési szintek, valamint a bemeneti és kimeneti feltételek meghatározása.
o A tesztelési tevékenységek beépítése a szoftver életciklusába:
o Beszerzés, beszállítás, fejlesztés, működtetés és karbantartás.

43
 o Döntéshozatal arról, hogy mit tesztelünk, mely szerepkörbe tartozók hajtják végre a
tesztelési tevékenységeket, és ezen tevékenységeket hogyan kell végrehajtani, hogy
fogják kiértékelni a teszteredményeket.
o A teszt elemzési és a tervezési tevékenységek ütemterve.
o A tesztmegvalósítás, végrehajtás és értékelés ütemterve.
o Erőforrások hozzárendelése a definiált tevékenységekhez.
o A teszt dokumentáció mennyiségének, részletességének, struktúrájának
meghatározása, minták megadása.
o Metrikák kiválasztása a teszt előkészítés és végrehajtás felügyeletéhez és
irányításához, a hibák és a kockázatok kezeléséhez.
o A teszteljárások részletességének meghatározása annak érdekében, hogy elegendő
információ álljon rendelkezésre a tesztek ismételt előkészítéséhez és
végrehajtásához.

5.2.3 Belépési feltétel

 A belépési feltételek rendeltetése, hogy meghatározzák, mikor kell elkezdeni a tesztelést.
o Belépési feltétel (entry criteria): általános és speciális feltételek halmaza, amely
engedélyezi egy adott feladat végrehajtását. Az a cél, hogy ne indítsunk olyan
feladatokat, amelyek több elvesztegetett ráfordítást jelentenének, mint az elbukó
belépési feltételek kijavítása. [Gilb és Graham]
 Tipikus belépési feltételek (Csak akkor kezdem el a tesztet, ha…):
o Tesztkörnyezet rendelkezésre áll
o Teszteszközök rendelkezésre állása a tesztkörnyezetben
o Tesztelhető kód rendelkezésre áll
o Tesztadatok rendelkezésre állnak

5.2.4 Kilépési feltétel (K2)

 A kilépési feltételek rendeltetése, hogy meghatározzák, mikor kell leállítani a tesztelést,
például egy tesztelési szint végén, vagy ha egy teszthalmaznak meghatározott célja van.
o Kilépési feltétel (exit criteria): általános és speciális feltételek halmaza, amelyet
minden érintettel egyeztetve egy folyamat hivatalos befejezési feltételének
tekintünk. A célja, hogy megakadályozzuk az olyan feladatok befejezettnek
tekintését, amelyeknek még vannak függőben levő, be nem fejezett részei. A kilépési
feltételeket a tesztelés leállításának tervezéséhez és jelentéséhez használjuk.
 A tipikus kilépési feltételek általában a következőkből tevődnek össze:
o Alapossági mérés, mint kód-, funkcionalitás- vagy kockázat-lefedettség.
o Hibasűrűség vagy megbízhatóság becslése.
o Költség.
o A fennmaradó kockázatok, mint például a javítatlan hibák, teszt lefedettség hiánya
bizonyos területeken.
o Ütemtervek, melyek lehetnek például a piacra kerüléssel kapcsolatosak.

5.2.5 A tesztelés becslése (K2)

 A tananyag két megközelítést mutat be a tesztelés becslésére:
o A metrika alapú megközelítés: a tesztelési ráfordítás becslése régebbi, vagy hasonló
projektek metrikái alapján, vagy tipikus értékek alapján.

44
 o A szakértő alapú megközelítés: a feladatok becslését az azokat ismerő személy vagy
szakértők hajtják végre.
 A teszteléshez szükséges ráfordítások becslése után következik a szükséges erőforrások és
az ütemterv meghatározása.

 A tesztelés ráfordításai több tényezőtől függnek:

o A termék jellemzői: a specifikáció és más, a tesztelési modelleknél felhasznált
információk (pl.: tesztbázis) minősége, a termék mérete, a problémakör
komplexitása, megbízhatósági és biztonsági követelmények, dokumentációra
vonatkozó követelmények.
o A fejlesztési folyamat jellemzői: a szervezet stabilitása, az alkalmazott eszközök, a
tesztelési folyamat, a résztvevő személyek szaktudása, és az időtényező.
o A tesztelés eredménye: a hibák száma és a szükséges átdolgozás mértéke.

5.2.6 Tesztelési megközelítések (tesztelési stratégiák) (K2)

 A tesztelési megközelítések vagy stratégiák osztályozásának egyik alapja lehet az, hogy
mikor kezdődik meg a műszaki teszttervezési munka jelentősebb része:
o Megelőző megközelítéseknél a lehető leghamarabb megtervezik a teszteket.
Hátránya a nagy bizonytalanság.
o Reaktív megközelítések esetén a műszaki teszttervet (test design-t) a szoftver vagy
rendszer létrehozása után dolgozzák ki.
o Tesztelési stratégia (test strategy): felsőszintű dokumentum, amely a végrehajtandó
tesztelési szinteket írja le, valamint azok részleteit tartalmazza a szervezetre vagy a
programra (egy vagy több projektre) vonatkozóan.
o Tesztelési megközelítés (test approach): a tesztelési stratégia megvalósítása egy
konkrét projektre. Jellemzően a projekt céljain és a kockázatelemzésen alapuló
döntéseket, a tesztelési folyamatok kiindulópontjait, az alkalmazandó műszaki
teszttervezési technikákat, belépési és kilépési kritériumokat valamint a tesztelés
fajtáit tartalmazza.
 A tipikus megközelítések, vagy stratégiák következőket foglalják magukba:
o Analitikus megközelítések esetén, mint amilyen például a kockázat alapú teszt, a
tesztelés a nagyobb kockázatú területekre irányul.
o Modell alapú megközelítéseknél, mint például a sztochasztikus teszt, a
hibaarányokra (megbízhatóság-növekedés modellek) vagy a használatra (működési
profilok) vonatkozó statisztikai információkat alkalmaznak. (Csimpánz-teszt:
véletlenszerű inputokkal találunk hibát)
o Módszeres megközelítések, mint például a programhiba alapú (ide tartozik a
hibasejtés és a támadás), tapasztalat alapú, ellenőrző lista alapú, minőségi jellemző
alapú.
o Folyamat- vagy szabvány szerinti megközelítések, mint például az iparhoz
kapcsolódó szabványok, vagy a különböző agilis módszertanok által meghatározott
megközelítések.
o Dinamikus és heurisztikus megközelítések, mint például a felderítő teszt, ahol a
tesztelés nincs eltervezve, inkább eseményekre reagál, s a végrehajtás és az
értékelés egyszerre történik.
o Tanácsadói megközelítések esetén a teszt lefedettséget elsősorban a technológia
és/vagy a tesztelő csapaton kívüli vállalati szakértők iránymutatása viszi előre.

45
 o Regresszió elkerülő megközelítéseknél újra alkalmazzák a meglévő tesztanyagot,
széles körben automatizálják a funkcionális regressziós teszteket és a standard
tesztkészleteket.
 A különböző megközelítéseket kombinálhatják, például: kockázat alapú dinamikus
megközelítés.
 A tesztelési megközelítés megválasztásánál figyelembe kell venni a következő
összefüggéseket:
o A projekt sikertelenségének kockázata, a termékre vonatkozó veszélyek, illetve a
termék sikertelenségének következményei az emberekre, a környezetre és a
vállalatra nézve.
o A személyek szaktudása és tapasztalata a javasolt technikákkal, eszközökkel és
metódusokkal kapcsolatban.
o A tesztelés célkitűzései és a tesztelő csapat feladata.
o Előírások a fejlesztési folyamatra vonatkozó külső és belső szabályzók.
o A termék és az üzlet természete, jellemzői

5.3 A teszt előrehaladásának felügyelete és irányítása (K2)

5.3.1 A teszt előrehaladásának felügyelete (K1)
 A teszt felügyeletének célja, hogy visszajelzéseket és adatokat nyújtson a tesztelési
tevékenységekről. A felügyelet alá vont információ manuálisan vagy automatizáltan
gyűjthető, és alkalmazható a kilépési feltételek, például a lefedettség mérésére. A tervezett
ütemtervhez és költségvetéshez képest történt előrehaladás értékelésére metrikákat is
alkalmazhatnak. A leggyakoribb tesztelési metrikák a következők:
o A tesztesetek előkészítésében végzett munka százalékosan (vagy hány százaléka
készült el a tervezett teszteseteknek).
o A tesztkörnyezet előkészítésében végzett munka százalékosan.
o Teszteset végrehajtás (pl. futtatott/nem futtatott tesztesetek száma,
sikeres/sikertelen tesztesetek).
o Információ a hibákról (pl. hibasűrűség, megtalált és javított hibák, hibaarány,
újratesztelési eredmények).
o A követelmények, a kockázatok vagy a kód tesztlefedettsége.
o A tesztelők szubjektív véleménye a termékről.
o A tesztelés mérföldköveinek dátumai.
o A tesztelés költségei, ahol számítandó a következő hiba megtalálásának vagy a
következő teszt futtatásából származó nyereség aránya a befektetett költséghez
képest.
 Tesztelés felügyelete (test monitoring): a tesztelési projekt státuszát rendszeresen vizsgáló,
a tesztelési tevékenységet kezelő tesztmenedzsment feladat. A tesztmonitorozás részét
képezi az elvárt eredményeket az aktuális eredményekkel összehasonlító jelentés készítése
 Hibaarány (failure rate): adott kategóriájú meghibásodások aránya egy adott
mértékegységben kifejezve, pl. időegységhez, a tranzakciók számához, vagy a futó gépek
számához viszonyítva
 Hibatűrés (fault/defect density): a szoftverben azonosított hibák aránya a szoftver
méretéhez viszonyítva (ez utóbbi standard mértékegységben kifejezve, mint pl. a kódsorok,
vagy az osztályok, illetve függvénypontok száma)

46
5.3.2 Tesztjelentés (Test summary report) (K2)
 A tesztjelentés összefoglalja a teszteléssel kapcsolatos információkat úgy, mint:
o Mi történt a tesztelés adott szakaszában, mint például a kilépési feltétel
teljesülésének időpontja.
o Feldolgozott információk és metrikák az elkövetkező lépésekkel kapcsolatos
ajánlások és döntések elősegítésére, mint például elemzés a fennmaradó hibákról, a
további tesztelés gazdasági előnyei, jelentősebb kockázatok, a tesztelt szoftver
megbízhatósági szintje.
 A teszt összefoglaló jelentés fő pontjait a „Szoftverteszt Dokumentáció Szabvány” (IEEE 829)
tartalmazza.
 A metrikákat gyűjteni kell az adott tesztelési szint folyamán és végén, a következők elemzése
érdekében:
o Megfelelőek-e az adott tesztelési szint célkitűzései.
o Megfelelőek-e az alkalmazott tesztelési megközelítések.
o A tesztelés hatékonysága a célkitűzésekre való tekintettel.

5.3.3 Tesztirányítás (K2)

 Folyamatos tevékenység.
 A tesztirányítás a begyűjtött és bejelentett információk, metrikák alapján foganatosított
korrekciós lépéseket jelenti. Ezek a műveletek bármely tesztelési tevékenységre
vonatkozhatnak és a szoftver életciklusának bármely tevékenységére vagy feladatára
hathatnak.
o Tesztirányítás (test control): tesztelési tervtől való eltérések esetén javító
tevékenységeket alkalmazandó teszt menedzselési feladat annak érdekében, hogy a
teszt projekt nyomon követhető legyen
 Példák tesztirányításra:
o Döntéshozatal a tesztelés felügyeletéből nyert információk alapján.
o Tesztek prioritásának megváltoztatása, ha egy ismert kockázat bekövetkezik (pl. a
szoftver késői leszállítása).
o A tesztelési ütemterv megváltoztatása a tesztkörnyezet felhasználhatóságának
változása miatt.
o Belépési feltétel meghatározása, amelyhez javítások végzése és azok fejlesztő általi
újratesztelése (ellenőrző teszttel) szükséges, mielőtt a szoftver build-be kerülne.

5.4 Konfiguráció menedzsment (K2)

 A konfiguráció menedzsment célja a szoftver- vagy rendszerrészek (komponensek, adatok és
dokumentáció) integritásának kialakítása és fenntartása a projekt és a termék teljes
életciklusa alatt.
o Konfiguráció menedzsment (configuration management): a következő
tevékenységek technikai és adminisztratív irányítása: a konfigurációs elemek
funkcionális és fizikai karakterisztikáinak meghatározása és dokumentálása, az ezen
karakterisztikákhoz képest történő változása irányítása, a változás kezelési és
megvalósítási állapot nyomon követése és jelentése, illetve a különböző
követelményeknek történő megfelelés

47
 o Konfigurációs irányítás (configuration control): a konfiguráció menedzsment része,
amely a konfigurációs elemeknek a konfigurációs állapot formális rögzítése utáni
változásainak kiértékelését, koordinálást, jóváhagyását, vagy éppen elutasítását,
továbbá a megvalósítását foglalja magába.
 A tesztelésnél a konfiguráció menedzsment a következők biztosítását jelentheti:
o A tesztkörnyezet minden eleme pontosan meghatározott, verziókövetés alá vont, a
benne történt változások nyomonkövethetők, az elemek kapcsolódnak egymáshoz és
a fejlesztési elemekhez (tesztelés tárgyaihoz), hogy a nyomonkövethetőség
fenntartható legyen a tesztelés folyamán.
o A teszt dokumentációban egyértelmű hivatkozás található minden létező
dokumentumra és szoftver elemre.
 A konfiguráció menedzsment segíti a tesztelőt a tesztelt elemek, a teszt dokumentumok, a
tesztek és a teszt alapkörnyezet egyértelmű meghatározásában és reprodukálásában.
 A teszttervezés során kell megválasztani, dokumentálni és megvalósítani a konfiguráció
menedzsment eljárásokat és infrastruktúrát (eszközöket).

5.5 Kockázat és tesztelés (K2)

A kockázat úgy definiálható, mint egy esemény, veszély, fenyegetés vagy szituáció fellépésének
esélye és nem kívánatos következményei, azaz egy potenciális probléma. A kockázat szintjét a káros
esemény bekövetkezésének valószínűsége és hatása (az esemény okozta kár) határozza meg.

Kockázat (risk): az a tényező, amely a jövőben negatív következményeket okozhat. Általában, mint
hatás és valószínűség jelenik meg.

5.5.1 Projekt kockázatok (K2)

 A projekt kockázatok olyan kockázatok, melyek a projekt céljainak elérését befolyásolják
úgy, mint:
o Szervezeti tényezők:
 szaktudás és munkaerő hiánya;
 személyi és képzési problémák;
 szervezeti működés problémái, mint pl. a tesztelők nem jól kommunikálják
az igényeiket és a teszteredményeket, vagy nem alkalmazzák a tesztelés és a
felülvizsgálat alkalmával szerzett információkat (pl. nem javítják a fejlesztési
és tesztelési eljárásfolyamatokat).
 nem megfelelő hozzáállás vagy rossz elvárások a teszteléssel kapcsolatban
(pl. nem értékelik a teszteléssel talált hibák jelentőségét).
o Technikai problémák:
 a megfelelő követelmények meghatározásával kapcsolatos problémák;
 a követelmények teljesíthetőségének mértéke a már létező megkötések
figyelembevételével;
 a terv, a kód és a tesztek minősége.
o Beszállítói problémák:
 a harmadik fél nem teljesít;
 szerződésbeli problémák.
 Ezen kockázatok elemzésekor, kezelésekor és mérséklésekor a tesztmenedzsernek követnie
kell a jól bevált projektmenedzsment-alapelveket. A „Szoftverteszt Dokumentáció Szabvány”

48
 (IEEE 829)-ban található teszttervezési vázlathoz meg kell állapítani a kockázatokat és a
mérséklésükre hozott intézkedéseket.

5.5.2 Termékkockázatok (K2)

 A szoftver vagy rendszer lehetséges hibás területeit (kedvezőtlen jövőbeli események, vagy
veszélyek) termék kockázatoknak nevezik, mivel kockázatot jelentenek a termék minőségére
vonatkozóan. Ilyenek például:
o Hibára hajlamos szoftver leszállítása.
o Annak lehetősége, hogy a szoftver/hardver károkat okozhat egy személynek vagy
egy cégnek.
o Gyenge szoftverjellemzők (pl. funkcionalitás, megbízhatóság, használhatóság és
teljesítmény).
o A szoftver nem teljesíti az elvárt funkciókat.
 A kockázatokat annak eldöntésére használják, hogy hol kezdjék a tesztelést, és hol
teszteljenek többet. A tesztelést egy ártalmas hatás fellépési kockázatának csökkentésére
vagy egy ártalmas hatás által okozott kár csökkentésére használják.
 A termék kockázatok a projekt sikerét veszélyeztető különleges kockázatok. A tesztelés, mint
kockázatkezelési tevékenység, visszajelzéseket nyújt a fennmaradó kockázatokról úgy, hogy
méri a kritikus hibák kiküszöbölésének és az előre nem látható veszélyekre vonatkozó tervek
hatékonyságát.
o Termékkockázat (product risk): A teszt tárgyához (magához a termékhez)
közvetlenül kapcsolódó kockázat.
o Kockázat alapú test (risk-based test): a tesztelés egy olyan megközelítése, mely
csökkenti a termék kockázati szintjét és tájékoztatja az érintetteket a kockázat
mértékéről már a projekt kezdeti fázisában. Magában foglalhatja mind a termék
kockázatainak azonosítását, mind a tesztelési folyamat kockázat szerinti vezetését.
 A tesztelés kockázat alapú megközelítése proaktív lehetőségeket teremt a termék kockázat
csökkentésére, már a projekt kezdeti szakaszaitól kezdve. Ide tartozik a termék kockázatok
azonosítása, és azok figyelembe vétele a teszttervezésben és - irányításban, a specifikáció
valamint a tesztelőkészítés és - végrehajtás során. A kockázat alapú megközelítésnél a
felismert kockázatok a következőkre használhatók:
o Az alkalmazandó tesztelési technikák meghatározása.
o A végrehajtandó tesztelés mértékének meghatározása.
o A tesztelés priorizálása úgy, hogy a kritikus hibák a lehető leghamarabb felszínre
kerüljenek.
o Nem teszteléshez kapcsolódó kockázatcsökkentő tevékenységek esetleges
bevezetése (pl. képzés a tapasztalattal nem rendelkező tervezők részére).
 A kockázat alapú teszt igénybe veszi a projektben résztvevők minden ismeretét és tudását a
kockázatok és az azok kezeléséhez szükséges tesztelési szintek meghatározásához.
 Hogy a termék sikertelenségének esélye minimális legyen, a kockázat menedzsmentnek
szigorú megközelítéseket kell alkalmazni a következők terén (kockázatkezelés lépései):
o Felismerés
o Annak elemzése (és rendszeres újraelemzése), hogy milyen probléma léphet fel
(kockázatok).
o Annak meghatározása, hogy mely kockázatok kezelése a legfontosabb. (Besorolás)
o Lépések kidolgozása ezen kockázatok kezelésére.

49
  Ezeken felül a tesztelés támogathatja az új kockázatok azonosítását, és annak
meghatározását, hogy mely kockázatokat kell csökkenteni, valamint csökkentheti a
kockázatokkal kapcsolatos bizonytalanságot.
 Kockázat elemzés: folyamatos tevékenység.

5.6 Incidens menedzsment (K3)

 Mivel a tesztelés egyik célja a hibák megtalálása, ezért a valós és az elvárt eredmények
közötti eltéréseket naplózni kell, mint incidenseket. Az incidenseket nyomon kell követni a
felfedezéstől az osztályozáson át a javításig illetve a megoldás ellenőrzéséig. A szervezetnek
osztályozási eljárást és szabályokat kell kidolgoznia annak érdekében, hogy minden
incidensnél teljes körű menedzsment történjen.
 Incidensek előjöhetnek a szoftvertermék fejlesztése, felülvizsgálata, tesztelése illetve
használata során. Jelenthetik a kóddal vagy a működő rendszerrel kapcsolatos problémákat,
vagy a dokumentációban levő problémákat, mint például követelményekben, fejlesztési
dokumentumokban, teszt dokumentumokban, felhasználói információkban, - pl. a súgóban,
vagy a telepítési útmutatóban.
o Kiváltó ok (root cause): A hiba forrása, melyet eltávolítva a hibajelenség is csökken
vagy megszűnik. [CMMI]
o Incidensnaplózás (incident logging): bármely bekövetkezett incidens feljegyzése pl. a
tesztelés alatt.
o Incidensjelentés (incident report): olyan dokumentum, amely minden, pl. a tesztelés
alatt bekövetkezett incidenst tartalmaz, amely vizsgálatot tesz szükségessé [Az IEEE
829 szerint]
o Hibajelentés (bugreport): egy olyan dokumentum, amely leírja a szoftver hibáit,
amelyek a program elégtelen működéséhez vezethetnek
 Az incidens jelentések céljai a következők:
o Visszajelzés nyújtani a problémáról a fejlesztők és egyéb érintettek részére, hogy
szükség el lehessen végezni a szükség szerinti azonosítást, izolálást, javítást.
o Biztosítani, hogy a tesztvezetők nyomon követhessék a tesztelt rendszer minőségét
és a tesztelés előrehaladását a teszt folyamán.
o A tesztelési folyamat javítására vonatkozó elképzeléseket kidolgozni.
 Az incidens jelentés a következőket tartalmazhatja:
o Keltezés, készítő szervezet, szerző.
o Elvárt és valós eredmények.
o A tesztelem (konfigurációs elem) és a környezet azonosítása.
o A szoftver- vagy rendszer életciklus folyamata, amiben az incidens fellépett.
o Az incidens leírása, hogy lehetséges legyen a megismétlése és a megoldása,
felhasználva a naplókat, adatbázis mentéseket, screenshotokat
o Hatás az érdekelt felek érdekeire.
o A rendszerre való hatás mértéke.
o Javítás sürgőssége/prioritása.
o Az incidens állapota (pl. nyitott, elhalasztott, duplikált, javításra váró, javított és
újratesztelésre váró, lezárt).
o Következtetések, javaslatok és jóváhagyások.

50
 o Globális problémák, mint például további területek, melyekre az incidens okozta
változások hatással lehetnek.
o A változtatások története: a projektcsapat tagjainak tevékenységei az incidens
izolálására, javítására, javításának ellenőrzésére.
o Referenciák, melyekbe beletartozik a problémát felfedő teszteset-specifikáció
azonosítása is.
 Az incidens jelentés struktúráját a „Szoftverteszt Dokumentáció Szabvány” (IEEE 829) is
tartalmazza.
 Hibaészlelési arány (DDP – defect detection percentage): egy teszt fázisban talált hibák száma
osztva az adott teszt fázisban és később talált kódhibák számával
 Prioritás (priority): Egy elemhez rendelt (üzleti) fontosság, például hiba prioritás.
 Súlyosság (severity): Egy hiba hatásának a mértéke a rendszer vagy komponens fejlesztésére
vagy működésére. [IEEE 610]

6 Eszköztámogatás a tesztelésben (K2)

6.1 Teszteszközök típusai (K2)
6.1.1 A tesztelés eszköztámogatásának célja (K2)
 A teszteszközök akár többféle teszttevékenységet is támogathatnak:
1. Közvetlenül a tesztsorán használt eszközök, mint pl. a tesztvégrehajtó, tesztadat
előállító, illetve eredmény összehasonlító eszközök.
2. A tesztfolyamat, a teszteredmények, adatok, követelmények, incidensek, hibák,
stb. kezelését segítő, továbbá a tesztvégrehajtást felügyelő és a jelentéseket
támogató eszközök.
3. A felderítő teszt során használt eszközök (pl. egy adott file műveleteit figyelő eszköz).
4. Bármilyen, a tesztelést segítő eszköz (egy táblázatkezelő ebben az értelemben
szintén teszteszköz).
 A teszteszközök akár több célt is szolgálhatnak:
o A teszttevékenységek hatékonyságának növelése az ismétlődő feladatok
automatizálásával, vagy a kézi teszttevékenységek támogatása, mint a
teszttervezést, a műszaki teszttervezést, a tesztjelentéseket, illetve a
tesztfelügyeletet
o Jelentős kézi erőforrást igénylő teszttevékenységek automatizálása (pl. statikus teszt)
o Kézzel végre nem hajtható tevékenységek automatizálása (pl. kliens-szerver
alkalmazások széles skálájú teljesítménymérése)
o A teszt megbízhatóságának növelése (pl. sokáig tartó monoton feladatok, nagy
mennyiségű adat összehasonlítására, vagy szimulációs tevékenységekre)
 A “keretrendszer” kifejezés szintén gyakran használt az iparban, legalább 3 értelemben:
o Újrahasználható és kiterjeszthető tesztkönyvtárak, amelyeket teszteszközök
létrehozására lehet használni (nevezik ezeket teszttámogató szoftverkörnyezetnek is)
o A tesztautomatizálás műszaki tervezésének egy típusa (pl. adatvezérelt, vagy
akciószó alapú
o Általános tesztvégrehajtási folyamat

51
6.1.2 Teszteszközök osztályozása (K2)
 Számos eszköz létezik a tesztelés különböző szempontból való támogatására:
o Az eszközöket az alapján csoportosítjuk, hogy melyik tesztelési tevékenységet, vagy
területet támogatják. Egyes eszközök csak egy tevékenységet támogatnak, mások
többet is, ezeket ahhoz a tevékenységhez sorolják, amelyhez leginkább köthetők.
o Cél
o Beszerzés: kereskedelmi, ingyenes, nyílt forráskódú (shareware)
o Kik használják: tesztelők, fejlesztők
o A teszteszközök egyes típusai lehetnek beavatkozók olyan értelemben, hogy maga az
eszköz befolyásolhatja a teszt aktuális eredményét. A beavatkozó eszközök
használatának következményét mérési mellékhatásnak nevezik.
 Mérési mellékhatás (probe effect): egy rendszer vagy komponens mérése
során a mérőeszköz által okozott hatás; például teljesítményteszt során a
tesztelő illetve mérőeszköz rontja a rendszer vagy komponens teljesítményét
(még ha nem is onnan futtatjuk, de monitorozzuk).

6.1.3 Eszköztámogatás a tesztelés és a tesztek menedzsmentjéhez (K1)

 A menedzsment eszközök minden teszt tevékenységnél, a szoftver teljes életciklusán át
alkalmazhatók. A gyakorlatban a tesztmenedzsment eszközöket tipikusan szakértő tesztelők vagy
tesztmenedzserek használják a rendszerteszt vagy az átvételi teszt szintjén.

Tesztmenedzsment eszközök
 Tesztmenedzsment eszköz (test management tool): olyan szoftver eszköz, amely támogatja a
teszt menedzsmentet és irányítja a tesztfolyamat egy részét. Gyakran rendelkezik olyan
funkciókkal, mint a tesztelési környezet menedzsmentje, tesztek ütemezése, eredmények
naplózása, folyamatkövetés, hibakezelés és teszteredmények jelentése.
 Funkciói és jellemzői (néhány eszköz minden felsorolt funkciót támogat, mások csak egyet,
kettőt):
o a tesztek menedzsmentje (pl. egy adott tesztkészlethez kapcsolódó adatok nyomon
követése: milyen teszteket kell futtatni, mennyi a futtatott, átment, megbukott
tesztesetek száma, stb.)
o az elvégzendő tesztek ütemezése (manuálisan, vagy egyéb eszközzel)
o a tesztelési tevékenységek menedzsmentje (a tervezésre és végrehajtásra fordított idő
megfelel-e az ütemtervben, költségvetésben foglaltaknak)
o interfészek vagy kölcsönhatások más eszközökkel
o tesztek, teszteredmények és programhibák visszakövetése a követelményekig
o teszteredmények listázása
o státuszjelentés készítése

Követelmény menedzsment eszközök

 Követelmény-menedzsment eszköz (requirements management tool): olyan eszköz, amely
támogatja a követelmények, a követelmény jellemzőinek (pl. prioritás, tudás gazda) rögzítését és
magyarázó jegyzetek készítését, valamint megkönnyíti a különböző szintű követelmények
nyomon követhetőségét és változás menedzsmentjét. Vannak olyan követelmény-menedzsment
eszközök, melyek a statikus elemzéshez is segítséget nyújtanak, például konzisztencia
ellenőrzéssel vagy előre definiált, követelményekre vonatkozó szabályokkal.

52
 Mivel a tesztek követelményeken alapulnak, ezért minél jobb a követelmények minősége, annál
könnyebb belőlük teszteket írni.
 Funkciói és jellemzői:
o követelményutasítások tárolása
o a követelmény jellemzőivel kapcsolatos információ tárolása
o a követelmények konzisztenciájának vizsgálata
o meghatározatlan, hiányzó, vagy „később meghatározandó” követelmények megtalálása
o a követelmények prioritási sorrendbe sorolása tesztelési szempontból
o a követelmények nyomonkövethetőség a tesztekig, illetve a tesztek
nyomonkövethetősége a követelményekig, funkciókig, jellemzőkig.
o nyomonkövethetőség a követelmények szintjein keresztül
o tesztmenedzsment-eszközökkel való együttműködés
o (néha) a követelmények lefedettsége egy tesztkészlettel.

Incidensmenedzsment eszközök (Hibakövető eszközök)

 Incidens menedzsment eszköz (incident management tool): olyan eszköz, amely
megkönnyíti az incidensek felismerését és állapotainak nyomon követését. Gyakran
munkafolyamat központú annak érdekében, hogy az incidens allokációját, javítását és
újratesztelését támogassa, illetve hogy támogassa a jelentéskészítést. Lásd még: hiba
menedzsment eszköz.
 Hibamenedzsment eszköz (defect management tool): olyan eszköz, amely megkönnyíti a
hibák és változások feljegyzését és állapotaik nyomon követését. Lehetőséget nyújt a hibák
allokálására, kijavítására és újratesztelésére, valamint támogatja a jelentéskészítést. Lásd
még: incidens menedzsment eszköz.
 Funkciói és jellemzői:
o az incidensek tulajdonságaival kapcsolatos információk tárolása (pl. súlyosság)
o mellékletek tárolása (screenshotok)
o az incidensek prioritási sorrendbe rendezése
o tevékenységek kiosztása egyes személyeknek (javítás, ellenőrző teszt)
o állapot nyilvántartása (nyitott, duplikált, tesztre váró, lezárt, stb.)
o az incidensekkel kapcsolatos statisztikákról/metrikákról szóló jelentések (pl. átlagos
idő nyitott állapotban, összes nyitott, lezárt incidens)

Konfiguráció menedzsment eszközök

 Konfiguráció menedzsment eszköz (configuration management tool): olyan eszköz, amely
támogatja a konfigurációs elemek meghatározását és irányítását, ezek változásainak, illetve
verzióinak, státuszainak nyomon követését, illetve felügyeli az ezeket tartalmazó alapverziók
kiadását.
 Bár nem kifejezetten teszteszközök, de (közvetve) szükségesek a tesztver és a kapcsolódó
szoftverek tárolásához és verziókövetéséhez
 Funkciói és jellemzői:
o a szoftver és a tesztver verzióival és rendszerépítésével kapcsolatos információk
tárolása
o a szoftver és a tesztver közötti, ill. ezek különböző verziói és variánsai közötti
nyomonkövethetőség
o annak nyomon követése, hogy mely verzió mely konfigurációhoz tartozik
o rendszerépítési és kiadási menedzsment
o alapkonfiguráció elkészítése

53
 o hozzáférés vezérlése

6.1.4 A statikus teszt eszköztámogatása (K1)

 A statikus teszteszközök lehetővé teszik a költséghatékony hibamegtalálást a fejlesztés kora
fázisában.

Felülvizsgálati eszközök
 Felülvizsgáló eszköz (review tool): olyan eszköz, ami a felülvizsgálat folyamatát támogatja.
Jellemzően a felülvizsgálatok tervezését, a változáskövetést, a felülvizsgálók közötti
kommunikációt, közös felülvizsgálat végzését támogatja. Ezek mellett a mérőszámok egyfajta
gyűjtőhelyeként, valamint az azokat tartalmazó jelentések alapjául is szolgál.

 Funkciói és jellemzői:
o egységes hivatkozás a különböző helyzetekben alkalmazandó felülvizsgálati
folyamatra vagy folyamatokra
o a felülvizsgálat során keletkező megjegyzések tárolása és csoportosítása
o a megjegyzések megfelelő személyhez juttatása
o online felülvizsgálatok koordinálása
o a megjegyzések – köztük a megtalált hibák – nyomon követése, és a velük
kapcsolatos statisztikai adatok biztosítása
o a megjegyzések, felülvizsgálati dokumentumok és a kapcsolódó dokumentumok
közötti nyomonkövethetőség biztosítása
o a felülvizsgálatokban felhasználandó szabályok, eljárások és ellenőrző listák,
valamint belépési és kilépési feltételek eltárolása
o a felülvizsgálat állapotának ellenőrzése (elfogadott, korrekcióval elfogadott)
o mérhető adatok gyűjtése és a kulcstényezőkkel kapcsolatos jelentés

Statikus elemző eszközök (F)

 A fejlesztők használják a fejlesztési tevékenység és a komponenstesztelési folyamat
részeként.
 Statikus elemzés (static analysis): a szoftverelemek (például követelmények, műszaki
szoftverterv, vagy kód) elemzése azok futtatása nélkül. Általában támogató eszközök
segítségével végzik.
 A statikus elemző eszközök lényegében kibővített fordítóprogram technológiák.
 Statikus elemző eszköz (static analysis tool, static analyzer): olyan eszköz, ami statikus
elemzést hajt végre.
 Statikus forráskód elemző eszköz (static code analysis): a forráskód elemzése anélkül, hogy
a szoftvert futtatnánk.
 Funkciói és jellemzői:
o mérhető adatoknak, mint a ciklomatikus komplexitásnak, vagy a beágyazás
szintjének a kiszámítása (segít kiszámolni, hogy hol van szükség több tesztre)
o kódolási szabályok érvényre juttatása
o struktúrák és függőségek elemzése
o segítség a kód megértésében
o anomáliák és programhibák felderítése a kódban

Modellező eszközök (F)

 Modellező eszköz (modeling tool): egy alkalmazás, vagy egy rendszer modelljeinek
létrehozását, javítását és validálását támogató eszköz.

54
  Funkciói és jellemzői:
o szoftver modell validálása
o inkonzisztenciák és hibák azonosítása a modellben
o a modell tesztelendő területei meghatározásának és prioritásának segítése
o a rendszer különböző szituációkban adott válaszainak, viselkedésének előrejelzése
o segítség a rendszer funkcióinak megértésében, a tesztelési feltételek
meghatározásának megkönnyítése egy modellezési nyelv (UML) felhasználásával

6.1.5 A tesztspecifikáció eszköztámogatása (K1)

Műszaki teszttervező eszközök
 Tesztesetek, vagy legalábbis tesztbemenetek készítését könnyítik meg. Amennyiben elérhető
egy automatizált orákulum, akkor az eszköz képes az elvárt eredményeket is elkészíteni,
tehát valójában teszteseteket generál.
 Műszaki teszttervező eszköz (test design tool): a műszaki teszttervezési tevékenységet
támogató eszköz, amely tesztbemeneteket generál egyéb forrásokból, pl. CASE eszközökből,
követelmény menedzsment eszközökből, tesztfeltételekből valamint magából a
programkódból.
 Funkciói és jellemzői:
o tesztbemeneti értékek generálása a következőkből:
 követelmények
 műszakiterv-modellek (állapot, adat vagy objektum)
 programkód
 grafikus felhasználói felületek
 tesztelési feltételek
o elvárt értékek generálása, amennyiben az eszköz rendelkezik orákulummal

Tesztadat-előkészítő eszközök
 Tesztadat előkészítő eszköz (test data preparation tool): olyan teszteszköz, amellyel a
teszteléshez adatot állíthatunk elő egy már meglévő adatbázisból. Az eszköz alkalmas lehet
egyéb adatok generálására, adatok manipulálására, valamint szerkesztésére is.
 Funkciói és jellemzői:
o fájlokból és adatbázisokból kiválasztott adatrekordok kiemelése
o az adatrekordok megváltoztatása, anonimizálása, hogy lehetetlenné váljon valódi
személyekkel történő beazonosításuk (adatvédelem)
o rekordok különböző rendben való csoportosításának, ill. elrendezésének lehetővé
tétele
o új rekordok generálása pszeudóvéletlen adatok telepítésével, vagy valamely
útmutató (pl. működési profil) alapján történő adatlétrehozással
o nagyszámú hasonló rekord létrehozása sablon alapján mennyiségi tesztekhez

6.1.6 A tesztvégrehajtás és naplózás eszköztámogatása (K1)

Tesztvégrehajtási eszközök
 Tesztvégrehajtási eszköz (test execution tool): olyan teszteszköz, amelynek segítségével
másik szoftvert futtathatunk egy automatizált szkript (pl. felvétel/lejátszás) segítségével
 Felvevő/lejátszó eszköz (capture/playback tool, record/playback tool): olyan végrehajtó
eszköz, amely felveszi a kézi tesztelés lépéseit annak érdekében, hogy ezekből később
végrehajtható automatikus teszt szkripteket generáljon (pl. megismétli őket). Ezeket az
eszközöket gyakran használják az automatikus regressziós tesztek támogatására.

55
 A tesztvégrehajtási eszközök szkriptnyelvet használnak az eszköz vezérléséhez. A szkriptelés
előnye, hogy a tesztek képesek az egyes műveletek (ciklikus) megismétlésére.
 Legjobban a regressziós tesztelésben alkalmazhatók, mert leggyakrabban korábban már
elvégzett teszteket futtatnak le újra.
 Funkciói és jellemzői:
o tesztbemenetek felvétele (átvétele) a tesztek manuális futtatása közben
o elvárt eredmény tárolása egy képernyőmentés vagy adatobjektum formájában,
amivel össze lehet hasonlítani a teszt későbbi futtatása során kapott eredményt
o tesztek végrehajtása a tárolt szkriptekből és esetlegesen a szkriptek számára
hozzáférhető adatfájlokkal meghajtott tesztek végrehajtása
o képernyőmentések, elemek, linkek, vezérlők, objektumok és értékek dinamikus
összehasonlítása (a teszt futása közben)
o a végrehajtás utáni összehasonlítás kezdeményezése
o a lefuttatott tesztek naplózási eredményei (siker/bukás, eredmény különbségek)
o a tényleges és az elvárt eredmények részhalmazainak maszkolása vagy szűrése
o időzítések mérése a teszthez
o a bemenetek bevitelének szinkronizálása a tesztelt alkalmazásokkal
o összefoglaló eredmények küldése egy tesztmenedzsment eszköznek

Teszttámogató szoftverkörnyezet/egységteszt keretrendszer eszközök (F)

 Teszttámogató szoftverkörnyezet (test harness): a teszt végrehajtásához szükséges, a
meghajtókat és csonkokat tartalmazó tesztelési környezet.
o Csonk (stub): egy szoftver komponens speciális célú vagy részleges megvalósítása. A
csonkot arra használjuk, hogy támogassuk a komponens(ek) fejlesztését vagy
tesztelését. Helyettesíti a meghívott komponenst. [IEEE 610 alapján].
o Meghajtó (driver): egy szoftver komponens, vagy teszt eszköz, amely kiváltja azt a
komponenst, amely egy másik komponens, vagy a rendszer vezérlését, és/vagy
felhívását végzi.
 Egységteszt keretrendszer (unit test framework): olyan környezetet biztosító keretrendszer,
amelyben egy komponens egyaránt tesztelhető különállóan valamint a megfelelő
segédprogramokkal. Hibakeresési funkciójával támogatja a szoftverfejlesztő munkáját is.
[Graham]
 Funkciói és jellemzői:
o bemenetek szolgáltatása a tesztelt szoftver felé
o a tesztelt szoftver által generált kimenetek átvétele
o tesztek egy készletének végrehajtása a keretrendszeren belül vagy a teszttámogató
szoftverkörnyezet felhasználásával
o az egyes tesztek eredményeinek (siker/bukás) rögzítése (keretrendszerekben)
o tesztek tárolása (keretrendszerekben)
o a hibakeresés tárolása (keretrendszerekben)
o lefedettség mérése a kód szintjén (keretrendszerekben)

Teszt összehasonlító eszközök

 Teszt összehasonlító eszköz (test comparator): egy teszteszköz, amellyel a teszt elvárt és
aktuális eredményeit automatikusan össze lehet hasonlítani.
 Teszt összehasonlítás (test comparison): a rendszeren illetve rendszerkomponensen végzett
elvárt és aktuális teszteredményt összehasonlító eljárás. Az összehasonlítás elvégezhető a
teszt futtatása közben (dinamikus összehasonlítás) valamint a teszt futtatása után is.

56
  Funkciói és jellemzői:
o a teszt végrehajtása alatt bekövetkező átmeneti események dinamikus
összehasonlítása
o fájlokban vagy adatbázisokban tárolt adatok végrehajtás utáni összehasonlítása
o tényleges és elvárt eredmények egy részének maszkolása, szűrése
o teszt-orákulum: megmondja, hogy mi az elvárt eredmény (lehet egy szakértő, vagy a
rendszer egy korábbi verziója, stb.)

Lefedettség mérő eszközök (Coverage) (F)

 Lefedettségi eszköz (coverage tool): olyan eszköz, amely objektíven méri, hogy mely
strukturális elemeket – pl. utasításokat, elágazásokat - hajt végre a tesztkészlet.
 Funkciói és jellemzői:
o lefedettségi elemek azonosítása (a kód instrumentálása)
o egy tesztkészlet által végrehajtott lefedettségi elemek százalékos arányának
kiszámítása
o a még végre nem hajtott lefedettségi elemek jelentése
o a még lefedetlen elemek végrehajtásához szükséges tesztbemenetek meghatározása
o csonkok és meghajtók készítése (ha egy egységteszt-keretrendszer része)

Biztonsági eszközök
 Biztonság (security): a szoftvertermékek azon tulajdonságai/attribútumai, amik a
programokhoz és adatokhoz való jogosulatlan hozzáférést előzik meg. A hozzáférés lehet
szándékos vagy akár véletlen is. Lásd még: funkcionalitás. [ISO 9126]
 Biztonsági eszköz (security tool): olyan eszköz, ami a működési biztonságot támogatja.
 Biztonsági teszt (security testing, safety testing): olyan teszt, amivel a szoftvertermék
biztonságát határozzuk meg. Lásd még: funkcionalitási teszt
 Biztonsági teszteszköz (security testing tool): olyan eszköz, ami a biztonsági karakterisztikák
és sebezhetőségek teszteléséhez nyújt támogatást.
 Biztonsági karakterisztika:
o adatbiztonság
o adatintegritás
o hitelesítés
o engedélyezés
o rendelkezésre állás
o válaszmegtagadás
 Funkciói és jellemzői:
o vírusok azonosítása
o behatolók felismerése (pl. DoS támadás)
o különböző típusú külső támadások szimulálása
o nyitott portok, és egyéb külsőleg látható támadási pontok kipróbálása
o a jelszófájlokban és jelszavakban lévő gyengeségek meghatározása
o biztonsági ellenőrzések a működés közben (pl. fájlok sérthetetlensége)
 A biztonsági eszközök általában a különböző technológiákra, platformokra és célokra
koncentrálnak.

6.1.7 Teljesítmény és felügyelet eszköztámogatása (K1)

Dinamikus elemző eszközök (F)
 A szoftver futtatása szükséges

57
 Dinamikus elemző eszköz (dynamic analysis tool): a szoftverkód állapotáról futási időben
információt szolgáltató eszköz. Leggyakrabban érvénytelen mutatók, memóriafoglalások – és
törlések, illetve memóriaszivárgások felderítésére használják.
 Funkciói és jellemzői:
o memóriaszivárgások felderítése
o mutatók aritmetikai hibáinak (null mutatók) azonosítása
o időbeli függőségek meghatározása
 Általában a komponens, vagy komponens integrációs tesztnél használják, valamint köztes
rétegű teszteknél.

Teljesítményteszt/terheléses teszt/stressz teszt eszközök

 A teljesítményteszt eszközök azt vizsgálják, hogy a rendszer helytáll-e, ha nagy értékű
használatnak van kitéve
 A terheléses teszt azt ellenőrzi, hogy a rendszer képes-e megbirkózni az elvárt számú
tranzakcióval.
o Terheléses teszt (load testing): a teljesítményteszt azon típusa, amely a komponens
vagy rendszer viselkedését vizsgálja növekedő terhelés alatt (például a felhasználók
számának, vagy kérések számának növelésekor). A teszt célja, hogy kiderüljön, a
komponens vagy rendszer hogyan reagál a magas terhelésre (lefagy, nő a válaszidő,
stb.). Lásd még: teljesítményteszt, stressz teszt.
 A mennyiségi teszt azt vizsgálja, hogy a rendszer meg tud-e birkózni a nagy mennyiségű
adattal (pl. túl sok rekord)
o Mennyiségi teszt (volume testing): a rendszer funkcióit nagy mennyiségű adattal
vizsgáló tesztelési módszer. Lásd még: erőforrás használat teszt.
 A stressz teszt a rendszer várt – a terhelés és a mennyiség tekintetében normális –
használatán túlmegy.
o Stressz teszt (stress testing): olyan teljesítményteszt típus, amikor úgy vizsgálunk egy
komponenst vagy rendszert, hogy az előre elvárt vagy annál nagyobb terheléssel,
vagy csökkentett erőforrás rendelkezésre bocsátással teszteljük - például korlátozott
szerver, vagy memória hozzáféréssel. Lásd még: teljesítményteszt, terheléses teszt.
[IEEE 610 alapján].
 Funkciói és jellemzői:
o terhelés generálása a tesztelt rendszerre
o adott tranzakciók időzítésének mérése, ahogy a rendszer terhelése változik
o az átlagos válaszidő mérése
o gráfok vagy diagramok készítése a válaszok időbeli eloszlásáról
 A terhelés szimulálása virtuális felhasználók létrehozásával érhető el, akik különböző
tranzakciókat hajtanak végre, különböző tesztgépeken elosztva. Ezeket általában terhelés
generátornak nevezik

Felügyeleti eszközök
 A használatban lévő rendszer státuszának folyamatos nyomon követésére használják.
 Felügyeleti eszköz (monitor, monitoring tool): egy szoftver, vagy hardver eszköz, amely
párhuzamosan fut a tesztelés alatt levő komponenssel vagy rendszerrel, ez utóbbiakat
felügyeli, elmenti és/vagy elemzi azok viselkedését. [IEEE 610 alapján].
 Funkciói és jellemzői:
o problémák azonosítása és figyelmeztető üzenet küldése az adminisztrátornak
o valós idejű és történeti információk naplózása

58
 o optimális beállítások keresése
o a hálózaton lévő felhasználók számának figyelése
o a hálózati forgalom felügyelete

6.1.8 Speciális tesztelői igények eszköztámogatása (K1)

 Adatminőség értékelése: Több projekt fókuszában az adatok vannak, pl. az
adatkonverziós/migrációs projektek, illetve az adatbázisokkal foglalkozó alkalmazások, és
ezek attribútumai különbözhetnek mind a kritikusság, mind a méret tekintetében. Bizonyos
körülmények között eszközök válhatnak szükségessé az adatminőség értékelésére, Meg kell
vizsgálni, hogy a feldolgozott adatok helyesek-e, teljeskörűek-e, illetve megfelelnek-e az
előre definiált szabványoknak.
 További teszteszközök léteznek a használhatósági tesztekhez.
 Hibakeresés (debugging): a szoftver meghibásodás okainak megtalálási, analizálási és
eltávolítási folyamata.
 Hibakereső eszköz (debugging tool): a programozó által használt eszköz a külső hibák
reprodukálására, elemzésére és a hibák okainak megtalálására. A hibakereső eszközök
lehetővé teszik a program lépésenkénti végrehajtását, illetve bármely utasításánál történő
megállítás át, valamint a programváltozók vizsgálatát és beállítását.

6.2 Eszközök hatékony használata: a lehetséges előnyök és kockázatok (K2)

 Egy eszköz megvétele vagy bérlése nem garantálja az eszköz sikerét. Minden típusú eszköz
esetében szükség lehet további erőfeszítésekre a valódi és tartós előnyök eléréséhez. A
tesztelés eszköztámogatása esetleges előnyöket és lehetőségeket jelent, azonban
kockázatokat is hordoz magában.

6.2.1 Az eszközök használatának lehetséges előnyei

 Csökken az ismétlődő munka (pl. regressziós tesztek futtatása, ugyanazon tesztadatok
ismételt bevitele, kódolási szabványok ellenőrzése).
 Jobb konzisztencia és megismételhetőség (pl. eszköz által végrehajtott tesztek,
követelményekből származtatott tesztek).
 Objektív elemzés (pl. statikus mérések, lefedettség).
 Könnyű hozzáférni a tesztekkel, vagy teszteléssel kapcsolatos információkhoz (pl. a teszt
előrehaladást, az incidens-arányokat és teljesítményt mutató statisztikák és grafikonok).

6.2.2 Az eszközök használatának kockázatai

 Irreális elvárások az eszközzel kapcsolatban (ilyen a funkcionalitás és a könnyű használat).
 Az eszköz bevezetésére szánt idő, költségek és erőfeszítések alábecslése (a képzés és a
külső szaktudás is ilyen).
 Az eszköz által nyert jelentős, szignifikáns és folyamatos előnyök eléréséhez szükséges idő és
erőfeszítés alábecslése (ide tartozik a tesztfolyamat átalakításának szükségessége és az
eszköz használati módjának folyamatos javítása).
 Az eszköz által előállított teszteszközök karbantartásához szükséges erőforrások
alábecslése.
 Az eszközbe vetett túl nagy bizalom (a műszaki tesztterv specifikáció helyettesítése, illetve
eszközhasználat ott, ahol a manuális teszt jobb lenne).
 Az eszközzel kapcsolatos verziókövetés elhanyagolása.

59
  A kritikus eszközök, mint pl. a követelmény menedzsment, verziókövető, incidens
menedzsment, hibakövető, illetve a különböző eszközforgalmazóktól származó eszközök
kapcsolatából, illetve együttműködéséből származó problémák elhanyagolása.
 Az eszköz forgalmazójának üzleti kockázata, mint pl. tönkremegy, nem támogatja tovább az
eszközt, vagy eladja egy másik félnek.
 A forgalmazó gyenge minőségű support, upgrade, illetve hibajavító szolgáltatása
 Előre nem látható problémák, mint például egy új platform támogatásának hiánya

6.2.3 Különleges tényezők egyes eszköz-típusoknál (K1)

Tesztvégrehajtási eszközök
 A tesztvégrehajtási eszközök visszajátsszák az elektronikusan rögzített tesztek
végrehajtására tervezett szkripteket. Ennél a típusnál gyakran jelentős erőfeszítések
szükségesek a nagyobb előnyök eléréséhez.
 Vonzó lehetőség teszteket rögzíteni egy manuális tesztelő műveleteinek felvételével, ez a
megközelítés azonban nem megfelelő nagyszámú automatizált teszt esetén. Egy felvett
szkript lineárisan reprezentálja a meghatározott adatokat és a műveleteket. Ez a típusú
szkript nem várt incidensek fellépésekor instabil lehet.
 Szkript nyelv (scripting language): a tesztvégrehajtási eszközök (pl. felvevő/lejátszó
eszközök) által is használt programozási nyelv, amiben futtatható teszt szkripteket lehet írni.
 A szkriptelésnek több szintjét különböztetjük meg:
o lineáris szkriptek (készíthetők manuálisan, vagy egy manuális teszt rögzítésével)
o strukturált szkriptek (elágazási és ciklusvezérlési programozási struktúrák
felhasználásával)
o megosztott szkriptek: egyes szkriptek lehívhatnak más szkripteket.
o adatvezérelt szkriptek:
 Az adatvezérelt megközelítés elkülöníti a tesztbemeneteket (az adatokat),
általában egy adatbázisba, és egy általánosabb szkriptet használ, amely
képes tesztadatokat beolvasni és eltérő adatokkal végrehajtani ugyanazokat
a teszteket. Azok a tesztelők, akik nem ismerik a szkriptnyelvet, bevihetik az
adatokat ezeknél az előre meghatározott szkripteknél.
 Vannak más adatvezérelt technikák is, ahol az adatbázisokban előre rögzített
adatkombinációk helyett konfigurálható paramétereken alapuló
algoritmusok segítségével futási időben generálják az adatokat, amelyeket
az alkalmazás tesztjeihez használnak. Például egy eszköz használhat egy
algoritmust, amely egy véletlenszerű felhasználói azonosítót generál, és a
megismételhetőség érdekében az eszköz biztosítja a véletlenszerűség
irányítását.
 Adatvezérelt teszt (data--driven testing): olyan szkript módszer, amely egy
táblázatban tárolja a bemeneteket és az elvárt értékeket oly módon, hogy
egy vezérlő szkript minden tesztet végre tud hajtani belőle. Az adatvezérelt
tesztet gyakran használják pl. felvevő/lejátszó tesztelő eszközök
használatának támogatására. [Fewster and Graham] Lásd még: kulcsszó-
alapú teszt.
o kulcsszó (akciószó) alapú szkriptek: Az akciószó alapú tesztelési megközelítésnél az
adatbázis akciószavakat (kulcsszavakat) tartalmaz, amelyek leírják, milyen adatokkal
és milyen akciót kell végrehajtani. A tesztelők – még akkor is, ha nem ismerik a
szkriptnyelvet – az akciószavak alapján teszteket definiálhatnak, amelyeket a
tesztelendő alkalmazásra testre szabhatnak.

60
  Kulcsszó-alapú teszt (action word driven testing, keyword-driven testing):
egy olyan, szkripteken alapuló tesztelési technológia, amelynél a teszt-
szkriptekben nemcsak tesztadatok és az elvárt eredmény található, hanem az
alkalmazással kapcsolatos vezérlő kulcsszavak is. Az akciószavak értelmezését
a teszthez tartozó vezérlő szkriptek által meghívott speciális támogató
szkriptek végzik. Lásd még: adatvezérelt teszt.
 Technikai szaktudás a szkriptnyelvhez minden esetben szükséges (vagy a tesztelő, vagy a
teszt automatizálási specialista részéről).
 Függetlenül a használt szkript technikától, minden teszthez tárolni kell az elvárt eredményt
későbbi összehasonlítás céljából.

Statikus elemző eszközök

 A projekt elejétől érdemes használni.
 A forráskódra alkalmazott statikus elemző eszközökkel be lehet tartatni a kódolási
szabványokat, ha azonban már meglévő kódon alkalmazzák őket, sok hibaüzenetet
hozhatnak létre. A figyelmeztető üzenetek nem állítják le a kód futtatható programmá való
fordítását, de érdemes kezelni őket, így a jövőben könnyebb lesz a kód karbantartása.
Hatékony megközelítés lehet a fokozatos bevezetés, kezdetben szűrők használata bizonyos
üzenetek kizárásához.

Tesztmenedzsment eszközök
 A tesztmenedzsment eszközöknek kapcsolódniuk kell más eszközökhöz, vagy
adatbázisokhoz, hogy a szervezet aktuális igényeinek megfelelő formátumban biztosíthassa
az információkat.

6.3 Eszköz bevezetése egy szervezetnél (K1)

6.3.1 Fő alapelvek
Egy szervezet a következő főbb szempontok alapján választ ki egy eszközt:
 Mennyire érett a szervezet egy eszköz bevezetésére; az eszköz erős és gyenge pontjainak
elemzése; az eszközök által támogatott, továbbfejlesztett tesztfolyamatok alkalmazási
lehetőségének felmérése.
 Világos követelmények és objektív feltételek kiértékelése.
 A kiértékelési fázisban meg kell győződni arról, hogy az eszköz hatékonyan működik-e együtt
a tesztelendő szoftverrel az adott infrastruktúrában, illetve az infrastruktúrában szükséges
változtatásokat meg kell határozni az eszköz hatékony használata érdekében.
 Az eszköz forgalmazójának értékelése (beleértve az oktatásokat, support-ot, illetve
kereskedelmi szempontokat), illetve a kereskedelemben nem kapható eszközöknél a szerviz
support szolgáltatást
 A belső követelmények meghatározása az eszköz használatával kapcsolatos coach, illetve
mentorálási tevékenységek tekintetében
 Az oktatási igények kiértékelése a jelenlegi tesztcsapat automatizálási képességeinek
tekintetében
 A konkrét üzleti eseten alapuló költség-ráfordítás becslés készítése

6.3.2 Próba projekt

A kiválasztott eszköz szervezetnél való bevezetése egy pilot projekttel kezdődik, melynek céljai a
következők:

61
  Az eszköz részletesebb megismerése.
 Annak értékelése, hogy az eszköz hogyan illeszkedik a meglévő folyamatokba és gyakorlatba;
a szükséges változtatások meghatározása.
 Az eszköz és a teszteléssel kapcsolatos elemek szabványos használati, menedzselési, tárolási
és karbantartási módjának meghatározása (pl. fájlok és tesztek elnevezési szabályai,
könyvtárak létrehozása, tesztkészletek modularitásának definiálása).
 Annak értékelése, hogy az előnyöket elfogadható kiadásokkal érik-e el.

6.3.3 Sikerességi tényezők

Az eszköz adott szervezetnél való sikeres bevezetésének tényezői:
 Az eszköz folyamatos bevezetése a szervezet további egységeiben.
 Az eszköz használatához illeszkedő folyamatok átvétele, illetve fejlesztése.
 Képzés és betanítás/tanácsadás biztosítása az új felhasználók részére.
 Használati irányelvek kidolgozása.
 Módszer kidolgozása az eszköz használatával kapcsolatos tapasztalatok feldolgozására.
 Az eszköz használatának és előnyeinek felügyelete.
 A tesztcsapat támogatása az eszközzel kapcsolatban
 A tanulságok begyűjtése minden csapattól

62
IEEE 610

 Minőség (quality)
 Követelmény (requirement)
 Teszteset (test case)
 Működési teszt (operational testing)
 Csonk (stub)
 Robosztusság (robustness)
 Tesztkörnyezet (test environment)
 Teljesítmény (performance)
 Stressz teszt (stress testing)
 Inspekció (inspection)
 Állapotdiagram (state diagram)
 Súlyosság (severity)
 Felügyeleti eszköz (monitor, monitoring tool)

IEEE 829 „Szoftverteszt Dokumentáció Szabvány”

 Teszt terv (test plan)

 Műszaki tesztterv specifikáció (test design specification)
 Teszteset specifikáció (test case specification)
 Teszteljárás specifikáció (Test Procedure Specification)
 Tesztelem kiadási jelentés (Test Item Transmittal Report)
 Tesztelési napló (Test Log)
 Incidensjelentés (Test incident report)
 Teszt összefoglaló jelentés (Test Summary)

IEEE 1008

 Incidens (incident)

IEEE 1028

 Felülvizsgálat (review)
 Átvizsgálás (walkthrough)
 Technikai felülvizsgálat (technical review)
 Inspekció (inspection)

IEEE 1219

 Karbantartás (maintenance)

63
EEE/IEC 12207

 A szoftver életciklus folyamatokat leíró szabvány („Software life cycle processes”)

ISO 9000

 Verifikáció (verification)
 Validáció (validation)

ISO 9126 „Software Engineering – Szoftvertermékek Minősége”

 Biztonság (security)
 Együttműködő képesség (interoperability)
 Karbantarthatóság (maintainability)
 Megbízhatóság (reliability)
 Hordozhatóság (portability)

ISO 14598

 Metrika (metric)

64