Objektumorientált tesztelés
OO tesztelés OO tesztelés funkcionális modell Az objektumok különálló komponensként nagyobbak, mint az egyszerű függvények A rendszernek nincsen egyértelmű teteje (az alrendszerekbe integrált objektumok lazán kötődnek) Az újrafelhasznált objektumoknál előfordul, hogy a tesztelők nem férnek hozzá a forráskódhoz Következmény: a fehér doboz tesztelést ki kell terjeszteni (hogy lefedje a nagyobb objektumokat), és alternatív megközelítési módokat kell találni az integrációs teszteléshez Az OO tesztelés szintjei: Az objektumokhoz kapcsolódó egyedi műveletek tesztelése (a metódusok tesztelésére a fekete/fehér doboz megközelítéseket alkalmazhatjuk) Objektumosztályok tesztelése (a fekete doboz elv nem változik, de az ekvivalenciaosztályozást ki kell terjeszteni műveletsorozatokra) Objektumok egy csoportjának tesztelése (a szigorú fentről lefele/lentről felfele történő integrációs elvek nem alkalmazhatóak más megközelítést kell találni) Objektumorientált rendszer tesztelése (a rendszerkövetelményspecifikáció verifikálása és validálása más rendszerekhez hasonlóan történik)
Objektumosztály tesztelése A tesztnek a teljes lefedettséghez tartalmaznia kell: Az objektumokhoz kapcsolódó összes művelet különálló letesztelését Az objektumokhoz kapcsolódó összes attribútum beállítását és vizsgálatát Az objektum összes lehetséges állapotának vizsgálatát: az összes olyan eseményt szimulálni kell, ami állapotváltozást okoz az objektumban Példa: meteorológiai állomás: egy egyszerű attribútum: azonosító: egy konstans ami az állomás telepítésekor kerül beállításra egy olyan tesztre van szükség ami ellenőrzi, hogy be van-e állítva WeatherStation identifier reportweather () calibrate (instruments) test () startup (instruments) shutdown (instruments) tesztesetek definiálása szükséges a metódusokhoz: ideális esetben ezeket elkülönítve teszteljük, de bizonyos esetekben tesztsorozatra is szükség lehet (pl. a shutdown teszteléséhez előbb le kell futtatni startup-ot)
Objektumosztály tesztelése Ha az objektum Leállítás állapotban van, a startup metódusra reagál, majd további üzenetre vár Ha Várakozás állapotban a rendszer shutdown üzenetet kap visszatér Leállítás állapotba Ha reportweather üzenet érkezik, a rendszer összegző állapotba kerül, majd ha az összegzés elkészül, átmegy átvivő állapotba, majd miután az információ továbbítódott, visszatér Várakozás állapotba Calibrate üzenet érkezése esetén a rendszer sorban kalibráló, tesztelő majd átvivő állapotokba kerül, mielőtt visszatérne Várakozás állapotba. A test üzenet közvetlenül tesztelő állapotba viszi a rendszert Az órától érkező jel esetén a rendszer gyűjtő állapotba kerül (sorban begyűjti az adatokat a műszerektől)
OO tesztelés A meteorológiai állomás állapotainak teszteléséhez állapotmodellt kell készíteni, így meghatározható az állapotátmenetek sorozata, és az átmenetekhez szükséges eseménysorozatok. Ideális esetben az összes lehetséges átmenetsorozatot tesztelni kellene, de a gyakorlatban általában ez túl költséges A meteorológiai állomás esetében a következő sorozatokat kell tesztelni: Indítás Várakozás Leállítás Várakozás Kalibrálás Tesztelés Továbbítás Várakozás Várakozás Gyűjtés Várakozás Összesítés Továbbítás Várakozás Ha öröklődést használunk, nehezebbé válik a tesztek megtervezése: az összes örökölt műveletet tesztelni kell, hasonlóan a felülírt műveletekhez Ekvivalenciaosztályozást alkalmazhatunk: az azonos ekvivalenciaosztályba eső tesztek azonos attribútumokat használnak (ekvivalenciosztályok azonosítása: melyik műveletek inicializálják/kérdezik le/frissítik az egyes attribútumokat)
Objektumintegráció OO rendszereknél az adatok és műveletek objektumokká és objektumosztályokká épülnek össze az integráció szintjei kevésbé eltérőek A modultesztelésnek nincs közvetlen megfelelője, bár bizonyos szolgáltatások biztosítására együttműködő osztálycsoportok tesztelése is ajánlott (csoporttesztelés) Nincs magától értetődő fent ami az integráció célját jelentené, nem hozható létre az objektumok tiszta hierarchiája csoportokat kell képezni az objektumok működésének ismeretében Lehetséges megközelítések: Használati eset vagy forgatókönyv alapú tesztelés: a tesztek a használati esetek leírásain és a megfelelő objektumcsoportokon alapulnak Száltesztelés: a rendszer egy sajátos bemenetre (vagy bemenet halmazra) adott válaszának tesztelésén alapszik. Az OO rendszerek általában eseményvezéreltek meg kell határozni, hogy az események feldolgozása hogyan halad keresztül a rendszeren Objektum együttműködési teszt: együttműködő objektumcsoportok esetén módszer-üzenet útvonalak azonosítása. Kiterjesztés: atomi rendszerfüggvények (ASF) bemeneti eseményt követő MM utak, melyek kimeneti eseményhez vezetnek
Forgatókönyv alapú tesztelés Gyakran a leghatékonyabb: először a leggyakoribb forgatókönyvek kerülhetnek tesztelésre a legtöbb tesztelési munkát a leggyakrabban használt részekre lehet fordítani Példa: meteorológiai állomás A forgatókönyvek elkészítése a használati eseteken alapul Ezeket kiegészíthetjük az együttműködési és szekvencia diagramokkal Biztosítanunk kell, hogy minden osztály minden metódusa legalább egyszer futtatásra kerüljön ellenőrző listát kell készíteni a módszerekről, és egy-egy forgatókönyv kiválasztásánál meg kell jelölni a lefuttatott módszereket A szekvencia diagram alapján meghatározhatóak a teszthez szükséges bemenetek és várt outputok Forgatókönyv: a meteorológiai állomás válaszol a térképrendszer adatgyűjtési kérésére
Forgatókönyv alapú tesztelés A teszthez szükséges bemenetek/kimenetek: A beérkező jelentéskérésnek rendelkeznie kell egy hozzátartozó nyugtázással, és a kérésre válaszolva vissza kell adnia egy jelentést. A tesztelés során összesített adatokat kell készíteni, hogy ellenőrizni lehessen a jelentés szerkezetét A WeatherStation-hoz érkező jelentéskérés egy összesített jelentést eredményez. Ezt elkülönítve tesztelhetjük, olyan nyers adatok előállításával, melyek megfelelnek a CommsController tesztelésére elkészített összesítéssel, továbbá ellenőrizzük, hogy a WeatherStation objektum helyesen készíti-e el az összesítést Az adatok a WeatherData objektum tesztelésére is alkalmazhatóak A diagram egyszerűsített: egy teljes forgatókönyv alapú tesztelés esetén a kivételeket is kezelni kell :CommsController request (report) acknowledge () report () :WeatherStation summarise () :WeatherData send (report) reply (report) acknowledge ()
Tesztelési eszközrendszerek A tesztelő eszközök mára a lehetőségek egész sorát nyújtják, és lényegesen csökkenthetik a tesztelési folyamat (egyébként általában magas) költségeit. A tesztelési eszközrendszerekben általában megtalálható tesztelési eszközök: Tesztmenedzser: a programtesztek futtatását menedzseli, nyomon követi a tesztadatokat, a várt eredményeket és tesztelt programeszközöket Tesztadat-generátor: adatbázisból történő adatleválogatással, minták használatával, vagy megfelelő formájú véletlen tesztadatok generálásával tesztadatokat állít elő a tesztelt program számára Előrejelző: a várt teszteredményekre vonatkozó előrejelzéseket állít elő. Lehetnek korábbi programverziók, vagy prototípus rendszerek, melyek párhuzamosan futnak a tesztelt programmal, így kiemelhetőek a kimenetek közötti esetleges különbségek Állomány összehasonlító: a programtesztek eredményeit hasonlítja össze korábbi teszteredményekkel, és jelzi a különbségeket. Elengedhetetlenek a regressziós tesztelésnél. Jelentésgenerátor: a jelentésdefiníciókat és az eredmények generálásához szükséges eszközöket nyújtja Dinamikus elemző: a programot kiegészítő kóddal látja el, hogy mérni lehessen az egyes utasítások futtatásának számát (a teszt lefuttatása után a mérések alaján futattási profilt generál) Szimulátor: célszimulátorok (a gépet szimulálják, amelyen a futtatásra kerül majd sor), felhasználói interfész szimulátorok (több egyidejű felhasználói interakciót szimulálnak), stb.
Tesztelési eszközrendszerek Tesztelési eszközrendszer (testing workbench): Test data generator Specification Source code Test manager Test data Oracle Dynamic analyser Program being tested Test results Test predictions Execution report Simulator File comparator Report generator Test results report