Csoport neve: ICECUBE

Feladat címe: Intelligens hűtőszekrény szoftver tervezete

Analízis modell

Gyakorlatvezető:

Ficsor Lajos

Csoport tagok:

2009.12.04

Történet

Tesztelés

Ezen rész fontossága a rendszer pontos és megbízható működésének megvizsgálása.

Elgondolásaink és előírásainknak túlnyomó részt megfelel. Erre a tesztelés ad teret.

Tesztelési lehetőségek:

Két módszer:

• forráskód vizsgálat

• működés és viselkedés vizsgálat

Statikus

• Kódellenőrzés: Program terv össze vetése a forrás programmal.

• Szintaktikai hibák: Fordítóval vagy interpreterrel végezzük

• Formai ellenőrzés: Forráskód tagoltság megfelelő kommentálás.

• Tartalmi ellenőrzés: Forrásprogram vizsgálata. (vezérlés és paraméterek megfelelőek-e?)

• Walk- throught: Kés forrás program átjárása számítógép nélkül. (kívülálló programozó)

Dinamikus

Az inputból előállított outputokat vizsgálja. A programot teszt adatokkal le futtatjuk. A lefutás végén kapott outputokat elemezzük, s következtetünk a program működésének helyességre.

Program tesztelésére két módszert használunk:

Fekete doboz módszer: A programot fekete doboznak tekintjük, amelynek adatokat adunk s arra reagál. Mivel minden bemeneti adatot nem tudunk meg határozni ezért osztályokra osztjuk (ekvivalencia-osztályok). Amennyiben a program rosszul válaszol úgy az osztály többi adatára is rosszul válaszolna. Ugyanígy viselkedve jó válaszra is.

Ha minden ekvivalencia-osztályra jól reagál akkor minden inputra megfelelő a program.

(Ekvivalencia-osztályokat úgy határozunk meg, hogy megfelelő és nem megfelelő input adatokat is tartalmazzon.) Kipróbálásnál adatokat úgy választunk, hogy lehetőleg minden osztályt lefedjen.

Fehér doboz módszer:

A program logikai menetéhez igazodik. Összes lehetséges utasítás végrehajtás sorrendjét ki kell próbálnunk, de szinte kivitelezhetetlen. Ezért következő módszereket használata előnyös:

Utasítások egyszeri lefedése: Teszt t adatokat úgy választunk hogy minden utasítás legalább egyszer végrehajtódjon.

Döntés lefedés: Az elv célja hogy a programban szereplő összes döntés felvegye minden lehetséges állapotát. Elágazások esetén mint hamis és igaz.

Hibakeresés a programban

A tesztelési folyamat során valamilyen hibát észlelünk, annak helyére szükségünk van.

Indukciós módszer: Teszt adatokat rendezzük, és ezek alapján próbálunk következtetni a hibára.

Dedukciós módszer: Összes hiba felsorolása és ennek csökkentése.

Visszalépéses módszer: A hiba jelentkezésének pontjától visszafelé keressük azt a pontot ahol még még nincs hiba.

Hibakeresési eszközök

Ezen módszerek célja a könnyed és gyors hiba keresés.

• Részegységekre bontás: Amennyiben lehetőség van kisebb külön álló részekre bontjuk a programot. Így kisebb területet kell vizsgálni.

• Kiíratás: A program helyezzük el minél több helyen. Így könnyebb a hiba helyének detektálása.

• Ellenőrző feltételek: A programban olyan feltételek elhelyezése melyek értéket működést ellenőrzést végeznek, s amennyiben hibát észlelnek megszakítják a futtatást.

A felderítendő hibák fajtái:

Bemeneti/kimeneti hibák:

• helytelen bemenet elfogadás

• helyes bemenet megtagadás

• rossz paraméterezés

• rossz kimeneti formátum

• rossz kimeneti eredmény

• hiányzó/pontatlan leírás

• rossz kódolás

Logikai hiba:

• hiányzó/duplikált esetek

• extrém feltételek hiánya

• rossz változok tesztelése

• rossz operátorok

• kimaradt feltételek

Számítási hiba:

• rossz algoritmus

• rossz belső függvény

• helytelen operandus/művelet

• hiányzó számítások és műveletek

Interface hiba:

• rossz modul hívás

• rossz megszakítás kezelés

• rossz I/O ütemezés

Adathiba:

• helytelen tárolás/hozzáférés

• helytelen inicializáció

• rossz változóhasználat

• helytelen típus

• ellentmondásos adat

• rossz flag/ index érték

Komponensek tesztelése

Külön álló egységek: Azon tesztelés amelyben meg bizonyosodhatunk, hogy az egyes komponensek/egységek működése helyes e.

Modultest: Magasabb szintű egységek tesztelése.

Rendszerek, alrendszerek tesztelése

rendszer teszt: Alrendszerek közti kommunikáció helységét figyeljük meg. Megvizsgáljuk, hogy a modulok megfelelően együtt működnek és illeszkednek.

alrendszer teszt: Használt modulok együttesének tesztelése. Ennek a tesztelésnek a modulok közti kommunikációs hibák felderítése a célja.

Tesztelési formák:

Top-down: A legfelső hierarchiai szintről indulva végig vizsgáljuk az összes útvonalat miközben ellenőrizzük a program részek megfelelő működését.

Bottom-up: Alulról felfelé. A legalapvetőbb programrészektől haladunk felfele s vizsgáljuk a részek közti átadott érték helyességét.

Végső teszt folyamatok:

Béta teszt: Amikor már a program a test adatokkal már megfelelően működik lehetőséget adhatunk néhány felhasználó számára a rendszer tesztelésére valós adatokkal. Ezzel is segítve a program hibáinak feltárását.

RC (Release Candidate): A kiadásra szánt modell de még nem a végleges. Itt a tesztelő felhasználok köre bővül. Hibák száma kevesebb.

Bug Report: Mivel tesztelés folyamán nem lehetséges mindent letesztelni a gyártó terén. Ezért a kiadás után a felhasználok találhatnak hibákat még. Ezen hibákat a gyártó felé jelezhetik. Így a felhasználók is valamilyen szinten tesztelőknek számítanak. Egy tökéletes program megvalósítása és egy jól használható hibamentes rendszer érdekében.