Verifikáció és validáció Általános bevezető
Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának és kielégíti a kliens igényeit Verifikáció: A szoftver megfelel-e specifikációjának? A rendszer eleget tesz-e a megadott funkcionális és nem funkcionális követelményeknek? Validáció: A szoftver kielégíti a kliens igényeit, megfelel a vásárló elvárásainak? Boehm megfogalmazása szerint (1979): Verifikáció: A terméket jól készítjük el? (Are we building the product right?) Validáció: A megfelelő terméket készítjük el? (Are we building the right product?) A folyamat lépései: követelményvizsgálat, a tervezés áttekintése, kódvizsgálat, a termék tesztelése. A szoftverfejlesztés minden szintjén szükség van V&V tevékenységekre
Átvizsgálás és tesztelés A rendszer elemzésére és ellenőrzésére két technika használható: Szoftverátvizsgálások (statikus V&V technikák): a követelményt leíró dokumentumok, a terv és ennek megfelelő diagrammok, a forráskód elemzése és ellenőrzése nem igénylik a program futtatását statikus V&V technikák Static V&V - software inspections A fejlesztési folyamat minden szintjén alkalmazhatóak, kiegészíthetőek automatikus elemzéssel Szoftvertesztelés (dinamikus V&V technikák) A szoftver implementációjának tesztadatokkal történő lefuttatása, a kimenetek futás közbeni viselkedésének vizsgálata A rendszer futtatható reprezentációjával dolgoznak dinamikus V&V technikák Dynamic V&V software testing Static verification Requirements specification High-level design Formal specification Detailed design Program Prototype Dynamic validation
Átvizsgálás Átvizsgálási technikák: Dokumentáció-, terv- és programátvizsgálások Automatizált forráskódelemzés Formális verifikáció Csak a specifikáció és a program közötti megfelelés ellenőrizhető nem ellenőrizhetőek a program nem funkcionális jellemzői (pl. teljesítmény vagy megbízhatóság), nem lehet kimutatni működésének hasznosságát Kritikus rendszereknél nagyobb hangsúlyt kap, egyre inkább elterjedt, de a V&V technikák közül továbbra is a programtesztelés az elterjedtebb
Tesztelés Két, a szoftverfejlesztés különböző szakaszaiban alkalmazható fajtája ismeretes: Hiányosságtesztelés: a program és annak specifikációja közötti ellentmondások felderítésére (melyek általában a programok hibáinak/hiányosságainak tulajdoníthatóak) Statisztikai tesztelés: a program megbízhatóságának és teljesítményének tesztelésére, ellenőrzésére hogyan teljesít a program működés közben. Nagyszámú, valós felhasználói bemenet a tesztek futtatását követően statisztikai becslést lehet készíteni a rendszer megbízhatóságával kapcsolatban a működési hibák/rendellenességek száma alapján
Elfogadási szint A V&V folyamat célja: megbizonyosodni arról, hogy a program a célnak megfelel ez nem azt jelenti, hogy a program tökéletes, egyáltalán nincsenek hiányosságai, hanem, hogy elég jónak kell lennie arra a célra, amire használni akarják. A szükséges elfogadási szint függ a rendszer céljától, felhasználóinak elvárásaitól, aktuális piaci környezetétől: Szoftverfunkció: a szoftver mennyire kritikus a szervezet számára (pl. a biztonságosság-kritikus rendszerek elfogadási szintje nagyobb) Felhasználói elvárások: az elvárási szint még ma is meglepően alacsony, de folyamatosan növekszik: a 90es évek óta a felhasználók rendszerhibákkal szembeni türelme folyamatosan csökken Piaci környezet: versenytársak és a felhasználók által kifizetett max. ár figyelembevétele
Debugging (belövés) A V&V folyamat során kiderülnek a program hiányosságai, így a programot módosítani kell a hibák kiküszöbölésének érdekében ezt nevezzük debugging-nak (belövési folyamatnak), melyet további V&V tevékenységekkel ötvözhetünk A debugging és a V&V különálló folyamatok, melyeket nem kell integrálni: A V&V annak megállapítására alkalmas, hogy a rendszerben vannak-e hiányosságok, hibák A belövés behatárolja és kijavítja ezeket a hiányosságokat Nincsen egyszerű, standard módszer a belövésre: a hibakeresők mintákat keresnek a teszt kimenetében, és a hiányosság típusának, a programozási nyelvnek, a programozási folyamatnak az ismeretében próbálják beazonosítani a hibát (ismerik a tipikus programozási hibákat, a programozási nyelvre jellemző hibákat, és azokat illesztik a megfigyelt mintákra)
Debugging (belövés) A hibák behatárolás nehéz: a hiba nem biztos, hogy pontosan ott van, ahol bekövetkezik a baj, a meghibásodás Interaktív belövő eszközök: a fordítórendszerrel integrált debugging segédeszközök, melyek speciális végrehajtási környezetet biztosítanak (hozzáférés változók értékeihez, lépegetés utasításról utasításra, stb.) Regressziós tesztelés: a javítások változtatásokkal járnak együtt, ez maga után vonja a program újra-átvizsgálásának, az előző tesztek megismétlésének szükségességét. a javítások lehet, hogy nem teljesek, vagy új meghibásodáshoz vezetnek elviekben az összes tesztet meg kellene ismételni, de ez túl költséges, ezért a gyakorlatban a tesztek tervezésénél meg kell határozni az egyes rendszerrészek és ezekhez rendelt tesztek közötti függőségeket így a módosított komponens és a tőle függő komponensek ellenőrzésére elegendő a futtatást csak a tesztadatok egy részhalmazára elvégezni
Verifikáció és validációtervezés Specifikáció, terv tesztek tervei (V modell) A fejlesztési folyamattal együtt kezdődik, tesztelési standardokat fogalmaz meg, egyensúlyt valósit meg a statikus és dinamikus technikák között Teszttervek: Tesztelési folyamat (a folyamat fő fázisainak leírása) Követelmények követése (minden követelmény külön le legyen tesztelve) Ütemezés (tesztelés ütemterve és erőforrások lefoglalása) Dokumentáló eljárások (a folyamat dokumentálása) Hardver és szoftverkövetelmények Megszorítások (a tesztelési folyamatot befolyásoló tényezők) Requirements specification System specification System design Detailed design Acceptance test plan System integration test plan Sub-system integration test plan Module and unit code and tess Service Acceptance test System integration test Sub-system integration test