Szoftver-minőségbiztosítás. Szoftver-tesztelési módszerek

Szoftver-minőségbiztosítás

Szoftver-tesztelési módszerek

Tesztelési 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. 2010.03.11.


2

Tesztelési alapfogalmak (folyt.) 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.

2010.03.11.


3

Tesztelési alapfogalmak (folyt.) 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. Tehát azt mondjuk, hogy a teszt kimutatja, felfedi, detektálja, vagy lefedi az adott hibát. 2010.03.11.


4

Tesztelési alapfogalmak (folyt.) Egy hiba tesztje: INPUT: Az összes lehetséges bemeneti adat halmaza. OUTPUT: Az összes lehetséges kimeneti adat halmaza. IH: A hibás működést okozó bemeneti adatok halmaza. OH: A hibás kimeneti adatok halmaza. 2010.03.11.


IH

Program

INPUT

(SW)

OH

OUTPUT

5

Tesztelési alapfogalmak (folyt.) Detektálható hiba: Egy hibáról akkor mondjuk, hogy detektálható, ha legalább egy tesztje létezik. (Tervezési redundancia folytán létezhetnek olyan hibák, amelyek semmilyen körülmények között nem éreztetik hatásukat a szoftver egészének működésében.) 2010.03.11.


6

Tesztelési alapfogalmak (folyt.) Tesztkészlet: Több hiba tesztjeinek együttese, halmaza. Tesztkészlet hibalefedése: Azon hibák százalékos aránya az összes feltételezett hibához képest, amelyeket a tesztkészlet detektálni tud. Vagy: Azon hibák százalékos aránya az összes feltételezett hibához képest, amelyeknek van tesztjük a tesztkészletben. 2010.03.11.


7

Tesztelési alapfogalmak (folyt.) Teljes tesztkészlet/teszthalmaz: Teszteknek olyan összessége, amely a szoftver mindegyik előre feltételezett és detektálható hibájának tesztjét magában foglalja. Az ilyen teszthalmazról azt mondjuk, hogy teljes hibalefedést eredményez. A teljes teszthalmaz 100 %-os hibalefedésű. 2010.03.11.


8

Tesztelési alapfogalmak (folyt.) Teszttervezés: A bemeneti tesztsorozat és az elvárt válaszjelek meghatározása egy előre feltételezett hibahalmazra nézve.

2010.03.11.


9

Tesztelési alapfogalmak (folyt.) 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. 2010.03.11.


10

Hibamodellek és érvényességi körük

Hibamodellnek nevezzük azoknak az előre feltételezett hibáknak a konkrét halmazát, amelyekre vonatkozóan a teszttervezést végre kívánjuk hajtani. Több fajta hibamodell létezik a gyakorlatban.

2010.03.11.


11

Egy hibamodell tervezésének főbb szempontjai

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


12

Szoftver hibamodellek Szoftver-specifikációs hibák Programozói hibák

2010.03.11.


13

Szoftver-specifikációs hibák A fejlesztés kezdetekor megjelenő hibák, amelyek a szoftver előre megadott, specifikált működési funkcióiban nyilvánulnak meg. Adódhat: Téves, ellentmondásos, hiányos specifikációból.

2010.03.11.


14

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

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.


15

Statisztikai felmérések

Minden hibát az eredete szerinti kategóriába sorolnak be. Feljegyzik az egyes hibák kijavítására fordított költséget. Megállapítják az egyes kategóriákba eső hibák számát, és a kategóriákat sorba rendezik, csökkenő sorrendben. Mindegyik kategóriához meghatározzák a teljes javítási költséget. A kapott adatok alapján megvizsgálják azokat a kategóriákat, amelyek a cég számára a legnagyobb költséget okozták. Terveket dolgoznak ki arra vonatkozóan, hogy miként módosítsák azokat a folyamatokat, amelyek a leginkább költséges kategóriákra vezettek.

2010.03.11.


16

Statisztikai felmérések (folyt.) Fejlesztési tevékenység

Hibák eredete (%)

Összesen (%)

Specifikálás

25%

25%

Programtervezés

Programkódolás

2010.03.11.

Logikai

20%

Adatkezelési

11%

Egyéb

7%

SW-interfész

6%

HW-interfész

8%

Felhasználói interfész

12%

Egyéb

11%


38%

37%

17

Szoftvertesztelés alapsémája Referencia (követelmény specifikáció, prototípus, rendszermodell stb.)

bemeneti sorozat

viselkedés, állapot megfigyelése

Tesztelt szoftver software under test, SUT

2010.03.11.

referencia kimenet

Értékelés (viselkedés, kimenetek összehasonlítása)

eredmény

SUT kimenet


18

Tesztek megtervezése Vegyünk egy egyszerű példát. Tegyük fel, hogy a következő funkciót teljesítő programot kell ellenőriznünk: A 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ú. 2010.03.11.


19

Tesztek megtervezése (folyt.)

A programon elvégezhető tesztek:

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.

2010.03.11.


20

Tesztek megtervezése (folyt.) Az előző vizsgálati esetek még egyáltalán nem elegendőek arra, hogy mindegyik elvileg lehetséges hibát fel tudják deríteni. Ebből is látható, hogy egy ilyen egyszerű program tesztelése sem könnyű feladat. Egy többszázezer utasításból álló szoftver megbízható leellenőrzése beláthatatlan bonyolultságú feladat. tervezni kell! 2010.03.11.


21

A teszttervezés alapvető megközelítései

funkcionális strukturális

2010.03.11.


22

Funkcionális tesztelés 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 azáltal, hogy a bementi adatokra kapott kimeneti válaszadatokat figyeljük meg. (fekete doboz tesztelés) 2010.03.11.


23

Funkcionális tesztelés (folyt.) Tesztelendő szoftver

Tesztinputok

Tesztoutputok

Fekete doboz

2010.03.11.


24

Strukturális tesztelés 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. (fehér doboz tesztelés) 2010.03.11.


25

Strukturális tesztelés (folyt.) Tesztelendő szoftver Tesztinputok

Tesztoutputok

Fehér doboz

2010.03.11.


26

Vezérlési folyamatgráf A tesztelő nem állít fel explicit hibamodellt a felderítendő hibákról, kizárólag a hibamentes program működését, vezérlési szerkezetét modellezi a folyamat vezérlési gráf (Control Flow Graph - CFG) segítségével. A strukturális tesztelés alapfeltételezése szerint a programban létrejövő hibák valamilyen módon befolyásolják a program vezérlési szerkezetét, mely a működést leíró folyamat vezérlési gráf gráfpontjainak, ill. éleinek hibás (nem megengedett) bejárását jelenti. A használt hibamodell tehát egy folyamat vezérlési gráf alapján felállított implicit hibamodell. 2010.03.11.


27

Vezérlési folyamatgráf (folyt.) A vezérlési folyamatgráf egy olyan irányított gráf, melyben minden egyes csomópont megfelel egy programutasításnak.

A

Soron köv. utasítások Döntési utasítás Feltétel nélküli elágazás Ciklus utasítás B

2010.03.11.


28

Vezérlési folyamatgráf (folyt.) Egymás utáni utasítások:

A

IF-THEN-ELSE:

B

A IF THEN

C

Ciklus:

ELSE

B

C

A CASE:

B

A

C

B C D D

2010.03.11.


29

Vezérlési folyamatgráf (folyt.) A gráf egyes csomópontjai között definiáljuk az út fogalmát: Az Si és Sj utasítások közötti út P(Si, Sj), az egymást követő csomópontok azon sorozata, amely Si-vel kezdődik és Sj-vel ér véget. Az Si és Sj között több lehetséges út létezhet. 2010.03.11.


30

Vezérlési folyamatgráf (folyt.) Si

A

D

B

E

C

F

Sj

G

H

P(Si – A – B – C – Sj), P(Si – D – E – B – C – Sj) P(Si – D – E – F – C – Sj) 2010.03.11.


31

Programok vezérlési bonyolultsága A programok vezérlési szerkezetének bonyolultsága igen eltérő lehet. A programok vezérlési szerkezetének bonyolultságát jellemző mérőszám, az ún. ciklomatikus komplexitás (CK).

2010.03.11.


32

Ciklomatikus komplexitás Független út: Olyan gráf út, amelyben létezik olyan pont vagy él, amely más útnak nem eleme. Ciklomatikus komplexitás definíciója: A VFG-ban található független gráf utak maximális száma. 2010.03.11.


33

Ciklomatikus komplexitás számítása Jelölés:

G: gráf; V(G): CK; E: élek száma; N: pontok száma; P: elágazás utasítások száma.

V(G)= E-N+2 V(G)=P+1 (bináris elágazások esetén) 2010.03.11.


34

Ciklomatikus komplexitás számítási példa begin

E=11 N=9 V(G)=E-N+2=11-9+2=4

1

2 3

P=3 V(G)=P+1=3+1=4

4 5 6 7 end

2010.03.11.


35

A programtesztelés pszichológiája (Glenford Myers)

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


36

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

2010.03.11.


37

Funkcionális megközelítés A háromszöges példa: az összes, a számítógépen létező egészszámot kellene a különböző hármas kombinációkban megadni. lehetetlen Egy C fordítóprogramnál például olyan teszteket kellene készítenünk, amelyben az összes érvénytelen C programot írjuk le, elvárva azt, hogy a kompájler mindegyiket érvénytelennek tudja nyilvánítani. lehetetlen Még súlyosabb a helyzet „memóriával” rendelkező programok esetén. Pl.: oprendszer esetén a munkafolyamatok vezérlése

2010.03.11.


38

Funkcionális megközelítés (folyt.) Az kimerítő inputtesztelés lehetetlen. Ebből két következtetést vonhatunk le: Nem lehet egy programot úgy tesztelni, hogy garantálni tudjuk annak hibamentes voltát. A tesztelés alapvető szempontja a gazdaságosság, vagyis annak elérése, hogy minél több hibát fedjünk fel egy véges számú vizsgálattal. 2010.03.11.


39

Strukturális megközelítés A példa folyamatgráfja mintegy 15-20 utasítást tartalmazó egyszerű programot képvisel. Tegyük fel, hogy az egyetlen DO-ciklus maximum 20-szor hajtandó végre. Az elkülönülő logikai utak számának meghatározása: az A pontból a B-be való eljutás különböző lehetséges módjainak megszámlálása. Független döntések esetén ez a szám 1014, vagyis 100 trillió lesz. 2010.03.11.


A

B

520 + 519 + 518 + … + 51 40

Strukturális megközelítés (folyt.) A valóságos programokban a döntési elágazások általában nem függetlenek egymástól, vagyis a bejárandó utak száma ezáltal kevesebb lesz. Azonban a valóságos programok jóval bonyolultabbak, mint a példában szereplő. Ebből látható, hogy a kimerítő úttesztelést sem lehetséges a gyakorlatban alkalmazni.

2010.03.11.


41

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


42

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

2010.03.11.


43

A teszttervezés kulcskérdése A szoftvervizsgálat legfontosabb összetevője és velejárója a hatékony tesztek megtervezése. A hatékonyság azért fontos, mert tudatában vagyunk annak, hogy nem lehetséges a meglevő összes hiba tesztjét előállítani. A kézenfekvő stratégia: amennyire csak lehetséges, csökkentsük a megmaradt hibák számát. 2010.03.11.


44

A teszttervezés kulcskérdése (folyt.) 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. 2010.03.11.


45

Szoftver-minőségbiztosítás. Szoftver-tesztelési módszerek

Recommend Documents