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
Prototype
High-level design
Formal specification
Detailed design
Program
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 integration test plan
Acceptance test plan
Service
System design
Acceptance test
Detailed design
Sub-system integration test plan
System integration test
Sub-system integration test
Module and unit code and tess
