Nyíregyházi Főiskola 1 Szoftvertesztelés Előadó: Dr. Nagy Mihály Előadó: Dr. Nagy Mihály WEB: WEB:

Az előadások a következő témára: "Nyíregyházi Főiskola 1 Szoftvertesztelés Előadó: Dr. Nagy Mihály Előadó: Dr. Nagy Mihály WEB: WEB:"— Előadás másolata:

1 Nyíregyházi Főiskola 1 Szoftvertesztelés Előadó: Dr. Nagy Mihály Előadó: Dr. Nagy Mihály WEB: http://zeus.nyf.hu/~nagym/ WEB: http://zeus.nyf.hu/~nagym/http://zeus.nyf.hu/~nagym/ Email: nagym@nyf.hu Email: nagym@nyf.hunagym@nyf.hu Dr. Kuki Ákos anyagának felhasználásával Dr. Kuki Ákos anyagának felhasználásával

2 Nyíregyházi Főiskola 2 Szoftvertesztelés Az a folyamat, mely vizsgálja, meghatározza a fejlesztett számítógépes szoftver Az a folyamat, mely vizsgálja, meghatározza a fejlesztett számítógépes szoftver helyességét helyességét teljességét teljességét biztonságát biztonságát minősé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). 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. 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!"

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

4 Nyíregyházi Főiskola 4 Megbízhatóság, robosztusság Annak a valószínűségével mérhető, hogy a program nem nyújt hibás szolgáltatást Annak a valószínűségével mérhető, hogy a program nem nyújt hibás szolgáltatást A megbízhatóság mértékét meghatározhatjuk a programban lévő rejtett hibák számának becslésével A megbízhatóság mértékét meghatározhatjuk a programban lévő rejtett hibák számának becslésével Erre egy lehetséges módszer a következő: Két azonos felkészültségű csapat keresi a rejtett hibákat. A programban n hiba van, ebből az egyik csapat n 1 -et, a másik pedig n 2 -őt talál meg. A közös hibák száma n 12. Erre egy lehetséges módszer a következő: Két azonos felkészültségű csapat keresi a rejtett hibákat. A programban n hiba van, ebből az egyik csapat n 1 -et, a másik pedig n 2 -őt talál meg. A közös hibák száma n 12. n n 12 n2n2n2n2 n1n1n1n1 Ha a két csapat azonos hatékonysággal dolgozik, akkor: n 12 /n 1 =n 2 /n és n 12 /n 2 =n 1 /n A megbízhatóság mértéke: 1/n= n 12 /(n 1 n 2 )

5 Nyíregyházi Főiskola 5 Fogalmak Error: people makes error. Synonym: ”mistake”. When people makes mistakes while coding, we call this mistakes ”bugs”. (tévedés, tévesztés) Error: people makes error. Synonym: ”mistake”. When people makes mistakes while coding, we call this mistakes ”bugs”. (tévedés, tévesztés) Fault: this is the result of an error. Synonym: ”defect” (bugs also good) Fault is a representation of an error. (hiba) Fault: this is the result of an error. Synonym: ”defect” (bugs also good) Fault is a representation of an error. (hiba) Failure: a failure occurs when a fault executes. (meghibásodás) Failure: a failure occurs when a fault executes. (meghibásodás) Incident: When undesirable or unexpected behavior occurs, we report it as an incident, rather than as a failure, until we can determine its true relationship to required behavior. (incidens) Incident: When undesirable or unexpected behavior occurs, we report it as an incident, rather than as a failure, until we can determine its true relationship to required behavior. (incidens)

6 Nyíregyházi Főiskola 6 Test: testing is obviously concerned with errors, fault, failures and incidents. A test is the act of exercising with test cases. 2 goals: Test: testing is obviously concerned with errors, fault, failures and incidents. A test is the act of exercising with test cases. 2 goals: to find failures to find failures to demonstrate correct execution to demonstrate correct execution Test case: A test case has an identity, and is associated with a program behaviour. A test case also has Test case: A test case has an identity, and is associated with a program behaviour. A test case also has set of inputs set of inputs preconditions preconditions actual input actual input list of expected outputs list of expected outputs postconditions postconditions actual output actual output

7 Nyíregyházi Főiskola 7 Validation: 'Are we building the right product‘ as defined by IEEE/ANSI, is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. azaz: 'A megfelelő terméket készítettük-e el?', tehát a fejlesztési ciklus végén elkészült szoftver a rendelő elvárásainak megfelel-e. Validation: 'Are we building the right product‘ as defined by IEEE/ANSI, is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. azaz: 'A megfelelő terméket készítettük-e el?', tehát a fejlesztési ciklus végén elkészült szoftver a rendelő elvárásainak megfelel-e. Verification: 'Are we building the product right?‘ as defined by IEEE/ANSI, is the process of evaluating a system or component to determine wheter the products of a given development phase satisfy the conditions imposed at the start of that phase. azaz 'Megfelelően készítettük-e el a terméket?', tehát az elkészített program helyesen működik-e. Ez mutatja, hogy a program megfelel-e a specifikációnak. Verification: 'Are we building the product right?‘ as defined by IEEE/ANSI, is the process of evaluating a system or component to determine wheter the products of a given development phase satisfy the conditions imposed at the start of that phase. azaz 'Megfelelően készítettük-e el a terméket?', tehát az elkészített program helyesen működik-e. Ez mutatja, hogy a program megfelel-e a specifikációnak. Testing = verification plus validation Testing = verification plus validation

8 Nyíregyházi Főiskola 8 Hibák súlyosság szerint osztályozva 1. Mild (enyhe) Félrebetűzött szó 2. Moderate (mérsékelt)Félrevezető, vagy redundáns információ 3. Annoying (bosszantó)Megcsonkított nevek, 0.00$-os számla 4. Disturbing (zavaró) Néhány tranzakció nem lett feldolgozva 5. Serious (komoly)Elveszt egy tranzakciót 6. Very serious (nagyon komoly) Helytelen tranzakció végrehajtás 7. Extreme Nagyon komoly hibák gyakori előfordulása 8. Intolerable (nem tolerálható)Adatbázis elromlás 9. Catastrophic Rendszerleállás 10. Infectious Rendszerleállás, amely továbbterjed más rendszerekre

9 Nyíregyházi Főiskola 9 Az absztrakció és a tesztelés szintjei

10 Nyíregyházi Főiskola 10 Tesztesetnek a be- és kimeneti adatok és feltételek együttes megadását nevezzük. Tesztesetnek a be- és kimeneti adatok és feltételek együttes megadását nevezzük. A jó teszteset az, ami nagy valószínűséggel egy még felderítetlen hibát mutat ki a programban. Pl. két szám legnagyobb közös osztóját számoló programot az [5,5] adatpár után a [6,6]-tal teljesen felesleges kipróbálni. A jó teszteset az, ami nagy valószínűséggel egy még felderítetlen hibát mutat ki a programban. Pl. két szám legnagyobb közös osztóját számoló programot az [5,5] adatpár után a [6,6]-tal teljesen felesleges kipróbálni. A meg nem ismételhető tesztesetek kerülendők. A meg nem ismételhető tesztesetek kerülendők. Teszteseteket mind az érvénytelen, mind az érvényes adatokra kell készíteni. Teszteseteket mind az érvénytelen, mind az érvényes adatokra kell készíteni. Minden tesztesetből a lehető legtöbb információt „ki kell bányászni”, azaz minden teszteset eredményét alaposan végig kell vizsgálni. Ezzel jelentősen csökkenthető a szükséges próbák száma. Minden tesztesetből a lehető legtöbb információt „ki kell bányászni”, azaz minden teszteset eredményét alaposan végig kell vizsgálni. Ezzel jelentősen csökkenthető a szükséges próbák száma. Egy próba eredményeinek vizsgálata során egyaránt fontos megállapítani, hogy miért nem valósít meg a program valamilyen funkciót, amit elvárunk tőle, illetve, hogy miért végez olyan tevékenységeket is, amelyek nem feltételeztünk róla. Egy próba eredményeinek vizsgálata során egyaránt fontos megállapítani, hogy miért nem valósít meg a program valamilyen funkciót, amit elvárunk tőle, illetve, hogy miért végez olyan tevékenységeket is, amelyek nem feltételeztünk róla. A program tesztelését csak a program írójától különböző személy képes hatékonyan elvégezni. A program tesztelését csak a program írójától különböző személy képes hatékonyan elvégezni.

11 Nyíregyházi Főiskola 11 Statikus tesztelés a hibák futtatás előtti detektálása a hibák futtatás előtti detektálása a programkód vizsgálatán, és analízisén alapul a programkód vizsgálatán, és analízisén alapul csak a program és a specifikációja közti kapcsolatot tudja ellenőrizni csak a program és a specifikációja közti kapcsolatot tudja ellenőrizni nem tudja demonstrálni, hogy a program működésileg helyes-e vagy nem nem tudja demonstrálni, hogy a program működésileg helyes-e vagy nem költség- és időhatékony költség- és időhatékony

12 Nyíregyházi Főiskola 12 Statikus tesztelési módszerek Szintaktikus ellenőrzés Szintaktikus ellenőrzés Szemantikus ellenőrzés, ellentmondás keresés Szemantikus ellenőrzés, ellentmondás keresés Statikus program analizátor (Static program analysers): a kódban rejlő potenciális hibák felfedezésére. (Példa) Statikus program analizátor (Static program analysers): a kódban rejlő potenciális hibák felfedezésére. (Példa)Példa Kódellenőrzés: A forrásprogramot összevetjük a programtervvel (code review, inspection) Kódellenőrzés: A forrásprogramot összevetjük a programtervvel (code review, inspection) hatékony a programhibák feltárásában (hibák 60 %-a kiszűrhető) hatékony a programhibák feltárásában (hibák 60 %-a kiszűrhető) óránként 100 soros kódot lehet olvasni óránként 100 soros kódot lehet olvasni Matematikai alapú verifikáció (Matematically-based verification) Matematikai alapú verifikáció (Matematically-based verification) a hibák 90%-át detektálhatja a hibák 90%-át detektálhatja Tisztaszoba technika (Cleanroom software development): a hibákat inkább elkerülni kell, mint detektálni, és kijavítani. Tisztaszoba technika (Cleanroom software development): a hibákat inkább elkerülni kell, mint detektálni, és kijavítani.

13 Nyíregyházi Főiskola 13 Szemantikus ellenőrzés deklaráció, hatáskör, láthatóság hibái deklaráció, hatáskör, láthatóság hibái felhasználatlan változó felhasználatlan változó felhasználatlan változóérték felhasználatlan változóérték inicializálatlan változó (pl. Java) inicializálatlan változó (pl. Java) önmagának értékadás (felesleges vagy elírás) önmagának értékadás (felesleges vagy elírás) azonosan igaz vagy hamis feltétel (pl. C) azonosan igaz vagy hamis feltétel (pl. C) konstans értékű, változókat tartalmazó kifejezés pl: x := a 2 -b 2 -(a+b)*(a-b) konstans értékű, változókat tartalmazó kifejezés pl: x := a 2 -b 2 -(a+b)*(a-b) típuskeveredés típuskeveredés függvény mellékhatással függvény mellékhatással végtelen ciklus végtelen ciklus

14 Nyíregyházi Főiskola 14 Dinamikus tesztelés Két alapvető megközelítése van a tesztesetek meghatározásának: funkcionális tesztelés (fekete doboz) funkcionális tesztelés (fekete doboz) strukturális tesztelés (fehér doboz) strukturális tesztelés (fehér doboz)

15 Nyíregyházi Főiskola 15 Fehér-doboz tesztelés (strukturális tesztelés) A program viselkedését összeveti a forráskód „szándékával” 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. 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 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 Tipikus, ha a szoftver egy részét, modulját teszteljük Előny: Előny: A programozói hibák könnyen felismerhetők, mert az implementáció ismert. A programozói hibák könnyen felismerhetők, mert az implementáció ismert. Hátrány: Hátrány: A hiányos vagy hibás szoftverspecifikációt nem tudja felismerni. A hiányos vagy hibás szoftverspecifikációt nem tudja felismerni. Kódlefedés (code coverage) Kódlefedés (code coverage)

16 Nyíregyházi Főiskola 16 Kódlefedés (code coverage) A tesztadatokat úgy határozzuk meg, hogy a program forráskódjának minél nagyobb részét teszteljük. Egy mérőszám is egyben, mely megmutatja, hogy a forráskód hány százalékát teszteltük. utasításlefedés: mindegyik utasítás végrehajtódjon utasításlefedés: mindegyik utasítás végrehajtódjon döntéslefedés: minden döntés felvegye a neki megfelelő összes lehetséges értéket; feltétel: igaz/hamis, elágazás: valamennyi ág döntéslefedés: minden döntés felvegye a neki megfelelő összes lehetséges értéket; feltétel: igaz/hamis, elágazás: valamennyi ág feltétellefedés: valamennyi részfeltétel teljesülését ill. nem teljesülését is vizsgáljuk ( és, vagy operátorral elválasztott) feltétellefedés: valamennyi részfeltétel teljesülését ill. nem teljesülését is vizsgáljuk ( és, vagy operátorral elválasztott) többszörös feltétellefedés: a részfeltételek összes kombinációját vizsgáljuk többszörös feltétellefedés: a részfeltételek összes kombinációját vizsgáljuk útvonallefedés: a kód összes lehetséges útfonalán végighaladunk útvonallefedés: a kód összes lehetséges útfonalán végighaladunk

17 Nyíregyházi Főiskola 17 Nagy biztonsági követelményű szoftvereknél néhány kódlefedési mutató 100%-os értékének az elérése a cél Nagy biztonsági követelményű szoftvereknél néhány kódlefedési mutató 100%-os értékének az elérése a cél Az útvonallefedés magába foglalja az utasítás- és döntéslefedést Az útvonallefedés magába foglalja az utasítás- és döntéslefedést Teljes útvonallefedés nem praktikus vagy nem is lehetséges Teljes útvonallefedés nem praktikus vagy nem is lehetséges Az utasításlefedés nem foglalja magába a döntés- lefedést, pl: Az utasításlefedés nem foglalja magába a döntés- lefedést, pl: void foo(int bar) { printf("this is "); if (bar < 0) { printf("not "); } printf("a positive integer"); return; } Ha a függvényt a bar=-1 tesztadattal hívjuk meg, elérjük az utasítás- lefedést, a döntéslefedést viszont nem

18 Nyíregyházi Főiskola 18 A program viselkedését összeveti a specifikáció követelményeivel A program viselkedését összeveti a specifikáció követelményeivel Magát a programot fekete doboznak tekintjük. Magát a programot fekete doboznak tekintjük. A felhasználó szemszögéből vizsgálja a szoftvert A felhasználó szemszögéből vizsgálja a szoftvert A tesztelés menetét az adatok határozzák meg. 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. 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: Ismert: bemenetek bemenetek a várt kimenetek a várt kimenetek az egyetlen információ, melyet felhasználunk az a szoftver specifikációja. az egyetlen információ, melyet felhasználunk az a szoftver specifikációja. Nem ismert: Nem ismert: a fekete doboz tartalma (implementáció, hogyan is kódoltuk a programot). a fekete doboz tartalma (implementáció, hogyan is kódoltuk a programot). Fekete-doboz tesztelés (funkcionális tesztelés)

19 Nyíregyházi Főiskola 19 Előnyök: Előnyök: Független attól, hogy a szoftvert hogyan implementáltá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. 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: 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. 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: Módszerek: ekvivalencia osztályok (equivalence partitioning) ekvivalencia osztályok (equivalence partitioning) határeset vizsgálat (Boundary value analysis) határeset vizsgálat (Boundary value analysis) érvénytelen bemenet vizsgálata érvénytelen bemenet vizsgálata

20 Nyíregyházi Főiskola 20 Ekvivalencia osztályok (equivalence partitioning) Cél: Cél: a tesztesetek számának minimumra csökkentése a tesztesetek számának minimumra csökkentése a megfelelő tesztesetek kiválasztása a megfelelő tesztesetek kiválasztása Mivel minden adatra nem tudjuk kipróbálni a programot, ezért a lehetséges input adatokat csoportokra osztjuk (ekvivalencia-osztályok). Mivel minden adatra nem tudjuk kipróbálni a programot, ezért a lehetséges input adatokat csoportokra osztjuk (ekvivalencia-osztályok). Az ekvivalencia-osztályok elemei valamilyen szempontból azonosak Az ekvivalencia-osztályok elemei valamilyen szempontból azonosak Ha a program jól/rosszul működik az osztály egy adatára, akkor a többire is jó/hibás eredményt fog adni valószínűleg. Ha a program jól/rosszul működik az osztály egy adatára, akkor a többire is jó/hibás eredményt fog adni valószínűleg. Ezután az ekvivalencia-osztályok egy vagy néhány tagjával kipróbáljuk a programot. Ezután az ekvivalencia-osztályok egy vagy néhány tagjával kipróbáljuk a programot.

21 Nyíregyházi Főiskola 21 Példa 1. 40 karakteres szövegből számoljuk, hogy hány magánhangzót tartalmaz. Ekvivalencia osztályok: 0 hosszú string, 0 hosszú string, 40-nél hosszabb string, 40-nél hosszabb string, 1..40 hosszú, csak mássalhangzókból áll, 1..40 hosszú, csak mássalhangzókból áll, 1..40 hosszú, van magánhangzó is (csak 1, néhány, mindegyik). 1..40 hosszú, van magánhangzó is (csak 1, néhány, mindegyik). Példa 2 Példa 2