Szoftvertesztelés

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

2. 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!" Nyíregyházi Főiskola

3. 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 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 • 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 n1-et, a másik pedig n2-őt talál meg. A közös hibák száma n12. Ha a két csapat azonos hatékonysággal dolgozik, akkor: n12/n1=n2/n és n12/n2=n1/n A megbízhatóság mértéke: 1/n= n12/(n1n2) n n1 n12 n2 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) • 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) • 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) 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: • to find failures • to demonstrate correct execution • Test case: A test case has an identity, and is associated with a program behaviour. A test case also has • set of inputs • preconditions • actual input • list of expected outputs • postconditions • actual output 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. • 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 Nyíregyházi Főiskola

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

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

10. 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 meg nem ismételhető tesztesetek kerülendők. • 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. • 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. Nyíregyházi Főiskola

11. Statikus tesztelés • a hibák futtatás előtti detektálása • 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 • nem tudja demonstrálni, hogy a program működésileg helyes-e vagy nem • költség- és időhatékony Nyíregyházi Főiskola

12. Statikus tesztelési módszerek • Szintaktikus ellenőrzé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) • 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ő) • óránként 100 soros kódot lehet olvasni • Matematikai alapú verifikáció (Matematically-based verification) • 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. Nyíregyházi Főiskola

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

18. Fekete-doboz tesztelés (funkcionális tesztelés) • 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: • bemenetek • a várt kimenetek • az 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). Nyíregyházi Főiskola

19. 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 Nyíregyházi Főiskola

20. Ekvivalencia osztályok (equivalence partitioning) • Cél: • a tesztesetek számának minimumra csökkentése • 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). • 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. • Ezután az ekvivalencia-osztályok egy vagy néhány tagjával kipróbáljuk a programot. 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, • 40-nél hosszabb string, • 1..40 hosszú, csak mássalhangzókból áll, • 1..40 hosszú, van magánhangzó is (csak 1, néhány, mindegyik). Példa 2 Nyíregyházi Főiskola