SW Minosegbizt

Dr.
Sziray Jzsef
Dr. Beny Balzs
Heckenast Tams
SZOFTVERMINSGBIZTOSTS
Kszlt a HEFOP 3.3.1-P.-2004-09-0102/1.0 plyzat tmogatsval.
Szerzk: Dr. Sziray Jzsef

Szchenyi Istvn Egyetem,
Informatika Tanszk
Dr. Beny Balzs
Informatika Tanszk
Heckenast Tams
Informatika Tanszk
Lektor:
Gaul Gza
Informatika Tanszk
Szerzk, 2007
Szoftver-minsgbiztosts
A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom
A dokumentum hasznlata
Vissza
A dokumentum hasznlata
Mozgs a dokumentumban
A dokumentumban val mozgshoz a Windows s az Adobe Reader megszokott elemeit s mdszereit hasznlhatjuk.
Minden lap tetejn s aljn egy navigcis sor tallhat, itt a megfelel
hivatkozsra kattintva ugorhatunk a hasznlati tmutatra, a tartalomjegyzkre, valamint a trgymutatra. A s a nyilakkal az elz s a kvetkez oldalra lphetnk t, mg a Vissza mez az utoljra megnzett oldalra
visz vissza bennnket.
Pozcionls a knyvjelzablak segtsgvel
A bal oldali knyvjelz ablakban tartalomjegyzkfa tallhat, amelynek
bejegyzseire kattintva az adott fejezet/alfejezet els oldalra jutunk. Az
aktulis pozcinkat a tartalomjegyzkfban kiemelt bejegyzs mutatja.
A tartalomjegyzk hasznlata
Ugrs megadott helyre a tartalomjegyzk segtsgvel
Kattintsunk a tartalomjegyzk megfelel pontjra, ezzel az adott fejezet

els oldalra jutunk.
Keress a szvegben
A dokumentumban val keresshez hasznljuk megszokott mdon a

Szerkeszts men Keress parancst. Az Adobe Reader az adott pozcitl kezdve keres a szvegben.
Vissza
Tartalomjegyzk
Vissza
Tartalomjegyzk
1. Bevezets ........................................................................................ 6
2. Szoftverminsgbiztosts............................................................ 9
2.1. Minsgi koncepcik................................................................................... 9
2.2. Minsgbiztostsi fogalmak .................................................................... 11
2.3. Szoftverminsg (Software quality) ........................................................ 11
2.4. Szoftver-mrszmok (metrikk) ............................................................ 12
2.5. Szoftver-megbzhatsg............................................................................ 19
3. Biztonsgkritikus rendszerek....................................................... 22
3.1. Alapfogalmak.............................................................................................. 22
3.2. Minsgi s megbzhatsgi kvetelmnyek.......................................... 23
3.3. Rendszerstruktrk.................................................................................... 27
3.4. A hardver redundancia megvalstsa..................................................... 29
3.5. A szoftver redundancia megvalstsa.................................................... 31
3.6. Az ELEKTRA tpus vezrlrendszer felptse s mkdse ......... 35
4. Szoftver-tesztelsi mdszerek ...................................................... 42
4.1. Tesztelsi alapfogalmak............................................................................. 42
4.2. Hibamodellek s rvnyessgi krk ...................................................... 43
4.3. A tesztek megtervezse ............................................................................. 45
4.4. A programtesztels pszicholgija s gazdasgossga (Glenford
Myers elvei)................................................................................................. 47
4.5. Funkcionlis tesztels ................................................................................ 53
4.6. Strukturlis tesztels .................................................................................. 63
4.7. Tesztminsgi mrszmok..................................................................... 71
4.8. A mdszerek sszekapcsolsa.................................................................. 75
5. Tesztelsi stratgik s folyamatok ............................................. 76
5.1. Szoftverfejlesztsi modellek ..................................................................... 77
5.2. Verifikci s validci.............................................................................. 85
5.3. A verifikci s a validci fzisainak tervezse.................................... 88
5.4. Egysgek, modulok tesztelse .................................................................. 91
5.5. Integrcis tesztels s rendszertesztels .............................................101
5.6. Validcis tesztels ..................................................................................105
5.7. A tesztels kltsge..................................................................................108
Vissza
Tartalomjegyzk
Vissza
5.8. Bizonylatols.............................................................................................111
5.9. A formlis mdszerek szerepe ...............................................................113
6. Objektum-orientlt szoftvertesztels ..........................................118
6.1. Az OO rendszerek jellemzi tesztelhetsgi szempontbl ...............118
6.2. Tesztels nem OO rendszerekben ........................................................120
6.3. Hagyomnyos tesztelsi mdszerek alkalmazsa OO
krnyezetben ............................................................................................121
6.4. OO rendszerek tesztelsi techniki .......................................................122
6.5. Mrtkszmok hasznlata .......................................................................125
6.6. Konkrt tesztel rendszerek...................................................................127
Felhasznlt irodalom ...........................................................................................130
Vissza
Bevezets
Vissza
1. Bevezets
Az informatikban hatalmas fejlds ment vgbe az elmlt negyedszzadban. Aki ezt szakmailag vgiglte, szinte mr maga sem tudja elhinni, ami a
25 vvel ezeltti vilgban volt. A fejlds pontosan nyomon kvethet a
szmtgpek s szmtgp-hlzatok hardvernek vonaln. Ez a mszaki, tervezstechnolgiai s gyrtstechnolgiai fejlds megkrdjelezhetetlenl impozns. A nyomon kvethetsg elssorban annak ksznhet,
hogy a hardver ellltsi folyamatai szigoran kttt, meghatrozott
rendben, jl bevlt, kitapasztalt folyamatokba szortva mehetnek vgbe. A
be nem vlt vagy tl drga j technolgik, irnyzatok igen hamar kiszorulnak a piacrl, s feledsbe merlnek. Ilyenek voltak pldul a buborkmemrik, vagy a kszb logikn alapul digitlis ramkrk.
Az informatikai rendszerek msik szerves sszetevje a szoftver. Ami
azt illeti, a szoftver vonalon vgbement fejlds mg dntbben szmt
bele a mai helyzet kialakulsba. Ezen a tren sokkal kevesebb volt a ktttsg, mint a hardvernl. A fejlesztsbe jval szlesebb rtegek tudtak s
tudnak ma is bekapcsoldni. Ezen tl mg olyan orszgok is, mint Magyarorszg pldul, amelyek a hardverfejlesztsbe nem tudnak beleszlni.
Az itt munklkod szakemberek szma rohamosan nvekszik, nagyon sok
a szertegaz egyedi fejleszts, mg akkor is, ha ugyanazon a hardver platformon mennek vgbe. A fejleszts nagyobb szabadsgfoka teszi lehetv
a szoftver rendszerek belthatatlan mrtk kibontakozst, fejldst,
ami a mretekben, vagyis az utastsok szmban, valamint a bonyolultsgban s az ehhez kapcsold teljestmnyben nyilvnul meg.
A nagy szabadsgfok, valamint az egyedi fejleszts s a nvekv bonyolultsg ugyanakkor megnveli a veszlyt annak, hogy a szoftver rendszer hibsan mkdik. A hiba addhat a specifikci sorn elkvetett tvedsbl, vagy aminek nagyobb az eslye, a programozs sorn elkvetett
tvedsbl. A hibk kiszrse s kijavtsa a fejleszts elrehaladtval egyre nagyobb rfordtst ignyel. Az ilyen rfordts mrtke exponencilisan
nvekszik. Ezrt nagy jelentsge van annak, hogy a fejlesztsi folyamatokat minl szigorbb technolgiai rendben, minl alaposabban megtervezve
s kivitelezve hajtsuk vgre.
A szoftver rendszerek megbzhat zemeltetse, felhasznlsa teht
szigor kvetelmnyeket tmaszt a fejlesztskre vonatkozan. Ebbe szorosan beletartozik az a minsgbiztostsi technolgia, amely a teljes fej-
Vissza
Bevezets
Vissza
lesztsi folyamatot vgigkveti, a specifikci megadstl a ksz rendszer

zembe helyezsig. A minsgi s megbzhatsgi kvetelmnyek kielgtse szksgess teszi azt, hogy a szoftvert n. verifikcis s validcis eljrsoknak vessk al. A verifikciban az egyes fejlesztsi fzisok kztti
sszhang ellenrzse a feladat, mg a validcival a vgs rendszer ellenrzsre kerl sor, annak eldntsre, hogy az mennyire felel meg a felhasznl ltal elrt kvetelmnyeknek.
A verifiklsi-validlsi tevkenysg pontos vgrehajtsa a kvetkez
fbb elnykkel jr:
Segt annak eldntsben, hogy elkezdhetjk-e a fejleszts soron kvetkez fzist.
A fejlesztsi folyamat korai szakaszban mutathat ki problmkat, hibkat.
A szoftver minsgre vonatkozan mindvgig tmpontokat, adatokat
szolgltat.
Kimutathatja mr korn azt is, hogy a szoftver nem teljesti a kvetelmnyeket.
Mindez a szoftver elre megtervezett ellenrzsvel, intenzv tesztelsvel
kell hogy jrjon az egyes fzisokban.
Ebben a knyvben azokkal a tmkkal, mdszerekkel foglalkozunk,
amelyek a szoftverfejleszts minsgbiztostshoz kapcsoldnak, belertve a fejlesztsi fzisokat ksr tesztelsi, verifiklsi mveleteket, msrszt
pedig a ksz rendszerek tvtelvel kapcsolatos validlsi mveleteket.
A knyv 2. fejezete a szoftver-minsgbiztosts ltalnos krdseivel,
az alapvet koncepcik s fogalmak ismertetsvel foglalkozik.
A 3. fejezet az n. biztonsgkritikus rendszereket trgyalja. Az ilyen informatikai rendszereknl a legfontosabb kritrium a biztonsgot megkvetel
mkds, zemels. A fejezetben a biztonsgkritikus rendszerek tulajdonsgait, a rjuk vonatkoz minsgi s megbzhatsgi kvetelmnyeket,
valamint a megvalstsban alkalmazott rendszerstruktrkat foglaljuk
ssze.
A 4. fejezet a legfontosabb szoftver-tesztelsi mdszereket vonultatja
fel. Ezen bell bemutatja a figyelembe vett szoftver-hibk krt, valamint
a hibk felfedsre alkalmazhat teszttervezsi megoldsokat. Mint ismeretes, a mdszerek lnyegben kt csoportba sorolhatk: Az egyik csoportba a mkd program kls funkcionlis megnyilvnulsainak vizsg-
Vissza
Bevezets
Vissza
lata tartozik, mg a msikba a programok bels struktrjnak alapjn trtn vizsglatok.

Az 5. fejezet a tesztelsi stratgikat s az ezeket megvalst folyamatokat trgyalja. Minderre a rendszerfejlesztsi s felhasznlsi folyamat
letciklusa fzisainak bemutatsval egytt kerl sor. A fejezet foglalkozik
a verifikci s a validci vgrehajtsval, az egysgek s modulok tesztelsvel, a modulok sszeintegrlsa sorn alkalmazand tesztelssel, majd
a teljes rendszer tesztelsvel, ill. validlsval.
A 6. fejezet az objektum-orientlt szoftverek ellenrzsnek megkzeltsi mdjait, megoldsait foglalja ssze. Az objektum-orientlt fejleszts az osztly szint tesztelst, valamint az osztlyok kztti tesztelst
kveteli meg. Itt felhasznlhatk mindazok a megoldsok, amelyek a hagyomnyos fejleszts (n. procedurlis tpus) szoftverekhez alkalmasak,
de ezen tlmenen szmos olyan mdszerre is szksg van, amelyek kifejezetten az objektum-orientlt szoftverekhez kapcsoldnak.
A knyv vgn a felhasznlt irodalom felsorolsa tallhat.
Vissza
Szoftverminsgbiztosts
Vissza
2. Szoftverminsgbiztosts
2.1. Minsgi koncepcik
A minsg tgabb rtelemben az emberisg trtnelmvel egyids, azonban korszer rtelmezse a mlt szzad elejn jelent meg, az ipari termels
elterjedsvel. A minsg s a minsggy igazi rtelmezse csak napjainkban alakul ki. A korszer minsgfogalom a termelsben s a fogyasztsban rdekelt szemlyek, ill. a trsadalom rtktlete arra, hogy a termelsi-fogyasztsi folyamat mennyire elgti az ignyeket. Ebbl kvetkezen
a minsg rtk. A minsggy a termelsi-fogyasztsi folyamat minsgnek szablyozsval foglalkozik. Napjainkban egyre nagyobb hangsly
fordtdik a minsgbiztostsra, azaz a termels s a fogyaszts magas
sznvonal minsgre, amely a fogyasztvdelem, s a fogyaszti ignyek
kielgtse mellett a termel nyeresgt is eredmnyezi. Mindez nem csak a
vllalkozs gazdasgi felemelkedst jelenti, hanem hasznos a trsadalom
szmra is.
2.1.1. A minsg filozfiai rtelmezse
A minsggy kzponti fogalma az igny-kielgtsi folyamat minsge. A

minsg filozfiai szempontbl ktflekppen rtelmezhet: ltalnos, s
rtkszemlletben.
A minsg ltalnos filozfiai rtelmezse a dolgok tulajdonsgokkal
trtn lersa.
A minsg rtkszemllet filozfiai rtelmezse szubjektv, rtkrenden alapul, szemlyhez kttt. A minsg rtelmezshez meg kell
fogalmazni a vizsglati szempontokat, meg kell mrni a tulajdonsgok
rtkt, meg kell hatrozni az rtkrendet, s meg kell adni az objektum minsgt (ez az rtkrend alapjn az objektumra vonatkoz rtktlet, minsts).
2.1.2. A minsg fogyaszti rtelmezse
Az igny-kielgtsi folyamat, ezen bell elssorban a termk s a fogyasztsi folyamat minsgnek fogyaszti rtelmezse a minsg rtkszemllet filozfiai rtelmezsn alapul. A fogyasztsi folyamat minsgt a
fogyaszt szempontjbl azok a funkcik hatrozzk meg, amelyek alkalmass teszik a termket a fogyaszts sorn a fogyaszt ltal ignyelt funk-
Vissza
Vissza
10
cik kielgtsre, vagyis biztostjk a fogyasztsi folyamat megfelel minsgt. Ez mskpp a termk hasznossgnak is nevezhet.
A fogyaszti minsg sok mindenre kiterjed, gy a fogyasztsi cikkek
esetn a tnyleges fogyasztsi ignyek mellett tartalmazza tbbek kztt a
cmkzs, a csomagols, a trolhatsg, a megismerhetsg, a hasznlhatsg, a karbantarthatsg, a szerelhetsg, a tartalkalkatrsz-ellts, a szervzellts s a garancia krdskrt.
2.1.3. A minsg termeli rtelmezse
Az igny-kielgtsi folyamat, ezen bell elssorban a termelsi folyamat

minsgnek termeli rtelmezse a minsg rtkszemllet filozfiai
rtelmezsn alapul. Az igny-kielgtsi folyamat termeli minsge teht
attl fgg, hogy a termelsi folyamat s a termk a termeli rdekeltek
szempontjbl megfelel-e, gy a termels folyamata az rdekeltek szmra
hasznos-e, gazdasgos-e, kellen veszlytelen-e.
2.1.4. A minsg trsadalmi rtelmezse
Az igny-kielgtsi folyamat minsgnek trsadalmi rtelmezse szintn

a minsg rtkszemllet filozfiai rtelmezsn alapul. Az ignykielgtsi folyamat trsadalmi minsge teht attl fgg, hogy megfelel-e
a trsadalom szmra, vagyis a termelsi s fogyasztsi folyamatok a trsadalom szmra kellen hasznosak-e s vdelmi, klnsen letvdelmi,
valamint krnyezetvdelmi szempontbl veszlytelenek-e.
Az Eurpai Uni s a fejlett orszgok minsggyi szablyozsi gyakorlatban egyre nagyobb hangslyt kap a minsg trsadalmi rtelmezse.
A minsg trsadalmi rtelmezse alapjn teht a minsggy magban
foglalja a fogyasztvdelem mellett a biztonsgtechnikt, a munkavdelmet, az let s egszsgvdelmet, az erklcsvdelmet, a krnyezetvdelmet, tovbb a vagyon- s a tzvdelmet is. A minsg trsadalmi rtelmezsben, felfogsban a fejlett orszgokban a vdelem mellett, az elmozdts s a tmogats is benne foglaltatik.
2.1.5. A minsg minsggyi rtelmezse
Az igny-kielgtsi folyamat minsge korszer minsggyi szemlletben egyrszt a termk s a fogyasztsi folyamat fogyaszti minsgt, azaz
a fogyaszti ignyek kielgtst, msrszt a termelsi folyamat s a termk
termeli minsgt, a hasznossgot, valamint az igny-kielgtsi folyamat
trsadalmi minsgt, ezen bell elssorban a vdelmet s a tmogatst
foglalja magban.
Vissza
10
Vissza
11
A j minsg ngyfle kvetelmny egyenslya (J. Cons megfogalmazsban):
mszaki (fizikai, kmiai, biolgiai stb.) (technical)

erklcsi (ethical)
piaci (marketing)
gazdasgi (economical)
Cons rtelmezse a megfelelsgre, a trsadalmi rdekekre, a fogyaszti s

a termeli ignyekre utal.
2.1.6. A minsg mrse
A minsg, szubjektv volta miatt nehezen mrhet. A mrs nehzsgt a

kvetkez problmk okozzk:
a minsget meghatroz tulajdonsgok mrse ltalban nem objektv
a minsget meghatroz funkcik, tulajdonsgok jelents rsze nem
mrhet
a minsts szubjektv, mivel a minsg nem ms, mint az emberek
rtktlete, s nincs trsadalmilag elfogadott rtkrend
a minsts idben s krnyezettl fggen vltoz
sokan megfelel httr ismeret hinyban minstenek, ami a minsts jsgt ronthatja
A minsg alapvet rtk, ezrt a mrst nehezt problmk ellenre is
mrni kell, amennyire ez lehetsges.
2.2. Minsgbiztostsi fogalmak
2.3. Szoftverminsg (Software quality)
A szoftver is egy termel-folyamat vgtermke, ezrt a minsgbiztosts
ezen esetben is elengedhetetlen felttel. Napjainkban mr egyre kevsb
fogadnak el gyengbb minsg termket. A tapasztalhat szoftver-krzis
egyik oka a minsgi kvetelmnyek vltozsa, a minsgi termkek kzppontba kerlse. A minsggyi menedzserek feladata, hogy a megkvetelt (elrt) minsget biztostsk. A minsgbiztosts jelenti a megfelel eljrsok, s szabvnyok definilst, valamint annak ellenrzst, hogy
ezeknek megfelelen trtnik-e a gyrts. A szoftverminsg egy tbbdimenzis fogalom, amit nem egyszer definilni. Klasszikus rtelemben a
Vissza
11
Vissza
12
minsg azt jelenti, hogy a fejlesztsi folyamat a specifikcis kvetelmnyeket kielgti (Crosby 1979). Idelis esetben ez a definci minden termkre alkalmazhat lehetne, de a szoftverek esetben nehzsgek akadnak
ezzel:
A specifikcinak a felhasznl ltal kvnt termk karakterisztikjt
kell kvetni, azonban a fejlesztsi szervezetnek is vannak kvetelmnyei, amelyek nem szerepelnek a specifikciban.
A szoftver specifikcik rendszerint nem teljesek.
A minsg tervezsnek kritikus pontja a fontos minsgi jellemzk kivlasztsa, s annak megtervezse, hogy ezek hogyan rhetk el. A szoftverminsg menedzserek 3 fajta tevkenysgrt felelsek:
Minsgbiztosts (quality assurance): szervezeti eljrsokat, valamint
szabvnyokat kell rgzteni, amelyek j minsg szoftverekhez vezetnek.
Minsgtervezs (quality planning): ki kell vlasztani az alkalmas eljrsokat, s szabvnyokat, s ezeket illeszteni kell a specilis szoftver
projektekhez.
Minsgszablyozs (quality control): biztostani kell, hogy ezeket az
eljrsokat s szabvnyokat kveti a szoftverfejleszt csapat
A szoftverminsget alapveten meghatroz sszetevk:
Minstsi, illetve kirtkelsi szempontok
Minsgfaktorok (hordozhatsg, megbzhatsg, hatkonysg, felhasznlsi knyelem, tesztelhetsg, rthetsg, mdosthatsg), minsgjegyek
Szoftverjellemzk (eszkzfggetlensg, teljessg, pontossg, konzisztencia, hatkonysg, elrhetsg, strukturlhatsg, dokumentltsg,
tmrsg, rthetsg, olvashatsg, bvthetsg)
Szoftvermrtkek, szoftver-mrszmok
2.4. Szoftver-mrszmok (metrikk)
A szoftver-merszmok (metrikk) a szoftver rendszerekhez, folyamatokhoz, vagy kapcsold dokumentcihoz tartoznak. A metrikk kt osz-
Vissza
12
Vissza
13
tlyba sorolhatk: az egyik az ellenrz metrika (control metrics), a msik

a prediktor metrika (predictor metrics) (2.1. bra).
szoftver termk
(software product)
szoftver folyamat
(software process)
prediktor mrsek
(predictor measurements)
ellenorzo mrs
(control measurement)
menedzsment dntsek
(management decisions)
2.1. bra. Prediktor s ellenrz metrikk

Az ellenrz metrikt a szoftver folyamatok ellenrzsnek kezelsre
hasznljk (pl. a lemezhasznlat, vagy a felhasznlhat, illetve eltelt id).
Ezen mrszmok becslse hasznlhat a projekt tervezsi folyamatok
finomtsra. Az ellenrz metrika informcit nyjt a folyamat minsgrl, s ezrt kapcsoldik a termk minsghez.
A prediktor metrika a termk jellemzinek mrshez tartozik, amely a
termk minsgnek elzetes megjsolsra hasznlhat. Pldul a termk
kziknyvnek olvashatsga elre jsolhat az n. Fog-index vizsglatval, vagy pldul a szoftver komponensek nyomon kvetsnek egyszersge megjsolhat a ciklomatikus komplexits mrsvel.
Idelis esetben a prdiktor metrika megengedi, hogy a szoftver nhny kls tulajdonsgnak rtkt elre megjsoljuk. A kls jellemzk
olyan dolgok, amelyek csak a szoftver zembe helyezse utn fedezhetk
fel. A bels jellemzket azonban kzvetlenl a szoftverbl hatrozhatjuk
meg. A kls jellemzk kzvetlenl nem mrhetk, ezrt feltteleznnk
kell, hogy ltezik kapcsolat akztt, amit mrni tudunk, s amit tudni akarunk.
A 2.2 bra mutatja a fontos kls minsgi jellemzket, valamint azokat
a bels minsgi jellemzket, amelyek mrhetk, s amelyek kapcsoldhatnak a kls jellemzkhz. (Az itt lthat kapcsolati sma Kitchenham-tl
szrmazik, USA, 1990) Az bra feltnteti a kls s bels jellemzk kzti
Vissza
13
Vissza
14
kapcsolatot, azonban a kapcsolat milyensgrl nem mond semmit. Ahhoz,

hogy a bels tulajdonsgok mrse hasznos prediktora legyen a bels szoftver karakterisztiknak, a kvetkez hrom felttelnek kell teljeslnie:
A bels jellemzket pontosan kell mrni.
A mrt s a kls tulajdonsgi jellemzk kztt kapcsolatnak kell lenni.
A kapcsolat rthet, vals, valamint egy formulval, vagy modellel
lerhat legyen.
Mindehhez mg annyit fznk, hogy egy szoftver bels minsgi jellemzi
elssorban a fejlesztk szempontjbl fontosak, mg a kls jellemzk a
felhasznlk szempontjbl.
Nyomonkvethetosg
(Maintainability)
Eljrs paramterek
szma
Megbzhatsg
(Reliability)
Ciklomatikus komplexits
Hordozhatsg
(Portability)
Programmret kdsorban
Hibazenetek szma
Hasznlhatsg
(Usability)
Felhasznli segdlet
hossza
2.2. bra. Lehetsges kapcsolatok

a bels s kls szoftverjellemzk kztt
A modell formalizls az sszegyjttt adatok alapjn a modell funkcionlis formjnak meghatrozst jelenti (pl. lineris, vagy exponencilis stb..),
a modellben szerepl paramterek meghatrozst, ezek belltst a rendelkezsre ll adatok hasznlatval. Ezltal a modellfejleszts statisztikai
technikai gyakorlatot kvetel meg, teht ebbe a folyamatba statisztikusokat
is be kell bevonni.
Jelenleg a szoftveriparban igen kis mrtkben hasznlnak csak metrikkat, azonban a minsgi fejleszts fontos szerepe miatt egyre inkbb
Vissza
14
Vissza
15
megn az igny erre. Szmos nagy cg (pl. a HP, AT&T) gyjti s hasznlja ezeket a mrszmokat a fejlesztsek folyamn. A kzppontban leginkbb a programhibk, valamint a verifikcis s validcis eljrsokhoz
tartoz mrszmok llnak. Ezrt ahogyan risi a hajlandsg a mennyisgi informcis fejlesztsekre, gy nvekszik a metrikk ipari hasznlatnak is a fontossga.
2.4.1. Termk minsgmrtke
A szoftvermrsekben rszt vev szervezeteknek sokkal inkbb kell tmaszkodni a loklisan gyjttt adatokra, mint megbzni a kls tapasztalatokban. Ahhoz, hogy felfedezzk, hogy egy bizonyos metrika egy termk
minsgnek hasznos prediktora, egy minsgbiztost csoportnak kell
kirtkelni a metrikt, loklis adatokat hasznl szisztematikus mdon, a
helyi eljrsokat s szabvnyokat is figyelembe vve.
A 2.3. bra mutatja a mrszmok hasznlatnak folyamatt a minsg
elrejelzsre. Alapveten a rendszer minden egyes komponenst fggetlenl vizsgljk, s a mrszmok klnbz rtkeit sszehasonltjk,
mind egymssal, mind pedig egy rgebbi projektbl szrmaz adatokkal.
Rendhagy mrseket kellene hasznlni, hogy kzppontba a minsgi
problmkkal rendelkez komponensek minsgbiztostsa kerljn.
rendhagy komponensek
vizsglata
mrsek vlasztsa
a kirtkelendo
komponensek
kivlasztsa
rendhagy mrsek
meghatrozsa
komponensek
karakterisztiikjnak
mrse
2.3. bra. A termk mrsnek folyamata
Vissza
15
Vissza
16
Ilyen metrikkat hasznlnak tervezs, valamint program s dokumentci

kirtkelsre. A tervezs kirtkelsnek metrikjt alkalmazzk a specifikcikban hasznlt grafikus jellsekben is. A dokumentcis metrika,
mint a Fog-index alkalmazhat termszetes nyelv specifikcikban.
2.4.2. A tervezs minsgmrtke
Sok fontos tervezsi tulajdonsg van, de a legfontosabb ezek kzl a karbantarthatsg. A minsgbiztosts ezrt leginkbb a hibadetektlssal,
valamint a karbantarthatsg kirtkelsvel foglalkozik. A karbantarthatsgot nem tudjuk kzvetlenl mrni. A tervezs karbantarthatsga
kapcsoldik:
A kohzihoz (Cohesion): A komponens rszei milyen szorosan kapcsoldnak?
A csatoldshoz (Coupling): Mennyire fggetlen a komponens?
Az rthetsghez (Understandability): Milyen knny megrteni a
komponens funkcijt?
A beilleszthetsghez (Adaptability): Milyen knny a komponenst
lecserlni?
A kohzi egy egyszer minsgi fogalom, de nehz a kirtkelse a komponens cljnak megrtse nlkl. A komponensek csatoldsa mrhet a
komponensek kzti kapcsolatok szmnak figyelsvel, ha egy megfelel
jellst hasznlnak a tervezsi folyamatban. Sem a komponensek rthetsge, sem az alkalmazhatsga nem mrhet kzvetlenl. Azonban kapcsolat van e tulajdonsgok, s a komponens komplexitsa kztt. A
komplexits mrse lehetsget biztost arra, hogy egymssal sszehasonltsuk a komponensek rthetsgt s alkalmazhatsgt, nhny szabvnyt is figyelembe vve.
Constantine s Yourdon (1979) javaslatra a tervezs trstsa meghatrozhat a tervezsi komponensek fan-in, s fan-out mrsvel. A fan-in
azon komponensek szma, amelyek ezt a komponenst meghvjk, a fanout pedig azon komponensek szmt jelenti, amelyeket a komponens
meghv.
Henry s Kafura javasolta a komponens komplexitsnak meghatrozsra a kvetkez kpletet az informcis Fan-in, valamint Fan-out-okkal:
Complexity = Length (Fan-in Fan-out)2
Vissza
16
Vissza
17
ahol, a length a hosszsgnak egy mrtke, ami lehet pl. a programkd

sorainak szma is
Henry s Kafura Unix rendszer hasznlatval validltk a metrikjukat,
s azt javasoltk, hogy a potencilisan hibs komponenst is megenged
rendszer mrt komplexitst is meg kell hatrozni. A metrika magas rtket mutatott azokban a komponensekben, amelyek a rendszerproblmk
viszonylag magas szmt okoztk, s ez magas karbantartsi kltsget
eredmnyezett.
A metrika alapvet htrnya viszont az, hogy a komplexitsra nulla rtket ad, ha az eljrsnak nincsenek kls klcsnhatsai. A komponensek
a legalacsonyabb szinten nem tudnak ms komponenseket meghvni,
azonban klcsnhatsba lphetnek a hardverrel, s ezltal bonyolultt
vlnak. A Fan-in, valamint a Fan-out teljesen egyrtelm definilsa nehz.
Henry s Kafura metrikja szmos fggetlen tanulmny trgya lett a
ksbbiekben. Ezek vizsgltk, hogy vajon ez a metrika jobb-e a tbbi
egyszer metriknl, mint pl. a mret, vagy a vgsok szma, ezen kvl
meg prbltk kitallni, hogy vajon a strukturlis komplexits hasznos
prediktora-e a fejlesztsi idnek.
A Fan-in/Fan-out nem teljesen megbzhat mrtk a tervezsi minsgre, de ezen metrikk hasznosak a hibs komponensek kiemelsre a
tovbbi analzis szmra. Ha valamelyik komponensnek klnsen magas
rtke van ebben a metrikban, akkor ez azt jelenti, hogy tlsgosan bonyolult.
2.4.3. A program minsgmrtke
A programnak hibamentesnek valamint karbantarthatnak kell lennie. A

szoftver-mrsekkel foglalkoz legtbb munka termszetesen a program
analzist helyezi a kzppontba, aminek az oka, hogy a program egyrtelm nyelven van megfogalmazva, msrszt meglehetsen nyitott azokra
eszkzkre nzve, amelyekkel a programrl adatokat gyjthetnk. A
programban lv hibk megjslsra az albbi metrikk hasznlhatk:
Kdhossz (Length of code): a program mretnek mrtke. ltalban
a nagyobb mret programkd tbb hibalehetsget rejthet magba.
Ciklomatikus komplexits (Cyclomatic complexity): a programkomplexits ellenrzsnek a mrtke. (A programban lv klnbz vgrehajtsi utastssorozatok szmt jelenti.) Ez a komplexitsi mrszm kapcsoldhat a program rthetsghez is.
Vissza
17
Vissza
18
Azonostk hossza (Length of identifiers): ez a programban hasznlatos klnbz azonostk tlagos hossznak a mrtke. Minl hoszszabb az azonost, annl tbb jelentst hordoz, teht jobban rthet a
program.
Feltteles szerkezetek mlysge: a programban szerepl if-utastsok
mlysgnek, begyazottsgnak a mrtke. Minl mlyebbek az ifutastsok, annl nehezebben rthetek, teht annl nagyobb a hibaforrs.
A program mretnek mrse hasznlhat a minsgbiztostsi eljrs rszeknt. Egy szabvnyban adtak egy fels korltot a komponens mretre
vonatkozlag. Azok a komponenseket, amelyek ezt tlhaladtk, azokat jra
kell tervezni, vagy pedig jabb rszletes analzis al vonni. Azonban a mret
az egyik legegyszerbb metrika, s a legknnyebb gyjteni, Kitchenman
(1990) szerint ez legalbb olyan j indiktora a rendellenes komponenseknek, mint ms bonyolultabb metrika.
Egy eljrs ciklomatikus komplexitsa a komponensek bels komplexitsnak mrtke. E metrika alacsony rtke a program rthetsgvel fgg
ssze. A ciklomatikus komplexits, mint a teljes kr komponenskomplexits mrtke kt htrnnyal br:
A program dntsi komplexitst mri, amely feltteles utastsokkal,
valamint elfelttelekkel van meghatrozva. Ha a program adatorientlt, akkor a ciklomatikus komplexitsra alacsony rtk addik, viszont ettl mg mindig elg komplex, s nehezen rthet.
Ugyanazon sllyal szerepelnek a begyazott, s nem begyazott ciklusok. Azonban a mlyen begyazott feltteles struktrkat nehezebb
megrteni, mint a nem-begyazottat.
Oviedo (1980) kidolgozott egy program-komplexitsi mrszmot, amely
szerint a komponens komplexitsa a kvetkez formulval becslhet
meg:
C = aE + bN,
ahol a s b konstans egytthatk, s
E a vezrlsi folyamatgrf leinek szma,
N: olyan adatokra val hivatkozsok szma, amelyek nincsenek deklarlva
a komponensben.
Vissza
18
Vissza
19
J programozsi stlusban mindig jelentssel br azonostkat hasznlnak.

Ezrt a program rthetsge nvelhet hosszabb nevek alkalmazsval,
termszetesen egyb ms faktor is ltezik, ami nveli a program olvashatsgt, mint pl. a megjegyzsek rsa. Fontos lenne programozsi szabvnyban definilni az azonostk hosszt is.
2.4.4. Dokumentcis minsgmrtk
A szoftverhez kapcsold dokumentci minsge legalbb olyan fontos,

mint a szoftvernek magnak a minsge. Gunning (1962) adta ki a Fogindexet, ami az olvashatsg mrtke. A Fog-index a mondatok hosszn,
s a nehz szavak szmn alapul, ahol a sz nehzsgt a szban tallhat hangok szma adja. Ez hasznos indiktora lehet a dokumentci olvashatsgnak. Ez klnsen akkor hasznos, ha egy dokumentcinak tbb
szerzje van. A dokumentci rszei kzti stlusbeli klnbsgeket ki kell
emelni, s ki kell javtani.
2.5. Szoftver-megbzhatsg
A szoftver rendszerek legfontosabb jellemzje a megbzhatsga. Napjainkban minden rendszer esetben a minsg alapvet kvetelmny. A
rendszerhibk a szoftverfejleszts kltsgt nvelik, mivel a megbzhatatlan szoftver a vgfelhasznlnak nagy kltsgbe kerlhet.
Formlisan a megbzhatsgot egy specilis clra egy adott krnyezetben egy adott id alatti hibamentes mveletek valsznsgeknt definiljk. Pl. a replgp vezrlsi szoftvernek 99,99%-os megbzhatsgnak
kell lennie egy trs tlagos replt sorn. Azonban a megbzhatsg
formlis defincija nem mindig van sszhangban a felhasznlk szoftver
tapasztalatval. A felhasznlk nem figyelik az sszes azonos fontossg
szolgltatst, viszont a rendszert megbzhatatlannak tarthatjk, ha az nem
mkdik bizonyos kritikus krlmnyek kztt.
A szoftver-megbzhatsg fggvnye a szoftver bizonyos felhasznli
ltal tapasztalt hibk szmnak. A szoftver hiba (failure) a szoftver futsa
kzben jelentkezik. Ez az eset, amikor a szoftver nem teljesti a felhasznl ltal elvrt szolgltatst. A failure s a fault nem ugyanaz, de gyakran
felcserlve hasznljk ket.
Szoftver hiba (fault) lehet programozsi vagy tervezsi hiba, amikor is
a szoftver nem felel meg a rendszer specifikcinak. Ezek lehetnek mg
dokumentcis, vagy specifikcis hibk is. Azaz a szoftver nem gy viselkedik, ahogyan a felhasznl elvrn. A szoftver hibk statikusak. Ezek
Vissza
19
Vissza
20
a program kd tulajdonsgai, amelyek a program fellvizsglatval felfedezhetk.

A szoftver hiba (fault) okozza a szoftver rendellenessgt (failure),
amikor a hibs kd olyan bemeneti halmazzal fut, amely a szoftver hibt
eredmnyezi. A kd amgy a legtbb bemenetre helyesen fut le.
A szoftverrendszer nem ms, mint egy lekpezs, egy input halmazbl
egy output halmazba, azaz a programnak sok inputja lehet, amire a rendszer vlaszkpp adja az outputot, vagy az output-halmazt. Az input halmaz egy rszhalmaza tartalmazza azokat az inputokat, amelyek hatsra a
program rossz outputokat generl. A szoftver megbzhatsga pedig annak a valsznsghez kapcsoldik, hogy a program egy bizonyos futtatsa sorn a rendszer inputja elemei-e annak a rszhalmaznak, amelyek a
hibs outputokat okozzk
Bonyolult kapcsolat ll fenn a vizsglt rendszer megbzhatsga, s a
szoftver hibk szma kztt. Mills (1987) megmutatta, hogy a szoftver
hibk nem egyforma valsznsggel okozzk a szoftver rendellenessgt.
Rendszerint vannak olyan bemenetek, amelyeket nagyobb valsznsggel
hasznlnak, s ha ezek a bemenetek nincsenek benne abban a halmazban,
ami a szoftver hibt okozzk, akkor nem lesz rendellenessg. Teht a
program megbzhatsga leginkbb a hibs kimeneteket okoz bemen
adatok halmaztl fgg.
A megbzhatsg fgg a hasznlat kzbeni hibafellps valsznsgtl is. Ha a szoftver ritkn hasznlt rszeibl eltvoltjuk a hibkat, akkor a
megbzhatsg csak kis mrtkben nvekszik (a termkhibk 60%-nak
eltvoltsa 3%-os megbzhatsgi nvekedst eredmnyez csak).
Ezrt a program hibkat is tartalmazhat, de mgis lehetsges az, hogy a
felhasznlk szmra megbzhat, mivel nem jelentkezett rendellenessg a
programban. A tapasztalt felhasznlk gyakran dolgoznak olyan krnyezetben, ahol olyan hibk vannak, amikrl tudjk, hogy rendellenessget
okozhatnak, ezrt megprbljk elkerlni ket.
Mivel a programot a felhasznlk klnbzkppen klnbz krnyezetben hasznljk, ezrt ugyanaz a program bizonyos felhasznlk
szmra megbzhat, mg esetleg ms felhasznl szmra (aki hibt okoz bemen adatokat hasznl) megbzhatatlan.
2.5.1. Formlis mdszerek
Megbzhatbb szoftvert eredmnyez, ha formlis mdszereket hasznlunk

a szoftverfejlesztsre, mert gy knnyebben elkerlhetjk az anomlikat.
Vissza
20
Vissza
21
Azonban a formlis specifikci mg nem garantlja, hogy a gyakorlati

hasznlatban a szoftver megbzhat lesz. Az okok a kvetkezk:
A felhasznlk valdi ignyeit a specifikci nem mindig tkrzi teljesen.
A bizonyts is tartalmazhat hibt
Ha a rendszert nem gy hasznljk, ahogyan elre lthat volt, akkor a
bizonyts is hibs lehet.
A megbzhatsg nvelse rdekben tett tovbbi fejlesztsek, tervezsek
drasztikusan megnvelhetik a kltsgeket. A valsgban lehetetlen lemrni
s igazolni, hogy a rendszer 100%-osan megbzhat, azonban ha megbzhatsgi kvetelmnyeket tovbb nveljk, akkor a kltsg exponencilisan
fog nvekedni. Termszetesen a megbzhatsg nvelse gyakran a program hatkonysgnak cskkenst is okozhatja, pl. nvekszik a program a
futsi ideje, mert gyakran extra redundns kdokat is kell hasznlni a kivteles felttelek megvalstsra. Azonban gyakran a megbzhatsg elnyt
lvez a hatkonysggal szemben a kvetkez okok miatt:
A szmtgpek jelenleg olcsk s gyorsak
A felhasznl hajlamos arra, hogy eldobja a nem megbzhat szoftvereket
A rendszerhibk kltsge risi lehet
A nem-megbzhat rendszert nehz fejleszteni
A gyenge hatkonysg elre megjsolhat
A nem-megbzhat szoftverek informcivesztst okozhatnak
Vissza
21
Biztonsgkritikus rendszerek
Vissza
22
3. Biztonsgkritikus rendszerek
Ebben a fejezetben a biztonsgkritikus informatikai rendszerekkel foglakozunk. A szoftver technolgia terletn azrt van kiemelt jelentsge az
ilyen rendszereknek, mivel ezekben jelentkezik a legnagyobb mrtkben a
fejlesztsi s tesztelsi feladatok szigor elrsokhoz kttt vgrehajtsnak ignye. Az ebbe a kategriba tartoz szoftverekre rvnyes elrsok
sorbl nem mindegyik vonatkozik a ms kategrij szoftverekre, hanem
azoknak csak egy rsze. A verifikcis s validcis folyamatok a biztonsgkritikus rendszereknl hajtandk vgre a legnagyobb gonddal, hozzrtssel s rfordtssal.
3.1. Alapfogalmak
Biztonsgkritikus rendszer: Olyan informatikai rendszer, amely azzal az
elsdleges kvetelmnnyel mkdtetend, hogy ne veszlyeztesse az emberi letet, egszsget, ne okozzon gazdasgi vagy krnyezeti krokat. Tipikusan ilyenek a vasti llomsirnyt kzpontok, az atomermvek
vezrlst, rhajk, rreplk irnytst, replgpek irnytst ellt
rendszerek, valamint a krhzakban, bankokban, hadszatban (pl. cirkl
rakta) alkalmazott informatikai rendszerek.
A felsorolt pldkban jl lthat az alkalmazott rendszerek hibs mkdsbl szrmaz krok milyensge. Egy banki alkalmazs risi anyagi
krokkal jrhat, egy vegyipari folyamat krnyezetei krt okozhat, hadszati
eszkz esetben pedig a civil lakossgnak okozott vesztesg jhet szba.
A biztonsgot eredmnyez mkds mellett a msik legfontosabb tulajdonsg a megbzhatsg. Csak nagy megbzhatsg rendszerek alkalmazhatk eben a kategriban. ltalban 24 rn keresztl tart folyamatos
zemelsre van igny. A biztonsg elrshez n. hibatr rendszerek alkalmazsra van szksg.
Hibatr rendszer: Egy informatikai rendszer hibatr, ha kpes elvgezni, ill. tovbb folytatni elrt feladatnak helyes vgrehajtst hardver-meghibsodsok s szoftver-hibk jelenlte esetn. A hibatrs nem
azt jelenti, hogy a rendszer ugyanazzal a hatsfokkal, teljestmnnyel mkdik hibsan is, mint hibamentesen, hanem azt, hogy a teljestmnye lecskkenhet, esetleg nem mindegyik funkcijt ltja el maradktalanul, viszont a legfontosabb elrt feladatait mg vgre tudja hajtani.
Vissza
22
Vissza
23
A hibatr rendszerek tervezsekor bizonyos tervezsi clokat kell elrni, amelyek elre megadott kvetelmnyek teljestst szolgljk. Ezek a
kvetelmnyek klnbz matematikai, valsznsg-szmtsi mutatk
minimlis rtknek elrst rjk el. A kvetkez alpontban ezeket a
mutatkat soroljuk fel, s definiljuk.
3.2. Minsgi s megbzhatsgi kvetelmnyek
Az albbiakban felsorolt mutatk szmszer rtknek meghatrozsra
pontosan kidolgozott mrsi, vizsglati s szmtsi eljrsok lteznek,
amelyekkel ebben a knyvben nem foglalkozunk.
Megbzhatsg (Reliability): Annak feltteles valsznsge, hogy a
rendszer hibtlanul mkdik a [t0, t] idintervallumban, feltve, hogy a
t0 t idpontban hibtlanul mkdtt. A megbzhatsgot ler valsznsgi fggvny jele R(t).
A megbzhatsgi rtk teht annak a valsznsgt fejezi ki, hogy a
rendszer a [t0, t] idintervallumban vgig hibtlanul mkdik. Ez az rtk
az intervallum hossznak a nvekedsvel nyilvnvalan cskken, hiszen
az elektronikus rszegysgek az zemeltetsk, ignybe vtelk elrehaladtval egyre inkbb elhasznldnak, elregszenek. A szoftver rsz elregedsrl, megbzhatsgi rtelemben, termszetesen nem beszlhetnk.
Ezt a paramtert elssorban olyan rendszerek jellemzsre hasznljk
kiemelten, ahol egy rvid idre sincs megengedve a hibs mkds, vagy
pedig nincs md a javtsra. Az elbbi felttelre plda egy rvid replsi
idej replgp, ahol az intervallum 10 ra. Erre vonatkozan el van
rva az
R(t) 0,9999999 = 0,97 rtkszint.
Egy nem javthat rszondnl a mkdsi id 10 vet is kitehet. Ebben
az esetben a kvetelmny a 10-ves peridus vgn:
R(t) 0,95.
A megbzhatsg s a hibatrs nem ugyanazt jelenti. A hibatrs olyan
technika, amely javtja a megbzhatsgot, de ettl mg nem biztos, hogy
valban magas lesz a megbzhatsg. Ha egy rendszer ki tud vdeni hardver hibkat, de azok nagy gyakorisggal jelentkeznek, akkor az R(t) rtke
mg alacsony is lehet. Msrszrl pedig, ha egy nagy megbzhatsg
rendszerbe nincs beptve hibatrs, akkor az els hiba fellpstl kezdve
rosszul fog mkdni.
Vissza
23
Vissza
24
Rendelkezsre lls (Availability): Annak valsznsge, hogy a

rendszer helyesen mkdik a t idpontban, vagyis a t idpontban rendelkezsre ll. A rendelkezsre llst ler valsznsgi fggvny jele A(t).
Mint lthat, az R(t) s az A(t) fggvny kztt az a klnbsg, hogy
az elbbi a t idpontig tart folyamatos helyessget fejezi ki, mg az utbbi
csak azt, hogy a t idpontban legyen a mkds helyes. Ezt megelzen
lehetett hibs is.
Az A(t) mrszm rtke ott lehet fontos, ahol az informatikai rendszert nem llandan hasznljk egy feladatra, hanem gyakori megszaktsokkal. Ilyen esetekben megnvekszik a kzbens karbantarts s javts
szerepe, amely a rendelkezsre lls magas szinten tartst szolglja.
Biztonsgossg (Safety): Annak valsznsge, hogy a rendszer helyesen vagy hibsan mkdik a t idpontban, de oly mdon, hogy nem
veszlyeztet emberi letet, nem okoz anyagi vagy krnyezeti krt, s nem
befolysolja krosan ms rendszerek mkdst. Msknt fogalmazva:
Annak valsznsge, hogy a rendszer a t idpontban biztonsgosan mkdik. A biztonsgossgot ler valsznsgi fggvny jele S(t).
Ez a paramter igen szorosan sszefgg a hibatrssel. Elfordulhat
ugyanis, hogy az informatikai rendszerben komoly meghibsods lp fel,
aminek kvetkeztben mr nem lesz kpes az elrt funkciit elltni. Ebben a helyzetben a biztonsg fenntartsa gy oldand meg, hogy a rendszer olyan sorrendben hagy fel, egyms utn, a funkcik elltsval, ami a
katasztrfa elkerlst teszi lehetv. Ez a fokozatos lepls esete (angol
elnevezssel: graceful degradation). A fokozatos lepls egy rendszer azon
kpessge, hogy automatikusan tudja cskkenteni teljestkpessgt, a
hardver- s szoftver-hibk hatsnak ellenslyozsra.
A msik elterjedt vszmegolds az, hogy a rendszer, mg utols intzkedseknt mindent gy llt le, hogy a katasztrfa semmikppen ne tudjon bekvetkezni. Tipikus plda erre a vastirnyts, ahol a lellts azzal
jr, hogy a vezrls hatsra egyik vonat vagy szerelvny sem mozoghat.
Teljestkpessg (Performability): Annak valsznsge, hogy a
rendszer teljestkpessge a t idpontban elri vagy meghaladja az L szintet. A teljestkpessget ler valsznsgi fggvny jele P(L, t).
Ez a paramter azt fejezi ki, hogy a hiba esetn milyen cskkent szinten kpes mg a rendszer mkdni. Pldul: tbbprocesszoros szmtgpnl egy-egy processzor kiesse a szmtsi sebessget cskkentheti.
Ugyanilyen hatssal jr a memriaterletek kiesse is. Ilyen esetekben az L
Vissza
24
Vissza
25
rtke lehet a sebessg, a jl mkd processzorok szma, vagy a megmarad memriaterlet.

A fokozatos lepls megvalstsa nem ms, mint a teljestkpessg
elre megtervezett mdon val fokozatos cskkentse, a biztonsg fenntartsa rdekben.
Karbantarthatsg (Maintainability): Annak valsznsge, hogy a
meghibsodott rendszer jra mkdkpess tehet t idtartam alatt. Ebbe az idbe beletartozik a hiba helynek meghatrozsa, a fizikai javts
vagy csere elvgzse, valamint az jraindts. A karbantarthatsgot ler
valsznsgi fggvny jele M(t).
Az M(t) rtknek magas szinten tartsa felttlenl megkveteli a beptett ntesztelst (built-in self-testing, BIST), valamint az automatizlt diagnzis
elvgzst, amely a hiba helynek meghatrozsra irnyul. A tesztelsi s
hibalokalizcis folyamatok vgrehajtshoz kln hardver egysgek s
kln szoftver felhasznlsra van szksg, ahol mindezek a hibatr
rendszer integrns rszt kpezik.
A fentiekben felsorolt paramterek mellett igen fontos tulajdonsga
egy rendszernek a tesztelhetsg (testability) is. A tesztelhetsg azt a lehetsget jelenti, hogy vizsglatok, tesztek segtsgvel meg tudjuk hatrozni a
rendszer egyes mkdsi tulajdonsgait. Ez lehet pldul a mkdsi sebessg ellenrizhetsge, vagy pedig ami a leginkbb fontos, annak meghatrozhatsga, hogy hibs-e a mkds.
A tesztelhetsg mrtke azt fejezi ki, hogy mekkora rfordtssal, nehzsggel jr egy-egy tesztelsi folyamat elvgzse. Ehhez a fogalomhoz
igen nehz jl hasznlhat kvantitatv mrszmot rendelni, ilyen mrszm jelenleg nincs mg definilva. Nyilvnval minsgi cl a minl gyorsabb s knnyebb vgrehajthatsg. Erre vonatkozan kln mdszerek,
ajnlott vagy elrt tervezsi megoldsok llnak rendelkezsre, ill. folyamatosan kerlnek kidolgozsra. Ennek tmakre a tesztelhetsgre val tervezs
(design for testability), amivel itt nem foglalkozunk.
A hibatrsre vonatkozan ngy f alkalmazsi terletet lehet megklnbztetni. Ezek a kvetkezk:
1. Hossz lettartam alkalmazsok
Az ide sorolhat berendezsek tbb ves idtartamban mkdnek, ltalban a javtsra kevs lehetsggel. Ilyenek: Ember nlkli rrepls, mholdak, rszondk. Egy-egy rszonda akr tz ven tl is teljesti kldet-
Vissza
25
Vissza
26
st, amikor tvoli bolygk kzelbe kell jutnia. Mint mr emltettk, a

megbzhatsgi rtknek 95% felett kell lenni mg ilyenkor is.
Az rszondkon a biztonsgos mkds elrse rdekben mindegyik
egysgnek, blokknak van msodlagos tartalka. Ez nemcsak az informatikai egysgekre, hanem a klnbz navigcis, tvmr, rdis, stb. blokkokra is fennll.
2. Kritikus szmtsok
Ez a felhasznlsi md ppen az ellenkezje az elbbinek. Itt az a fontos,
hogy arra a viszonylag rvid idtartamra, amg egy kritikus mkdsi,
szmtsi szakaszban zemel a rendszer, a megbzhatsga garantltan
magas legyen. Pldk:
rkompnl a felszlls s leszlls idejre nem szabad hibnak fellpni,
mert a komp elveszhetne vgleg.
Vegyi zem szablyoz rendszere: egy technolgiai folyamat kritikus
szakaszban megnhet a robbansveszly. Erre a szakaszra a hibtlan
mkdst minl inkbb el kell rni.
Replsirnyt rendszer, amely a replgp fedlzetn helyezkedik el.
A fenti esetekre az elrs a 95 % feletti megbzhatsg.
3. Elhalasztott karbantarts
Az olyan esetekre rvnyes, amikor a karbantartsi mveleteket igen nehz,
vagy igen kltsges elvgezni. J pldk erre a tvoli helyeken zemeltetett
feldolgozllomsok, vagy az rbeli alkalmazsok. Egy-egy ilyen rendszer
karbantartsa egy ksbbi, megfelel idpontban trtnik meg. Kt karbantartsi procedra kztt kiemelten szksges a hibatr mkds.
A fldi alkalmazsra j plda az amerikai AT & T Bell szmtgpes
vezrls s feldolgozs telefonhlzata, melyben a hibatrst az zemels elvrt biztonsgossga s az risi anyagi vesztesgek elkerlse indokolja. (Itt mr 10 perc kiess is millird dollrokban mrhet krt jelent a
szolgltatnak.) A telefonhlzat kiptse megkvetelte, hogy tvoli helyeken is legyenek teleptve szmtgpes kapcsolllomsok. Ezeket a
vllalat emberei periodikusan ltogatjk vgig, s elvgzik a karbantartsi
munkkat.
4. Magas szint rendelkezsre lls
A vltakoz mrtkben ignybe vett informatikai rendszerekre vonatkozik
ez a kategria. Ilyenek az n. on-line tranzakci-feldolgozst vgz rend-
Vissza
26
Vissza
27
szerek (on-line transaction processing, OLTP), ahol a felhasznli megkeress vletlenszer mdon rkezik tbb helyrl, s ezekre azonnali feldolgozs, kiszolgls van megkvetelve. Ilyenek pldul a banki alkalmazsok.
Az OLTP-rendszerek ltalban nagykiterjeds orszgos hlzatban
zemelnek, ezen bell tbb loklis hlzattal. Az zemels legtbbszr
24-rs munkarendben trtnik, de a felhasznls jellegbl addan md
van az jszakai karbantarts idnknti elvgzsre is. Az ilyen rendszereknl nemcsak a kzponti szmtgp a hibatr, hanem a helyi hlzatok
szerver gpei is. A felhasznli terminlok ltalban szemlyi szmtgpek, amelyekre mr nincs elrva a hibatrs. Fontos azonban, hogy ezek
is nagymegbzhatsg, kivl minsg gyrtmnyok legyenek.
A bankok mellett tovbbi elterjedt OLTP-alkalmazsok a kvetkezk:
Rendrsgi gyeleti bevetsirnyt rendszer, amely a bejelentsek
feldolgozsn tl a rendri beavatkozsok nyilvntartst s szervezst is vgzi. Ugyanilyen funkcij a mentk s tzoltk bevetsirnytsa is.
Orszgos vagy nemzetkzi szlltssirnyts, amely a vasti, kamionos, vagy lgi ruszllts nyomon kvetsre, nyilvntartsra s optimlis szervezsre szolgl.
3.3. Rendszerstruktrk
A hibatrs megvalstsa mindenkppen elre betervezett redundancival kell
hogy jrjon. Ennek az a magtl rtend oka van, hogy a hibatr informatikai rendszerre a norml funkcijn kvl a sajt hibs mkds felismerse s az ilyenkor megvalstand feladatteljests is rhrul. A redundancia mind a hardverben, mind pedig a szoftverben rvnyre jut, mivel
egyedl egyik f komponens sem kpes a msik hibjt felismerni s funkcijt elltni. Termszetesen a szoftver s a hardver egymssal sszhangban zemel, amibe az is beletartozik, hogy a hibafelismersben s az ilyenkor szksges reakcikban is kiegsztik, vagy tfedik egymst. A hibatr
rendszerek felptse sok esetben olyan, hogy a hardver is hozzjrul a
szoftver-hibk felismershez, s viszont, a szoftver is rszt vehet a hardver-hibk szlelsben.
A redundancia megvalstsra ngy terlet vlt alkalmass. Ezek a
kvetkezk:
Vissza
27
Vissza
28
1. Hardver redundancia: A hibatrs elrse rdekben kiegszt

hardver elemeket alkalmaznak, klnbz funkcikkal. A funkcik
egyrszt a mkdshez kapcsold tesztelst (beptett ntesztelst),
msrszt pedig egyes elemek ismtlst (tartalkknt) jelentik ltalban.
A fejezet ksbbi rszben erre be fogunk mutatni nhny jellegzetes
megoldst.
2. Szoftver redundancia: A hibatrs elrse rdekben kiegszt
szoftverelemeket, ill. szoftverrel megvalstott mdszereket alkalmaznak. Itt is szmtsba kell vennnk a szoftvert az ntesztels megvalstsban, valamint az ismtld funkcik elltsban. Ezzel is bvebben foglalkozunk mg a fejezetben.
3. Informcis redundancia: A mkdsi biztonsg nvelse rdekben tbbletinformcit, tbbletbiteket hasznlnak fel. Ezltal a hibk
detektlsra s/vagy tolerlsra kerlhet sor. Tipikus elterjedt megolds pldul a paritsbitek, hibadetektl kdok, hibajavt kdok, ellenrz sszegek (check sum) hasznlata. A hibajavt kdok nemcsak
detektlsra, hanem tolerlsra, vagyis a hiba elfedsre, hatsnak
megszntetsre is alkalmasak. Az ilyen megoldsok az adattviteli folyamatokban, tovbb a memrikban, ill. a kzponti feldolgoz egysgekben (CPU) terjedtek el leginkbb. Megvalstsuk egyarnt trtnhet hardver s szoftver ton.
4. Id redundancia: A szksgesnl hosszabb feldolgozsi id ignybevtele. A cl itt is a hibk detektlsa s/vagy tolerlsa. A legelterjedtebb megolds a feldolgozs, a szmtsok ismtelt lefolytatsa, az
eredmnyek sszehasonltsval egybektve. Ezzel elrhet az, hogy a
hardverben fellp tmeneti hibt, amely az egyik vgrehajts alatt rvnyeslt, egy jabb vgrehajtssal ki lehessen ejteni. Az idtbblet teht gy detektlst s korriglst is lehetv tesz. A megvalsts egyarnt trtnhet hardverrel s szoftverrel is.
A gyakorlatban a fenti ngy elv kombincijt alkalmazzk. Igen sok esetben mind a ngy redundancit beptik a biztonsgkritikus rendszerekbe.
A kvetkezkben nhny fontosabb strukturlis s algoritmikus megoldst ismertetnk, amelyek a hibatrst szolgljk hardver s szoftver
tren. A hardvert itt rendszertechnikai szempontbl mutatjuk be, s csak
olyan mlysgben, amennyire ez a szoftver oldalrl fontos lehet.
Vissza
28
Vissza
29
3.4. A hardver redundancia megvalstsa

A kvetkezkben hrom jellegzetes megoldst ismertetnk a hardver redundancia megvalstsra.
3.4.1. Prhuzamos duplikls
A legrgebben alkalmazott s kzenfekv struktra ugyanazon hardver

egysgnek a megkettzse s prhuzamos mkdtetse. Ekkor mindkt
egysg ugyanazokat a bemen jeleket kapja, s helyes mkds esetn
ugyanazokat az eredmnyeket is kell produklniuk. Az eredmnyek megfigyelsrl s sszevetsrl egy kln beiktatott sszehasonlt egysg
gondoskodik. Egyezs esetn az egyik egysg jelei jutnak tovbb a feldolgozsi folyamatban. Az egymstl eltr eredmny az egyik egysg hibs
mkdst jelenti. Itt a hibt csak detektlni lehet, de elfedsre, tolerlsra mr nincs md. Clszer intzkeds lehet ilyenkor a tovbbi mkds
biztonsgot nem srt lelltsa.
A lert prhuzamos struktrt a 3.1. brn mutatjuk be. A dupliklt
egysgek brmilyen bonyolultsg modulok lehetnek, ugyanakkor tetszleges szm egysgprost lehet egy rendszeren bell kialaktani. Pldul
aritmetikai logikai egysget (ALU-t), vagy httrtrolkat, diszkegysget. A
legmagasabb szint megolds az, amikor egy teljes szmtgp megkettzse valsul meg.
1. modul
Bemenet
sszehasonlt
egysg
Kimenet
2. modul
3.1. bra. Prhuzamos duplikls

3.4.2. Tartalkelemes zemeltets
Ebben a struktrban is kt azonos egysg vesz rszt, de csak az egyik, a

norml egysg fejt ki zemszer mkdst, a msik tartalkknt szerepel
(3.2. bra). Azt, hogy melyik egysg jelei jutnak a kimenetre, az tkapcsol
modul intzi el, a hibadetektor modul parancsa alapjn. A hibadetektor
rendelkezik azzal a kpessggel, hogy meg tudja llaptani a helyes-hibs
mkdst az ltala ellenrztt modulrl. Ha a norml modul hibsnak
Vissza
29
Vissza
30
mutatkozik, akkor a tartalkmodul zemeltetsre kerl sor. Ha az is meghibsodna, a mkds felfggesztdik.

A tartalkmodult ktfle llapotban szoks hasznlni a norml zemels folyamn. Az egyikben nincs bekapcsolva, vagyis nincs tpfeszltsg
al helyezve (hideg tartalk), a msikban llandan be van kapcsolva, s
mkdst fejt ki (meleg tartalk). A hideg tartalk alkalmazsra egyrszt
energia-takarkossgbl, msrszt pedig az lettartam meghosszabbtsa
rdekben kertenek sort.
Hibadetektl
egysg
Norml modul
Bemenet
tkapcsol
egysg
Kimenet
Tartalk modul
3.2. bra. Tartalkelemes zemeltets

3.4.3. Hrommodulos redundancia (TMR)
Mint lthat volt, a hibatrs megvalstsra nem elegend kt egysg. A

cl elrse legalbb hrom egysg beiktatst kvnja meg. Egy ilyen struktrt tntet fel a 3.3. bra, az n. hrommodulos redundancit. (Angolul: Triple
Modular Redundancy, TMR.) A TMR-struktrban a hrom megismtelt
modul jelei egy n. szavazegysgre (voting unit, voter) jutnak, amely a tbbsgi
szavazs elvn mkdik. Ez azt jelenti, hogy a kimenetre az a jel megy
tovbb, amely legalbb kt modulnl azonos. Ha teht egy modul meghibsodik, akkor a msik kett azonosan helyes mkdse rvnyesl. A
hibs modul hibja egyrszt detektldik, mivel az megllapthat, hogy
melyik trt el a msik ketttl, msrszt pedig tolerldik is, mivel a hatsa
nem jut rvnyre a teljes mkdsben.
Ha kt vagy hrom modul hibsodna meg, akkor vrhatlag hrom
klnbz jel jutna a szavazra, amely ilyenkor deklarln a teljesen tves
mkdst, aminek alapjn egy biztonsgra trekv lellts, vagy tartalkegysg belptetse kvetkezhet.
Vissza
30
Vissza
31
1. modul
Bemenet
Szavaz
egysg
2. modul
3. modul
Kimenet
(Tbbsgi szavazs)
3.3. bra. A TMR-rendszer felptse

Mindehhez mg az a felttelezs is jrul, hogy annak a valsznsge, hogy
kt modul teljesen azonos mdon hibsodik meg egyidejleg, elhanyagolhatan kicsi.
A vzolt szisztma egyetlen hibs modul tolerlsra alkalmas. Az eltrt hibs modulok szma gy nvelhet, hogy nveljk a prhuzamosan
dolgoz modulok szmt, de mindig gy, hogy ez a szm pratlan legyen a
tbbsgi szavazssal sszhangban. Knnyen belthat, hogy az eltrt hibs modulok szma N 3 esetn az
(N 1) / 2
kplettel hatrozhat meg. Ez a szm t modulnl kett, ht modulnl
hrom. A modulok szmnak nvelse termszetesen nem jr arnyosan
egyrtelm javulssal, mivel a meghibsodsok valsznsge is nvekszik,
msrszt pedig gazdasgossgi korltok is jelentkeznek. A gyakorlatban
alkalmazott informatikai rendszerek ismeretben megllapthatjuk, hogy a
vilgon a TMR-konstrukci terjedt el s vlt be leginkbb.
rdekessgknt mg megemltend, hogy a tbbsgi szavazsos rendszerek megbzhatsgi elmletvel elszr Neumann Jnos foglakozott
behatbban, az Egyeslt llamokban, az 1950-es vekben. Akkoriban
mg az volt a f gond, hogy kisebb megbzhatsg alkatrszekbl (relk,
elektroncsvek) hogyan lehet olyan szmtgpet pteni, ami nagy megbzhatsggal ltja el a szmtsi feladatait.
3.5. A szoftver redundancia megvalstsa
A hibatrs magas fokon val elrse megkveteli a szoftver-hibk elfedst, ami plusz szoftvert ignyel, msrszt pedig, mint tudjuk, a hardverhibkhoz is szksg van a tbblet-szoftver alkalmazsra.
Vissza
31
Vissza
32
A szoftver hibatrs kt cllal valsthat meg:

A szoftver sajt hibjnak elfedsre.
A szoftver sajt s a hardver hibinak egyttes elfedsre.
A msodik felttel magban foglalja az elst is, ezrt a kvetend megoldsknt ezt rdemes vlasztani. A tovbbiakban csak ilyen megoldsokkal
foglalkozunk.
Elszr vizsgljuk meg azt a struktrt, amelyben a hardver megkettzse szerepel (3.4. bra). Tegyk fel, hogy mindkt csatornban ugyanaz a
szoftver van teleptve, s a csatornk CPU-ja is megegyezik, vagyis
SW1 SW2, valamint CPU1 CPU2.
SW1
SW2
CPU1
CPU2
sszehasonlt
3.4. bra. Ktcsatorns szoftvermkds
Vissza
32
Vissza
33
Ebben a struktrban a szoftverben elfordul hibk detektlsra semmilyen lehetsg nincsen, mivel mindkt csatorna hibsan is azonosan
mkdik, s gy az sszehasonlt ezt helyes mkdsnek rzkeli. Hardverhiba esetn a csatornk kztt eltrs fog mutatkozni, ami hibadetektlsra vezet.
Ha egy TMR-rendszerben alkalmazzuk ugyanezt az elrendezst, akkor
sem vltozik a helyzet, az ismtld szoftver hibjt ilyenkor sem lehet
szlelni. A megolds kulcsa abban ll, hogy elkerlend a teljesen azonos
szoftverek alkalmazsa. Ezt gy valsthatjuk meg, hogy a klnbz csatornk szoftverje nem lesz azonos, viszont ugyanazt a mkdst vrjuk el
az egyes vltozatoktl. Ezt az elvet szoftver diverzitsnak nevezzk.
A kvetkezkben kt olyan megoldst mutatunk be, amely a szoftver
hibatrst szolglja a diverzitsi elv rvnyestsvel.
3.5.1. N-verzis programozs
Az N-verzis programozsban a teljes szoftvert N db. pldnyban valstjk meg, kt lehetsges megkzeltsben:
Ugyanazt a programozsi nyelvet alkalmazva, egymstl fggetlen,
klnbz fejleszt csoportok, teamek.
Eltr programozsi nyelveket alkalmazva, egymstl fggetlen, klnbz fejleszt csoportok, teamek.
A fejleszt csoportok ugyanazt a specifikcit realizljk. Eltr nyelvek
esetn az egymstl val fggetlensgk azt a clt szolglja, hogy nehogy
ugyanazokat a hibkat kvessk el s vigyk bele a szoftverbe.
Az N-verzis rendszer mkdse a kvetkez: Az N program a szmtgpes szervezstl fggen lefut, akr prhuzamosan, akr sorosan.
Elbbi esetben N db. CPU vesz rszt a feldolgozsban, utbbi esetben
csak egyetlen CPU. Az egyes programverzik ugyanazokat a bemen adatokat hasznljk, s a kimen adatok sszehasonltdnak. Az sszehasonltst egy erre a clra elksztett program vgzi.
N = 2 esetn, ha prhuzamos feldolgozs trtnik, csak a hibadetektls tnye derl ki. A hibs szoftver-komponensre, vagy a hibs hardverre
nem kapunk informcit. Egymst kvet feldolgozsok esetn ugyanez a
helyzet, azzal a klnbsggel, hogy a hardverben fellp esetleges tmeneti
hiba detektlsra is sor kerlhet.
Vissza
33
Vissza
34
Ennl hatkonyabb megolds az N = 3, ahol md nylik a TMR-szisztma alkalmazsra, egy a szavazst megvalst programkomponens bevonsval. Ez a szervezs lehetv teszi a hibs szoftver meghatrozst,
s hibjnak eltrst is.
A szmtgpes implementci meglehetsen kltsges, hiszen ugyanazt a szoftvert tbbszrsen kell kifejleszteni. A futtats szervezse is
plusz fejlesztst kvn. Akr prhuzamos a feldolgozs, akr soros, a futsi
eredmnyek eltrolsrl s sszehasonltsrl kln kell gondoskodni.
Esetenknt ez igen komoly adatmennyisg kezelst teheti szksgess.
A magas ltrehozsi kltsgek korltoztk a mdszer elterjedst. Az
egyik jellegzetes megvalsts az Egyeslt llomokban trtnt, ahol az
AIRBUS A330/340 nagyteljestmny replgp fedlzeti irnyt szmtgpn hoztak ltre TMR-rendszer szoftvert.
3.5.2. A javt blokkok mdszere
A szoftverhibk elfedsnek egy msik mdszere az n. javt blokkok

(recovery blocks) alkalmazsa. Ebben a teljes szoftvert tbb modulra bontjk,
s az egyes modulok tbbverzis megvalstsval, valamint a modulok
ntesztelssel egybekttt jrafuttatsval rhetjk el a hibatrst. A vgrehajts elve a kvetkez:
Egy-egy modul azonos funkcij verzii alkotnak egy blokkot. Mindegyik blokkhoz tartozik egy n. elfogadsi teszt (acceptance test), ami egy kln
program az esetleges hibs mkds detektlsra. A feldolgozsban a modulok egyms utni futtatsra kerl sor, ahol minden futst az elfogadsi
teszt vgrehajtsa kvet. Ha egy modulverzit elfogad a teszt, jabb verzira nem kerl sor, a kvetkez blokk els verzijn lesz a sor. Ha egy modulverzi hibsnak bizonyul a teszt alapjn, akkor a soron kvetkez tartalkmodul futtatsra kerl sor, a blokkon bell. Ha ez is hibs a teszt szerint, jabb modulra kerl sor stb., mindaddig, amg csak van futtathat
modulverzi. A javts (felpls, recovery) elve akkor rvnyesl egy
blokkban, ha egy hibs modult egy j modul futsa kvet. Ha egy blokkban
mindegyik modulverzi hibsnak bizonyul, akkor a teljes futs vget r.
Egy j blokk futtatsa eltt mindig el kell menteni az addig elllt szszes adatot egy fggetlen trba. Ha hibt tall az ellenrzs, az j modul
futtatsa ebbl az elmentett llapotbl kell hogy trtnjk.
Az elfogadsi tesztek megrsa igen komoly szellemi rfordtst ignyel. A programmodul s a mkdsi krnyezet alapos ismerete s tanul-
Vissza
34
Vissza
35
mnyozsa szksges hozz. Egzakt mdszerek nem llnak rendelkezsre.

Nhny kvetend irnyelv lehet a kvetkez:
Annak ellenrzse, hogy egy kiszmtott rtk az elfogadhat normlis
fizikai tartomnyba esik-e (pldul, hmrsklet vagy nyoms).
Nem trtnt 0-val val oszts.
Nem trtnt cmtartomnyon kvli cmzs, a tmbdeklarcik figyelembevtelvel.
Egy-egy fontos szmrtk meghatrozsa alternatv algoritmussal is
megtrtnik.
Vgezetl megemltjk mg, hogy a javt blokkok elve az elosztott szmtgpes rendszerekben is alkalmazst nyert. Az ilyen rendszerekben tbb
klnbz szmtgp (csompont) vesz rszt egy-egy feladat megoldsban, az erforrsok sszehangolt, automatizlt elosztsval. Ilyen szervezsben elfordulhat az is, hogy egy modul ismtelt vgrehajtsra egy msik csomponton kerl sor, ha az elz csompont hibsnak bizonyult.
3.6. Az ELEKTRA tpus vezrlrendszer
felptse s mkdse
A szoftver diverzitson alapul hibatrs egyik rdekes gyakorlati pldjt
adja az ALCATEL-AUSTRIA AG. cg ltal tervezett s gyrtott szmtgpes vastirnyt rendszer, melynek tpusneve ELEKTRA. Az ELEKTRA egy n. biztostberendezs, amely vasti plyaudvarok forgalmnak irnytsra szolgl. A felhasznlsbl addan ez is biztonsgkritikus rendszer,
ktelezen elrt hibatrssel. A szmtgpes vezrlrendszer ktoldal
informcis kapcsolatban ll az ltala felgyelt plyaudvarral, ahol az n.
klstri berendezsek, a jelzlmpk, sorompk, vgnyvltk helyezkednek
el. A bejv informci a vonatok, szerelvnyek mozgsra, helyzetre
utal. A kimen informci a klstri berendezsek automatizlt vezrlsre szolgl. Mindezt a 3.5. bra szerinti felptsben is szemlltetjk.
Az ALCATEL-ELEKTRA megkettztt prhuzamos felpts rendszer, amelyben a kt prhuzamos csatornhoz (A s B csatorna) egymstl
eltr fejleszts szoftverek tartoznak. Az ELEKTRA felptst a 3.6.
bra mutatja be.
Vissza
35
Vissza
36
Szmtgpes
irnytrendszer
Vasti plyaudvar
irnyt kzpontja
Hardver
interfsz
Klstri berendezs:
jelzlmpk, vltk
Plyaudvar
3.5. bra. Vasti irnytrendszer vzlata

2.
Szmtgprendszer
1.
Szmtgprendszer
A
Csatorna
B
sszehasonlt
Csatorna
Logikai
csatorna
Biztonsgi
csatorna
Hardver interfsz
Irnytott folyamat
3.6. bra. Az ALCATEL-ELEKTRA rendszer felptse
Vissza
36
Vissza
37
Az A csatorna elnevezse: logikai csatorna. A B elnevezse: biztonsgi csatorna. Norml, hibamentes zemben a plyaudvar irnytst az A csatorna
intzi. A kt csatorna szoftverei kztt lnyeges mkdsbeli klnbsg
van, a kvetkezk szerint:
1. Az A csatorna szoftvere egy CHILL programozsi nyelven elksztett
procedurlis vgrehajts program. (A CHILL magas szint programnyelv, a telekommunikci terletn fejlesztett vals idej (real-time)
rendszereknl terjedt el a felhasznlsa.) A bemen adatok a kls plyaudvari esemnyek, helyzetek, amiknek alapjn a program lefut, s ennek eredmnyeknt kiadja a szksges vezrl jeleket a plyaudvar fel.
2. A B csatorna szoftvere nem procedurlis program, hanem egy nll
szakrti rendszer. Elnevezse: SAFETY BAG (biztonsgi csomag). Ltrehozsa a PAMELA nev fejleszti krnyezetben ment vgbe. A
rendszer tudsbzisa szablyalap: tbb mint 800 szablyt tartalmaz. A
szablyok PAMELA nyelven rdtak. (PAMELA: PAttern Matching
Expert System LAnguage.) A SAFETY BAG egy-egy szablynak
struktrja: Ha egy adott esemny vagy esemnylnc kvetkezett be,
akkor egy elre definilt intzkedsre van szksg. Pldul:
IF track 27 is occupied AND signal 33 is free THEN set signal 33 to stop
Ennek rtelmezse: HA a 27-es vgny foglalt S a 33-as jelz szabad,
AKKOR lltsd a 33-as jelzt llj-ra.
Amikor egy helyzetet elemez a szakrti rendszer, akkor azt vizsglja
vgig, hogy az sszes szably kzl melyek azok, amelyeket figyelembe
kell venni az adott helyzetben, ill. melyeket nem, s a szerint kell dntst
hozni a plyaudvari teendket illeten.
A mkdsi folyamat a kvetkez:
Az A jel csatorna a forgalomirnyts bejv jeleit dolgozza fel logikailag, az adott helyzetet elemzi, kirtkeli, s a szksges vezrl jeleket kldi ki.
A B csatorna a biztonsgi mkdst szolglja. A bejv jeleket elemzi,
dntst hoz, majd megvizsglja az A csatorna dntst. Ha azt elfogadja, az A intzkedse kimegy. Ha nem fogadja el, akkor a kvetkez
esetek lehetsgesek:
1. B veszi t az intzkedst.
2. B tilt jelet ad ki a forgalom korltozsra.
3. B lelltja a forgalmat.
Vissza
37
Vissza
38
A dntshozatalhoz mindkt csatorna a TMR-struktrt alkalmazza sajt

magn bell, a biztonsg nvelse rdekben. Ez azt jelenti, hogy a szoftver is hromszorozva van a kt g CPU-ival egytt, mind az A-ban, mind
a B-ben kln-kln. A csatornk kevsb kritikus helyein (a monitorok
vezrlse, ill. a hardver interfsz vezrlse) mr csak megkettztt prhuzamostst terveztek be.
A csatornk tbb ponton el vannak ltva ntesztel egysgekkel is. Az
ezekhez elksztett tesztprogramok szintn a szoftver rszt kpezik. Az
ntesztels a hardver hibk felfedsre irnyul. Hibadetektls esetn a
hiba helye az ramkri krtya szintjig automatizltan behatroldik, s
kijelzsre kerl. A mkdsi helyzettl fggen egyes krtyk zem kzben is kicserlhetk, msok cserje eltt a rendszert le kell lltani. Ekkor a
krtyacsert kveten jraindtsra kerl sor.
Az A meghibsodsa esetn B intzkedik a forgalomirnytsrl, s viszont: ha B-ben lp fel hardver-hiba, akkor az A egyedl vgzi az irnytst. Ez az ideiglenes llapot a krtyacsere vgrehajtsig ll fenn.
Az ELEKTRA szisztma hibalefedsi kpessgeit tekintve az albbi
megllaptsokat tehetjk:
1. A prhuzamosan, valamint a TMR-ben szervezett mkdtets nemcsak az llandsult, hanem az tmeneti hardver-hibk felfedsre is alkalmas. Ezeknek a hibknak a felfedshez mindkt csatorna szoftvere
is hozzjrul.
2. A kt csatorna egymstl gykeresen eltr szoftvermegoldsa lnyegesen nveli a biztonsgot, ahol a kt szoftvernek ugyanazt a feladatot
kell elltnia, s az eredmnyeik mindig szembestve vannak egymssal.
Ez a konstrukci egyrszt lehetv teszi a meglev szoftver-hibk detektlst, msrszt pedig azoknak a hibknak a detektlst is, amelyeket mg a tervezs sorn sem tudtak elre szmtsba venni. Ezen
tlmenen, a diverzits megvalstsi mdjbl mg egy nagyon fontos kvetkezmny is szrmazik: Nevezetesen az, hogy ezltal olyan
zemelsi veszlyek elkerlse is lehetv vlik, amelyekkel a tervezsi
folyamatban nem kalkulltak.
A teljes hardver-szoftver komplexum hibadetektlsa s hibatrse a kvetkez mdon elemezhet:
Jelljk az sszes, elvileg lehetsges, tervezsi s mkdsi hiba halmazt H-val. A H halmazt az albbi rszhalmazokra tudjuk felosztani (3.7.
bra):
Vissza
38
Vissza
39
HE: Az elre felttelezett s detektlhat hardver-hibk halmaza, amelyek felfedsrl a tervezs sorn gondoskods trtnt (vagyis az
ELEKTRA bizonythatan felfedi ezeket a hibkat).
HN: Olyan hibk, amelyek bekvetkezsvel nem kell szmolni, mert
felismerskrl s elkerlskrl az ELEKTR-n kvl kln trtnt
gondoskods. (Pldul: kbelezsi hibk.)
HI: A biztonsgra nem hat, irrelevns hibk kre.
HU: Azon hibk kre, amelyekrl nincs semmilyen elzetes tudomsunk. Ide tartoznak azok a veszlyes forgalmi helyzetek is, amelyek kezelse a tervezs sorn nem volt kalkullva s megoldva.
HE
HN
H:
HU
HI
3.7. bra. A lehetsges hibk felosztsa

Mindezek utn rhat, hogy
H = HE HN HI HU.
A teljes halmazban nem jelent gondot a bizonytottan lefedett, valamint a
veszlyt nem okoz hibk kre. Biztonsgi okokbl egyedl a HU halmaz
hibinak egy rsze a kritikus, ezek idzhetnek el balesetet. Vizsgljuk meg
ezt a halmazt kzelebbrl.
Legyen azoknak a hibknak a halmaza HA, amelyeket nem ismernk,
s amelyek megnyilvnulsa, jelentkezse az A csatorna mkdsnek a
kvetkezmnye. Ugyangy, legyen azoknak a hibknak a halmaza HB, ame-
Vissza
39
Vissza
40
lyeket nem ismernk, s amelyek megnyilvnulsa, jelentkezse a B csatorna mkdsnek a kvetkezmnye. A kt halmazt a 3.8. brn tntettk fel.
HB
HA
3.8. bra. A szoftverdiverzits eredmnye

Legyen tovbb azoknak a hibknak a halmaza HX, amelyeket nem ismernk, s hatsuk teljesen kvl esik az ELEKTRA mkdsi krn. Ezek
utn felrhat a kvetkez sszefggs:
HU = HA HB HX.
Az sszefggst a 3.9. bra illusztrlja.
HA
HB
HX
3.9. bra. Az ismeretlen hibkat kpvisel halmazok

A HA s HB halmazok egymssal diszjunkt rszei olyan hibkat foglalnak
magukban, amelyekre a kt csatorna eltren reagl, gy azok a hibk a
csatornk kztti mkdsi sszehasonltsban detektldnak. Ezzel
szemben nem ll fenn ugyanez a kt halmaz kzs rszre: Az ide tartoz
Vissza
40
Vissza
41
hibkra vagy egyformn reagl a kt csatorna, vagy pedig a B nem veszi

szre, hogy az A helytelenl reaglt. Vgeredmnyben teht kimondhat,
hogy azoknak az ismeretlen hibknak a HV halmaza, amelyek potencilis
katasztrfaveszlyt jelentenek, a kvetkez sszefggssel rhat le:
HV = HA HB HX.
A HV halmaz teht a biztonsgot veszlyeztet hibkat hordozza magban. Annak az idelis tervezsi clnak az elrse, hogy ez a halmaz abszolt res legyen, lehetetlen. Mindazonltal arra kell trekedni, hogy HV minl kisebb mrtk legyen. Ennek elrshez a tervezsi s fejlesztsi folyamat szigor szablyainak betartsra, msrszt pedig az elkszlt rendszer kln biztonsgi vizsglatra van szksg. Ezekkel a tmakrkkel az
5. fejezetben fogunk rszletesebben foglalkozni.
Vissza
41
Szoftver-tesztelsi mdszerek
Vissza
42
4. Szoftver-tesztelsi mdszerek
4.1. Tesztelsi alapfogalmak
A kvetkezkben a szoftverek tesztelshez kapcsold legfontosabb
fogalmakat s defincikat soroljuk fel.
Defincik
Bemeneti adat: Olyan szmtgpes adat, amely egy tetszleges szoftver
mkdtetst vonja maga utn, felhasznli szinten.
Kimeneti adat: Olyan szmtgpes adat, amely egy tetszleges szoftver
mkdtetse sorn jelenik meg, a mkdtets eredmnyeknt, felhasznli
szinten.
Hibamodell: Azon szoftverhibk halmaza, amelyeknek a felfedsre irnyul a teszttervezs.
Tesztels: A szoftver bemeneti adatokkal val sorozatos elltsa s a
kimeneti vlaszadatok megfigyelse.
Egy hiba tesztje: Bemeneti adatok olyan rendezett sorozata, melynek
hatsra az adott hibt tartalmaz szoftver a legutols adatkombincira a
helyestl eltr (hibs) kimeneti adatkombincival vlaszol. Ebben az
esetben azt mondjuk, hogy a teszt kimutatja, felfedi vagy detektlja a hibt. Itt
hasznlatban van mg az a kifejezs is, hogy a teszt lefedi az adott hibt.
Detektlhat hiba: Egy hibrl akkor mondjuk, hogy detektlhat, ha
legalbb egy tesztje ltezik. (Tervezsi redundancia folytn ltezhetnek olyan
hibk, amelyek semmilyen krlmnyek kztt nem reztetik hatsukat a
szoftver egsznek mkdsben. Az ilyen hibk nem detektlhatk a
teszt defincija rtelmben.)
Tesztkszlet: Tbb hiba tesztjeinek egyttese, halmaza.
Tesztkszlet hibalefedse (fault coverage): Azon hibk szzalkos arnya az sszes felttelezett hibhoz kpest, amelyeket a tesztkszlet detektlni tud. Msknt megfogalmazva: Azon hibk szzalkos arnya az sszes
felttelezett hibhoz kpest, amelyeknek van tesztjk a tesztkszletben. Az
elrend cl a 100%-os lefedst produkl tesztkszlet ltrehozsa.
Teljes tesztkszlet/teszthalmaz: Teszteknek olyan sszessge, amely a
szoftver mindegyik elre felttelezett s detektlhat hibjnak tesztjt
Vissza
42
Vissza
43
magban foglalja. Az ilyen teszthalmazrl azt mondjuk, hogy teljes hibalefedst eredmnyez. A teljes teszthalmaz 100%-os hibalefeds.
Teszttervezs: Az a tervezsi folyamat, amelyben egyms utn meghatrozzuk az egyes elre felttelezett szoftverhibk tesztjt. Ennek sorn
megtrtnik a bemeneti tesztek s az ezekre elvrt vlaszadatok meghatrozsa az elre felttelezett hibahalmazra nzve. A szmtsok mindenkori
clja egy olyan tesztsorozat ellltsa, amely kpes az sszes elre definilt hiba felfedsre, amikor az adott ltez szoftveren vgrehajtjuk a teszteljrst.
Megjegyzs: A mai informci-technolgia mr olyan bonyolult szoftver-rendszerek ellltst teszi lehetv (millis szmban tudnak utastsokat tartalmazni), hogy a teljes hibalefeds elrse gyakorlatilag nem valsthat meg. ltalban a 90%-on felli minl jobb lefeds a relis s elfogadhat cl.
Tesztszmts vagy determinisztikus tesztgenerls: Egy adott hiba
tesztjnek szisztematikus szmtsokkal trtn meghatrozsa.
Vletlenszer/random tesztgenerls: Bemen adatok sorozatnak
vletlenszer kpzse a hibk tesztjeknt trtn felhasznlsra. (Angolban: random test generation.) Ilyenkor a bemeneti tesztadatokat egy adott
tartomnyban hasznlt vletlenszm-genertorral lltjuk el.
4.2. Hibamodellek s rvnyessgi krk
Hibamodellnek nevezzk azoknak az elre felttelezett hibknak a konkrt
halmazt, amelyekre vonatkozan a teszttervezst vgre kvnjuk hajtani.
Tbb fajta hibamodell ltezik a gyakorlatban. Egy hibamodell meghatrozsakor a kvetkez fbb szempontokat rdemes tekintetbe kell venni:
A teszttervezs kivitelezhetsgi lehetsgei s a rfordtand kltsgek.
Az adott fejlesztsi technolgihoz kapcsold hibajelensgek elzetes
ismerete.
A tesztels vgrehajtshoz szksges hardver s szoftver eszkzk
ltal nyjtott szolgltatsok kre.
Vissza
43
Vissza
44
Megjegyzs: A publiklt gyakorlati tapasztalatok alapjn ltalban megllapthat, hogy a szoftver rendszerek fejlesztsi s ellltsi kltsgben a
tesztelsi folyamatok megtervezsre s vgrehajtsra fordtand kltsg
tbb mint 50%-ot tesz ki. A technolgik fejldsvel folyamatosan nvekszik a rendszerek bonyolultsga s mrete, ami vgs soron a tesztkltsgek arnynak nvekedst vonja maga utn. Mindebbl az kvetkezik,
hogy folyamatosan szksg van jabb s hatkonyabb mdszerek, eszkzk kidolgozsra mind a teszttervezs, mind pedig a tesztvgrehajts
terletn.
A kvetkezkben a hasznlatban lev fontosabb hibamodelleket tekintjk
t. Fontos megjegyezni, hogy a szoftver-hibk mindig jelen vannak a mkds sorn, a krds csak az, hogy milyen mdon nyilvnulnak meg.
Szoftver hibk
a) Szoftver specifikcis hibk
A fejleszts kezdetekor megjelen hibk, amelyek a szoftver elre megadott, specifiklt mkdsi funkciiban nyilvnulnak meg, mgpedig oly
mdon, hogy a szoftver valamilyen vonatkozsban nem teljesti a felhasznli kvetelmnyeket. A specifikcis hiba addhat: tves specifikcibl, ellentmondsos specifikcibl, valamint hinyos specifikcibl.
b) Programozi hibk
A szoftver tervezse s kdolsa sorn a programoz ltal elkvetett hibk
krt foglalja magban. A lehetsges hibk az albbiak:
Hibs funkciteljests.
Hinyz funkcik.
Adatkezelsi hibk az adatbzisban.
Indtsi (inicializlsi) s lelltsi hibk.
Felhasznli interfsz hibi
Hatrrtkek tllpse
Kdolsi hiba
Algoritmikus hiba
Kalkulcis hibk
Inicializlsi hiba
Vezrlsi folyamat hibja
Vissza
44
Vissza
45
Adattovbbtsi hiba
Versenyhelyzet programblokkok kztt
Terhelsi hiba
A kvetkez alpontokban a teszttervezs legfontosabb megkzeltsi
mdjaival foglalkozunk. Ezekhez kapcsoldan olyan determinisztikus
mdszereket mutatunk be, amelyek felhasznlsval a klnbz hibk
tesztjeit tudjuk megkeresni.
4.3. A tesztek megtervezse
Annak rdekben, hogy betekintst kapjunk a szmtgpes programok
tesztelsi feladatnak sszetettsgbe, vegynk egy egyszer pldt. Tegyk fel, hogy a kvetkez funkcit teljest programot kell ellenriznnk:
A program beolvas hrom egszszmot, amelyek egy hromszg oldalainak hosszt kpviselik. A feladata annak meghatrozsa, hogy az gy
elll hromszg szablytalan, egyenl szr, vagy pedig egyenl oldal.
Ha tesztelni akarjuk az elkszlt programot, akkor a kvetkez vizsglatokat, teszteket vgezhetjk el rajta:
1. Hrom olyan szmot adunk meg, amelyek egy rvnyes hromszget
tesznek ki.
2. Hrom olyan szmot adunk meg, amelyek egyenlk, vagyis egyenl
oldal hromszget alkotnak.
3. Kt egyenl s egy ettl klnbz szmot adunk meg, melyek gy
egyenl szr hromszget adnak.
4. Olyan szmokat adunk meg, amelyek kzl kettnek az sszege kisebb, mint a harmadik szm.
5. Olyan szmokat adunk meg, amelyek kzl kettnek az sszege egyenl a harmadikkal.
6. Hrom 0-t adunk meg.
7. Olyan szmokat adunk meg, melyek kztt nem egsz szm is van.
8. A hrom szm kztt negatvat is magadunk.
Az rvnytelen bemeneti adatokra azrt volt szksg, hogy ellenrizzk,
hogyan reagl rjuk a program. Ha elfogadn valamelyiket, akkor az programhiba lenne.
A fenti vizsglati esetek mg egyltaln nem elegendek arra, hogy
mindegyik elvileg lehetsges hibt fel tudjk derteni. Ebbl is lthat,
hogy egy ilyen egyszer program tesztelse sem knny feladat. Mindez
Vissza
45
Vissza
46
teht azt jelenti, hogy pldul egy tbbszzezer utastsbl ll szoftver

megbzhat leellenrzse belthatatlan bonyolultsg feladat tud lenni.
Ami a tesztek megtervezsnek krdst illeti, erre vonatkozan kt
alapvet megkzelts ltezik: a funkcionlis, valamint a strukturlis. Ezeknek
a lnyegt a kvetkez kt alpontban rjuk le.
4.3.1. A funkcionlis tesztels alapelve
Funkcionlis tesztelsrl beszlnk akkor, amikor a programot egyedl csak a

kls viselkedsben, az elrt funkciinak teljestsben vizsgljuk azltal,
hogy a bementi adatokra kapott kimeneti vlaszadatokat figyeljk meg, a
futtathat trgykd felhasznlsval. Ebben a megkzeltsben egyltaln
nem vesszk figyelembe a forrskdot, mg a program megrsi nyelvt
sem, vagyis a programot olyan egysgnek tekintjk, amibe nem ltunk
bele. Emiatt szoks mg ezt a megoldst fekete doboz vagy vasdoboz tesztelsnek is nevezni (angolban black-box testing, iron-box testing).
A funkcionlis tesztelsben a szoftver minden egyes specifiklt funkcijnak a sorra vtele s leellenrzse a cl, ezen kvl pedig mg az is,
hogy nincs-e valamilyen tves, nem betervezett tevkenysge a programnak.
4.3.2. A strukturlis tesztels alapelve
Strukturlis tesztelsrl beszlnk akkor, amikor a szoftver forrskdjnak

felhasznlsval a bels struktra, a bels mkds vgigkvetsre irnyul az ellenrzs. Ebben a megkzeltsben a tesztelsi adatok megtervezse sorn az a cl, hogy a forrskd utastsainak s elgazsainak minl
alaposabb vgigjrst tudjuk elrni. Itt a programot teht olyan egysgnek
tekintjk, amibe beleltunk. Emiatt szoks mg a fehr doboz vagy vegdoboz tesztels elnevezsek hasznlata is. (Angolul: white-box testing, glass-box
testing.)
A strukturlis tesztelssel a program minden egyes utastsnak a vgrehajtst, a dntsi elgazsok lehetsges vgrehajtsait, valamint a ciklusok vgrehajtst kell ellenrizni.
A kdbejrs trgyalst megknnyti az n. vezrlsi folyamatgrf (VFG)
(angolul: control-flow graph, CFG) fogalmnak a bevezetse s felhasznlsa.
A vezrlsi folyamatgrf egy olyan irnytott grf, melyben minden egyes
csompont megfelel egy programutastsnak. Az egymst soron kvet A
s B utasts csompontjait gy kti ssze az irnytott l, hogy az A pontjbl a B-jbe mutat. Egy dntsi utasts (pldul IF THEN ELSE, vagy
CASE) csompontjbl annyi irnytott l indul ki, ahny fel trtnhet a
Vissza
46
Vissza
47
dntshozatal feltteles elgazsa. A felttel nlkli elgazst (GO TO) reprezentl pontbl kivezet irnytott l az elgazst kvet utasts pontjhoz vezet. A ciklusutastsokat (pldul FOR DO, REPEAT WHILE) egy
visszafel irnyul hurokl reprezentlja. Mint lthat, a VFG a programok
vgrehajtsi menetnek az elvont brzolsra szolgl, a vgrehajts strukturlis vzt hordozza magban.
A grf egyes csompontjai kztt definiljuk az t fogalmt:
Az Si s Sj utastsok kztti t P(Si, Sj), az egymst kvet csompontok
azon sorozata, amely Si-vel kezddik s Sj-vel r vget. Az Si s Sj kztt
tbb lehetsges t ltezhet.
4.4. A programtesztels pszicholgija s
gazdasgossga (Glenford Myers elvei)
Jllehet a tesztels tmakrt szmos technikai szempontbl trgyalhatjuk,
gy tnik, hogy a legfontosabb szempontok a pszicholgihoz s a gazdasgossghoz ktdnek. Ms szval, az olyan megfontolsok, mint a tesztelshez val szellemi hozzlls, egy program teljes tesztelsnek kivitelezhetsge, vagy ki legyen a tesztels elvgzje, jval tbbet szmt a vgrehajts sikerben, mint a technikai megfontolsok. Ezekkel a krdsekkel
Glenford Myers (USA) foglalkozott behatbban.
Elszr is, vizsgljuk meg a tesztels cljnak krdst. Szoksos megfogalmazsok a kvetkezk:
Annak bizonytsa, hogy nincsenek a programban hibk.
Annak bizonytsa, hogy a program a neki sznt funkcikat helyesen hajtja vgre.
Ezek a defincik helytelenek, mivel ppen az ellenkezjt rjk le annak,
aminek a tesztelst tekintennk kellene. Egy program rtkt akkor tudjuk
nvelni, ha javtjuk a minsgt s megbzhatsgt. A megbzhatsg
nvelse azltal rhet el, hogy megkeressk s eltvoltjuk a hibkat. Abbl a feltevsbl kell teht kiindulnunk, hogy a program hibkat tartalmaz,
s azrt teszteljk, hogy minl tbb hibt fedjnk fel benne. Eszerint:
A tesztels clja a program olyan vgrehajtsa, amelyben a szndkunk a hibk
megtallsa.
Itt azonnal addik a krds, hogy md van-e arra, hogy az sszes hibt
megtalljuk. A vlasz egyrtelmen negatv, mg az egyszerbb esetekre
nzve is. Az ltalnos gyakorlatban nem rdemes, vagy ppensggel lehe-
Vissza
47
Vissza
48
tetlen mindegyik hibt kiszrni. Ez az alapvet problma kihatssal van a

tesztels gazdasgossgra, a programra vonatkoz elzetes feltevsekre,
s nem utols sorban a tesztek tervezsnek mdjra.
A funkcionlis megkzeltsben a programot fekete dobozknt kezeljk, ahol nem ismerjk a bels viselkedst s struktrt. Ilyenkor a tesztel
abban rdekelt, hogy a specifikcitl eltr mkdst fedezzen fel. Az
ehhez szksges bemen adatokat teht a specifikci alapjn lehet ellltani. Az sszes lehetsges hiba megtallsnak egy biztos mdja a kimert
inputtesztels, vagyis az sszes lehetsges bemen adat felhasznlsa. A hromszges programban pldul az sszes, a szmtgpen ltez egszszmot kellene a klnbz hrmas kombincikban megadni. Az ilyen
esetek szma csillagszati. De mg ez sem lenne elg: pldul nem fedn
fel azt a hibt, aminl a program a {2, A, 2} halmazbl egyenlszr hromszget hozna ki.
A bonyolultabb programok kimert tesztelse mg inkbb lehetetlen.
Egy Pascal fordtprogramnl pldul olyan teszteket kellene ksztennk,
amelyben az sszes rvnytelen Pascal programot rjuk le, elvrva azt,
hogy a kompjler mindegyiket rvnytelennek tudja nyilvntani. Ha valamelyiket helyes programnak fogadn el, az mr hiba lenne. A problma
mg slyosabb az olyan szoftverek esetben, amelyek memrival rendelkeznek. Ezeknl egy tranzakci vgrehajtsa fgg attl, hogy mi trtnt, mi hajtdott volt vgre azt megelzen. Pldul egy opercis rendszernl korbban melyik munkafolyamat (job) ment le. Ilyenkor teht nem
elg az rvnyes s rvnytelen tranzakcikat vgigprblni, hanem a
tranzakcik sszes lehetsges sorozatt is.
Az elbbi diszkusszi azt tmasztotta al, hogy a kimert inputtesztels lehetetlen. Ebbl kt kvetkeztetst vonhatunk le:
Nem lehet egy programot gy tesztelni, hogy garantlni tudjuk annak
hibamentes voltt.
A tesztels alapvet szempontja a gazdasgossg, vagyis annak elrse,
hogy minl tbb hibt fedjnk fel egy vges szm vizsglattal.
A msik stratgia a strukturlis megkzelts, amelyben a forrskd
alapjn vgezzk a vizsglatokat. Ebben az esetben a kimert inputtesztels analgja a forrskd sszes lehetsges mdon trtn vgigprblsa,
bejrsa volna. A teljes bejrshoz egyltaln nem elegend, ha az sszes
utasts vgrehajtdik legalbb egyszer. Ettl mg hibs hatrok kztt
futhat le egy ciklus, vagy hibs dnts elgazsokra kerlhet sor. Az ana-
Vissza
48
Vissza
49
lg prhuzam itt a kimert ttesztels lehet, vagyis az sszes lehetsges vgrehajtsi t vgigprblst eredmnyez vizsglati input megadsa.
A kimert ttesztels ugyancsak belthatatlan mennyisg szmtssal
jrna. Ennek demonstrlsra tekintsk a 4.1. brn szerepl vezrlsi
folyamatgrfot.
4.1. bra. Egy ciklusos vezrlsi folyamatgrf
Vissza
49
Vissza
50
A plda folyamatgrfja mintegy 15-20 utastst tartalmaz egyszer programot kpvisel. Tegyk fel, hogy az egyetlen DO-ciklus maximum 20-szor
hajtand vgre. A DO-cikluson bell begyazott IF-utastsok halmaza
helyezkedik el. Az elklnl logikai utak szmnak meghatrozsa
ugyanazt jelenti, mint az A pontbl a B-be val eljuts klnbz lehetsges mdjainak megszmllst. Ha feltesszk, hogy a grfon mindegyik
dnts fggetlen egymstl, akkor ez a szm megkzeltleg 1014, vagyis
100 trilli lesz. A pontos rtket a kvetkez sszeg kiszmtsval kaphatjuk meg:
520 + 519 + 518 + + 51,
ahol 5 a hurokban tallhat utak szma. Ha felttelezzk, hogy egy teszt
megrsa, vgrehajtsa s leellenrzse 5 percet ignyel, akkor a teljes folyamat krlbell egy millird vig tartana.
Termszetesen a valsgos programokban a dntsi elgazsok ltalban nem fggetlenek egymstl, vagyis a bejrand utak szma ezltal
kevesebb lesz. Ugyanakkor azonban a valsgos programok jval bonyolultabbak, mint a pldban szerepl. Ebbl lthat, hogy a kimert ttesztelst sem lehetsges a gyakorlatban alkalmazni.
A msik gondot az jelenti, hogy nem llthat, hogy a kimert ttesztelssel fel tudjuk fedni az sszes programhibt. Az egyik oka ennek az,
hogy egyltaln nem biztos, hogy a letesztelt program teljesti a specifikcijt. Ha pldul egy nvekv sorba rendez rutin helyett egy cskken
sorba rendezt runk, akkor a kimert ttesztels ezt nem tudn detektlni. A msik ok az, hogy egy program tves lehet attl is, hogy hinyoznak
belle utak. Az ttesztels ilyenkor nem lenne kpes kimutatni a hinyz
utakat. A harmadik gond az, hogy ez a megkzelts esetleg nem mutat ki
n. adatrzkenysgi hibkat, vagyis olyan hibkat, amelyek csak az adatok
bizonyos rtkei mellett lpnek fel. Erre egy egyszer plda az olyan szszehasonlts, amelyben azt akarjuk eldnteni, hogy kt vltoz adat kzti
eltrs kisebb-e, mint egy elre megadott rtk (konvergencia-vizsglatnl
jelentkez feladat). Ha a kvetkez utastst vesszk, ami
IF ((A B) < EPSZILON) THEN .
alak, akkor lthat, hogy az hibs, mivel az A B klnbsg abszolt
rtkt kellett volna vennnk. Ennek a hibnak felfedse azonban fgg az
A s B konkrt rtktl, s nem biztos, hogy a program sszes tjnak a
szisztematikus bejrsa kihozza ezt a felfedst.
Vissza
50
Vissza
51
sszegezve kijelenthetjk, hogy br a kimert inputtesztels fltte

ll a kimert ttesztelsnek, egyikk sem fogadhat el kvetend stratgiaknt, mivel nem lehet ket kivitelezni.
Tesztelsi elvek
A kvetkezkben nhny ltalnos irnyelvet sorakoztatunk fel a tesztels
minl clszerbb vgrehajtsra vonatkozan.
Egy tesztnek szksges rsze az elvrt kimenet vagy eredmny definilsa.
Ezt az egyszer elvet sok esetben figyelmen kvl szoktk hagyni. Ha az
elvrt eredmny nincs elre megadva, esly van arra, hogy egy ltszlag
jnak tn eredmnyt fogadjon el a tesztel szemly. Ez a folyamat ismt
sszefgg a szubjektivitsra val hajlammal. A helyes megoldsban teht
egy tesztelsi eset mindig a kvetkez sszetevbl kell hogy lljon: a
programnak sznt bemeneti adatok lersa, valamint a program kimen
adatainak precz lersa ugyanarra a bemeneti halmazra.
Clszer a tesztelst a fejlesztstl fggetlen szemly vagy szervezet ltal elvgeztetni.
Az, hogy egy programoz sajt maga ellenrizze le a programjt, tbb
htrnnyal jr. Egyrszt nincs arra motivlva, hogy minl tbb sajt hibt
fedjen fel. Msrszt a sajt flrertseibl add eltrsekre, hibkra nem
valszn, hogy r fogna rezni. Termszetesen jrhat t a sajt ellenrzs is, azonban hatkonyabbnak s sikeresebbnek vrhat el a kls fl
munkja. (Mindezek a megfontolsok nem vonatkoznak a fejleszts sorn
trtn hibakeressre, nyomkvetsre, mivel ott a programoz ltal menet
kzben felismert hibkrl van sz.)
Egy fejlesztsi szervezet szempontjbl hasonl rvek hozhatk fel,
mint egy szemly esetben. Msrszt azonban egy teamnl jelentkezik mg
egy fejlesztsi folyamat hatrids lezrsnak ignye is. Ebben htrltatn
ket egy alapos, mindent tfog objektv tesztels sajt erbl trtn
elvgzse.
A teszteket nemcsak elvrt s rvnyes bemeneti felttelekre kell rni, hanem olyan
felttelekre is, amiket nem vrunk el, ill. amik rvnytelenek.
Ennek az elvnek a hasznossgt a tapasztalat tmasztja al. Nagyon sok
hiba derlt mr ki olyankor, amikor a programot nem kell hozzrtssel
vagy szokatlan mdon hasznltk fel.
Vissza
51
Vissza
52
Annak a valsznsge, hogy egy programszakaszban mg hibk lteznek, egyenesen arnyos az ugyanott mr megtallt hibk szmval.
Ezt a jelensget, amit a gyakorlati tapasztalat igazol, a 4.2. brn szemlltetjk. Pldul, ha egy program kt modulbl ll, A-bl s B-bl, s A-ban
t hibt talltunk eddig, B-ben pedig csak egyet, s ha A-t mg nem vizsgltuk meg alaposan, akkor ez az elv azt mondja ki, hogy nagyobb a valsznsge annak, hogy A-ban mg tallunk hibt, mint annak, hogy B-ben
tallunk. Msknt fogalmazva, gy ltszik, hogy a hibk sokszor csoportosan jelentkeznek, klnsen az olyan modulokban, programszakaszokban,
amelyeket nehezebb volt megrni.
Tovbbi hibk
ltezsnek
valsznsge
Megtallt hibk szma
4.2. bra. A megmarad s a megtallt hibk kztti sszefggs

Ezt a megfigyelst jl ki tudjuk hasznlni akkor, amikor olyan rszhez
jutunk, amelyben tbb hiba jelentkezett, mint a tbbiben. Ekkor tovbbi
fokozott erfesztst rdemel a tallt rsz tvizsglsa.
A tesztels igen kreatv tevkenysg, s komoly szellemi kihvst jelent feladat.
Valsznleg igaz az, hogy egy nagy program tesztelshez szksges kreativits meghaladja ugyanannak a programnak a megtervezshez szksges
Vissza
52
Vissza
53
kreativitst. Jllehet egyre jabb szisztematikus mdszereket dolgoznak ki

a szoftverek vizsglatra, ezek a mdszerek tovbbra is jelents kreativitst ignyelnek.
A teszttervezs kulcskrdse
A szoftvervizsglat legfontosabb sszetevje s velejrja a hatkony tesztek megtervezse. A hatkonysg azrt fontos, mert tudatban vagyunk
annak, hogy nem lehetsges a meglev sszes hiba tesztjt ellltani. A
kzenfekv stratgia ekkor arra trekedni, hogy amennyire csak lehetsges, cskkentsk a megmaradt hibk szmt. Tekintetbe vve az idt,
kltsgeket, gpidt, stb. a tesztels kulcskrdse a kvetkez lesz:
Az sszes lehetsges teszt mely rszhalmaza detektlja a legnagyobb valsznsggel a legtbb hibt?
A legkisebb hatkonysg metodolgia minden bizonnyal a vletlenszer
tesztels, amelyben random mdon kpezzk bemeneti rtkeknek egyegy halmazt. A legtbb hiba detektlsra vonatkoz valsznsget tekintve, a random rtkeknl kis esly van arra, hogy optimlisak legyenek,
vagy akr kzel optimlis rszhalmazt kpezzenek.
A tovbbiakban eltrbe helyezzk a determinisztikus ton trtn
tervezst, ahol arra treksznk, hogy minl tgondoltabban alaktsuk ki a
felhasznlsra kerl tesztkszleteket. Kln foglalkozunk a funkcionlis
s kln a strukturlis megkzeltssel. A kt megkzelts jellegbl addan azok nem azonos hibahalmazok felfedsre lesznek alkalmasak (br
termszetesen tfeds biztosan van a halmazok kztt), ezrt ha az lehetsges, mindig rdemes a kt megolds mindegyikt felhasznlni, egymst
kveten. Kifejleszthet egy szszeren szigor tesztfolyamat a fekete
dobozos kezelsmdban, ennek kiegsztseknt pedig egy olyan folyamat,
amely a program bels logikjt is vgigkveti, a fehr dobozos mdban.
Ajnlatos a fejlesztsi fzisokat az itt lert sorrendben vgezni: elbb a
fekete, azutn a fehr. Ehhez mg annyit jegyznk meg, hogy elfordulhatnak esetek, amikor a tesztelst vgzk szmra nem ll rendelkezsre a forrskd, csak a mkd szoftver maga. Ilyenkor termszetesen le
kell mondanunk a strukturlis vizsglatokrl.
4.5. Funkcionlis tesztels
Ebben az alpontban a funkcionlis tesztels megvalstsra mutatunk be
klnbz szisztematikus mdszereket.
Vissza
53
Vissza
54
4.5.1. Ekvivalencia partcionls
A clunk a lehetsges bemeneti adatok olyan rszhalmazt kpezni, amely

a legnagyobb valsznsggel a legtbb hibt fedi fel. E rszhalmaz megkeresshez rdemes mg tekintetbe venni azt, hogy egy jl megvlasztott
teszt kt msik tulajdonsggal is rendelkezik:
1. Egynl tbbel reduklja azon ms teszteknek a szmt, amelyeket azrt
kellene kialaktani, hogy egy szszer, hatkony tesztelst rjnk el.
2. Ms lehetsges tesztek nagy halmazt fedi le, vagyis kpes azokat helyettesteni.
Ez a kt tulajdonsg kt eltr meggondolst foglal magban, ill. von maga utn. Az els azt, hogy mindegyik teszt annyi klnbz bemeneti felttelt r el, amennyi csak lehetsges, annak rdekben, hogy minimalizlja
a szksges tesztek szmt. A msik azt, hogy meg kell ksrelni a program
input adatainak tartomnyt olyan n. ekvivalencia osztlyokba csoportostani, partcionlni, amelyekrl fel tudjuk ttelezni, hogy egy adott osztlyhoz
tartoz teszt adatrtkei ekvivalensek a teszt brmelyik ms adatrtkeivel.
Egyazon ekvivalencia osztlyba azok a tesztek (bemeneti adatcsoportok)
tartoznak, amelyek ugyanazt a hibt fedik fel. Vagyis, ha az ekvivalencia
osztly egy tesztje detektl egy hibt, az osztly minden tesztjtl azt vrjuk el, hogy ugyanazt a hibt legyen kpes detektlni. Megfordtva: ha egy
teszt nem fed fel egy hibt, akkor azt vrjuk el, hogy az ekvivalencia osztly ms tesztjei sem fogjk ezt a hibt felfedni. (Kivve azt az esetet, amikor egy ekvivalencia osztly rszhalmaza egy msik ekvivalencia osztlyba
is esik. Ez akkor llhat el, amikor klnbz ekvivalencia osztlyok tfedik egymst.) Az elv mgtt az a meggondols rejlik, hogy vrhatan elegend lesz egy osztlybl csak egyetlen tesztet kivlasztani, ami akrmelyik
lehet, mg az osztly tbbi tesztjtl mr nem vrunk el j hibafelfedst.
A fenti kt meggondols egy funkcionlis tesztelsi metodolgit kpez, amit ekvivalencia partcionlsnak neveznk. A msodik meggondolst
arra hasznljuk, hogy rdekes feltteleket talljunk a tesztelsre. Az els
meggondolst ezutn arra hasznljuk, hogy minimlis szm tesztet keressnk ezen felttelek lefedsre. A hromszges pldt vve, ugyanabba az
ekvivalencia osztlyba sorolhatk azok a bemeneti adatok, amelyek hrom
azonos rtk, nullnl nagyobb egsz szmot kpeznek. Ezekrl felttelezzk, hogy ha az egyik szmhrmas nem fed fel hibt, akkor a msik sem
fog. Msknt fogalmazva: a tesztelsi idt ms esetekre tudjuk fordtani,
msik ekvivalencia osztlyok bevonsval.
Vissza
54
Vissza
55
A mdszer kt lpsbl ll: Elszr meghatrozand az ekvivalencia

osztly, azutn pedig az oda tartoz tesztek definilsa kvetkezik.
Az ekvivalencia osztlyok meghatrozsa
Az ekvivalencia osztlyok keresse alapjban vve egy heurisztikus folyamat. Egyms utn sorra vesszk a bemeneti feltteleket, s csoportokba
soroljuk ket. Kt tpus ekvivalencia osztlyt kell keresnnk: egyrszt
rvnyeset, amelyben rvnyes bemenetek vannak, msrszt rvnytelent,
amelyben rvnytelen, hibs bemeneti adatok vannak. Nhny irnyelv a
keresshez:
Ha egy bemeneti felttel rtktartomnyt r el, akkor egy ebbe es
rvnyes osztlyt, tovbb egy vagy tbb nem ebbe es rvnytelen
osztlyt vlasszunk. Pldul, ha egy darabszm 1 s 999 kz eshet,
akkor rvnytelen osztlyknt 1-nl kisebb darabszmot, valamint 999nl nagyobb darabszmot vlasszunk.
Ha egy ttelnek adott szm vltozata lehet (mondjuk 12), akkor kt
rvnytelen osztlyt adhatunk meg: egyet a 0-ra, egyet pedig a 12-nl
nagyobbra.
Ha egy bemeneti felttel ktelez elrst tartalmaz (pldul egy azonost els karaktere bet kell legyen), akkor egy rvnyes osztly lesz
a betvel kezdd, s egy rvnytelen ami nem betvel kezddik.
A tesztek meghatrozsa
Az ekvivalencia osztlyok hasznlatnak msodik lpseknt a tesztek
kivlogatsra kerl sor. Ennek folyamata a kvetkez:
Mindegyik ekvivalencia osztlyhoz sajt azonost szmot rendelnk.
Az rvnyes ekvivalencia osztlyokhoz gy vlasszunk teszteket egyms utn, hogy egy-egy teszt minl tbb osztlyt tudjon kpviselni,
ms szval lefedni. Clunk az sszes osztly lefedse teszttel.
Az rvnytelen ekvivalencia osztlyokhoz egyenknt vlasszunk tesztet
gy, hogy az csak egyetlen osztlyt fedjen le. A cl itt is az sszes osztly lefedse.
Az rvnytelen osztlyok egyedi teszttel val lefedsnek az az oka, hogy
lehetnek olyan hibs bemeneti adatok, amelyek egy msik hibs adat detektlst histank meg. Ezrt rdemes mindegyik hibs adatot nllan,
egyedileg kezelni.
Vissza
55
Vissza
56
Jllehet az ekvivalencia osztlyokra val partcionls jval hatkonyabb, mint a random kivlaszts, mgis maradhatnak ki hatkony tesztek
az alkalmazsa utn. Emiatt rdemes ms mdszereket is ignybe venni. A
kvetkezkben ilyen mdszereket ismertetnk.
4.5.2. Hatrrtk-analzis
A tapasztalatok szerint azok a tesztek, amelyek a hatrrtkekre vonatkoz feltteleket rnak el, kifizetdbbek, mint azok, amelyek nem. A
hatrfelttelek a bemeneti s kimeneti adattartomnyok als s fels szlt
jelentik. A vizsglatokat ezen rtkek krl rdemes vgezni, vagyis a hatrrtken, ill. alatta s felette. A hatrrtk-analzis kt szempontbl klnbzik az ekvivalencia felosztstl:
1. Egy ekvivalencia osztlyt tekintve annyi szmrtket tartalmaz, amenynyire szksg van az osztly mindegyik hatrrtknek a vizsglathoz.
Egy ekvivalencia osztlynak ugyanis tbb hatrrtke is lehet.
2. Nemcsak a bemeneti felttelekre kell koncentrlni, hanem a kimenetiekre is, ahol a kimeneti ekvivalencia osztlyok hatrrtkeit vesszk
szmtsba.
ltalnos receptet nem lehet adni, ez a mdszer sok intuitivitst is ignyel.
Mindazonltal nhny irnymutatt adunk az albbiak szerint:
1. Ha egy bemeneti felttel rtktartomnyt tartalmaz, akkor teszteket
runk a tartomny szleire, tovbb rvnytelen bemenet teszteket, a
szlsrtkeket minimlisan tllpve. Pldul, ha egy bemeneti rtk
(1,0) s (+1,0) kz eshet, akkor a tesztek a kvetkezk lehetnek:
1,0, 1,0, 1,001, valamint 1,001.
2. Ha egy bemeneti felttel fix szm rtket enged meg egy vltozzra,
a minimumra, a maximumra, tovbb alatta s felette rdemes egy-egy
rtket megadni. Pldul, ha egy input fjlnak 1255 rekordja ltezhet,
akkor a teszteket 0, 1, 255, s 256 rekordra rjuk el.
3. Hasznljuk fel az 1-es tmutatt a kimeneti felttelekre is. A kimeneti
hatrrtkek vizsglata azrt is fontos, mert azok nem mindig a bemeneti hatrrtkek hatsra jnnek ltre (ilyen pl. a szinusz fggvny).
Msrszrl nem mindig lehetsges a kimeneti hatrrtkeken tli
eredmnyt produklni, a vizsglatot akkor is rdemes elvgezni, ahhoz
hogy a hiba lehetsgt biztosan ki tudjuk zrni.
4. Ugyancsak hasznljuk fel a 2-es tmutatt is mindegyik kimeneti felttelhez.
Vissza
56
Vissza
57
5. Ha egy program inputja vagy outputja sorrendezett halmaz (pl. egy

szekvencilis fjl, lineris lista, tblzat), akkor szenteljnk figyelmet a
halmaz els s utols elemnek.
6. Mindezeken tl, ksreljnk meg a sajt megfigyelseink alapjn minl
tbb jabb hatrrtk-felttelt elrni.
Pldaknt ismt vehetjk a hromszges feladatot. Ott a bemeneti adatokra az a felttel rvnyes, hogy mindhrman 0-nl nagyobb egsz szmok,
msrszt brmelyik kettjk sszege nagyobb kell legyen a harmadiknl.
Ezekre az esetekre ekvivalencia partcikat tudunk megadni, mind a teljeslskre, mind pedig a nem teljeslskre. Az erre szolgl lehetsges teszt
esetek pldul az rvnyes {3, 4 ,5} halmaz, ill. az rvnytelen {1, 2, 4}
halmaz. Ezzel azonban mg kihagytuk egy valsznsthet hiba tesztjt.
Ha a programban az rtkellenrzst A + B C alakban kdoltk, a helyes
A + B > C helyett, akkor a hibs {1, 2, 3} halmaz rvnyesnek lenne elfogadva. A szlsrtk-analzis viszont ezt a hibt kiszrn azzal, hogy az
ekvivalencia partcik szlein s azok krnyezetben vgezn az ellenrzst.
4.5.3. Ok-hats-analzis
Az ekvivalencia partcionlsnak s a hatrrtk-analzisnek az a kzs hinyossga, hogy nem vonjk be a vizsglatba a bemeneti felttelek kombinciit. A bemeneti kombincik sorravtele nehz feladat, mivel a lehetsges
tesztek szma rendszerint horribiliss vlhat. Ezen a tren mindenkppen
arra kell trekedni, hogy szisztematikus mdon vlogassuk ki a lehetsges
kombincik azon rszhalmazt, amely a lehet leghatkonyabb lesz.
Az ok-hats-analzis olyan technika, amely eredmnyes tesztek szisztematikus kivlogatst teszi lehetv. Megjegyzend mg, hogy a mdszernek olyan hasznos mellkhatsa is van, amellyel specifikcis hinyossgokat s ellentmondsokat tudunk felfedezni. Az eljrshoz Boole-algebrai
formalizmust hasznlunk fel, a szoksos alapmveletek bevonsval.
Ezek: S, VAGY, valamint NEM. A mveletekhez az ket megjelent
logikai kapukat tudjuk ignybe venni, ill. a kapukbl felpl kombincis
logikai hlzat grfreprezentcijt, az n. Boole-grfot.
A Boole-grf egy irnytott grf, melynek csompontjai a logikai mveleteket kpviselik. Egy csompontba befut lek ugyancsak egy-egy
csompontbl indulnak ki. Egy csompont 0 vagy 1 rtket vehet fel,
ahol a 0 rtelmezse a hinyzik (nincs), az 1- pedig a jelen van (ltezik). A
grf jellsrendszert a 4.3. bra foglalja ssze. A NEM mvelet az a rt-
Vissza
57
Vissza
58
kt invertlja b rtkeknt, az S mvelet csak akkor ad 1-et c-nek, ha

mind a, mind pedig b rtke 1, klnben c 0 lesz. A VAGY mvelet rtelmben c csak akkor lesz 0, ha mind a, mind b 0, klnben pedig c rtke 1
lesz.
NEM
a
VAGY
v
c
c
b
b
4.3. bra. Az ok-hats Boole-grfjnak jellsei
A tesztek leszrmaztatsa a szoftver-specifikci alapjn trtnik, a kvetkez folyamat lpsei szerint:

1. A specifikci felbontand kisebb, feldolgozhat rszekre. Erre
azrt van szksg, mivel az ok-hats grf tl bonyolultt s ttekinthetetlenn vlik nagyobb mret specifikciknl. Pldul, egy idosztsos rendszer tesztelsnl kln feldolgozhat rsz lehet egy-egy parancsra vonatkoz specifikci. Egy kompjler tesztelsnl kln kezelend egysg lehet egy-egy nyelvi utasts.
2. A specifikciban egy ok nem ms mint egy bemeneti felttel vagy egy
bemeneti ekvivalencia osztly. Egy hats a kimeneti felttelben nyilvnul meg. Az okok s hatsok a specifikci vgigkvetsvel azonostandk: ennek sorn egyenknt ki kell vlasztani azokat a szvegelemeket, ill. elrsokat, amelyek egy-egy okot, ill. annak hatst kpviselik. Mindegyik ok s hats kln azonost szmot kap.
3. A specifikci szemantikus tartalmt elemezve ltrehozzuk azt a
Boole-grfot, amely logikailag sszekapcsolja az okokat s hatsokat.
Ez lesz az n. ok-hats grf.
Vissza
58
Vissza
59
4. A grfhoz mg hozz kell rendelnnk azokat a kiegszt megszortsokat, amelyek meg nem engedett okok s hatsok kombincijt foglaljk magukba.
5. A grf llapotfeltteleinek mdszeres vgigkvetsvel a grfot egy n.
dntsi tblzatba konvertljuk t. A tblzat mindegyik oszlopa egy
tesztet kpvisel.
6. A dntsi tblzat mindegyik oszlopbl leszrmaztatjuk a teszteket.
Egy grf illusztrlsra vegyk a kvetkez rvid specifikcit.
Az 1-es oszlopban lev karakter A vagy B kell legyen. A 2-es oszlop karaktere csak szmjegy lehet. Ezzel a megadssal fjl-frissts (updateols) hajtdik vgre. Ha az els karakter helytelen, az X12 zenet jelenik
meg, ha a msodik helytelen, akkor pedig az X13 zenet.
Az okok a kvetkezk:
(1) Az 1-es oszlop karaktere A.
(2) Az 1-es oszlop karaktere B.
(3) A 2-es oszlop karaktere szmjegy.
A hatsok a kvetkezk lesznek:
(71) Frissts hajtdik vgre.
(72) Az X12 zenet jelenik meg.
(73) Az X13 zenet jelenik meg.
A specifikcit megjelent ok-hats grf a 4.4. brn lthat.
72
v
4
2
^71
73
4.4. bra. Ok-hats grf
Vissza
59
Vissza
60
Jllehet a grf a specifikcit reprezentlja, egy olyan ok-kombincit is

tartalmaz, ami nincs megengedve: az (1) s (2) nem lehet egyszerre 1-es
rtk. Ez ltalban is gyakran elfordul eset, amely a lehetsges tesztek
szmt cskkenti. Ugyangy lehetsgesek az olyan specifikcik is, amelyekben bizonyos kimeneti hatsok sem lphetnek fel.
A grf alapjn a ltrehozand n. dntsi tblzat valjban nem ms
mint a grf ltal kpviselt logikai hlzat igazsgtblzata. Ez az igazsgtblzat 0-t s 1-et tartalmaz, s azt rja le, hogy mik azok a bemeneti logikai
felttelek, amelyekre egy-egy kimenet 1-es rtk lesz. A dntsi tbla
meghatrozsa gy trtnik, hogy kivlasztunk egy kimeneti hatst, s viszszafel haladva a grfon megkeressk azokat a logikai feltteleket, egszen
a bemeneti okokig haladva, amelyek a hats bekvetkezst idzik el. Ms
szval ez azt jelenti, hogy meghatrozzuk azokat a bementi 01 kombincikat, amelyek a logikai hlzatban 1-es kimeneti rtkeket produklnak.
Ez pedig a hlzat olyan igazsgtblzata, amelyben a 0 kimeneti rtkhez
nem adunk meg bemeneti kombincit. Ennek megfelelen a tblzat nem
tartalmaz olyan sort, amelyben mindegyik hats rtke 0 lenne.
A dntsi tblzatban mindegyik bemeneti okhoz, ill. mindegyik kimeneti hatshoz egy-egy sor tartozik. Az oszlopok szmt az adja meg, hogy
mennyi klnbz lehetsges bemeneti kombinci tud elidzni egy-egy
kimeneti hatst. Ebben az elrendezsben egy oszlop egy tesztet kpvisel:
azokat a bementi okokat, ill. okok hinyt foglalja magban, amelyekre a
kimeneti hats bekvetkezik.
A pldnkban szerepl Boole-grf alapjn a 4.5. brn szerepl dntsi
tblzatot tudjuk leszrmaztatni.
1
2
3
71
72
73
1
0
1
1
1
0
0
2
1
0
1
1
0
0
3
1
1
1
1
0
0
4
0
0
0
0
1
1
5
0
0
1
0
1
0
6
0
1
0
0
0
1
7
1
0
0
0
0
1
8
1
1
0
0
0
1
4.5. bra. Dntsi tblzat
Vissza
60
Vissza
61
A dntsi tblzat 1-es oszlopa ltal kpviselt teszt a kvetkez: az 1-es

oszlop B bett, a 2-es oszlop szmjegyet tartalmaz, ami legyen pldul 5.
A 4-es oszlop alapjn kpezhet teszt: Az els oszlop karaktere nem A s
nem B, a harmadik oszlop karaktere pedig nem szmjegy. A konkrt teszt
pldul lehet QY.
A tblzathoz mg kt kiegsztst fznk:
1. A 3-adik s 8-adik oszlop tesztjei nem rtelmezhetek, hiszen nem
lehet egyidejleg A-t is meg B-t is megadni els karakterknt. Mint
tudjuk, ez az eset meg nem engedett kombinciknt szerepelt a fentiekben.
2. Lthat, hogy ugyanazt a hatst tbb klnbz bemeneti okkombinci segtsgvel is el tudjuk rni. Ez azt jelenti, hogy tesztek
klnbz kombincija szolgl a hatsok vizsglathoz. Ugyanakkor
az is lthat, hogy a 4-ik oszlop tesztje egyszerre alkalmas a 72-es s
73-as hatsok ellenrzsre. Ezek a tulajdonsgok azt eredmnyezik,
hogy hatkony teszteket tudunk leszrmaztatni.
Az elbbiekben hrom funkcionlis tpus teszttervezsi mdszert ismertettnk. Ezeket a mdszereket mindenkppen clszer egymssal kombinlni, mivel mindegyikk egy bizonyos hasznos teszthalmazt produkl,
amelyek jl kiegsztik egymst a hibk felfedse tekintetben. Az egyes
mdszereket a kvetkez sorrendben tancsos vgrehajtani:
1. Ok-hats analzis.
2. Hatrrtk-analzis.
3. Ekvivalencia partcionls.
A klnbz teszteknek s az ltaluk vizsglt funkciknak a kapcsolatt az
n. tesztlefedsi mtrixon lehet sszesteni. A mtrix soraihoz a tesztek, oszlopaihoz a funkcik tartoznak. Ha az i-edik teszt a j-edik funkci ellenrzsre alkalmas, akkor a mtrixban ezt stttett kockval brzoljuk. Pldaknt a 4.6. bra mtrixt mutatjuk be.
Vissza
61
Vissza
62
Vizsglt funkcik
1
10
1
2
3
4
5
6
7
8
9
10
4.6. bra. Egy tesztlefedsi mtrix

4.5.4. A vletlenszer tesztgenerls felhasznlsa
Mr korbban emltettk, hogy a vletlenszeren (random mdon) kpzett bemeneti adatoknak a hibafelfed kpessge meglehetsen korltozott a
determinisztikusan ellltott tesztekhez kpest. Ennek ellenre mindenkppen rdemes ezt a megkzeltst is bekapcsolni a tesztelsi stratginkba. Ennek a legfbb oka az, hogy a vletlen szmok ellltsa s bemeneti
adatknt val felhasznlsa elhanyagolhat szmtsi rfordtssal jr a
determinisztikus adatkpzshez kpest. A msik emltst rdeml ok az,
hogy nagyszm, nagytmeg adatot tudunk gy a folyamatban ignybe
venni, ami megnveli az eslyt a hibafelfedsnek. A random tesztek olyan
hibk felfedst is eredmnyezhetik, amelyek a determinisztikus teszttervezsnl elkerltk a figyelmet.
A vletlen szmok ellltsnak folyamatt mindenkppen clszer
elre tgondolt, megtervezett mdon vgezni. A kvetkezkben egy erre
vonatkoz szervezsi elvet ismertetnk:
Vissza
62
Vissza
63
1. Hatrozzunk meg mindegyik bemen adathoz egy olyan szmtartomnyt, amelyen bell a vletlen szmok kpzst akarjuk elvgezni.
2. Az egyes adatokhoz kpezzk a sajt tartomnyukon bell es, normlis eloszls random szmokat, amelyek a bemeneti tesztadatok lesznek.
3. A szoftverre adott teszteket kt mdon szervezhetjk:
Egy vagy annl tbb, de nem mindegyik adat vltozik random mdon, a tbbi rgztett rtken ll.
Mindegyik adat vltozik a sajt tartomnyn bell.
4. A tesztvlaszok meghatrozsa random inputok esetn kln meggondolst ignyel. Vgl is hrom eset lehetsges:
Az egyes tesztszmok ismeretben magunk hatrozzuk meg az elvrt vlaszreakcikat.
Ha automatizltan kldjk a szoftverre a random teszteket, akkor a
reakcik folyamatos kls figyelse a feladatunk, anlkl, hogy
tudnnk mit kell elvrnunk. Ebben a mkdsi mdban a feladatunk abbl ll, hogy azt dntsk el mindig, hogy nem trtnt-e valamilyen szrevehet rendellenes megnyilvnuls. (Itt az automatizmust egy tesztmeghajt keretprogram kpviseli, amely a random
szmgenertort is magban foglalja.)
Lehetsges olyan szimulcis krnyezet ltrehozsa is, amelyben a
random bemeneti rtkekre adott vlaszadatok kiszmtsa a szimulcis szoftvernek a feladata.
Ezzel befejeztk a funkcionlis tesztelsi elvek s mdszerek ttekintst.
A kvetkez alfejezetben a strukturlis megkzeltssel foglalkozunk rszletesebben.
4.6. Strukturlis tesztels
Mint mr korbban emltettk a szoftver tesztelsi technikk ill. mdszerek kt f csoportba sorolhatak:
Funkcionlis (black-box) tesztels s
Strukturlis (white-box) tesztels (ST).
Mg funkcionlis tesztels esetn a tesztelt szoftver felptst, a megvalsts rszleteit nem vesszk figyelembe, addig a ST esetn a tesztels a
szoftver a specifikciban megadott funkcit megvalst program szerkezete alapjn trtnik.
Vissza
63
Vissza
64
ST esetn a program vezrlsi szerkezett modellezzk s a tesztel

adott szempontrendszer szerint a vezrlsi szerkezet minden gt, a
program minden alternatv rszt vgrehajtva vizsglja annak mkdst.
4.6.1. Hibamodell ST esetn
A hibamodell nem ms, mint a lehetsges hibk valamilyen knnyen kezelhet, tmr lersa. A szoftver tesztels ltalnos problmja a megfelel hibamodell generlsa. A nehzsget az jelenti, hogy a szoftver hibk
forrsa igen vltozatos: megklnbztethetnk specifikcis, tervezsi
kdolsi stb. hibkat.
A hibamodelltl azt vrjuk, hogy egyrszt leth legyen, vagyis tartalmazza (lerja) az sszes elfordul hibt, msrszt a tesztels sorn knynyen hasznlhat legyen. Ez utbbi ignyt kevsb lehet tmren, egzakt
mdon meghatrozni, mert a meghatrozs fgghet a konkrt tesztelsi
mdszertl. ltalnossgban a kvetkezket mondhatjuk: A tesztels sorn trtn knny felhasznlhatsg magban foglalja azt az ignyt, hogy
a hibamodell adjon lehetsget a lehetsges hibk szisztematikus (algoritmikus) kezelsre, a tesztels sorn mr lefedett (tesztelt) hibk arnynak
meghatrozsra, adott teszthalmaz hibafedsnek meghatrozsra stb.
ltalnos tapasztalat, hogy a szoftver tesztels esetn nem lehet olyan
hibamodellt tallni, amely minden alkalmazs esetn, minden fejlesztsi
krnyezetben jl hasznlhat lenne. Az egyes hibamodellek a felttelezhet szoftver hibknak csak egy rszhalmazt fedik le (4.7. bra). ltalban a
klnbz technikk ms s ms rszhalmazt fedik le, ezrt ltalnos elv,
hogy clszer a klnbz technikkat egymssal vegyesen hasznlni a
tesztels sorn.
4.7. bra. Szoftver hibamodellek ltal lefedett hibk viszonya
Vissza
64
Vissza
65
4.6.2. A strukturlis tesztels alapjai
A ST arra a megllaptsra alapszik, hogy a szoftver hibk ltalban a vezrlsi szerkezetet rintik (Beizer, 1990). Pl.: A programoz if( c ) kifejezs helyett if( !c ) kifejezst hasznl. Termszetesen ez a kijelents a gyakorlati eseteknek csak egy rszben helytll, ezrt szksges meghatrozni azokat az alkalmazsi terleteket s tesztelsi clokat, ahol a ST hatkonyan hasznlhat. ltalnossgban azonban kijelenthetjk, hogy ha a fenti
llts igaz, akkor a strukturlis tesztelsi technikk hatkonyan alkalmazhatak.
Vizsgljuk meg rszletesen, a ST ltal hasznlt hibamodell tulajdonsgait. A strukturlis tesztelskor a tesztel lnyegben nem foglalkozik a
feldertend hiba termszetvel. Csak a hibamentes program mkdst,
vezrlsi szerkezett modellezi a ksbbiekben rszletesen is bemutatand
.n. folyamat vezrls grf segtsgvel. A tesztel azt felttelezi, hogy a
programban ltrejv hibk valamilyen mdon befolysoljk a a vezrlsi
szerkezet mkdst (a folyamat vezrlsi grf bejrst). A hasznlt hibamodell lnyegben egy implicit hibamodell, mert a tesztel nem hatrozza meg explicit mdon, milyen hibkat tesztel.
4.6.3. A tesztels menete ST esetn
A ST, mint a tbbi tesztels mdszer is kt fzisra bonthat:

tesztgenerls s
teszt vgrehajts.
A tesztgenerls teszt bemenetek generlst jelenti valamilyen mrtkszm
alapjn. A mrtkszm annak jellemzsre szolgl szmszer paramter,
hogy a generlt teszt bemenetek mennyire alaposan vizsgljk meg az
egyes kdrszleteket, mennyire alaposan vizsgljk meg a vezrlsi szerkezet vgrehajtst. A mrtkszmokat ltalnosan is hasznlhatjuk a teszthalmazok, ill. a tesztelsi procedra hatkonysgnak, alapossgnak jellemzsre. A mrtkszmokrl, ill. alkalmazsukrl a kvetkez fejezetben
lesz sz.
A teszt vgrehajtsa lnyegben nem ms, mint a program egy vezrlsi gnak vgrehajtsa. A tesztelshez hozztartozik a program kimeneteinek, eredmnyeinek sszehasonltsa a specifikciban rgztettel. A
strukturlis tesztelsi eljrsok nem definiljk, milyen mdszerrel trtnjen az sszehasonlts, ezzel alkalmazsukkor minden konkrt esetben
kln kell foglalkozni. Strukturlis tesztels esetn a kimenetek vizsglatn
Vissza
65
Vissza
66
tl szksges a vezrlsi szerkezet vgrehajtott vezrlsi gnak azonostsa is. Ennek megfigyelst vagy magnak a kdnak, vagy a tesztelsi krnyezetnek kell tmogatnia.
4.6.4. A strukturlis tesztels elnyei s felhasznlsa
A strukturlis tesztels egyik legnagyobb elnye az implicit hibamodellbl

addik. ST segtsgvel hibkat kereshetnk anlkl, hogy tudnnk, milyen
szoftver hibkat is keresnk.
A msik kedvez tulajdonsga az ST-nek, hogy a funkcionlis tesztelssel ellenttben szisztematikus algoritmusok ltal jl kezelhet matematikai modellt (vezrlsi folyamat grf) hasznl. Radsul a tesztels hatkonysgnak mrsre szmszer mrtkszmokat lehet hasznlni. sszehasonlthat kt teszthalmaz jsga, vagyis hogy mennyire alaposan
tesztelnek egy adott szoftvert. (A teszthalmazokhoz trstott mrszmokat csak vatosan szabad a teszthalmazok hibafedsnek nevezni, hiszen
az implicit hibamodell miatt ilyenrl nehz is lenne beszlni. Sokkal inkbb a teszthalmaz tesztelsnek adott szempont szerinti alapossgt jellemzik ezek a mrtkszmok.)
Az eddigieket sszefoglalva meghatrozhatjuk azokat az alkalmazsi
terleteket, ahol a ST hatkonyan alkalmazhat tesztelsre:
Vezrls intenzv alkalmazsok. Ezeknl az alkalmazsoknl j valsznsggel igaz a fent idzett llts, hogy a szoftver hibk ltalban a vezrlsi szerkezetet rintik.
Tervezsi hibk feldertse. Elssorban itt nem az adatszerkezeteket rint hibkra kell gondolni, hanem olyan globlis logikai hibkra, amelyek
a vezrlsi szerkezetet rintik. Ilyen pl. az elrhetetlen (dead) kdrszek feldertse.
Szabvnyok szerinti tesztels. Mivel ST esetn szmszersthet a tesztels alapossga a klnbz szoftver tesztelssel foglalkoz szabvnyok
elszeretettel rnak el valamilyen mrtkszm szerint ST technikt,
mint ktelezen vgrehajtand tesztelsi lpst.
4.6.5. A vezrlsi szerkezet modellezse
Mint emltettk ST sorn a program vezrlsi szerkezett modellezzk az

n. folyamat vezrlsi grf (FVG, Control Flow Graph CFG) segtsgvel.
AZ FVG egy grf modell. A grf pontok az utastsoknak feleltethetk
meg. Az utastsokat reprezentl grf pontokon kvl a program kezdett, belpsi pontjt s vgt, kilpsi pontjt is egy-egy grf pont repre-
Vissza
66
Vissza
67
zentlja. A grf szrmaztatsa igen egyszer, az egyms utn vgrehajthat

utastsokat egy-egy irnytott grf l kti ssze.
A grfpontoknak kt tpust klnbztethetjk meg:
Egyszer (szekvencilis) grf pont, amelybl egyetlen grf l indul ki,
s egy szekvencilis utastst reprezentl.
Elgazs grfpont, amelybl egynl tbb grf l indul ki, s egy elgazs utasts (predicate statement) feleltethet meg neki. (AZ FVG esetn az egyszerbb kezelhetsg miatt ltalban a kimen lek szmt
kettben szoktk limitlni.) Az elgazs utastsban mindig szerepel
egy felttel, mely meghatrozza, hogy az utasts vgrehajtsakor melyik kvetkez utasts hajtdik vgre.
A 4.8. brn egy kdrszletet s az azt modellez FVG-t lthatunk. A
grfpontokban a pontok ltal reprezentlt utasts szma szerepel.
1:
2:
3:
4:
5:
6:
7:
mid = (low + high) / 2;

if (x == list[mid])
found = 1;
if (x > list[mid])
low = mid+1;
if (x < list[mid])
high = mid;
START
2
3
4
5
6
7
END
4.8. bra. Plda az FVG generlsra
Vissza
67
Vissza
68
A programok vgrehajtsa is kvethet, ill. szemlltethet, az FVG segtsgvel. Hasznljuk azt a terminolgit, hogy ha egyms utn vgrehajtdik egy program kt utastsa, akkor FVG-ben bejrjuk a kt utastsoknak
megfelel kt grf pontot, ill. a kztk lv let. A program minden, adott
bemenetek hatsra trtn vgrehajtsakor az FVG egy jellemz pont- s
lsorozata jrdik be.
A program minden futtatskor a belpsi ponttl a kilpsi pontig tart pont- s lsorozatot sorozatot, egy n. grf utat jr be. A 4.9. brn a
fenti FVG-ben lehetsges utak felsorolst talljuk.
1
2
3
4
5
6
7
1
2
3
4
5
6
1
2
3
4
6
7
1
2
3
4
6
1
2
4
5
6
7
1
2
4
5
6
1
2
4
6
7
1
2
4
6
4.9. bra. Utak az FVG-ben

AZ FVG elemzse alapjn meghatrozott utak nem mindegyike jrhat
azonban be a valsgban. Mivel az elgazs utastsokban szerepl felttelek nem fggetlenek egymstl, gy egyes lek kivlasztsa mr meghatrozhatja valamelyik msik ksbbi elgazs utasts felttelt, vagyis egy
msik g bejrst. Az 4.8. brn lthat kdban az egymst kvet felttelek kzl csak egy lehet igaz (Az x vltoz rtke vagy kisebb, vagy
egyenl, vagy nagyobb a list[mid] rtknl.) A 4.9. brn a tnylegesen
bejrhat utakat vastagon szedtk.
4.6.6. Programok vezrlsi bonyolultsga
A programok vezrlsi szerkezetnek bonyolultsga egymstl igen eltr

lehet. A tesztels feladata termszetesen sokkal bonyolultabb egy komplex
vezrlsi szerkezettel rendelkez program esetn. Ezrt bevezettek egy, a
programok vezrlsi szerkezetnek bonyolultsgra jellemz szmot az
n. ciklomatikus komplexits-t (CK, Cyclomatic Complexity).
AZ FVG-ben fggetlen tnak neveznk kt utat, ha mindkettben ltezik olyan pont vagy l, amely nem eleme a msik tnak.
A ciklomatikus komplexits az FVG-ben tallhat fggetlen grf utak
maximlis szmt adja meg.
Vissza
68
Vissza
69
ltalnosan hasznlt minimlis tesztelsi cl strukturlis tesztelskor,

hogy a teszthalmaz fedje le a fggetlen utak egy maximlis (tovbbi fggetlen utakkal tovbb mr nem bvthet) halmazt. A 4.9. brn a bejrhat utak halmaza egyben a fggetlen utak egy tovbb mr nem bvthet,
maximlis halmazt is alkotjk.
Ki kell emelni, hogy az ilyen utak halmaza nem egyedi, vagyis egy
grfhoz akr tbb ilyen tulajdonsggal rendelkez t halmazt (s persze
teszthalmazt) tudunk generlni. Sajnos mg az a knnytett llts sem
igaz, hogy az egyes halmazok szmossga megegyezik a CK rtkvel. A
4.10. brn a 4.8. brn megadott FVG-nak a fggetlen utak egy msik,
tovbb mr nem bvthet halmazt adjuk meg, amely azonban csak kt
tbl ll.
1
2
3
4
5
6
7
1
2
3
4
5
6
1
2
3
4
6
7
1
2
3
4
6
1
2
4
5
6
7
1
2
4
5
6
1
2
4
6
7
1
2
4
6
4.10. bra. Fggetlen utak az FVG-ben

4.6.7. CK szmtsa
A CK legnagyobb elnye, hogy az FVG egyszer elemzse alapjn kiszmthat. Hasznljuk a kvetkez jellst:
G: grf,
V(G): CK,
E: lek szma;
N: pontok szma;
P: elgazs utastsok szma.
CK rtkt kt kplet alapjn is meghatrozhatjuk:
V(G)= E-N+2
V(G)=P+1
A msodik kplet csak abban az esetben ad helyes eredmnyt, ha ketts
elgazsok vannak csak az FVG-ben, vagyis csak egy grfpontbl kt kimen l lehet.
Vissza
69
Vissza
70
A 4.8. brn szerepl grf esetn a fenti kpletek:

E=11; N=9; P=3;
V(G)= E-N+2= 11-9+2=4;
V(G)=P+1=3+1=4.
4.6.8. Egyszer strukturlis tesztgenerlsi algoritmus
A ST technikk ltalnos problminak vizsglathoz tekintsnk egy egyszer tesztelsi algoritmust:

1. FVG generlsa a kd alapjn.
2. V(G) (CK) szmtsa az FVG alapjn.
3. Fggetlen utak maximlis (CK darab utat tartalmaz) halmaznak generlsa.
4. Bemenetek generlsa a fggetlen utak bejrshoz.
A tesztgenerls sorn a kvetkez problmk addhatnak:
AZ FVG ciklikus, krt tartalmaz, gy elvben a vgtelen sok t generlhat az adott FVG-hoz.
Nem generlhat olyan bemeneti kombinci, amely egy adott t bejrst eredmnyezn az FVG-ben.
A kvetkez fejezetekben a fenti problmk kezelsvel foglakozunk.
4.6.9. ST ltalnos problmja: Ciklusok tesztelse
A ST mdszerek legnagyobb problmja a ciklusok tesztelse. A programok vezrlsi szerkezetben gyakoriak a ciklus utastsok. Ezek az FVGben krnek felelnek meg. A problma az, hogy minden olyan grf tbl,
melyben van kr ha nem limitljuk a kr bejrsnak szmt elvben
vgtelen tovbbi utat tudok generlni, attl fggen, hogy az adott krt
hnyszor jrom be. Erre mutatunk egy egyszer pldt a 4.11. brn.
1
3
1
2
3
1
2
2
3
1
2
2
2
3
1
2
2
2
2
3
4.11. bra. Egyszer ciklikus FVG s grf utak
Vissza
70
Vissza
71
Ennek a problmnak a kezelsre egyetlen technika ltezik: ciklus bejrsnak limitlsa. Minden FVG krhz nknyesen, vagy a ciklus felttel
alapjn egy egsz szmot rendelek, mely a kr bejrsnak maximlis szma lesz.
Sajnos mg gy is igaz lesz, hogy minden krt tartalmaz thoz annyi
tesztvektort kell generlnom, mint a kr bejrsnak szma plusz egy.
Mg nehezebb a helyzet, ha a ciklus utastsok egymsba gyazdnak.
Ekkor sajnos az utak szma (s ezzel egytt a szksges tesztek szma is)
exponencilisan n a ciklusok szmval.
ltalnossgban igaz, hogy a ciklusok kezelse jelenti a legnagyobb kihvst az sszes strukturlis tesztelsi mdszerrel szemben.
4.7. Tesztminsgi mrszmok
A ST alapossgnak jellemzsre hasznlhatunk mrtkszmokat. Ezek a
mrtkszmok tmpontot adhatnak a tesztels alapossgnak jellemzsre.
Megmutatjk, hogy egy adott szempont szerint mennyire alaposan teszteltk az adott szoftvert.
A mrtkszm egy arnyszm: megmutatja, hogy a kivlasztott szempont szerint a tesztelhet elemek (egysgek, ttelek) mekkora rszt teszteltk le, a terlet terminolgijt hasznlva az adott ttelek mekkora rszt fedtk le.
A mrtkszmok tipikusan strukturlis tesztelshez kapcsoldnak.
Nhny plda a mrtkszmokra:
Utasts lefedettsg: Az utastsok mekkora hnyadt hajtottuk vgre
tesztelskor.
g lefedettsg (dnts lefedettsg): AZ FVG gainak mekkora hnyadt fedtk le (hajtottuk vgre) tesztelskor.
t lefedettsg: AZ FVG-ben tallhat utaknak mekkora hnyadt fedtk le (hajtottuk vgre) tesztelskor.
A tesztels, teszt generls clja minl magasabb, lehetleg 100%-os lefedettsg elrse. A mrtkszmokat ennek megfelelen hasznljk a tesztgenerls sorn az egyes teszthalmazok tesztel kpessgnek sszehasonltsra.
Fontos kiemelni, hogy a mrtkszmok kzelrl sem a lehetsges hibk lefedettsgt, vagyis a konkrt hibk megltnek teszteltsgt mutatjk. Mint emltettk a ST minden mdszere implicit hibamodellt hasznl,
Vissza
71
Vissza
72
nem llt fel explicit hibamodellt, vagyis a teszteket nem egyes konkrt
hibk tesztelse rdekben generlja.
Azt is hozz kell tenni a kp teljessghez, hogy a tesztels minsgnek szmszer jellemzsre ma a fenti mrtkszmoknl jobb eszkz
nincs.
4.7.1. Lefedettsgi elemzs (coverage analisys)
A mrtkszmok tesztels sorn trtn hasznlatnak kln elmlete

alakult ki, az n. lefedettsgi elemzs (coverage analisys). Ennek lnyege,
hogy nagy szoftverek esetn nem mindegy, hogy az egyes teszteket milyen
sorrendben hajtjuk vgre. Akkor hatkony a tesztels, ha a tesztels elejn
azokat a teszteseteket hajtjuk vgre, amelyek viszonylag nagy tlagos hibafeldert kpessggel rendelkeznek, s az egsz szoftvert tesztelik. Nem j
stratgia, ha a nagy szoftverem egyetlen kis rszt igen alaposan tesztelem,
de maradnak egyltaln nem tesztelt rszei. Akkor hatkony a tesztels, ha
a hibk nagy rszt minl hamarabb feldertem, majd a tesztels tovbbi
rszben tallom meg egyre kisebb gyakorisggal a nehezen detektlhat hibkat. Hatkony s alacsony hatkonysg tesztelsre jellemz hibafedst s a szoftverben marad hibk arnynak tesztels sorn trtn
vltozst mutat sematikus brkat lthatunk a 4.12. s 4.13 brn.
hibafeds
hatkony tesztels
alacsony hatkonysg tesztels
tesztelsre fordtott id (erfeszts)
4.12. bra. Hibafeds alakulsa tesztels sorn
Vissza
72
Vissza
73
szoftverben marad hibk
alacsony hatkonysg tesztels
hatkony tesztels
tesztelsre fordtott id (erfeszts)
4.13. bra. Szoftverben marad hibk vltozsa tesztels sorn

A fenti elvnek megfelelen a tesztels elejn clszer egy nem szigor
(nem a legalaposabb tesztelst biztost) mrtkszm alapjn generlt
teszthalmazt hasznlni, vagy nem teljes (100%-os) lefedettsget clul tzni
ki. Ezutn a tesztels ksbbi fzisban az egyre szigorbb mrtkszmokat alkalmazni, ill. egyre szigorbb, egyre magasabb lefedettsgi rtkeket
hasznlni.
4.7.2. Utasts lefedettsg
Az utasts lefedettsg defincija:

S(c)=s/S
Ahol s a tesztels sorn legalbb egyszer vgrehajtott utastsok szma, S
pedig a program sszes utastsnak a szma.
Nem szigor tesztelsi mrtkszm. Vegyk pl. a kvetkez kdrszletet:
int* p = NULL;
if (felttel)
p = &variable;
*p = 12;
A fenti kdrszlet teljesen fedettnek tekintjk az utasts lefedettsg mrtkszm szerint, akkor is, ha nincs olyan teszt, amely hatsra a felttel
hamis rtket vesz fel. Viszont egyrtelm, hogy hibt okoz, ha futs sorn a felttel hamis rtket kap.
Vissza
73
Vissza
74
4.7.3. Dnts lefedettsg (g lefedettsg)
Az dnts lefedettsg defincija:

D(c)=d/D
Ahol d az elgazs utastsokban szerepl felttelek (dntsek) kimenetek
tesztels sorn bekvetkezett rtkeinek szma, D pedig a program sszes
elgazs utastsban szerepl felttelek kimenetnek lehetsges szma. A
dnts lefedettsg teht akkor teljes, ha a programban szerepl sszes
dnts minden lehetsges kimenete elfordult a tesztels sorn.
A dnts lefedettsg alternatv elnevezse az g lefedettsg, ugyan is a
dnts lefedettsget definilhatjuk az FVG alapjn is: A tesztels sorn
legalbb egyszer bejrt FVG gak szma osztva az FVG-ben tallhat
sszes g szmval.
A 100% g lefedettsg mr sokkal alaposabb tesztelst eredmnyez,
azonban nem biztostja az sszetett elgazs felttelek alapos tesztelst.
Vegyk a kvetkez pldt:
if ( felttel1 && ( felttel2 || fggvny1() ) )
utasts1;
else
utasts2;
A fenti kdrszlet teljesen lefedett az g lefedettsg szerint, ha van egy

olyan teszteset, ahol a felttel1==IGAZ, felttel2 ==IGAZ valamint
egy olyan teszteset, ahol felttel1==HAMIS. Ebben az esetben pedig a
fggvny1() egyltaln nem hvdott meg a tesztels sorn, ami trivilisan nem alapos tesztels.
4.7.4. Bool (felttel) lefedettsg
Az Bool (felttel) lefedettsg defincija:

B(c)=b/B
Ahol b az elgazs utastsok feltteleiben szerepl Bool-kifejezsekben a
tesztels sorn tesztelt bemeneti kombincik szma, B pedig az elgazs
utastsok feltteleiben szerepl Bool-kifejezsekben a lehetsges bemeneti kombincik sszes szma. A Bool (felttel) akkor teljes, ha az elgazs
utastsok feltteleiben szerepl Bool vltozk minden lehetsges kombincit felvesznek a tesztels sorn.
Vissza
74
Vissza
75
A Bool lefedettsg alaposabban teszteli az elgazs utastsok feltteleit, azonban rdekes mdon kszthet olyan kd, amely esetn a teljes
Bool lefedettsg nem eredmnyez teljes dnts lefedettsget.
4.7.5. t lefedettsg
Az t lefedettsget az FVG alapjn definiljuk. Az t lefedettsg defincija:

P(c)=p/P
Ahol p az FVG-ben a tesztels sorn bejrt (vgrehajtott) utak szma, P
pedig az FVG sszes t szma. Az t lefedettsg akkor teljes, ha az FVGben tallhat sszes t bejrdott a tesztels sorn.
Az t lefedettsg igen szigor mrtkszm. Teljes t lefedettsg
100%-os utasts lefedettsget s 100%-os g lefedettsget biztost. Nagyon kpletes mrtk, mert a teljes lefedettsg azt jelenti, hogy a programomat minden lehetsges vezrlsi g-kombincija esetn vgrehajtottam, teszteltem.
Az t lefedettsg problmja, hogy az FVG-ben lehetnek nem bejrhat utak, mint azt korbban mr lttuk, s ezek meglte a teszthalmaz generlst megnehezti.
4.8. A mdszerek sszekapcsolsa
Azok a teszttervezsi mdszerek, amelyeket ebben a fejezetben tekintettnk t, egy teljes, sszefgg lncba kombinlhatk ssze. A kombinlsnak az adja az rtelmt, hogy nmagban egyik mdszer sem elegend
arra, hogy alapos, tfog vizsglatot eredmnyezzen. Msrszrl pedig
mindegyik mdszer egy klnllan hasznos tesztcsoportot llt el, amelyek jl kiegsztik egymst.
A clszer stratgia abbl ll, hogy elszr a funkcionlis tesztek sorozatt hajtjuk vgre, azt kveten pedig a strukturlis tesztekt. Termszetesen nincs biztos garancia arra, hogy minden elfordul szoftverhibt fel
tudunk fedni ez ltal, viszont azt tudjuk, hogy szszer kompromisszum
rn jutunk el a vgeredmnyhez.
Vissza
75
Tesztelsi stratgik s folyamatok
Vissza
76
5. Tesztelsi stratgik s folyamatok

Ebben a fejezetben a szoftver rendszerek fejlesztsi folyamatnak az ltalnos menett vzoljuk fel, ehhez kapcsoldan pedig az ellenrzsitesztelsi eljrsok szerept, funkcijt ismertetjk, megmutatva, hogy
azok hogyan illeszkednek be a teljes folyamatba.
A 3. fejezetben mr kifejtettk, hogy a szoftverfejleszts legignyesebb, legpontosabb vgrehajtsra a biztonsgkritikus rendszerek esetben
van szksg. Biztonsgkritikus rendszereket mr rgta hasznlnak, mr a
szmtgpek megjelense eltti idkben is voltak ilyen alkalmazsok, s
mg ma is lteznek. Tipikus pldi ennek a rels vasti biztostberendezsek, amelyek a plyaudvarok forgalmnak az automatizlt vezrlsre
szolglnak. A rels szablyozsok-vezrlsek krben mg mindig mkdnek olyan berendezsek, amelyeknl a biztonsg az elsdleges szempont.
A szmtgpek megjelensvel s elterjedsvel hatalmas mrtkben
ntt meg a teljestmny, viszont szmtalan j gond, problma jelentkezett,
ppen hogy a biztonsg szempontjbl. Hardver tren az integrltsgi fok
minden elkpzelhet hatron tli nvekedse (10-50-100 milli tranzisztor
egy processzor-chipben), szoftver tren az ugyancsak millis nagysgrendben lv utastsszm mind olyan veszlyeket hordoz magban, amelyek a biztonsg rovsra dolgoznak.
A rendszerek teljestmnynek nvekedsvel egytt jrt a bonyolultsg lnyeges nvekedse is. Megntt az emberi eredet tervezsi, javtsi
s zemeltetsi hibk elfordulsnak valsznsge. Az ilyen rendszerek
tervezsnl, zemeltetsnl igen nagy gondot kell fordtani arra, hogy az
emberi kzremkdsbl szrmaz veszlyek mrtkt a minimlisra lehessen cskkenteni. Ennek az a mdja, hogy minl nagyobb teret kell
szentelni az automatizmusoknak, gy minl kevesebb teret hagyni az emberi beavatkozsi lehetsgeknek. A kell optimlis arny megteremtse
tgondolt s alaposan kimvelt tervezsi megoldsokat kvetel.
Felvethet az a krds, hogy mi a klnbsg hardver s szoftver kztt a
biztonsg szempontjbl. Kijelenthetjk, hogy a kt szfra kzl a szoftver az,
amely a legtbb gondot, problmt okozza. A hardvernek hosszabb idre
visszanyl kialakulsi, fejlesztsi, bezemelsi mltja, folyamata van, mint
a szoftvernek. Sokkal tbb technolgiai tapasztalat gylt ssze ezen a tren. Olyan elterjedt megoldsok, alkatelemek, mikroprocesszorok, mem-
Vissza
76
Vissza
77
rik, egyb szabvnyos, kiprblt ptelemek vannak vilgszerte forgalomban, amelyek jl bevltak, amelyeket mindentt hasznlnak. Az elterjedtsgbl addan az esetleges tervezsi hibk is knnyebben napfnyre
kerlnek. J plda erre az Intel-Pentium processzor els kibocstott vltozata, amelyrl egy felhasznl dertette ki, hogy hibsan mkdik. Az illet
egy amerikai matematikus volt, aki kpfeldolgozsi szmtsokat vgzett,
s magas helyrtk lebegpontos mveleteknl tallt bittvesztst. Az
Intel cg szmra ez risi fiask volt. A hiba kijavtsrl, majd a hibs
processzorok becserlsrl, ill. megsemmistsrl szinte azonnal gondoskodtak.
A hardvertechnolgia fejldsvel a versenyben fennmaradt vezet
nyugati s japn cgek olyan magas szintre tudtk mr emelni a fejlesztsi
s gyrtsi minsgbiztostst, hogy ezzel lnyegesen javult az ltaluk kibocstott termkek megbzhatsga s idtllsga.
A szoftver ezzel szemben mindegyik fejlesztsnl egyedi, specilis, az
adott alkalmazshoz lett ltrehozva. Ezeket nem hasznljk fel szles krben, a kereskedelmi forgalomban nem hozzfrhetek. Mindez lnyegesen
cskkenti a biztonsgos mkdsrl szerezhet tapasztalatok lehetsgt,
ezltal a jelentkez hibk kiszrsnek lehetsgt is.
Egy konkrt biztonsgkritikus rendszerrl sszegyjttt tapasztalatok
is llnak rendelkezsnkre. Az USA-beli AT & T Bell telefontrsasg szmtgpes vezrlssel zemelteti az egsz orszgra kiterjed hlzatt. Itt
10-perces lells mr tbb millird dollrban mrhet vesztesget, ill. krt
okozhat. A Bell az ltala zemeltetett rendszerben 1997-ben statisztikai
felmrst vgzett a lellsi idk okaira vonatkozan. Eszerint az egy vre
terjed eredmnyek azt mutattk, hogy 70%-ban szoftverhiba, 20%-ban
tmeneti s idztsi hardver-hiba, tovbb llandsult statikus hardverhiba csak 10%-ban volt a lellsok elidzje. Mindez altmasztja a
szoftver-minsgbiztosts jelentsgt, a fejlesztsi s vizsglati folyamatok minl alaposabb elvgzsnek fontossgt.
5.1. Szoftverfejlesztsi modellek
Amg egy szoftvertermk elkszl, addig tbb fejlesztsi fzison megy
keresztl. Ilyen fzisok lehetnek a kvetkezk: specifikls rendszerterv
elksztse programterv elksztse kdols modulok tesztelse
modulok sszeptse (integrlsa) rendszertesztels.
Minden szoftver rendszerhez egy n. letciklus tartozik. Az letciklus
mindazon tevkenysgek, fzisok sorozata, amelyek a fejleszts elkezds-
Vissza
77
Vissza
78
tl a rendszer hasznlatba vteln keresztl addig tartanak, amg a rendszer mr vgleg hasznlaton kvl kerl. Az letciklus a kvetelmnyek
specifiklsval veszi kezdett. Ennek alapjn megy vgbe a fejlesztsi
folyamat, ami az zembe helyezssel, majd az zemeltetssel s karbantartssal folytatdik, egszen a hasznlaton kvlre kerlsig.
A szoftverek letciklusra nzve tbb modellt dolgoztak ki. A legelterjedtebb modellek: az n. vzess modell, a spirl modell, valamint a V-modell.
Ezeknek a modelleknek az elnevezse az egyms utn kvetkez letciklus-fzisok geometriai elrendezsnek alakja szerint trtnt.
A klnbz modellek a fejlesztsi projektek egyes fontosabb aspektusainak hangslyozsban trnek el egymstl. gy pldul a vzess modell leginkbb a vllalati informcis rendszerekhez alkalmas, a spirl modell pedig az erforrsok elosztsra s a kltsgekre koncentrl. A Vmodell a biztonsgi kvetelmnyek teljestshez alkalmazkodik. Mindegyik techniknak megvan a maga elnye s htrnya. Ezeknek a modelleknek az elemzsvel s sszehasonltsval ebben a knyvben nem foglalkozunk.
A modellek legfontosabb kzs vonsa az, hogy mindegyikk egy j
minsgbiztostsi-fejlesztsi paradigma sajtsgait hordozza magban. Ez
a paradigma abban tr el az elz paradigmtl, hogy nem a fejleszts
lefolytatsa utn ksrli meg a termk elrsok szerinti kialaktst, hanem
a fejlesztsi folyamat minden egyes fzisban gondoskodik az ahhoz a
fzishoz elrt felttelek betartsrl. A szakirodalomban szerepl szemlltet plda a kvfzsbl van kivlasztva. A rgi metdus szerint megfztk a kvt, s a benne maradt kvport megprbltk eltvoltani, amenynyire csak lehetett. Az j metdus szerint a fzs sorn a kv tbb szrsi
procedrn megy keresztl, s az utols fzist kveten mr gyakorlatilag
nem tartalmaz kvport.
A vzess modell fbb fzisai:
Rendszerkvetelmnyek megadsa.
Szoftver-kvetelmnyek megadsa.
Elzetes programtervek elksztse, elemzse.
Programtervezs.
Programkdols.
Tesztels.
Mkdtets.
Vissza
78
Vissza
79
A spirl modell fbb fzisai a kvetkezk:
A mkdsi koncepci kialaktsa.

Kvetelmnyek tervezse.
letciklus tervezse.
Kockzat-analzis.
Szoftver-kvetelmnyek meghatrozsa.
Szoftver-termk tervezse.
A tervezs verifiklsa s validlsa.
Integrls s tesztels tervezse.
Rszletes tervezs.
Kdols.
Egysgek (modulok) tesztelse.
sszeintegrls s tesztels.
Elfogadsi tesztels.
zembe helyezs.
A biztonsgkritikus szmtgprendszerek esetben a V-modell hasznlata

terjedt el. Ugyanis ez illeszkedik legjobban ehhez az informatikai tpushoz.
Egy tipikus letciklus-modellt mutatunk be az 5.1. brn, ahol az egyes
fzisok V alak elrendezsben kvetik egymst. Az egyes elemek sorrendje
egyben a munkafzisok sorrendjt is tkrzi. A modell jl kifejezi a tervezsi folyamat fentrl lefel trtn haladst (top-down megkzelts) a diagram baloldali gban, mg a tesztelsi folyamat lentrl felfel halad (bottomup megkzelts) a jobboldali gban. Az ilyen brzols csak megkzeltleg
rja le a fejlesztst. A gyakorlatban a klnbz fzisok nem szigoran a
megadott sorrendben hajtdnak vgre. A tervezs gyakran nagy szm
itercit foglal magban, olyan mveletek sorval, amelyeket addig kell
ismtelni, amg kielgt eredmnyre nem jutunk. Prhuzamossgok
ugyancsak lehetsgesek. Msrszrl az 5.1. bra mg nem tnteti fel az
egyes llapotok kztt informciramlst. A kvetkezkben rszletesebben fogunk vgigmenni az bra V-modelljn, magnak a modellnek a
szksg szerinti rszletezsvel, finomtsval egytt. Ebben a trgyalsban a teljes informatikai rendszer tervezst is rintjk, amennyiben kitrnk a hardvertervezsre is, olyan mrtkben, ahogyan az a szoftverre
kihatssal br.
Vissza
79
Kvetelmnyek
specifiklsa
1.
2.
Rendszervalidls
Architektratervezs
5.
80
Modultervezs
6.
Rendszerverifikls
Rendszer
integrlsa s
tesztelse
11.
10.
Bizonylatols
Specifikls
4.
Rendszer
zemeltetse
Hazrd- s
kozkzatanalzis
3.
Vissza
9.
8.
7.
Modulok
ellltsa s
tesztelse
5.1. bra. Az letciklus V-modellje

Egy rendszer fejlesztsi letciklusnak llomsai
Az 5.1. bra blokkjainak szmozst kvetve, az albbi magyarzatok tartoznak az egyes blokkokhoz:
1. Kvetelmnyek specifiklsa: Minden fejlesztsi folyamat kiindulsi
pontjt a rendszerre vonatkoz kvetelmnyek kpezik. Ennek megjelensi formja: Funkcionlis kvetelmnyek dokumentcija. A doku-
Vissza
80
Vissza
81
mentci azt rja le, hogy milyen funkcikat s milyen mdon kell a
rendszernek teljesteni. Pldul a Magyar llami Vast (MV) n. felttfzetben rja el a vasti biztostberendezsek funkciit.
2. Hazrdok s kockzatok elemzse: Clja: a lehetsges veszlyhelyzetek meghatrozsa a rendszerben, a megelz kiszrs rdekben.
Hazrd: Olyan helyzet, amely egy valsgos vagy lehetsges veszlyt
jelent az emberek vagy a krnyezet szmra.
Kockzat: Egy hazrdhoz kapcsold esemnyek s azok kvetkezmnyei, valsznsgi alapon. Azt fejezi ki, hogy milyen valsznsg
veszlyes kvetkezmnyei lehetnek egy hazrdnak.
Az analzisek elvgzshez klnfle mdszerek llnak rendelkezsre.
A hazrdanalzisre az albbiak hasznlatosak:
Hibamdok s hatsuk analzise: Ebben az eljrsban komponenshibkat tteleznk fel kln-kln, s azt vizsgljuk, hogy a
hibknak milyen hatsuk lehet a rendszer biztonsgra. Ez gy trtnik, hogy vgigkvetjk a hiba hatst a teljes mkdsen keresztl. Ha ezt szmtgpes modellen vgezzk, akkor hibaszimulcirl beszlnk. Ilyenkor egy hibamodellez szoftver felhasznlsval szimulljuk a mkdst. A felttelezett hibk lehetnek kisebb
rszegysgben, nagyobb modulban stb., a modellez programtl
fggen. A modellezs trtnhet hardver-elem szinten, vagy pedig
funkcionlis szinten is, a teljes mkds lejtszsval, ahol a hardvert s szoftvert egytt, egszben vve kezeljk.
Esemnyfa-analzis (event-tree analysis): Ennek az elve hasonlt a hibahatsok analzishez. Itt egy-egy olyan esemnyt tteleznk fel, amely hatssal lehet a rendszer mkdsre. Az analzis
sorn ennek a hatst kvetjk vgig. Nemcsak a lehetsges hibs
esemnyeket vesszk kiindulsul, hanem a norml mdon betervezett esemnyeket is. Ennek az az oka, hogy a norml esemnyekbl
is addhat katasztrfa, a hibs tervezs folytn. Az esemnyfa egy
fa tpus irnytott grf, amelynek gykere a kiindulsi esemny, ezt
kveten pedig annak hatsai szerint gazik szt a klnbz szinteken, egszen a lehetsges vgs kimenetelekig (a fa leveleiig). Ha
egy vgs kimenetel veszlyt jelent, akkor gondoskodni kell annak
megszntetsrl, a tervezsbe val visszanylssal, vagy pedig a
rendszer mkdtetsre vonatkozan kell olyan elrsokat lefektetni, amelyek kizrjk a vszhelyzet fellpst.
Vissza
81
Vissza
82
Hibafa-analzis (fault-tree analysis): Ez a megolds is egy fa tpus irnytott grf kiptsn alapul. A kiinduls viszont itt teljesen fordtott, ennek megfelelen a grfon trtn halads irnya is
fordtott, az irnytssal ellenttes. Kiindulsknt egy vszhelyzetet
tteleznk fel, s azt hatrozzuk meg szintrl szintre visszafel haladva, hogy mik lehetnek elidzi az adott vszhelyzetnek. A grf
egy-egy cscsa logikai Boole-opertort kpvisel: S, VAGY, ill.
NEM mveletet. Ez azrt van gy, mert a kiindulsi helyzetet elidz lehetsges okok meghatrozsakor az okok egyttes (S),
kln-kln (VAGY), ill. tagad (NEM) ltezst kell megllaptanunk. Ha egy vszhelyzetrl kiderl, hogy semmikppen nem kvetkezhet be, akkor nincs szksg a mdostsra. Ha viszont tallunk legalbb egy okot, amitl bekvetkezhet, akkor a terv talaktsa vlik szksgess.
A kockzatok elemzsre valsznsg-szmtsi segdeszkzket
hasznlnak fel, aminek eredmnyeknt szmszer rtkeket rendelnek
az egyes veszlyes kvetkezmnyekhez.
Az elemzsi folyamatok eredmnyeknt ltrehozand a biztonsgi
kvetelmnyek dokumentcija. Ez a dokumentum arra ad elrst, hogy
mit kell betartani a rendszernl, mit szabad, ill. mit nem szabad megengedni a rendszer mkdse sorn.
3. A teljes rendszerspecifikci: A funkcionlis kvetelmnyek valamint a biztonsgi kvetelmnyek egyttese alkotja. Mindezen specifikci alapjn megkezdhet a teljes rendszer konkrt tervezsi folyamata.
4. Architekturlis tervezs: A teljes informatikai rendszer architektrja
hardverbl s szoftverbl tevdik ssze. A tervezsnek ebben a fzisban azt kell eldnteni, hogy mely funkcik legyenek megvalstva
hardver, s melyek szoftver ltal. Az ltalnos mkds szempontjbl
ez a tervezsi fzis dnt szerepet jtszik. A kt informatikai szfra
kztti megoszts egyarnt kihatssal van a sebessgre, a megbzhatsgra, a teljestmnyre, valamint a biztonsgossgra. A vastirnyt
szmtgpek pldul tipikus vals idej rendszerek, amelyeknl mindegyik reakciidnek igazodni kell a forgalmi esemnyek idtartamaihoz. Megjegyzend mg, hogy ma mr egyre inkbb terjedben van a
hardver-szoftver egyttes tervezsnek kivitelezse, angolul az n.
HW-SW co-design. Ebben a megkzeltsben a tervezsi folyamatnak
csak egy ksbbi szakaszban dl el a HW-SW-megoszts, addig a tervezs azonos elveken, azonos eszkzkkel halad elre.
Vissza
82
Vissza
83
A tervezs eredmnyeknt ltrejnnek a hardver s a szoftver rendszertervei, tervdokumentcik formjban. Ezek alapjn mind a hardvert, mind
pedig a szoftvert hierarchikusan fentrl lefel haladva (top-down) tervezik meg. A kvetkezkben az letciklusnak a szoftver vonalra fogjuk a hangslyt helyezni, a hardverrel csak rintlegesen foglalkozunk.
5. A szoftver modulokra bontsa: Clja a tervezsi folyamat egyszerstse, ttekinthetbb ttele, a fejlesztsi feladatok rszekre val sztosztsa. A tervezs eredmnyeknt a szoftver modulok specifikcija,
valamint a kztk lev interfszek, ill. kapcsoldsi folyamatok terve
kszl el.
6. A modulok elksztse s tesztelse: Ebben a szakaszban trtnik
meg az egyes modulok forrsnyelvi kdjnak megrsa, a modulok
egyenknti lefordtsa, a nyomkvetses fejleszti belvse, ezt kveten pedig az elkszlt modulok nll tesztelse. A tesztelsi folyamatok elzetesen megtervezendk. A tesztels mr integrns rsze a
szoftver verifikcis folyamatnak, amelyben azt dntjk el, hogy egyegy modul megfelel-e a specifikcijnak. Ehhez az inputot a modulok
terve szolgltatja.
7. A szoftver-modulok sszeintegrlsa: Miutn mindegyik modul
tment a tesztelsen, a teljes rendszer sszeintegrlsra kerl sor. A
gyakorlatban ktfle megkzelts terjedt el erre vonatkozan:
a) Integrls egyenknti bvtssel s tesztelssel: Inkrementlis tesztels.
Ekkor egy kiindulsi, minimlis szm modulhoz egyms utn illesztjk a bvtsknt szolgl modulokat. Minden egyes bvts
utn kln teszteljk az addig sszellt komplexumot. A megolds
elnye az, hogy az jabb hibk egy-egy bvts sorn lphetnek be
nagy valsznsggel, s gy knnyebb felfedni ket a bonyolultsg
lpcszetes nvekedsvel.
b) A msik megkzeltsben az sszes modult egyszerre rakjuk ssze,
s a teljes komplexumra hajtjuk vgre a tesztelst. Ez a megolds
azon a feltevsen alapul, hogy az elzetesen kitesztelt modulok mr
nagy valsznsggel egytt is helyesen fognak mkdni. A lert
megkzelts az n. big bang tesztels (testing). Az elnevezs arra
utal, hogy szmtanunk kell az els indtst kvet sszeomlsra.
(Big bang: nagy csattans.) Ekkor a hibk megtallsa viszonylag
nehezebb lesz a feladat bonyolultsga miatt.
Ennek a folyamatnak a vgrehajtshoz a bemen ionformcit a modulok terve, s a teljes rendszer terve kpviselik.
Vissza
83
Vissza
Kvetelmnyek
elemzse
84
zemeltets/
Karbantarts
Bizonylatolt
rendszer
Kvetelmnyek
dokumentcija
Rendszerspecifikls
Validls/
Bizonylatols
Rendszerspecifikci
Verifiklt
rendszer
Fels szint
tervezs
Rendszer
tesztelse
Rendszer
terve
sszeintegrlt
rendszer
Rszletes
tervezs
Rendszer
sszeintegrlsa
Modulok
terve
Tesztelt
modulok
Konstrukcis
tervezs
Kdols
Modulok
tesztelse
Modulok
5.2. bra. V-modell a tevkenysgek eredmnyeivel
Vissza
84
Vissza
85
8. A teljes rendszer verifiklsa: Ebben a fzisban eldntend, hogy a

teljes rendszer megfelel-e a specifikcijnak, vagyis funkcionlisan teljesti-e az sszes specifikcis pontot. Az ehhez felhasznland input:
A rendszer terve, valamint a teljes rendszer-specifikci.
9. A teljes rendszer validlsa: Azt dntend el, hogy a teljes rendszer
megfelel-e a felhasznli kvetelmnyeknek. Ebbe beletartozik a biztonsgi felttelek teljestsnek eldntse is: az n. biztonsgigazols. (Ez az elrt funkcik ellenrzsn tli ellenrzst kvetel meg.) Input: A rendszerkvetelmnyek dokumentcija, s a teljes rendszer-specifikci.
10. Bizonylatols (certification): A hatsgi elrsok s szabvnyok
szerinti megfelels eldntse, s az erre vonatkoz bizonylatok killtsa. Input: A rendszer-kvetelmnyek dokumentcija, s a teljes rendszer-specifikci.
11. zembe helyezs, zemeltets, karbantarts, elavuls, zemeltets megszntetse: Input: A biztonsgi kvetelmnyek dokumentcija.
A fentiekben felvzolt V-modell rszletesebb megjelentse az 5.2. brn
lthat. Az bra szgletes blokkjai az egyes fzisok tevkenysgt tartalmazzk, a kerektett sark blokkok a kimenti eredmnyeket kpviselik, a
folyamatos nyl az informci elsdleges ramlst, a szaggatott nyl pedig
a msodlagos informciramlst jelzi.
5.2. Verifikci s validci
A szoftverfejlesztsben alapvet kvetelmny a fejlesztsi folyamat mindvgig helyes, kvetkezetes vgrehajtsa. A fejleszts egyes stdiumaihoz
egymstl eltr megvalstsi reprezentcik tartoznak. A helyes vgrehajts deklarlsa azt kvnja meg, hogy bizonytsuk ezen reprezentcik
kztti egyrtelm sszhang teljeslst. Ekkor valjban azt kell bizonytanunk, hogy a vgeredmnyknt kiadd szoftver-termk 100%-ig megfelel a kiindulsi specifikcinak. A bizonytsi folyamat elvgzse gy
logikus, hogy az egymst kvet fejlesztsi fzisok kztti sszhang, ekvivalencia igazolst vgezzk el lpsenknt. Ha eltrs addik, akkor az
ppen vizsglt fzist addig kell mdostani, amg sszhangba nem kerl az
t megelz fzissal. A teljes folyamatot az 5.3. brn szemlltetjk.
Vissza
85
Vissza
86
Szoftver specifikci
1. tervezsi fzis
Mdosts
Nem
1. fzis megfelel
Igen
2. tervezsi fzis
Mdosts
Nem
2. fzis megfelel
Igen
Mdosts
Nem
Utols fzis megfelel

Igen
Szoftver-vgtermk
5.3. bra. A fejlesztsi fzisok kapcsolata

Az egymst kvet fejlesztsi fzisok kztti sszhang, ekvivalencia ellenrzsi folyamatt nevezzk verifikcinak. Pontosabb defincival ezt a
kvetkez mdon fogalmazhatjuk meg:
Verifikci: Az a folyamat, amelyben meghatrozzuk, hogy a vizsglt
informatikai rendszer szoftvere teljesti-e mindazokat a kvetelmnyeket,
amelyeket egy elz fzisban specifikltak a szoftver fejlesztsi vagy ellltsi folyamatban
Vissza
86
Vissza
87
Ezen a ponton azonban meg kell llaptanunk, hogy a biztonsgkritikus

szoftverek fejlesztse sorn a verifikcis folyamat tkletes vgrehajtsa
nem garantlja a vgtermk tkletes felhasznlhatsgt. Amit a verifiklssal garantlni lehet, az a kiindulsi specifikcival val ekvivalencia teljeslse. Abban az esetben viszont, ha a specifiklsban trtnt hinyossg
vagy tveds, a vgtermk nem fog minden tekintetben megfelelni a felhasznlsi kvetelmnyeknek. Szksg van teht arra is, hogy vizsglat al
vessk a szoftver-vgtermket abbl a szempontbl, hogy megfelel-e a
valdi rendeltetsnek. Erre nzve kln vizsglati eljrsra van szksg,
amit validcinak neveznk. Ennek defincija a kvetkez:
Validci: A teljes szoftver vizsglata s kirtkelse azzal a cllal, hogy
meghatrozzuk, minden szempontbl megfelel-e a felhasznli kvetelmnyeknek.
Egy biztonsgkritikus rendszernl a kvetkezket kell igazolni:
A funkcionlis megfelelsget.
A teljestmnyben val megfelelsget.
A biztonsgi kvetelmnyek teljeslst.
A validcis eljrsban teht kln kell azt vizsglni, hogy a teljes rendszer
biztonsgos-e. Az erre szolgl tesztelsben a legklnflbb helyzeteknek
kell kitenni a vizsglt rendszert, azzal a cllal, hogy annak a biztonsgot
nem veszlyeztet mkdsrl gyzdhessnk meg. Ennek a folyamatnak lehet olyan eredmnye, amely specifikcis hinyossgokra utal. Ilyenkor vissza kell trni a kiindulsi specifikcihoz, azt a szksg szerint mdostani, majd a mdostsokat az sszes fejlesztsi fzison keresztl lpsenknt vgigvezetni, a velejr verifikcis eljrsokkal egyetemben. Termszetesen megismtlend a vgs validls is.
Magtl rtetdik, hogy a fenti eljrs nem valsthat meg zemi krlmnyek kztt, mgpedig biztonsgi okokbl. A megolds az, hogy a
teljes szoftver rendszer szmra egy szmtgpen szimullt krnyezetet
hoznak ltre, amelynek keretn bell a tesztelsi-validlsi folyamatot el
lehet vgezni.
A verifikci s a validci a fejlesztsi folyamat kt sszefgg velejrja, a kt eljrs mindig egytt kezelend. Szoks ezeket gy V & V
eljrsnak is rvidteni.
Vissza
87
Vissza
88
Ha sszehasonltst tesznk a kt megkzelts kztt, akkor a kvetkez tmr megklnbztetst tudjuk tenni:
A verifikci vgs soron arra ad vlaszt, hogy a termk ellltsa helyesen trtnt-e.
A validci arra ad vlaszt, hogy a helyes termket lltottuk-e el.
A fentiekhez mg a kvetkez fontos megjegyzst fzzk:
Nem minden szoftverfejleszts kveteli meg a V & V eljrs vgrehajtst. Az olyan esetekben, amikor teljes bizonyossggal kijelenthet, hogy
a kiindulsi specifikciban nincsen semmilyen hinyossg, nincs szksg
a validlsra. Ekkor elegend a specifikcival val sszhangot bizonytani, vagyis egyedl csak verifiklni. Ilyen eset lehet pldul egy jl definilt
algoritmust vagy szmtsi eljrst megvalst szoftver elksztse, ami
akr egy igen nagy, sszetett rendszert is adhat eredmnyl. A biztonsgkritikus rendszerek azonban nem ebbe a kategriba esnek, itt mindig
szksg van mind a kt V-re.
5.3. A verifikci s a validci fzisainak
tervezse
Amikor egy biztonsgkritikus rendszer tervezse trtnik, a teljes rfordtsnak igen jelents rszt kpezi a verifikcinak s a validcinak a megtervezse. Kvetkezskppen az elre val tervezs lnyeges mind a kltsgek becslse, mind pedig minimalizlsa szempontjbl. Mivel a verifikls s a validls egyarnt a tesztelsen alapul, a tesztek megtervezse
igen fontos rsze lesz a fejlesztsi folyamatnak. A tervezs egyik terlete a
szoftveregysgek, vagyis a modulok ellenrzse, a msik pedig a modulok
sszeintegrlsnak ellenrzse. A teljes rendszer validlsa a rendszerfejleszts utols fzisai kz tartozik, viszont ennek a tevkenysgnek a megtervezse mr egy korai szakaszban meg kell hogy trtnjk. Ennek az a
legfbb indoka, hogy a validcis terv befolysolni tudja magnak a projektnek a tovbbi menett. A validcis szempontoknak a figyelembe vtele a tervezs egy korai szakaszban jelents megtakartshoz vezethet a
ksbbi szakaszok rfordtsban.
Az 5.3. bra szerinti folyamatot tekintve lthat, hogy a projekt korai
fzisai informcis kapcsolatban vannak a ksbbi fzisokkal, amit a szaggatott vonalak fejeznek ki. A diagram jobboldali ga a megvalstsi, ill. a
tesztelsi tevkenysgeket kpviseli. Amint a rendszer az egyes modulok-
Vissza
88
Vissza
89
bl teljes egssz kezd sszeplni, gy kell az ptsi llapotokat sszevetni a nekik megfelel tervezsi llapotokkal. gy pldul egy adott modul
megvalstst a modul tervvel sszehasonltva kell tesztelni, mg a teljes
rendszert a rendszer specifikcija alapjn teszteljk. Az erre vonatkoz
teszttervezsi tevkenysget be lehet iktatni a V-diagramba, amint azt az
5.4. bra mutatja. Az brbl vilgosan kitnik, hogy a baloldali g minden
egyes fzisnak egy jabb fzisba val transzformcijhoz meg kell tervezni a transzformci helyes vgrehajtsnak verifiklst.
A rendszer validlsa megkveteli, hogy a rendszer sszes szempontjt, tovbb az sszes mkdsi mdjt tekintetbe vegyk. Ez tbbek kztt azt jelenti, hogy a klnbz technolgikon alapul biztonsgi mechanizmusokat is vizsglni kell, mint pldul a hardvert, vagy a mechanikus, esetleg hidraulikus rszeket, s az ezekhez kapcsold kls kockzatcskkent megoldsokat. Mieltt egy rendszert megvalstannak, vgs validlst meg kell tervezni, az sszes olyan tnyez figyelembevtelvel, amelyek a biztonsgot befolysoljk.
Az IEC 1508 szabvnytervezet 1995-s vltozata megad egy kvetelmnylistt az ltalnos validcis tervekre vonatkozan. (IEC: International Electrotechnical Commission, Nemzetkzi Elektrotechnikai Bizottsg). A kvetelmnylistt az albbiakban ismertetjk:
a) Annak lersa, hogy a validls mikor hajtand vgre.
b) Annak megadsa, hogy ki hajtja vgre a validlst.
c) A rendszermkds figyelembe veend mdjainak megadsa, az albbiak szerint:
A hasznlat elksztse
Indts
Automatikus zemeltets
Manulis zemeltets
Flautomatikus zemeltets
llandsult llapotbeli mkds
jrallts (reset-els)
Teljes lellts
Karbantarts
Elrelthat abnormlis felttelek kezelse
d) A biztonsgra kihat rendszerek megadsa, s azon kls kockzatcskkent eszkzk megadsa, amelyeket validlni kell mindegyik mkdsi mdban.
Vissza
89
Vissza
Kvetelmnyek
elemzse
90
zemeltets/
Karbantarts
Kvetelmnyek
dokumentcija
Bizonylatolt
rendszer
Teszttervezs
Rendszerspecifikls
Validls/
Bizonylatols
Rendszerspecifikci
Verifiklt
rendszer
Teszttervezs
Fels szint
tervezs
Rendszer
tesztelse
Rendszer
terve
Teszttervezs
Rszletes
tervezs
Modulok
terve
sszeintegrlt
rendszer
Rendszer
sszeintegrlsa
Teszttervezs
Konstrukcis
tervezs
Kdols
Tesztelt
modulok
Modulok
tesztelse
Modulok
5.4. bra. Az letciklus V-modellje a teszttervezssel
Vissza
90
Vissza
91
e) A validls technikai stratgija.

f) Intzkedsek, technikk, eljrsok, amelyek arra hasznlandk, hogy
mindegyik biztonsgi funkcirl el legyen dntve, hogy az megfelel-e
az ltalnos biztonsgi kvetelmnyeknek.
g) Hivatkozsok az ltalnos biztonsgi kvetelmnyek dokumentumaira.
h) A szksges krnyezet, amelyben a validls tevkenysget el kell vgezni.
i) Az elfogadsi/elutastsi kritriumok.
j) Irnyelvek s szablyok a validcis eredmnyek kirtkelsre vonatkozan.
A kvetkez alpontokban a tesztelsi folyamatok klnbz fzisainak
rszletesebb ismertetsvel foglalkozunk, modul szinttl kezdve, a rendszer szintig bezran.
5.4. Egysgek, modulok tesztelse
A legtbb programozsi nyelv lehetv teszi a programkd kisebb- nagyobb darabokban trtn ellltst (fggvnyek, szubrutinok). Ezt az
egyre bonyolultabb vl alkalmazsok strukturlt fejlesztse is motivlta.
A modulris fejleszts lehetv teszi a modulris vagy egysgenknti tesztelst. Az egysgtesztels egy tesztelsi szintet kpvisel, megjelenhet a
szoftver-letciklus tesztelsi fzisnak elemeknt vagy a kdolssal szorosan sszekapcsoldva. Mint tesztelsi szint kapcsoldik mind a klnbz
magas szint tesztelsi stratgikhoz (megkzeltsmdokhoz) s mind
bizonyos tesztelsi technikkhoz (konkrt eljrsok) is. Elbbiek meghatrozzk az egysgtesztels kereteit (ltalnos tesztelsi stratgia), formjt
s hatkonysgt (a szinthez kapcsold stratgia) s az utbbiak kivlasztst (a szinthez kapcsold stratgia megkvnta technikk). Az egysgtesztels jrszt white-box jelleg strukturlis tesztelsi keretbe illeszkedik.
Ezt az indokolja, hogy a nagy mret programok strukturlis tesztelse
bonyolult, illetve a funkcionlis tesztek a mr integrlt rendszer specifikcijra plnek. A white-box jelleg segti a tesztelst a fejlesztsi fzisban.
Ez a keret meghatrozza az alkalmazott mdszereket s technikkat s a
tesztels rtkelshez vlasztott kritriumokat. Termszetesen a modulok
tesztelsnl is alkalmazandk black-box mdszerek a specifikcinak
val megfelels tesztelsre. Az egysgtesztels tipikus teszteset tervezsi
eljrsa a kvetkez: a modul szerkezetnek elemzse white-box mdsze-
Vissza
91
Vissza
92
rekkel, majd az gy ellltott tesztesetek kiegsztse a specifikci tesztelsre szolgl black-box mdszerekkel ellltott tesztesetekkel.
Az egysg- vagy modultesztek jelentik a szoftverfejleszts kzbeni legalacsonyabb szint tesztelst. Ilyenkor a szoftver egyes nll egysgeinek
tesztjt a program tbbi rsztl elszigetelten vgzik. A modultesztek teht lehetv teszik, hogy a programot ne csak teljes egszben az elkszlte
utn teszteljk, hanem a tesztelst mr kisebb ptelemeinek elkszlte
utn is elvgezhessk. A modultesztelst magt a tesztelsi fzis vgrehajtsa is motivlta. Egyrszt lehetv teszi a tesztelsi folyamat komplexitsnak kezelst (kisebb modulok tesztelsre kell csak sszpontostani),
msrszt megknnyti a felfedezett hibs mkds oknak s a hibk helynek pontosabb azonostst, s vgl lehetsget ad a tesztels prhuzamostsra tbb modul egyidej tesztelsvel. Az gy ltrehozott tesztesetek nem csak egyszer hasznlatosak a fejleszts sorn a hibamentes kdols ellenrzsre, hanem mindannyiszor vgre kell hajtani ket, ahnyszor a szoftveren vltoztatst vgznk vagy a modult egy j, msik krnyezetben hasznljuk fel (regresszis tesztels).
A modultesztek sorn teszteljk az adott modul s a modult a rendszerhez csatol interfsz funkcionlis mkdst. A modul tesztelse egy
tesztkrnyezetben trtnik, mely lehetv teszi a tesztesetek ellenrztt
vgrehajtst. A modul a tesztkrnyezettel kombinlva alkot egy mkd
rendszert. Ennek a rendszernek a szerkezett, kialaktst, erforrs ignyt a kvetett modultesztelsi stratgia hatrozza meg. Ktfle megkzeltsmd kpzelhet el: az egyik esetben a modulok egymstl teljesen
fggetlenl kerlnek tesztelsre (izolcis tesztels), illetve a tesztelend
modul mr korbban tesztelt modulokkal kombinlva kerl tesztelsre
(inkrementlis tesztels). A tesztkrnyezetek egy tesztvgrehajt egysgbl
s egy kiegszt rszbl llnak. A tesztvgrehajt egysg a tesztesetek
elvgzst biztostja a megfelel input paramterek belltsval, a tesztelend modul vgrehajtsval s a kimen paramterek kiolvassval. A
kiegszt rsz a modul eredeti krnyezett helyettesti a teszt sorn n.
csonkokkal, melyek a tesztels alatt ll modulbl a krnyezetbe irnyul
hvsokat kezelik le s szolgltatnak visszatrsi rtkeket.
5.4.1. A modultesztels szksgessge s elnyei
A gyakorlatban a jl tervezett egysgtesztek ugyanannyi erfeszts rn

hozhatk ltre mint az adott egysg program kdja. Az egysgtesztek elvgzse a hibk nagy rszt feltrja s a javtsok utn a fejlesztk egy
Vissza
92
Vissza
93
sokkal hatkonyabb integrcis fzisba kezdhetnek, tudva azt, hogy megbzhat komponensekkel dolgoznak. A jl megvalstott egysgtesztels
teht jobb id kihasznlst biztost.
A modultesztels nem csak azt bizonythatja, hogy a kd azt teszi, amit
kdoltak. Ehhez azonban az szksges, hogy a kdot a specifikcijnak
tkrben teszteljk. gy nem csak tbb kdolsi hibt, de specifikcibeli
hibkat is felderthetnk. Amennyiben egy specifikci nlkli modult kell
tesztelni, akkor a kd visszafejtsvel egy vzlat specifikcit kell ltrehozni a modul felttelezett mkdsre vonatkozan.
Az integrcis, vagyis az alkalmazst egszben tekint tesztek nem
alkalmasak a hibk jrsznek feldertsre. Az ok az, hogy a nagyobb kd
integrcik sokkal komplexebbek. Amennyiben a szoftvert alkot modulok nem estek t egysgtesztelsen mr maga a szoftver futsnak elrse,
tesztesetek vgrehajtsa nlkl, sem kis feladat. Az integrcis tesztels
sorn nagyon nehz lehet olyan helyzetek teremtse, hogy egy bizonyos
egysg vgrehajtsra kerljn s radsul kimerten tesztelve legyen, vagyis az egysgszint alapos tesztels elrse integrcis tesztels kzben
sokkal komplexebb feladat, mint az egyes egysgek elszigetelt tesztelsnl. Ennek a kvetkezmnye pedig az lesz, hogy a szoftver bizonyos rszei
nem kerlnek tesztelsre s feldertetlen hibk maradnak a benne.
Alkalmazs
Potencilis
hibk
Modulok
Teszt input
5.5. bra. Az egysgszint hibk feldertse

integrcis tesztels kzben nehz
Vissza
93
Vissza
94
Teszt input
Modul
Potencilis
hibk
5.6. bra. Az egysgtesztels jobb lefedettsget eredmnyez.

A szoftver minsgnek biztostsa gyakorlatilag az letciklus minl korbbi szakaszban vgrehajtott tesztelssel lehetsges. Minl ksbb kerl
feldertsre egy hiba, annl magasabb a javtsi kltsge. Az egysgtesztek
ltrehozsa, karbantartsa sokkal knnyebb s knyelmesebb mint a ksbbi fzisokban vgrehajtott tesztek.
5.7. bra. Klnbz tpus tesztek

egymshoz viszonytott relatv idignye
A kvetkezkben az egysgtesztels hrom alapvet szervezsi megkzeltse, s az egyes stratgik elnyeinek s htrnyainak lersa kvetkezik. A
hrom stratgia sszehasonltshoz egy egyszer, az brn lthat modulhierarchit fogunk hasznlni.
Vissza
94
Vissza
95
5.8. bra. Modul hierarchia plda

Az bra a hierarchia szintjeit mutatja: hogyan fggenek a felsbb szinteken
lv egysgek az alsbb szinteken lvktl (hvsi hierarchia).
5.4.2. Izolcis tesztels
Az izolcis tesztels sorn a tesztels alatt ll modul az ltala hvott s

az t hv moduloktl elszigetelten kerl tesztelsre. Az egysgek tetszleges sorrendben tesztelhetk, mivel egyik egysg tesztelse sem kvnja
meg ms modulok teszteltsgt. Minden egyes modulhoz szksg van egy
tesztvgrehajt komponensre s az sszes ltala hvott egysgeket helyettest csonkokra.
A
Te szt
h jt
D
Te szte l s
l tt
E
Cso nk
F
Cso nk
G
Cso nk
5.9. bra. Izolcis modul tesztels

Amennyiben a tesztelend egysg a D, akkor az brn lthat tesztvgrehajt egysgre s csonkokra van szksg. A teljes program (hierarchia)
egysgtesztelse egy lpsbl ll, a tesztek sorrendje rdektelen s a tesztek
akr prhuzamosan is vgezhetk. A tesztels egyetlen lpse azt jelenti,
hogy az sszes egysghez el kell kszteni egy tesztvgrehajt komponenst
Vissza
95
Vissza
96
s ha fgg ms egysgektl, akkor az azokat helyettest csonkokat is,

majd el kell vgezni a tesztelst.
Az izolcis tesztels elnyei
Knnyebb egy elszigetelt egysg alapos, kimert tesztelse, amikor is az
egysgtesztels mentes a tbbi egysggel val kapcsolat okozta komplexitstl. Az izolcis tesztels biztostja a legknnyebb utat a megfelel
strukturlis tesztlefedettsg elrshez, s ennek a lefedettsgnek az elrsi
nehzsge nem fgg az adott egysg hierarchiabeli helytl. Mivel egy
tesztben csak egy egysg kerl tesztelsre, a tesztvgrehajt egysgek egyszerbbek mint a bottom-up tesztelsnl, ugyanakkor a csonkok ltalban
egyszerbbek a top-down tesztelshez szksges csonkoknl. Izolcis
egysgtesztelsnl az egysgtesztek nem fggnek egymstl, gy az egysgtesztelsi fzis tfedheti a szoftver letciklus rszletes tervezsi s kdolsi
fzist. Tetszleges szm egysg tesztelhet prhuzamosan, ami rvid
egysgtesztelsi fzist eredmnyezhet, ez pedig lehetv teszi a szoftverfejleszts sszidejnek cskkentst. Tovbbi elnye az egysgek hierarchibl val eltvoltsnak, hogy az egy egysgen vgrehajtott mdostsok csak az adott egysg tesztjnek a vltoztatst vonjk maguk utn s
nincsenek hatssal ms egysgek tesztjeire. Az izolcis megkzelts teljesen sztvlasztja az egysg- s az integrcis tesztelst, ez ltal lehetv
teszi, hogy a fejlesztk a szoftver letciklus egysg tesztelsi szakaszban
valban csak egysgtesztelsre, mg integrcis tesztelskor csak integrcis tesztekre koncentrljanak. Az izolcis tesztels az egyetlen teljesen
tiszta egysgtesztelsi megkzelts, mg mind a bottom-up s mind a topdown tesztels egy hibrid egysg s integrcis tesztelsre vezet. Ellenttben a top-down s a bottom-up stratgikkal, az izolcis egysgtesztelsre nincsenek hatssal a modulok egyms kztti hivatkozsai.
Az izolcis tesztels htrnyai
Az izolcis tesztels egyik legfbb htrnya, hogy nem biztostja az egysgek korai integrcijt. Az integrcival meg kell vrni a szoftver letciklus integrcis fzist. (Ez csak bizonyos esetekben valdi htrny.) Az
izolcis tesztelsi megkzelts megkveteli strukturlis tervezsi informcik rendelkezsre llst s tesztvgrehajt modulok s csonkok rst.
Mivel ezt az egysghierarchia minden szintjn el kell vgezni ezrt ez kltsgesebb lehet mint az inkrementlis megkzelts esetben.
Vissza
96
Vissza
97
5.4.3. Top-down tesztels
Top-down egysgtesztelskor az egyes modulok az ket hv modulokbl

kerlnek tesztelsre, de elszigetelve az ltaluk hvott moduloktl. Elszr
a hierarchia cscsn ll modul kerl tesztelsre, az sszes hvott modult
csonkok helyettestik. A tesztels a csonkok tesztelend egysgekkel trtn helyettestsvel folytatdik, ahol a mlyebb szinten lv hvott egysgek helyett megint csonkok llnak. Ez a folyamat addig ismtldik, mg
a legals szint egysgek is tesztelsre kerlnek. A top-down tesztelshez
teht szksg van teszt csonkokra, de nincs szksg specilis kiegszt
tesztvgrehajt egysgekre.
A
Te szte lve
B
Te szte lve
C
Te szte lve
D
Te szte l s
l tt
E
Cso nk
F
Cso nk
G
Cso nk
5.10. bra. Top-down modul tesztels

Az bra a D egysg tesztelshez szksges mr tesztelt egysgeket s
csonkokat mutatja top-down tesztels esetn. A tesztels tbb szekvencilis lpsbl ll. Tesztelni kell a fels szint egysget a hvott egysgek
csonkokkal val helyettestsvel, majd ezutn a csonkokat helyettesteni
kell ugyanilyen mdon az aktulis tesztelend egysgekkel.
A top-down tesztels elnyei
A top-down egysgtesztels az egysgek korai, szoftver integrcis fzis
eltti integrcijt biztostja. Valjban a top-down egysgtesztels egy
kombinlt egysgtesztelsi s integrcis stratgia. Mivel a modulok rszletes tervezse top-down jelleg s a top-down egysgtesztels a teszteket
gy a modulok tervezsi sorrendjben hajtja vgre, a fejlesztsi idt cskkentheti a szoftver letciklus rszletes tervezsi s kdolsi fzist tlapol
egysg tesztels. Konvencionlis strukturlt tervezs esetn a hierarchia
cscsn lv egysgek biztostjk a szoftver magas szint funkciit, mg a
mlyebben lv egysgek implementljk a rszleteket. A top-down egy-
Vissza
97
Vissza
98
sgtesztels ebbl kifolylag a lthat funkcionalits korai integrcijt

biztostja s egy ersen kvetelmny orientlt megkzeltshez vezet az
egysgtesztels sorn. Top-down egysgtesztelssel azonosthat az alsbb
szint egysgekben megvalstott redundns funkcionalits, mert ez nem
fedhet le tesztekkel (A magasabb szint egysgek elrejtik).
A top-down tesztels htrnyai
A top-down tesztelst a csonkokkal lehet irnytani, a tesztesetek tbb
csonkot is hasznlhatnak egyszerre. Minden egyes tesztelt egysggel a tesztels egyre komplikltabb lesz s gy kltsgesebben kifejleszthet s karbantarthat. Ahogy a tesztels lefele halad az egysghierarchiban, gy egyre nehezebb azt a strukturlis lefedettsget elrni mely a nagy integrits s
biztonsg kritikus alkalmazsoknl szksges, illetve amit a szabvnyok
elrnak. A strukturlis lefeds nehzsge problmkat okoz a redundns
funkcionalits s a nem tesztelt funkcionalits elklntsben. Bizonyos
als szint funkcionalits tesztelse gyakorlatilag teljesen lehetetlenn vlhat. Egy egysgen vgrehajtott mdosts gyakran befolysolja a hierarchiban azonos vagy az alacsonyabb szinten lv egysgek tesztelst. Tekintsk a plda D egysgnek mdostst. Termszetesen a D egysg
tesztjeit meg kell vltoztatni s ismtelni. Ezenkvl az E, F, G, H, I, J
egysgek tesztjeit, melyek hasznltk a D egysget szintn meg kell ismtelni. Valsznleg meg is kell vltoztatni ezeket a teszteket a D egysg
mdostsa miatt, mindezt annak ellenre, hogy az E, F, G, H, I, J egysgek maguk nem vltoztak. Ez magas teszt karbantartsi s jratesztelsi
kltsgeket jelent vltoztatsok esetn. A top-down tesztesetek tervezse
megkveteli, hogy rendelkezznk arra vonatkoz informcival, hogy mikor hv a tesztels alatt ll modul ms modulokat. Az egysgek tesztelsnek sorrendjt az egysghierarchia hatrozza meg, az alsbb szint egysgeknek vrniuk kell a felsbb szint egysgek teszteltsgre, hossz egysgtesztelsi fzist eredmnyezve. A pldban szemlltetett egysgek viszonylag egyszer hierarchit alkotnak, vals programokban a modulok egy rszre egynl tbb msik modul is hivatkozik.
5.4.4. Bottom-up tesztels
Bottom-up egysgtesztelskor a modulok az ket hv moduloktl elszigetelten kerlnek tesztelsre, de a valdi hvott modulokat hasznljk sajt
hvsaikhoz. Elszr a legals szinten lv modulokat kell tesztelni, majd
ezeket kell hasznlni a felsbb szint egysgek tesztjeinl, vagyis mr tesztelt hvott egysgekkel kerl sor a tesztelsre. A folyamatot addig kell is-
Vissza
98
Vissza
99
mtelni, mg a hierarchia cscsn ll egysg is tesztelve nem lesz. A

bottom-up tesztels tesztvgrehajt egysgeket kvn, de nincs szksg
csonkokra.
A
Te szt
h jt
H
Te szte lve
D
Te szte l s
l tt
E
Te szte lve
F
Te szte lve
I
Te szte lve
J
Te szte lve
G
Te szte lve
5.11. bra. Bottom-up modul tesztels

Az bra a D egysg tesztelshez szksges tesztvgrehajt egysget s
korbban tesztelt egysgeket mutatja bottom-up megkzelts esetn. A
tesztels ismt egy tbb lpsbl ll szekvencia. Kln tesztvgrehajt
egysgek segtsgvel tesztelni kell a legalacsonyabb szint egysgeket. Ezutn tesztvgrehajt egysgekkel tesztelni kell a kvetkez szinten lv
modulokat, melyek a mr korbban tesztelt alacsonyabb szint egysgeket
hvjk. Az eljrst a hierarchia cscsn lv egysg tesztelsig kell vgezni.
A bottom-up tesztels elnyei
A top-down egysgtesztelshez hasonlan a bottom-up tesztels is biztostja az egysgek korai, szoftverintegrcis fzis eltti integrcijt. A
bottom-up egysgtesztels is egy kombinlt egysgtesztelsi s szoftverintegrcis stratgia. A teszteseteket teljes egszben a tesztvgrehajt egysgek hatrozzk meg, nincs szksg csonkokra. Ez az egysghierarchia
aljn ll modulok tesztelst relatv egyszerv teszi. A bottom-up tesztels tesztesetei a funkcionlis tervezsi informcikbl szrmaztathatk,
nincs szksg strukturlis tervezsi informcikra, br teljes lefedettsg
elrshez hasznosak lehetnek. A bottom-up tesztels az alacsonyszint
funkcionalits korai integrcijt biztostja, a felsbb szint funkcionalits
az egysghierarchin felfel haladva szintenknt addik ehhez hozz. Ebbl kifolylag ez a tesztelsi stratgia jl hasznlhat objektumok tesztelsre.
Vissza
99
Vissza
100
A bottom-up tesztels htrnyai

Ahogy a tesztels felfel halad az egysghierarchiban gy vlik a bottomup egysgtesztels mind bonyolultabb s ezrt egyre nehezebben kifejleszthetv s karbantarthatv. Ezzel prhuzamosan egyre nehezebb
vlik kielgt strukturlis lefedettsget elrni. Egy egysg megvltoztatsa
gyakran hatssal van a hierarchiban felette lv egysgekre. Tekintsk a
plda H egysgnek megvltoztatst. Trivilis, hogy a H egysg tesztjeit meg kell vltoztatni s meg kell ismtelni. Ezenkvl meg kell ismtelni
s esetleg vltoztatni az A, D, E egysgek tesztjeit is hiszen ezen tesztek
hasznltk a tesztelt H egysget, br maguk az A, D, E egysgek nem
vltoztak. Vagyis a vltoztatsok jelents jra tesztelsi kltsggel jrnak.
Az egysgek tesztelsi sorrendjt az egysghierarchiban elfoglalt helyk
korltozza. A magasabb szinteken lv egysgek tesztelsvel meg kell
vrni az alacsony szint egysgek tesztelsnek befejezst, ami hossz
egysgtesztelsi fzishoz vezet. Az elszr tesztelsre kerl egysgek
kerlnek legksbb tervezsre, gy az egysgtesztels nem fedheti t a
szoftver letciklus rszletes tervezsi fzist. A top-down tesztelshez hasonlan itt is jelentsen nehezti a tesztelst, ha egy egysgre tbb msik
egysg is hivatkozik.
5.4.5. Egysgtesztelsi stratgik sszehasonltsa
Az izolcis egysgtesztels a legjobb vlaszts egysgtesztelsre. Ha egy

megfelel integrcis stratgival egszl ki, akkor segt lervidteni a fejlesztsi idt. Az izolcis egysgtesztelst kveten az egysgek top-down,
bottom-up sorrendben vagy brmilyen megfelel kombinciban integrlhatk. Ez a mdszer a legkedvezbb magas strukturlis lefedettsg elrsre. A top-down stratgia kltsgesebb, mint az izolcis stratgia. Ezt a
tesztek nagyobb komplexitsa s vltoztatsok komoly hatsa okozza. A
top-down stratgia nem j vlaszts egysgtesztelsre, hanem inkbb a
mr tesztelt egysgek integrlsnak megfelel eszkze. A bottom-up
megkzelts j egysgtesztelsi stratgia lehet klnsen, ha objektumokat s egysg jra felhasznlst tekintnk. Azonban a bottom-up megkzelts inkbb a funkcionlis, mint a strukturlis tesztels irnyba mutat.
Ez a megfelel strukturlis lefedettsg elrsben okozhat gondot, pldul
biztonsgkritikus alkalmazsok esetn. A bottom-up tesztels nem megfelel stratgia a legtbb szoftverprojekt rvid idkorltjai miatt.
Vissza
100
Vissza
101
5.5. Integrcis tesztels s rendszertesztels

A modul szint tesztelst kveten magasabb szinteken kell a tesztelst
tovbb folytatni. Ezek a tesztelsi szintek prhuzamosak a fejlesztsi V
letciklus megfelel szintjeivel. gy teht a magasabb szint tesztels tbb
szintet jelent. Legalacsonyabb szinten idetartoznak a modulok rendszerbeli egyttmkdst (integrcijt) ellenrz integrcis tesztek. A kvetkez, n. funkciteszt szinten mr tisztn black-box jelleg teszteket vgznk a kls specifikcinak val megfelels ellenrzsre. Ebben a tesztelsi fzisban szerepet kell kapnia a negatv teszteknek is. A kvetkez
szint a rendszertesztek szintje. Itt nem a rendszer funkciit teszteljk, hanem a rendszer eredeti cljainak val megfelelsgt.
5.5.1. Integrcis tesztels
A tisztn integrcis tesztek a szoftver letciklus integrcis fzisban

kerlnek vgrehajtsra, s a klnbz modulok hierarchikus fggseinek,
interakciinak ellenrzsre szolglnak. Ebben a tesztelsi fzisban ltalban nehz az egyes modulok programkdjnak teljes lefedse,s nem is ez
a cl, a hangsly a modulok kapcsoldsi pontjainak tesztelsn van: interfszek, inter-modul zenetkezelk. A kooperl modulokbl felptett
rendszerek llapott az egyes modulok kztti interakcik is meghatrozzk. Elkpzelhet, hogy egy rendszer annak ellenre hibsan mkdik,
hogy az sszes alkot komponense egyenknt korrekt. Az egsz rendszer
szekvencilis mkdst moduljainak a kapcsolata is befolysolja. Ezek a
tesztek tovbbra is tartalmaznak white-box jelleg struktrlis teszteket.
(A white-box integrcis tesztek kln hangslyt kaptak az objektum orientlt fejlesztsi mdszerek megjelensvel.)
Alkalmazs
Modulok
Potencilis hibk
Teszt input
5.12. bra. Az integrcis tesztels a modulok interakciit ellenrzi
Vissza
101
Vissza
102
Az integrcis tesztekkel kapcsolatban a kvetkez stratgiai krdst lehet

feltenni: az sszes, mr korbban egyenknt tesztelt modult egyszerre
kombinlva az alkalmazss hajtsuk vgre az integrcis tesztelst, vagy
kvessnk egy olyan stratgit, mely a modulokat egyenknt kombinlja a
mr egysgben tesztelt modulokkal az jabb tesztelend rendszerr? Az
els megkzeltsmdot hvjk big-bang integrcinak, mg a msodik
az inkrementlis integrci.
Az inkrementlis integrci stratgii megegyeznek az inkrementlis
egysgtesztels stratgiival, hiszen az inkrementlis egysgtesztels integrcis elemeket hordoz magban, vagyis hibrid stratginak tekinthet.
Ebbl kifolylag teht itt is top-down s bottom-up integrcirl beszlhetnk. A kt technika kzl az integrcis tesztelsi clokat inkbb a
bottom-up stratgia szolglja. Az letciklus integrcis fzisban ugyanis
mr rendelkezsre llnak a legalacsonyabb szint modulok.
5.5.2. Rendszertesztels
Ez utbbi tesztelsi fzis a megfogalmazott cloknak a kvetelmnyek

meghatrozsakor specifikciv trtn alaktsnl elkvetett hibk feltrst szolglja. Mivel a termk szempontjbl ez az egyik legkritikusabb
szakasz a fejleszts sorn, a rendszertesztels egy ltfontossg szakasza a
tesztelsnek. A rendszertesztels nehzsgt az jelenti, hogy a clokat
meghatroz dokumentumok nem elg rszletesek ahhoz, hogy konkrt
tesztesetek szrmaztathatk legyenek bellk, mg a kls specifikci
hasznlata tlmutat a rendszertesztels cljain. A rendszertesztelshez
hasznlt teszteseteket a rendszer cljainak elemzsbl s felhasznli
dokumentcijbl kiindulva kell elkszteni. A problmt az okozza,
hogy a rendszer cljai nem hatrozzk meg a clok elrshez szksges
funkcikat, melyeknek a reprezentldsa viszont szksges volna a tesztesetek tervezsnl. A rendszerteszteket lehetleg a fejlesztktl fggetlen s a vgfelhasznlk helyzett ismer szervezetnek kell vgeznie. Annak ellenre, hogy nem ltezik ltalnosan elfogadott mdszertan a rendszertesztek ltrehozsra s elvgzsre, a rendszertesztek az albbi pontokban ismertetett kategrikba sorolhatk.
Szolgltatstesztels
Az egyik legalapvetbb dolog, amit tesztelni kell egy rendszeren, hogy
valban nyjtja-e azokat a szolgltatsokat melyeket cljai kztt megjelltek. Ez abban klnbzik a funkcitesztelstl, hogy nem a szoftverspecifikcira pl. A teszt sorn meg kell hatrozni, hogy a clok lersban
Vissza
102
Vissza
103
megadott tevkenysgeket az ott lertak szerint el lehet-e elvgezni a

szoftverrel. Ez a fajta tesztels az esetek egy rszben elvgezhet a felhasznli dokumentci alapjn.
Mennyisgi tesztels
Ez a tpus tesztels azt jelenti, hogy a szoftver mkdst nagy mennyisg adattal teszteljk a kapacitskorltok ellenrzsre. A mennyisgi
tesztels viszonylag erforrs ignyes, olyan rtelemben, hogy a nagy
mennyisg megfelel adat ellltsa, majd a tesztels maga is idignyes
lehet, s az adatok is komoly trolkapacitst ignyelhetnek.
Lket-terhelses tesztels (Stressz-tesztels)
A lket-terhelses tesztels a tesztelt rendszert valamilyen szempontbl
ers terhelsnek, stressznek teszi ki. Ez a fajta tesztels nem keverend
ssze a mennyisgi tesztelssel: a stressz-tesztelsnek fontos tnyezje az
id, itt teht nagy mennyisg adat rvid id alatti feldolgozsrl van sz.
A stressz-tesztels ltalban fontos eleme folyamatirnyt, valsidej vagy
biztonsg kritikus rendszerek tesztelsnek. A tesztels sorn teht olyan
intenzv feldolgozst kvn helyzeteket teremtenek, melyek szlssgesek
ugyan, de nem elkpzelhetetlenek a rendszer mkdse sorn. A rendszer,
vals helyzetekben megnyilvnul, robosztussgnak ellenrzsre vgeznek olyan stressz-teszteket is, melyek a valsgban soha el nem fordul
feltteleket jelentenek.
Hasznlhatsgi tesztels
A szoftver minsg egyik modern megkzeltse a hasznlat kzbeni
minsg fogalma. A hasznlat kzbeni minsg azt jelenti, hogy egy termk egy meghatrozott felhasznl ltal, egy meghatrozott felhasznlsi
krben hasznlva, meghatrozott clok hatkony s produktv elrsre,
mennyire kielgt s mennyire vezet megelgedsre. Vagyis a hasznlhatsgi minsget hatkonysgi teljestmnymutatkkal s a megelgedettsggel lehet mrni. A hasznlhatsgi tesztels clja teht az emberkomputer interakci minsgnek ellenrzse, azaz, hogy mennyire egyszer megtanulni a szoftver hasznlatt, mennyire kielgt hasznlni.
Ezek a krdsek ltalban a szoftver felhasznl felletnek tervezsvel
fggenek ssze. A tesztels sorn a felhasznl teljestmnyre vonatkoz
kvantitatv (idk, pontossg, elvgzett feladatok szma) s a megelgedettsgre, vlemnyre vonatkoz kvalitatv (krdvek, megjegyzsek) adatokat
Vissza
103
Vissza
104
gyjtenek. Ezen adatok alapjn azonosthatk a hasznlhatsgot befolysol hibk.

Biztonsgi tesztels
A biztonsgi tesztels clja, hogy felfedje az adatbiztonsggal s adatvdelemmel kapcsolatos hibkat. Az adatvdelem az adatok elrst s a jogosultsgokat szablyozza, mg az adatbiztonsg az adatok helyessgt, integritst jelenti. Tesztesetek ltrehozshoz elnys lehet a hasonl rendszerek mr feldertett biztonsgi hinyossgainak ismerete.
Teljestmnytesztels
A programok egy rsznl a teljestmny vagy a hatkonysg specifiklva
van klnbz terhelseknl s konfigurcikra meghatrozott vlaszidk
s feldolgozsi sebessgek formjban. A tesztesetek clja annak a demonstrlsa, hogy a rendszer nem kpes a megadott teljestmnyclok
kielgtsre. A teljestmny tesztels ltalban megkveteli hogy ismerjk
az adott program dinamikus viselkedst s olyan tesztkrnyezetek hasznlatt melyek kpesek tetszleges esemnyek idmrsre, az idt is tartalmaz naplzsra.
Konfigurcitesztels
Bizonyos programoknak eltr opercis krnyezetekben is mkdnik
kell. Ezek a klnbz krnyezetek jelenthetnek eltr hardver konfigurcikat (adott esetben teljesen klnbz architektrkat), klnbz opercis rendszereket ill. klnbz szoftver installcikat. A konfigurcitesztels sok esetben klnbz konfigurcikban elvgzend teljestmnytesztelst jelent. A cloknak megfelelen, lehetleg minl nagyobb
szm konfigurcira kell elvgezni a teszteket. Bizonyos esetekben elg a
teszteket elvgezni a minimum s maximum konfigurcikra. Sokszor a
programoknak korbbi rendszerekhez kell kapcsoldniuk, vagy a program
egy korbbi vltozatt vltjk le. Ezekben az esetekben tesztekkel ellenrizni kell a kompatibilitsi clok elrst vagy a konverzis eljrsokat. A
konfigurcis tesztelst segtheti, ha a tesztel krnyezet kpes a mr elksztett tesztesetek automatizlt vgrehajtsra a klnbz konfigurcikban. Erre legalkalmasabbak az adat vezrelt tesztkrnyezetek.
Megbzhatsgi tesztels
Termszetesen mindenfle tesztelsnek az a clja, hogy nvelje a szoftver
megbzhatsgt, de ha program cljai kztt megbzhatsggal kapcsola-
Vissza
104
Vissza
105
tos specilis kittelek szerepelnek, akkor kln megbzhatsgi teszteket is

kell vgezni. ltalban igen nehz a tesztelshez rendelkezsre ll id
alatt a rendkvl alacsony meghibsodsi rta kvetelmnyeknek megfelel
rendszerek tesztelse. Bizonyos megbzhatsgi paramterek rvnyessgre matematikai modellek alapjn adhatunk becslseket. A megbzhatsgi teszteknek adott esetben ki kell terjednik a rendszer programozsi,
hardver- vagy adathibk bekvetkezte utni felllsra, mkdsbe visszallsra. A teszteknek rinteni kell ezen visszallt eljrsokat. (Gondoljunk a modern programozsi nyelvek kivtelkezel mechanizmusaira.)
Ezeknek a teszteknek a vgrehajtst segtik az olyan tesztkrnyezetek
melyek kpesek hibainjektlsra, hibs mkds kivltsra (hardver hibk
szimullsa).
Dokumentci-tesztels
A felhasznli dokumentci minsge elssorban a hasznlhatsgot
befolysolja. Msrszt, mint lttuk a rendszertesztelst meghatrozza a
felhasznli dokumentci pontossga. Ezen okokbl kifolylag teht
szksges e dokumentci ellenrzse pontossg s vilgos rthetsg
szempontjbl. A dokumentciban szerepl sszes illusztratv pldt le
kell kpezni tesztesetekk s vgre is kell hajtani velk a tesztelst.
5.6. Validcis tesztels
A validcis folyamatokban egyrszt a rendszer funkcionlis tren elvrt
mkdsnek ellenrzsre van szksg, msrszt pedig az ezen tlmen,
tovbbi felhasznli elvrsok teljeslst is igazolni kell. Az utbbi kritrium elssorban a biztonsgkritikus rendszerek esetben vlik fontoss. Itt
szksg van arra, hogy a rendszer olyan tulajdonsgait, mkdsi mdjait
is megvizsgljuk, amelyeket a tervezsi specifikci nem definilt.
Az 5.3. alpontban mr foglalkoztunk a validcis tesztek megtervezsre vonatkoz kln elrsokkal, amelyek kitrnek a vizsglatok klnbz terleteire. Az egyes tesztelsi folyamatokat ezen elrsok szerint
kell lebonyoltani.
A biztonsgos mkds teljeslsnek igazolsa megkveteli, hogy
minl tbb olyan tesztet hajtsunk vgre, amely a valsgos krnyezet esemnyeit foglalja magban. Az elrt funkcik teljestsnek ellenrzse
utn olyan bemeneti feltteleknek clszer kitenni a rendszert, amelyek
kritikus helyzeteket teremtenek el.
Vissza
105
Vissza
106
Az eddig bekvetkezett katasztrfk vizsglata mindig azt az eredmnyt hozta, hogy tbb egyttesen fellp vratlan esemny kombincija
idzte el a nem kvnt esetet. Mivel a tervezs sorn nem vrhat el, hogy
minden lehetsges esemnyre fel lehessen kszlni, minden elfordulhat
helyzetet vgig lehessen kvetni, ezrt ennek a ptlsra egyedl a tesztels ad mdot. A tesztelsben megvan a lehetsge annak, hogy a tervezstl fggetlen szemly vagy csoport teremtsen olyan helyzeteket a vizsglt
rendszer szmra, amelyben kiderlhet, hogy az nem lett felksztve az
ilyenek megfelel feldolgozsra, kezelsre. Clszer teht arra trekedni,
hogy minl tbb esemnykombinci kerljn vizsglatra, amelyek lehetnek szokatlanok, ill. kis valsznsggel elfordulk. Az ilyen irnyultsg
tesztek ellltsra rdemes ignybe venni a vletlenszer adatgenerls
mdszert is. Ugyanis a random bemeneti adatok kztt elfordulhatnak
olyanok is, amelyek extrm zemeltetsi feltteleket rnak el.
5.6.1. Idztsi szempontok
Az ipari, gyrtsi, vagy kzlekedsi, replsi folyamatokat irnyt biztonsgkritikus rendszerek vals idben kell hogy zemeljenek. A vals idej
rendszerekre nzve olyan idkorltok rvnyeslnek, amelyeken bell kell
a rendszernek a kls esemnyekre reaglni, s a megfelel vlaszt adni.
Az egyes idkorltok fggenek az adott kls esemnyek kategrijtl,
vagyis a klnbz esemnyekhez klnbz reaglsi idkorltok vannak rendelve.
A vals idej megktsek kielgtse sok esetben igen komoly kvetelmnyt jelent mind a hardver, mind pedig a szoftver oldalrl. Ugyancsak nehz feladat annak az igazolsa is, hogy a megktsek feltteleit teljesti az adott berendezs. Az igazolsi feladat megoldsa kt rszbl ll:
A rendszerkvetelmnyekbl meg kell hatrozni az idztsi korltozsokat.
Meg kell mutatni, hogy ezek a korltozsok ki vannak elgtve.
Az els feladat jval nehezebb, mint amilyennek ltszik, mivel sok idkorlt valaminek a kvetkezmnye, ahelyett, hogy kifejezetten deklarlva lenne. Amikor a specifikci termszetes nyelven van lerva, akkor klnsen
nehz a lersbl azonostani s szmszersteni az sszes idztsi kvetkezmnyt.
Miutn az idkorltok azonostva lettek, szksgess vlik annak verifiklsa, hogy azok mindegyike ki van elgtve. A hardver ilyen irny
Vissza
106
Vissza
107
vizsglata elgg kidolgozottan hajthat vgre, dinamikus tesztelssel, vagy

szimulcis ellenrzssel. A dinamikus tesztelshez, programozhat idbelltsi lehetsgekkel rendelkez nagysebessg mrberendezsek
llnak rendelkezsre. A jelentkez problmk az olyan aszinkron tevkenysgekkel vannak kapcsolatban, mint amilyen a kls rendszerekkel
val kommunikci, vagy pedig a kvlrl jv mrsi adatok rzkelse.
A szoftver idbeli sajtsgainak vizsglata mr ltalban sokkal bonyolultabb, a viselkeds sszetettsge kvetkeztben. A rendszer dinamikus
tesztelse a valdi futsi krlmnyek kztt vgezhet, de a lehetsges
esetek teljes vgigprblsa mr tbbnyire komoly nehzsgekbe tkzik.
Emiatt nem bizonythat, hogy az idkorltok betartsa minden esetben,
minden mkdsi helyzetben teljesl.
5.6.2. Krnyezeti szimulci
A biztonsgkritikus rendszerek esetben gyakran nincs arra lehetsg,

hogy a rendszert teljes egszben a vals mkdsi krlmnyek kztt
vessk vizsglat al. Pldul, ha egy nukleris erm biztonsgi lellt
rendszert teszteljk, akkor nem tehetjk meg azt, hogy a lellts menetnek ellenrzsekor a reaktort egy esetlegesen veszlyes llapotba juttatjuk.
Ugyangy nem tehet meg az sem, hogy egy vasti irnytrendszert a vals plyaudvari forgalom fenntartsa alatt tesztelnk. Az ilyen szitucikban az elterjedten alkalmazott megolds a rendszer vals krnyezetnek a
szimulcija. A szimulcis krnyezet megteremtse trtnhet hardver, ill.
szoftver rvn, s a kett kombincijval is. Ez a megolds nemcsak a
biztonsgot garantlja a vizsglati folyamatok idejre, hanem jval hatkonyabb, szabadabb, gyorsabb, tfogbb s teljesebb tesztelst tesz lehetv
a mkdsre vonatkozan. A vizsglatokba termszetesen nemcsak a statikus mkds, hanem a dinamikus is bekapcsolhat, az idkorltok ellenrzsvel.
A biztonsgorientlt rendszerek tesztelsekor hasznlt szimultorokkal
szemben is szigor minsgi kvetelmnyeket kell tmasztani ahhoz, hogy
megbzhat legyen a velk vgzett tesztelsi folyamat.
A szimultorok minsgnek meghatrozst tbb tnyez befolysolja, melyek kzl az albbiakban sorolunk fel nhnyat:
A szimullt vltozk: Mely krnyezeti vltozk vannak figyelembe
vve, s melyek vannak elhanyagolva.
Az alkalmazott modellek pontossga: Azoknak a modelleknek a
pontossga, amelyek a klnbz krnyezeti hatsokat reprezentljk.
Vissza
107
Vissza
108
A szmtsok pontossga: Az egyes vltozk kiszmtsnl alkalmazott felbontsi fok s pontossg.

Az idztsek figyelembevtele: A szmtsi sebessg hatsa a szimulcira.
A szakirodalom tansga szerint jelenleg mg nincsen ltalnosan elfogadott mdszer a szimultorok minsgnek meghatrozsra, eldntsre.
Ennek az a f oka, hogy a klnbz tnyezk, paramterek az alkalmazsoktl fggen ersen eltrnek egymstl. A gyakorlatban a szimultorok rtkelse elssorban a felhasznlsi tapasztalatokon alapszik.
A biztonsgkritikus projektekben a szimultorok felhasznlsn alapul tesztelsi eredmnyek nagyon fontos szerepet jtszanak a validcis
folyamatokban. A megbzhat felhasznlshoz arra van szksg, hogy a
szimultorok fejlesztse is szigor elvek szerint trtnjk. Ugyancsak ajnlatos a fejlesztst attl a rendszertl fggetlenl vgezni, aminek a tesztelshez a szimultor fel lesz felhasznlva, annak rdekben, hogy cskkentsk a kzs tervezsi hibk kockzatt.
A validls elvgzsre vonatkozan az IEC 1508 szabvny tervezete
olyan elrsokat tartalmaz, amelyek szerint a magas biztonsgi kvetelmnyekkel fejlesztett rendszerek validlst felttlenl fggetlen szervezeteknek kell elvgezni. Olyan szervezeteknek teht, amelyeknek semmilyen
kapcsolata nincsen a fejleszt intzmnnyel.
5.7. A tesztels kltsge
A tesztelsi-diagnosztizlsi folyamatok vgrehajtsa meglehetsen idignyes s kltsgignyes feladat. Ez mg akkor is gy van, amikor jl megtervezett tesztkszlet ll rendelkezsre. A hibs mkds feltrsa, a hiba
detektlsa utn szksg van ugyanis a hiba oknak, helynek pontos
meghatrozsra, a diagnosztizlsra. Ez a tevkenysg az, ami a kltsgeket jelentsen nveli. A hibahely meghatrozsa akkor is szksges, amikor egy szoftver zemeltetse sorn, vagy forgalomba hozatala utn derl
ki a hibs mkds, a fejleszts tesztelsi folyamatn kvl esve.
Magtl rtetdik, hogy minden modulokbl felpl rendszernl nvekedni fog a hibakeress s hibajavts kltsge, ha arra az ptsi folyamat egy ksbbi szakaszban kerl sor, ahhoz kpest, hogy egy korbbi
szakaszban trtnt volna meg ez. Hardver esetben az sszegylt tbb
vtizedes tapasztalat azt mutatja, hogy az ptkezsi lpcsk emelkedsvel
ez a kltsg minden jabb lpcsnl 10-szeresre nvekszik. A megfigye-
Vissza
108
Vissza
109
lsek alapjn, szoftver tren sem vrhatunk el kedvezbb adatokat. St,

mivel a hardvertechnolgia folyamatai jval kialakultabb, megszabottabb
rendben hajtdnak vgre, a szoftvernl ennl nagyobb arny kltsgugrsokra szmthatunk. Az exponencilis nvekedsi trend rvnyeslst az
5.13. brn szemlltetjk. Mindezek alapjn kijelenthetjk, hogy nagy jelentsge s komoly kltsgcskkentsi kihatsa van annak, hogy egy
adott szoftverhibt a fejlesztsi folyamat minl korbbi szakaszban szrjnk ki. Egy ksbbi szakaszban ugyanaz a hiba mr jval nagyobb rfordtssal tvolthat el.
(Kltsg)
Kvetelmnyek
Kdolva
Kibocstva
(Id)
5.13. bra. A tesztelsi kltsgek vltozsa

A hibk felfedsnek s javtsnak kltsgeit sok tnyez hatrozza meg.
Ilyenek pldul: a fejlesztk, tesztelk bre a rfordtsi idtl fggen, a
gpid kltsge, az infrastrukturlis kltsg, tovbb piacra vitt szoftvernl a felhasznlknl tett cserk kltsge. Az utbbi esetben, ha pldul
egy kompjler vagy egy opercis rendszer javtott vltozatnak cserjre
van szksg, az eladott ttelszmtl fggen a kltsg risira nhet.
Egy publiklt adat, amely egy amerikai szoftverfejleszt cgtl szrmazik (C. Kaner, J. Falk, H. Q Nguyen, USA, 1993):
Fejlesztsi kltsg:
75 $ / utasts
Karbantarts:
4.000 $ / utasts
Vissza
109
Vissza
110
Lthat, hogy a kt stdiumban fellp kltsgek kt nagysgrendnyit trnek el egymstl.

Szmos szoftverfejleszt cgtl gyjttt adatok tlagolsa alapjn az
5.1. tblzatban szerepl irnymutat kltsgmegoszlst valsznstette
A. Jarvis s V. Crandall (USA, 1997):
5.1. tblzat. Egy hiba kijavtsnak kltsge
a szoftver fejlesztsi letciklusban
Specifkci/
Tervezs
10100$
Programozs
Tesztels
100300$
5001.500$
Installls/
Karbantarts
10.000$
millik $-ban
A fejlesztst vgz intzmnyeknek rdemes lland kltsgfigyelst vgezni a hibajavts terletn. Ehhez fel kell jegyeznik az sszes olyan
rfordtst, amely a hibakeressre s javtsra vonatkozott. Elfordulhat
olyan eset is, amikor egy-egy hiba miatt nagyobb ttervezst, talaktst
kell vgrehajtani a szoftveren. Ez is jelents kltsgnvekedssel jrhat.
A biztonsg-orientlt rendszereknl a ksn szlelt hibk nemcsak a
javtsi kltsgben jelentkezhetnek, hanem a rendszer tves mkdse ltal
okozott krokban is, ami ugyancsak kltsgnvel tnyez. Az ilyen rendszereknk fokozott jelentsge van a korai hibaelhrtsnak.
A tesztelsi rfordtsok a fejleszts tekintlyes rszt teszik ki. Az erre
irnyul kltsgek cskkentse ezrt nagyon fontos. A mrsre a kvetkez kifejezs ltal definilt szmot (tesztkltsgi tnyez, test cost factor TCF)
szoks hasznlni:
Tesztkltsgi tnyez =
Tesztels kltsge
Tesztels kltsge + Tervezs kltsge
A tesztkltsgi tnyez rtke a ltrehozott alkalmazs termszettl, sajtsgaitl fgg. Ersen valsznsthet, hogy rtke mind a komplexits,
mind pedig a biztonsgi szint nvekedsvel egytt nvekszik. A hasonl
jellemzkkel br rendszerek tnyezi kztti klnbsg azt tkrzi, hogy
a fejleszt teamek milyen kpessggel s sikerrel ksreltk meg cskkenteni az ellenrzsi rfordtsokat. Azt mutatja, hogy mennyire sikerlt nekik jl tesztelhet rendszert ltrehozni. A gyakorlati tapasztalatok szerint a
Vissza
110
Vissza
111
tesztkltsgi tnyez tipikusan a 0,250,75 kztti svban mozog. (Irodalmi adat: N. Storey, Nagy-Britannia, 1996.)
5.8. Bizonylatols
Bizonylatols (certification): Annak igazolsa, hogy a termk minden
tekintetben megfelel a hatsgi elrsoknak, szabvnyoknak, kvetelmnyeknek.
A bizonylatolst minden orszgban egy erre a clra ltrehozott hatsg
rja el. Ilyen elrs vonatkozhat pldul a replgpekre, amelyek csak
akkor kerlhetnek forgalomba, vagyis szllhatnak fel, ha erre megvan a
megfelel bizonylat. A forgalomba helyezshez szksges bizonylatok
minden lgi jrmre el vannak rva. A biztonsgkritikus rendszerekre
nzve is hasonl jelleg elrsok vonatkoznak, melyek orszgonknt vltoznak. Az esetek tbbsgben llami hatsgokra tartozik a bizonylatok
elrsi rendjnek kidolgozsa s betartatsa.
A biztonsgkritikus rendszerek esetben a biztonsgrl kell meggyzni
a megfelel szablyoz szervet. Ez ltalban igen nehz feladat. A fejlesztnek meg kell mutatnia, hogy minden fontosabb hazrd azonostva lett,
s gondoskods trtnt az elkerlskrl, tovbb hogy a rendszer kell
vdelmet kapott az illetktelen hozzfrs s helytelen kezels ellen. A
bizonylat kiadshoz ugyancsak szksg lehet annak igazolsra is, hogy az
adott rendszer miden pontban megfelel-e az sszes ide vonatkoz szabvny elrsainak. A fejleszt s kivitelez cgnek rszletesen dokumentlnia kell a fejlesztsnl hasznlt mdszereket, tovbb a tesztelsnl
hasznlt megoldsokat is. Mindezeken tl szigoran al kell tmasztani azt
az lltst, hogy a rendszer kellkppen biztonsgos, s az is marad a teljes
letciklusa alatt. A bizonylat kiadsig terjed munka meglehetsen nagy
volumen, s ehhez mg igen gondos, alapos tervezst kvetel meg.
A biztonsgkritikus rendszerek gyrti mindenkppen r vannak utalva
arra, hogy az ltaluk fejlesztett berendezsek megkapjk az zembe helyezshez szksges bizonylatot. Az erre vonatkoz kvetelmnyek vltoznak az alkalmazstl s az orszgtl fggen. Pldul az orvosi elektronika
terletn Nagy-Britanniban a bizonylatols nkntes, az Egyeslt llamokban s Nmetorszgban viszont szigoran ktelez. A polgri replsben s a nukleris ermveknl a bizonylatols mindig ktelez. Az
esetek tbbsgben a teljes rendszerre vonatkozik az engedlyezsi elrs,
mskor pedig csak a kritikus komponensekre.
Vissza
111
Vissza
112
A szoftvert tartalmaz termkek klnleges figyelmet rdemelnek,

amellett kln problmkkal jrnak mind a fejleszt, mind pedig a bizonylatolsi szablyzatot kidolgoz hatsgok szmra. Az ilyen rendszerek
megbzhat tesztelse nem csak magnak a rendszernek az ellenrzst
kveteli meg, hanem a fejlesztsi folyamatok egsznek az ellenrzst is.
Utbbi egyrszt a felhasznlt mdszerek, fejlesztsi technolgik vizsglatt jelenti, msrszt pedig a fejlesztst vgz szemlyzet hozzrtsnek
vizsglatt is.
Az zemeltetshez elrt bizonylat kiadshoz szksg van annak igazolsra is, hogy az adott rendszer biztonsgos. Az ehhez vgrehajtand
folyamatot nevezzk biztonsgigazolsnak. A bizonylatozs rszeknt kezelend biztonsgigazols ugyancsak elrsok szerint kell hogy vgbemenjen. Pldaknt megadunk egy listt, amely azt sorolja fel, hogy milyen dokumentumok elksztsre van szksg a biztonsgigazolshoz. A listra
vonatkoz javaslatot az Angliban szervezett, llami tmogats projekt
(CONTESS projekt, 1995) keretben dolgoztk ki:
A biztonsgkritikus rendszer lersa.
A biztonsgi tervezsben rszt vev szemlyzet kompetencijnak
igazolsa.
A biztonsgi kvetelmnyek specifikcija.
A hazrdok s kockzatok analzisnek eredmnyei.
A kockzatok cskkentsre alkalmazott mdszerek rszletezse.
A tervezsi elemzsek eredmnye, amely azt mutatja meg, hogy a rendszer tervezse minden szempontbl elsegti a biztonsgi clok elrst.
A verifikcis s validcis stratgia.
Az sszes verifikcis s validcis tevkenysg eredmnyei.
A biztonsgi vizsglatok eredmnyei.
Azon esemnyek feljegyzse, amelyek a rendszer zemeltetse sorn
lptek fel.
A rendszeren vgrehajtott vltoztatsok feljegyzse, s annak bizonytsa, hogy a rendszer tovbbra is megrizte biztonsgossgt.
A bizonylatols teht vgs soron magban kell hogy foglalja a rendszer
verifiklsnak, validlsnak jvhagyst, valamint az ezeken tl mg
meglev hatsgi elrsok, szabvnyok betartsnak ellenrzst is. Kiterjedhet a rendszer biztonsgos zemeltetsnek ellenrzsre is.
Vissza
112
Vissza
113
sszefoglalva a kvetkezket llapthatjuk meg: A bizonylatols hrom kvetelmnyrendszer kielgtsnek elismerst, elfogadst szolglja:
A specifikcis kvetelmnyeknek val megfelelst (verifikci).
A felhasznli kvetelmnyeknek val megfelelst (validci).
A hatsgi elrsoknak val megfelelst.
5.9. A formlis mdszerek szerepe
A formlis mdszerek matematikai alapokon ll eljrsok, amelyeket az
informatikai rendszerek
specifiklsra,
tervezsre, valamint
analzisre
hasznlnak fel. A felsorolt felhasznlsi mdok egyarnt vonatkoznak a
hardverre s a szoftverre. Az ide tartoz formlis megkzelts a diszkrt
matematika, a szmtgpes nyelvek s fordtprogramok, a matematikai
nyelvszet, valamint a matematikai logika felhasznlsn, ill. tovbbfejlesztsn alapszik. Jelentsge a matematikai precizits s szigorsg tfog
kihasznlsban rejlik, ami pontos, ellentmondsmentes s egyrtelm megoldsokat
segt el.
Ebben a felfogsban az eddig lert megoldsok valjban informlis
specifikcis s tervezsi mdszereken alapultak. A specifikci ltalban
valamilyen verblis, lersos alapon van elksztve. Ez a lers lehet pontatlan, nem egyrtelm, nem teljes, esetleg ellentmondsokat is tartalmazhat.
A formlis megkzelts precz matematikai technikinak alkalmazsa ppen arra irnyul, hogy ezeket a hinyossgokat ki lehessen kszblni.
(Ismeretes, hogy a formalitst teljesen nlklz jogalkots lland velejrja a trvnyek kztti ellentmondsok meglte, valamint hinyos trvnyek megszletse, amelyek tele vannak joghzaggal. A mszaki vilgban ugyangy keletkezhetnek specifikcis hzagok is, amelyek pldul
slyos kvetkezmnyekkel jrhatnak a biztonsgra nzve.) Az alapvet
feladat teht az egyrtelm, pontos s ellentmondsmentes specifikci megteremtse.
Ebben az irnyban mr rgta komoly trekvsek trtntek. Ilyenek
pldul a szoftverfejlesztsben az n. CASE-eszkzk (CASE: ComputerAided Software Engineering, szmtgppel segtett szoftvertechnolgia),
vagy a grafikus specifikcis eszkzk a rendszerek lersra. Ezek n.
Vissza
113
Vissza
114
formalizlt mdszerek, amelyek szisztematikusak, s nagymrtkben elsegtik a pontos tervezst, azonban mg nem garantljk a kvnt cl elrst.
Ugyanis teljes mrtkben a terveztl fgg az alkalmazsuk mikntje, mg
akkor is, ha komoly segtsget jelentenek szmra. Arrl van sz, hogy a
terveznek ezek a munkjt knnytik meg, teszik gyorsabb, egy sereg
manulis, ill. munkaignyes feladatot levve a vllrl, de a tervezs helyessge egyedl a tervezn mlik. A hibzsi lehetsgeket lnyegesen
cskkentik, de meg nem szntetik.
A formlis mdszerek ettl klnbznek. Olyan formlis nyelveken
alapulnak, amelyek igen precz szablyokat hordoznak magukban. A terveznek ezeket a szablyokat ktelez betartani, mert a nyelv fordtprogramja kijelzi a szablyok megszegst. Ez egyrtelm specifikcit eredmnyez, msrszt pedig a szablyok betartsa lehetv teszi azt is, hogy
egy kln szoftver automatikusan tudja ellenrizni s kimutatni a tervezsi
hibkat, ellentmondsokat is. Az ilyen nyelvek elnevezse:
rendszerspecifikcis nyelv, vagy

formlis specifikcis nyelv.
A formlis lers legnagyobb elnye az, hogy lehetv teszi a tervezsi
folyamat helyessgnek szmtgppel segtett ellenrzst. A specifikci
s a vgtermk kztti fejlesztsi t tbb fzisbl ll. Az egyes fzisok
kztti tmenetet tbb esetben automatikus transzformci tudja biztostani. Ez azt jelenti, hogy egy tervezsi fzis eredmnye szolgl bemen
informciknt a soron kvetkez fzist megvalst tervezprogram
szmra, amely program talaktja a bemeneti reprezentcit az j fzis
kimeneti reprezentcijra. A folyamat nem minden esetben automatizlt
mg. Ekkor kls tervezi kzremkdsre kerl sor. Az talakts,
transzformci sorn szksg van annak bizonytsra is, hogy az j reprezentci ekvivalens az t megelzvel. Klnbz szoftver eszkzk
llnak rendelkezsre a bizonyts elvgzshez, vagyis a verifikcihoz, de
ezek jelenleg mg nem teszik lehetv a teljesen automatikus vgrehajtst,
vagyis itt is szksg van a tervez kzremkdsre. Vgl is a formlis
mdszerek hasznlata nem jr a tapasztalt tervezk munkjnak megtakartsval, viszont megvltoztatja a mrnki tevkenysg, dntshozatal
mdjt, formjt. A formlis megkzelts alkalmazsnak legfbb rtelme
abban van, hogy nagyobb megbzhatsggal teszi lehetv a tervezsi s
verifikcis folyamatok vgrehajtst. Mindezt az 5.14. brn szemlltet-
Vissza
114
Vissza
115
jk. Az brn lefel haladva a V-modell tervezsi ga valsul meg, felfel

haladva pedig az ellenrzsi, tesztelsi ga.
Formlis specifikci
Transzformci s ellenrzs
Verifikci
1. tervezsi fzis
Verifikci
2. tervezsi fzis
Verifikci
Vgs tervezsi fzis
5.14. bra. A formlis mdszerek alkalmazsnak folyamata
A formlis mdszerek egyarnt vonatkoznak a hardver-tervezsre s a

szoftver-tervezsre. A kt szfra egymssal prhuzamosan halad fejlesztsi folyamatt az 5.15. bra mutatja be.
Vissza
115
Vissza
116
Felhasznli
kvetelmnyek
Specifikls
Hardverspecifikls
Szoftverspecifikls
Hardvertervezs
Szoftvertervezs
Hardvermegvalsts
Szoftvermegvalsts
sszeintegrlt
rendszer
5.15. bra. A hardver s szoftver tervezsi s ellltsi folyamata
Ha a szoftver folyamatt tekintjk, lthatjuk, hogy az a specifikcis fzissal veszi kezdett. Ez transzlland t a szoftvertervbe, majd a terv a
szoftver-implementciba. Mivel a specifikci pontosan definilja, hogy
mit kell teljestenie a programnak, ezrt kivihetnek ltszik egy olyan fajta
fordtprogram ellltsa, amely a specifikcit kzvetlenl forrskdba
alaktja t. Ehhez teht egy olyan kompjlerra van szksg, amely a terve-
Vissza
116
Vissza
117
zsi specifikcit fogadja inputknt. A forrskd alapjn (pldul C nyelven) mr egy norml fordtprogram fogja generlni a megvalstott programot.
Ugyanez az t a hardver esetben is felvzolhat. Ekkor egy hardver
kompjler veszi inputknt a hardver-specifikcit, ebbl ellltja a szksges logikai terveket, a logikai kapcsolsi rajz formjban, ezt kveten a
fizikai terveket, mint pldul a nyomtatott huzalozs krtyk tervt, valamint a logikai elemeket realizl integrlt ramkrk (IC-k) layout-jnak
tervt.
Ismt megjegyezzk, hogy jelenleg mg messze vagyunk a fenti folyamatok teljesen automatizlt megvalststl, jllehet folyamatos fejlesztsi erfesztsek trtnnek ezen cl elrsre. Az itt sszegylt s jl bevlt
eszkzk mindenesetre kitn segtsget tudnak nyjtani a jl felkszlt
tervezmrnkk s szoftverfejlesztk szmra. A hardverben pldul
nagy jelentsgre tett szert az USA Vdelmi Minisztriuma ltal szabvnyostott VHDL nev hardver-ler s szimulcis nyelv (Hardware Description Language). A VHDL egy magas szint nyelv, amely kitnen
alkalmas a hardver logikai s idbeli mkdsi mdjainak definilsra.
Tbb jl bevlt silicon compiler (szilcium kompjler) ltezik mr, amely
az integrlt ramkrk tervt generlja a hardver-tervbl. A szoftverben
egyre inkbb terjedben van pldul az UML (Unified Modeling
Language, egysges modellez nyelv) felhasznlsa. Az UML az objektumorientlt szoftvertervezst tmogatja, grafikus megjelentssel prosulva. Az UML-t magban foglal Rational Rose elnevezs keretrendszer mr
tbb nyelvre, mint pldul C ++, JAVA, kpes forrskdot generlni.
Jllehet a formlis mdszerek alkalmazsa szmos fontos elnnyel jr,
a felhasznls ugyanakkor jelents mrtk megszortsokat is jelent a
tervezsi mdszerekre nzve. Tudvalev, hogy egy lnc erssgt a leggyengbb szeme hatrozza meg, ezrt a formlis bizonytsokat a fejlesztsi folyamat mindegyik llomsnl el kell vgezni annak rdekben, hogy a
maximlis hasznunk szrmazzon ebbl. Mindez komoly kihatssal van a
projekten bell alkalmazhat tervezsi mdszerekre is. A formlis bizonytsok vgrehajtsa ugyanakkor ersen tmaszkodik a matematikai technikkra, amitl sok mrnk idegenkedik. Ennek a gondnak a cskkentse
tovbbkpz tanfolyamok megtartst kveteli meg.
Vissza
117
Objektum-orientlt szoftvertesztels
Vissza
118
6. Objektum-orientlt
szoftvertesztels
Alapvet krds objektum-orientlt (OO) rendszerek tesztelsvel kapcsolatban, hogy lehet-e alkalmazni OO rendszerek vizsglatakor a nem OO
rendszerek tesztelsre hasznlt mdszereket. Termszetes vlasz lehet a
krdsre, hogy mirt ne lehetne, hiszen az OO programozsi paradigma is
a procedurlis nyelvek tovbbfejlesztseknt szletett meg. A C++ nyelv
pldul a C nyelv kiterjesztse, ugyan ma mr nem felttlenl generlhat
minden C++ kddal ekvivalens C kd, mint a nyelv kialakulsakor, azonban a nyelv megtartotta az alapvet utasts kszlett, csak jelentsen kiterjesztette azt.
A problmt egy kicsit kzelebbrl megvizsglva azonban sokkal bonyolultabb a kp. Egyazon szoftver problmnak OO, ill. nem OO krnyezetben trtnt megoldsa egymstl lnyegesen klnbzhet struktrjban s egyb tesztelhetsg szempontjbl fontos jellemzjben.
Ezek a klnbsgek egyrszt az OO tervezsi metodikbl, msrszt a
hasznlt OO nyelv (krnyezet) sajtossgaibl kvetkezhetnek.
A kvetkez fejezetben elszr rviden sszefoglaljuk, az OO rendszerek tesztelsi szempontbl fontos jellemzit. Bemutatjuk, hogy a nem
OO rendszerek tesztelshez hasznlt mdszerek OO rendszerek tesztelsre trtn alkalmazsakor milyen problmkkal kell szembenzni. Ezutn ismertetjk azokat a technikkat, amelyek segtsgvel megoldhatjuk
az ismertetett problmkat.
6.1. Az OO rendszerek jellemzi tesztelhetsgi
szempontbl
Az OO tpus tervezsnek, problmamegoldsnak kt olyan jellemzje
van, mely problmk forrsa lehet tesztelskor:
Problmk sztdarabolsa.
Adatrejts.
A OO krnyezetek sajtossga, hogy lehetsget ad a problmk sztdarabolsra, s a rszproblmk hierarchikus megoldsra. A OO tervezs
egyik alapideolgija, hogy igyekezznk a megoldand feladat elemzsvel
azt olyan kisebb egysgekre, rszfeladatokra osztani, amelyeket mr kny-
Vissza
118
Vissza
119
nyebben meg lehet oldani. Ennek eredmnye ltalban, hogy az OO rendszerek nagyszm, egymssal aktvan kapcsolatban lev, egyttmkd
komponensekbl llnak. A tesztelt rendszer ilyen jelleg felptse elssorban az izolcis (elhatrolsos) tesztels esetn lehet kedveztlen.
Az OO programozs msik jellemzje a komponensek jl definilt interfszen keresztl trtn elrse, s ezzel prhuzamosan a nem publikus
adatok s funkcik elrejtse. Az adatok s fggvnyek elrejtse a tesztels
sorn igen sok gondot okozhat, ha a szoftvernk mkdst meg szeretnnk figyelni, ill. irnytani szeretnnk, egy adott mkdsi llapotba szeretnnk juttatni.
A problmk tovbbi forrsai lehetnek nyelvi sajtsgok. Ilyen pl. a
C++-ban hasznlatos virtulis fggvnyek. Egy adott objektum osztly
virtulis fggvnyeit a leszrmaztatott osztlyban fll lehet definilni. Ha
egy flldefinilt virtulis fggvnyt hvok meg a szl osztlyra mutat
pointeren keresztl, akkor az adott pointer tpustl (ellettl) fggen
a szl osztly, vagy valamelyik gyermek osztly fggvnye fog tnylegesen meghvdni. Logikailag ezt gy tekinthetjk, mintha az adott helyen
egy specilis elgazs utasts lenne, mely a pointer tpustl fggen
klnbz vezrlsi gat, klnbz fggvnyt vlaszt. Az ilyen kdba
rejtett, implicit elgazsok kezelse igen nehz tesztels sorn.
Mindenkppen szt kell ejteni arrl, hogy az OO paradigmban szles
kren hasznlt polimorfizmus (egyazon kd hasznlati krnyezettl fgg rtelmezse) milyen hatssal van a tesztelsre. A fenti plda, a C++
virtulis fggvnyek kezelse is polimorfizmus, de sokkal egyszerbb pldkat is mondhatunk polimorfizmusra: template-ek hasznlata, azonos
nev fggvnyek paramterlisttl fgg meghvsa, szl osztlyban definilt fggvnyek flldefinilsa, ill. hasznlata. Ezek a nyelvi lehetsgek elssorban a tesztels alapossgnak mrsekor (lefedettsgi analzis)
okozhatnak problmt. A tesztels alapossgnak jellemzsekor a tesztel
rendszerek ltalban strukturlis mrtkszmokat (utasts lefedettsg, t
lefedettsg stb.) hasznlnak.
OO kd esetn ezeknek a mrtkszmoknak a kzvetlen hasznlata
igen megtveszt lehet. Vegynk egy nagyon egyszer pldt. Egy G
(gyermek) osztly egy S (szl) osztlybl szrmazik. Ttelezzk fel, hogy
van az S osztlynak egy F fggvnye, amit G nem definil fell. Ha G
osztlyt teszteljk, termszetesen teszteljk az F fggvnyt is, melynek
kdja az S osztlyban van definilva. Ha az S osztly kd lefedettsgt
vizsgljuk, akkor a G osztly tesztelse utn az S osztlybeli F fggvny
Vissza
119
Vissza
120
kdjt pl. az utasts lefedettsg mrtkszm lefedettnek fogja tekinteni.

Ez termszetesen nem jogos, mert az F fggvny meghvsa nem az S
osztly krnyezetbl, hanem a G osztly krnyezetbl trtnt.
Lthatjuk teht, hogy a procedurlis nyelvek tesztelsnl hasznlt
mrtkszmok vltozatlan hasznlata OO rendszerek tesztelsekor nem
fejezi ki helyesen a tesztels alapossgt. Ezrt egyrszt kidolgoztak az
OO rendszerek tesztelsnek alapossgnak jellemzsre alkalmas egyedi
mrtkszmokat, valamint a strukturlis tesztelskor hasznlt mrtkszmok OO rendszerekben hasznlhat vltozatt.
6.2. Tesztels nem OO rendszerekben
Az OO rendszerekben alkalmazott tesztelsi mdszerek ismertets eltt
rviden sszefoglaljuk a hagyomnyos, nem OO rendszerek tesztelsekor
hasznlt tipikus teszt krnyezetek mdszereket lerst, azok elnyeit.
A tipikus, hagyomnyos szoftverfejleszts procedurlis nyelven trtnik, top-down tervezsi metodika szerint. Az ilyen alkalmazsokat tipikusan n. dinamikus tesztelssel ellenrzik. Ksztenek egy teszt krnyezetet, melynek feladatai a kvetkezk:
bemenetek biztostsa a tesztelend szoftver (Software Under Test:

SUT) szmra,
SUT mkdtetse,
kimenetek, esetleges bels vltozk megfigyelse.
Az ilyen tesztelsi megkzelts mind modul, mind integrcis, mind
rendszer tesztels esetn jl hasznlhat.
A leggyakrabban hasznlt tesztelsi mdszer az elssorban modul
tesztelskor hasznlt izolcis tesztels. Ekkor a teszt krnyezet a fenti
feladatokon tl lehetsget ad a szoftver nem tesztelt rszeinek szimullsra n. csonkok definilsa formjban. A csonkok helyettestik a nem
tesztelt program fggvnyeit. A fggvnyek mkdsnek megfelelen a
csonkokat is meghvhatja a SUT, a klnbsg annyi, hogy a csonkok mkdse ismert s garantltan helyes. Helytelen mkds esetn a hiba a
SUT-ban van.
Az izolcis tesztels elnyei a kvetkezk:
A szoftver komponensei egyenknt is tesztelhetek, adott esetben mg
a tbbi rsz elkszlte eltt.
Vissza
120
Vissza
121
Tesztelhet elszr a komponensek bels mkdse, majd ezt kveten az interfszek.

A tesztkrnyezet egy adott szoftver egymst kvet verziiban jrahasznlhat.
A tesztels megfelel teszt krnyezet esetn jl automatizlhat.
Az izolcis tesztels htrnya, hogy a tesztelnek definilnia kell a csonkokat. Ezt a feladatot lnyegesen megknnytheti, ha olyan mdon lehet
az egy alkalommal tesztelt komponensek hatrait megvlasztani, hogy
kevs kapcsolata legyen a tesztelt rendszer tbbi komponensvel.
6.3. Hagyomnyos tesztelsi mdszerek
alkalmazsa OO krnyezetben
6.3.1. Izolcis tesztels
Az izolcis tesztels alkalmazsakor a legnagyobb gondot a krnyezet

kialaktsa jelenti. Az OO rendszerek mint emltettk tipikusan sok
egymssal szoros kapcsolatban lev komponensbl llnak. Ezrt nehz a
komponensekhez a teszt krnyezet elksztse, tl sok tbbletmunkt
ignyel a nagyszm csonk definilsa.
Problmt jelent a teszt krnyezet (csonkok) jrafelhasznlsa is. A
OO rendszerek elszeretettel hasznljk a megrt kdot tbbszr is (pl.:
rkls). A teszt krnyezet vltozatlan formban trtn jra-hasznlata
ltalban nincs lehetsg, az esetek tlnyom tbbsgben jelents tbbletmunkt ignyel az adaptci.
Az izolcis technikt ezrt ltalban nem gyakran hasznljk OO
rendszerek tesztelsekor. Ezzel szemben a bottom-up tesztelst, mely sok
vonatkozsban hasonl az izolcis technikhoz, annl tbbszr.
6.3.2. Bottom-up tesztels
A bottom-up tesztels esetn is a tesztel rszekre osztja a SUT-ot. Az

egyes nllan tesztelt rszeket azonban rtegeknek nevezzk, mert azok
rtegesen plnek egymsra. Legelszr a tesztel azokat a komponenseket, osztlyokat teszteli, amelyek nem fggenek ms osztlytl, nem hvnak semmilyen ms osztlybeli fggvnyt. Utna azok az osztlyok kvetkeznek, amelyek csak ettl az elszr tesztelt osztlytl fggenek. A csak
mr tesztelt osztlyra pl osztlyok tesztelse addig tart, mg az egsz
szoftvert le nem teszteltk.
Vissza
121
Vissza
122
A legnagyobb problmt a krkrs hivatkozsok jelentik, ha van olyan

csoportja az osztlyoknak, amelyek krkrsen hivatkoznak egymsra.
Ekkor vagy egyszerre teszteljk az sszes, krben szerepl osztlyt, vagy az
izolcis technikt hasznljuk, vagyis a hivatkozott osztlyok egy rszt a
teszt krnyezet segtsgvel (csonkok formjban) implementljuk.
sszefoglalva a bottom-up tesztels mdszernek elnye, hogy nem
kell csonkokat definilni. Htrnya, hogy egy adott rtegben lev komponensek bels mkdst, ill. a komponensek kztti interfszt egyszerre,
ugyanazon tesztesetekkel teszteljk. gy adott esetben nehz lehet a hiba
forrsnak lokalizlsa.
Tovbbi htrnya a bottom-up tesztelsnek, hogy nem tesztelhet egy
adott rteg viselkedse abban az esetben, ha az alatta lev rteg hibsan
mkdik, hiszen egy rteg tesztelse csak az alatta lev rtegek tesztelse
utn kvetkezik.
Elkpzelhet, hogy a szoftver szerencstlen felptse, a krkrs fggsek kvetkeztben nem oszthat megfelelen rtegekre. Emiatt a gyakorlatban gyakran hasznljk a bottom-up tesztelst kombinlva az izolcis technikval.
6.4. OO rendszerek tesztelsi techniki
OO rendszerek tipikus tesztelsi feladatainak megoldsra tbb technika
szletett ezek kzl ismertetjk a legfontosabbakat. Ezek a technikk ltalban a hagyomnyos (procedurlis nyelvi krnyezetben fejlesztett) szoftverek tesztelsre kidolgozott mdszerek alkalmazst teszik lehetv,
vagy knnytik meg OO krnyezetben.
6.4.1. Tesztelhetsgre tervezs
ltalnosan megllapthat, hogy OO rendszerek tervezsekor rdemes

figyelembe venni a tesztelhetsgi szempontokat, a szoftvert tesztelhetre
tervezni. A tesztelhetsg olyan ltalnos szempontokknt fogalmazhat
meg mint:
Kerlni kell a nem felttlenl szksges kapcsolatokat osztlyok kztt.
Lehetsget kell adni az adatok (bels vltozk) megfigyelsre, belltsra.
Kerlni kell a virtulis fggvnyek felesleges hasznlatt.
Vissza
122
Vissza
123
A fenti kittelek sajnos nagyon ltalnosak, s ami rosszabb, az OO programozs eszkztrt lnyegesen korltozzk. Az esetek nagy tbbsgben
a szablyok betartsa a kd hatkonysgnak cskkenshez, az OO tervezs elnyeinek elvesztshez vezetne. Ezrt a fenti szablyok betartsnak realitsa megkrdjelezhet.
A fenti ltalnos szablyoknl gyakorlati szempontbl gretesebb lehetsg az Absztrakt Bzis Osztlyok (ABO: Abstract Base Classes) hasznlata. Ennek a tesztelhetre tervezsi techniknak a lnyege, hogy az osztlyok interfszt egy kln osztlyban valstjk meg absztrakt (fggvnytrzs nlkli virtulis) fggvnyekknt. Ekkor ugyan a rendszerben lev
osztlyok szma megn, azonban knnyebben lehet az egyes osztlyokat
egymstl elhatrolni, s alkalmazni az izolcis technikt.
6.4.2. Wrapper osztlyok hasznlata
Mint korban mr emltettk, az OO rendszerekben nehzsget okoz az

objektumokban hasznlt rejtett adatok megfigyelse s belltsa. Ezt a
problmt lehet megoldani az n. wrapper (csomagol, kpeny) osztlyok
segtsgvel. A wrapper osztlyok hasznlatnak msik indoka, hogy megknnytik a tesztesetek dokumentlst.
A wrapper osztlyok tlete nagyon egyszer. Az egyes osztlyok bels
vltozi, fggvnyei nem elrhetek a klvilg szmra. A nyelvek tbbsge (pl.: C++, Java) lehetsget ad azonban egyes osztlyok kztti specilis viszony (friend) deklarlsra, ami lnyege, hogy a kt osztly kdjbl
elrhetv vlik a msik osztly bels vltozi s fggvnyei.
A wrapper osztlyok segtsgvel ezt a lehetsget hasznlhatjuk ki
tesztelsre. A tesztel krnyezetben minden osztlyhoz ltrehozhatunk
egy wrapper osztlyt, amely a deklarcik megfelel megadsval elrheti a
tesztelt osztly bels vltozit. Ekkor a wrapper osztlyban kszthetnk
fggvnyeket a bels vltozk megjelentsre, belltsra.
A wrapper osztlyok hasznlatnak msik clja, hogy a megfigyelse s
dokumentlsa a tesztelt rendszer mkdsnek. Ebben az esetben az
wrapper osztlyt a tesztelt osztllyal azonos interfsszel hozzuk ltre. A
tesztelt osztly tesztelsekor annak fggvnyei helyett mindig a wrapper
osztly fggvnyeit hvjuk meg.
A wrapper osztly adott fggvny meghvsakor dokumentlja a meghvs tnyt, a hvsi paramtereket, majd meghvja a tesztelt osztly eredeti fggvnyt. A fggvnyhvsbl trtn visszatrskor a wrapper
Vissza
123
Vissza
124
osztly megint csak dokumentlhatja, esetleg ellenrizheti a visszatrsi

rtkeket. A wrapper osztly hasznlatt mutatja 6.1. bra.
Class A
public
Class B
fggvny hvs
public
return
private
private
Wrapper Class B
Class A
public fggvny hvs
Class B
public
public
return
private
private
Teszt
dokumentci
6.1. bra. Wrapper osztlyok hasznlata a tesztesetek dokumentlsra

6.4.3. Tesztels llapot-tmeneti diagram alapjn
Az llapot tmeneti diagramm alapjn trtn tesztels az OO rendszerek

azon tulajdonsgt hasznlja ki, hogy az objektumok mkdse jl modellezhet egy llapot automatval.
Vissza
124
Vissza
125
Tesztelskor egyes osztlyok, ill. az osztlyokat megtestest objektumok mkdst egy-egy llapot automatval, ill. annak mkdst reprezentl llapottmenet diagrammal rjuk le. A tesztelt szoftver rendszer
reprezentcija a hozz tartoz objektumokat ler automatk halmaza lesz.
Az egyes objektumokhoz tartoz automatk kapcsolatt, a teljes rendszer mkdst egy rendszer szint llapot automatval rhatjuk le. Az
globlis rendszer a kls hatsokra, a bemenetekre ad vlaszokat. A bemeneteket a rendszer szint automata fogadja, s tovbbtja az egyes objektumok, vagyis az ket reprezentl automatk fel. Az egsz rendszer
gy esemnyvezrelten mkdik, a bemenetek hatsa vgig szalad az egsz
rendszeren.
kls esemny
vlasz
szl
receptor
emitter
tesztelt rendszer hatra

komponens osztlyok
llapot modelljei
6.2. bra. Esemny terjedse
llapot-tmeneti automata alapjn trtn tesztelskor
Ltezik llapot-tmeneti diagram alapjn trtn tesztelst tmogat rendszer, melyben egyszeren definilhatak az automatk, s kvethet a
rendszer mkdse.
6.5. Mrtkszmok hasznlata
Mint mr emltettk, a strukturlis mrszmok hasznlata OO rendszerek tesztelse esetn torz mrsi eredmnyt eredmnyezhet. Ennek a
problmnak megoldsra egyrszt definiltak specilisan OO rendszerek
tesztelsnek alapossgt jl jellemz mrszmokat, msrszt kidolgoz-
Vissza
125
Vissza
126
tk egy a strukturlis mrszmok szmolsnak OO rendszerek tesztelsekor hasznlhat mdszert. Ezeket a szrmaztatott mrtkszmokat
nevezzk krnyezetfgg mrtkszmoknak.
Elssorban OO szoftvertesztelshez definilt mrtkszmok:
Belpsi pont lefedettsg Entry point coverage.
Klcsns hvs lefedettsg Call-pair coverage.
Krnyezetfgg mrtkszmok:
rklsfgg lefedettsg Inheritance context coverage
llapotfgg lefedettsg State based context coverage
Szlfgg lefedettsg Thread based context coverage
6.5.1. Belpsi pont fedettsg Entry point coverage
Objektum-orientlt rendszerek elssorban integrcis funkcionlis tesztelsnl hasznlt mrszm. Azt mutatja meg, hogy egy adott objektum
publikus interfszben definilt fggvnyek mekkora hnyadt hvtuk meg
a tesztels folyamn. A mrtkszm elnye, hogy alkalmas az esetlegesen
nem megvalstott, gy nem felhvhat fggvnyek feldertsre.
6.5.2. Klcsns hvslefedettsg Call-pair coverage
ltalban integrcis tesztelsnl hasznlt mrszm. Arnyszm, ami

megadja, hogy kt objektum kztt lehetsges fggvnyhvsok mekkora
hnyada kerlt tnylegesen meghvsra a teszt vgrehajtsa sorn. Ugyan
azon fggvny klnbz kdrszletekbl trtn hvsait megklnbzteti.
6.5.3. Krnyezetfgg mrtkszmok
A strukturlis mrtkszmok OO krnyezetben, mint lttuk, nem szolgltatnak megfelel tmpontot a tesztels alapossgra vonatkozan. A f
problma abbl addik, hogy a kd jrahasznlsa, ill. a polimorfizmus
miatt egy adott kdrszlet (adott FVG-beli g, csompont, t stb.) a program klnbz helyeirl, klnbz (program) krnyezetbl meghvhat.
A meghvott kd mkdse fgghet a meghvsi (aktivizlsi) krnyezettl, gy az alapos tesztelshez hozztartozik az adott kdrszlet minden
lehetsges krnyezetbl trtn meghvsa, tesztelse.
A krnyezetfgg mrtkszmok pontosan ezt oldjk meg. Minden
hagyomnyos strukturlis mrtkszmbl szrmaztathatunk krnyezet
Vissza
126
Vissza
127
fgg mrtkszmot, radsul tbbet is attl fggen, hogy a kd hvsi

(aktivizlsi) krnyezetnek milyen jellemzjt vesszk figyelembe.
Ha a tesztelskor az osztlyhierarchit vesszk figyelembe mint krnyezetet, akkor az n. rklt kd lefedettsgi (inheritance context
coverage) mrtkszmokat kapjuk. Az rklt kd lefedettsg szmtsa
szempontjbl egy rklt fggvny meghvsa klnbzik, ha a szl s
ha a gyerek osztlybl hvdik meg.
6.5.4. rklsfgg dnts lefedettsg Inheritance context
decision coverage
A dnts lefedettsg rklt kd lefedettsg alapjn szmolt krnyezet

fgg mrtkszm vltozata. Szmtsnak menete:
I(c)=i/I.
Ahol i egyenl a teszt sorn vgrehajtott elgazsok szmnak sszegvel,
olyan mdon szmolva, hogy a klnbz elgazsok bejrst (dntsek
meghozatalt) objektum krnyezetenknt megklnbztetjk. I az elgazsok sszes szma megszorozva az elgazsra hivatkoz krnyezetek
szmval.
6.5.5. llapotfgg lefedettsg State based context coverage
Olyan krnyezet fgg mrtkszm csoport, ahol a hvsi krnyezet

figyelembevtelekor nem csak a hv objektum tpust, hanem annk
aktulis llapott is figyelembe vesszk. Ezeket a mrtkszmokat az llapot-tmenet diagramm alapjn trtn tesztels sorn hasznljk.
6.5.6. Szlfgg lefedettsg Thread based context coverage
Tbbszl alkalmazsok tesztelse esetn lehetnek hasznosak, amikor a

mrtkszm szmtsakor a hv szl azonostjt is figyelembe vesszk. A
szlak azonos kzs kdot hajtanak vgre, tesztelsi szempontbl fontos,
hogy egy adott kdrszlet melyik szl krnyezetben kerlt vgrehajtsra.
A mrtkszm gy viselkedik, mintha a klnbz szlaknak kln kdja
lenne, s annak lefedettsgt mrnnk.
6.6. Konkrt tesztel rendszerek
6.6.1. Cantata++
A Cantata++ C++ nyelv szoftverek egysg s integrcis tesztjeihez

hasznlhat A teszteket a felhasznl ltal rt scriptek vezrlik. A teszt a
Vissza
127
Vissza
128
tesztelend forrskd, a teszt script s a Cantata++ Test Harness fordtsval, ill. linkelsvel keletkez futtathat program, mely futtatva egy
teszteredmny fjlt hoz ltre. Az gy keletkezett program lehetv teszi a
teszt futtatst, dokumentlst s megismtlst. A Cantata++ teszt
scriptek C++ nyelven rdnak s tulajdonkppen egy main fggvnybl
llnak, ami vgrehajtja a tesztelend szoftveregysget. Egy SM Tool
nev egysg lehetv teszi, hogy a Test Harness s ezen az interfszen
keresztl a teszt script hozzfrhessen a tesztelend egysg implementcija ltal elzrt olyan rszletekhez, mint adat elemek s ms egysgek fel
irnyul interfszek. Ez az egysg vgzi a forrskd bemszerezst, mely
C++ friend deklarcik s wrapping formjban jelentkezik. A csonkok
(stub) rsa a felhasznlra marad, de megadhat, hogy tesztelskor az
egyes meghvsokkor milyen visszatrsi rtkei legyenek a szimullt fggvnynek. A teszt scriptekben ellenrizhetk az adatelemek rtkei ill. ellenrizhetk azok az adatterletek melyek rtkeinek nem szabad vltozniuk a teszt futsa alatt. A Cantata lehetv teszi hogy mrjnk klnbz
vgrehajtsi idket s sszehasonltsuk ket meghatrozott kvetelmnyekkel. A Cantata++ biztost eszkzket arra, hogy a leszrmaztatott
osztlyok tesztelsre teszteket szrmaztassunk le az alap osztly tesztjeibl (parallel inheritance hierachy). A bemszerezs elltja a kdot teszt
lefedettsgi metrikk meghatrozshoz szksges adatgyjt rszekkel. A
kvetkez lefedettsgi metrikk mrhetk: statement coverage, decision
coverage, boolean expression coverage, call-pair coverage, call coverage,
modified condition coverage. A Cantata rendelkezik egy statikus analiztorral is, mely kd metrikk meghatrozsra alkalmas, pl. a Halstead-fle
szoftver metrikk, a McCabe-fle ciklomatikus metrikk, nyelvi konstrukcik szma sorok szma, megjegyzsek, fggvny paramterek stb.
Meghatrozhatk klnbz objektum orientlt szoftver metrikk is, pl.
Chidamber s Kremerer metrikk, osztly entrpia metrikk stb.
6.6.2. SGI Tester
A Tester az sgi ProDev debugger-csomag dinamikus teszt lefedettsg analzis eszkze. A Tester nem biztost egy komplett tesztvgrehajt krnyezetet, csupn a vgrehajthat kd specilis bemszerezsre szolgl, teszt
lefedettsgi adatok gyjtsre, s lehetv teszi ezen adatok grafikus felleten val elemzst. C, C++ s Fortran programokhoz hasznlhat. A
folyamat a kvetkez: a felhasznl definilja, hogy milyen kd moduloknl milyen jelleg lefedettsgi adatokat kell gyjteni. A rendszer ez alapjn
Vissza
128
Vissza
129
generl egy specilis vgrehajthat fjlt, melyet futtatva lehet elvgezni a

tesztelst. A tesztels vgeztvel rendelkezsre llnak a lefedettsgi adatok,
melyek elemzshez a ProDev rendszeren bell specilis grafikus megjelentk tartoznak. Az alkalmazhat lefedettsgi metrikk: forrs sor lefedettsg, function entry point coverage, arcs (call-pair) coverage, decision
coverage, block coverage. A rendszer script nyelve lehetv teszi olyan
parancssor orientlt programok automatizlt tesztelst, melyek viselkedst indtsukkor megszabhatjuk.
6.6.3. Aprobe
Az Aprobe egy tesztel, debuggol s teljestmny-optimalizl rendszer.

Az ltala alkalmazott mszerezsi eljrs abban klnbzik a szoksos
tesztel krnyezetektl, hogy a tesztelend programot a forrskd jrafordtsa s linkelse nlkl teszi alkalmass a tesztelsre. Az Aprobe minimlisan mdostja csak az eredeti program mkdst s gy alkalmas
real-time alkalmazsok egysg s integrcis tesztelsre is. A tesztelend
program s a mszerezs interakcija csak a teszt vgrehajtsakor kezddik. A mszerezst n. prbk rsval vgezhetjk. A prbk az eredeti
vgrehajthat kddal mint patch-ek egy dynamic action linking nev
eljrssal kerlnek kapcsolatba. Mivel a tesztelend alkalmazs teljesen
sztvlik a prbktl ezrt knny nll, jra felhasznlhat prbkat
kszteni. Bizonyos tesztmrsek, metrikk meghatrozsa elvgezhet a
forrskd nlkl is, ms ltal fejlesztett rendszereken. Amennyiben a vgrehajthat kd tartalmaz debug informcikat, amely sszekti a forrssal
(nem szksges rendelkeznnk a forrskddal), akkor prbinkban hivatkozhatunk a forrs terminolgijra. A prbkat egy C-szer script nyelven lehet megrni. Tartalmazhatnak sajt vltozkat, hozz frhetnk a
tesztelt program sajt vltozihoz, mrhetnk vgrehajtsi idket (teljestmnytesztels), fggvnyek ki- s belpsi pontjain mdosthatjuk a
bemen paramtereket, ill. a visszatrsi rtket. Ez utbbiak segtsgvel
lehetsgnk van hiba injektlsra, stressz tesztelsre vagy hibajavtsi
elkpzelsek kiprblsra. Aprobe prbkkal elllthatunk teszt
lefedettsgi metrikkat s hasznlhatjuk optimalizlsi profil ksztsre is.
Mivel a script nyelv egy teljes programozsi nyelv, ltrehozhatunk vele
automatizlt tesztelsre alkalmas krnyezetet.
Vissza
129
Felhasznlt irodalom
Vissza
130
Felhasznlt irodalom
Alka Jarvis, Vern Crandall: Inroads to Software Quality. Prentice-Hall, Inc.,
USA, 1997.
sten Oskarsson, Robert L. Glass: An ISO-9000 Approach to Building
Quality Software. Prentice-Hall, Inc., USA, 1996.
IEC-1025: International Standard: Fault Tree Anlysis (FTA), Geneva,
International Electrotechnical Commission, 1990.
IEC-65A Secretariat 122: Software for Computers in the Application of
Industrial Safety-Related Systems, Draft Document, Geneva,
International Electrotechnical Commission, 1991.
IEC-1508: Draft International Standard: Functional Safety: Safety-Related
Systems, Geneva, International Electrotechnical Commission, 1995.
European Standard EN-50128, Final Draft, Railway Applications: Software for Railway Control and Protection Systems, CENELEC:
European Committee for Electrotechnical Standardization, 1997.
European Standard EN-50129, Draft, Railway Applications: Standard for
Acceptance and Certification of Safety-Oriented Electronic Systems in
Railway Control, CENELEC: European Committee for Electrotechnical Standardization, 1995.
Ian Sommerville: Software Engineering. Sixth Edition, Addison-Wesley
Publishing Company, Inc., USA, 2001.
Roger S. Pressman: Software Engineering. McGraw-Hill Book Company,
USA, 1997.
David E. Avison, Hanifa U. Shah: The Information Systems Development
Lifecycle: A First Course in Information Systems. McGraw-Hill Book
Company, Great Britain, 1997.
Glenford J. Myers: The Art of Software Testing. John Wiley & Sons, Inc.,
New York, 1979.
B. Chandrasekaran, S. Radicchi (Editors): Computer Program Testing. NorthHolland Publishing Company, Amsterdam, 1981.
Cem Kaner, Jack Falk, Hung Quoc Nguyen: Testing Computer Software. Van
Nostrand Reinhold, Inc., New York, 1993.
Boris Beizer: Black-Box Testing, Techniques for Functional Testing of Software and
Systems. John Wiley & Sons, Inc., New York, 1995.
Software Testing, IPL Information Processing Ltd., Bath, United Kingdom,
1996.
Vissza
130
Felhasznlt irodalom
Vissza
131
Simeon C. Ntafos: A Comparison of Some Structural Testing Strategies. IEEE

Transactions on Software Engineering, pp. 868-874, June, 1988
Nancy G. Leveson: Safeware: System Safety and Computers. Addison-Wesley
Publishing Company Inc., USA, 1995.
Felix Redmill, Tom Anderson (Editors): Safety-Critical Systems. Current
Issues, Techniques and Standards, Chapman & Hall, London, 1993.
Neil Storey: Safety-Critical Computer Systems. Addison-Wesley-Longman,
Inc., New York, 1996.
Dhiraj K. Pradhan: Fault-Tolerant Computer System Design. Prentice-Hall,
Inc., USA, 1996.
Harlan D. Mills: Zero Defect Software: Cleanroom Engineering. Advances in
Computers (Editor: Marshall C. Yovits), Vol. 36, pp. 141, Academic
Press, Inc., San Diego, 1993.
Marvin V. Zelkowitz: Role of Verification in the Software Specification Process.
Advances in Computers (Editor: Marshall C. Yovits), Vol. 36, pp. 43
109, Academic Press, Inc., San Diego, 1993.
Jzsef Sziray: Verification and Validation of Software Systems. Research Study,
Szchenyi University, Gyr, 2001.
Constance Heitmeyer, Dino Mandrioli (Editors): Formal Methods for RealTime Computing. John Wiley & Sons, Inc., New York, 1996.
Jean-Michel Berg, Oz Levia, Jacques Rouillard: Hardware/Software CoDesign and Co-Verification. Kluwer Academic Publishers, Dordrecht,
The Netherlands, 1997.
Nicolas Halbwachs, Doron Peled (Editors): Computer Aided Verification.
Lecture Notes in Computer Science, Vol. 1633, Springer-Verlag, Berlin, 1999.
Pter Arat, Tams Visegrdy, Istvn Jankovits, Szabolcs Szigeti: HighLevel Synthesis of Pipelined Datapaths. Panem Publishing Ltd., Budapest,
2000.
Pataricza Andrs, Majzik Istvn, Csertn Gyrgy, Bartha Tams: Formlis
mdszerek az informatikban. Jegyzet, 185 old., Budapesti Mszaki Egyetem, 2000.
Z. Navabi: VHDL: Analysis and Modeling of Digital Systems. McGraw-Hill
Sudhakar Yalamanchili: VHDL: Starters Guide. Prentice-Hall, Inc., USA,
1998.
Richard S. Wiener, Lewis J. Pinson: The C++ Workbook. Addison-Wesley
Vissza
131
Felhasznlt irodalom
Vissza
132
Kondorosi Kroly, Lszl Zoltn, Szirmay-Kalos Lszl: Objektum-orientlt

szoftverfejleszts. Computer Books Kiadi Kft., Budapest, 1997.
Martin Fowler, Kendall Scott: UML Distilled: Applying the Standard Object
Modeling Language. Addison-Wesley-Longman, Inc., USA, 1997.
Mark Priestley: Practical Object-Oriented Design with UML. McGraw-Hill
Publishing Company, Great Britain, 2000.
Shel Siegel: Object-Oriented Software Testing. John Wiley & Sons, Inc., New
York, 1996.
Balzs Beny, Jzsef Sziray: Testing Principles for Object-oriented Software.
Research Study, Szchenyi University, Gyr, 2001.
Vissza
132

SW Minosegbizt

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SW Minosegbizt

Transféré par

Droits d'auteur :

Formats disponibles

Dr.

Kszlt a HEFOP 3.3.1-P.-2004-09-0102/1.0 plyzat tmogatsval.

Szerzk: Dr. Sziray Jzsef

Kattintsunk a tartalomjegyzk megfelel pontjra, ezzel az adott fejezet

A dokumentumban val keresshez hasznljuk megszokott mdon a

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

lesztsi folyamatot vgigkveti, a specifikci megadstl a ksz rendszer

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

lata tartozik, mg a msikba a programok bels struktrjnak alapjn trtn vizsglatok.

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A minsggy kzponti fogalma az igny-kielgtsi folyamat minsge. A

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

Az igny-kielgtsi folyamat, ezen bell elssorban a termelsi folyamat

Az igny-kielgtsi folyamat minsgnek trsadalmi rtelmezse szintn

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A j minsg ngyfle kvetelmny egyenslya (J. Cons megfogalmazsban):

mszaki (fizikai, kmiai, biolgiai stb.) (technical)

Cons rtelmezse a megfelelsgre, a trsadalmi rdekekre, a fogyaszti s

A minsg, szubjektv volta miatt nehezen mrhet. A mrs nehzsgt a

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

tlyba sorolhatk: az egyik az ellenrz metrika (control metrics), a msik

2.1. bra. Prediktor s ellenrz metrikk

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

kapcsolatot, azonban a kapcsolat milyensgrl nem mond semmit. Ahhoz,

2.2. bra. Lehetsges kapcsolatok

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

2.3. bra. A termk mrsnek folyamata

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

Ilyen metrikkat hasznlnak tervezs, valamint program s dokumentci

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

ahol, a length a hosszsgnak egy mrtke, ami lehet pl. a programkd

A programnak hibamentesnek valamint karbantarthatnak kell lennie. A

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

J programozsi stlusban mindig jelentssel br azonostkat hasznlnak.

A szoftverhez kapcsold dokumentci minsge legalbb olyan fontos,

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

a program kd tulajdonsgai, amelyek a program fellvizsglatval felfedezhetk.

Megbzhatbb szoftvert eredmnyez, ha formlis mdszereket hasznlunk

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

Azonban a formlis specifikci mg nem garantlja, hogy a gyakorlati

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom

A dokumentum hasznlata | Tartalomjegyzk | Felhasznlt irodalom