7. Verifikáció, validáció
Boehm megfogalmazásában: Verifikáció: A terméket jól készítjük el? (a termék megfelel-e a specifikációnak, illetve a funkcionális és nem funkcionális követelményeknek)
A verifikáció és a validáció (V&V) azon ellenőrző és elemző folyamatok összessége, amelyek célja annak vizsgálata, hogy a szoftver megfelel a specifikációnak.
Validáció: A megfelelő terméket készítjük el? (a termék megfelel-e a vevő elvárásainak, ezért a validáció már a követelmények megfogalmazásánál kezdődik)
Ennek része a hagyományos értelemben vett szoftvertesztelés is.
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
A V&V végig követi a teljes fejlesztési folyamatot.
1
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
2
A szoftver verifiká verifikálásának, validá validálásának, nak, tesztelé tesztelésének helye a szoftverfolyamatban.
A V&V folyamaton belül 2 technika használható: 1., A szoftver átvizsgálások A rendszer fejlesztése során keletkező dokumentumok (követelmény-dokumentáció, tervek, ábrák, forrássorok, stb.) ellenőrzése. Ezek statikus technikák, mert szükséges hozzá a program futtatása (a korai szakaszban még nincs is program) 2., A szoftver tesztelések Az elkészült szoftver ellenőrzése különböző tesztadatok futtatásával. Ellenőrizzük a szoftver kimeneteit, a futás közbeni viselkedését és a teljesítményét. Ez ún. dinamikus technika, mivel a szoftver futtatását igényli.
Szoftver átvizsgálása
Követelmények specifikációja
Magasszintű terv
Formális specifikáció
Részletes terv
Szoftver
Szoftver tesztelése
Prototípus
I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
3
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
4
1
A tesztelések fajtái:
Átvizsgálási technikák: l Programátvizsgálások
l Hiányosságtesztelés
(célja a program és a specifikáció között meglévő hiányosságok felderítése. Célirányos, tervezett vizsgálat.)
l Automatikus
forráskód elemzés l Formális verifikáció
l Statisztikai
tesztelés (célja a program teljesítményének, megbízhatóságának vizsgálata. Tükrözniük kell a valós felhasználói bemeneteket és azok gyakoriságát. Becslés adható a megbízhatóságra a működés közben mért hibák alapján, illetve a teljesítményre a statisztikai tesztadatok feldolgozásánál rögzített paraméterek - pl.: futási idő, válaszidő, stb - alapján)
A statikus technikával csak a program és a specifikáció közötti megfelelőséget tudja vizsgálni. Így nem vizsgálható pl.: a megbízhatóság, teljesítmény. A tesztelés nem nélkülözhető. BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
5
BMF-NIK-SZTI
A „belö belövési” si” folyamat
Tick: Szoftver Tervezés és Technológia
6
A szoftver belö belövési folyamat
A V & V az a folyamat, amelyik megállapítja, hogy a szoftverben vannak-e hiányosságok. A belövés az a folyamat, amely behatárolja és kijavítja ezeket a hiányosságokat. Jellemzők: l Igen magas fokú nyelvi környezet ismeretet igényel l Nehezen algoritmizálható, szabályok nehezen adhatók meg l Speciális célszoftverek segíthetik a hiba megtalálását
Teszteredmények
Specifikáció
Hiba behatárolása
Hibajavítás megtervezése
Tesztesetek
Hiba kijavítás
Program újratesztelése
I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
7
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
8
2
A hiba behatárolását követően kijavítjuk, majd rendszert újra validáljuk. Ez lényegében a tesztek újbóli megismétlését jelent, amit szokás regressziós tesztelésnek nevezni. A regressziós tesztelés célja annak vizsgálata, hogy a hiba kijavítása során nem követtünk-e el újabb hibát. A regressziós tesztelés során elvben az összes tesztet megismételjük minden javítási lépés után. A gyakorlatban ez igen nagy ráfordítást igényelne, így csak a módosított rész és annak függőségeihez tartozó teszteseteket ismételjük meg. (Alapos teszt terv és dokumentáció szükséges ennek kivitelezéséhez) BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
9
Rendszerspecifikáció
Átvételi teszt terve
Szolgáltatás
Rendszertervezés
Rendszerintegrációs teszt terve
Átvételi teszt
Részletes tervezés
Alrendszerintegrciós teszt terve
RendszerIntegrációs teszt
Modul és EgységKódolás, és -tesztelés
AlrendszerIntegrációs teszt
I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
A V&V igen költséges folyamat, szükséges gondos megtervezése A teszttervek jellemzői: l Áttekintő képet ad a rendszer tesztelési folyamatról l Rendelkezik a felhasználható erőforrásokról l Kötelezően betartandó és irányadó szabványokat és eljárásokat tartalmaz a tesztelésre vonatkozóan l Ellenőrző listákat tartalmaz a tesztelők számára l Információt ad a fejlesztést és az implementálást végzők számára is BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
10
Szoftverek átvizsgálása
A teszttervek és s tesztelé tesztelési fá fázisok a szoftver folyamatban (lá (lásd: 3.4.2) Követelmények meghatározása
V & V tervezése
11
A szoftver átvizsgáláshoz nem kell programot futtatni, így a fejlesztés korai szakaszában, a programok implementációja előtt, verifikációs technikaként használható. Azonban kiterjedhetnek a szoftverfolyamat bármely dokumentumára: követelmény specifikáció, vázlatos és részletes tervekre, adattervekre, teszttervekre, stb. Mit vizsgálhatunk? l Rendszermodellt, Specifikációt, l Magas szintű nyelven megfogalmazott metakódot, l Bármilyen dokumentumot, mely a szoftverfolyamat része BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
12
3
A szoftverátvizsgálás jellemzői: l Sokkal olcsóbb a tesztelésnél l Az egyes programelemek elszigetelten vizsgálhatók l Elhanyagolhatók a hibák kölcsönhatásai l A hiba detektálása közvetlenül történik (nem valamilyen rossz értékből derül ki a hiba) l Egyes vizsgálatok szerint az átvizsgálás nem csak olcsóbb, hanem hatékonyabb is mint a tesztelés l Fagan szerint egy program hibáinak 60 százaléka felderíthető átvizsgálással l Az átvizsgálás során a minőség és a szabványoknak való megfelelőség is ellenőrizhető BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
lA
dinamikus viselkedés vizsgálatára, a megbízhatóság becslésére nem alkalmas az átvizsgálás l Működési hatékonyság, szűk keresztmetszet nem határozható meg segítségével l A felhasználói felület validálása nem végezhető el az átvizsgálás során l Rendszerszinten a bonyolultság miatt gyakorlatilag nem alkalmazható
13
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
14
Programátvizsgálások
Mi indokolja az átvizsgálások hatékonyságát? l Egyetlen átvizsgálással több különböző hiba is felderíthető, míg a tesztelés általában tesztenként csak egy hibát hoz ki. l A felhalmozódott tapasztalatok segítenek a kritikus részek ellenőrzésében. (Az átvizsgálást végző, rutinos szakember „tudja, hogy mit kell nézni”)
A programátvizsgálás lényege: egy különböző háttérrel rendelkező tagokból álló csoport a program forráskódját gondosan, sorról, sorra átnézi.
Kritikus programszerkezetek: Pointeres kezelés, több kilépési ponttal rendelkező ciklusok, bonyolult vezérlési szerkezetek
Az átvizsgálás egy formális folyamat, melyet egy, legalább 4 főből álló team végez.
Az átvizsgálás célja a hiányosságok, hibák felderítése
Az átvizsgálás nem helyettesíti a tesztelést, hanem kiegészíti azt! BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
15
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
16
4
Különböző szerepkörök definiáltak a csoportban Fagan szerint: – Szerző (a program vagy dokumentum elkészítésért és a hibák kijavításáért felelős) – Olvasó (felolvassa, illetve elmagyarázza a kódot vagy dokumentumot) – Tesztelő (a tesztelés szempontjából vizsgálja a kódot) – Moderátor (az átvizsgálás folyamatát szervezi, vezeti)
Az átvizsgá tvizsgálási folyamat Tervezés
Új verzió
Áttekintés Egyéni előkészítés
Átdolgozás
Felülvizsgálati találkozó
Grady és Van Slack, illetve Gilb és Graham egyéb funkciók bevezetését javasolták
I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
17
A programátvizsgálás hatékonyságának jellemzői: l Az áttekint szakasz során kb. 500 LOC/óra tekinthető át. l Az egyéni előkészület során kb. 125 LOC/óra vizsgálható meg l A találkozó során 90-125 LOC/óra vizsgálható át.
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
18
Automatizált statikus elemzés Az automatizált statikus programelemző szoftverek a program forráskódját analizálva derítenek fel hibákat, hiányosságokat. (pl: nem inicializált változók, nem használt változók, a tartományon túlmutató adatértékek) Az automatizált statikus elemzővel felismerhető hibák: (inicializálás, deklarálás, rossz értékadás, stb.) l Vezérlési hibák (hibás vezérlési szerkezetek, ciklusok, nem hívott függvények, eljárások, stb.) l Input/Output hibák (a típusnak nem megfelelő I/O form.) l Interfészhibák (paraméterek típusütközése, stb.) l Tárkezelési hibák (védett területre írás, stb.) l Adathibák
Az AT&T-nél gyűjtött adatok szerint: 4 fős csapat 100 LOC-ot kb 1 embernapnyi ráfordítással vizsgál át. l Ha átvizsgálás helyett tesztelnének, akkor több, mint a duplája ráfordításra lenne szükség. l Egy
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
19
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
20
5
A statikus elemzés szakaszai: 1., A vezérlés folyamatának elemzése (többszörös be, illetve kilépési ponttal rendelkező ciklusok vizsgálata, nem használt kódrészek felderítése, stb.) 2., Az adathasználat elemzése (inicializálás nélkül használt változók, kétszer ír egy változóba, de senki nem olvassa, deklarált, de fel nem használt változók felderítése) 3., Interfészelemzés (gyengén típusos nyelveknél használható, pl.: C, a függvény és eljárás deklarációval, paraméterekkel, visszatérési értékekkel kapcsolatos hibákat vizsgálja) BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
21
4., Az információáramlás elemzése (a bemenő és kimenő változók közötti függéseket deríti fel, a programban használt értékek származtatását gyűjti ki, ami segítséget nyújthat az átvizsgálásokhoz.) 5., Útvonalelemzés (azonosítja a program összes lehetséges végrehajtási útvonalát, és kigyűjti az ezeken az útvonalakon végrehajtott utasításokat.) Az automatizált statikus elemzőkre különösen azon nyelveknél van szükség, amelyek gyengén típusosak, vagy a fordítójuk kevés ellenőrzést végez. Nem helyettesíti az átvizsgálást, illetve a tesztelést, csak kiegészíti! BMF-NIK-SZTI
l Aláírás
pótlása: 2006. január 3. 9:00, F01 előadó (jelentkezés a dossziéban a III. emeleten január 2.-án 12 óráig)
l Vizsgák:
2006. január 5., 12., 19., 9:00, F01 előadó (jelentkezés a NEPTUN-ban) Tick: Szoftver Tervezés és Technológia
22
A vizsgák jellege
Vizsgaidőpontok
BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
23
l Aláírás
pótlása
– Különeljárási díjhoz kötött – A ZH-k hoz hasonló jellegű, 4 oldalas feladatlap – A teljes féléves anyagot tartalmazza – Kidolgozási idő 1 óra – Maximálisan elérhető 100 pont – Az aláíráshoz minimálisan szükséges 31 pont – Eredmények legkésőbb aznap estig a weben BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
24
6
l
Vizsga – 2 oldal a ZH-k hoz hasonló jellegű feladatlap (max. 30 pont) – 2 oldal terjedelemben kidolgozandó 1 témakör a kiadottak közül. (max. 40 pont) – Vázlatos tervezési feladat az órákon áttekintett példák alapján kb. 2 oldal terjedelemben (max. 30 pont) – Maximálisan elérhető: 100 pont. – Értékelés: 0 - 50 pont elégtelen 51 – 65 pont elégséges 66 – 80 pont közepes 81 – 90 pont jó 91 – 100 pont jeles – Kidolgozási idő 1,5 óra – Eredmények legkésőbb vasárnap estig a weben BMF-NIK-SZTI
Tick: Szoftver Tervezés és Technológia
25
7