Szoftver min ség és menedzsment

Átírás

1 Szoftver min ség és menedzsment 15. Tesztelési módszerek, technikák Dr. Balla Katalin

2 Tartalom Miért tesztelünk? Mit tesztelünk és mir l ad információt a tesztelés? Mikor tesztelünk? Hogyan tesztelünk? A tesztelés (mai) problémái Tesztelési alapismeretek Tesztelési technikák Tesztelési módszerek, eszközök A tesztelés tervezése A tesztelés végrehajtása A tesztelés dokumentálása Dr. Balla Katalin Szoftver min ség és menedzsment

3 A tesztelés a rendszer próbafuttatása a valós m ködés szimulálása annak ellen rzése, hogy jól értettük-e a követelményeket? annak ellen rzése, hogy a követelmények mindegyikének van-e megfelel je a modellekben? a dokumentáció / kód átolvasása... Dr. Balla Katalin Szoftver min ség és menedzsment

4 Miért tesztelünk? Mert az a tapasztalatunk, hogy a szoftverben hibák vannak, és ezek közül minél többet szeretnénk megtalálni, még miel tt a felhasználó találná meg ket, és miel tt bajt okoznának Tapasztalt programozók átlagban minden 10 forrássorban vétenek 1 hibát Ezen hibák felét a gépnyelvre történ fordításkor kijavítják A tesztelés során további hibák is kijavulnak, de a hibák 15%-a bent marad az ügyfélnek való átadáskor (Watts Humphrey: What if your life depended on software? El adás a 2000-s EuroSPI konferemcián, Koppenhága, április) Dr. Balla Katalin Szoftver min ség és menedzsment

5 Miért tesztelünk? hogy a szoftver bizonyos jellemz it megismerjük, kipróbáljuk, helyességükr l, elvárt m ködésükr l meggy z djünk hogy er södjék a rendszerbe vetett bizalmunk hogy feltárjuk a rendszernek és m ködtetésének kockázatait Dr. Balla Katalin Szoftver min ség és menedzsment

6 Miért tesztelünk? «KRJ\EL]RQ\RVPLQ VpJLDWWULE~WXPRNpUWpNpWPHJLVPHUM N karbantarthatóság hajlékonyság tesztelhet ség Termék átdolgozása Termék átvitele Termék m ködése hordozhatóság újrafelhasználhatóság együttm ködés helyesség megbízhatóság használhatóság hatékonyság teljesség Dr. Balla Katalin Szoftver min ség és menedzsment

7 Mit tesztelünk? Általában: a terméket, különböz kritériumok alapján pl: funkcionalitás megbízhatóság teljesítmény egyéb jellemz k... de: a tesztelés a szoftver egyéb elemeir l is szolgáltat adatokat Dr. Balla Katalin Szoftver min ség és menedzsment

8 A tesztelés információt ad... a szoftver min ségér l az átadáskor a rendszerben lev hibák (átadás után megtalálandó hibák) számáról arról, hogy a rendszer vajon jól fog-e m ködni? a fejlesztési folyamat min ségér l a korábban már megtörtént tesztelés min ségér l a fejlesztési folyamat és a termék javulásáról Dr. Balla Katalin Szoftver min ség és menedzsment

9 A tesztelés információt ad... a tesztelési folyamat költségér l arról, hogy a tesztelési folyamatba fektetett energia, id, pénz megtérül-e? arról, hogy mi a kockázata a rendszer azonnali átadásának? Idejekorán figyelmeztet(het) egy, a rendszer m ködtetéséb l fakadó katasztrófára Dr. Balla Katalin Szoftver min ség és menedzsment

10 A tesztelés nem ad információt... a rendszer átadásának optimális id pontjáról a tesztelési folyamat hatékonyságáról arról, hogy vajon eleget teszteltünk-e? Dr. Balla Katalin Szoftver min ség és menedzsment

11 Mikor tesztelünk? Általában a kódolás végén, pedig a hibák nagy része nem a kódoláskor kerül a rendszerbe )RUUiV3URGXFWTXDOLW\WKURXJKGHIHFWPDQDJHPHQW Mita Rout, Mastek Ltd. European SEPG,9-12 April 2002, Amsterdam Dr. Balla Katalin Szoftver min ség és menedzsment

12 Hogyan tesztel(j)ünk? Tervezetten Dokumentáltan Függetlenül A teljes életciklus alatt M köd rendszerben való változtatáskor Dr. Balla Katalin Szoftver min ség és menedzsment

13 Hogyan tesztelünk? ad-hoc módon elméleti tudás nélkül van, amit keveset, van, amit túl sokat nem tervezetten nem dokumentáltan Dr. Balla Katalin Szoftver min ség és menedzsment

14 A tesztelés problémái A tesztelt programot / rendszert érteni kell (?) Meg kell találni a hibát a szoftverben, és ki kell javítani Minél el bb ajánlatos a hibát megtalálni (jó lenne, ha abban a fázisban, amelyikben belekerült ) Biztosítani kell, hogy a hibajavításkor ne kerüljenek további hibák a rendszerbe, vagy, ha belekerülnek, javítsuk ki ket... Dr. Balla Katalin Szoftver min ség és menedzsment

15 A tesztelés (mai) problémái Mindenki ért hozzá Senki sem szereti Szégyen tesztel nek lenni??? A cégek nem vállalják (tudatosan) a tesztelés költségét A tesztelés költsége a teljes fejlesztési költség 30-50%-a Kevesen alkalmaznak tesztelési eszközöket Mindenki csak a számára fontos funkciókat teszteli Nincs független tesztel csapat A tesztelés jó részét a felhasználó végzi, átadás után Dr. Balla Katalin Szoftver min ség és menedzsment

16 A tesztelés (mai) problémái Hogy elkerüljük ket, a tesztelés elméletét jól ismer szakemberek kellenek független tesztelési csapatok kellenek módszertanok alkalmazása segít számítógépes eszközök alkalmazása segít Dr. Balla Katalin Szoftver min ség és menedzsment

17 Tesztelési alapismeretek Vezérlési gráf Hívási gráf Hatásanalízis A program tesztelhet sége Tesztelési kritériumok A teszt lefedettség Tesztelési technikák Szeletelés Fekete-doboz teszt, fehér-doboz teszt Tesztesetek, tesztadatok Tesztelési stratégia A tesztelés dokumentálása Dr. Balla Katalin Szoftver min ség és menedzsment

18 Vezérlési gráf CFG (Control Flow Graph) irányított gráf a csomópontok utasítások vagy alapblokkok az élek: a vezérlést mutatják a csomópontok között van egy belépési és egy kilépési csomópont Dr. Balla Katalin Szoftver min ség és menedzsment

19 Vezérlési gráf Példa (Forrás: A tesztelés alapjai. Tanfolyami anyag. IQSOFT-JohnBryce Oktatóközpont, IQSOFt -Alvicom tesztközpont.) X := 1 ; Y := X * 5 ; if Y > Z then read (X) else Z := a + b ; X := 0 ; endif ; write (X, Z) ; Dr. Balla Katalin Szoftver min ség és menedzsment

20 Hívási gráf CG (Call Graph) irányított folyam multigráf a csomópontok: az eljárások (függvények) az élek: a hívások az eljárások között többszörös hívásokat többszörös élek reprezentálják ha rekurzió van a programban, a gráf nem ciklusmentes A rekurzióban lev modulok egy SCC-t (összefügg tartományt) alkotnak. Az SCC-k száma és nagysága a program bonyolultságának mér száma. Dr. Balla Katalin Szoftver min ség és menedzsment

21 Hívási gráf Példa (Forrás: A tesztelés alapjai. Tanfolyami anyag. IQSOFT-JohnBryce Oktatóközpont, IQSOFt -Alvicom tesztközpont.) Program M read (b) CALL P ; while a > 3 do CALL Q; endwhile ; CALL P ; write (X, Z) ; Procedure P CALL Q CALL R Procedure Q CALL P Dr. Balla Katalin Szoftver min ség és menedzsment M P Q O O O O R

22 Hatásanalízis A program hatásokon alapuló feltérképezése segíti a tesztelést közvetlen adatfüggés: egy utasítás változókon keresztül hat egy másikra pl. x változó 1.0 értéket kap, majd valahol y változó felveszi x- nek ezt az értékét közvetlen vezérlésfüggés: a feltételt l függ en egy utasítás végrehajtódik vagy sem if x > 0 then y = 2 A teljes hatás e kett kombinációja és terjedése Dr. Balla Katalin Szoftver min ség és menedzsment

23 Tesztelési kritériumok Valamilyen elv alapján sorolják be a teszteket, pl: Tesztadat megfelelési kritérium a C S X P X T reláció, ahol S a program specifikációk halmaza P az implementált programok halmaza T a teszt sorozatok halmaza A program sikeres a t T teszt esetén, ha S(t)=P(t) (a programfutás megfelel az elvárt értékeknek az adott input esetén) Dr. Balla Katalin Szoftver min ség és menedzsment

24 Tesztelési kritériumok Kimerít teszt a P program az összes lehetséges t D inputra lefut és az eredményt összehasonlítjuk az S specifikációban megadottal Megbízható teszt Egy T teszt megbízható, ha letesztelve vele a P programot, a program minden inputra helyes, vagy a teszt felfedezi a hibát Véletlen egybeesés akkor történik, ha egy számítás hibás, de a kiválasztott tesztesetre az output megegyezik az elvárttal Dr. Balla Katalin Szoftver min ség és menedzsment

25 Tesztelési kritériumok Korlátozott tesztelési kritériumok tartomány alapú teszt ha a teljes input teret input tartományokra felosztva, legalább egy-egy tesztesetet választunk minden input tartomány esetében programút alapú teszt ha minden D i tartomány esetében a tartományhoz hozzárendelhetünk egy P úthalmazt úgy, hogy T i futtatása során egy egyedi programút lesz végrehajtva. A hozzárendelés a teszt el tt történik. Egy programút alapú kritérium lehet vezérlés alapú adatfolyam alapú Dr. Balla Katalin Szoftver min ség és menedzsment

26 Tesztelési kritériumok Vezérlés alapú kritériumok minden utasítás kritérium T-t úgy választjuk meg, hogy a P program minden utasítása legalább egyszer végre legyen hajtva (túl gyenge, mert pl. az üres else ágakat sem teszteli - gyakorlatban elfogadhatatlan) minden ág kritérium minden CFG élt legalább egyszer le kell fedni, beleértve az üres ágakat is minden út kritérium a CFG minden egyes útját legalább egyszer le kell tesztelni Dr. Balla Katalin Szoftver min ség és menedzsment

27 Tesztelési kritériumok Gyakran használt kritériumok az utasítások egymásra való hatásán alapulók (pl: minden def kritérium, minden felhasználás (use) kritérium, minden DU(definíciófelhasználás pár) kritérium stb.) Dr. Balla Katalin Szoftver min ség és menedzsment

28 A program tesztelhet sége A tesztelhet ség mér száma: DRR tartomány-eredmény arány (D / R), ahol D az input tartomány számossága, R az eredmény számossága pl: f(d) = d DIV 2, ahol D ={1,2, 100}, R = {0,1, 50}, DRR = 100 / 51 ~2 - pl. ha a helyes kifejezés (d+1) DIV 2, akkor csak minden második érték fedezi fel a hibát a DRR az információvesztés közelít mér száma, azt modellezi, hogy különböz input esetében ugyanaz az output Dr. Balla Katalin Szoftver min ség és menedzsment

29 A program tesztelhet sége Mikor találjuk meg a hibát? Több dolog együttes fennállása szükséges a hiba helyéig a megfelel úton fut a program a hiba helyén az eredménytér hibás ( nem veszhet el információ, magas DRR következtében) a hiba el kell jusson egy kimenetre. Ehhez minden hatás (du) pár esetében a use helyén az állapottérnek hibásnak kell lennie A minden él kritérium az 1-et próbálja megvalósítani A du kritérium az 1-et és részben a 3-at A tartományteszt kritérium 1-et és részben 2-t Megbízható eredményt kapunk, ha az utóbbi kett t kombináljuk (Forrás: A tesztelés alapjai. Tanfolyami anyag. IQSOFT-JohnBryce Oktatóközpont, IQSOFt -Alvicom tesztközpont.) Dr. Balla Katalin Szoftver min ség és menedzsment

30 A teszt lefedettség Azt mutatja, hogy mennyire átfogó a tesztelés Követelmény alapú lefedettség tesztlefedettség = végrehajtott tesztek száma / tervezett tesztek száma a teszteket a követelményekb l kiindulva tervezzük Teszt lefedettség = T (t,i,v,s) /RTF ahol: T a tervezett (t), implementált (i), végrehajtott (v) és sikeres (s) tesztesetek és teszteljárások száma. RTF a tesztelési követelmények összes száma. Dr. Balla Katalin Szoftver min ség és menedzsment

31 A teszt lefedettség Kód alapú lefedettség A kód alapú lefedettség mérésénél azt határozzuk meg, hogy milyen mennyiség kód lett letesztelve az összes kódhoz viszonyítva. A lefedettség- mérés lehet vezérlés- vagy adat- alapú. Vezérlés alapú lefedettség - mérés: a kód sorokat, elágazási feltételeket ellen rizzük. Adat alapú lefedettség- mérés: a cél az adatok állapotának ellen rzése a m velet során, pl. egy adat elem definiálva van a használata el tt.» Teszt lefedettség = I s /TLIC, ahol:» I s a végrehajtott elemek száma, mint utasítások, kód elágazások, kód útvonalak, döntési pontok vagy adat nevek.» TLIC a kódban lev elemek összes száma. A fenti arányszámok százalékban kifejezése adja a kód alapú következ mutatót.» A tesztesetek X százaléka van lefedve a Y százalékban megadott sikeres esetekkel. Dr. Balla Katalin Szoftver min ség és menedzsment

32 Tesztelési technikák, teszt típusok A hibák megtalálása szempontjából valószín leg az lenne ideális, ha a rendszert minden lehetséges esetben kipróbáljuk, minden elképzelhet esetet, programágat, funkciót végigjárunk. Ez nagyon sok id t, költséget igényel, nem is reális elvárás. A tesztelési technikák segítenek válogatni a tesztelend elemek között (fontos elem, sorrend, id pillanat ) Dr. Balla Katalin Szoftver min ség és menedzsment

33 Szeletelés M. Weiser Alapötlet: hibakereséskor a programozók tulajdonképpen szeletelnek, vagyis azokat a részeket választják ki a programból, amelyek egy adott utasításra hatást gyakorolnak. A hagyományos debuggolással szemben, a szeletelés alkalmazásánál csak a szelet utasításait kell debuggolni Dr. Balla Katalin Szoftver min ség és menedzsment

34 Szeletelés Statikus szeletelési kritérium egy pár c = (V,I), ahol: V a változók egy halmaza a P programban, I egy utasítás. Statikus szelet egy P program statikus szelete (StS) a C(V,I) szeletelési kritériumra nézve P egy végrehejtható részprogramja, amely minden érvényes input esetén minden V-beli változóra az I helyen ugyanazt az értéket adja, mint P. Dr. Balla Katalin Szoftver min ség és menedzsment

35 Szeletelés Statikus szelet, példa var n, sum, j : integer ; {1} sum := 0 ; {2} j := 2 ; {3} read(n) ; {4} while n > 0 do {5} sum := sum + j ; {6} j := j+2 ; {7} n := n-1 ; endwhile {8} write (sum) ; C = ({n},7) StS: var n, sum, j : integer ; {3} read(n) ; {4} while n > 0 do {7} n := n-1 ; endwhile Dr. Balla Katalin Szoftver min ség és menedzsment

36 Szeletelés Program-függés gráfja (PDG) irányított folyamgráf létezik egy kiinduló csomópont, amelybe él nem fut be a P program minden utasítása egy csomópont a PDG-ben Ha a B csomópont adat vagy vezérlésfügg az A csomóponttól, akkor van egy irányított él A-ból B-be Dr. Balla Katalin Szoftver min ség és menedzsment

37 Szeletelés Példa, PDG sum:=0 entry j:=2 kontrollfüggés adatfüggés Read(n) Write(sum) While n>0 sum:= sum+j j:= j +2 n := n+1 (Forrás: A tesztelés alapjai. Tanfolyami anyag. IQSOFT-JohnBryce Oktatóközpont, IQSOFt -Alvicom tesztközpont.) Dr. Balla Katalin Szoftver min ség és menedzsment

38 Szeletelés A PDG-t a szeletek meghatározásánál használjuk fel. A szeletelési kritériumban lev utasításokból és változókból kiindulva, a szelet egy gráfelérési algoritmussal megkapható Dr. Balla Katalin Szoftver min ség és menedzsment

39 Szeletelés El nyök kisebb kódot kell tesztelni teszteseteket könnyebb megadni segít a hibák helyének megtalálásában támogatja regressziós tesztelést el segíti a programok megértését Hátrányok az egész program elmélyült hatásanalízise szükséges Dr. Balla Katalin Szoftver min ség és menedzsment

40 Szeletelés Példa Szeletelés az Y2K problémában Kiindulva egy dátum típusú utasításból, meg lehet határozni az összes utasítást, amelyre az adott utasítás hatással van Ezt kihasználva, automatikusan lehet tesztadatokat generálni, amelyek nagy biztonsággal megtalálják a 2000., év hibáit. Igy született az Y2K.O. Dr. Balla Katalin Szoftver min ség és menedzsment

41 Teszt-típusok Fehér-doboz teszt Fekete -doboz teszt Inspekció, szemle Regressziós teszt ( Dr. Balla Katalin Szoftver min ség és menedzsment

42 Teszt típusok Fehér doboz teszt (white box / glass box): strukturált teszt A program bels szerkezetét ismerve végezzük a tesztet Statikus és dinamikus analízisre bomlik Dr. Balla Katalin Szoftver min ség és menedzsment

43 Teszt típusok Fehér-doboz teszt Statikus analízis technikák Alapvet en 3 módon: a program bels szerkezetének vizsgálata, a program teljességének és konzisztenciájának vizsgálata el re meghatározott szabályok alapján, a program összehasonlítása a specifikációjával vagy dokumentációjával. Dr. Balla Katalin Szoftver min ség és menedzsment

44 Teszt típusok Fehér-doboz teszt Dinamikus analízis technikák a rendszer futtatását feltételezik A rendszer valódi vagy mesterséges környezetbeli viselkedésének elemzése a végrehajtás el tt, alatt és után (Hausen, 1984) Dr. Balla Katalin Szoftver min ség és menedzsment

45 Teszt-típusok Fekete-doboz teszt: funkcionális teszt a program (rész) funkcióit veszi alapul, nem foglalkozik a program bels szerkezetével ne a programozó végezze végezhetjük a felhasználók bevonásával, vagy anélkül Dr. Balla Katalin Szoftver min ség és menedzsment

46 Teszt-típusok Inspekció Szemle Dr. Balla Katalin Szoftver min ség és menedzsment

47 Regressziós teszt Azokat a részeket kell tesztelni, amelyekre a megváltozott utasítások hatást gyakorolnak Új funkciók tesztelése egy már korábban tesztelt programban korábbi tesztek felhasználása új tesztek megadása Nem várt hatások tesztelése nehéz hagyományos módszer: összes tesztadat futtatása javított módszer: a tesztadatokból csak a szükségeseket kell kiválasztani - sok adminisztráció Dr. Balla Katalin Szoftver min ség és menedzsment

48 Statikus regressziós teszt Kiindulás: az eredeti és a módosított program Szemantikus különbségeket azonosítjuk Mindkét program esetében a módosított részekb l hatásanalízist (szeletelést) indítunk A két szeletet egyesítjük A szeletb l kiválasztjuk a kimen változókat Megvizsgáljuk, melyek azok a változók, amelyekre a módosításnak ténylegesen hatnia kell A többi: a hibás változó El ny: minden hibát megtalálunk Hátrány: vaklárma lehetséges Dr. Balla Katalin Szoftver min ség és menedzsment

49 Teszteset A teszt bemeneteknek és a várt eredményeknek a halmaza Az input lehet menükiválasztás is (tehát a megfelel végrehajtási út kiválasztása) Az eredmények ellen rzése automatizált manuális Dr. Balla Katalin Szoftver min ség és menedzsment

50 Tesztesetek származtatása felhasználói esetekb l Funkcionális teszteléshez. Minden használati eset forgatókönyvhöz kell fejleszteni teszteseteket. származtatása kiegészít specifikációból A nem funkcionális követelmények (teljesítmény, biztonság, hozzáférhet ség) és a konfigurációs követelmények a tesztelt rendszer kiegészít viselkedéseit és jellemz it határozzák meg. Ezek a kiegészít specifikációból derülhetnek ki. Dr. Balla Katalin Szoftver min ség és menedzsment

51 Tesztesetek származtatása teljesítménytesztekhez Els dleges bemenet: a kiegészít specifikáció nem-funkcionális követelményei Irányelvek: bizonyosodjunk meg arról, hogy a specifikációban szerepl minden olyan állításra, amelyik teljesítmény kritériumot fejez ki, van legalább egy teszteset azonosítva bizonyosodjunk meg arról, hogy minden kritikus használati esetre van legalább egy teszteset azonosítva Több teszteset használati esetenként / követelményenként küszöbérték alatti, küszöbértéken, küszöbérték feletti Válaszid t befolyásoló speciális feltételek azonosítása az adatbázis mérete - hány rekord van? A terheléselemzés - a végrehajtás alatti egyidej végfelhasználók száma, a tranzakciók száma és típusa a környezet jellemz i (hardver, szoftver, hálózati konfiguráció) Dr. Balla Katalin Szoftver min ség és menedzsment

52 Tesztesetek származtatása biztonsági / hozzáférési tesztekhez Bemenet: szerepl k, használati esetek. Kritikus a biztonság! Csak a megadott szerepl k hajthassák végre a megadott használati eseteket, de k igen (pl. pénzkiadó automata) Dr. Balla Katalin Szoftver min ség és menedzsment

53 Tesztesetek származtatása installációs tesztekhez Installálható-e a tesztelt rendszer minden lehetséges installációs forgatókönyv szerint installációs média =CD-ROM, lemezek, fileszerver ) új installáció teljes installáció custom installációk upgrade installációk Dr. Balla Katalin Szoftver min ség és menedzsment

54 Tesztelési stratégia A teszt stratégia kidolgozás Teszt tervezése Tesztadatok generálása Egységteszt (unit test) Integrációs teszt Rendszerteszt Inspekció Átvételi teszt Dr. Balla Katalin Szoftver min ség és menedzsment

55 A tesztelési stratégia kidolgozása Adjon összefügg, elméleti megalapozottságú leírást a tesztekr l Adjon gyakorlati útmutatást is a teszt végrehajtásához (ki, mit, mikor, hogyan, miért ) Jó esetben egy cégnek van átfogó tesztelési stratégiája (kritériumok, technikák, eszközök, elfogadható értékek a tesztelésben ), amely a konkrét esetekre szabható Dr. Balla Katalin Szoftver min ség és menedzsment

56 A teszt tervezése A teszteléssel kapcsolatos tevékenységek és azok id beli sorrendje hasonlóak a programfejlesz tés folyamatához. 7HV]WWHYpNHQ\VpJ Teszt terv elkészítése Teszt tervezése Teszt eljárások megvalósítása Teszteset 'RNXPHQWiFLy Tesztterv Teszt specifikáció Teszteljárás Teszt szkript Teszt végrehajtása Tesztelési napló Hibaleírás Teszt eredmény kiértékelése Tesztelési jelentés Dr. Balla Katalin Szoftver min ség és menedzsment

57 Tesztadatok A teszteléshez szükségünk van jól meghatározott tesztadatokra, amelyek el re meghatározott értékeket tartalmaznak, annak érdekében. hogy a tesztesetek végrehajtása során el re tervezhet, ellen rizhet eredményeket kapjunk, továbbá, amelyek értékei kell képpen széls séges határok között mozognak a program rendszertervben specifikált jellemz inek vizsgálatához. Dr. Balla Katalin Szoftver min ség és menedzsment

58 Egységteszt (unit test) Az egységeket teszteljük a specifikációval szemben. Egy egység: egy v. több eljárás, függvény Fekete- doboz módszer Fehér -doboz módszer Mindkett egyformán jelent s. Egységteszt deríti ki a legtöbb hibát. Dr. Balla Katalin Szoftver min ség és menedzsment

59 Integrációs teszt (Integration test) Az egységeket integráljuk, és az integrált részek interfészeit teszteljük a specifikációval szemben. Fekete-doboz módszer (kisebb jelent ség ) Fehér-doboz módszer (az A egységben van egy utasítás, amely hat a B egységben lev utasításra, és fordítva) Integrációs teszt deríti ki a legköltségesebb hibákat. Dr. Balla Katalin Szoftver min ség és menedzsment

60 Rendszerteszt A teljes rendszert teszteljük a specifikációval szemben. Funkcionális teszt Terheléses teszt Felhasználói teszt: a teljes rendszert a felhasználó vagy megbízottja teszteli Dr. Balla Katalin Szoftver min ség és menedzsment

61 Inspekció Csökkentheti a tesztelési költségeket, akár a fejlesztési költségek %-ra. Elmaradhat az egységteszt és integrált teszt, csak a rendszertesztet kell elvégezni Pl: Rendszerterv inspekciója a követelményekhez viszonyítva, kód inspekciója a rendszertervvel összevetve stb. Dr. Balla Katalin Szoftver min ség és menedzsment

62 Átvételi teszt Általában a felhasználó által elvégzett, a teljes rendszerre kiterjed teszt, amelynek eredményeképpen a felhasználó elfogadja és átveszi a rendszert. Dr. Balla Katalin Szoftver min ség és menedzsment

63 Tesztelési hibák A tesztelt szoftvernek a teszt során tapasztalt hibás viselkedését nem a tesztelt szoftver hibái okozzák. A tesztelési hiba lehet: Teszt specifikációs vagy tesztadat hiba. A hibát a vizsgálati pont min sítésének hibás specifikációja vagy a rosszul megválasztott tesztadatok okozták. A teszt hibás végrehajtása A hibát a teszt nem megfelel végrehajtása (pl. a végrehajtás lépéseinek helytelen sorrendje, ütemezési hibák) okozták. Hibás tesztkörnyezet A hibát a tesztkörnyezet rossz megválasztása (pl. hibás tesztprogram) okozta. Tesztelési hibák feltárásakor a hibát okozó elemet el kell hárítani (pl. javítani kell a teszt specifikációt, módosítani kell a teszt adatokat, a teszt környezetet, a teszt lépéseinek végrehajtási sorrendjét stb.), majd meg kell ismételni a tesztet. Dr. Balla Katalin Szoftver min ség és menedzsment

64 Szoftver hibák A hibás viselkedést a tesztelt szoftver hibái okozzák. A szoftver hiba lehet: Megvalósítási hiba: a szoftver nem teljesíti a rendszertervben el írtakat. Tervezési hiba: a hiba a nem megfelel rendszerterv következménye. Hiba felmerülése esetén a projekt vezet je dönt a további lépésekr l. Elrendelheti újabb, a hiba keletkezésének körülményeit pontosabban feltáró tesztek elvégzését, visszaadhatja a tesztelt programot a hiba kijavításáért felel s személynek vagy apróbb hibák esetén azok kijavítását az átvev vel egyeztetve kés bbre halaszthatja. Az ilyen döntéseket bizonylatolni kell (pl. bejegyzés a teszt naplóba, stb.) Dr. Balla Katalin Szoftver min ség és menedzsment

65 Hibaelemzés A hiba elemzéshez általában négy f paramétert használhatunk: A hiba aktuális állapotának státusza ( nyitott, kijavított, lezárt, stb.) A hiba fontosságának prioritása. A hiba súlyossága. A forrás, ahol a hiba el fordult, és mi a hiba eredeti oka. A hiba elemzéskor az alábbi kimutatásokat szokás elkészíteni: Hiba eloszlás riport: a hibák száma egy vagy két paraméter függvényében. (pl. a hibák száma prioritás vagy súlyosság szerint) Hiba korosítás riport: milyen sokáig marad javítatlanul egy hiba. Hiba tendencia riport: hibák száma státusz szerint az id függvényében. Teszt eredmény és fejl dés riport: a tesztelés végrehajtásának eredményét mutatja meg az iterációk számán és teszt ciklusokon keresztül. Dr. Balla Katalin Szoftver min ség és menedzsment

66 A teszt kiértékelése Globális elemzése az összes elvégzett tesztnek. Ennek alapján döntés születhet a rendszer elfogadásáról. Általános elfogadási kritériumok pl a következ mér számokon alapulhatnak: Hibák száma és típusa (javított, nem javított hibák száma) Teszt lefedettség: a kód lefedettség, a tervezett, megvalósított és végrehajtott tesztesetek és teszteljárások száma. A teszt lefedettség mindig a hiba kritériummal együtt használatos. Teljesítmény: egy megadott tevékenység végrehajtási ideje (funkciók, m veletek, egyéb események). Ez a kritérium azoknál a teszteknél használatos, ahol az id kritikus tényez. Teljesítés. Ez a kritérium azt jelzi, hogy egy adott készítménynek vagy folyamat tevékenységnek/lépésnek milyen mértékben elégíti ki az elfogadott szabványt vagy irányvonalat. Elfogadhatóság és elégedettség: szubjektív érték, mely a használhatóságra és az esztétikus megjelenésre vonatkozik. Dr. Balla Katalin Szoftver min ség és menedzsment

67 A tesztelés dokumentálása Tesztelési terv Teszt esetek Teszt szkriptek Teszt adatok Tesztelési jegyz könyvek Hibalista, hibák bizonylatolása Átadás/ átvételi jegyz könyv Dr. Balla Katalin Szoftver min ség és menedzsment

68 A tesztelés dokumentálása 7HV]WWHYpNHQ\VpJ Teszt terv elkészítése 'RNXPHQWiFLy Tesztterv Teszt tervezése Teszt specifikáció Teszteset Teszt eljárások megvalósítása Teszteljárás Teszt szkript Teszt végrehajtása Tesztelési napló Hibaleírás Teszt eredmény kiértékelése Tesztelési jelentés Dr. Balla Katalin Szoftver min ség és menedzsment

69 A tesztelés dokumentálása Tesztterv A tesztterv leírja a tesztelésbe bevont programelemeket, a tesztelési célokat és az alkalmazni kívánt tesztelési módszereket / megközelítéseket. Ismerteti a teszteléssel kapcsolatos tevékenységeket, azok felel seit, fázisainak határidejét, a tesztkövetelményeket és a tesztelés során létrehozandó dokumentumokat. Rögzítésre kerül a tesztkörnyezet (hardver és szoftver), valamint a tesztelés tervezéséhez és lefolytatásához szükséges dokumentációk. Teszt szkript A tesztel által írt, a számítógép által olvasható leírás, amely automatizálja a teszt eljárások végrehajtását. Dr. Balla Katalin Szoftver min ség és menedzsment

70 A tesztelés dokumentálása Teszt specifikáció A teszt specifikációk finomítják, részletezik a teszttervben megadott módszereket/megközelítéseket, tesztelend jellemz ket és definiálják egy adott specifikációhoz rendelt teszteseteket. Teszteset A teszteset definiálja a teszt input adatait, a végrehajtás feltétételeit, a végrehajtás lépéseit (teszteljárások) és a várt eredményeket. Teszteljárás Teszteljárásnak azokat a leírásokat nevezzük, amelyek megadják, hogy a teszteseteket hogyan kell végrehajtani, azaz részletes utasításokat tartalmaznak a teszt indítási állapotának a beállítására, a végrehajtás lépéseire és az eredmények kiértékelésére. Egy teszteljárás több tesztesethez is tartozhat. Dr. Balla Katalin Szoftver min ség és menedzsment

71 A tesztelés dokumentálása Hibaleírás A hibaleírás dokumentumban a tesztesetekben definiált elvárt eredményekt l való eltérést rögzítjük. Tesztelési jelentés A tesztelési jelentés összesíti a kvalifikációs, illetve az átvételi teszt elvégzésekor tapasztaltakat és a tesztelés eredményét. Tesztelési napló A tesztelési napló rögzíti a teszt specifikációk alapján végrehajtott tesztelési tevékenységeket, a tesztkörnyezetet, valamint a tesztelés eredményét (a felmerül hibákat és a sikeres végrehajtást is). Rögzíteni kell továbbá a teszt specifikációban, illetve a tesztesetekben el írtaktól való eltéréseket. Dr. Balla Katalin Szoftver min ség és menedzsment

72 A teszt végrehajtásának bizonylatolása A végrehajtás során a következ információkat kell rögzíteni: a tesztelést végz személy nevét a tesztelt funkciót a tesztelés végrehajtásának dátumát a tesztelés sikeres vagy sikertelen voltát milyen gépen történt a tesztelés. Dr. Balla Katalin Szoftver min ség és menedzsment

73 Hibák bizonylatolása Az egyes hibákról a következ információkat kell rögzíteni hiba azonosító hibajelenség leírása tesztelt program azonosítója teszteset azonosító a hiba felfedezésének dátuma a hibát felfedez személy a hiba súlyossága a hiba prioritása a hiba állapota (rögzített, javítás alatt, kijavított) a hiba javításáért felel s személy javítás dátuma. Dr. Balla Katalin Szoftver min ség és menedzsment

74 A tesztelt szoftver teljesítménye tesztelési dokumentumokkal (ból) vizsgálható Az teljesítményre vonatkozó mér számokkal az adott szoftver teljesítménye határozható meg a válaszid, a végrehajtási folyamat, a m veleti megbízhatóság és korlátok vonatkozásában. Els dleges teljesítmény mértékek: Dinamikus felügyelet - a teszt szkriptek státuszának és állapotának valós idej elfogása és megjelenítése a teszt végrehajtása alatt. Válaszid / Átbocsátó képesség a válaszid és átbocsátó képesség mérése egy adott szerepl nél és vagy use case-nél. Százalékos riport összegy jtött adat értékek százalékos mérése / számítása. Összehasonlító riport különböz teszt végrehajtások két vagy több adatcsoportja közötti különböz ségek vagy tendenciák. Nyomkövetés riport a teszt szkript és a tesztelés célja közötti üzenetek / párbeszédek részletei Dr. Balla Katalin Szoftver min ség és menedzsment

75 Átadás-átvételi jegyz könyv Felhasználó és szállító közötti szerz déses feltételek teljesülésekor Dr. Balla Katalin Szoftver min ség és menedzsment

76 A tesztelési folyamat min sége Általában elmondható, hogy a tesztelési folyamat akkor jó: ha a hibák a fejlesztés minél korábbi szakaszában kiderülnek és kijavítódnak, ha a kód alapú lefedettség megfelel, ha a elkészült termék és a m szaki folyamat az elfogadási kritériumoknak megfelel ha a vev i reklamációk száma csekély a termék átadása után, vagyis a vev elégedett az elkészült és átvett termékkel. Dr. Balla Katalin Szoftver min ség és menedzsment

77 Mir l volt szó Mér szám Min ségi attribútum Definíció Termék M szaki folyamat PM folyamat Dr. Balla Katalin Szoftver min ség és menedzsment