Bánsághi Anna 1 of 67

Validáció

8. előadás

SZOFTVERTECHNOLÓGIA © Bánsághi Anna [email protected]

8. ELŐADÁS - VERIFIKÁCIÓ ÉS VALIDÁCIÓ

1 of 67

Validáció

8. előadás

TEMATIKA I. SZOFTVERTECHNOLÓGIA ALTERÜLETEI II. KÖVETELMÉNY MENEDZSMENT III. RENDSZERMODELLEK IV. RENDSZERARCHITEKTÚRÁK V. RENDSZERTERVEZÉS VI. VALIDÁCIÓ, VERIFIKÁCIÓ VII. MINŐSÉGBIZTOSÍTÁS VIII. TESZTELÉS

2 of 67

Validáció

8. előadás

VI. VALIDÁCIÓ, VERIFIKÁCIÓ 1. Felhasználói felületek tervezése 2. Verifikáció és validáció

3 of 67

Validáció

8. előadás

1. FELHASZNÁLÓI FELÜLETEK TER‐ VEZÉSE felhasználói kezelőfelület felhasználói kezelőfelületek tervezésének alapelvei a felhasználó és a rendszer kapcsolata az információ megjelenítése felhasználói támogatás felhasználói felületek értékelése

4 of 67

Validáció

8. előadás

FELHASZNÁLÓI KEZELŐFELÜLET a felhasználó a kezelőfelületen keresztül kerül kapcsolatba a rendszerrel, ennek alapján alkot véleményt, csak ezután ismeri meg a rendszer funkcionalitását a rosszul tervezett kezelőfelület gyakran katasztrofális hibákhoz vezet a szegényes vagy következetlen felhasználói kezelőfelület sok rendszer bukásához vezetett már nagy fejlesztő szervezetekben szakértőket alkalmaznak (grafikus, pszichológus, szakterületi szakértő), de kis/közepes cégeknél a kezelőfelület megtervezése is különleges tervezői feladat

5 of 67

Validáció

8. előadás

KONZOL ÉS GRAFIKUS FELÜLETEK konzol rendszerek csak alfanumerikus terminálokat alkalmaznak, a kezelőfelület karakteres parancsokat fogad grafikus nagyfelbontású, színes, grafikus felületet támogat. Az interakcióra nemcsak a klaviatúra, hanem egér vagy más kijelölő eszköz is rendelkezésre áll ALAPVETŐ ELVÁRÁSOK legyen strukturált, következetes, áttekinthető biztosítson segítő szolgáltatásokat a hibákat egyértelműen jelezze

6 of 67

Validáció

8. előadás

GRAFIKUS FELÜLET JELLEMZŐI ablakok / oldalak több ablakban / oldalon egyszerre többféle információ jeleníthető meg ikonok az ikonokkal az információ fajtái jelölhetők: állományok, folyamatok, stb. menük menütechnikával a parancsok egy strukturált menüből választhatók ki. A felhasználónak nem kell egy parancsnyelvet megtanulnia és parancsokat begépelnie pozícionálás egér, toll, érintés vagy más eszköz alkalmazható egy menüpont kiválasztására, vagy egy ablakban a lényeges elemek meg- vagy kijelölésére grafika / szinek grafikus elemek és színek alkalmazása a szöveg mellett (vagy helyett) áttekinthetőbbé teszik a képernyőt

7 of 67

Validáció

8. előadás

A GRAFIKUS KEZELŐFELÜLET ELŐNYEI könnyebben megtanulható és használható, akár számítógépes ismeretek nélkül is a felhasználó több képernyőt használhat az interakcióra, gyorsan válthat különböző alkalmazások között, az információ látható maradhat az éppen nem aktív ablakban is a felhasználó a teljes képernyő bármely részét elérheti, ez gyors interakciót tesz lehetővé

8 of 67

Validáció

8. előadás

FELHASZNÁLÓ-CENTRIKUS TERVEZÉS User Experience Design (UX Design) a felhasználó központú kezelőfelület-tervezés megköveteli, hogy a tervező: alaposan megismerje a felhasználó tevékenységét (a munkafolyamatot, amelyet a rendszernek támogatnia kell) és felkészültségét a felhasználót kezdettől bevonjuk a tervezés folyamatába először papíron, a struktúra felvázolásával, majd prototípusok készítésével tesszük számára megfoghatóvá és érthetővé a tervet

9 of 67

Validáció

8. előadás

A FELHASZNÁLÓI KEZELŐFELÜLET TERVEZÉSE

10 of 67

Validáció

8. előadás

A FELHASZNÁLÓI KEZELŐFELÜLETEK TER‐ VEZÉSÉNEK ALAPELVEI a kezelőfelület tervezésekor figyelembe kell venni a felhasználók igényeit, gyakorlatát és képességeit az emberek fizikai és mentális képességei korlátozottak (rövid távú memória), a felhasználói felület tervezésekor ezt is vegyük figyelembe a grafikus felhasználói felületek tervezésének alapelvei minden felhasználói interakció tervezésének alapjául szolgálhatnak

11 of 67

Validáció

8. előadás

TERVEZÉSI ALAPELVEK 1. felhasználói jártasság figyelembevétele a felületnek olyan kifejezéseket és fogalmakat kell használnia, amelyeket az átlagos felhasználó ismer a felület konzisztenciája a menüknek és parancsoknak ugyanazzal a formátummal kell rendelkezniük, hasonló műveleteket hasonló módon kell jelezni és megvalósítani minimális meglepetés a felhasználóban kialakul egy modell a rendszer működéséről. A hasonló tevékenységeknek hasonló hatást kell kiváltaniuk, különben a rendszer kellemetlen meglepetéseket okoz felhasználó számára

12 of 67

Validáció

8. előadás

TERVEZÉSI ALAPELVEK 2. visszaállíthatóság minden helyzetben számítsunk arra, hogy a felhasználó hibázhat, ezért gondoskodjunk arról, hogy a hibát kijavíthassa: visszavonási lehetőség (undo), esetleg többszintű veszélyes tevékenységek megerősítése (pl. törlés) „puha törlés” felhasználó támogatása a felület rendelkezzen könnyen elérhető segítő vagy súgó rendszerrel. A súgót struktúráljuk, nem szabad túl sok információt közölni. Előnyös a helyzetfüggő súgó alkalmazása felhasználók sokfélesége az alkalmi felhasználók több támogatást, a gyakorlott felhasználók egyszerűbb, gyorsabb működést várnak

13 of 67

Validáció

8. előadás

A FELHASZNÁLÓ ÉS A RENDSZER KAPCSOLATA egy interaktív rendszer tervezésekor két kulcskérdést kell megoldani 1. hogyan jusson el az információ a felhasználótól a rendszerhez 2. hogyan jusson el az információ a rendszertől a felhasználóhoz a felhasználói beavatkozás és az információ megjelenítése egy összefüggő keretrendszerbe integrálható, amely biztosíthatja a konzisztenciát és a felhasználói támogatást

14 of 67

Validáció

8. előadás

INTERAKCIÓK FAJTÁK közvetlen manipuláció menükiválasztás űrlapkitöltés parancsnyelv természetes nyelv

15 of 67

Validáció

8. előadás

KÖZVETLEN MANIPULÁCIÓ lényege a felhasználó közvetlenül a képernyőn látható objektumot kezeli (pl. törléshez kukába viszi) előnyök könnyen tanulható és gyors a felhasználó azonnal visszajelzést kap, így a tévedés gyorsan visszavonható hátrányok bonyolult lehet a felhasználó tevékenységéről (szándékáról) a megfelelő információt begyűjteni a program számára csak akkor használható, ha a feladatok és az objektumok egyértelműen megkülönböztethető ikonokkal reprezentálhatók

16 of 67

Validáció

8. előadás

MENÜKIVÁLASZTÁS lényege a felhasználó a rendszer által felkínált (sokszor helyzetfüggő) listából választhat, a kijelölést egér vagy kurzormozgatással, rövidített név beírással is végezheti előnyök alkalmazható érintőképernyős terminálokon is a felhasználónak nem kell parancsokat megjegyeznie kevés gépelést igényel, és a hibák könnyen kivédhetők állapotfüggő súgó alkalmazható hátrányok az akciók közötti logikai összefüggések (and, or) nem jeleníthetők meg kevés választási lehetőséget enged meg, a sok lehetőséghez struktúrált menüre van szükség a gyakorlott felhasználó számára lassú 17 of 67

Validáció

8. előadás

ŰRLAPKITÖLTÉS lényege az űrlap az aktuális állapothoz igazítható. Olyan rendszerekben alkalmazzák, ahol sok adatot kell bevinni (pl. adatrögzítés) előnyök a felhasználói hibák felfedhetők és jelezhetők, illetve kivédhetők könnyen megtanulható hátrányok nagy képernyőfelületet foglal

18 of 67

Validáció

8. előadás

PARANCSNYELV lényege a felhasználó parancsokat gépelve utasítja a rendszert előnyök egyszerű, olcsó terminálon is alkalmazható egyszerűen feldolgozható (pl. fordító technikával) bonyolult, egymásba ágyazott parancsok is kezelhetők rugalmas hátrányok nehezen tanulható, az átlagos felhasználó számára bonyolult gépelési gyakorlatot kíván a hibakezelést (hibajelzés, visszavonás) nehéz megoldani

19 of 67

Validáció

8. előadás

TERMÉSZETES NYELV a felhasználó a parancsokat természetes nyelven gépeli be, amelynek szótára korlátozott. Az ilyen rendszerek általában speciális alkalmazási területet szolgálnak ki a természetes nyelv megfelelő az alkalmi felhasználó számára, de a gyakorlott felhasználó nem kedveli a túl sok gépelés miatt

20 of 67

Validáció

8. előadás

TÖBBSZÖRÖS FELHASZNÁLÓI INTERFÉSZEK az eseti és a gyakorlott felhasználók számára külön felületet célszerű megvalósítani

21 of 67

Validáció

8. előadás

AZ INFORMÁCIÓ MEGJELENÍTÉSE a rendszer megjeleníti a felhasználó számára közlendő információkat ez az információ megjelenhet közvetlenül szöveges formában, grafikusan, animációval, hang kíséretében a jól tervezett rendszerekben maga az információ és az azt megjelenítő réteg különválik többféle alkalmazásarchitektúra létezik az információ, az alkalmazás logika és a megjelenítés hármasának szétválasztására

22 of 67

Validáció

8. előadás

MODEL VIEW CONTROLLER (MVC)

az MVC alkalmazásarchitektúrát a Smalltalkban dolgozták ki, de azóta általánosan elterjedt az interaktív rendszerek grafikus felhasználói kezelőfelületének tervezésében lényege, hogy különválasztja a az információt (az üzleti logikát), a megjelenítés vezérlését és a megjelenítést

23 of 67

Validáció

8. előadás

INFORMÁCIÓ TÍPUSOK STATIKUS értéket kap a munkafázis (session) kezdetén, és ez a session ideje alatt nem változik meg lehet numerikus vagy szöveges DINAMIKUS megváltozik a munkafázis alatt, és a megváltozott értéket a felhasználó számára meg kell jeleníteni lehet numerikus vagy szöveges

24 of 67

Validáció

8. előadás

A MEGJELENÍTÉS MÓDJÁNAK KIVÁLASZTÁSA A felhasználónak pontos információra van-e szüksége (numerikus), vagy különböző adatok közti kapcsolatok, arányok érdeklik (grafikus)? Milyen gyorsan változik az információ? Azonnal szükség van-e rá? (A gyorsan változó információt grafikusan, vagy többféle módon kell megjeleníteni?) Egy változást követően be kell-e avatkoznia a felhasználónak valamilyen akcióval? (Ha igen, a megváltozott információt ki kell emelni.) Szükség van-e közvetlen beavatkozási felületre? (Ha igen, az információ közelében kell erre lehetőséget adni.) Szöveges vagy numerikus a megjelenítendő információ? Fontosak-e a relatív értékek? (Ha igen, grafikus.)

25 of 67

Validáció

8. előadás

SZÖVEGES MEGJELENÍTÉS

26 of 67

Validáció

8. előadás

GRAFIKUS MEGJELENÍTÉS

27 of 67

Validáció

8. előadás

ANALÓG ÉS DIGITÁLIS MEGJELENÍTÉS DIGITÁLIS pontos értékeket közöl kevés helyet foglal a képernyőn ANALÓG egy pillantással áttekinthető relatív értékeket is képes közölni, pl. egy állandó értékhez képest (egy határhoz közeli értéket színnel még külön ki lehet emelni), vagy korábbi minimális-maximális értékhez képest

28 of 67

Validáció

8. előadás

FIGYELMEZTETŐ SZÖVEG MEGJELENÍTÉSE a figyelmeztetés megjelenítésekor a grafika kiemeli a fontos szöveget, az információ jellegére ikonnal is utalhatunk a szöveg és grafika mellett hang is használható a figyelem felkeltésére, amennyiben feltételezhető, hogy a felhasználók nagy része rendelkezik hangkártyával

29 of 67

Validáció

8. előadás

NAGY MENNYISÉGŰ ADAT MEGJELENÍTÉSE a megjelenítés felhívhatja a figyelmet a több forrásból származó adatok közti összefüggésekre, amelyek tendenciákra utalnak a tervezőnek ismernie kell a szakterületet, az ott alkalmazott jelölés- és ábrázolásmódokat

30 of 67

Validáció

8. előadás

ADATMEGJELENÍTÉSI MÓDOK időjárási információt célszerű térképen ábrázolni egy hálózat állapota a központokkal és kapcsolataikkal ábrázolható egy vegyi üzem állapota a csövek és tartályok hálózatán tehető jól áttekinthetővé a térbeli modellezésre (pl. molekula modellje) jól kezelhető grafikus eszközök állnak rendelkezésre

31 of 67

Validáció

8. előadás

SZÍNEK ALKALMAZÁSA a színek külön dimenziót kölcsönöznek a felületnek, segíthetnek a bonyolult összefüggések megértésében a különleges esetekre, értékekre felhívhatják a figyelmet ODA KELL FIGYELNI, HOGY a sokféle, rikító szín alkalmazása taszító lehet, fárasztja a szemet a rossz színkompozíció hibalehetőségeket okozhat a tervezőnek gondolnia kell arra, hogy sok ember színtévesztő vagy színvak

32 of 67

Validáció

8. előadás

SZABÁLYOK A SZÍNEK ALKALMAZÁSÁRA ne használjunk túl sok színt (egy felületen 4-5, egy rendszerben 7-8 az átlag) először tervezzünk monokróm felületeket, utána adjuk hozzá a színeket az állapotváltozásokat jelezzük színváltással a végrehajtandó feladatokat jelöljük színkóddal, a különböző feladatokat különböztessük meg színekkel is a színkódolást alkalmazzuk következetesen a teljes rendszerben egyes színkombinációk zavaróak vagy fárasztják a szemet

33 of 67

Validáció

8. előadás

FELHASZNÁLÓI TÁMOGATÁS a felhasználó támogatása kiterjed a rendszer minden megjelenési formájára: súgó, hibaüzenetek, kézikönyvek a felhasználó tájékoztatását be kell építeni a felhasználói felületekbe, hogy minden helyzetben kérhessen támogatást vagy kapjon információt, ha hibát vétett célszerű a súgó és az üzenő rendszert összeépíteni, hogy minden üzenetről magyarázatot kérhessen a felhasználó

34 of 67

Validáció

8. előadás

SÚGÓ ÉS ÜZENŐ RENDSZER

35 of 67

Validáció

8. előadás

HIBAÜZENETEK a hibaüzenetek tervezése különösen fontos: a kezdő felhasználó ezekkel találkozik a leggyakrabban. A rossz vagy számára érthetetlen hibaüzenetek miatt elutasíthatja a rendszert az üzeneteknek udvariasnak, előrevivőnek és következetesnek kell lennie a felhasználó háttere, gyakorlata a hibaüzenetek tervezésének meghatározó tényezője

36 of 67

Validáció

8. előadás

AZ ÜZENETEK SZÖVEGEZÉSE szövegkörnyezet a rendszer a felhasználó tevékenységéhez és a rendszer aktuális állapotához igazodó üzenetet adjon tapasztalat a tapasztalt felhasználót már idegesíti az a kifejtő magyarázat, amit a kezdő felhasználó még hasznosnak tart és igényel. A rendszer mindkét üzenettípust kínálja fel képzettség igazítsuk az üzeneteket a felhasználó képzettségéhez és gyakorlatához. A különböző felhasználók számára szánt üzeneteket különböző módon, a számukra érthető terminológiával fogalmazzuk meg stílus az üzenetek legyenek pozitívak. Egy üzenet soha ne legyen sértő, gúnyolódó kultúra hasznos, ha az üzenetek tervezője tisztában van azzal a kultúrával, ahol a rendszert használni fogják. Az egyik országban megfelelő üzenetek a kulturális különbségek miatt egy másik országban elfogadhatatlanok 37 of 67

Validáció

8. előadás

ROSSZ ÜZENETEK negatív szemléletű rendszerorientált, fejlesztőknek szóló hibáztat, nem javasol megoldást JÓ ÜZENETEK pozitív szemléletű felhasználó-orientált megoldást javasol

38 of 67

Validáció

8. előadás

SÚGÓ TERVEZÉSE a felhasználó segítségért vagy információért fordul a súgóhoz a súgó tervezésekor mindkét igényt figyelembe kell venni többféle lehetőséget kell biztosítani, ehhez több belépési pontra van szükség a jó súgórendszer hierarchikus szerkezetű, de bonyolult hálós struktúrájú, ahol az információs egységek között sokféle kapcsolat van több ablak alkalmazásával érthetővé tehető a bonyolult hierarchia

39 of 67

Validáció

8. előadás

A SÚGÓ INFORMÁCIÓTARTALMA a súgó nem lehet egy on-line kézikönyv a képernyő nem felel meg a papírlapoknak. Az emberek másként olvassák a képernyőt, mint a papírt a megjelenítés dinamikus természete segíti az információ megjelenítését a súgórendszer szövegeit az alkalmazást és a szakterületet jól ismerő embereknek kell megfogalmaznia

40 of 67

Validáció

8. előadás

A SÚGÓRENDSZER HASZNÁLATA több belépési pontra van szükség, hogy a felhasználó a rendszer különböző állapotaiból léphessen be ugyanakkor hasznos azt jelezni, hogy éppen hol jár a súgó hierarchiájában célszerű a korábban bejárt útvonalat is megjeleníteni, mert a bonyolult hálóban könnyen elvész a felhasználó. Ez a visszalépéseket is támogathatja

41 of 67

Validáció

8. előadás

SÚGÓRENDSZER BELÉPÉSI PONTJAI

42 of 67

Validáció

8. előadás

FELHASZNÁLÓI DOKUMENTÁCIÓ az on-line súgó mellett papíralapú dokumentációt is kell készíteni a rendszerhez a dokumentációnak a kezdőtől a gyakorlott felhasználóig mindenkit figyelembe kell vennie a különböző csoportba tartozó felhasználók számára legalább ötféle dokumentumot kell készíteni

43 of 67

Validáció

8. előadás

DOKUMENTUMTÍPUSOK funkcionális leírás a rendszer funkcióinak rövid leírása bevezető kézikönyv a rendszer helyes használatának leírása, sok példával referencia kézikönyv a rendszer lehetőségei, hibaüzenetek és teendők hiba esetén, minden esetre kiterjedően telepítési dokumentum a telepítés menete, a teendők listája, a beállítások ismertetése üzemeltetési-, adminisztrátori kézikönyv a rendszer működtetésének, a hibák kijavításának leírása

44 of 67

Validáció

8. előadás

FELHASZNÁLÓI FELÜLETEK ÉRTÉKELÉSE a szoftverrendszer ellenőrzésének, jóváhagyásának része a felhasználói felület elemzése a használhatóság ellenőrzésére szolgál (a használhatóság specifikációja alapján kellene végrehajtani, de ilyen dokumentum ritkán készül) az alapos értékelés nagyon sokba kerül, mert sok valódi felhasználót kell bevonni, laboratóriumi körülmények között megfigyelni, és véleményüket kiértékelni

45 of 67

Validáció

8. előadás

ÉRTÉKELÉSI MÓDSZEREK kérdőívek etnográfia a jellegzetes rendszerhasználat felvétele videóra felhasználói szemmozgások rögzítése felhasználói egérhasználat, billentyűhasználat rögzítése kódrészletek beépítése a gyakori hibák gyűjtésére

46 of 67

Validáció

8. előadás

A HASZNÁLHATÓSÁG JELLEMZŐI tanulhatóság mennyi idő alatt tudja egy új felhasználó produktív módon megtanulni a rendszer használatát műveleti sebesség mennyire felel meg a rendszer válaszideje a felhasználó munkatempójának robusztusság mennyire toleráns a rendszer a felhasználói hibákkal szemben visszaállíthatóság milyen jól áll helyre a rendszer a felhasználói hibák után adaptálhatóság mennyire van kötve a rendszer egy egyedi munkamodellhez

47 of 67

Validáció

8. előadás

ÖSSZEFOGLALÁS a felhasználói felületek tervezésekor mindenekelőtt a felhasználót tartsuk szem előtt. A felület legyen logikus, konzisztens és támogassa a felhasználót a hibák kijavításában grafikus megjelenítést akkor használjunk, ha megközelítő értékeket, trendeket szeretnénk bemutatni a színeket visszafogottan és következetesen alkalmazzuk a felület szolgáltasson on-line súgót is a hibaüzenetek legyenek pozitívak a felhasználói dokumentációkat különböző felkészültségű felhasználók számára készítsük

48 of 67

Validáció

8. előadás

2. VERIFIKÁCIÓ ÉS VALIDÁCIÓ A SZOFTVER VERIFIKÁCIÓJA ÉS VALIDÁCIÓJA a verifikáció és validáció folyamata programtesztelés A VERIFIKÁCIÓ ÉS VALIDÁCIÓ TERVEZÉSE szoftverek átvizsgálása programátvizsgálás automatizált statikus elemzés

49 of 67

Validáció

8. előadás

A SZOFTVER VERIFIKÁCIÓJA ÉS VALIDÁCIÓJA a szoftvernek azt kell megvalósítania, amit a felhasználó elvár tőle verifikáció annak ellenőrzése, hogy valóban a megfelelő terméket készítjük el, vagyis hogy a szoftver megfelel a specifikációnak („The product was built right”) validáció annak bizonyítása, hogy a terméket jól készítjük el, vagyis hogy a szoftver valóban a megrendelő elvárásainak megfelelően működik (esetleg a specifikációval ellentétesen) („The right product was built”)

50 of 67

Validáció

8. előadás

A VERIFIKÁCIÓ ÉS VALIDÁCIÓ FOLYAMATA (V&V) a verifikáció és validáció folyamata a szoftver teljes életciklusára kiterjed, a szoftverfejlesztési folyamat minden fázisában szerepet kap alapvető céljai felfedni a rendszerben rejlő hibákat meggyőződni arról, hogy a rendszer egy-egy konkrét működési szituációban használhatóan működik-e meggyőződni arról, hogy a rendszer a megrendelő igényeinek megfelelően készül-e/készült-e el

51 of 67

Validáció

8. előadás

STATIKUS ÉS DINAMIKUS VERIFIKÁCIÓ a V&V folyamatban kétféle technika alkalmazható szoftver-átvizsgálás (inspekció) a rendszer reprezentációjának elemzése (követelményspecifikáció, tervek, grafikus ábrázolások, forráskód). A forráskód elemzése automatizálható szoftvertesztelés a szoftver implementációjának tesztadatokkal való futtatása, és a viselkedés megfigyelése (dinamikus verifikáció)

52 of 67

Validáció

8. előadás

STATIKUS ÉS DINAMIKUS V&V

53 of 67

Validáció

8. előadás

PROGRAMTESZTELÉS még ma is a legelterjedtebb V&V technika (bár a szoftverfolyamat végén helyezkedik el) a hiba meglétét felfedezi fel, nem pedig a hiba hiányát az a sikeres teszt, amely legalább egy hibát felfedez az egyetlen módszer a nemfunkcionális követelmények validálására a statikus verifikációval (inspekció) együtt célszerű alkalmazni

54 of 67

Validáció

8. előadás

A TESZTEK TÍPUSAI hiányosságok tesztelése feladata a rendszer hibáinak és hiányosságainak felfedése, például egy interaktív rendszer esetén tesztelni kell a menükön elérhető összes funkciót egyazon menüponton elérhető valamennyi rendszerfunkciót a felhasználói inputok által használt összes függvényt, helyes és helytelen input adatokkal egyaránt statisztikai tesztelés a rendszer teljesítményének és megbízhatóságának tesztelése, valós helyzetekben (valós felhasználói inputtal és gyakorisággal)

55 of 67

Validáció

8. előadás

A VERIFIKÁCIÓ ÉS VALIDÁCIÓ CÉLJAI megbizonyosodni arról, hogy a szoftverrendszer megfelel a céljának (vagyis nem arról, hogy hibamentes!) az elfogadás szintje különböző célú rendszereknél különböző az elfogadást befolyásoló tényezők a szoftver funkciója (biztonsági rendszer vs. prototípus) a felhasználó elvárásai (olcsó szoftver – több hiba) piaci környezet (árak, versenytársak) kritikus rendszerek (ne okozzon tragikus eseményeket)

56 of 67

Validáció

8. előadás

TESZTELÉS ÉS BELÖVÉS a hiányosságok tesztelése és a belövés különböző folyamatok: a verifikáció és validáció feladata a hibák, hiányosságok létezésének felfedezése a belövés ezen hibák helyének lokalizálása és kijavítása a belövés a program viselkedésére vonatkozó feltételezések felállításával kezdődik, majd ezen feltételezések vizsgálatával próbálja megtalálni a hibákat a belövés során felfedezett hibák javítása után újra kell tesztelni a programot

57 of 67

Validáció

8. előadás

A BELÖVÉS FOLYAMATA

58 of 67

Validáció

8. előadás

VERIFIKÁCIÓ ÉS VALIDÁCIÓ TERVEZÉSE alapos tervezésre van szükség, hogy a legtöbb eredményt kapjuk az egyébként igen költséges tesztelésből és felülvizsgálatból a V&V tervezését a fejlesztési folyamat elején érdemes megkezdeni a tervn határozza meg az arányokat a statikus verifikáció és a tesztelés között a teszttervezésre a nagyobb cégeknél általános szabványokat, szabályokat dolgoznak ki. Ennek alapján kell megtervezni és végrehajtani a termék konkrét tesztelését, és a tesztek dokumentálását

59 of 67

Validáció

8. előadás

A TESZTELÉS ÉS A FEJLESZTÉS MODELLJE

60 of 67

Validáció

8. előadás

A SZOFTVER TESZTTERV STRUKTÚRÁJA a tesztelési folyamat, azaz a fő tesztfázisok leírása a követelmények nyomon követhetősége (minden követelményt külön kell tesztelni) a tesztelt elemek ( tesztelendő szoftver termékek listája) a tesztelés ütemezése (a szoftverfejlesztési projekt részeként) a tesztek dokumentálása (a tesztelés utólagos ellenőrzésére, minőségbiztosítására) a tesztek hardver és szoftver követelményei (a teszteléshez szükséges erőforrások) megszorítások (a tesztelést gátló tényezők)

61 of 67

Validáció

8. előadás

A SZOFTVER ÁTVIZSGÁLÁSA a szoftver átvizsgálás célja a hiányosságok felderítése, a költséges tesztelés helyett a hibák kb. 60 %-a felfedhető az átvizsgálás során a fejlesztési folyamat kezdetétől alkalmazható, a dokumentumok (követelmények, tervek) átvizsgálásával egy átvizsgálás során több hiányosság felfedezhető, amíg egy teszt többnyire egy hibát fed fel a tapasztalt vizsgálók (inspektorok) már ismerik és könnyen megtalálják a típushibákat

62 of 67

Validáció

8. előadás

ÁTVIZSGÁLÁS (INSPEKCIÓ) ÉS TESZTELÉS az inspekció és a tesztelés nem helyettesítik egymást, de a korai fázistól rendszeresen végzett átvizsgálás sok költséges tesztet előzhet meg érdemes mindkettőt alkalmaznia V&V folyamatban az inspekció alkalmas eszköz arra, hogy ellenőrizze azt, hogy a program megfelel-e a specifikációnak a nemfunkcionális rendszerkövetelmények vizsgálatára azonban a felülvizsgálat nem használható

63 of 67

Validáció

8. előadás

PROGRAMÁTVIZSGÁLÁS a dokumentumok átvizsgálásának formalizált eszköze: tapasztalt szakemberek nézik át a dokumentumokat és a kódot, ellenőrző lista alapján célja a hiányosságok felderítése a forráskódban (logikai hibák, kezdőérték nélküli változók, szabványoknak való meg nem felelés, stb.) az átvizsgálást követően a programozó módosítja a programot, az új verziót nem kell feltétlenül újravizsgálni

64 of 67

Validáció

8. előadás

AUTOMATIZÁLT STATIKUS ELEMZÉS a statikus elemzők a forráskódot vizsgáló szoftvereszközök nem futtatják a programot, hanem elemzik a program szövegét FÁZISAI a vezérlés folyamatának elemzése az adatok használatának elemzése interfész-elemzés az információáramlás elemzése a végrehajtási útvonalak elemzése

65 of 67

Validáció

8. előadás

STATIKUS ELEMZŐK HASZNÁLATA a statikus elemzés különösen az olyan nyelveknél hasznos, mint a C, amelyek nem tartalmaznak szigorú szabályokat a típusokra, így a fordító sok hibát nem vesz észre elemző eszközök: SonarQube, FxCop, NDepend, Lint, Checkstyle, PMD

66 of 67

Validáció

8. előadás

ÖSSZEFOGLALÁS a verifikáció és a validáció két különböző tevékenység a verifikáció a specifikációnak való megfelelést vizsgálja a validáció bizonyítja, hogy a rendszer megfelel a felhasználó igényeinek a tesztelési folyamatot tervezni kell a statikus verifikációs technikák a szoftver vizsgálatát és elemzését is tartalmazzák a felülvizsgálat hatékony eszköz a hibák felderítésére a statikus elemző eszközök a forráskódban olyan rejtett hibákat keresnek, mint a nem iniciált változók, nem használt kódrészletek, kódklónok

67 of 67