SZOFTVER-MINŐSÉGBIZTOSÍTÁS SZOFTVER-TESZTELÉSI MÓDSZEREK. Széchenyi István Egyetem. Alapfogalmak

Átírás

1 Alapfogalmak Bemeneti adat: Olyan számítógépes adat, amely egy tetszőleges szoftver működtetését vonja maga után, felhasználói szinten. Kimeneti adat: Olyan számítógépes adat, amely egy tetszőleges szoftver működtetése során jelenik meg, a működtetés eredeményeként, felhasználói szinten. Hibamodell: Azon szoftver-hibák halmaza, amelyeknek a felfedésére irányul a teszttervezés. Tesztelés: A szoftver bemeneti adatokkal való sorozatos ellátása és a kimeneti válaszadatok megfigyelése. 1

2 Alapfogalmak Egy hiba tesztje: Bemeneti adatok olyan rendezett sorozata, melynek hatására az adott hibát tartalmazó szoftver a legutolsó adatkombinációra a helyestől eltérő (hibás) kimeneti adatkombinációval válaszol. Detektálható hiba: Egy hibáról akkor mondjuk, hogy detektálható, ha legalább egy tesztje létezik. Tesztkészlet: Több hiba tesztjeinek együttese, halmaza. Tesztkészlet hibalefedése (fault coverage): Azon hibák százalékos aránya az összes feltételezett hibához képest, amelyeket a tesztkészlet detektálni tud. 2

3 Alapfogalmak Teszttervezés: A bemeneti tesztsorozat és az elvárt válaszjelek meghatározása egy előre feltételezett hibahalmazra nézve. A mai információ-technológia már olyan bonyolult szoftverrendszerek előállítását teszi lehetővé, hogy a teljes hibalefedés elérése gyakorlatilag nem valósítható meg. Tesztszámítás vagy determinisztikus tesztgenerálás: Egy adott hiba tesztjének szisztematikus számításokkal történő meghatározása. Véletlenszerű/random tesztgenerálás: Bemenő adatok sorozatának véletlenszerű képzése a hibák tesztjeként történő felhasználásra. 3

4 Hibamodellek és érvényességi körük Egy hibamodell meghatározásakor a következő főbb szempontokat érdemes tekintetbe kell venni: A teszttervezés kivitelezhetőségi lehetőségei és a ráfordítandó költségek. Az adott fejlesztési technológiához kapcsolódó hibajelenségek előzetes ismerete. A tesztelés végrehajtásához szükséges hardver és szoftver eszközök által nyújtott szolgáltatások köre. 4

5 Szoftver-hibák Szoftver-specifikációs hibák A szoftver valamilyen vonatkozásban nem teljesíti a felhasználói követelményeket. A specifikációs hiba adódhat: téves specifikációból, ellentmondásos specifikációból, valamint hiányos specifikációból. Programozói hibák A szoftver tervezése és kódolása során a programozó által elkövetett hibák körét foglalja magában. 5

6 Programozói hibák Hibás funkcióteljesítés. Hiányzó funkciók. Adatkezelési hibák az adatbázisban. Indítási (inicializálási) és leállítási hibák. Felhasználói interfész hibái Határértékek túllépése Kódolási hiba Algoritmikus hiba Kalkulációs hibák Inicializálási hiba Vezérlési folyamat hibája Adattovábbítási hiba Versenyhelyzet programblokkok között Terhelési hiba 6

7 Teszttervezési példa Egy program beolvas három egészszámot, amelyek egy háromszög oldalainak hosszát képviselik. A feladata annak meghatározása, hogy az így előálló háromszög szabálytalan, egyenlő szárú, vagy pedig egyenlő oldalú. 7

8 Teszttervezési példa A következő vizsgálatokat, teszteket végezhetjük el: Három olyan számot adunk meg, amelyek egy érvényes háromszöget tesznek ki. Három olyan számot adunk meg, amelyek egyenlőek, vagyis egyenlő oldalú háromszöget alkotnak. Két egyenlő és egy ettől különböző számot adunk meg, melyek így egyenlő szárú háromszöget adnak. Olyan számokat adunk meg, amelyek közül kettőnek az összege kisebb, mint a harmadik szám. Olyan számokat adunk meg, amelyek közül kettőnek az összege egyenlő a harmadikkal. Három 0-t adunk meg. Olyan számokat adunk meg, melyek között nem egész szám is van. A három szám között negatívat is magadunk. 8

9 Teszttervezési példa A fenti vizsgálati esetek még egyáltalán nem elegendőek arra, hogy mindegyik elvileg lehetséges hibát fel tudják deríteni. Ami a tesztek megtervezésének kérdését illeti, erre vonatkozóan két alapvető megközelítés létezik: a funkcionális, valamint a strukturális. 9

10 A funkcionális tesztelés alapelve Funkcionális tesztelésről beszélünk akkor, amikor a programot egyedül csak a külső viselkedésében, az előírt funkcióinak teljesítésében vizsgáljuk. Egyáltalán nem vesszük figyelembe a forráskódot. Szokás még ezt a megoldást fekete doboz, vagy vasdoboz tesztelésnek is nevezni (angolban black-box testing, iron-box testing). 10

11 A strukturális tesztelés alapelve Strukturális tesztelésről beszélünk akkor, amikor a szoftver forráskódjának felhasználásával a belső struktúra, a belső működés végigkövetésére irányul az ellenőrzés. Ebben a megközelítésben a tesztelési adatok megtervezése során az a cél, hogy a forráskód utasításainak és elágazásainak minél alaposabb végigjárását tudjuk elérni. Szokás még a fehér doboz, vagy üvegdoboz tesztelés elnevezések használata is. (Angolul: white-box testing, glass-box testing.) 11

12 A strukturális tesztelés alapelve A strukturális teszteléssel a program minden egyes utasításának a végrehajtását, a döntési elágazások lehetséges végrehajtásait, valamint a ciklusok végrehajtását kell ellenőrizni. A kódbejárás tárgyalását megkönnyíti az ún. vezérlési folyamatgráf (VFG) (angolul: control-flow graph, CFG). 12

13 A tesztelés pszichológiája A tesztelés célja Helytelen definíciók Annak bizonyítása, hogy nincsenek a programban hibák. Annak bizonyítása, hogy a program a neki szánt funkciókat helyesen hajtja végre. Helyes definíció A tesztelés célja a program olyan végrehajtása, amelyben a szándékunk a hibák megtalálása. 13

14 A tesztelés gazdaságossága Van-e mód arra, hogy az összes hibát megtaláljuk? Nincs funkcionális megközelítés - kimerítő inputtesztelés strukturális megközelítés - kimerítő úttesztelés 14

15 Tesztelési elvek Egy tesztnek szükséges része az elvárt kimenet vagy eredmény definiálása. Célszerű a tesztelést a fejlesztéstől független személy vagy szervezet által elvégeztetni. A teszteket nemcsak elvárt és érvényes bemeneti feltételekre kell írni, hanem olyan feltételekre is, amiket nem várunk el, ill. amik érvénytelenek. Annak a valószínűsége, hogy egy programszakaszban még hibák léteznek, egyenesen arányos az ugyanott már megtalált hibák számával. A tesztelés igen kreatív tevékenység, és komoly szellemi kihívást jelentő feladat. 15

16 Megmaradt és a megtalált hibák További hibák létezésének valószínűsége Megtalált hibák száma 16

17 A teszttervezés kulcskérdése Az összes lehetséges teszt mely részhalmaza detektálja a legnagyobb valószínűséggel a legtöbb hibát? A legkisebb hatékonyságú metodológia minden bizonnyal a véletlenszerű tesztelés. Előtérbe helyezzük a determinisztikus úton történő tervezést: észszerűen szigorú tesztfolyamat a fekete dobozos kezelésmódban kiegészítéseként pedig egy olyan folyamat, amely a program belső logikáját is végigköveti, a fehér dobozos módban 17

18 Funkcionális tesztelési módszerek Ekvivalencia partícionálás Határérték-analízis Ok-hatás-analízis Véletlenszerű tesztgenerálás 18

19 Ekvivalencia partícionálás A célunk a lehetséges bemeneti adatok olyan részhalmazát képezni, amely a legnagyobb valószínűséggel a legtöbb hibát fedi fel. Egy jól megválasztott teszt két másik tulajdonsággal is rendelkezik: Egynél többel redukálja azon más teszteknek a számát, amelyeket azért kellene kialakítani, hogy egy észszerű, hatékony tesztelést érjünk el. Más lehetséges tesztek nagy halmazát fedi le, vagyis képes azokat helyettesíteni. 19

20 Ekvivalencia partícionálás A program input adatainak tartományát ún. ekvivalencia osztályokba csoportosítani, partícionálni. Egy adott osztályhoz tartozó teszt adatértékei ekvivalensek a teszt bármelyik más adatértékeivel Ha az ekvivalencia osztály egy tesztje detektál egy hibát, az osztály minden tesztjétől azt várjuk el, hogy ugyanazt a hibát legyen képes detektálni. Ha egy teszt nem fed fel egy hibát, akkor azt várjuk el, hogy az ekvivalencia osztály más tesztjei sem fogják ezt a hibát felfedni. Kivéve azt az esetet, amikor különböző ekvivalencia osztályok átfedik egymást. 20

21 Ekvivalencia osztályok meghatározása Az ekvivalencia osztályok keresése heurisztikus folyamat. Két típusú ekvivalencia osztályt kell keresnünk: érvényeset, amelyben érvényes bemenetek vannak érvénytelent, amelyben érvénytelen, hibás bemeneti adatok vannak 21

22 Ekvivalencia osztályok meghatározása Ha egy bemeneti feltétel értéktartományt ír elő, akkor egy ebbe eső érvényes osztályt, továbbá egy vagy több nem ebbe eső érvénytelen osztályt válasszunk. Ha egy tételnek adott számú változata lehet, akkor két érvénytelen osztályt adhatunk meg: egyet a 0-ra, egyet pedig az adott számnál nagyobbra. 22

23 A tesztek meghatározása Mindegyik ekvivalencia osztályhoz saját azonosító számot rendelünk. Az érvényes ekvivalencia osztályokhoz úgy válasszunk teszteket egymás után, hogy egy-egy teszt minél több osztályt tudjon képviselni, más szóval lefedni. Célunk az összes osztály lefedése teszttel. Az érvénytelen ekvivalencia osztályokhoz egyenként válasszunk tesztet úgy, hogy az csak egyetlen osztályt fedjen le. A cél itt is az összes osztály lefedése. 23

24 Ekvivalencia osztályok lefedése tesztekkel a x1 d [a,b) [b,c) [c,d] e x2 g [e,f) [f,g] 24

25 Határérték-analízis A tapasztalatok szerint azok a tesztek, amelyek a határértékekre vonatkozó feltételeket írnak elő, kifizetődőbbek, mint azok, amelyek nem. A határérték-analízis két szempontból különbözik az ekvivalencia felosztástól: Egy ekvivalencia osztályt tekintve annyi számértéket tartalmaz, amennyire szükség van az osztály mindegyik határértékének a vizsgálatához. Egy ekvivalencia osztálynak ugyanis több határértéke is lehet. Nemcsak a bemeneti feltételekre kell koncentrálni, hanem a kimenetiekre is, ahol a kimeneti ekvivalencia osztályok határértékeit vesszük számításba. 25

26 Határérték-analízis Ha egy bemeneti feltétel értéktartományt tartalmaz, akkor teszteket írunk a tartomány széleire, továbbá érvénytelen bemenetű teszteket, a szélsőértékeket minimálisan túllépve. Ha egy bemeneti feltétel fix számú értéket enged meg egy változózóra, a minimumra, a maximumra, továbbá alatta és felette érdemes egy-egy értéket megadni. Ha egy program inputja vagy outputja sorrendezett halmaz (pl. egy szekvenciális fájl, lineáris lista, táblázat), akkor szenteljünk figyelmet a halmaz első és utolsó elemének. 26

27 Határérték-analízis tesztesetek a x1 b c x2 d 27

28 Ok-hatás-analízis Az ekvivalencia partícionálásnak és a határérték-analízisnek az a közös hiányossága, hogy nem vonják be a vizsgálatba a bemeneti feltételek kombinációit. Az ok-hatás-analízis olyan technika, amely eredményes tesztek szisztematikus kiválogatását teszi lehetővé. 28

29 Ok-hatás-analízis Az eljáráshoz Boole-algebrai formalizmust használunk fel. Szokásos alapműveletek: ÉS, VAGY, valamint NEM A műveletekhez az őket megjelenítő logikai kapukat, ill. a kapukból felépülő kombinációs logikai hálózat gráfreprezentációját, az ún. Boolegráfot használjuk. 29

30 Az ok-hatás Boole-gráfjának jelölései NEM a b a ÉS c ^ a VAGY v c b b 30

31 Ok-hatás-analízis A tesztek leszármaztatása a szoftver-specifikáció alapján történik: A specifikáció felbontandó kisebb, feldolgozható részekre. A specifikációban egy ok nem más mint egy bemeneti feltétel vagy egy bemeneti ekvivalencia osztály. Egy hatás a kimeneti feltételben nyilvánul meg. A specifikáció szemantikus tartalmát elemezve létrehozzuk a Boole-gráfot, ok-hatás gráf A gráfhoz még hozzá kell rendelnünk azokat a kiegészítő megszorításokat, amelyek meg nem engedett okok és hatások kombinációját foglalják magukba. A gráf állapotfeltételeinek módszeres végigkövetésével a gráfot egy ún. döntési táblázatba konvertáljuk át. 31

32 Ok-hatás-analízis példa Az 1-es oszlopban levő karakter A vagy B kell legyen. A 2-es oszlop karaktere csak számjegy lehet. Ezzel a megadással fájl-frissítés (update) hajtódik végre. Ha az első karakter helytelen, az X12 üzenet jelenik meg, ha a második helytelen, akkor pedig az X13 üzenet. 32

33 Ok-hatás-analízis példa Az okok a következők: (1) Az 1-es oszlop karaktere A. (2) Az 1-es oszlop karaktere B. (3) A 2-es oszlop karaktere számjegy. A hatások a következők lesznek: (71) Frissítés hajtódik végre. (72) Az X12 üzenet jelenik meg. (73) Az X13 üzenet jelenik meg. 33

34 Ok-hatás-analízis példa 1 2 v 4 72 ^ 71 g

35 Ok-hatás-analízis példa A gráf alapján a létrehozandó ún. döntési táblázat valójában nem más mint a gráf által képviselt logikai hálózat igazságtáblázata. Meghatározzuk azokat a bementi 0-1 kombinációkat, amelyek a logikai hálózatban 1-es kimeneti értékeket produkálnak. A döntési táblázatban mindegyik bemeneti okhoz, ill. mindegyik kimeneti hatáshoz egy-egy sor tartozik. 35

36 Ok-hatás-analízis példa Döntési táblázat 36

37 Funkció lefedés Funkcionális módszereket mindenképpen célszerű egymással kombinálni. A különböző teszteknek és az általuk vizsgált funkcióknak a kapcsolatát az ún. tesztlefedési mátrixon lehet össszesíteni. Ha az i-edik teszt a j-edik funkció ellenőrzésére alkalmas, akkor a mátrixban ezt sötétített kockával ábrázoljuk. 37

38 Tesztlefedési mátrix Vizsgált funkciók Teszt

39 Véletlenszerű tesztgenerálás A hibafelfedő képessége meglehetősen korlátozott a determinisztikusan előállított tesztekhez képest. Véletlen számok előállítása és bemeneti adatként való felhasználása elhanyagolható számítási ráfordítással jár. nagy számú, nagy tömegű tesztadat A random tesztek olyan hibák felfedését is eredményezhetik, amelyek a determinisztikus teszttervezésnél elkerülték a figyelmet. 39

40 Véletlenszerű tesztgenerálás A véletlen számok előállításának folyamata Határozzunk meg mindegyik bemenő adathoz egy olyan számtartományt, amelyen belül a véletlen számok képzését akarjuk elvégezni. Az egyes adatokhoz képezzük a saját tartományukon belül eső, normális eloszlású random számokat, amelyek a bemeneti tesztadatok lesznek. A szoftverre adott teszteket két módon szervezhetjük Egy vagy annál több, de nem mindegyik adat változik random módon, a többi rögzített értéken áll. Mindegyik adat változik a saját tartományán belül. 40

41 Véletlenszerű tesztgenerálás A tesztválaszok meghatározása random inputok esetén külön meggondolást igényel Az egyes tesztszámok ismeretében magunk határozzuk meg az elvárt válaszreakciókat. Ha automatizáltan küldjük a szoftverre a random teszteket, a feladatunk abból áll, hogy azt döntsük el, hogy nem történt-e valamilyen észrevehető rendellenes megnyilvánulás. A random bemeneti értékekre adott válaszadatok kiszámítása a szimulációs szoftvernek a feladata. 41

42 Hibamodell strukturális tesztelés esetén A szoftver hibák forrása igen változatos: megkülönböztethetünk specifikációs, tervezési, kódolási stb. hibákat. A hibamodell adjon lehetőséget a lehetséges hibák szisztematikus (algoritmikus) kezelésére Az egyes hibamodellek a feltételezhető szoftver hibáknak csak egy részhalmazát fedik le. 42

43 SZOFTVER-MINŐSÉGBIZTOSÍTÁS Hibamodellek által lefedett hibák 43

44 A strukturális tesztelés alapjai A szoftver hibák általában a vezérlési szerkezetet érintik. Ez a kijelentés a gyakorlati eseteknek csak egy részében helytálló. A strukturális teszteléskor (ST) a tesztelő lényegében nem foglalkozik a felderítendő hiba természetével. A strukturális teszteléskor a tesztelő lényegében nem foglalkozik a felderítendő hiba természetével. A tesztelő azt feltételezi, hogy a programban létrejövő hibák valamilyen módon befolyásolják a a vezérlési szerkezet működését (a folyamat vezérlési gráf bejárását). 44

45 A tesztelés menete ST esetén A ST, mint a többi tesztelés módszer is két fázisra bontható: A tesztgenerálás teszt bemenetek generálását jelenti valamilyen mértékszám alapján. A mértékszám annak jellemzésére szolgáló számszerű paraméter, hogy a generált teszt bemenetek mennyire alaposan vizsgálják meg az egyes kódrészleteket. A teszt végrehajtása lényegében nem más, mint a program egy vezérlési ágának végrehajtása. A teszteléshez hozzátartozik a program kimeneteinek, eredményeinek összehasonlítása a specifikációban rögzítettel. Strukturális tesztelés esetén a kimenetek vizsgálatán túl szükséges a vezérlési szerkezet végrehajtott vezérlési ágának azonosítása is. 45

46 A strukturális tesztelés előnyei ST segítségével hibákat kereshetünk anélkül, hogy tudnánk, milyen szoftver hibákat is keresünk. A tesztelés hatékonyságának mérésére számszerű mértékszámokat lehet használni. A teszthalmazokhoz társított mérőszámokat csak óvatosan szabad a teszthalmazok hibafedésének nevezni, hiszen az implicit hibamodell miatt ilyenről nehéz lenne beszélni. 46

47 A strukturális tesztelés felhasználása Vezérlés intenzív alkalmazások Tervezési hibák felderítése Szabványok szerinti tesztelés 47

48 A vezérlési szerkezet modellezése ST során a program vezérlési szerkezetét modellezük az ú.n. folyamat vezérlési gráf (FVG, Control Flow Graph - CFG) segítségével. A gráf pontok az utasításoknak feleltethetők meg. A gráf származtatása igen egyszerű, az egymás után végrehajtható utasításokat egy-egy irányított gráf él köti össze. 48

49 Control Flow Graph A gráfpontoknak két típusát különböztethetjük meg: Egyszerű (szekvenciális) gráf pont, amelyből egyetlen gráf él indul ki, és egy szekvenciális utasítást reprezentál. Elágazás gráfpont, amelyből egynél több gráf él indul ki, és egy elágazás utasítás (predicate statement) feleltethető meg neki. 49

50 Példa az FVG generálására START 1 1:mid = (low + high) / 2; 2:if (x == list[mid]) 3:found = 1; 4:if (x > list[mid]) 5:low = mid+1; 6:if (x < list[mid]) 7:high = mid; END 50

51 Utak az FVG-ben A programok végrehajtása is követhető, ill. szemléltethető, az FVG-segítségével. A program minden futtatáskor a belépési ponttól a kilépési pontig tató pont és élsorozatot sorozatot, egy ú.n. gráf utat jár be. AZ FVG elemzése alapján meghatározott utak nem mindegyike járható azonban be a valóságban. Mivel az elágazás uasításokban szereplő feltételek nem függetlenek egymástól, így egyes élek kiválasztása már meghatározhatja egy másik ág bejárását. 51

52 Utak az FVG-ben 1:mid = (low + high) / 2; 2:if (x == list[mid]) 3:found = 1; 4:if (x > list[mid]) 5:low = mid+1; 6:if (x < list[mid]) 7:high = mid; A kódban az egymast követő feltételek közül csak egy lehet igaz. A ténylegesen bejárható utakat vastagon szedtük

53 Programok vezérlési bonyolultsága A programok vezérlési szerkezetének bonyolultsága egymástól igen eltérő lehet. Ezért bevezettek egy, a programok vezérlési szerkezetének bonyolultságára jellemző számot az ún. ciklomatikus komplexitás-t (CK, Cyclonometric complexity). A ciklomatikus komplexitás az FVG-ben található független gráf utak maximális számát adja meg. Általánosan használt minimális tesztelési cél strukturális teszteléskor, hogy a teszthalmaz fedje le a független utak egy maximális (további független utakkal tovább már nem bővíthető) halmazát. 53

54 Független utak maximális halmaza Az ilyen utak halmaza nem egyedi, vagyis egy gráfhoz akár több ilyen tulajdonsággal rendelkező út halmazt (és persze teszthalmazt) tudunk generálni. Sajnos még az a könnyített állítás sem igaz, hogy az egyes halmazok számossága megegyezik a CK értékével. 54

55 Független utak maximális halmaza Független utak egy, tovább már nem bővíthető halmaza 55

56 CK számítása A CK az FVG egyszerű elemzése alapján kiszámítható: Használjuk a következő jelölést: G: gráf, V(G): CK, E: élek száma; N: pontok száma; P: elágazás utasítások száma. CK értékét két képlet alapján is meghatározhatjuk: V(G)= E-N+2 V(G)=P+1 (abban az esetben ad helyes eredményt, ha kettős elágazások vannak csak az FVG-ben) 56

57 CK számítása START END E=11; N=9; P=3; V(G)= E-N+2= =4; V(G)=P+1=3+1=4. 57

58 Egyszerű strukturális tesztgenerálási algoritmus FVG generálása a kód alapján. V(G) (CK) számítása az FVG alapján. Független utak maximális (CK darab utat tartalmazó) halmazának generálása. Bemenetek generálása a független utak bejárásához. 58

59 Egyszerű strukturális tesztgenerálási algoritmus A tesztgenerálás során a következő problémák adódhatnak: AZ FVG ciklikus, kört tartalmaz, így elvben a végtelen sok út generálható az adott FVG-hoz. Nem generálható olyan bemeneti kombináció, amely egy adott út bejárását eredményezné az FVG-ben. 59

60 Ciklusok tesztelése A programok vezérlési szerkezetében gyakoriak a ciklus utasítások. Ezek az FVG-ben körnek felenek meg. Elvben végtelen további utat tudok generálni, attól függően, hogy az adott kört hányszor járom be. 60

61 Ciklusok tesztelése 1: while (feltétel) 2: számláló++; 3:eredmény = számláló; START END

62 Ciklusok tesztelése Ennek a problémának a kezelésére egyetlen technika létezik: ciklus bejárásának limitálása. Minden FVG körhöz önkényesen, vagy a ciklus feltétel alapján egy egész számot rendelek, mely a kör bejárásának maximális száma lesz. Még nehezebb a helyzet, ha a ciklus utasítások egymásba ágyazódnak. Ekkor sajnos az utak száma (és ezzel együtt a szükséges tesztek száma is) exponenciálisan nő a ciklusok számával. 62

63 Tesztminőségi mérőszámok A mértékszám egy arányszám: megmutatja, hogy a kiválasztott szempont szerint a tesztelhető elemek (egységek, tételek) mekkora részét teszteltük le. Utasítás lefedettség Ág lefedettség (döntés lefedettség) Út lefedettség A tesztelés, teszt generálás célja minnél magasabb, lehetőleg 100%-os lefedettség elérése. 63

64 Lefedettségi elemzés (coverage analisys) Nagy szoftverek esetén nem mindegy, hogy az egyes teszteket milyen sorrendben hajtjuk végre. Akkor hatékony a tesztelés, ha a hibák nagy részét minél hamarabb felderítem, majd a tesztelés további részében találom meg egyre kisebb gyakorisággal a nehezen detektálható hibákat. 64

65 Hibafedés alakulása tesztelés során hibafedés hatékony tesztelés alacsony hatékonyságú tesztelés tesztelésre fordított idő (erőfeszítés) 65

66 Szoftverben maradó hibák szoftverben maradó hibák alacsony hatékonyságú tesztelés hatékony tesztelés tesztelésre fordított idő (erőfeszítés) 66

67 Utasítás lefedettség Az utasítás lefedettség definíciója: S(c)=s/S Ahol s a tesztelés során legalább egyszer végrehajtott utasítások száma, S pedig a program összes utasításának a száma. 67

68 Utasítás lefedettség int* p = NULL; if (feltétel) p = &variable; *p = 12; A fenti kódrészlet teljesen fedettnek tekintjük az utasítás lefedettség mértékszám szerint, akkor is, ha nincs olyan teszt, amely hatására a feltétel hamis értéket vesz fel. Viszont egyértelmű, hogy hibát okoz, ha futás során a feltétel hamis értéket kap. 68

69 Döntés lefedettség (ág lefedettség) Az döntés lefedettség definíciója: D(c)=d/D Ahol d az elágazás utasításokban szereplő feltételek (döntések) kimenetek tesztelés során bekövetkezett értékeinek száma, D pedig a program összes elágazás utasításában szereplő feltételek kimenetének lehetséges száma. 69

70 Döntés lefedettség (ág lefedettség) if ( feltétel1 && ( feltétel2 függvény1() ) ) utasítás1; else utasítás2; A fenti kódrészlet teljesen lefedett az ág lefedettség szerint, ha van egy olyan teszteset, ahol a feltétel1 IGAZ, feltétel2 IGAZ, valamint egy olyan teszteset, ahol feltétel1 HAMIS. Ebben az esetben pedig a függvény1() egyáltalán nem hívódott meg a tesztelés során, ami triviálisan nem alapos tesztelés. 70

71 Bool (feltétel) lefedettség Az Bool (feltétel) lefedettség definíciója: B(c)=b/B Ahol b az elágazás utasítások feltételeiben szereplő Bool-kifejezésekben a tesztelés során tesztelt bemeneti kombinációk száma, B pedig az elágazás utasítások feltételeiben szereplő Bool-kifejezésekben a lehetséges bemeneti kombinációk összes száma. A Bool (feltétel) akkor teljes, ha az elágazás utasítások feltételeiben szereplő Bool változók minden lehetséges kombinációt felvesznek a tesztelés során. 71

72 Út lefedettség Az út lefedettség definíciója: P(c)=p/P Ahol p az FVG-ben a tesztelés során bejárt (végrehajtott) utak száma, P pedig az FVG összes út száma. Az út lefedettség akkor teljes, ha az FVG-ben található összes út bejáródott a tesztelés során. 72

73 A módszerek összekapcsolása A teszttervezési módszerek egy teljes, összefüggő láncba kombinálhatók össze. A kombinálásnak az adja az értelmét, hogy önmagában egyik módszer sem elegendő. A célszerű stratégia abból áll, hogy először a funkcionális tesztek sorozatát hajtjuk végre, azt követően pedig a strukturális tesztekét. 73