1144-4. tétel Egy program működése közben időnként hibák lépnek fel, de ezek nem rendszeresen következnek be. Milyen módszerrel keresné meg a hiba helyét?

Információtartalom vázlata

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

–Szoftverkomponensek– Az egyes elemek kommunikációjának vizsgálata

–Tesztelés, hibakeresés– A hiba helyének szűkítése

–Alkalmazásfejlesztő eszközök– Debuggolás használata

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érelvek Csak 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és A 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.

Tesztelési megfontolások Achitektúrális validáció

A felülről lefelé integrálásos teszteléssel könnyebb a rendszer architektúrájában levő hibák felfedezése.

Rendszer demonstrációja A felülről lefelé integrálásos tesztelés a fejlesztés korai szakaszában már lehetővé tesz korlátozott demonstrációt.

A teszt implementálása Gyakran könnyebb alulról felfelé integrálásos teszteléssel.

A teszt megfigyelése Mindkét megközelítéssel problematikus. Extra kódra lehet szükség a teszt megfigyeléséhez.

Végtesztelés A rendszer egy terjesztésre szánt verziójának (release) tesztelésének folyamata. Elsődleges célja a gyártó bizalmi szintjének növelése abban, hogy a rendszer megfelel

a követelményeknek. A végteszt általában fekete doboz teszt (vagy funkcionális teszt)

Csak a specifikáción alapul; A tesztelők nem ismerik a rendszer implementációját.

Stressz tesztelés A rendszert a tervezett értéknél jobban terheljük. A rendszer stresszelése gyakran fed

fel hibákat. A stresszelés a hibás működés közbeni viselkedését is teszteli. A rendszernek nem

szabad katasztrofálisan összeomlania. Teszteli az elfogadhatatlan szolgáltatás-kiesést vagy adatvesztést.

A stressz teszt különösen fontos elosztott rendszereknél, ahol a rendszer súlyosan degradálódhat, ha a hálózat túlterhelődik.

Komponens tesztelés A komponens tesztelés az egyes komponensek izolált tesztelésének folyamata. Hibatesztelő folyamat. Komponensek lehetnek: Egyedi függvények vagy objektumok metódusai; Objektum osztályok sok attribútummal és metódussal; Kompozit komponensek, amelyek szolgáltatásait interfészeken keresztül lehet elérni.

Objektum osztályok tesztelése Egy osztály teljes tesztelése:

Az objektumhoz tartozó valamennyi operáció tesztelése; Az összes attribútum beállítása és lekérdezése; Az objektum valamennyi állapotának elérése.

Az öröklés megnehezíti az objektum-osztály tesztelését, mert a tesztelendő információ nem lokalizált.

Követelmény-alapú tesztelés A követelmény-tervezés egyik alapelve, hogy a követelmények tesztelhetők legyenek. A követelmény-alapú tesztelés egy validációs tesztelési technika, ahol minden egyes

követelményhez kidolgozunk azt ellenőrző teszteket.

Partíciós tesztelés A ki- és bemeneti adatok gyakran különböző osztályokba sorolhatók, ahol az

osztályon belüli elemek „hasonlóak”. Ezen osztályok mindegyike egy ekvivalencia partíció, ahol a a program ekvivalens

módon viselkedik az osztály minden elemére. Teszt esetek minden partícióból választandók.

Fekete doboz és fehér doboz módszer

Fekete doboz módszerMagá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.

A program viselkedését összeveti a specifikáció követelményeivel Magát a programot fekete doboznak tekintjük. A felhasználó szemszögéből vizsgálja a szoftvert A tesztelés menetét az adatok határozzák meg. Azon a szemléleten alapszik, hogy minden program egy-egy függvénynek tekinthető,

amely a bemenő értelmezési tartományának értékeit a kimenő értékkészletének értékeire képezi le.

Ismert:bemeneteka várt kimenetekaz egyetlen információ, melyet felhasználunk az a szoftver specifikációja.

Nem ismert:a fekete doboz tartalma (implementáció, hogyan is kódoltuk a programot).

Előnyök:Független attól, hogy a szoftvert hogyan implementálták. A test-case fejlesztés párhuzamosan következhet be az implementációval,

ezáltal csökkentve a teljes projekt tervezési intervallumot. Hátrányok:

Nem teszteli a rejtett függvényeket, azaz azokat amelyek implementálva lettek, de a funkcionális specifikációban nem szerepelnek, ezáltal az ebből adódó hibákat sem detektálja.

Módszerek:ekvivalencia osztályok (equivalence partitioning)határeset vizsgálat (Boundary value analysis)érvénytelen bemenet vizsgálata

Tesztelési tanácsokÖtletek a tesztelőknek: hogyan érdemes olyan teszteket választani, amelyek kimutatják a rendszer hibáit.

Olyan bemenetek választása, amelyek a rendszert hibaüzenetek (az összes!) generálására kényszerítik;

Olyan bemenetek tervezése, ami puffer túlcsorduláshoz vezethet; Ugyanazon bemenet vagy bemeneti sorozat többszöri ismétlése; Érvénytelen kimenetek kikényszerítése; Túl nagy vagy túl kicsi számítási eredmények kikényszerítése.

Rendszertesztek A bejelentkezési mechanizmus tesztelése helyes és helytelen azonosítókkal: annak

ellenőrzése, hogy az érvényes azonosítókat elfogadja, az érvényteleneket visszautasítja.

A keresés tesztelése különféle kereső kifejezésekkel ismert forrásokra: ellenőrizhető, hogy a kereső valóban megtalálja-e a dokumentumokat.

A kijelzés tesztelése: a dokumentumokról szóló információ helyesen van-e kijelezve? A letöltéshez engedélyt kérő mechanizmus tesztelése. Az e-mail-es értesítő rendszer tesztelése: elküldi-e a levelet a dokumentum

megérkezésekor.

Strukturális tesztelés/ 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 bonyolullt programok esetén többnyire gyakorlatilag kivitelezhetetlen, helyette sok módszert használhatunk, melyek közül megemlítünk kettőt:

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).

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.

Teszt esetek a program struktúrája alapján. A program ismerete alapján újabb teszt esetek azonosítása. A cél valamennyi utasítás (de nem minden végrehajtási út kombináció) végrehajtása.

A program viselkedését összeveti a forráskód „szándékával” A tesztelő a program belső struktúráját vizsgálja, azaz hogy miként is működik a

program. Hozzáférünk a forráskódhoz, annak a logikája szerint tesztelünk Tipikus, ha a szoftver egy részét, modulját teszteljük Előny:

A programozói hibák könnyen felismerhetők, mert az implementáció ismert. Hátrány:

A hiányos vagy hibás szoftverspecifikációt nem tudja felismerni. Kódlefedés (code coverage)

Szoftvetkomponensek

A szoftver komponens egy kompozíciós egység szerződésszerűen specifikált interfészekkel, amelyik környezetétől kizárólag a leírtak szerint függ. Függetlenül telepíthető és harmadik fél számára is felhasználható.Az újrafelhasználható szoftver komponens egy logikailag összetartozó, lazán csatolt modul, amelyik egyetlen absztrakciót jelöl.A szoftver komponensek előregyártott, előre tesztelt önhordó, újrafelhasználható szoftver modulok – adat- és eljáráscsomagok – amelyek specifikus funkciókat hajtanak végre.

A szoftver komponens olyan program-elem, amelyik:

Más program-elemek (nem személyek, vagy nem-szoftver rendszerek) – azaz kliensek - által használható

A szerzőjének nem kell tudnia a kliensekről A klienseknek csak azt kell tudni, amit a komponens szerzője mond nekik

Az egyes elemek kommunikációjának vizsgálata

Tesztelés, hibakeresés

Ellenőrzés és hibakeresés

A forrásprogram elkészülte után meg kell győződnünk annak helyességéről, illetve ha nem helyes, meg kell találnunk és ki kell javítanunk a hibákat. Egy program helyességét lehet matematikai eszközökkel (léteznek erre vonatkozó axiómák, tételek) bizonyítani. Az alapvető algoritmusokat éppen azért nevezik sokszor „programozási tételek”-nek, mert ezek helyességét matematikailag be lehet bizonyítani. Gyakorlati okokból azonban inkább teszteléssel ellenőrzünk.

Szoftvertesztelés Az a folyamat, mely vizsgálja, meghatározza a fejlesztett számítógépes szoftver

helyességét teljességét biztonságát minőségét

A programnak a hibák felderítése céljából történő futtatását jelenti (dinamikus vizsgálat).

Nem tudja teljes mértékben megállapítani a program helyességét. "A tesztelés csak a hibák létét bizonyítja, de azok hiányát nem!"

A minőség kritériumai lehetnek: megbízhatóság, hibatűrés hatékonyság hordozhatóság karbantarthatóság felhasználóbarátság

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 hiba helyének szűkítéseHibakeresés

Ha a tesztelésnél valamilyen hibát találunk, akkor szükségünk van a helyének meghatározására, hogy kijavíthassuk, ez a célja a hibakeresésnek. A hibakeresés megoldható a programfejlesztői környezet lehetőségeinek kihasználásával (TP-nál Iásd IDE).

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 a programozási nyelvhez tartozó fejlesztői környezet lehetőségeitől függenek.

Általában a következők használhatók: Kiíratás: A program több pontján elhelyezhetünk (ideiglenesen) kiíró utasításokat

(ezek később törölhetők a programból, vagy comment-ekké tehetők), így futtatás közben láthatóvá tehetünk sok mindent (változókat, vagy hogy melyik ágon fut a végrehajtás, stb.)

Töréspontok elhelyezése: (a programfejlesztői környezettől függően TP-ban Ctrl-F8, BASlCben Stop vagy Break, dBASE-ben Pause, Wait vagy Esc-pel, a program esetleg folytatható Resume-mal.) Meg lehet nézni a változók tartalmát, a file-ok állapotát a kívánt pillanatban, sőt szükség esetén módosíthatjuk is azokat, majd futtathatjuk tovább a programot.

Nyomkövetés: Utasításonként (vagy blokkonként) hajtja végre a programot, azok eredményéről tájékoztatást ad (Id.változók értékének követése).

Állapotellenőrzés: Különböző feltételeket helyezünk el, amelyek a program változóira vonatkoznak, és figyeljük annak helyességét. Ezek megállítják a programot, vagy üzenetet küldenek.

Szemantikus hibák keresése: Átnézhetjük a program kritikus részeit a programozási típushibákra koncentrálva. Ilyenek például: gépelési hiba, azonosító hibás megadása, vezérlésátadási hiba, elágazási hiba, szervezési hibák, a ciklusszervezés hibái.

Alkalmazásfejlesztő eszközökDebuggolás használata

Debuggolás fogalma:A szoftverekben rejlő hibák felderítésének és javításának folyamata, amelynek során a fejlesztők töréspontok és lépésenkétni végrehajtás segítségével nyomon követik a program állapotainak változásait, hogy azonosíthassák a hibás algoritmusokat és/vagy adatokat.