1144-20. Milyen módszerrel tesztelné az Ön által fejlesztett modult, amely egy másik programozó által írandó modult használná, de az még nincs teljesen kész?

Információtartalom vázlata

–Tesztelési ismeretek (teszttípusok)– Fekete és fehér doboz módszerek

–Adatszerkezetek, objektumok– Virtuális működés kialakítása– Interfészek használata

–Tesztelés, hibakeresés– A modul összes funkciójának tesztelése

Tesztelési ismeretek:A tesztelési eljárás

Komponens tesztelés Programkomponensek egyedi tesztelése; Általában a komponens fejlesztőjének feladata (kivétel a kritikus rendszerek); A tesztek a fejlesztő tapasztalatán alapulnak.

Rendszertesztelés Komponensek rendszerbe vagy alrendszerbe integrált csoportjainak tesztelése; Egy független fejlesztő csoport feladata; A tesztek a rendszerspecifikáción alapulnak.

A tesztelés fázisai Komponens tesztelés (szoftverfejlesztő)- rendszer tesztelés (független tesztelő

csoport) Hibatesztelés

A hibatesztelés célja a programhibák felfedezése A sikeres hibateszt a programot hibás viselkedésre bírja A teszt csak a hibák jelenlétét mutatja, de nem képes a hibák hiányát

jelezni.

A tesztelési eljárások célja Validációs tesztelés

A fejlesztők és megrendelő számára annak demonstrálása, hogy a szoftver teljesíti a követelményeket; A sikeres tesz eredménye, hogy a rendszer a tervek szerint működik.

Hibatesztelés A rendszerben hibák keresése: hibás viselkedés, vagy a specifikáció nem teljesítése; A sikeres teszt a rendszert hibás működésre kényszeríti, így a rendszer hibájára mutat rá.

Tesztelési vezérelvekCsak a kimerítő teszteléssel deríthető ki, hogy a program hibamentes. De a kimerítő tesztelés lehetetlen. A tesztelési vezérelvek definiálják a tesztek kiválasztásának módját: A menükön keresztül elérhető valamennyi funkciót le kell tesztelni; Az azonos menün keresztül elérhető funkciók kombinációit tesztelni kell; Ahol felhasználói bevitel van, minden funkciót ellenőrizni kell helyes és helytelen adatokkal.

Rendszertesztelés A komponensek rendszerbe vagy alrendszerbe integrálásával foglalkozik. A megrendelőnek átadandó inkrementum tesztelésével is foglalkozhat. Két fázis:

Integrációs teszt – A tesztelők használhatják a rendszer forráskódját. A rendszer a komponensek integrálása folyamán teszteljük. Végteszt (release test) – A tesztelők az átadandó teljes rendszert fekete dobozként tesztelik.

Integrációs tesztelésA rendszer komponensekből áll. A tesztelés a komponensek interakciójából eredő problémákkal foglalkozik. Felülről lefelé (top-down) integrálás A rendszer vázának felépítése, majd a komponensek beépítése.

Alulról felfelé (bottom-up) integrálás

Az infrastruktúra komponensek integrálása, majd a funkcionális komponensek hozzáadása. A hibalokalizálás megkönnyítése érdekében a rendszereket inkrementálisan célszerű integrálni.

Fekete doboz módszer: Magát a programot fekete doboznak tekintjük; nem foglalkozunk a szerkezetével. Mivel minden adatra nem tudjuk kipróbálni a programot, ezért a lehetséges input adatokat (beleértve érvényes és érvénytelen input adatokat is) jellemzőik szerint csoportokra (ekvivalencia-osztályokra) osztjuk. Ezután a ekvivalencia-osztályok egy vagy néhány tagjával kipróbáljuk a programot. Ha a program jól/rosszul működik az osztály egy adatára, akkor a többire is valószínűleg ugyanolyan módon működne. A tesztelésnél használt adatok mennyisége és minősége közelítse meg a futtatáskor várhatóakat, hogy a program gyorsaságáról is képet kapjunk.Fehér doboz módszer: Figyelembe veszi a program szerkezetét, a program logikájához igazodik. Olyan input-adatokat kellene összeállítunk, amelyek a program végrehajtódásakor annak összes ágát lefedik. Ez bonyolult programok esetén többnyire gyakorlatilag kivitelezhetetlen, helyette sok módszert használhatunk, melyek közül megemlítünk kettőt:

1. Utasítások egyszeri lefedésének elve: A tesztadatokat úgy határozzuk meg, hogy a program minden utasítására ráfusson legalább egyszer (vagyis minden programágra kerülő adatok előforduljanak).

2. Döntés-lefedés: A programban szereplő összes döntésnél (elágazási feltételnél) legyen hamis és igaz is a feltétel.

Interface definiálásaEgy osztály definiálása során a legfontosabb feladat az, hogy a készítendő típus adatait, metódusait megadjuk. Gyakran felmerül az az igény, hogy egy további fejlesztés, általánosabb leírás érdekében ne egy osztály keretében fogalmazzuk meg a legjellemzőbb tulajdonságokat, hanem kisebb tulajdonságcsoportok alapján definiáljunk. Ez viszont ellentmond annak az elvárásnak, hogy minél részletesebben fogalmazzunk meg a típusainkat. Az interfész gyakorlatilag egy absztrakt osztály, az alábbi megkötésekkel:Az interfész csak public hozzáférésű tagokat tartalmazhat. Nem lehetnek példányai.Metódusai nem implementálhatóak. Nem lehetnek adatmezői.A .Net osztályoknak csak egy főosztályuk lehet, de lehet több interfészük.Az interfészek konstruktorral nem rendelkezhetnek.

Az interfészt megvalósító osztálynak az összes metódust meg kell valósítania.Interfész csak interfész leszármazottja lehet.Egy osztály több interfészt is megvalósíthat.Ugyanazt az interfészt megvalósíthatja több osztály.A kiszolgáló objektum interfészt megvalósító metódusai nevének nem kell megegyeznie az interfészben hozzátartozó metódussal, de a paraméterlistája és visszatérési értéke típusának egyeznie kell.Az interfész többféle probléma megoldásánál is jól jöhet. Például C# nyelvben nem lehet egy osztálynak több szülője, csak egyetlenegy. Lehet viszont több interfésze, ezzel megvalósíthatunk közel ugyanolyan viselkedést, mintha több szülője lenne. A többalakúság is nagyon jól kezelhető interfészek segítségével, ha egy interfészen belül deklarált metódust több különböző osztályban fejtünk ki. Az interfészek használatára lássuk az alábbi példát.

TESZTELÉSA program-helyességet általában teszteléssel ellenőrizzük. A tesztelés a matematikai igazolással szemben nem bizonyítja a program helyességét, csak azt mondhatjuk, hogy minél körültekintőbb a tesztelés, annál valószínűbb, hogy a programban nem marad hiba. Sokféleképpen lehet a tesztelési módszereket csoportosítani;A programterv vizsgálatát íróasztal-tesztnek szokás nevezni, és ezt még a tervezés időszakában végzik el (fehér doboz-módszerrel).

Statikus tesztelésnek is nevezik a forrásprogram ellenőrzését; ekkor összevetik a programtervvel (kódellenőrzés), megkeresik a fordítóprogrammal a szintaktikai hibákat és ellenőrzik a változók használatát (formai ellenőrzés), a változók értékadásait és a vezérlőszerkezeteket (tartalmi ellenőrzés), valaki mást megkérnek arra, hogy nézze végig a listát (walk-through).

Dinamikus tesztelés: Futtatással vizsgáljuk a különböző input adatokból előállt output adatokat. Vagyis a programot lefuttatjuk a jól összeállított tesztadatokkal, és a kapott eredményeket összehasonlítjuk a vártakkal. A dinamikus tesztelésnek két alapvető fajtája van

A hibakeresés módszerei :Indukciós módszer: A rendelkezésre álló tesztelési tapasztalatokat rendszerezzük, s ezekből megpróbálunk következtetni a hibára. Ha jó ekvivalencia-osztályokat határoztunk meg, a hibás outputokból következtethetünk arra, hogy a program melyik ágán lépett fel a hiba.Dedukciós módszer: Az összes lehetséges hibaokot felsoroljuk, majd ezek körét szűkítjük.Visszalépéses módszer: A hiba helyétől visszafelé haladva vizsgáljuk a programot, és megpróbáljuk megállapítani azt a pontot, ahol még nincs hiba.

A Hibakeresési eszközök Kiíratás: Töréspontok elhelyezése: Nyomkövetés: Állapotellenőrzés:. Szemantikus hibák keresése: