Szoftver min ség és menedzsmentkondor/rszf/SWMM/ELOADASOK/SzMM15-teszteles1-1.pdf · Dr. Balla Katalin Szoftver min ség és menedzsment - 15. 3 A tesztelés … a rendszer próbafuttatása

Szoftver min ség ésmenedzsment

15. Tesztelési módszerek, technikák

Dr. Balla Katalin

Dr. Balla Katalin Szoftver min ség és menedzsment - 15. 2

Tartalom✔ Miért tesztelünk?

✔ Mit tesztelünk és mirl 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


A tesztelés

✔… a rendszer próbafuttatása

✔…a valós mködés szimulálása

✔…annak ellenrzése, hogy jól értettük-e akövetelményeket?

✔ …annak ellenrzése, hogy a követelményekmindegyikének van-e megfelelje amodellekben?

✔…a dokumentáció / kód átolvasása

✔...


Miért tesztelünk?

✔Mert az a tapasztalatunk, hogy a szoftverbenhibák vannak, és ezek közül minél többetszeretnénk megtalálni, még mieltt afelhasználó találná meg ket, és mieltt bajtokozná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 bentmarad az ügyfélnek való átadáskor

(Watts Humphrey: „What if your life depended on software?”Eladás a 2000-s EuroSPI konferemcián, Koppenhága, 2000. április)


Miért tesztelünk?

✔… hogy a szoftver bizonyos jellemzitmegismerjük, kipróbáljuk , helyességükrl,elvárt m ködésükr l meggy z djünk

✔…hogy er södjék a rendszerbe vetettbizalmunk

✔…hogy feltárjuk a rendszernek ésm ködtetésének kockázatait


Miért tesztelünk?✔ «KRJ\�EL]RQ\RV�PLQ VpJL�DWWULE~WXPRN�pUWpNpW�PHJLVPHUM�N

Term

ékát

dolg

ozás

aTerm

ék „átvitele”Termék m ködése

karbantarthatóság„hajlékonyság”tesztelhetség

hordozhatóságújrafelhasználhatóságegyüttm ködés

helyességmegbízhatósághasználhatósághatékonyság

teljesség


Mit tesztelünk?

✔Általában: a terméket, különböz kritériumokalapján– pl:

• funkcionalitás

• megbízhatóság

• teljesítmény

• …egyéb jellemzk...

✔… de: a tesztelés a szoftver egyéb elemeirlis szolgáltat adatokat


A tesztelés információt ad...

✔…a szoftver minsé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-em ködni?

✔…a fejlesztési folyamat minségér l

✔… a korábban már megtörtént tesztelésmin ségér l

✔… a fejlesztési folyamat és a termék javulásáról


A tesztelés információt ad...

✔…a tesztelési folyamat költségérl

✔… arról, hogy a tesztelési folyamatbafektetett energia , id, pénz megtérül-e?

✔…arról, hogy mi a kockázata a rendszerazonnali átadásának?

✔Idejekorán figyelmeztet(het) egy, a rendszerm ködtetésébl fakadó katasztrófára


A tesztelés nem ad információt...

✔…a rendszer átadásának optimálisid pontjáról

✔…a tesztelési folyamat hatékonyságáról

✔…arról, hogy vajon eleget teszteltünk-e?


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

)RUUiV��3URGXFW�TXDOLW\�WKURXJK�GHIHFW�PDQDJHPHQWMita Rout, Mastek Ltd. European SEPG,9-12 April 2002, Amsterdam


Hogyan tesztel(j)ünk?✔Tervezetten

✔Dokumentáltan

✔Függetlenül

✔A teljes életciklus alatt

✔M köd rendszerben való változtatáskor


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


A tesztelés problémái

✔A tesztelt programot / rendszert érteni kell (?)

✔ Meg kell találni a hibát a szoftverben, és kikell javítani

✔Minél el bb ajánlatos a hibát megtalálni (jólenne, ha abban a fázisban, amelyikbenbelekerült…)

✔Biztosítani kell, hogy a hibajavításkor nekerüljenek további hibák a rendszerbe, vagy,ha belekerülnek, javítsuk ki ket...


A tesztelés (mai) problémái✔ Mindenki ért hozzá…

✔ Senki sem szereti…

✔ “Szégyen” tesztelnek 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


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


Tesztelési alapismeretek✔ Vezérlési gráf

✔ Hívási gráf

✔ Hatásanalízis

✔ A program tesztelhetsé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


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ópontokközött

– van egy belépési és egy kilépési csomópont


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) ;

0

00

0

0

0


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üggtartományt) alkotnak. Az SCC-k száma és nagysága aprogram bonyolultságának mérszáma.


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

O

O

O

O

M

P

Q

R


Hatásanalízis

✔A program hatásokon alapuló feltérképezésesegí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ételtl függ enegy 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


Tesztelési kritériumok

✔Valamilyen elv alapján sorolják be ateszteket, 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) (aprogramfutás megfelel az elvárt értékeknek az adottinput esetén)


Tesztelési kritériumok– Kimerít teszt

• a P program az összes lehetséges t ∈D inputra lefut és azeredmé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



✔Korlátozott tesztelési kritériumok– tartomány alapú teszt

• ha a teljes input teret input tartományokra felosztva, legalábbegy-egy tesztesetet választunk minden input tartomány esetében

– programút alapú teszt• ha minden Di tartomány esetében a tartományhoz

hozzárendelhetünk egy P úthalmazt úgy, hogy Ti futtatása soránegy egyedi programút lesz végrehajtva. A hozzárendelés a tesztel tt történik.

• Egy programút alapú kritérium lehet– vezérlés alapú

– adatfolyam alapú



✔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ásalegalább egyszer végre legyen hajtva (túl gyenge, mert pl. az üreselse á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



✔Gyakran használt kritériumok az utasításokegymá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.)


A program tesztelhet sége

✔A tesztelhet ség mérszáma: DRR– tartomány-eredmény arány (D / R), ahol D az

input tartomány számossága, R az eredményszá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 csakminden 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


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áreseté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 ketttkombináljuk

(Forrás: A tesztelés alapjai. Tanfolyami anyag. IQSOFT-JohnBryce Oktatóközpont, IQSOFt -Alvicom tesztközpont.)


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ényekbl 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.


A teszt lefedettség– Kód alapú lefedettség

• A kód alapú lefedettség mérésénél azt határozzuk meg, hogymilyen mennyiség kód lett letesztelve az összes kódhozviszonyí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ásifeltételeket ellenrizzük.

• Adat alapú lefedettség- mérés: a cél az adatok állapotának ellenrzése a mvelet során, pl.egy adat elem definiálva van a használata eltt.

» Teszt lefedettség = Is/TLIC, ahol:

» Is a végrehajtott elemek száma, mint utasítások, kód elágazások, kód útvonalak, döntésipontok 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.”


Tesztelési technikák, teszt típusok

✔ A hibák megtalálása szempontjábólvalószín leg az lenne ideális, ha a rendszertminden lehetséges esetben kipróbáljuk,minden elképzelhet esetet, programágat,funkciót… végigjárunk. Ez nagyon sok idt,költséget igényel, nem is reális elvárás.

✔A tesztelési technikák segítenek „válogatni” atesztelend elemek között (fontos elem,sorrend, idpillanat…)


Szeletelés

✔M. Weiser

✔Alapötlet: hibakereséskor a programozóktulajdonképpen szeletelnek, vagyis azokat arészeket választják ki a programból, amelyekegy adott utasításra hatást gyakorolnak.

✔A hagyományos debuggolással szemben, aszeletelés alkalmazásánál csak a szeletutasításait kell debuggolni


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 inputesetén minden V-beli változóra az I helyenugyanazt az értéket adja, mint P.


Szeletelés

✔ Statikus szelet, példavar 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


Szeletelés

✔Program-függés gráfja (PDG)– irányított folyamgráf

– létezik egy kiinduló csomópont, amelybe él nemfut be

– a P program minden utasítása egy csomópont aPDG-ben

– Ha a B csomópont adat vagy vezérlésfügg az Acsomóponttól, akkor van egy irányított él A-bólB-be


Szeletelés

✔Példa, PDGentry

sum:=0 j:=2

(Forrás: A tesztelés alapjai. Tanfolyami anyag. IQSOFT-JohnBryce Oktatóközpont, IQSOFt -Alvicom tesztközpont.)

Read(n)

Write(sum) While n>0

n := n+1j:= j +2sum:= sum+j

kontrollfüggés

adatfüggés


Szeletelés

✔A PDG-t a szeletek meghatározásánálhasználjuk fel.

✔A szeletelési kritériumban lev utasításokbólés változókból kiindulva, a szelet egygráfelérési algoritmussal megkapható


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


Szeletelés

✔Példa– Szeletelés az Y2K problémában

– Kiindulva egy dátum típusú utasításból, meglehet határozni az összes utasítást, amelyre azadott utasítás hatással van

– Ezt kihasználva, automatikusan lehettesztadatokat generálni, amelyek nagybiztonsággal megtalálják a 2000., év hibáit.

– Igy született az Y2K.O.


Teszt-típusok

✔ Fehér-doboz teszt

✔ Fekete -doboz teszt

✔ Inspekció, szemle

✔ Regressziós teszt

(http://issco-www.unige.ch/ewg95/node79.html)


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


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 elre meghatározottszabályok alapján, a program összehasonlítása a specifikációjával vagydokumentációjával.


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égeskörnyezetbeli viselkedésének elemzése avégrehajtás eltt, alatt és után” (Hausen,1984)


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, vagyanélkül


Teszt-típusok

✔Inspekció

✔Szemle


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 teszteltprogramban– 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 kellkiválasztani - sok adminisztráció…


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észekblhatá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 amó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


Teszteset

✔A teszt bemeneteknek és a várt eredményekneka halmaza

✔Az input lehet menükiválasztás is (tehát amegfelel végrehajtási út kiválasztása)

✔Az eredmények ellenrzése– automatizált

– manuális


Tesztesetek

✔…származtatása felhasználói esetekbl– 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érhetség) és akonfigurációs követelmények a tesztelt rendszerkiegészít viselkedéseit és jellemzit határozzákmeg. Ezek a kiegészít specifikációbólderülhetnek ki.


Tesztesetek✔ …származtatása teljesítménytesztekhez

– Els dleges bemenet: a kiegészít specifikáció nem-funkcionáliskövetelményei

– Irányelvek:

• bizonyosodjunk meg arról, hogy a specifikációban szerepl mindenolyan állításra, amelyik teljesítmény kritériumot fejez ki, van legalábbegy teszteset azonosítva

• bizonyosodjunk meg arról, hogy minden kritikus használati esetre vanlegalá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, atranzakciók száma és típusa

– a környezet jellemzi (hardver, szoftver, hálózati konfiguráció)


Tesztesetek

✔…származtatása biztonsági / hozzáférésitesztekhez– Bemenet: szereplk, használati esetek.

– Kritikus a biztonság! Csak a megadott szereplkhajthassák végre a megadott használati eseteket,de k igen (pl. pénzkiadó automata)


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, file-

szerver…)

• új installáció

• teljes installáció

• custom installációk

• upgrade installációk


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


A tesztelési stratégia kidolgozása

✔ Adjon összefügg, elméleti megalapozottságú leírásta tesztekrl

✔ Adjon gyakorlati útmutatást is a tesztvégrehajtásához (ki, mit , mikor, hogyan, miért…)

✔ Jó esetben egy cégnek van átfogó tesztelésistratégiája (kritériumok, technikák, eszközök,elfogadható értékek a tesztelésben…), amely akonkrét esetekre szabható


A teszt tervezése

Tesztterv

Teszt specifikáció

TeszteljárásTeszt szkript

Teszt végrehajtása

Tesztelési napló Hibaleírás

Tesztelési jelentés

Teszteset

Teszt tervelkészítése

Teszt tervezése

Teszt eredménykiértékelése

Teszt eljárásokmegvalósítása

7HV]W�WHYpNHQ\VpJ 'RNXPHQWiFLy

•A tesztelésselkapcsolatostevékenységekés azok idbelisorrendjehasonlóak aprogramfejlesztésfolyamatához.


Tesztadatok

✔A teszteléshez szükségünk van jólmeghatározott tesztadatokra,

• amelyek el re meghatározott értékeket tartalmaznak,annak érdekében. hogy a tesztesetek végrehajtásasorán elre tervezhet, ellen rizhet eredményeketkapjunk, továbbá,

• amelyek értékei kellképpen szélsséges határokközött mozognak a program rendszertervbenspecifikált jellemzinek vizsgálatához.


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 jelents.

– Egységteszt deríti ki a legtöbb hibát.


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 jelentség )

• Fehér-doboz módszer (az A egységben van egyutasítás, amely hat a B egységben lev utasításra, ésfordítva)

• Integrációs teszt deríti ki a legköltségesebb hibákat.


Rendszerteszt

✔A teljes rendszert teszteljük a specifikációvalszemben.– Funkcionális teszt

– Terheléses teszt

– Felhasználói teszt: a teljes rendszert a felhasználóvagy megbízottja teszteli


Inspekció

✔Csökkentheti a tesztelési költségeket, akár afejlesztési költségek 20-30 %-ra.

✔ Elmaradhat az egységteszt és integrált teszt,csak a rendszertesztet kell elvégezni

✔Pl: Rendszerterv inspekciója akövetelményekhez viszonyítva, kódinspekciója a rendszertervvel összevetve stb.


Átvételi teszt

✔Általában a felhasználó által elvégzett, ateljes rendszerre kiterjed teszt, amelynekeredményeképpen a felhasználó elfogadja ésátveszi a rendszert.


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 minsítésének hibás specifikációja vagy a rosszulmegvá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 tesztkörnyezetet, a teszt lépéseinek végrehajtási sorrendjét stb.), majd meg kellismételni a tesztet.


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 rendszertervkövetkezménye.

✔ Hiba felmerülése esetén a projekt vezetje dönt a további lépésekrl.Elrendelheti újabb, a hiba keletkezésének körülményeit pontosabbanfeltáró tesztek elvégzését, visszaadhatja a tesztelt programot a hibakijavításáért felels személynek vagy apróbb hibák esetén azokkijavítását az átvevvel egyeztetve késbbre halaszthatja. Az ilyendöntéseket bizonylatolni kell (pl. bejegyzés a teszt naplóba, e-mail stb.)


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 elfordult, é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 fejldés riport: a tesztelés végrehajtásának eredményétmutatja meg az iterációk számán és teszt ciklusokon keresztül.


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ámokonalapulhatnak:

• 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égrehajtotttesztesetek és teszteljárások száma. A teszt lefedettség mindig a hibakritériummal együtt használatos.

• Teljesítmény: egy megadott tevékenység végrehajtási ideje (funkciók, mveletek,egyéb események). Ez a kritérium azoknál a teszteknél használatos, ahol az idkritikus tényez.

• Teljesítés. Ez a kritérium azt jelzi, hogy egy adott készítménynek vagy folyamattevékenységnek/lépésnek milyen mértékben elégíti ki az elfogadott szabványtvagy irányvonalat.

• Elfogadhatóság és elégedettség: szubjektív érték, mely a használhatóságra és azesztétikus megjelenésre vonatkozik.


A tesztelés dokumentálása

✔Tesztelési terv

✔Teszt esetek

✔Teszt szkriptek

✔Teszt adatok

✔Tesztelési jegyzkönyvek

✔Hibalista, hibák bizonylatolása

✔Átadás/ átvételi jegyzkönyv



Tesztterv

Teszt specifikáció

TeszteljárásTeszt szkript

Teszt végrehajtása

Tesztelési napló Hibaleírás

Tesztelési jelentés

Teszteset

Teszt tervelkészítése

Teszt tervezése

Teszt eredménykiértékelése

Teszt eljárásokmegvalósítása

7HV]W�WHYpNHQ\VpJ 'RNXPHQWiFLy


A tesztelés dokumentálása✔Tesztterv

– A tesztterv leírja a tesztelésbe bevont programelemeket, a tesztelésicélokat és az alkalmazni kívánt tesztelési módszereket /megközelítéseket. Ismerteti a teszteléssel kapcsolatostevékenységeket, azok felelseit, fázisainak határidejét, atesztkövetelményeket és a tesztelés során létrehozandódokumentumokat. Rögzítésre kerül a tesztkörnyezet (hardver ésszoftver), valamint a tesztelés tervezéséhez és lefolytatásáhozszü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.



✔ 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ákegy 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észletesutasításokat tartalmaznak a teszt indítási állapotának a beállítására, avégrehajtás lépéseire és az eredmények kiértékelésére. Egy

teszteljárás több tesztesethez is tartozhat.



✔Hibaleírás– A hibaleírás dokumentumban a tesztesetekben definiált elvárt

eredményektl 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éseredmé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 atesztesetekben elírtaktól való eltéréseket.


A teszt végrehajtásánakbizonylatolása

✔A végrehajtás során a következinformá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.


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 felels személy

• javítás dátuma.


A tesztelt szoftver teljesítménye✔ … tesztelési dokumentumokkal (ból) vizsgálható

✔ Az teljesítményre vonatkozó mérszámokkal az adott szoftverteljesítménye határozható meg a válaszid, a végrehajtási folyamat, am 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 idejelfogá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 egyadott szereplnél és vagy use case-nél.

• Százalékos riport – összegyjtö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öbbadatcsoportja közötti különbözsé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


Átadás-átvételi jegyzkönyv

✔Felhasználó és szállító közötti szerzdésesfeltételek teljesülésekor


A tesztelési folyamat minsége

✔Általában elmondható, hogy a tesztelésifolyamat akkor jó:

• ha a hibák a fejlesztés minél korábbi szakaszábankiderülnek és kijavítódnak,

• ha a kód alapú lefedettség megfelel,

• ha a elkészült termék és a mszaki folyamat azelfogadási kritériumoknak megfelel

• ha a vevi 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.


Mir l volt szó

PMfolyamat

Term

ék

Definíció

Min ségi attribútum

Mér szám

Mszaki

folyamat

Documents

Szoftver min ség és menedzsmentkondor/rszf/SWMM/ELOADASOK/SzMM15-teszteles1-1.pdf · Dr. Balla Katalin Szoftver min ség és menedzsment - 15. 3 A tesztelés … a rendszer próbafuttatása