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.

Az előadások a következő témára: "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."— Előadás másolata:

1 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!"

2 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

3 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 Nem megengedett bemenő adat esetén a helyesség nem mond semmit, de ha a program megbízható, akkor ilyenkor sem nyújthat helytelen szolgáltatást. n1 n12 n2

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

5 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

6 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

7 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

8 Az absztrakció és a tesztelés szintjei

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

10 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

11 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. Kódellenőrzés: Egy kis (legalább négy főből álló) csoport átnézi a követelmény-specifikációt, a részletes tervezési definíciókat, adatstruktúra terveket, tesztterveket, és a felhasználói dokumentációt. Ez egy rövid de nagyon hatékony vizsgálatot jelent, mert a terméknek csak egy kis része lehet az átvizsgálandó komponens. A formális program verifikáció matematikai módon bizonyítja, hogy a program konzisztens-e a specifikációban foglaltakkal. A matematika-alapú formális specifikációnak két előfeltételt kell betartania: - A programnyelv szemantikájának formálisan definiáltnak kell lennie. - A programot formálisan olyan jelölésrendszerben kell megadni, ami konzisztens a használt matematikai verifikációs technikával Mindamellett, hogy néhány munka formális nyelven van definiálva, a legtöbb nyelv szemantikája nincs formálisan definiálva. Ez azt jelenti, hogy legtöbb program esetében nem lehetséges a szigorú matematikai értelemben vett bizonyítás. Ezek a bizonyítékok két dolgot demonstrálnak: - A program kód logikailag konzisztens a program specifikációjával A program mindig befejeződik. A tisztaszoba szoftverfejlesztés a statikus verifikálási technikákon alapuló szoftverfejlesztési filozófia. Ezen technika célja egy hibamentes szoftver előállítása. Ez a megközelítés azon alapul, hogy a hibákat inkább elkerülni kell, mint detektálni, és kijavítani. Ez egy szoftvertesztelést megelőző pontos, formalizált a hibák felfedézére irányuló vizsgálati eljáráson alapul. A tisztaszoba fejlesztési technika jellegzetességei: · Formális specifikáció · Inkrementális fejlesztés: program növekmények külön, egymástól elszeparáltan vannak fejlesztve tisztaszoba technikával · Strukturális programozás: a programfejlesztési eljárás a specifikáció lépésről lépésre történő finomítása · Statikus verifikálás: matematikai alapú verifikálás · Statisztikai tesztelés: a beépített programnövekményeket statisztikusan teszteljük Nagy rendszerek fejlesztésében 3 csapat vesz részt: · Specifikációs csapat (Specification team): a rsz-specifikáció fejlesztéséért és nyomonkövetéséért ő a felelős. Ez a csapat készíti a felhasználó-központú specifikációt, valamint a verifikációhoz szükséges matematika specifikációt. · Fejlesztő csapat (Development team): a szoftver fejlesztéséért és specifikálásáért ők a felelősek. A fejlesztési eljárás során a szoftvert nem futtatják, és nem is fordítják · Igazoló csapat (Certification team): a statisztikus teszthez szükséges tesztesetek fejlesztéséért és ezek után a szoftver futtatásáért ők a felelősek. Ezek a tesztek formális specifikáción alapulnak. A teszteseteket a szoftver megbízhatóságának az igazolására használják. Ők döntenek arról, hogy mikor lehet a tesztelést befejezni. A nagy megbízhatóságú rendszerek fejlesztésekor ezt a technikát használják.

12 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és pl: x := a2-b2-(a+b)*(a-b) típuskeveredés függvény mellékhatással végtelen ciklus Láthatóság: Delphi példa (átlag) felhasználatlan változó: Delphi (6.0) felhasználatlan változó érték: Delphi (6.0)

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

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

15 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

16 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

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

18 Előnyök: Hátrányok: Módszerek:
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

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

20 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