Informatika | Tesztelés, Minőségbiztosítás » Sziray-Benyó - Szoftver-minőségbiztosítás

Dr. Sziray József Dr. Benyó Balázs Heckenast Tamás SZOFTVERMINŐSÉGBIZTOSÍTÁS Készült a HEFOP 3.31-P-2004-09-0102/10 pályázat támogatásával Szerzők: Dr. Sziray József Széchenyi István Egyetem, Informatika Tanszék Dr. Benyó Balázs Széchenyi István Egyetem, Informatika Tanszék Heckenast Tamás Széchenyi István Egyetem, Informatika Tanszék Lektor: Gaul Géza Széchenyi István Egyetem, Informatika Tanszék Szerzők, 2007 Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom A dokumentum használata Vissza ◄ 3 ► A dokumentum használata Mozgás a dokumentumban A dokumentumban való mozgáshoz a Windows és az Adobe Reader megszokott elemeit és módszereit használhatjuk. Minden lap tetején és alján egy navigációs sor található, itt a megfelelő hivatkozásra kattintva ugorhatunk a használati útmutatóra, a tartalomjegyzékre, valamint a tárgymutatóra. A ◄ és a ► nyilakkal az

előző és a következő oldalra léphetünk át, míg a Vissza mező az utoljára megnézett oldalra visz vissza bennünket. Pozícionálás a könyvjelzőablak segítségével A bal oldali könyvjelző ablakban tartalomjegyzékfa található, amelynek bejegyzéseire kattintva az adott fejezet/alfejezet első oldalára jutunk. Az aktuális pozíciónkat a tartalomjegyzékfában kiemelt bejegyzés mutatja. A tartalomjegyzék használata Ugrás megadott helyre a tartalomjegyzék segítségével Kattintsunk a tartalomjegyzék megfelelő pontjára, ezzel az adott fejezet első oldalára jutunk. Keresés a szövegben A dokumentumban való kereséshez használjuk megszokott módon a Szerkesztés menü Keresés parancsát. Az Adobe Reader az adott pozíciótól kezdve keres a szövegben A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 3 ► Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom

Tartalomjegyzék Vissza ◄ 4 ► Tartalomjegyzék 1. Bevezetés 6 2. Szoftver–minőségbiztosítás 9 2.1 Minőségi koncepciók 9 2.2 Minőségbiztosítási fogalmak 11 2.3 Szoftverminőség (Software quality) 11 2.4 Szoftver-mérőszámok (metrikák) 12 2.5 Szoftver-megbízhatóság 19 3. Biztonságkritikus rendszerek 22 3.1 Alapfogalmak 22 3.2 Minőségi és megbízhatósági követelmények 23 3.3 Rendszerstruktúrák 27 3.4 A hardver redundancia megvalósítása 29 3.5 A szoftver redundancia megvalósítása 31 3.6 Az ELEKTRA típusú vezérlőrendszer felépítése és működése 35 4. Szoftver-tesztelési módszerek 42 4.1 Tesztelési alapfogalmak 42 4.2 Hibamodellek és érvényességi körük 43 4.3 A tesztek megtervezése 45 4.4 A programtesztelés pszichológiája és gazdaságossága (Glenford Myers elvei). 47 4.5 Funkcionális tesztelés 53 4.6 Strukturális tesztelés 63 4.7 Tesztminőségi mérőszámok 71 4.8 A módszerek összekapcsolása 75 5.

Tesztelési stratégiák és folyamatok 76 5.1 Szoftverfejlesztési modellek 77 5.2 Verifikáció és validáció 85 5.3 A verifikáció és a validáció fázisainak tervezése 88 5.4 Egységek, modulok tesztelése 91 5.5 Integrációs tesztelés és rendszertesztelés 101 5.6 Validációs tesztelés 105 5.7 A tesztelés költsége108 A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 4 ► Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Tartalomjegyzék Vissza ◄ 5 ► 5.8 Bizonylatolás111 5.9 A formális módszerek szerepe 113 6. Objektum-orientált szoftvertesztelés 118 6.1 Az OO rendszerek jellemzői tesztelhetőségi szempontból 118 6.2 Tesztelés nem OO rendszerekben 120 6.3 Hagyományos tesztelési módszerek alkalmazása OO környezetben .121 6.4 OO rendszerek tesztelési technikái 122 6.5 Mértékszámok használata 125 6.6 Konkrét tesztelő rendszerek127 Felhasznált

irodalom .130 A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 5 ► Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Bevezetés Vissza ◄ 6 ► 1. Bevezetés Az informatikában hatalmas fejlődés ment végbe az elmúlt negyedszázadban. Aki ezt szakmailag végigélte, szinte már maga sem tudja elhinni, ami a 25 évvel ezelőtti világban volt. A fejlődés pontosan nyomon követhető a számítógépek és számítógép-hálózatok hardverének vonalán. Ez a műszaki, tervezéstechnológiai és gyártástechnológiai fejlődés megkérdőjelezhetetlenül impozáns A nyomon követhetőség elsősorban annak köszönhető, hogy a hardver előállítási folyamatai szigorúan kötött, meghatározott rendben, jól bevált, kitapasztalt folyamatokba szorítva mehetnek végbe. A be nem vált vagy túl drága új technológiák, irányzatok igen hamar kiszorulnak a piacról, és feledésbe

merülnek. Ilyenek voltak például a buborékmemóriák, vagy a küszöb logikán alapuló digitális áramkörök Az informatikai rendszerek másik szerves összetevője a szoftver. Ami azt illeti, a szoftver vonalon végbement fejlődés még döntőbben számít bele a mai helyzet kialakulásába. Ezen a téren sokkal kevesebb volt a kötöttség, mint a hardvernél A fejlesztésbe jóval szélesebb rétegek tudtak és tudnak ma is bekapcsolódni. Ezen túl még olyan országok is, mint Magyarország például, amelyek a hardverfejlesztésbe nem tudnak beleszólni Az itt munkálkodó szakemberek száma rohamosan növekszik, nagyon sok a szerteágazó egyedi fejlesztés, még akkor is, ha ugyanazon a hardver platformon mennek végbe. A fejlesztés nagyobb szabadságfoka teszi lehetővé a szoftver rendszerek beláthatatlan mértékű kibontakozását, fejlődését, ami a méretekben, vagyis az utasítások számában, valamint a bonyolultságban és az ehhez kapcsolódó

teljesítményben nyilvánul meg. A nagy szabadságfok, valamint az egyedi fejlesztés és a növekvő bonyolultság ugyanakkor megnöveli a veszélyét annak, hogy a szoftver rendszer hibásan működik. A hiba adódhat a specifikáció során elkövetett tévedésből, vagy aminek nagyobb az esélye, a programozás során elkövetett tévedésből. A hibák kiszűrése és kijavítása a fejlesztés előrehaladtával egyre nagyobb ráfordítást igényel Az ilyen ráfordítás mértéke exponenciálisan növekszik. Ezért nagy jelentősége van annak, hogy a fejlesztési folyamatokat minél szigorúbb technológiai rendben, minél alaposabban megtervezve és kivitelezve hajtsuk végre. A szoftver rendszerek megbízható üzemeltetése, felhasználása tehát szigorú követelményeket támaszt a fejlesztésükre vonatkozóan. Ebbe szorosan beletartozik az a minőségbiztosítási technológia, amely a teljes fej- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom

Vissza ◄ 6 ► Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Bevezetés Vissza ◄ 7 ► lesztési folyamatot végigköveti, a specifikáció megadásától a kész rendszer üzembe helyezéséig. A minőségi és megbízhatósági követelmények kielégítése szükségessé teszi azt, hogy a szoftvert ún verifikációs és validációs eljárásoknak vessük alá A verifikációban az egyes fejlesztési fázisok közötti összhang ellenőrzése a feladat, míg a validációval a végső rendszer ellenőrzésére kerül sor, annak eldöntésére, hogy az mennyire felel meg a felhasználó által előírt követelményeknek. A verifikálási-validálási tevékenység pontos végrehajtása a következő főbb előnyökkel jár: • Segít annak eldöntésében, hogy elkezdhetjük-e a fejlesztés soron következő fázisát. • A fejlesztési folyamat korai szakaszában mutathat ki problémákat, hibákat. • A

szoftver minőségére vonatkozóan mindvégig támpontokat, adatokat szolgáltat. • Kimutathatja már korán azt is, hogy a szoftver nem teljesíti a követelményeket. Mindez a szoftver előre megtervezett ellenőrzésével, intenzív tesztelésével kell hogy járjon az egyes fázisokban. Ebben a könyvben azokkal a témákkal, módszerekkel foglalkozunk, amelyek a szoftverfejlesztés minőségbiztosításához kapcsolódnak, beleértve a fejlesztési fázisokat kísérő tesztelési, verifikálási műveleteket, másrészt pedig a kész rendszerek átvételével kapcsolatos validálási műveleteket. A könyv 2. fejezete a szoftver-minőségbiztosítás általános kérdéseivel, az alapvető koncepciók és fogalmak ismertetésével foglalkozik. A 3. fejezet az ún biztonságkritikus rendszereket tárgyalja Az ilyen informatikai rendszereknél a legfontosabb kritérium a biztonságot megkövetelő működés, üzemelés. A fejezetben a biztonságkritikus rendszerek

tulajdonságait, a rájuk vonatkozó minőségi és megbízhatósági követelményeket, valamint a megvalósításban alkalmazott rendszerstruktúrákat foglaljuk össze. A 4. fejezet a legfontosabb szoftver-tesztelési módszereket vonultatja fel. Ezen belül bemutatja a figyelembe vett szoftver-hibák körét, valamint a hibák felfedésére alkalmazható teszttervezési megoldásokat. Mint ismeretes, a módszerek lényegében két csoportba sorolhatók: Az egyik csoportba a működő program külső funkcionális megnyilvánulásainak vizsgá- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 7 ► Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Bevezetés Vissza ◄ 8 ► lata tartozik, míg a másikba a programok belső struktúrájának alapján történő vizsgálatok. Az 5. fejezet a tesztelési stratégiákat és az ezeket megvalósító folyamatokat tárgyalja Minderre a

rendszerfejlesztési és felhasználási folyamat életciklusa fázisainak bemutatásával együtt kerül sor. A fejezet foglalkozik a verifikáció és a validáció végrehajtásával, az egységek és modulok tesztelésével, a modulok összeintegrálása során alkalmazandó teszteléssel, majd a teljes rendszer tesztelésével, ill. validálásával A 6. fejezet az objektum-orientált szoftverek ellenőrzésének megközelítési módjait, megoldásait foglalja össze Az objektum-orientált fejlesztés az osztály szintű tesztelést, valamint az osztályok közötti tesztelést követeli meg. Itt felhasználhatók mindazok a megoldások, amelyek a hagyományos fejlesztésű (ún procedurális típusú) szoftverekhez alkalmasak, de ezen túlmenően számos olyan módszerre is szükség van, amelyek kifejezetten az objektum-orientált szoftverekhez kapcsolódnak. A könyv végén a felhasznált irodalom felsorolása található. A dokumentum használata | Tartalomjegyzék |

Felhasznált irodalom Vissza ◄ 8 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 9 ► 2. Szoftver–minőségbiztosítás 2.1 Minőségi koncepciók A minőség tágabb értelemben az emberiség történelmével egyidős, azonban korszerű értelmezése a múlt század elején jelent meg, az ipari termelés elterjedésével. A minőség és a minőségügy igazi értelmezése csak napjainkban alakul ki A korszerű minőségfogalom a termelésben és a fogyasztásban érdekelt személyek, ill a társadalom értékítélete arra, hogy a termelési-fogyasztási folyamat mennyire elégíti az igényeket Ebből következően a minőség érték. A minőségügy a termelési-fogyasztási folyamat minőségének szabályozásával foglalkozik Napjainkban egyre nagyobb hangsúly fordítódik a minőségbiztosításra, azaz a termelés és a fogyasztás magas színvonalú

minőségére, amely a fogyasztóvédelem, és a fogyasztói igények kielégítése mellett a termelő nyereségét is eredményezi. Mindez nem csak a vállalkozás gazdasági felemelkedését jelenti, hanem hasznos a társadalom számára is. 2.11 A minőség filozófiai értelmezése A minőségügy központi fogalma az igény-kielégítési folyamat minősége. A minőség filozófiai szempontból kétféleképpen értelmezhető: általános, és értékszemléletben. • A minőség általános filozófiai értelmezése a dolgok tulajdonságokkal történő leírása. • A minőség értékszemléletű filozófiai értelmezése szubjektív, értékrenden alapuló, személyhez kötött. A minőség értelmezéséhez meg kell fogalmazni a vizsgálati szempontokat, meg kell mérni a tulajdonságok értékét, meg kell határozni az értékrendet, és meg kell adni az objektum minőségét (ez az értékrend alapján az objektumra vonatkozó értékítélet, minősítés). 2.12 A

minőség fogyasztói értelmezése Az igény-kielégítési folyamat, ezen belül elsősorban a termék és a fogyasztási folyamat minőségének fogyasztói értelmezése a minőség értékszemléletű filozófiai értelmezésén alapul. A fogyasztási folyamat minőségét a fogyasztó szempontjából azok a funkciók határozzák meg, amelyek alkalmassá teszik a terméket a fogyasztás során a fogyasztó által igényelt funk- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 9 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 10 ► ciók kielégítésére, vagyis biztosítják a fogyasztási folyamat megfelelő minőségét. Ez másképp a termék hasznosságának is nevezhető A fogyasztói minőség sok mindenre kiterjed, így a fogyasztási cikkek esetén a tényleges fogyasztási igények mellett tartalmazza többek között a

címkézés, a csomagolás, a tárolhatóság, a megismerhetőség, a használhatóság, a karbantarthatóság, a szerelhetőség, a tartalékalkatrész-ellátás, a szervízellátás és a garancia kérdéskörét. 2.13 A minőség termelői értelmezése Az igény-kielégítési folyamat, ezen belül elsősorban a termelési folyamat minőségének termelői értelmezése a minőség értékszemléletű filozófiai értelmezésén alapul. Az igény-kielégítési folyamat termelői minősége tehát attól függ, hogy a termelési folyamat és a termék a termelői érdekeltek szempontjából megfelelő-e, így a termelés folyamata az érdekeltek számára hasznos-e, gazdaságos-e, kellően veszélytelen-e. 2.14 A minőség társadalmi értelmezése Az igény-kielégítési folyamat minőségének társadalmi értelmezése szintén a minőség értékszemléletű filozófiai értelmezésén alapul. Az igénykielégítési folyamat társadalmi minősége tehát attól függ, hogy

megfelelő-e a társadalom számára, vagyis a termelési és fogyasztási folyamatok a társadalom számára kellően hasznosak-e és védelmi, különösen életvédelmi, valamint környezetvédelmi szempontból veszélytelenek-e. Az Európai Unió és a fejlett országok minőségügyi szabályozási gyakorlatában egyre nagyobb hangsúlyt kap a minőség társadalmi értelmezése. A minőség társadalmi értelmezése alapján tehát a minőségügy magában foglalja a fogyasztóvédelem mellett a biztonságtechnikát, a munkavédelmet, az élet és egészségvédelmet, az erkölcsvédelmet, a környezetvédelmet, továbbá a vagyon- és a tűzvédelmet is. A minőség társadalmi értelmezésében, felfogásában a fejlett országokban a védelem mellett, az előmozdítás és a támogatás is benne foglaltatik 2.15 A minőség minőségügyi értelmezése Az igény-kielégítési folyamat minősége korszerű minőségügyi szemléletben egyrészt a termék és a fogyasztási

folyamat fogyasztói minőségét, azaz a fogyasztói igények kielégítését, másrészt a termelési folyamat és a termék termelői minőségét, a hasznosságot, valamint az igény-kielégítési folyamat társadalmi minőségét, ezen belül elsősorban a védelmet és a támogatást foglalja magában. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 10 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 11 ► A jó minőség négyféle követelmény egyensúlya (J. Cons megfogalmazásában): • • • • műszaki (fizikai, kémiai, biológiai stb.) (technical) erkölcsi (ethical) piaci (marketing) gazdasági (economical) Cons értelmezése a megfelelőségre, a társadalmi érdekekre, a fogyasztói és a termelői igényekre utal. 2.16 A minőség mérése A minőség, szubjektív volta miatt nehezen mérhető. A mérés

nehézségét a következő problémák okozzák: • a minőséget meghatározó tulajdonságok mérése általában nem objektív • a minőséget meghatározó funkciók, tulajdonságok jelentős része nem mérhető • a minősítés szubjektív, mivel a minőség nem más, mint az emberek értékítélete, és nincs társadalmilag elfogadott értékrend • a minősítés időben és környezettől függően változó • sokan megfelelő háttér ismeret hiányában minősítenek, ami a minősítés jóságát ronthatja A minőség alapvető érték, ezért a mérését nehezítő problémák ellenére is mérni kell, amennyire ez lehetséges. 2.2 Minőségbiztosítási fogalmak 2.3 Szoftverminőség (Software quality) A szoftver is egy termelő-folyamat végterméke, ezért a minőségbiztosítás ezen esetben is elengedhetetlen feltétel. Napjainkban már egyre kevésbé fogadnak el gyengébb minőségű terméket. A tapasztalható szoftver-krízis egyik oka a minőségi

követelmények változása, a minőségi termékek középpontba kerülése. A minőségügyi menedzserek feladata, hogy a megkövetelt (előírt) minőséget biztosítsák A minőségbiztosítás jelenti a megfelelő eljárások, és szabványok definiálását, valamint annak ellenőrzését, hogy ezeknek megfelelően történik-e a gyártás. A szoftverminőség egy többdimenziós fogalom, amit nem egyszerű definiálni Klasszikus értelemben a A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 11 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 12 ► minőség azt jelenti, hogy a fejlesztési folyamat a specifikációs követelményeket kielégíti (Crosby 1979). Ideális esetben ez a definíció minden termékre alkalmazható lehetne, de a szoftverek esetében nehézségek akadnak ezzel: • A specifikációnak a felhasználó által

kívánt termék karakterisztikáját kell követni, azonban a fejlesztési szervezetnek is vannak követelményei, amelyek nem szerepelnek a specifikációban. • A szoftver specifikációk rendszerint nem teljesek. A minőség tervezésének kritikus pontja a fontos minőségi jellemzők kiválasztása, és annak megtervezése, hogy ezek hogyan érhetők el. A szoftverminőség menedzserek 3 fajta tevékenységért felelősek: • Minőségbiztosítás (quality assurance): szervezeti eljárásokat, valamint szabványokat kell rögzíteni, amelyek jó minőségű szoftverekhez vezetnek. • Minőségtervezés (quality planning): ki kell választani az alkalmas eljárásokat, és szabványokat, és ezeket illeszteni kell a speciális szoftver projektekhez. • Minőségszabályozás (quality control): biztosítani kell, hogy ezeket az eljárásokat és szabványokat követi a szoftverfejlesztő csapat A szoftverminőséget alapvetően meghatározó összetevők: • Minősítési,

illetve kiértékelési szempontok • Minőségfaktorok (hordozhatóság, megbízhatóság, hatékonyság, felhasználási kényelem, tesztelhetőség, érthetőség, módosíthatóság), minőségjegyek • Szoftverjellemzők (eszközfüggetlenség, teljesség, pontosság, konzisztencia, hatékonyság, elérhetőség, strukturálhatóság, dokumentáltság, tömörség, érthetőség, olvashatóság, bővíthetőség) • Szoftvermértékek, szoftver-mérőszámok 2.4 Szoftver-mérőszámok (metrikák) A szoftver-merőszámok (metrikák) a szoftver rendszerekhez, folyamatokhoz, vagy kapcsolódó dokumentációhoz tartoznak. A metrikák két osz- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 12 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 13 ► tályba sorolhatók: az egyik az ellenőrző metrika (control metrics), a másik a prediktor

metrika (predictor metrics) (2.1 ábra) szoftver termék (software product) szoftver folyamat (software process) prediktor mérések (predictor measurements) ellenorzo mérés (control measurement) menedzsment döntések (management decisions) 2.1 ábra Prediktor és ellenőrző metrikák Az ellenőrző metrikát a szoftver folyamatok ellenőrzésének kezelésére használják (pl. a lemezhasználat, vagy a felhasználható, illetve eltelt idő) Ezen mérőszámok becslése használható a projekt tervezési folyamatok finomítására. Az ellenőrző metrika információt nyújt a folyamat minőségéről, és ezért kapcsolódik a termék minőségéhez A prediktor metrika a termék jellemzőinek méréséhez tartozik, amely a termék minőségének előzetes megjósolására használható. Például a termék kézikönyvének olvashatósága előre jósolható az ún. Fog-index vizsgálatával, vagy például a szoftver komponensek nyomon követésének egyszerűsége

megjósolható a ciklomatikus komplexitás mérésével Ideális esetben a prédikátor metrika megengedi, hogy a szoftver néhány külső tulajdonságának értékét előre megjósoljuk. A külső jellemzők olyan dolgok, amelyek csak a szoftver üzembe helyezése után fedezhetők fel. A belső jellemzőket azonban közvetlenül a szoftverből határozhatjuk meg. A külső jellemzők közvetlenül nem mérhetők, ezért feltételeznünk kell, hogy létezik kapcsolat aközött, amit mérni tudunk, és amit tudni akarunk. A 2.2 ábra mutatja a fontos külső minőségi jellemzőket, valamint azokat a belső minőségi jellemzőket, amelyek mérhetők, és amelyek kapcsolódhatnak a külső jellemzőkhöz. (Az itt látható kapcsolati séma Kitchenham-tól származik, USA, 1990) Az ábra feltünteti a külső és belső jellemzők közti A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 13 ► Szoftver-minőségbiztosítás

Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 14 ► kapcsolatot, azonban a kapcsolat milyenségéről nem mond semmit. Ahhoz, hogy a belső tulajdonságok mérése hasznos prediktora legyen a belső szoftver karakterisztikának, a következő három feltételnek kell teljesülnie: • A belső jellemzőket pontosan kell mérni. • A mért és a külső tulajdonsági jellemzők között kapcsolatnak kell lenni. • A kapcsolat érthető, valós, valamint egy formulával, vagy modellel leírható legyen. Mindehhez még annyit fűzünk, hogy egy szoftver belső minőségi jellemzői elsősorban a fejlesztők szempontjából fontosak, míg a külső jellemzők a felhasználók szempontjából. Nyomonkövethetoség (Maintainability) Eljárás paraméterek száma Megbízhatóság (Reliability) Ciklomatikus komplexitás Hordozhatóság (Portability) Programméret kódsorban Hibaüzenetek száma Használhatóság

(Usability) Felhasználói segédlet hossza 2.2 ábra Lehetséges kapcsolatok a belső és külső szoftverjellemzők között A modell formalizálás az összegyűjtött adatok alapján a modell funkcionális formájának meghatározását jelenti (pl. lineáris, vagy exponenciális stb), a modellben szereplő paraméterek meghatározását, ezek beállítását a rendelkezésre álló adatok használatával. Ezáltal a modellfejlesztés statisztikai technikai gyakorlatot követel meg, tehát ebbe a folyamatba statisztikusokat is be kell bevonni. Jelenleg a szoftveriparban igen kis mértékben használnak csak metrikákat, azonban a minőségi fejlesztés fontos szerepe miatt egyre inkább A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 14 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 15 ► megnő az igény erre. Számos nagy cég (pl a

HP, AT&T) gyűjti és használja ezeket a mérőszámokat a fejlesztések folyamán A középpontban leginkább a programhibák, valamint a verifikációs és validációs eljárásokhoz tartozó mérőszámok állnak. Ezért ahogyan óriási a hajlandóság a mennyiségi információs fejlesztésekre, úgy növekszik a metrikák ipari használatának is a fontossága 2.41 Termék minőségmértéke A szoftvermérésekben részt vevő szervezeteknek sokkal inkább kell támaszkodni a lokálisan gyűjtött adatokra, mint megbízni a külső tapasztalatokban. Ahhoz, hogy felfedezzük, hogy egy bizonyos metrika egy termék minőségének hasznos prediktora, egy minőségbiztosító csoportnak kell kiértékelni a metrikát, lokális adatokat használó szisztematikus módon, a helyi eljárásokat és szabványokat is figyelembe véve. A 2.3 ábra mutatja a mérőszámok használatának folyamatát a minőség előrejelzésére. Alapvetően a rendszer minden egyes komponensét

függetlenül vizsgálják, és a mérőszámok különböző értékeit összehasonlítják, mind egymással, mind pedig egy régebbi projektből származó adatokkal. Rendhagyó méréseket kellene használni, hogy középpontba a minőségi problémákkal rendelkező komponensek minőségbiztosítása kerüljön. rendhagyó komponensek vizsgálata mérések választása a kiértékelendo komponensek kiválasztása rendhagyó mérések meghatározása komponensek karakterisztiikájának mérése 2.3 ábra A termék mérésének folyamata A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 15 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 16 ► Ilyen metrikákat használnak tervezés, valamint program és dokumentáció kiértékelésre. A tervezés kiértékelésének metrikáját alkalmazzák a specifikációkban használt grafikus

jelölésekben is A dokumentációs metrika, mint a Fog-index alkalmazható természetes nyelvű specifikációkban. 2.42 A tervezés minőségmértéke Sok fontos tervezési tulajdonság van, de a legfontosabb ezek közül a karbantarthatóság. A minőségbiztosítás ezért leginkább a hibadetektálással, valamint a karbantarthatóság kiértékelésével foglalkozik. A karbantarthatóságot nem tudjuk közvetlenül mérni A tervezés karbantarthatósága kapcsolódik: • A kohézióhoz (Cohesion): A komponens részei milyen szorosan kapcsolódnak? • A csatolódáshoz (Coupling): Mennyire független a komponens? • Az érthetőséghez (Understandability): Milyen könnyű megérteni a komponens funkcióját? • A beilleszthetőséghez (Adaptability): Milyen könnyű a komponenst lecserélni? A kohézió egy egyszerű minőségi fogalom, de nehéz a kiértékelése a komponens céljának megértése nélkül. A komponensek csatolódása mérhető a komponensek közti

kapcsolatok számának figyelésével, ha egy megfelelő jelölést használnak a tervezési folyamatban. Sem a komponensek érthetősége, sem az alkalmazhatósága nem mérhető közvetlenül Azonban kapcsolat van e tulajdonságok, és a komponens komplexitása között A komplexitás mérése lehetőséget biztosít arra, hogy egymással összehasonlítsuk a komponensek érthetőségét és alkalmazhatóságát, néhány szabványt is figyelembe véve. Constantine és Yourdon (1979) javaslatára a tervezés társítása meghatározható a tervezési komponensek fan-in, és fan-out mérésével. A fan-in azon komponensek száma, amelyek ezt a komponenst meghívják, a fanout pedig azon komponensek számát jelenti, amelyeket a komponens meghív. Henry és Kafura javasolta a komponens komplexitásának meghatározására a következő képletet az információs Fan-in, valamint Fan-out-okkal: Complexity = Length × (Fan-in × Fan-out)2 A dokumentum használata | Tartalomjegyzék |

Felhasznált irodalom Vissza ◄ 16 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 17 ► ahol, a length a hosszúságnak egy mértéke, ami lehet pl. a programkód sorainak száma is Henry és Kafura Unix rendszer használatával validálták a metrikájukat, és azt javasolták, hogy a potenciálisan hibás komponenst is megengedő rendszer mért komplexitását is meg kell határozni. A metrika magas értéket mutatott azokban a komponensekben, amelyek a rendszerproblémák viszonylag magas számát okozták, és ez magas karbantartási költséget eredményezett. A metrika alapvető hátránya viszont az, hogy a komplexitásra nulla értéket ad, ha az eljárásnak nincsenek külső kölcsönhatásai. A komponensek a legalacsonyabb szinten nem tudnak más komponenseket meghívni, azonban kölcsönhatásba léphetnek a hardverrel, és ezáltal bonyolulttá válnak. A

Fan-in, valamint a Fan-out teljesen egyértelmű definiálása nehéz Henry és Kafura metrikája számos független tanulmány tárgya lett a későbbiekben. Ezek vizsgálták, hogy vajon ez a metrika jobb-e a többi egyszerű metrikánál, mint pl. a méret, vagy a vágások száma, ezen kívül meg próbálták kitalálni, hogy vajon a strukturális komplexitás hasznos prediktora-e a fejlesztési időnek. A Fan-in/Fan-out nem teljesen megbízható mérték a tervezési minőségre, de ezen metrikák hasznosak a hibás komponensek kiemelésére a további analízis számára. Ha valamelyik komponensnek különösen magas értéke van ebben a metrikában, akkor ez azt jelenti, hogy túlságosan bonyolult. 2.43 A program minőségmértéke A programnak hibamentesnek valamint karbantarthatónak kell lennie. A szoftver-mérésekkel foglalkozó legtöbb munka természetesen a program analízisét helyezi a középpontba, aminek az oka, hogy a program egyértelmű nyelven van

megfogalmazva, másrészt meglehetősen nyitott azokra eszközökre nézve, amelyekkel a programról adatokat gyűjthetünk. A programban lévő hibák megjóslására az alábbi metrikák használhatók: • Kódhossz (Length of code): a program méretének mértéke. Általában a nagyobb méretű programkód több hibalehetőséget rejthet magába. • Ciklomatikus komplexitás (Cyclomatic complexity): a programkomplexitás ellenőrzésének a mértéke. (A programban lévő különböző végrehajtási utasítássorozatok számát jelenti) Ez a komplexitási mérőszám kapcsolódhat a program érthetőségéhez is A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 17 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 18 ► • Azonosítók hossza (Length of identifiers): ez a programban használatos különböző azonosítók átlagos

hosszának a mértéke. Minél hoszszabb az azonosító, annál több jelentést hordoz, tehát jobban érthető a program. • Feltételes szerkezetek mélysége: a programban szereplő if-utasítások mélységének, beágyazottságának a mértéke. Minél mélyebbek az ifutasítások, annál nehezebben érthetőek, tehát annál nagyobb a hibaforrás A program méretének mérése használható a minőségbiztosítási eljárás részeként. Egy szabványban adtak egy felső korlátot a komponens méretére vonatkozólag. Azok a komponenseket, amelyek ezt túlhaladták, azokat újra kell tervezni, vagy pedig újabb részletes analízis alá vonni. Azonban a méret az egyik legegyszerűbb metrika, és a legkönnyebb gyűjteni, Kitchenman (1990) szerint ez legalább olyan jó indikátora a rendellenes komponenseknek, mint más bonyolultabb metrika. Egy eljárás ciklomatikus komplexitása a komponensek belső komplexitásának mértéke. E metrika alacsony értéke a program

érthetőségével függ össze. A ciklomatikus komplexitás, mint a teljes körű komponenskomplexitás mértéke két hátránnyal bír: • A program döntési komplexitását méri, amely feltételes utasításokkal, valamint előfeltételekkel van meghatározva. Ha a program adatorientált, akkor a ciklomatikus komplexitásra alacsony érték adódik, viszont ettől még mindig elég komplex, és nehezen érthető • Ugyanazon súllyal szerepelnek a beágyazott, és nem beágyazott ciklusok. Azonban a mélyen beágyazott feltételes struktúrákat nehezebb megérteni, mint a nem-beágyazottat. Oviedo (1980) kidolgozott egy program-komplexitási mérőszámot, amely szerint a komponens komplexitása a következő formulával becsülhető meg: C = aE + bN, ahol a és b konstans együtthatók, és E a vezérlési folyamatgráf éleinek száma, N: olyan adatokra való hivatkozások száma, amelyek nincsenek deklarálva a komponensben. A dokumentum használata | Tartalomjegyzék |

Felhasznált irodalom Vissza ◄ 18 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 19 ► Jó programozási stílusban mindig jelentéssel bíró azonosítókat használnak. Ezért a program érthetősége növelhető hosszabb nevek alkalmazásával, természetesen egyéb más faktor is létezik, ami növeli a program olvashatóságát, mint pl. a megjegyzések írása Fontos lenne programozási szabványban definiálni az azonosítók hosszát is 2.44 Dokumentációs minőségmérték A szoftverhez kapcsolódó dokumentáció minősége legalább olyan fontos, mint a szoftvernek magának a minősége. Gunning (1962) adta ki a Fogindexet, ami az olvashatóság mértéke A Fog-index a mondatok hosszán, és a „nehéz” szavak számán alapul, ahol a szó nehézségét a szóban található hangok száma adja. Ez hasznos indikátora lehet a dokumentáció

olvashatóságának Ez különösen akkor hasznos, ha egy dokumentációnak több szerzője van. A dokumentáció részei közti stílusbeli különbségeket ki kell emelni, és ki kell javítani. 2.5 Szoftver-megbízhatóság A szoftver rendszerek legfontosabb jellemzője a megbízhatósága. Napjainkban minden rendszer esetében a minőség alapvető követelmény A rendszerhibák a szoftverfejlesztés költségét növelik, mivel a megbízhatatlan szoftver a végfelhasználónak nagy költségébe kerülhet. Formálisan a megbízhatóságot egy speciális célra egy adott környezetben egy adott idő alatti hibamentes műveletek valószínűségeként definiálják. Pl a repülőgép vezérlési szoftverének 99,99%-os megbízhatóságúnak kell lennie egy ötórás átlagos repülőút során. Azonban a megbízhatóság formális definíciója nem mindig van összhangban a felhasználók szoftver tapasztalatával. A felhasználók nem figyelik az összes azonos fontosságú

szolgáltatást, viszont a rendszert megbízhatatlannak tarthatják, ha az nem működik bizonyos kritikus körülmények között. A szoftver-megbízhatóság függvénye a szoftver bizonyos felhasználói által tapasztalt hibák számának. A szoftver hiba (failure) a szoftver futása közben jelentkezik. Ez az eset, amikor a szoftver nem teljesíti a felhasználó által elvárt szolgáltatást A failure és a fault nem ugyanaz, de gyakran felcserélve használják őket. Szoftver hiba (fault) lehet programozási vagy tervezési hiba, amikor is a szoftver nem felel meg a rendszer specifikációnak. Ezek lehetnek még dokumentációs, vagy specifikációs hibák is. Azaz a szoftver nem úgy viselkedik, ahogyan a felhasználó elvárná A szoftver hibák statikusak Ezek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 19 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék |

Felhasznált irodalom Vissza ◄ 20 ► a program kód tulajdonságai, amelyek a program felülvizsgálatával felfedezhetők. A szoftver hiba (fault) okozza a szoftver rendellenességét (failure), amikor a hibás kód olyan bemeneti halmazzal fut, amely a szoftver hibát eredményezi. A kód amúgy a legtöbb bemenetre helyesen fut le A szoftverrendszer nem más, mint egy leképezés, egy input halmazból egy output halmazba, azaz a programnak sok inputja lehet, amire a rendszer válaszképp adja az outputot, vagy az output-halmazt. Az input halmaz egy részhalmaza tartalmazza azokat az inputokat, amelyek hatására a program rossz outputokat generál. A szoftver megbízhatósága pedig annak a valószínűségéhez kapcsolódik, hogy a program egy bizonyos futtatása során a rendszer inputja elemei-e annak a részhalmaznak, amelyek a hibás outputokat okozzák Bonyolult kapcsolat áll fenn a vizsgált rendszer megbízhatósága, és a szoftver hibák száma között. Mills

(1987) megmutatta, hogy a szoftver hibák nem egyforma valószínűséggel okozzák a szoftver rendellenességét. Rendszerint vannak olyan bemenetek, amelyeket nagyobb valószínűséggel használnak, és ha ezek a bemenetek nincsenek benne abban a halmazban, ami a szoftver hibát okozzák, akkor nem lesz rendellenesség. Tehát a program megbízhatósága leginkább a hibás kimeneteket okozó bemenő adatok halmazától függ. A megbízhatóság függ a használat közbeni hibafellépés valószínűségétől is. Ha a szoftver ritkán használt részeiből eltávolítjuk a hibákat, akkor a megbízhatóság csak kis mértékben növekszik (a termékhibák 60%-ának eltávolítása 3%-os megbízhatósági növekedést eredményez csak). Ezért a program hibákat is tartalmazhat, de mégis lehetséges az, hogy a felhasználók számára megbízható, mivel nem jelentkezett rendellenesség a programban. A tapasztalt felhasználók gyakran dolgoznak olyan környezetben, ahol olyan

hibák vannak, amikről tudják, hogy rendellenességet okozhatnak, ezért megpróbálják elkerülni őket. Mivel a programot a felhasználók különbözőképpen különböző környezetben használják, ezért ugyanaz a program bizonyos felhasználók számára megbízható, míg esetleg más felhasználó számára (aki hibát okozó bemenő adatokat használ) megbízhatatlan. 2.51 Formális módszerek Megbízhatóbb szoftvert eredményez, ha formális módszereket használunk a szoftverfejlesztésre, mert így könnyebben elkerülhetjük az anomáliákat. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 20 ► Szoftver-minőségbiztosítás Szoftver–minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 21 ► Azonban a formális specifikáció még nem garantálja, hogy a gyakorlati használatban a szoftver megbízható lesz. Az okok a következők: • A felhasználók valódi

igényeit a specifikáció nem mindig tükrözi teljesen. • A bizonyítás is tartalmazhat hibát • Ha a rendszert nem úgy használják, ahogyan előre látható volt, akkor a bizonyítás is hibás lehet. A megbízhatóság növelése érdekében tett további fejlesztések, tervezések drasztikusan megnövelhetik a költségeket. A valóságban lehetetlen lemérni és igazolni, hogy a rendszer 100%-osan megbízható, azonban ha megbízhatósági követelményeket tovább növeljük, akkor a költség exponenciálisan fog növekedni. Természetesen a megbízhatóság növelése gyakran a program hatékonyságénak csökkenését is okozhatja, pl növekszik a program a futási ideje, mert gyakran extra redundáns kódokat is kell használni a kivételes feltételek megvalósítására. Azonban gyakran a megbízhatóság előnyt élvez a hatékonysággal szemben a következő okok miatt: • A számítógépek jelenleg olcsók és gyorsak • A felhasználó hajlamos arra, hogy

eldobja a nem megbízható szoftvereket • A rendszerhibák költsége óriási lehet • A nem-megbízható rendszert nehéz fejleszteni • A gyenge hatékonyság előre megjósolható • A nem-megbízható szoftverek információvesztést okozhatnak A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 21 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 22 ► 3. Biztonságkritikus rendszerek Ebben a fejezetben a biztonságkritikus informatikai rendszerekkel foglakozunk. A szoftver technológia területén azért van kiemelt jelentősége az ilyen rendszereknek, mivel ezekben jelentkezik a legnagyobb mértékben a fejlesztési és tesztelési feladatok szigorú előírásokhoz kötött végrehajtásának igénye. Az ebbe a kategóriába tartozó szoftverekre érvényes előírások sorából nem mindegyik vonatkozik a más kategóriájú

szoftverekre, hanem azoknak csak egy része. A verifikációs és validációs folyamatok a biztonságkritikus rendszereknél hajtandók végre a legnagyobb gonddal, hozzáértéssel és ráfordítással 3.1 Alapfogalmak Biztonságkritikus rendszer: Olyan informatikai rendszer, amely azzal az elsődleges követelménnyel működtetendő, hogy ne veszélyeztesse az emberi életet, egészséget, ne okozzon gazdasági vagy környezeti károkat. Tipikusan ilyenek a vasúti állomásirányító központok, az atomerőművek vezérlését, űrhajók, űrrepülők irányítását, repülőgépek irányítását ellátó rendszerek, valamint a kórházakban, bankokban, hadászatban (pl. cirkáló rakéta) alkalmazott informatikai rendszerek. A felsorolt példákban jól látható az alkalmazott rendszerek hibás működéséből származó károk milyensége. Egy banki alkalmazás óriási anyagi károkkal járhat, egy vegyipari folyamat környezetei kárt okozhat, hadászati eszköz esetében

pedig a civil lakosságnak okozott veszteség jöhet szóba. A biztonságot eredményező működés mellett a másik legfontosabb tulajdonság a megbízhatóság. Csak nagy megbízhatóságú rendszerek alkalmazhatók eben a kategóriában Általában 24 órán keresztül tartó folyamatos üzemelésre van igény. A biztonság eléréséhez ún hibatűrő rendszerek alkalmazására van szükség Hibatűrő rendszer: Egy informatikai rendszer hibatűrő, ha képes elvégezni, ill. tovább folytatni előírt feladatának helyes végrehajtását hardver-meghibásodások és szoftver-hibák jelenléte esetén A hibatűrés nem azt jelenti, hogy a rendszer ugyanazzal a hatásfokkal, teljesítménnyel működik hibásan is, mint hibamentesen, hanem azt, hogy a teljesítménye lecsökkenhet, esetleg nem mindegyik funkcióját látja el maradéktalanul, viszont a legfontosabb előírt feladatait még végre tudja hajtani. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom

Vissza ◄ 22 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 23 ► A hibatűrő rendszerek tervezésekor bizonyos tervezési célokat kell elérni, amelyek előre megadott követelmények teljesítését szolgálják. Ezek a követelmények különböző matematikai, valószínűség-számítási mutatók minimális értékének elérését írják elő. A következő alpontban ezeket a mutatókat soroljuk fel, és definiáljuk. 3.2 Minőségi és megbízhatósági követelmények Az alábbiakban felsorolt mutatók számszerű értékének meghatározására pontosan kidolgozott mérési, vizsgálati és számítási eljárások léteznek, amelyekkel ebben a könyvben nem foglalkozunk. Megbízhatóság (Reliability): Annak feltételes valószínűsége, hogy a rendszer hibátlanul működik a [t0, t] időintervallumban, feltéve, hogy a t0 ≤ t időpontban hibátlanul

működött. A megbízhatóságot leíró valószínűségi függvény jele R(t) A megbízhatósági érték tehát annak a valószínűségét fejezi ki, hogy a rendszer a [t0, t] időintervallumban végig hibátlanul működik. Ez az érték az intervallum hosszának a növekedésével nyilvánvalóan csökken, hiszen az elektronikus részegységek az üzemeltetésük, igénybe vételük előrehaladtával egyre inkább elhasználódnak, elöregszenek. A szoftver rész elöregedéséről, megbízhatósági értelemben, természetesen nem beszélhetünk Ezt a paramétert elsősorban olyan rendszerek jellemzésére használják kiemelten, ahol egy rövid időre sincs megengedve a hibás működés, vagy pedig nincs mód a javításra. Az előbbi feltételre példa egy rövid repülési idejű repülőgép, ahol az intervallum 10 óra. Erre vonatkozóan elő van írva az R(t) ≥ 0,9999999 = 0,97 értékszint. Egy nem javítható űrszondánál a működési idő 10 évet is kitehet.

Ebben az esetben a követelmény a 10-éves periódus végén: R(t) ≥ 0,95. A megbízhatóság és a hibatűrés nem ugyanazt jelenti. A hibatűrés olyan technika, amely javítja a megbízhatóságot, de ettől még nem biztos, hogy valóban magas lesz a megbízhatóság. Ha egy rendszer ki tud védeni hardver hibákat, de azok nagy gyakorisággal jelentkeznek, akkor az R(t) értéke még alacsony is lehet. Másrészről pedig, ha egy nagy megbízhatóságú rendszerbe nincs beépítve hibatűrés, akkor az első hiba fellépésétől kezdve rosszul fog működni. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 23 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 24 ► Rendelkezésre állás (Availability): Annak valószínűsége, hogy a rendszer helyesen működik a t időpontban, vagyis a t időpontban rendelkezésre áll. A rendelkezésre

állást leíró valószínűségi függvény jele A(t) Mint látható, az R(t) és az A(t) függvény között az a különbség, hogy az előbbi a t időpontig tartó folyamatos helyességet fejezi ki, míg az utóbbi csak azt, hogy a t időpontban legyen a működés helyes. Ezt megelőzően lehetett hibás is. Az A(t) mérőszám értéke ott lehet fontos, ahol az informatikai rendszert nem állandóan használják egy feladatra, hanem gyakori megszakításokkal. Ilyen esetekben megnövekszik a közbenső karbantartás és javítás szerepe, amely a rendelkezésre állás magas szinten tartását szolgálja. Biztonságosság (Safety): Annak valószínűsége, hogy a rendszer helyesen vagy hibásan működik a t időpontban, de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem befolyásolja károsan más rendszerek működését. Másként fogalmazva: Annak valószínűsége, hogy a rendszer a t időpontban biztonságosan működik. A

biztonságosságot leíró valószínűségi függvény jele S(t) Ez a paraméter igen szorosan összefügg a hibatűréssel. Előfordulhat ugyanis, hogy az informatikai rendszerben komoly meghibásodás lép fel, aminek következtében már nem lesz képes az előírt funkcióit ellátni. Ebben a helyzetben a biztonság fenntartása úgy oldandó meg, hogy a rendszer olyan sorrendben hagy fel, egymás után, a funkciók ellátásával, ami a katasztrófa elkerülését teszi lehetővé. Ez a fokozatos leépülés esete (angol elnevezéssel: graceful degradation). A fokozatos leépülés egy rendszer azon képessége, hogy automatikusan tudja csökkenteni teljesítőképességét, a hardver- és szoftver-hibák hatásának ellensúlyozására. A másik elterjedt vészmegoldás az, hogy a rendszer, még utolsó intézkedéseként mindent úgy állít le, hogy a katasztrófa semmiképpen ne tudjon bekövetkezni. Tipikus példa erre a vasútirányítás, ahol a leállítás azzal jár,

hogy a vezérlés hatására egyik vonat vagy szerelvény sem mozoghat. Teljesítőképesség (Performability): Annak valószínűsége, hogy a rendszer teljesítőképessége a t időpontban eléri vagy meghaladja az L szintet. A teljesítőképességet leíró valószínűségi függvény jele P(L, t) Ez a paraméter azt fejezi ki, hogy a hiba esetén milyen csökkent szinten képes még a rendszer működni. Például: többprocesszoros számítógépnél egy-egy processzor kiesése a számítási sebességet csökkentheti Ugyanilyen hatással jár a memóriaterületek kiesése is. Ilyen esetekben az L A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 24 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 25 ► értéke lehet a sebesség, a jól működő processzorok száma, vagy a megmaradó memóriaterület. A fokozatos leépülés

megvalósítása nem más, mint a teljesítőképesség előre megtervezett módon való fokozatos csökkentése, a biztonság fenntartása érdekében. Karbantarthatóság (Maintainability): Annak valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető t időtartam alatt. Ebbe az időbe beletartozik a hiba helyének meghatározása, a fizikai javítás vagy csere elvégzése, valamint az újraindítás. A karbantarthatóságot leíró valószínűségi függvény jele M(t). Az M(t) értékének magas szinten tartása feltétlenül megköveteli a beépített öntesztelést (built-in self-testing, BIST), valamint az automatizált diagnózis elvégzését, amely a hiba helyének meghatározására irányul. A tesztelési és hibalokalizációs folyamatok végrehajtásához külön hardver egységek és külön szoftver felhasználására van szükség, ahol mindezek a hibatűrő rendszer integráns részét képezik. A fentiekben felsorolt paraméterek mellett

igen fontos tulajdonsága egy rendszernek a tesztelhetőség (testability) is. A tesztelhetőség azt a lehetőséget jelenti, hogy vizsgálatok, tesztek segítségével meg tudjuk határozni a rendszer egyes működési tulajdonságait. Ez lehet például a működési sebesség ellenőrizhetősége, vagy pedig ami a leginkább fontos, annak meghatározhatósága, hogy hibás-e a működés A tesztelhetőség mértéke azt fejezi ki, hogy mekkora ráfordítással, nehézséggel jár egy-egy tesztelési folyamat elvégzése. Ehhez a fogalomhoz igen nehéz jól használható kvantitatív mérőszámot rendelni, ilyen mérőszám jelenleg nincs még definiálva. Nyilvánvaló minőségi cél a minél gyorsabb és könnyebb végrehajthatóság Erre vonatkozóan külön módszerek, ajánlott vagy előírt tervezési megoldások állnak rendelkezésre, ill. folyamatosan kerülnek kidolgozásra Ennek témaköre a tesztelhetőségre való tervezés (design for testability), amivel itt nem

foglalkozunk. A hibatűrésre vonatkozóan négy fő alkalmazási területet lehet megkülönböztetni. Ezek a következők: 1. Hosszú élettartamú alkalmazások Az ide sorolható berendezések több éves időtartamban működnek, általában a javításra kevés lehetőséggel. Ilyenek: Ember nélküli űrrepülés, műholdak, űrszondák Egy-egy űrszonda akár tíz éven túl is teljesíti küldeté- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 25 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 26 ► sét, amikor távoli bolygók közelébe kell jutnia. Mint már említettük, a megbízhatósági értékének 95% felett kell lenni még ilyenkor is. Az űrszondákon a biztonságos működés elérése érdekében mindegyik egységnek, blokknak van másodlagos tartaléka. Ez nemcsak az informatikai egységekre, hanem a különböző

navigációs, távmérő, rádiós, stb blokkokra is fennáll 2. Kritikus számítások Ez a felhasználási mód éppen az ellenkezője az előbbinek. Itt az a fontos, hogy arra a viszonylag rövid időtartamra, amíg egy kritikus működési, számítási szakaszban üzemel a rendszer, a megbízhatósága garantáltan magas legyen. Példák: • Űrkompnál a felszállás és leszállás idejére nem szabad hibának fellépni, mert a komp elveszhetne végleg. • Vegyi üzem szabályozó rendszere: egy technológiai folyamat kritikus szakaszában megnőhet a robbanásveszély. Erre a szakaszra a hibátlan működést minél inkább el kell érni. • Repülésirányító rendszer, amely a repülőgép fedélzetén helyezkedik el. A fenti esetekre az előírás a 95 % feletti megbízhatóság. 3. Elhalasztott karbantartás Az olyan esetekre érvényes, amikor a karbantartási műveleteket igen nehéz, vagy igen költséges elvégezni. Jó példák erre a távoli helyeken üzemeltetett

feldolgozóállomások, vagy az űrbeli alkalmazások. Egy-egy ilyen rendszer karbantartása egy későbbi, megfelelő időpontban történik meg. Két karbantartási procedúra között kiemelten szükséges a hibatűrő működés A földi alkalmazásra jó példa az amerikai AT & T Bell számítógépes vezérlésű és feldolgozású telefonhálózata, melyben a hibatűrést az üzemelés elvárt biztonságossága és az óriási anyagi veszteségek elkerülése indokolja. (Itt már 10 perc kiesés is milliárd dollárokban mérhető kárt jelent a szolgáltatónak.) A telefonhálózat kiépítése megkövetelte, hogy távoli helyeken is legyenek telepítve számítógépes kapcsolóállomások Ezeket a vállalat emberei periodikusan látogatják végig, és elvégzik a karbantartási munkákat. 4. Magas szintű rendelkezésre állás A váltakozó mértékben igénybe vett informatikai rendszerekre vonatkozik ez a kategória. Ilyenek az ún on-line tranzakció-feldolgozást

végző rend- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 26 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 27 ► szerek (on-line transaction processing, OLTP), ahol a felhasználói megkeresés véletlenszerű módon érkezik több helyről, és ezekre azonnali feldolgozás, kiszolgálás van megkövetelve. Ilyenek például a banki alkalmazások Az OLTP-rendszerek általában nagykiterjedésű országos hálózatban üzemelnek, ezen belül több lokális hálózattal. Az üzemelés legtöbbször 24-órás munkarendben történik, de a felhasználás jellegéből adódóan mód van az éjszakai karbantartás időnkénti elvégzésére is. Az ilyen rendszereknél nemcsak a központi számítógép a hibatűrő, hanem a helyi hálózatok szerver gépei is. A felhasználói terminálok általában személyi számítógépek, amelyekre már

nincs előírva a hibatűrés Fontos azonban, hogy ezek is nagymegbízhatóságú, kiváló minőségű gyártmányok legyenek. A bankok mellett további elterjedt OLTP-alkalmazások a következők: • Rendőrségi ügyeleti bevetésirányító rendszer, amely a bejelentések feldolgozásán túl a rendőri beavatkozások nyilvántartását és szervezését is végzi. Ugyanilyen funkciójú a mentők és tűzoltók bevetésirányítása is • Országos vagy nemzetközi szállításásirányítás, amely a vasúti, kamionos, vagy légi áruszállítás nyomon követésére, nyilvántartására és optimális szervezésére szolgál. 3.3 Rendszerstruktúrák A hibatűrés megvalósítása mindenképpen előre betervezett redundanciával kell hogy járjon. Ennek az a magától értendő oka van, hogy a hibatűrő informatikai rendszerre a normál funkcióján kívül a saját hibás működés felismerése és az ilyenkor megvalósítandó feladatteljesítés is ráhárul A redundancia

mind a hardverben, mind pedig a szoftverben érvényre jut, mivel egyedül egyik fő komponens sem képes a másik hibáját felismerni és funkcióját ellátni. Természetesen a szoftver és a hardver egymással összhangban üzemel, amibe az is beletartozik, hogy a hibafelismerésben és az ilyenkor szükséges reakciókban is kiegészítik, vagy átfedik egymást A hibatűrő rendszerek felépítése sok esetben olyan, hogy a hardver is hozzájárul a szoftver-hibák felismeréséhez, és viszont, a szoftver is részt vehet a hardver-hibák észlelésében. A redundancia megvalósítására négy terület vált alkalmassá. Ezek a következők: A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 27 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 28 ► 1. Hardver redundancia: A hibatűrés elérése érdekében kiegészítő hardver elemeket

alkalmaznak, különböző funkciókkal. A funkciók egyrészt a működéshez kapcsolódó tesztelést (beépített öntesztelést), másrészt pedig egyes elemek ismétlését (tartalékként) jelentik általában. A fejezet későbbi részében erre be fogunk mutatni néhány jellegzetes megoldást. 2. Szoftver redundancia: A hibatűrés elérése érdekében kiegészítő szoftverelemeket, ill. szoftverrel megvalósított módszereket alkalmaznak Itt is számításba kell vennünk a szoftvert az öntesztelés megvalósításában, valamint az ismétlődő funkciók ellátásában Ezzel is bővebben foglalkozunk még a fejezetben 3. Információs redundancia: A működési biztonság növelése érdekében többletinformációt, többletbiteket használnak fel Ezáltal a hibák detektálására és/vagy tolerálására kerülhet sor. Tipikus elterjedt megoldás például a paritásbitek, hibadetektáló kódok, hibajavító kódok, ellenőrző összegek (check sum) használata A

hibajavító kódok nemcsak detektálásra, hanem tolerálásra, vagyis a hiba elfedésére, hatásának megszüntetésére is alkalmasak. Az ilyen megoldások az adatátviteli folyamatokban, továbbá a memóriákban, ill a központi feldolgozó egységekben (CPU) terjedtek el leginkább Megvalósításuk egyaránt történhet hardver és szoftver úton 4. Idő redundancia: A szükségesnél hosszabb feldolgozási idő igénybevétele A cél itt is a hibák detektálása és/vagy tolerálása A legelterjedtebb megoldás a feldolgozás, a számítások ismételt lefolytatása, az eredmények összehasonlításával egybekötve. Ezzel elérhető az, hogy a hardverben fellépő átmeneti hibát, amely az egyik végrehajtás alatt érvényesült, egy újabb végrehajtással ki lehessen ejteni. Az időtöbblet tehát így detektálást és korrigálást is lehetővé tesz A megvalósítás egyaránt történhet hardverrel és szoftverrel is A gyakorlatban a fenti négy elv kombinációját

alkalmazzák. Igen sok esetben mind a négy redundanciát beépítik a biztonságkritikus rendszerekbe A következőkben néhány fontosabb strukturális és algoritmikus megoldást ismertetünk, amelyek a hibatűrést szolgálják hardver és szoftver téren. A hardvert itt rendszertechnikai szempontból mutatjuk be, és csak olyan mélységben, amennyire ez a szoftver oldalról fontos lehet. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 28 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 29 ► 3.4 A hardver redundancia megvalósítása A következőkben három jellegzetes megoldást ismertetünk a hardver redundancia megvalósítására. 3.41 Párhuzamos duplikálás A legrégebben alkalmazott és kézenfekvő struktúra ugyanazon hardver egységnek a megkettőzése és párhuzamos működtetése. Ekkor mindkét egység ugyanazokat a

bemenő jeleket kapja, és helyes működés esetén ugyanazokat az eredményeket is kell produkálniuk. Az eredmények megfigyeléséről és összevetéséről egy külön beiktatott összehasonlító egység gondoskodik. Egyezés esetén az egyik egység jelei jutnak tovább a feldolgozási folyamatban Az egymástól eltérő eredmény az egyik egység hibás működését jelenti. Itt a hibát csak detektálni lehet, de elfedésére, tolerálására már nincs mód Célszerű intézkedés lehet ilyenkor a további működés biztonságot nem sértő leállítása. A leírt párhuzamos struktúrát a 3.1 ábrán mutatjuk be A duplikált egységek bármilyen bonyolultságú modulok lehetnek, ugyanakkor tetszőleges számú egységpárost lehet egy rendszeren belül kialakítani. Például aritmetikai logikai egységet (ALU-t), vagy háttértárolókat, diszkegységet. A legmagasabb szintű megoldás az, amikor egy teljes számítógép megkettőzése valósul meg. 1. modul Bemenet

Összehasonlító egység Kimenet 2. modul 3.1 ábra Párhuzamos duplikálás 3.42 Tartalékelemes üzemeltetés Ebben a struktúrában is két azonos egység vesz részt, de csak az egyik, a normál egység fejt ki üzemszerű működést, a másik tartalékként szerepel (3.2 ábra) Azt, hogy melyik egység jelei jutnak a kimenetre, az átkapcsoló modul intézi el, a hibadetektor modul parancsa alapján. A hibadetektor rendelkezik azzal a képességgel, hogy meg tudja állapítani a helyes-hibás működést az általa ellenőrzött modulról. Ha a normál modul hibásnak A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 29 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 30 ► mutatkozik, akkor a tartalékmodul üzemeltetésére kerül sor. Ha az is meghibásodna, a működés felfüggesztődik A tartalékmodult kétféle állapotban

szokás használni a normál üzemelés folyamán. Az egyikben nincs bekapcsolva, vagyis nincs tápfeszültség alá helyezve (hideg tartalék), a másikban állandóan be van kapcsolva, és működést fejt ki (meleg tartalék). A hideg tartalék alkalmazására egyrészt energia-takarékosságból, másrészt pedig az élettartam meghosszabbítása érdekében kerítenek sort. Hibadetektáló egység Normál modul Bemenet Átkapcsoló egység Kimenet Tartalék modul 3.2 ábra Tartalékelemes üzemeltetés 3.43 Hárommodulos redundancia (TMR) Mint látható volt, a hibatűrés megvalósítására nem elegendő két egység. A cél elérése legalább három egység beiktatását kívánja meg. Egy ilyen struktúrát tüntet fel a 33 ábra, az ún hárommodulos redundanciát (Angolul: Triple Modular Redundancy, TMR.) A TMR-struktúrában a három megismételt modul jelei egy ún. szavazóegységre (voting unit, voter) jutnak, amely a többségi szavazás elvén működik. Ez azt

jelenti, hogy a kimenetre az a jel megy tovább, amely legalább két modulnál azonos. Ha tehát egy modul meghibásodik, akkor a másik kettő azonosan helyes működése érvényesül A hibás modul hibája egyrészt detektálódik, mivel az megállapítható, hogy melyik tért el a másik kettőtől, másrészt pedig tolerálódik is, mivel a hatása nem jut érvényre a teljes működésben. Ha két vagy három modul hibásodna meg, akkor várhatólag három különböző jel jutna a szavazóra, amely ilyenkor deklarálná a teljesen téves működést, aminek alapján egy biztonságra törekvő leállítás, vagy tartalékegység beléptetése következhet. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 30 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 31 ► 1. modul Bemenet Kimenet 2. modul Szavazó egység 3. modul (Többségi

szavazás) 3.3 ábra A TMR-rendszer felépítése Mindehhez még az a feltételezés is járul, hogy annak a valószínűsége, hogy két modul teljesen azonos módon hibásodik meg egyidejűleg, elhanyagolhatóan kicsi. A vázolt szisztéma egyetlen hibás modul tolerálására alkalmas. Az eltűrt hibás modulok száma úgy növelhető, hogy növeljük a párhuzamosan dolgozó modulok számát, de mindig úgy, hogy ez a szám páratlan legyen a többségi szavazással összhangban. Könnyen belátható, hogy az eltűrt hibás modulok száma N ≥ 3 esetén az (N – 1) / 2 képlettel határozható meg. Ez a szám öt modulnál kettő, hét modulnál három. A modulok számának növelése természetesen nem jár arányosan egyértelmű javulással, mivel a meghibásodások valószínűsége is növekszik, másrészt pedig gazdaságossági korlátok is jelentkeznek. A gyakorlatban alkalmazott informatikai rendszerek ismeretében megállapíthatjuk, hogy a világon a TMR-konstrukció

terjedt el és vált be leginkább. Érdekességként még megemlítendő, hogy a többségi szavazásos rendszerek megbízhatósági elméletével először Neumann János foglakozott behatóbban, az Egyesült Államokban, az 1950-es években. Akkoriban még az volt a fő gond, hogy kisebb megbízhatóságú alkatrészekből (relék, elektroncsövek) hogyan lehet olyan számítógépet építeni, ami nagy megbízhatósággal látja el a számítási feladatait. 3.5 A szoftver redundancia megvalósítása A hibatűrés magas fokon való elérése megköveteli a szoftver-hibák elfedését, ami plusz szoftvert igényel, másrészt pedig, mint tudjuk, a hardverhibákhoz is szükség van a többlet-szoftver alkalmazására. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 31 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 32 ► A szoftver

hibatűrés két céllal valósítható meg: • A szoftver saját hibájának elfedésére. • A szoftver saját és a hardver hibáinak együttes elfedésére. A második feltétel magában foglalja az elsőt is, ezért a követendő megoldásként ezt érdemes választani. A továbbiakban csak ilyen megoldásokkal foglalkozunk. Először vizsgáljuk meg azt a struktúrát, amelyben a hardver megkettőzése szerepel (3.4 ábra) Tegyük fel, hogy mindkét csatornában ugyanaz a szoftver van telepítve, és a csatornák CPU-ja is megegyezik, vagyis SW1 ≡ SW2, valamint CPU1 ≡ CPU2. SW1 SW2 CPU1 CPU2 Összehasonlító 3.4 ábra Kétcsatornás szoftverműködés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 32 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 33 ► Ebben a struktúrában a szoftverben előforduló hibák

detektálására semmilyen lehetőség nincsen, mivel mindkét csatorna hibásan is azonosan működik, s így az összehasonlító ezt helyes működésnek érzékeli. Hardverhiba esetén a csatornák között eltérés fog mutatkozni, ami hibadetektálásra vezet Ha egy TMR-rendszerben alkalmazzuk ugyanezt az elrendezést, akkor sem változik a helyzet, az ismétlődő szoftver hibáját ilyenkor sem lehet észlelni. A megoldás kulcsa abban áll, hogy elkerülendő a teljesen azonos szoftverek alkalmazása. Ezt úgy valósíthatjuk meg, hogy a különböző csatornák szoftverje nem lesz azonos, viszont ugyanazt a működést várjuk el az egyes változatoktól. Ezt az elvet szoftver diverzitásnak nevezzük A következőkben két olyan megoldást mutatunk be, amely a szoftver hibatűrést szolgálja a diverzitási elv érvényesítésével. 3.51 N-verziós programozás Az N-verziós programozásban a teljes szoftvert N db. példányban valósítják meg, két lehetséges

megközelítésben: • Ugyanazt a programozási nyelvet alkalmazva, egymástól független, különböző fejlesztő csoportok, teamek. • Eltérő programozási nyelveket alkalmazva, egymástól független, különböző fejlesztő csoportok, teamek. A fejlesztő csoportok ugyanazt a specifikációt realizálják. Eltérő nyelvek esetén az egymástól való függetlenségük azt a célt szolgálja, hogy nehogy ugyanazokat a hibákat kövessék el és vigyék bele a szoftverbe. Az N-verziós rendszer működése a következő: Az N program a számítógépes szervezéstől függően lefut, akár párhuzamosan, akár sorosan. Előbbi esetben N db. CPU vesz részt a feldolgozásban, utóbbi esetben csak egyetlen CPU. Az egyes programverziók ugyanazokat a bemenő adatokat használják, és a kimenő adatok összehasonlítódnak Az összehasonlítást egy erre a célra elkészített program végzi N = 2 esetén, ha párhuzamos feldolgozás történik, csak a hibadetektálás ténye

derül ki. A hibás szoftver-komponensre, vagy a hibás hardverre nem kapunk információt. Egymást követő feldolgozások esetén ugyanez a helyzet, azzal a különbséggel, hogy a hardverben fellépő esetleges átmeneti hiba detektálására is sor kerülhet. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 33 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 34 ► Ennél hatékonyabb megoldás az N = 3, ahol mód nyílik a TMR-szisztéma alkalmazására, egy a szavazást megvalósító programkomponens bevonásával. Ez a szervezés lehetővé teszi a hibás szoftver meghatározását, és hibájának eltűrését is. A számítógépes implementáció meglehetősen költséges, hiszen ugyanazt a szoftvert többszörösen kell kifejleszteni. A futtatás szervezése is plusz fejlesztést kíván. Akár párhuzamos a feldolgozás, akár soros,

a futási eredmények eltárolásáról és összehasonlításáról külön kell gondoskodni. Esetenként ez igen komoly adatmennyiség kezelését teheti szükségessé. A magas létrehozási költségek korlátozták a módszer elterjedését. Az egyik jellegzetes megvalósítás az Egyesült Állomokban történt, ahol az AIRBUS A–330/340 nagyteljesítményű repülőgép fedélzeti irányító számítógépén hoztak létre TMR-rendszerű szoftvert. 3.52 A javító blokkok módszere A szoftverhibák elfedésének egy másik módszere az ún. javító blokkok (recovery blocks) alkalmazása. Ebben a teljes szoftvert több modulra bontják, és az egyes modulok többverziós megvalósításával, valamint a modulok önteszteléssel egybekötött újrafuttatásával érhetjük el a hibatűrést. A végrehajtás elve a következő: Egy-egy modul azonos funkciójú verziói alkotnak egy blokkot. Mindegyik blokkhoz tartozik egy ún elfogadási teszt (acceptance test), ami egy külön

program az esetleges hibás működés detektálására. A feldolgozásban a modulok egymás utáni futtatására kerül sor, ahol minden futást az elfogadási teszt végrehajtása követ. Ha egy modulverziót elfogad a teszt, újabb verzióra nem kerül sor, a következő blokk első verzióján lesz a sor Ha egy modulverzió hibásnak bizonyul a teszt alapján, akkor a soron következő tartalékmodul futtatására kerül sor, a blokkon belül Ha ez is hibás a teszt szerint, újabb modulra kerül sor stb, mindaddig, amíg csak van futtatható modulverzió. A javítás (felépülés, recovery) elve akkor érvényesül egy blokkban, ha egy hibás modult egy jó modul futása követ. Ha egy blokkban mindegyik modulverzió hibásnak bizonyul, akkor a teljes futás véget ér. Egy új blokk futtatása előtt mindig el kell menteni az addig előállt öszszes adatot egy független tárba. Ha hibát talál az ellenőrzés, az új modul futtatása ebből az elmentett állapotból kell hogy

történjék. Az elfogadási tesztek megírása igen komoly szellemi ráfordítást igényel. A programmodul és a működési környezet alapos ismerete és tanul- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 34 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 35 ► mányozása szükséges hozzá. Egzakt módszerek nem állnak rendelkezésre Néhány követendő irányelv lehet a következő: • Annak ellenőrzése, hogy egy kiszámított érték az elfogadható normális fizikai tartományba esik-e (például, hőmérséklet vagy nyomás). • Nem történt 0-val való osztás. • Nem történt címtartományon kívüli címzés, a tömbdeklarációk figyelembevételével. • Egy-egy fontos számérték meghatározása alternatív algoritmussal is megtörténik. Végezetül megemlítjük még, hogy a javító blokkok elve az elosztott

számítógépes rendszerekben is alkalmazást nyert. Az ilyen rendszerekben több különböző számítógép (csomópont) vesz részt egy-egy feladat megoldásában, az erőforrások összehangolt, automatizált elosztásával. Ilyen szervezésben előfordulhat az is, hogy egy modul ismételt végrehajtására egy másik csomóponton kerül sor, ha az előző csomópont hibásnak bizonyult 3.6 Az ELEKTRA típusú vezérlőrendszer felépítése és működése A szoftver diverzitáson alapuló hibatűrés egyik érdekes gyakorlati példáját adja az ALCATEL-AUSTRIA AG. cég által tervezett és gyártott számítógépes vasútirányító rendszer, melynek típusneve ELEKTRA Az ELEKTRA egy ún biztosítóberendezés, amely vasúti pályaudvarok forgalmának irányítására szolgál A felhasználásból adódóan ez is biztonságkritikus rendszer, kötelezően előírt hibatűréssel. A számítógépes vezérlőrendszer kétoldalú információs kapcsolatban áll az általa

felügyelt pályaudvarral, ahol az ún. külsőtéri berendezések, a jelzőlámpák, sorompók, vágányváltók helyezkednek el. A bejövő információ a vonatok, szerelvények mozgására, helyzetére utal. A kimenő információ a külsőtéri berendezések automatizált vezérlésére szolgál Mindezt a 35 ábra szerinti felépítésben is szemléltetjük Az ALCATEL-ELEKTRA megkettőzött párhuzamos felépítésű rendszer, amelyben a két párhuzamos csatornához (A és B csatorna) egymástól eltérő fejlesztésű szoftverek tartoznak. Az ELEKTRA felépítését a 36 ábra mutatja be. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 35 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 36 ► Számítógépes irányítórendszer Vasúti pályaudvar irányító központja Hardver interfész Külsőtéri berendezés: jelzőlámpák,

váltók Pályaudvar 3.5 ábra Vasúti irányítórendszer vázlata 2. Számítógéprendszer 1. Számítógéprendszer A B Összehasonlító Csatorna Csatorna Logikai csatorna Biztonsági csatorna Hardver interfész Irányított folyamat 3.6 ábra Az ALCATEL-ELEKTRA rendszer felépítése A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 36 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 37 ► Az A csatorna elnevezése: logikai csatorna. A B elnevezése: biztonsági csatorna Normál, hibamentes üzemben a pályaudvar irányítását az A csatorna intézi. A két csatorna szoftverei között lényeges működésbeli különbség van, a következők szerint: 1. Az A csatorna szoftvere egy CHILL programozási nyelven elkészített procedurális végrehajtású program. (A CHILL magas szintű programnyelv, a telekommunikáció területén

fejlesztett valós idejű (real-time) rendszereknél terjedt el a felhasználása.) A bemenő adatok a külső pályaudvari események, helyzetek, amiknek alapján a program lefut, és ennek eredményeként kiadja a szükséges vezérlő jeleket a pályaudvar felé 2. A B csatorna szoftvere nem procedurális program, hanem egy önálló szakértői rendszer. Elnevezése: SAFETY BAG (biztonsági csomag) Létrehozása a PAMELA nevű fejlesztői környezetben ment végbe A rendszer tudásbázisa szabályalapú: több mint 800 szabályt tartalmaz. A szabályok PAMELA nyelven íródtak. (PAMELA: PAttern Matching Expert System LAnguage.) A SAFETY BAG egy-egy szabályának struktúrája: „Ha egy adott esemény vagy eseménylánc következett be, akkor egy előre definiált intézkedésre van szükség.” Például: „IF track 27 is occupied AND signal 33 is free THEN set signal 33 to stop” Ennek értelmezése: HA a 27-es vágány foglalt ÉS a 33-as jelző szabad, AKKOR állítsd a

33-as jelzőt „állj”-ra. Amikor egy helyzetet elemez a szakértői rendszer, akkor azt vizsgálja végig, hogy az összes szabály közül melyek azok, amelyeket figyelembe kell venni az adott helyzetben, ill. melyeket nem, és a szerint kell döntést hozni a pályaudvari teendőket illetően. A működési folyamat a következő: • Az A jelű csatorna a forgalomirányítás bejövő jeleit dolgozza fel logikailag, az adott helyzetet elemzi, kiértékeli, és a szükséges vezérlő jeleket küldi ki. • A B csatorna a biztonsági működést szolgálja. A bejövő jeleket elemzi, döntést hoz, majd megvizsgálja az A csatorna döntését. Ha azt elfogadja, az A intézkedése kimegy Ha nem fogadja el, akkor a következő esetek lehetségesek: 1. B veszi át az intézkedést 2. B tiltó jelet ad ki a forgalom korlátozására 3. B leállítja a forgalmat A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 37 ►

Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 38 ► A döntéshozatalhoz mindkét csatorna a TMR-struktúrát alkalmazza saját magán belül, a biztonság növelése érdekében. Ez azt jelenti, hogy a szoftver is háromszorozva van a két ág CPU-ival együtt, mind az A-ban, mind a B-ben külön-külön. A csatornák kevésbé kritikus helyein (a monitorok vezérlése, ill. a hardver interfész vezérlése) már csak megkettőzött párhuzamosítást terveztek be A csatornák több ponton el vannak látva öntesztelő egységekkel is. Az ezekhez elkészített tesztprogramok szintén a szoftver részét képezik. Az öntesztelés a hardver hibák felfedésére irányul. Hibadetektálás esetén a hiba helye az áramköri kártya szintjéig automatizáltan behatárolódik, és kijelzésre kerül. A működési helyzettől függően egyes kártyák üzem közben is kicserélhetők,

mások cseréje előtt a rendszert le kell állítani Ekkor a kártyacserét követően újraindításra kerül sor. Az A meghibásodása esetén B intézkedik a forgalomirányításról, és viszont: ha B-ben lép fel hardver-hiba, akkor az A egyedül végzi az irányítást. Ez az ideiglenes állapot a kártyacsere végrehajtásáig áll fenn Az ELEKTRA szisztéma hibalefedési képességeit tekintve az alábbi megállapításokat tehetjük: 1. A párhuzamosan, valamint a TMR-ben szervezett működtetés nemcsak az állandósult, hanem az átmeneti hardver-hibák felfedésére is alkalmas Ezeknek a hibáknak a felfedéséhez mindkét csatorna szoftvere is hozzájárul. 2. A két csatorna egymástól gyökeresen eltérő szoftvermegoldása lényegesen növeli a biztonságot, ahol a két szoftvernek ugyanazt a feladatot kell ellátnia, és az eredményeik mindig szembesítve vannak egymással. Ez a konstrukció egyrészt lehetővé teszi a meglevő szoftver-hibák detektálását,

másrészt pedig azoknak a hibáknak a detektálását is, amelyeket még a tervezés során sem tudtak előre számításba venni. Ezen túlmenően, a diverzitás megvalósítási módjából még egy nagyon fontos következmény is származik: Nevezetesen az, hogy ezáltal olyan üzemelési veszélyek elkerülése is lehetővé válik, amelyekkel a tervezési folyamatban nem kalkuláltak. A teljes hardver-szoftver komplexum hibadetektálása és hibatűrése a következő módon elemezhető: Jelöljük az összes, elvileg lehetséges, tervezési és működési hiba halmazát H-val. A H halmazt az alábbi részhalmazokra tudjuk felosztani (37 ábra): A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 38 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 39 ► • HE: Az előre feltételezett és detektálható hardver-hibák halmaza, amelyek

felfedéséről a tervezés során gondoskodás történt (vagyis az ELEKTRA bizonyíthatóan felfedi ezeket a hibákat). • HN: Olyan hibák, amelyek bekövetkezésével nem kell számolni, mert felismerésükről és elkerülésükről az ELEKTRÁ-n kívül külön történt gondoskodás. (Például: kábelezési hibák) • HI: A biztonságra nem ható, irreleváns hibák köre. • HU: Azon hibák köre, amelyekről nincs semmilyen előzetes tudomásunk. Ide tartoznak azok a veszélyes forgalmi helyzetek is, amelyek kezelése a tervezés során nem volt kalkulálva és megoldva HE HN H: HU HI 3.7 ábra A lehetséges hibák felosztása Mindezek után írható, hogy H = HE ∪ HN ∪ HI ∪ HU. A teljes halmazban nem jelent gondot a bizonyítottan lefedett, valamint a veszélyt nem okozó hibák köre. Biztonsági okokból egyedül a HU halmaz hibáinak egy része a kritikus, ezek idézhetnek elő balesetet. Vizsgáljuk meg ezt a halmazt közelebbről. Legyen azoknak a hibáknak

a halmaza HA, amelyeket nem ismerünk, és amelyek megnyilvánulása, jelentkezése az A csatorna működésének a következménye. Ugyanígy, legyen azoknak a hibáknak a halmaza HB, ame- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 39 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 40 ► lyeket nem ismerünk, és amelyek megnyilvánulása, jelentkezése a B csatorna működésének a következménye. A két halmazt a 38 ábrán tüntettük fel HB HA 3.8 ábra A szoftverdiverzitás eredménye Legyen továbbá azoknak a hibáknak a halmaza HX, amelyeket nem ismerünk, és hatásuk teljesen kívül esik az ELEKTRA működési körén. Ezek után felírható a következő összefüggés: HU = HA ∪ HB ∪ HX. Az összefüggést a 3.9 ábra illusztrálja HA HB HX 3.9 ábra Az ismeretlen hibákat képviselő halmazok A HA és HB

halmazok egymással diszjunkt részei olyan hibákat foglalnak magukban, amelyekre a két csatorna eltérően reagál, így azok a hibák a csatornák közötti működési összehasonlításban detektálódnak. Ezzel szemben nem áll fenn ugyanez a két halmaz közös részére: Az ide tartozó A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 40 ► Szoftver-minőségbiztosítás Biztonságkritikus rendszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 41 ► hibákra vagy egyformán reagál a két csatorna, vagy pedig a B nem veszi észre, hogy az A helytelenül reagált. Végeredményben tehát kimondható, hogy azoknak az ismeretlen hibáknak a HV halmaza, amelyek potenciális katasztrófaveszélyt jelentenek, a következő összefüggéssel írható le: HV = HA ∩ HB ∪ HX. A HV halmaz tehát a biztonságot veszélyeztető hibákat hordozza magában. Annak az ideális tervezési célnak az

elérése, hogy ez a halmaz abszolút üres legyen, lehetetlen Mindazonáltal arra kell törekedni, hogy HV minél kisebb mértékű legyen Ennek eléréséhez a tervezési és fejlesztési folyamat szigorú szabályainak betartására, másrészt pedig az elkészült rendszer külön biztonsági vizsgálatára van szükség Ezekkel a témakörökkel az 5. fejezetben fogunk részletesebben foglalkozni A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 41 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 42 ► 4. Szoftver-tesztelési módszerek 4.1 Tesztelési alapfogalmak A következőkben a szoftverek teszteléséhez kapcsolódó legfontosabb fogalmakat és definíciókat soroljuk fel. Definíciók Bemeneti adat: Olyan számítógépes adat, amely egy tetszőleges szoftver működtetését vonja maga után, felhasználói szinten. Kimeneti adat:

Olyan számítógépes adat, amely egy tetszőleges szoftver működtetése során jelenik meg, a működtetés eredményeként, felhasználói szinten. Hibamodell: Azon szoftverhibák halmaza, amelyeknek a felfedésére irányul a teszttervezés. Tesztelés: A szoftver bemeneti adatokkal való sorozatos ellátása és a kimeneti válaszadatok megfigyelése. Egy hiba tesztje: Bemeneti adatok olyan rendezett sorozata, melynek hatására az adott hibát tartalmazó szoftver a legutolsó adatkombinációra a helyestől eltérő (hibás) kimeneti adatkombinációval válaszol. Ebben az esetben azt mondjuk, hogy a teszt kimutatja, felfedi vagy detektálja a hibát. Itt használatban van még az a kifejezés is, hogy a teszt lefedi az adott hibát. Detektálható hiba: Egy hibáról akkor mondjuk, hogy detektálható, ha legalább egy tesztje létezik. (Tervezési redundancia folytán létezhetnek olyan hibák, amelyek semmilyen körülmények között nem éreztetik hatásukat a szoftver

egészének működésében. Az ilyen hibák nem detektálhatók a teszt definíciója értelmében.) Tesztkészlet: Több hiba tesztjeinek együttese, halmaza. Tesztkészlet hibalefedése (fault coverage): Azon hibák százalékos aránya az összes feltételezett hibához képest, amelyeket a tesztkészlet detektálni tud. Másként megfogalmazva: Azon hibák százalékos aránya az összes feltételezett hibához képest, amelyeknek van tesztjük a tesztkészletben. Az elérendő cél a 100%-os lefedést produkáló tesztkészlet létrehozása. Teljes tesztkészlet/teszthalmaz: Teszteknek olyan összessége, amely a szoftver mindegyik előre feltételezett és detektálható hibájának tesztjét A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 42 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 43 ► magában foglalja. Az ilyen

teszthalmazról azt mondjuk, hogy teljes hibalefedést eredményez A teljes teszthalmaz 100%-os hibalefedésű Teszttervezés: Az a tervezési folyamat, amelyben egymás után meghatározzuk az egyes előre feltételezett szoftverhibák tesztjét. Ennek során megtörténik a bemeneti tesztek és az ezekre elvárt válaszadatok meghatározása az előre feltételezett hibahalmazra nézve. A számítások mindenkori célja egy olyan tesztsorozat előállítása, amely képes az összes előre definiált hiba felfedésére, amikor az adott létező szoftveren végrehajtjuk a teszteljárást. Megjegyzés: A mai információ-technológia már olyan bonyolult szoftver-rendszerek előállítását teszi lehetővé (milliós számban tudnak utasításokat tartalmazni), hogy a teljes hibalefedés elérése gyakorlatilag nem valósítható meg. Általában a 90%-on felüli minél jobb lefedés a reális és elfogadható cél Tesztszámítás vagy determinisztikus tesztgenerálás: Egy adott

hiba tesztjének szisztematikus számításokkal történő meghatározása. Véletlenszerű/random tesztgenerálás: Bemenő adatok sorozatának véletlenszerű képzése a hibák tesztjeként történő felhasználásra. (Angolban: random test generation) Ilyenkor a bemeneti tesztadatokat egy adott tartományban használt véletlenszám-generátorral állítjuk elő. 4.2 Hibamodellek és érvényességi körük Hibamodellnek nevezzük azoknak az előre feltételezett hibáknak a konkrét halmazát, amelyekre vonatkozóan a teszttervezést végre kívánjuk hajtani. Több fajta hibamodell létezik a gyakorlatban. Egy hibamodell meghatározásakor a következő főbb szempontokat érdemes tekintetbe kell venni: • A teszttervezés kivitelezhetőségi lehetőségei és a ráfordítandó költségek. • Az adott fejlesztési technológiához kapcsolódó hibajelenségek előzetes ismerete. • A tesztelés végrehajtásához szükséges hardver és szoftver eszközök által nyújtott

szolgáltatások köre. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 43 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 44 ► Megjegyzés: A publikált gyakorlati tapasztalatok alapján általában megállapítható, hogy a szoftver rendszerek fejlesztési és előállítási költségében a tesztelési folyamatok megtervezésére és végrehajtására fordítandó költség több mint 50%-ot tesz ki. A technológiák fejlődésével folyamatosan növekszik a rendszerek bonyolultsága és mérete, ami végső soron a tesztköltségek arányának növekedését vonja maga után Mindebből az következik, hogy folyamatosan szükség van újabb és hatékonyabb módszerek, eszközök kidolgozására mind a teszttervezés, mind pedig a tesztvégrehajtás területén. A következőkben a használatban levő fontosabb hibamodelleket tekintjük

át. Fontos megjegyezni, hogy a szoftver-hibák mindig jelen vannak a működés során, a kérdés csak az, hogy milyen módon nyilvánulnak meg Szoftver hibák a) Szoftver specifikációs hibák A fejlesztés kezdetekor megjelenő hibák, amelyek a szoftver előre megadott, specifikált működési funkcióiban nyilvánulnak meg, mégpedig oly módon, hogy a szoftver valamilyen vonatkozásban nem teljesíti a felhasználói követelményeket. A specifikációs hiba adódhat: téves specifikációból, ellentmondásos specifikációból, valamint hiányos specifikációból b) Programozói hibák A szoftver tervezése és kódolása során a programozó által elkövetett hibák körét foglalja magában. A lehetséges hibák az alábbiak: • • • • • • • • • • • Hibás funkcióteljesítés. Hiányzó funkciók. Adatkezelési hibák az adatbázisban. Indítási (inicializálási) és leállítási hibák. Felhasználói interfész hibái Határértékek

túllépése Kódolási hiba Algoritmikus hiba Kalkulációs hibák Inicializálási hiba Vezérlési folyamat hibája A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 44 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 45 ► • Adattovábbítási hiba • Versenyhelyzet programblokkok között • Terhelési hiba A következő alpontokban a teszttervezés legfontosabb megközelítési módjaival foglalkozunk. Ezekhez kapcsolódóan olyan determinisztikus módszereket mutatunk be, amelyek felhasználásával a különböző hibák tesztjeit tudjuk megkeresni. 4.3 A tesztek megtervezése Annak érdekében, hogy betekintést kapjunk a számítógépes programok tesztelési feladatának összetettségébe, vegyünk egy egyszerű példát. Tegyük fel, hogy a következő funkciót teljesítő programot kell ellenőriznünk: A program beolvas

három egészszámot, amelyek egy háromszög oldalainak hosszát képviselik. A feladata annak meghatározása, hogy az így előálló háromszög szabálytalan, egyenlő szárú, vagy pedig egyenlő oldalú. Ha tesztelni akarjuk az elkészült programot, akkor a következő vizsgálatokat, teszteket végezhetjük el rajta: 1. Három olyan számot adunk meg, amelyek egy érvényes háromszöget tesznek ki. 2. Három olyan számot adunk meg, amelyek egyenlők, vagyis egyenlő oldalú háromszöget alkotnak. 3. Két egyenlő és egy ettől különböző számot adunk meg, melyek így egyenlő szárú háromszöget adnak. 4. Olyan számokat adunk meg, amelyek közül kettőnek az összege kisebb, mint a harmadik szám 5. Olyan számokat adunk meg, amelyek közül kettőnek az összege egyenlő a harmadikkal 6. Három 0-t adunk meg 7. Olyan számokat adunk meg, melyek között nem egész szám is van 8. A három szám között negatívat is magadunk Az érvénytelen bemeneti adatokra

azért volt szükség, hogy ellenőrizzük, hogyan reagál rájuk a program. Ha elfogadná valamelyiket, akkor az programhiba lenne A fenti vizsgálati esetek még egyáltalán nem elegendőek arra, hogy mindegyik elvileg lehetséges hibát fel tudják deríteni. Ebből is látható, hogy egy ilyen egyszerű program tesztelése sem könnyű feladat. Mindez A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 45 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 46 ► tehát azt jelenti, hogy például egy többszázezer utasításból álló szoftver megbízható leellenőrzése beláthatatlan bonyolultságú feladat tud lenni. Ami a tesztek megtervezésének kérdését illeti, erre vonatkozóan két alapvető megközelítés létezik: a funkcionális, valamint a strukturális. Ezeknek a lényegét a következő két alpontban írjuk le. 4.31 A

funkcionális tesztelés alapelve Funkcionális tesztelésről beszélünk akkor, amikor a programot egyedül csak a külső viselkedésében, az előírt funkcióinak teljesítésében vizsgáljuk azáltal, hogy a bementi adatokra kapott kimeneti válaszadatokat figyeljük meg, a futtatható tárgykód felhasználásával. Ebben a megközelítésben egyáltalán nem vesszük figyelembe a forráskódot, még a program megírási nyelvét sem, vagyis a programot olyan egységnek tekintjük, amibe nem „látunk bele”. Emiatt szokás még ezt a megoldást fekete doboz vagy vasdoboz tesztelésnek is nevezni (angolban black-box testing, iron-box testing) A funkcionális tesztelésben a szoftver minden egyes specifikált funkciójának a sorra vétele és leellenőrzése a cél, ezen kívül pedig még az is, hogy nincs-e valamilyen téves, nem betervezett tevékenysége a programnak. 4.32 A strukturális tesztelés alapelve Strukturális tesztelésről beszélünk akkor, amikor a

szoftver forráskódjának felhasználásával a belső struktúra, a belső működés végigkövetésére irányul az ellenőrzés. Ebben a megközelítésben a tesztelési adatok megtervezése során az a cél, hogy a forráskód utasításainak és elágazásainak minél alaposabb végigjárását tudjuk elérni. Itt a programot tehát olyan egységnek tekintjük, amibe „belelátunk”. Emiatt szokás még a fehér doboz vagy üvegdoboz tesztelés elnevezések használata is (Angolul: white-box testing, glass-box testing.) A strukturális teszteléssel a program minden egyes utasításának a végrehajtását, a döntési elágazások lehetséges végrehajtásait, valamint a ciklusok végrehajtását kell ellenőrizni. A kódbejárás tárgyalását megkönnyíti az ún. vezérlési folyamatgráf (VFG) (angolul: control-flow graph, CFG) fogalmának a bevezetése és felhasználása. A vezérlési folyamatgráf egy olyan irányított gráf, melyben minden egyes csomópont megfelel

egy programutasításnak. Az egymást soron követő A és B utasítás csomópontjait úgy köti össze az irányított él, hogy az A pontjából a B-jébe mutat. Egy döntési utasítás (például IF THEN ELSE, vagy CASE) csomópontjából annyi irányított él indul ki, ahány felé történhet a A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 46 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 47 ► döntéshozatal feltételes elágazása. A feltétel nélküli elágazást (GO TO) reprezentáló pontból kivezető irányított él az elágazást követő utasítás pontjához vezet A ciklusutasításokat (például FOR DO, REPEAT WHILE) egy visszafelé irányuló hurokél reprezentálja. Mint látható, a VFG a programok végrehajtási menetének az elvont ábrázolására szolgál, a végrehajtás strukturális vázát hordozza

magában. A gráf egyes csomópontjai között definiáljuk az út fogalmát: Az Si és Sj utasítások közötti út P(Si, Sj), az egymást követő csomópontok azon sorozata, amely Si-vel kezdődik és Sj-vel ér véget. Az Si és Sj között több lehetséges út létezhet. 4.4 A programtesztelés pszichológiája és gazdaságossága (Glenford Myers elvei) Jóllehet a tesztelés témakörét számos technikai szempontból tárgyalhatjuk, úgy tűnik, hogy a legfontosabb szempontok a pszichológiához és a gazdaságossághoz kötődnek. Más szóval, az olyan megfontolások, mint a teszteléshez való szellemi hozzáállás, egy program teljes tesztelésének kivitelezhetősége, vagy ki legyen a tesztelés elvégzője, jóval többet számít a végrehajtás sikerében, mint a technikai megfontolások Ezekkel a kérdésekkel Glenford Myers (USA) foglalkozott behatóbban. Először is, vizsgáljuk meg a tesztelés céljának kérdését. Szokásos megfogalmazások a következők:

• Annak bizonyítása, hogy nincsenek a programban hibák. • Annak bizonyítása, hogy a program a neki szánt funkciókat helyesen hajtja végre. Ezek a definíciók helytelenek, mivel éppen az ellenkezőjét írják le annak, aminek a tesztelést tekintenünk kellene. Egy program értékét akkor tudjuk növelni, ha javítjuk a minőségét és megbízhatóságát. A megbízhatóság növelése azáltal érhető el, hogy megkeressük és eltávolítjuk a hibákat. Abból a feltevésből kell tehát kiindulnunk, hogy a program hibákat tartalmaz, és azért teszteljük, hogy minél több hibát fedjünk fel benne. Eszerint: • A tesztelés célja a program olyan végrehajtása, amelyben a szándékunk a hibák megtalálása. Itt azonnal adódik a kérdés, hogy mód van-e arra, hogy az összes hibát megtaláljuk. A válasz egyértelműen negatív, még az egyszerűbb esetekre nézve is. Az általános gyakorlatban nem érdemes, vagy éppenséggel lehe- A dokumentum használata

| Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 47 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 48 ► tetlen mindegyik hibát kiszűrni. Ez az alapvető probléma kihatással van a tesztelés gazdaságosságára, a programra vonatkozó előzetes feltevésekre, és nem utolsó sorban a tesztek tervezésének módjára. A funkcionális megközelítésben a programot fekete dobozként kezeljük, ahol nem ismerjük a belső viselkedést és struktúrát. Ilyenkor a tesztelő abban érdekelt, hogy a specifikációtól eltérő működést fedezzen fel. Az ehhez szükséges bemenő adatokat tehát a specifikáció alapján lehet előállítani. Az összes lehetséges hiba megtalálásának egy biztos módja a kimerítő inputtesztelés, vagyis az összes lehetséges bemenő adat felhasználása. A háromszöges programban például az összes, a számítógépen létező

egészszámot kellene a különböző hármas kombinációkban megadni Az ilyen esetek száma csillagászati. De még ez sem lenne elég: például nem fedné fel azt a hibát, aminél a program a {2, A, 2} halmazból egyenlőszárú háromszöget hozna ki. A bonyolultabb programok kimerítő tesztelése még inkább lehetetlen. Egy Pascal fordítóprogramnál például olyan teszteket kellene készítenünk, amelyben az összes érvénytelen Pascal programot írjuk le, elvárva azt, hogy a kompájler mindegyiket érvénytelennek tudja nyilvánítani. Ha valamelyiket helyes programnak fogadná el, az már hiba lenne A probléma még súlyosabb az olyan szoftverek esetében, amelyek „memóriával” rendelkeznek. Ezeknél egy tranzakció végrehajtása függ attól, hogy mi történt, mi hajtódott volt végre azt megelőzően Például egy operációs rendszernél korábban melyik munkafolyamat (job) ment le Ilyenkor tehát nem elég az érvényes és érvénytelen tranzakciókat

végigpróbálni, hanem a tranzakciók összes lehetséges sorozatát is. Az előbbi diszkusszió azt támasztotta alá, hogy a kimerítő inputtesztelés lehetetlen. Ebből két következtetést vonhatunk le: Nem lehet egy programot úgy tesztelni, hogy garantálni tudjuk annak hibamentes voltát. A tesztelés alapvető szempontja a gazdaságosság, vagyis annak elérése, hogy minél több hibát fedjünk fel egy véges számú vizsgálattal. A másik stratégia a strukturális megközelítés, amelyben a forráskód alapján végezzük a vizsgálatokat. Ebben az esetben a kimerítő inputtesztelés analógja a forráskód összes lehetséges módon történő végigpróbálása, bejárása volna. A teljes bejáráshoz egyáltalán nem elegendő, ha az összes utasítás végrehajtódik legalább egyszer. Ettől még hibás határok között futhat le egy ciklus, vagy hibás döntésű elágazásokra kerülhet sor. Az ana- A dokumentum használata | Tartalomjegyzék | Felhasznált

irodalom Vissza ◄ 48 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 49 ► lóg párhuzam itt a kimerítő úttesztelés lehet, vagyis az összes lehetséges végrehajtási út végigpróbálását eredményező vizsgálati input megadása. A kimerítő úttesztelés ugyancsak beláthatatlan mennyiségű számítással járna. Ennek demonstrálására tekintsük a 41 ábrán szereplő vezérlési folyamatgráfot. A B 4.1 ábra Egy ciklusos vezérlési folyamatgráf A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 49 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 50 ► A példa folyamatgráfja mintegy 15-20 utasítást tartalmazó egyszerű programot képvisel. Tegyük fel, hogy az egyetlen DO-ciklus maximum 20-szor hajtandó

végre. A DO-cikluson belül beágyazott IF-utasítások halmaza helyezkedik el. Az elkülönülő logikai utak számának meghatározása ugyanazt jelenti, mint az A pontból a B-be való eljutás különböző lehetséges módjainak megszámlálását. Ha feltesszük, hogy a gráfon mindegyik döntés független egymástól, akkor ez a szám megközelítőleg 1014, vagyis 100 trillió lesz. A pontos értéket a következő összeg kiszámításával kaphatjuk meg: 520 + 519 + 518 + + 51, ahol 5 a hurokban található utak száma. Ha feltételezzük, hogy egy teszt megírása, végrehajtása és leellenőrzése 5 percet igényel, akkor a teljes folyamat körülbelül egy milliárd évig tartana. Természetesen a valóságos programokban a döntési elágazások általában nem függetlenek egymástól, vagyis a bejárandó utak száma ezáltal kevesebb lesz. Ugyanakkor azonban a valóságos programok jóval bonyolultabbak, mint a példában szereplő Ebből látható, hogy a

kimerítő úttesztelést sem lehetséges a gyakorlatban alkalmazni A másik gondot az jelenti, hogy nem állítható, hogy a kimerítő útteszteléssel fel tudjuk fedni az összes programhibát. Az egyik oka ennek az, hogy egyáltalán nem biztos, hogy a letesztelt program teljesíti a specifikációját. Ha például egy növekvő sorba rendező rutin helyett egy csökkenő sorba rendezőt írunk, akkor a kimerítő úttesztelés ezt nem tudná detektálni. A másik ok az, hogy egy program téves lehet attól is, hogy hiányoznak belőle utak. Az úttesztelés ilyenkor nem lenne képes kimutatni a hiányzó utakat. A harmadik gond az, hogy ez a megközelítés esetleg nem mutat ki ún. adatérzékenységi hibákat, vagyis olyan hibákat, amelyek csak az adatok bizonyos értékei mellett lépnek fel. Erre egy egyszerű példa az olyan öszszehasonlítás, amelyben azt akarjuk eldönteni, hogy két változó adat közti eltérés kisebb-e, mint egy előre megadott érték

(konvergencia-vizsgálatnál jelentkező feladat). Ha a következő utasítást vesszük, ami IF ((A – B) < EPSZILON) THEN . alakú, akkor látható, hogy az hibás, mivel az A – B különbség abszolút értékét kellett volna vennünk. Ennek a hibának felfedése azonban függ az A és B konkrét értékétől, és nem biztos, hogy a program összes útjának a szisztematikus bejárása kihozza ezt a felfedést. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 50 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 51 ► Összegezve kijelenthetjük, hogy bár a kimerítő inputtesztelés fölötte áll a kimerítő úttesztelésnek, egyikük sem fogadható el követendő stratégiaként, mivel nem lehet őket kivitelezni. Tesztelési elvek A következőkben néhány általános irányelvet sorakoztatunk fel a tesztelés minél

célszerűbb végrehajtására vonatkozóan. • Egy tesztnek szükséges része az elvárt kimenet vagy eredmény definiálása. Ezt az egyszerű elvet sok esetben figyelmen kívül szokták hagyni. Ha az elvárt eredmény nincs előre megadva, esély van arra, hogy egy látszólag jónak tűnő eredményt fogadjon el a tesztelő személy. Ez a folyamat ismét összefügg a szubjektivitásra való hajlammal. A helyes megoldásban tehát egy tesztelési eset mindig a következő összetevőből kell hogy álljon: a programnak szánt bemeneti adatok leírása, valamint a program kimenő adatainak precíz leírása ugyanarra a bemeneti halmazra. • Célszerű a tesztelést a fejlesztéstől független személy vagy szervezet által elvégeztetni. Az, hogy egy programozó saját maga ellenőrizze le a programját, több hátránnyal jár. Egyrészt nincs arra motiválva, hogy minél több saját hibát fedjen fel. Másrészt a saját félreértéseiből adódó eltérésekre, hibákra

nem valószínű, hogy rá fogna érezni. Természetesen járható út a saját ellenőrzés is, azonban hatékonyabbnak és sikeresebbnek várható el a külső fél munkája. (Mindezek a megfontolások nem vonatkoznak a fejlesztés során történő hibakeresésre, nyomkövetésre, mivel ott a programozó által menet közben felismert hibákról van szó.) Egy fejlesztési szervezet szempontjából hasonló érvek hozhatók fel, mint egy személy esetében. Másrészt azonban egy teamnél jelentkezik még egy fejlesztési folyamat határidős lezárásának igénye is. Ebben hátráltatná őket egy alapos, mindent átfogó objektív tesztelés saját erőből történő elvégzése. • A teszteket nemcsak elvárt és érvényes bemeneti feltételekre kell írni, hanem olyan feltételekre is, amiket nem várunk el, ill. amik érvénytelenek Ennek az elvnek a hasznosságát a tapasztalat támasztja alá. Nagyon sok hiba derült már ki olyankor, amikor a programot nem kellő

hozzáértéssel vagy szokatlan módon használták fel. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 51 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 52 ► • Annak a valószínűsége, hogy egy programszakaszban még hibák léteznek, egyenesen arányos az ugyanott már megtalált hibák számával. Ezt a jelenséget, amit a gyakorlati tapasztalat igazol, a 4.2 ábrán szemléltetjük Például, ha egy program két modulból áll, A-ból és B-ből, és A-ban öt hibát találtunk eddig, B-ben pedig csak egyet, és ha A-t még nem vizsgáltuk meg alaposan, akkor ez az elv azt mondja ki, hogy nagyobb a valószínűsége annak, hogy A-ban még találunk hibát, mint annak, hogy B-ben találunk. Másként fogalmazva, úgy látszik, hogy a hibák sokszor csoportosan jelentkeznek, különösen az olyan modulokban, programszakaszokban,

amelyeket nehezebb volt megírni. További hibák létezésének valószínűsége Megtalált hibák száma 4.2 ábra A megmaradó és a megtalált hibák közötti összefüggés Ezt a megfigyelést jól ki tudjuk használni akkor, amikor olyan részhez jutunk, amelyben több hiba jelentkezett, mint a többiben. Ekkor további fokozott erőfeszítést érdemel a talált rész átvizsgálása. • A tesztelés igen kreatív tevékenység, és komoly szellemi kihívást jelentő feladat. Valószínűleg igaz az, hogy egy nagy program teszteléséhez szükséges kreativitás meghaladja ugyanannak a programnak a megtervezéséhez szükséges A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 52 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 53 ► kreativitást. Jóllehet egyre újabb szisztematikus módszereket dolgoznak ki a szoftverek

vizsgálatára, ezek a módszerek továbbra is jelentős kreativitást igényelnek. A teszttervezés kulcskérdése A szoftvervizsgálat legfontosabb összetevője és velejárója a hatékony tesztek megtervezése. A hatékonyság azért fontos, mert tudatában vagyunk annak, hogy nem lehetséges a meglevő összes hiba tesztjét előállítani. A kézenfekvő stratégia ekkor arra törekedni, hogy amennyire csak lehetséges, csökkentsük a megmaradt hibák számát. Tekintetbe véve az időt, költségeket, gépidőt, stb. a tesztelés kulcskérdése a következő lesz: • Az összes lehetséges teszt mely részhalmaza detektálja a legnagyobb valószínűséggel a legtöbb hibát? A legkisebb hatékonyságú metodológia minden bizonnyal a véletlenszerű tesztelés, amelyben random módon képezzük bemeneti értékeknek egyegy halmazát. A legtöbb hiba detektálására vonatkozó valószínűséget tekintve, a random értékeknél kis esély van arra, hogy optimálisak

legyenek, vagy akár közel optimális részhalmazt képezzenek. A továbbiakban előtérbe helyezzük a determinisztikus úton történő tervezést, ahol arra törekszünk, hogy minél átgondoltabban alakítsuk ki a felhasználásra kerülő tesztkészleteket. Külön foglalkozunk a funkcionális és külön a strukturális megközelítéssel. A két megközelítés jellegéből adódóan azok nem azonos hibahalmazok felfedésére lesznek alkalmasak (bár természetesen átfedés biztosan van a halmazok között), ezért ha az lehetséges, mindig érdemes a két megoldás mindegyikét felhasználni, egymást követően. Kifejleszthető egy észszerűen szigorú tesztfolyamat a fekete dobozos kezelésmódban, ennek kiegészítéseként pedig egy olyan folyamat, amely a program belső logikáját is végigköveti, a fehér dobozos módban. Ajánlatos a fejlesztési fázisokat az itt leírt sorrendben végezni: előbb a „fekete”, azután a „fehér”. Ehhez még annyit jegyzünk

meg, hogy előfordulhatnak esetek, amikor a tesztelést végzők számára nem áll rendelkezésre a forráskód, csak a működő szoftver maga Ilyenkor természetesen le kell mondanunk a strukturális vizsgálatokról. 4.5 Funkcionális tesztelés Ebben az alpontban a funkcionális tesztelés megvalósítására mutatunk be különböző szisztematikus módszereket. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 53 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 54 ► 4.51 Ekvivalencia partícionálás A célunk a lehetséges bemeneti adatok olyan részhalmazát képezni, amely a legnagyobb valószínűséggel a legtöbb hibát fedi fel. E részhalmaz megkereséséhez érdemes még tekintetbe venni azt, hogy egy jól megválasztott teszt két másik tulajdonsággal is rendelkezik: 1. Egynél többel redukálja azon más teszteknek a

számát, amelyeket azért kellene kialakítani, hogy egy „észszerű”, hatékony tesztelést érjünk el. 2. Más lehetséges tesztek nagy halmazát fedi le, vagyis képes azokat helyettesíteni Ez a két tulajdonság két eltérő meggondolást foglal magában, ill. von maga után Az első azt, hogy mindegyik teszt annyi különböző bemeneti feltételt ír elő, amennyi csak lehetséges, annak érdekében, hogy minimalizálja a szükséges tesztek számát. A másik azt, hogy meg kell kísérelni a program input adatainak tartományát olyan ún. ekvivalencia osztályokba csoportosítani, partícionálni, amelyekről fel tudjuk tételezni, hogy egy adott osztályhoz tartozó teszt adatértékei ekvivalensek a teszt bármelyik más adatértékeivel. Egyazon ekvivalencia osztályba azok a tesztek (bemeneti adatcsoportok) tartoznak, amelyek ugyanazt a hibát fedik fel. Vagyis, ha az ekvivalencia osztály egy tesztje detektál egy hibát, az osztály minden tesztjétől azt várjuk

el, hogy ugyanazt a hibát legyen képes detektálni. Megfordítva: ha egy teszt nem fed fel egy hibát, akkor azt várjuk el, hogy az ekvivalencia osztály más tesztjei sem fogják ezt a hibát felfedni. (Kivéve azt az esetet, amikor egy ekvivalencia osztály részhalmaza egy másik ekvivalencia osztályba is esik. Ez akkor állhat elő, amikor különböző ekvivalencia osztályok átfedik egymást) Az elv mögött az a meggondolás rejlik, hogy várhatóan elegendő lesz egy osztályból csak egyetlen tesztet kiválasztani, ami akármelyik lehet, míg az osztály többi tesztjétől már nem várunk el új hibafelfedést. A fenti két meggondolás egy funkcionális tesztelési metodológiát képez, amit ekvivalencia partícionálásnak nevezünk. A második meggondolást arra használjuk, hogy érdekes feltételeket találjunk a tesztelésre. Az első meggondolást ezután arra használjuk, hogy minimális számú tesztet keressünk ezen feltételek lefedésére. A háromszöges

példát véve, ugyanabba az ekvivalencia osztályba sorolhatók azok a bemeneti adatok, amelyek három azonos értékű, nullánál nagyobb egész számot képeznek. Ezekről feltételezzük, hogy ha az egyik számhármas nem fed fel hibát, akkor a másik sem fog. Másként fogalmazva: a tesztelési időt más esetekre tudjuk fordítani, másik ekvivalencia osztályok bevonásával. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 54 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 55 ► A módszer két lépésből áll: Először meghatározandó az ekvivalencia osztály, azután pedig az oda tartozó tesztek definiálása következik. Az ekvivalencia osztályok meghatározása Az ekvivalencia osztályok keresése alapjában véve egy heurisztikus folyamat. Egymás után sorra vesszük a bemeneti feltételeket, és csoportokba soroljuk

őket. Két típusú ekvivalencia osztályt kell keresnünk: egyrészt érvényeset, amelyben érvényes bemenetek vannak, másrészt érvénytelent, amelyben érvénytelen, hibás bemeneti adatok vannak. Néhány irányelv a kereséshez: • Ha egy bemeneti feltétel értéktartományt ír elő, akkor egy ebbe eső érvényes osztályt, továbbá egy vagy több nem ebbe eső érvénytelen osztályt válasszunk. Például, ha egy darabszám 1 és 999 közé eshet, akkor érvénytelen osztályként 1-nél kisebb darabszámot, valamint 999nél nagyobb darabszámot válasszunk. • Ha egy tételnek adott számú változata lehet (mondjuk 12), akkor két érvénytelen osztályt adhatunk meg: egyet a 0-ra, egyet pedig a 12-nél nagyobbra. • Ha egy bemeneti feltétel kötelező előírást tartalmaz (például egy azonosító első karaktere betű kell legyen), akkor egy érvényes osztály lesz a betűvel kezdődő, és egy érvénytelen ami nem betűvel kezdődik. A tesztek

meghatározása Az ekvivalencia osztályok használatának második lépéseként a tesztek kiválogatására kerül sor. Ennek folyamata a következő: • Mindegyik ekvivalencia osztályhoz saját azonosító számot rendelünk. • Az érvényes ekvivalencia osztályokhoz úgy válasszunk teszteket egymás után, hogy egy-egy teszt minél több osztályt tudjon képviselni, más szóval lefedni. Célunk az összes osztály lefedése teszttel • Az érvénytelen ekvivalencia osztályokhoz egyenként válasszunk tesztet úgy, hogy az csak egyetlen osztályt fedjen le. A cél itt is az összes osztály lefedése Az érvénytelen osztályok egyedi teszttel való lefedésének az az oka, hogy lehetnek olyan hibás bemeneti adatok, amelyek egy másik hibás adat detektálását hiúsítanák meg. Ezért érdemes mindegyik hibás adatot önállóan, egyedileg kezelni. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 55 ►

Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 56 ► Jóllehet az ekvivalencia osztályokra való partícionálás jóval hatékonyabb, mint a random kiválasztás, mégis maradhatnak ki hatékony tesztek az alkalmazása után. Emiatt érdemes más módszereket is igénybe venni A következőkben ilyen módszereket ismertetünk. 4.52 Határérték-analízis A tapasztalatok szerint azok a tesztek, amelyek a határértékekre vonatkozó feltételeket írnak elő, kifizetődőbbek, mint azok, amelyek nem. A határfeltételek a bemeneti és kimeneti adattartományok alsó és felső szélét jelentik. A vizsgálatokat ezen értékek körül érdemes végezni, vagyis a határértéken, ill alatta és felette A határérték-analízis két szempontból különbözik az ekvivalencia felosztástól: 1. Egy ekvivalencia osztályt tekintve annyi számértéket tartalmaz, amenynyire szükség

van az osztály mindegyik határértékének a vizsgálatához Egy ekvivalencia osztálynak ugyanis több határértéke is lehet. 2. Nemcsak a bemeneti feltételekre kell koncentrálni, hanem a kimenetiekre is, ahol a kimeneti ekvivalencia osztályok határértékeit vesszük számításba. Általános receptet nem lehet adni, ez a módszer sok intuitivitást is igényel. Mindazonáltal néhány iránymutatót adunk az alábbiak szerint: 1. Ha egy bemeneti feltétel értéktartományt tartalmaz, akkor teszteket írunk a tartomány széleire, továbbá érvénytelen bemenetű teszteket, a szélsőértékeket minimálisan túllépve. Például, ha egy bemeneti érték (−1,0) és (+1,0) közé eshet, akkor a tesztek a következők lehetnek: −1,0, 1,0, −1,001, valamint 1,001. 2. Ha egy bemeneti feltétel fix számú értéket enged meg egy változózóra, a minimumra, a maximumra, továbbá alatta és felette érdemes egy-egy értéket megadni. Például, ha egy input fájlnak

1–255 rekordja létezhet, akkor a teszteket 0, 1, 255, és 256 rekordra írjuk elő. 3. Használjuk fel az 1-es útmutatót a kimeneti feltételekre is A kimeneti határértékek vizsgálata azért is fontos, mert azok nem mindig a bemeneti határértékek hatására jönnek létre (ilyen pl. a szinusz függvény) Másrészről nem mindig lehetséges a kimeneti határértékeken túli eredményt produkálni, a vizsgálatot akkor is érdemes elvégezni, ahhoz hogy a hiba lehetőségét biztosan ki tudjuk zárni. 4. Ugyancsak használjuk fel a 2-es útmutatót is mindegyik kimeneti feltételhez A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 56 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 57 ► 5. Ha egy program inputja vagy outputja sorrendezett halmaz (pl egy szekvenciális fájl, lineáris lista, táblázat), akkor szenteljünk

figyelmet a halmaz első és utolsó elemének. 6. Mindezeken túl, kíséreljünk meg a saját megfigyeléseink alapján minél több újabb határérték-feltételt előírni. Példaként ismét vehetjük a háromszöges feladatot. Ott a bemeneti adatokra az a feltétel érvényes, hogy mindhárman 0-nál nagyobb egész számok, másrészt bármelyik kettőjük összege nagyobb kell legyen a harmadiknál. Ezekre az esetekre ekvivalencia partíciókat tudunk megadni, mind a teljesülésükre, mind pedig a nem teljesülésükre. Az erre szolgáló lehetséges teszt esetek például az érvényes {3, 4 ,5} halmaz, ill. az érvénytelen {1, 2, 4} halmaz. Ezzel azonban még kihagytuk egy valószínűsíthető hiba tesztjét Ha a programban az értékellenőrzést A + B ≥ C alakban kódolták, a helyes A + B > C helyett, akkor a hibás {1, 2, 3} halmaz érvényesnek lenne elfogadva. A szélsőérték-analízis viszont ezt a hibát kiszűrné azzal, hogy az ekvivalencia partíciók

szélein és azok környezetében végezné az ellenőrzést. 4.53 Ok-hatás-analízis Az ekvivalencia partícionálásnak és a határérték-analízisnek az a közös hiányossága, hogy nem vonják be a vizsgálatba a bemeneti feltételek kombinációit. A bemeneti kombinációk sorravétele nehéz feladat, mivel a lehetséges tesztek száma rendszerint horribilissé válhat. Ezen a téren mindenképpen arra kell törekedni, hogy szisztematikus módon válogassuk ki a lehetséges kombinációk azon részhalmazát, amely a lehető leghatékonyabb lesz. Az ok-hatás-analízis olyan technika, amely eredményes tesztek szisztematikus kiválogatását teszi lehetővé. Megjegyzendő még, hogy a módszernek olyan hasznos mellékhatása is van, amellyel specifikációs hiányosságokat és ellentmondásokat tudunk felfedezni Az eljáráshoz Boole-algebrai formalizmust használunk fel, a szokásos alapműveletek bevonásával. Ezek: ÉS, VAGY, valamint NEM. A műveletekhez az őket

megjelenítő logikai kapukat tudjuk igénybe venni, ill. a kapukból felépülő kombinációs logikai hálózat gráfreprezentációját, az ún. Boole-gráfot A Boole-gráf egy irányított gráf, melynek csomópontjai a logikai műveleteket képviselik. Egy csomópontba befutó élek ugyancsak egy-egy csomópontból indulnak ki. Egy csomópont 0 vagy 1 értéket vehet fel, ahol a 0 értelmezése a „hiányzik (nincs)”, az 1-é pedig a „jelen van (létezik)”. A gráf jelölésrendszerét a 4.3 ábra foglalja össze A NEM művelet az a érté- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 57 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 58 ► két invertálja b értékeként, az ÉS művelet csak akkor ad 1-et c-nek, ha mind a, mind pedig b értéke 1, különben c 0 lesz. A VAGY művelet értelmében c csak akkor lesz 0, ha mind

a, mind b 0, különben pedig c értéke 1 lesz. NEM a a ÉS ^ b a VAGY v c c b b 4.3 ábra Az ok-hatás Boole-gráfjának jelölései A tesztek leszármaztatása a szoftver-specifikáció alapján történik, a következő folyamat lépései szerint: 1. A specifikáció felbontandó kisebb, „feldolgozható részekre” Erre azért van szükség, mivel az ok-hatás gráf túl bonyolulttá és áttekinthetetlenné válik nagyobb méretű specifikációknál. Például, egy időosztásos rendszer tesztelésénél külön feldolgozható rész lehet egy-egy parancsra vonatkozó specifikáció Egy kompájler tesztelésénél külön kezelendő egység lehet egy-egy nyelvi utasítás 2. A specifikációban egy ok nem más mint egy bemeneti feltétel vagy egy bemeneti ekvivalencia osztály. Egy hatás a kimeneti feltételben nyilvánul meg Az okok és hatások a specifikáció végigkövetésével azonosítandók: ennek során egyenként ki kell választani azokat a

szövegelemeket, ill előírásokat, amelyek egy-egy okot, ill annak hatását képviselik Mindegyik ok és hatás külön azonosító számot kap 3. A specifikáció szemantikus tartalmát elemezve létrehozzuk azt a Boole-gráfot, amely logikailag összekapcsolja az okokat és hatásokat. Ez lesz az ún. ok-hatás gráf A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 58 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 59 ► 4. A gráfhoz még hozzá kell rendelnünk azokat a kiegészítő megszorításokat, amelyek meg nem engedett okok és hatások kombinációját foglalják magukba 5. A gráf állapotfeltételeinek módszeres végigkövetésével a gráfot egy ún döntési táblázatba konvertáljuk át. A táblázat mindegyik oszlopa egy tesztet képvisel. 6. A döntési táblázat mindegyik oszlopából leszármaztatjuk a teszteket Egy

gráf illusztrálására vegyük a következő rövid specifikációt. Az 1-es oszlopban levő karakter „A” vagy „B” kell legyen. A 2-es oszlop karaktere csak számjegy lehet Ezzel a megadással fájl-frissítés (updateolás) hajtódik végre Ha az első karakter helytelen, az X12 üzenet jelenik meg, ha a második helytelen, akkor pedig az X13 üzenet. Az okok a következők: • (1) Az 1-es oszlop karaktere „A”. • (2) Az 1-es oszlop karaktere „B”. • (3) A 2-es oszlop karaktere számjegy. A hatások a következők lesznek: • (71) Frissítés hajtódik végre. • (72) Az X12 üzenet jelenik meg. • (73) Az X13 üzenet jelenik meg. A specifikációt megjelenítő ok-hatás gráf a 4.4 ábrán látható 1 72 v 4 2 ^71 3 73 4.4 ábra Ok-hatás gráf A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 59 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék |

Felhasznált irodalom Vissza ◄ 60 ► Jóllehet a gráf a specifikációt reprezentálja, egy olyan ok-kombinációt is tartalmaz, ami nincs megengedve: az (1) és (2) nem lehet egyszerre 1-es értékű. Ez általában is gyakran előforduló eset, amely a lehetséges tesztek számát csökkenti. Ugyanígy lehetségesek az olyan specifikációk is, amelyekben bizonyos kimeneti hatások sem léphetnek fel A gráf alapján a létrehozandó ún. döntési táblázat valójában nem más mint a gráf által képviselt logikai hálózat igazságtáblázata. Ez az igazságtáblázat 0-t és 1-et tartalmaz, és azt írja le, hogy mik azok a bemeneti logikai feltételek, amelyekre egy-egy kimenet 1-es értékű lesz. A döntési tábla meghatározása úgy történik, hogy kiválasztunk egy kimeneti hatást, és viszszafelé haladva a gráfon megkeressük azokat a logikai feltételeket, egészen a bemeneti okokig haladva, amelyek a hatás bekövetkezését idézik elő. Más szóval ez

azt jelenti, hogy meghatározzuk azokat a bementi 0–1 kombinációkat, amelyek a logikai hálózatban 1-es kimeneti értékeket produkálnak. Ez pedig a hálózat olyan igazságtáblázata, amelyben a 0 kimeneti értékhez nem adunk meg bemeneti kombinációt. Ennek megfelelően a táblázat nem tartalmaz olyan sort, amelyben mindegyik hatás értéke 0 lenne. A döntési táblázatban mindegyik bemeneti okhoz, ill. mindegyik kimeneti hatáshoz egy-egy sor tartozik Az oszlopok számát az adja meg, hogy mennyi különböző lehetséges bemeneti kombináció tud előidézni egy-egy kimeneti hatást. Ebben az elrendezésben egy oszlop egy tesztet képvisel: azokat a bementi okokat, ill. okok hiányát foglalja magában, amelyekre a kimeneti hatás bekövetkezik. A példánkban szereplő Boole-gráf alapján a 4.5 ábrán szereplő döntési táblázatot tudjuk leszármaztatni. 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 Döntési táblázat A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 60 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 61 ► A döntési táblázat 1-es oszlopa által képviselt teszt a következő: az 1-es oszlop B betűt, a 2-es oszlop számjegyet tartalmaz, ami legyen például 5. A 4-es oszlop alapján képezhető teszt: Az első oszlop karaktere nem A és nem B, a harmadik oszlop karaktere pedig nem számjegy. A konkrét teszt például lehet QY. A táblázathoz még két kiegészítést fűzünk: 1. A 3-adik és 8-adik oszlop tesztjei nem értelmezhetőek, hiszen nem lehet egyidejűleg A-t is meg B-t is megadni első karakterként. Mint tudjuk, ez az eset meg nem engedett kombinációként szerepelt a fentiekben. 2. Látható, hogy ugyanazt a hatást több különböző bemeneti okkombináció

segítségével is el tudjuk érni Ez azt jelenti, hogy tesztek különböző kombinációja szolgál a hatások vizsgálatához. Ugyanakkor az is látható, hogy a 4-ik oszlop tesztje egyszerre alkalmas a 72-es és 73-as hatások ellenőrzésére. Ezek a tulajdonságok azt eredményezik, hogy hatékony teszteket tudunk leszármaztatni. Az előbbiekben három funkcionális típusú teszttervezési módszert ismertettünk. Ezeket a módszereket mindenképpen célszerű egymással kombinálni, mivel mindegyikük egy bizonyos hasznos teszthalmazt produkál, amelyek jól kiegészítik egymást a hibák felfedése tekintetében. Az egyes módszereket a következő sorrendben tanácsos végrehajtani: 1. Ok-hatás analízis 2. Határérték-analízis 3. Ekvivalencia partícionálás A különböző teszteknek és az általuk vizsgált funkcióknak a kapcsolatát az ún. tesztlefedési mátrixon lehet összesíteni A mátrix soraihoz a tesztek, oszlopaihoz a funkciók tartoznak Ha az i-edik

teszt a j-edik funkció ellenőrzésére alkalmas, akkor a mátrixban ezt sötétített kockával ábrázoljuk Példaként a 46 ábra mátrixát mutatjuk be A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 61 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 62 ► Vizsgált funkciók 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 4.6 ábra Egy tesztlefedési mátrix 4.54 A véletlenszerű tesztgenerálás felhasználása Már korábban említettük, hogy a véletlenszerűen (random módon) képzett bemeneti adatoknak a hibafelfedő képessége meglehetősen korlátozott a determinisztikusan előállított tesztekhez képest. Ennek ellenére mindenképpen érdemes ezt a megközelítést is bekapcsolni a tesztelési stratégiánkba Ennek a legfőbb oka az, hogy a véletlen számok előállítása és bemeneti adatként való felhasználása

elhanyagolható számítási ráfordítással jár a determinisztikus adatképzéshez képest. A másik említést érdemlő ok az, hogy nagyszámú, nagytömegű adatot tudunk így a folyamatban igénybe venni, ami megnöveli az esélyét a hibafelfedésnek. A random tesztek olyan hibák felfedését is eredményezhetik, amelyek a determinisztikus teszttervezésnél elkerülték a figyelmet. A véletlen számok előállításának folyamatát mindenképpen célszerű előre átgondolt, megtervezett módon végezni. A következőkben egy erre vonatkozó szervezési elvet ismertetünk: A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 62 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 63 ► 1. Határozzunk meg mindegyik bemenő adathoz egy olyan számtartományt, amelyen belül a véletlen számok képzését akarjuk elvégezni 2. Az egyes

adatokhoz képezzük a saját tartományukon belül eső, normális eloszlású random számokat, amelyek a bemeneti tesztadatok lesznek 3. A szoftverre adott teszteket két módon szervezhetjük: – Egy vagy annál több, de nem mindegyik adat változik random módon, a többi rögzített értéken áll. – Mindegyik adat változik a saját tartományán belül. 4. A tesztválaszok meghatározása random inputok esetén külön meggondolást igényel Végül is három eset lehetséges: – Az egyes tesztszámok ismeretében magunk határozzuk meg az elvárt válaszreakciókat. – Ha automatizáltan küldjük a szoftverre a random teszteket, akkor a reakciók folyamatos külső figyelése a feladatunk, anélkül, hogy tudnánk mit kell elvárnunk. Ebben a működési módban a feladatunk abból áll, hogy azt döntsük el mindig, hogy nem történt-e valamilyen észrevehető rendellenes megnyilvánulás (Itt az automatizmust egy tesztmeghajtó keretprogram képviseli, amely a random

számgenerátort is magában foglalja.) – Lehetséges olyan szimulációs környezet létrehozása is, amelyben a random bemeneti értékekre adott válaszadatok kiszámítása a szimulációs szoftvernek a feladata. Ezzel befejeztük a funkcionális tesztelési elvek és módszerek áttekintését. A következő alfejezetben a strukturális megközelítéssel foglalkozunk részletesebben. 4.6 Strukturális tesztelés Mint már korábban említettük a szoftver tesztelési technikák ill. módszerek két fő csoportba sorolhatóak: • Funkcionális (black-box) tesztelés és • Strukturális (white-box) tesztelés (ST). Míg funkcionális tesztelés esetén a tesztelt szoftver felépítését, a megvalósítás részleteit nem vesszük figyelembe, addig a ST esetén a tesztelés a szoftver a specifikációban megadott funkciót megvalósító program szerkezete alapján történik. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 63 ►

Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 64 ► ST esetén a program vezérélési szerkezetét modellezzük és a tesztelő – adott szempontrendszer szerint – a vezérlési szerkezet minden ágát, a program minden alternatív részét végrehajtva vizsgálja annak működését. 4.61 Hibamodell ST esetén A hibamodell nem más, mint a lehetséges hibák valamilyen könnyen kezelhető, tömör leírása. A szoftver tesztelés általános problémája a megfelelő hibamodell generálása A nehézséget az jelenti, hogy a szoftver hibák forrása igen változatos: megkülönböztethetünk specifikációs, tervezési kódolási stb. hibákat A hibamodelltől azt várjuk, hogy egyrészt élethű legyen, vagyis tartalmazza (leírja) az összes előforduló hibát, másrészt a tesztelés során könynyen használható legyen. Ez utóbbi igényt kevésbé lehet tömören, egzakt

módon meghatározni, mert a meghatározás függhet a konkrét tesztelési módszertől. Általánosságban a következőket mondhatjuk: A tesztelés során történő könnyű felhasználhatóság magában foglalja azt az igényt, hogy a hibamodell adjon lehetőséget a lehetséges hibák szisztematikus (algoritmikus) kezelésére, a tesztelés során már lefedett (tesztelt) hibák arányának meghatározására, adott teszthalmaz hibafedésének meghatározására stb. Általános tapasztalat, hogy a szoftver tesztelés esetén nem lehet olyan hibamodellt találni, amely minden alkalmazás esetén, minden fejlesztési környezetben jól használható lenne. Az egyes hibamodellek a feltételezhető szoftver hibáknak csak egy részhalmazát fedik le (47 ábra) Általában a különböző technikák más és más részhalmazát fedik le, ezért általános elv, hogy célszerű a különböző technikákat egymással vegyesen használni a tesztelés során. 4.7 ábra Szoftver

hibamodellek által lefedett hibák viszonya A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 64 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 65 ► 4.62 A strukturális tesztelés alapjai A ST arra a megállapításra alapszik, hogy a szoftver hibák általában a vezérlési szerkezetet érintik (Beizer, 1990). Pl: A programozó if( c ) kifejezés helyett if( !c ) kifejezést használ Természetesen ez a kijelentés a gyakorlati eseteknek csak egy részében helytálló, ezért szükséges meghatározni azokat az alkalmazási területeket és tesztelési célokat, ahol a ST hatékonyan használható Általánosságban azonban kijelenthetjük, hogy ha a fenti állítás igaz, akkor a strukturális tesztelési technikák hatékonyan alkalmazhatóak. Vizsgáljuk meg részletesen, a ST által használt hibamodell tulajdonságait. A

strukturális teszteléskor a tesztelő lényegében nem foglalkozik a felderítendő hiba természetével. Csak a hibamentes program működését, vezérlési szerkezetét modellezi a későbbiekben részletesen is bemutatandó ú.n folyamat vezérlés gráf segítségével A tesztelő azt feltételezi, hogy a programban létrejövő hibák valamilyen módon befolyásolják a a vezérlési szerkezet működését (a folyamat vezérlési gráf bejárását). A használt hibamodell lényegében egy implicit hibamodell, mert a tesztelő nem határozza meg explicit módon, milyen hibákat tesztel 4.63 A tesztelés menete ST esetén A ST, mint a többi tesztelés módszer is két fázisra bontható: • tesztgenerálás és • teszt végrehajtás. A tesztgenerálás teszt bemenetek generálását jelenti valamilyen mértékszám alapján. A mértékszám annak jellemzésére szolgáló számszerű paraméter, hogy a generált teszt bemenetek mennyire alaposan vizsgálják meg az egyes

kódrészleteket, mennyire alaposan vizsgálják meg a vezérlési szerkezet végrehajtását. A mértékszámokat általánosan is használhatjuk a teszthalmazok, ill a tesztelési procedúra hatékonyságának, alaposságának jellemzésére A mértékszámokról, ill alkalmazásukról a következő fejezetben lesz szó. A teszt végrehajtása lényegében nem más, mint a program egy vezérlési ágának végrehajtása. A teszteléshez hozzátartozik a program kimeneteinek, eredményeinek összehasonlítása a specifikációban rögzítettel A strukturális tesztelési eljárások nem definiálják, milyen módszerrel történjen az összehasonlítás, ezzel alkalmazásukkor minden konkrét esetben külön kell foglalkozni. Strukturális tesztelés esetén a kimenetek vizsgálatán A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 65 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék

| Felhasznált irodalom Vissza ◄ 66 ► túl szükséges a vezérlési szerkezet végrehajtott vezérlési ágának azonosítása is. Ennek megfigyelését vagy magának a kódnak, vagy a tesztelési környezetnek kell támogatnia 4.64 A strukturális tesztelés előnyei és felhasználása A strukturális tesztelés egyik legnagyobb előnye az implicit hibamodellből adódik. ST segítségével hibákat kereshetünk anélkül, hogy tudnánk, milyen szoftver hibákat is keresünk. A másik kedvező tulajdonsága az ST-nek, hogy a funkcionális teszteléssel ellentétben szisztematikus algoritmusok által jól kezelhető matematikai modellt (vezérlési folyamat gráf) használ. Ráadásul a tesztelés hatékonyságának mérésére számszerű mértékszámokat lehet használni Összehasonlítható két teszthalmaz „jósága”, vagyis hogy mennyire alaposan tesztelnek egy adott szoftvert. (A teszthalmazokhoz társított mérőszámokat csak óvatosan szabad a teszthalmazok

hibafedésének nevezni, hiszen az implicit hibamodell miatt ilyenről nehéz is lenne beszélni. Sokkal inkább a teszthalmaz tesztelésének adott szempont szerinti alaposságát jellemzik ezek a mértékszámok) Az eddigieket összefoglalva meghatározhatjuk azokat az alkalmazási területeket, ahol a ST hatékonyan alkalmazható tesztelésre: • Vezérlés intenzív alkalmazások. • Ezeknél az alkalmazásoknál jó valószínűséggel igaz a fent idézett állítás, hogy a szoftver hibák általában a vezérlési szerkezetet érintik • Tervezési hibák felderítése. • Elsősorban itt nem az adatszerkezeteket érintő hibákra kell gondolni, hanem olyan globális logikai hibákra, amelyek a vezérlési szerkezetet érintik. Ilyen pl az elérhetetlen (dead) kódrészek felderítése • Szabványok szerinti tesztelés. • Mivel ST esetén számszerűsíthető a tesztelés alapossága a különböző szoftver teszteléssel foglalkozó szabványok előszeretettel írnak

elő valamilyen mértékszám szerint ST technikát, mint kötelezően végrehajtandó tesztelési lépést. 4.65 A vezérlési szerkezet modellezése Mint említettük ST során a program vezérlési szerkezetét modellezzük az ún. folyamat vezérlési gráf (FVG, Control Flow Graph – CFG) segítségével AZ FVG egy gráf modell. A gráf pontok az utasításoknak feleltethetők meg. Az utasításokat reprezentáló gráf pontokon kívül a program kezdetét, belépési pontját és végét, kilépési pontját is egy-egy gráf pont repre- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 66 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 67 ► zentálja. A gráf származtatása igen egyszerű, az egymás után végrehajtható utasításokat egy-egy irányított gráf él köti össze. A gráfpontoknak két típusát különböztethetjük

meg: • Egyszerű (szekvenciális) gráf pont, amelyből egyetlen gráf él indul ki, és egy szekvenciális utasítást reprezentál. • Elágazás gráfpont, amelyből egynél több gráf él indul ki, és egy elágazás utasítás (predicate statement) feleltethető meg neki. (AZ FVG esetén az egyszerűbb kezelhetőség miatt általában a kimenő élek számát kettőben szokták limitálni.) Az elágazás utasításban mindig szerepel egy feltétel, mely meghatározza, hogy az utasítás végrehajtásakor melyik következő utasítás hajtódik végre. A 4.8 ábrán egy kódrészletet és az azt modellező FVG-t láthatunk A gráfpontokban a pontok által reprezentált utasítás száma 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 1 2 3 4 5 6 7 END 4.8 ábra Példa az FVG generálására A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom

Vissza ◄ 67 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 68 ► A programok végrehajtása is követhető, ill. szemléltethető, az FVG segítségével Használjuk azt a terminológiát, hogy ha egymás után végrehajtódik egy program két utasítása, akkor FVG-ben bejárjuk a két utasításoknak megfelelő két gráf pontot, ill. a köztük lévő élet A program minden, adott bemenetek hatására történő végrehajtásakor az FVG egy jellemző pont- és élsorozata járódik be. A program minden futtatáskor a belépési ponttól a kilépési pontig tartó pont- és élsorozatot sorozatot, egy ún. gráf utat jár be A 49 ábrán a fenti FVG-ben lehetséges utak felsorolását találjuk. 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 elemzése alapján meghatározott utak nem

mindegyike járható azonban be a valóságban. Mivel az elágazás utasításokban szereplő feltételek nem függetlenek egymástól, így egyes élek kiválasztása már meghatározhatja valamelyik másik későbbi elágazás utasítás feltételét, vagyis egy másik ág bejárását. Az 48 ábrán látható kódban az egymást követő feltételek közül csak egy lehet igaz (Az x változó értéke vagy kisebb, vagy egyenlő, vagy nagyobb a list[mid] értéknél.) A 49 ábrán a ténylegesen bejárható utakat vastagon szedtük. 4.66 Programok vezérlési bonyolultsága A programok vezérlési szerkezetének bonyolultsága egymástól igen eltérő lehet. A tesztelés feladata természetesen sokkal bonyolultabb egy komplex vezérlési szerkezettel rendelkező program esetén. Ezért bevezettek egy, a programok vezérlési szerkezetének bonyolultságára jellemző számot az ún. ciklomatikus komplexitás-t (CK, Cyclomatic Complexity) AZ FVG-ben független útnak nevezünk két

utat, ha mindkettőben létezik olyan pont vagy él, amely nem eleme a másik útnak. A ciklomatikus komplexitás az FVG-ben található független gráf utak maximális számát adja meg. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 68 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 69 ► Általánosan használt minimális tesztelési cél strukturális teszteléskor, hogy a teszthalmaz fedje le a független utak egy maximális (további független utakkal tovább már nem bővíthető) halmazát. A 49 ábrán a bejárható utak halmaza egyben a független utak egy tovább már nem bővíthető, maximális halmazát is alkotják. Ki kell emelni, hogy az ilyen utak halmaza nem egyedi, vagyis egy gráfhoz akár több ilyen tulajdonsággal rendelkező út halmazt (és persze teszthalmazt) tudunk generálni. Sajnos még az a könnyített

állítás sem igaz, hogy az egyes halmazok számossága megegyezik a CK értékével. A 4.10 ábrán a 48 ábrán megadott FVG-nak a független utak egy másik, tovább már nem bővíthető halmazát adjuk meg, amely azonban csak két útból á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 Független utak az FVG-ben 4.67 CK számítása A CK legnagyobb előnye, hogy az FVG egyszerű elemzése alapján kiszámítható. Használjuk a következő jelölést: G: gráf, V(G): CK, E: élek száma; N: pontok száma; P: elágazás utasítások száma. CK értékét két képlet alapján is meghatározhatjuk: V(G)= E-N+2 V(G)=P+1 A második képlet csak abban az esetben ad helyes eredményt, ha kettős elágazások vannak csak az FVG-ben, vagyis csak egy gráfpontból két kimenő él lehet. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 69 ► Szoftver-minőségbiztosítás

Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 70 ► A 4.8 ábrán szereplő gráf esetén a fenti képletek: E=11; N=9; P=3; V(G)= E-N+2= 11-9+2=4; V(G)=P+1=3+1=4. 4.68 Egyszerű strukturális tesztgenerálási algoritmus A ST technikák általános problémáinak vizsgálatához tekintsünk egy egyszerű tesztelési algoritmust: 1. FVG generálása a kód alapján 2. V(G) (CK) számítása az FVG alapján 3. Független utak maximális (CK darab utat tartalmazó) halmazának generálása 4. Bemenetek generálása a független utak bejárásához A tesztgenerálás során a következő problémák adódhatnak: • AZ FVG ciklikus, kört tartalmaz, így elvben a végtelen sok út generálható az adott FVG-hoz. • Nem generálható olyan bemeneti kombináció, amely egy adott út bejárását eredményezné az FVG-ben. A következő fejezetekben a fenti problémák kezelésével foglakozunk. 4.69 ST általános

problémája: Ciklusok tesztelése A ST módszerek legnagyobb problémája a ciklusok tesztelése. A programok vezérlési szerkezetében gyakoriak a ciklus utasítások Ezek az FVGben körnek felelnek meg A probléma az, hogy minden olyan gráf útból, melyben van kör – ha nem limitáljuk a kör bejárásának számát – elvben végtelen további utat tudok generálni, attól függően, hogy az adott kört hányszor járom be. Erre mutatunk egy egyszerű példát a 411 ábrán 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 gráf utak A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 70 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 71 ► Ennek a problémának a kezelésére egyetlen technika létezik: ciklus bejárásának limitálása. Minden FVG körhöz önkényesen, vagy a ciklus feltétel

alapján egy egész számot rendelek, mely a kör bejárásának maximális száma lesz. Sajnos még így is igaz lesz, hogy minden kört tartalmazó úthoz annyi tesztvektort kell generálnom, mint a kör bejárásának száma plusz egy. Még nehezebb a helyzet, ha a ciklus utasítások egymásba ágyazódnak. Ekkor sajnos az utak száma (és ezzel együtt a szükséges tesztek száma is) exponenciálisan nő a ciklusok számával. Általánosságban igaz, hogy a ciklusok kezelése jelenti a legnagyobb kihívást az összes strukturális tesztelési módszerrel szemben. 4.7 Tesztminőségi mérőszámok A ST alaposságának jellemzésére használhatunk mértékszámokat. Ezek a mértékszámok támpontot adhatnak a tesztelés alaposságának jellemzésére. Megmutatják, hogy egy adott szempont szerint mennyire alaposan teszteltük az adott szoftvert. A mértékszám egy arányszám: megmutatja, hogy a kiválasztott szempont szerint a tesztelhető elemek (egységek, tételek) mekkora

részét teszteltük le, a terület terminológiáját használva az adott tételek mekkora részét fedtük le. A mértékszámok tipikusan strukturális teszteléshez kapcsolódnak. Néhány példa a mértékszámokra: • Utasítás lefedettség: Az utasítások mekkora hányadát hajtottuk végre teszteléskor. • Ág lefedettség (döntés lefedettség): AZ FVG ágainak mekkora hányadát fedtük le (hajtottuk végre) teszteléskor. • Út lefedettség: AZ FVG-ben található utaknak mekkora hányadát fedtük le (hajtottuk végre) teszteléskor. A tesztelés, teszt generálás célja minél magasabb, lehetőleg 100%-os lefedettség elérése. A mértékszámokat ennek megfelelően használják a tesztgenerálás során az egyes teszthalmazok tesztelő képességének összehasonlítására Fontos kiemelni, hogy a mértékszámok közelről sem a lehetséges hibák lefedettségét, vagyis a konkrét hibák meglétének teszteltségét mutatják. Mint említettük a ST minden

módszere implicit hibamodellt használ, A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 71 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 72 ► nem állít fel explicit hibamodellt, vagyis a teszteket nem egyes konkrét hibák tesztelése érdekében generálja. Azt is hozzá kell tenni a kép teljességéhez, hogy a tesztelés minőségének számszerű jellemzésére ma a fenti mértékszámoknál jobb eszköz nincs. 4.71 Lefedettségi elemzés (coverage analisys) A mértékszámok tesztelés során történő használatának külön elmélete alakult ki, az ún. lefedettségi elemzés (coverage analisys) Ennek lényege, hogy nagy szoftverek esetén nem mindegy, hogy az egyes teszteket milyen sorrendben hajtjuk végre. Akkor hatékony a tesztelés, ha a tesztelés elején azokat a teszteseteket hajtjuk végre, amelyek viszonylag nagy

átlagos hibafelderítő képességgel rendelkeznek, és az egész szoftvert tesztelik. Nem jó stratégia, ha a nagy szoftverem egyetlen kis részét igen alaposan tesztelem, de maradnak egyáltalán nem tesztelt részei. Akkor hatékony a tesztelés, ha a hibák nagy részét minél hamarabb felderítem, majd a tesztelés további részében találom meg – egyre kisebb gyakorisággal – a nehezen detektálható hibákat. Hatékony és alacsony hatékonyságú tesztelésre jellemző hibafedést és a szoftverben maradó hibák arányának tesztelés során történő változását mutató sematikus ábrákat láthatunk a 4.12 és 413 ábrán hibafedés hatékony tesztelés alacsony hatékonyságú tesztelés tesztelésre fordított idő (erőfeszítés) 4.12 ábra Hibafedés alakulása tesztelés során A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 72 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum

használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 73 ► szoftverben maradó hibák alacsony hatékonyságú tesztelés hatékony tesztelés tesztelésre fordított idő (erőfeszítés) 4.13 ábra Szoftverben maradó hibák változása tesztelés során A fenti elvnek megfelelően a tesztelés elején célszerű egy nem szigorú (nem a legalaposabb tesztelést biztosító) mértékszám alapján generált teszthalmazt használni, vagy nem teljes (100%-os) lefedettséget célul tűzni ki. Ezután a tesztelés későbbi fázisában az egyre szigorúbb mértékszámokat alkalmazni, ill egyre szigorúbb, egyre magasabb lefedettségi értékeket használni. 4.72 Utasítás lefedettség Az utasítás lefedettség definíciója: S(c)=s/S Ahol s a tesztelés során legalább egyszer végrehajtott utasítások száma, S pedig a program összes utasításának a száma. Nem szigorú tesztelési mértékszám. Vegyük pl a következő kódrészletet: int* p = NULL; if

(feltétel) p = &variable; *p = 12; A fenti kódrészlet teljesen fedettnek tekintjük az utasítás lefedettség mértékszám szerint, akkor is, ha nincs olyan teszt, amely hatására a feltétel hamis értéket vesz fel. Viszont egyértelmű, hogy hibát okoz, ha futás során a feltétel hamis értéket kap A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 73 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 74 ► 4.73 Döntés lefedettség (ág lefedettség) Az döntés lefedettség definíciója: D(c)=d/D Ahol d az elágazás utasításokban szereplő feltételek (döntések) kimenetek tesztelés során bekövetkezett értékeinek száma, D pedig a program összes elágazás utasításában szereplő feltételek kimenetének lehetséges száma. A döntés lefedettség tehát akkor teljes, ha a programban szereplő összes döntés

minden lehetséges kimenete előfordult a tesztelés során. A döntés lefedettség alternatív elnevezése az ág lefedettség, ugyan is a döntés lefedettséget definiálhatjuk az FVG alapján is: A tesztelés során legalább egyszer bejárt FVG ágak száma osztva az FVG-ben található összes ág számával. A 100% ág lefedettség már sokkal alaposabb tesztelést eredményez, azonban nem biztosítja az összetett elágazás feltételek alapos tesztelését. Vegyük a következő példát: if ( feltétel1 && ( feltétel2 || függvény1() ) ) utasítás1; else utasítás2; A fenti kódrészlet teljesen lefedett az ág lefedettség szerint, ha van egy olyan teszteset, ahol a feltétel1==IGAZ, feltétel2 ==IGAZ valamint egy olyan teszteset, ahol feltétel1==HAMIS. Ebben az esetben pedig a függvény1() egyáltalán nem hívódott meg a tesztelés során, ami triviálisan nem alapos tesztelés. 4.74 Bool (feltétel) lefedettség Az Bool (feltétel) lefedettség

definíciója: B(c)=b/B Ahol b az elágazás utasítások feltételeiben szereplő Bool-kifejezésekben a tesztelés során tesztelt bemeneti kombinációk száma, B pedig az elágazás utasítások feltételeiben szereplő Bool-kifejezésekben a lehetséges bemeneti kombinációk összes száma. A Bool (feltétel) akkor teljes, ha az elágazás utasítások feltételeiben szereplő Bool változók minden lehetséges kombinációt felvesznek a tesztelés során. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 74 ► Szoftver-minőségbiztosítás Szoftver-tesztelési módszerek A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 75 ► A Bool lefedettség alaposabban teszteli az elágazás utasítások feltételeit, azonban érdekes módon készíthető olyan kód, amely esetén a teljes Bool lefedettség nem eredményez teljes döntés lefedettséget. 4.75 Út lefedettség Az út lefedettséget az FVG alapján

definiáljuk. Az út lefedettség definíciója: P(c)=p/P Ahol p az FVG-ben a tesztelés során bejárt (végrehajtott) utak száma, P pedig az FVG összes út száma. Az út lefedettség akkor teljes, ha az FVGben található összes út bejáródott a tesztelés során Az út lefedettség igen szigorú mértékszám. Teljes út lefedettség 100%-os utasítás lefedettséget és 100%-os ág lefedettséget biztosít. Nagyon képletes mérték, mert a teljes lefedettség azt jelenti, hogy a programomat minden lehetséges vezérlési ág-kombinációja esetén végrehajtottam, teszteltem Az út lefedettség problémája, hogy az FVG-ben lehetnek nem bejárható utak, mint azt korábban már láttuk, és ezek megléte a teszthalmaz generálását megnehezíti. 4.8 A módszerek összekapcsolása Azok a teszttervezési módszerek, amelyeket ebben a fejezetben tekintettünk át, egy teljes, összefüggő láncba kombinálhatók össze. A kombinálásnak az adja az értelmét, hogy

önmagában egyik módszer sem elegendő arra, hogy alapos, átfogó vizsgálatot eredményezzen. Másrészről pedig mindegyik módszer egy különállóan hasznos tesztcsoportot állít elő, amelyek jól kiegészítik egymást. A célszerű stratégia abból áll, hogy először a funkcionális tesztek sorozatát hajtjuk végre, azt követően pedig a strukturális tesztekét. Természetesen nincs biztos garancia arra, hogy minden előforduló szoftverhibát fel tudunk fedni ez által, viszont azt tudjuk, hogy észszerű kompromisszum árán jutunk el a végeredményhez. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 75 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 76 ► 5. Tesztelési stratégiák és folyamatok Ebben a fejezetben a szoftver rendszerek fejlesztési folyamatának az általános menetét vázoljuk fel, ehhez

kapcsolódóan pedig az ellenőrzésitesztelési eljárások szerepét, funkcióját ismertetjük, megmutatva, hogy azok hogyan illeszkednek be a teljes folyamatba. A 3. fejezetben már kifejtettük, hogy a szoftverfejlesztés legigényesebb, legpontosabb végrehajtására a biztonságkritikus rendszerek esetében van szükség. Biztonságkritikus rendszereket már régóta használnak, már a számítógépek megjelenése előtti időkben is voltak ilyen alkalmazások, és még ma is léteznek. Tipikus példái ennek a relés vasúti biztosítóberendezések, amelyek a pályaudvarok forgalmának az automatizált vezérlésére szolgálnak. A relés szabályozások-vezérlések körében még mindig működnek olyan berendezések, amelyeknél a biztonság az elsődleges szempont A számítógépek megjelenésével és elterjedésével hatalmas mértékben nőtt meg a teljesítmény, viszont számtalan új gond, probléma jelentkezett, éppen hogy a biztonság szempontjából. Hardver

téren az integráltsági fok minden elképzelhető határon túli növekedése (10-50-100 millió tranzisztor egy processzor-chipben), szoftver téren az ugyancsak milliós nagyságrendben lévő utasításszám mind olyan veszélyeket hordoz magában, amelyek a biztonság rovására dolgoznak. A rendszerek teljesítményének növekedésével együtt járt a bonyolultság lényeges növekedése is. Megnőtt az emberi eredetű tervezési, javítási és üzemeltetési hibák előfordulásának valószínűsége. Az ilyen rendszerek tervezésénél, üzemeltetésénél igen nagy gondot kell fordítani arra, hogy az emberi közreműködésből származó veszélyek mértékét a minimálisra lehessen csökkenteni. Ennek az a módja, hogy minél nagyobb teret kell szentelni az automatizmusoknak, így minél kevesebb teret hagyni az emberi beavatkozási lehetőségeknek. A kellő optimális arány megteremtése átgondolt és alaposan kiművelt tervezési megoldásokat követel.

Felvethető az a kérdés, hogy mi a különbség hardver és szoftver között a biztonság szempontjából. Kijelenthetjük, hogy a két szféra közül a szoftver az, amely a legtöbb gondot, problémát okozza. A hardvernek hosszabb időre visszanyúló kialakulási, fejlesztési, beüzemelési múltja, folyamata van, mint a szoftvernek. Sokkal több technológiai tapasztalat gyűlt össze ezen a téren Olyan elterjedt megoldások, alkatelemek, mikroprocesszorok, memó- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 76 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 77 ► riák, egyéb szabványos, kipróbált építőelemek vannak világszerte forgalomban, amelyek jól beváltak, amelyeket mindenütt használnak. Az elterjedtségből adódóan az esetleges tervezési hibák is könnyebben napfényre kerülnek. Jó példa erre az

Intel-Pentium processzor első kibocsátott változata, amelyről egy felhasználó derítette ki, hogy hibásan működik Az illető egy amerikai matematikus volt, aki képfeldolgozási számításokat végzett, és magas helyértékű lebegőpontos műveleteknél talált bittévesztést. Az Intel cég számára ez óriási fiaskó volt. A hiba kijavításáról, majd a hibás processzorok becseréléséről, ill. megsemmisítéséről szinte azonnal gondoskodtak A hardvertechnológia fejlődésével a versenyben fennmaradt vezető nyugati és japán cégek olyan magas szintre tudták már emelni a fejlesztési és gyártási minőségbiztosítást, hogy ezzel lényegesen javult az általuk kibocsátott termékek megbízhatósága és időtállósága. A szoftver ezzel szemben mindegyik fejlesztésnél egyedi, speciális, az adott alkalmazáshoz lett létrehozva. Ezeket nem használják fel széles körben, a kereskedelmi forgalomban nem hozzáférhetőek Mindez lényegesen csökkenti

a biztonságos működésről szerezhető tapasztalatok lehetőségét, ezáltal a jelentkező hibák kiszűrésének lehetőségét is. Egy konkrét biztonságkritikus rendszerről összegyűjtött tapasztalatok is állnak rendelkezésünkre. Az USA-beli AT & T Bell telefontársaság számítógépes vezérléssel üzemelteti az egész országra kiterjedő hálózatát Itt 10-perces leállás már több milliárd dollárban mérhető veszteséget, ill. kárt okozhat. A Bell az általa üzemeltetett rendszerében 1997-ben statisztikai felmérést végzett a leállási idők okaira vonatkozóan. Eszerint az egy évre terjedő eredmények azt mutatták, hogy 70%-ban szoftverhiba, 20%-ban átmeneti és időzítési hardver-hiba, továbbá állandósult statikus hardverhiba csak 10%-ban volt a leállások előidézője. Mindez alátámasztja a szoftver-minőségbiztosítás jelentőségét, a fejlesztési és vizsgálati folyamatok minél alaposabb elvégzésének fontosságát. 5.1

Szoftverfejlesztési modellek Amíg egy szoftvertermék elkészül, addig több fejlesztési fázison megy keresztül. Ilyen fázisok lehetnek a következők: specifikálás – rendszerterv elkészítése – programterv elkészítése – kódolás – modulok tesztelése – modulok összeépítése (integrálása) – rendszertesztelés. Minden szoftver rendszerhez egy ún. életciklus tartozik Az életciklus mindazon tevékenységek, fázisok sorozata, amelyek a fejlesztés elkezdésé- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 77 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 78 ► től a rendszer használatba vételén keresztül addig tartanak, amíg a rendszer már végleg használaton kívül kerül. Az életciklus a követelmények specifikálásával veszi kezdetét. Ennek alapján megy végbe a fejlesztési

folyamat, ami az üzembe helyezéssel, majd az üzemeltetéssel és karbantartással folytatódik, egészen a használaton kívülre kerülésig. A szoftverek életciklusára nézve több modellt dolgoztak ki. A legelterjedtebb modellek: az ún vízesés modell, a spirál modell, valamint a V-modell Ezeknek a modelleknek az elnevezése az egymás után következő életciklus-fázisok geometriai elrendezésének alakja szerint történt. A különböző modellek a fejlesztési projektek egyes fontosabb aspektusainak hangsúlyozásában térnek el egymástól. Így például a vízesés modell leginkább a vállalati információs rendszerekhez alkalmas, a spirál modell pedig az erőforrások elosztására és a költségekre koncentrál A Vmodell a biztonsági követelmények teljesítéséhez alkalmazkodik Mindegyik technikának megvan a maga előnye és hátránya Ezeknek a modelleknek az elemzésével és összehasonlításával ebben a könyvben nem foglalkozunk A modellek

legfontosabb közös vonása az, hogy mindegyikük egy új minőségbiztosítási-fejlesztési paradigma sajátságait hordozza magában. Ez a paradigma abban tér el az előző paradigmától, hogy nem a fejlesztés lefolytatása után kísérli meg a termék előírások szerinti kialakítását, hanem a fejlesztési folyamat minden egyes fázisában gondoskodik az ahhoz a fázishoz előírt feltételek betartásáról. A szakirodalomban szereplő szemléltető példa a kávéfőzésből van kiválasztva A régi metódus szerint megfőzték a kávét, és a benne maradt kávéport megpróbálták eltávolítani, amenynyire csak lehetett Az új metódus szerint a főzés során a kávé több szűrési procedúrán megy keresztül, és az utolsó fázist követően már gyakorlatilag nem tartalmaz kávéport. A vízesés modell főbb fázisai: • • • • • • • Rendszerkövetelmények megadása. Szoftver-követelmények megadása. Előzetes programtervek elkészítése,

elemzése. Programtervezés. Programkódolás. Tesztelés. Működtetés. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 78 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 79 ► A spirál modell főbb fázisai a következők: • • • • • • • • • • • • • • A működési koncepció kialakítása. Követelmények tervezése. Életciklus tervezése. Kockázat-analízis. Szoftver-követelmények meghatározása. Szoftver-termék tervezése. A tervezés verifikálása és validálása. Integrálás és tesztelés tervezése. Részletes tervezés. Kódolás. Egységek (modulok) tesztelése. Összeintegrálás és tesztelés. Elfogadási tesztelés. Üzembe helyezés. A biztonságkritikus számítógéprendszerek esetében a V-modell használata terjedt el. Ugyanis ez illeszkedik legjobban ehhez az informatikai

típushoz Egy tipikus életciklus-modellt mutatunk be az 5.1 ábrán, ahol az egyes fázisok V alakú elrendezésben követik egymást. Az egyes elemek sorrendje egyben a munkafázisok sorrendjét is tükrözi. A modell jól kifejezi a tervezési folyamat fentről lefelé történő haladását (top-down megközelítés) a diagram baloldali ágában, míg a tesztelési folyamat lentről felfelé halad (bottomup megközelítés) a jobboldali ágban Az ilyen ábrázolás csak megközelítőleg írja le a fejlesztést. A gyakorlatban a különböző fázisok nem szigorúan a megadott sorrendben hajtódnak végre. A tervezés gyakran nagy számú iterációt foglal magában, olyan műveletek sorával, amelyeket addig kell ismételni, amíg kielégítő eredményre nem jutunk. Párhuzamosságok ugyancsak lehetségesek. Másrészről az 51 ábra még nem tünteti fel az egyes állapotok között információáramlást. A következőkben részletesebben fogunk végigmenni az ábra

V-modelljén, magának a modellnek a szükség szerinti részletezésével, finomításával együtt. Ebben a tárgyalásban a teljes informatikai rendszer tervezését is érintjük, amennyiben kitérünk a hardvertervezésre is, olyan mértékben, ahogyan az a szoftverre kihatással bír. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 79 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom 1. 2. Követelmények specifikálása Rendszervalidálás Architektúratervezés 5. 80 Modultervezés 6. Rendszerverifikálás Rendszer integrálása és tesztelése ► 11. 10. Bizonylatolás Specifikálás 4. ◄ Rendszer üzemeltetése Hazárd- és kozkázatanalízis 3. Vissza 9. 8. 7. Modulok előállítása és tesztelése 5.1 ábra Az életciklus V-modellje Egy rendszer fejlesztési életciklusának állomásai Az 5.1 ábra blokkjainak

számozását követve, az alábbi magyarázatok tartoznak az egyes blokkokhoz: 1. Követelmények specifikálása: Minden fejlesztési folyamat kiindulási pontját a rendszerre vonatkozó követelmények képezik. Ennek megjelenési formája: Funkcionális követelmények dokumentációja A doku- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 80 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 81 ► mentáció azt írja le, hogy milyen funkciókat és milyen módon kell a rendszernek teljesíteni. Például a Magyar Állami Vasút (MÁV) ún feltétfüzetben írja elő a vasúti biztosítóberendezések funkcióit 2. Hazárdok és kockázatok elemzése: Célja: a lehetséges veszélyhelyzetek meghatározása a rendszerben, a megelőző kiszűrés érdekében Hazárd: Olyan helyzet, amely egy valóságos vagy lehetséges veszélyt

jelent az emberek vagy a környezet számára. Kockázat: Egy hazárdhoz kapcsolódó események és azok következményei, valószínűségi alapon. Azt fejezi ki, hogy milyen valószínűségű veszélyes következményei lehetnek egy hazárdnak. Az analízisek elvégzéséhez különféle módszerek állnak rendelkezésre. A hazárdanalízisre az alábbiak használatosak: – Hibamódok és hatásuk analízise: Ebben az eljárásban komponenshibákat tételezünk fel külön-külön, és azt vizsgáljuk, hogy a hibáknak milyen hatásuk lehet a rendszer biztonságára. Ez úgy történik, hogy végigkövetjük a hiba hatását a teljes működésen keresztül Ha ezt számítógépes modellen végezzük, akkor hibaszimulációról beszélünk Ilyenkor egy hibamodellező szoftver felhasználásával szimuláljuk a működést A feltételezett hibák lehetnek kisebb részegységben, nagyobb modulban stb., a modellező programtól függően. A modellezés történhet hardver-elem

szinten, vagy pedig funkcionális szinten is, a teljes működés lejátszásával, ahol a hardvert és szoftvert együtt, egészben véve kezeljük. – Eseményfa-analízis (event-tree analysis): Ennek az elve hasonlít a hibahatások analíziséhez. Itt egy-egy olyan eseményt tételezünk fel, amely hatással lehet a rendszer működésére Az analízis során ennek a hatását követjük végig. Nemcsak a lehetséges hibás eseményeket vesszük kiindulásul, hanem a normál módon betervezett eseményeket is. Ennek az az oka, hogy a normál eseményekből is adódhat katasztrófa, a hibás tervezés folytán. Az eseményfa egy fa típusú irányított gráf, amelynek gyökere a kiindulási esemény, ezt követően pedig annak hatásai szerint ágazik szét a különböző szinteken, egészen a lehetséges végső kimenetelekig (a fa leveleiig). Ha egy végső kimenetel veszélyt jelent, akkor gondoskodni kell annak megszüntetéséről, a tervezésbe való visszanyúlással, vagy

pedig a rendszer működtetésére vonatkozóan kell olyan előírásokat lefektetni, amelyek kizárják a vészhelyzet fellépését. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 81 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 82 ► – Hibafa-analízis (fault-tree analysis): Ez a megoldás is egy fa típusú irányított gráf kiépítésén alapul. A kiindulás viszont itt teljesen fordított, ennek megfelelően a gráfon történő haladás iránya is fordított, az irányítással ellentétes. Kiindulásként egy vészhelyzetet tételezünk fel, és azt határozzuk meg szintről szintre visszafelé haladva, hogy mik lehetnek előidézői az adott vészhelyzetnek. A gráf egy-egy csúcsa logikai Boole-operátort képvisel: ÉS, VAGY, ill. NEM műveletet. Ez azért van így, mert a kiindulási helyzetet előidéző

lehetséges okok meghatározásakor az okok együttes (ÉS), külön-külön (VAGY), ill. tagadó (NEM) létezését kell megállapítanunk Ha egy vészhelyzetről kiderül, hogy semmiképpen nem következhet be, akkor nincs szükség a módosításra Ha viszont találunk legalább egy okot, amitől bekövetkezhet, akkor a terv átalakítása válik szükségessé A kockázatok elemzésére valószínűség-számítási segédeszközöket használnak fel, aminek eredményeként számszerű értékeket rendelnek az egyes veszélyes következményekhez. Az elemzési folyamatok eredményeként létrehozandó a biztonsági követelmények dokumentációja. Ez a dokumentum arra ad előírást, hogy mit kell betartani a rendszernél, mit szabad, ill. mit nem szabad megengedni a rendszer működése során 3. A teljes rendszerspecifikáció: A funkcionális követelmények valamint a biztonsági követelmények együttese alkotja Mindezen specifikáció alapján megkezdhető a teljes rendszer

konkrét tervezési folyamata 4. Architekturális tervezés: A teljes informatikai rendszer architektúrája hardverből és szoftverből tevődik össze. A tervezésnek ebben a fázisában azt kell eldönteni, hogy mely funkciók legyenek megvalósítva hardver, és melyek szoftver által. Az általános működés szempontjából ez a tervezési fázis döntő szerepet játszik. A két informatikai szféra közötti megosztás egyaránt kihatással van a sebességre, a megbízhatóságra, a teljesítményre, valamint a biztonságosságra. A vasútirányító számítógépek például tipikus valós idejű rendszerek, amelyeknél mindegyik reakcióidőnek igazodni kell a forgalmi események időtartamaihoz. Megjegyzendő még, hogy ma már egyre inkább terjedőben van a hardver-szoftver együttes tervezésének kivitelezése, angolul az ún. HW-SW co-design. Ebben a megközelítésben a tervezési folyamatnak csak egy későbbi szakaszában dől el a HW-SW-megosztás, addig a

tervezés azonos elveken, azonos eszközökkel halad előre. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 82 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 83 ► A tervezés eredményeként létrejönnek a hardver és a szoftver rendszertervei, tervdokumentációk formájában. Ezek alapján mind a hardvert, mind pedig a szoftvert hierarchikusan fentről lefelé haladva (top-down) tervezik meg. A következőkben az életciklusnak a szoftver vonalára fogjuk a hangsúlyt helyezni, a hardverrel csak érintőlegesen foglalkozunk 5. A szoftver modulokra bontása: Célja a tervezési folyamat egyszerűsítése, áttekinthetőbbé tétele, a fejlesztési feladatok részekre való szétosztása A tervezés eredményeként a szoftver modulok specifikációja, valamint a köztük levő interfészek, ill. kapcsolódási folyamatok terve

készül el. 6. A modulok elkészítése és tesztelése: Ebben a szakaszban történik meg az egyes modulok forrásnyelvi kódjának megírása, a modulok egyenkénti lefordítása, a nyomkövetéses fejlesztői „belövése”, ezt követően pedig az elkészült modulok önálló tesztelése. A tesztelési folyamatok előzetesen megtervezendők A tesztelés már integráns része a szoftver verifikációs folyamatának, amelyben azt döntjük el, hogy egyegy modul megfelel-e a specifikációjának. Ehhez az inputot a modulok terve szolgáltatja. 7. A szoftver-modulok összeintegrálása: Miután mindegyik modul átment a tesztelésen, a teljes rendszer összeintegrálására kerül sor. A gyakorlatban kétféle megközelítés terjedt el erre vonatkozóan: a) Integrálás egyenkénti bővítéssel és teszteléssel: Inkrementális tesztelés. Ekkor egy kiindulási, minimális számú modulhoz egymás után illesztjük a bővítésként szolgáló modulokat. Minden egyes bővítés

után külön teszteljük az addig összeállt komplexumot. A megoldás előnye az, hogy az újabb hibák egy-egy bővítés során léphetnek be nagy valószínűséggel, s így könnyebb felfedni őket a bonyolultság lépcsőzetes növekedésével. b) A másik megközelítésben az összes modult egyszerre rakjuk össze, és a teljes komplexumra hajtjuk végre a tesztelést. Ez a megoldás azon a feltevésen alapul, hogy az előzetesen kitesztelt modulok már nagy valószínűséggel együtt is helyesen fognak működni. A leírt megközelítés az ún. „big bang tesztelés (testing)” Az elnevezés arra utal, hogy számítanunk kell az első indítást követő összeomlásra. (Big bang: nagy csattanás.) Ekkor a hibák megtalálása viszonylag nehezebb lesz a feladat bonyolultsága miatt. Ennek a folyamatnak a végrehajtásához a bemenő ionformációt a modulok terve, és a teljes rendszer terve képviselik. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom

Vissza ◄ 83 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza Követelmények elemzése ◄ 84 ► Üzemeltetés/ Karbantartás Követelmények dokumentációja Bizonylatolt rendszer Rendszerspecifikálás Validálás/ Bizonylatolás Rendszerspecifikáció Verifikált rendszer Felső szintű tervezés Rendszer tesztelése Rendszer terve Összeintegrált rendszer Részletes tervezés Rendszer összeintegrálása Modulok terve Tesztelt modulok Konstrukciós tervezés Kódolás Modulok tesztelése Modulok 5.2 ábra V-modell a tevékenységek eredményeivel A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 84 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 85 ► 8. A teljes rendszer verifikálása: Ebben a

fázisban eldöntendő, hogy a teljes rendszer megfelel-e a specifikációjának, vagyis funkcionálisan teljesíti-e az összes specifikációs pontot. Az ehhez felhasználandó input: A rendszer terve, valamint a teljes rendszer-specifikáció. 9. A teljes rendszer validálása: Azt döntendő el, hogy a teljes rendszer megfelel-e a felhasználói követelményeknek. Ebbe beletartozik a biztonsági feltételek teljesítésének eldöntése is: az ún biztonságigazolás (Ez az előírt funkciók ellenőrzésén túli ellenőrzést követel meg) Input: A rendszerkövetelmények dokumentációja, és a teljes rendszer-specifikáció 10. Bizonylatolás (certification): A hatósági előírások és szabványok szerinti megfelelés eldöntése, és az erre vonatkozó bizonylatok kiállítása. Input: A rendszer-követelmények dokumentációja, és a teljes rendszer-specifikáció 11. Üzembe helyezés, üzemeltetés, karbantartás, elavulás, üzemeltetés megszüntetése: Input: A

biztonsági követelmények dokumentációja A fentiekben felvázolt V-modell részletesebb megjelenítése az 5.2 ábrán látható. Az ábra szögletes blokkjai az egyes fázisok tevékenységét tartalmazzák, a kerekített sarkú blokkok a kimenti eredményeket képviselik, a folyamatos nyíl az információ elsődleges áramlását, a szaggatott nyíl pedig a másodlagos információáramlást jelzi. 5.2 Verifikáció és validáció A szoftverfejlesztésben alapvető követelmény a fejlesztési folyamat mindvégig helyes, következetes végrehajtása. A fejlesztés egyes stádiumaihoz egymástól eltérő megvalósítási reprezentációk tartoznak. A helyes végrehajtás deklarálása azt kívánja meg, hogy bizonyítsuk ezen reprezentációk közötti egyértelmű összhang teljesülését. Ekkor valójában azt kell bizonyítanunk, hogy a végeredményként kiadódó szoftver-termék 100%-ig megfelel a kiindulási specifikációnak A bizonyítási folyamat elvégzése úgy

logikus, hogy az egymást követő fejlesztési fázisok közötti összhang, ekvivalencia igazolását végezzük el lépésenként. Ha eltérés adódik, akkor az éppen vizsgált fázist addig kell módosítani, amíg összhangba nem kerül az őt megelőző fázissal. A teljes folyamatot az 53 ábrán szemléltetjük A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 85 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 86 ► Szoftver specifikáció 1. tervezési fázis Módosítás Nem 1. fázis megfelelő Igen 2. tervezési fázis Módosítás Nem 2. fázis megfelelő Igen • • • Módosítás Nem Utolsó fázis megfelelő Igen Szoftver-végtermék 5.3 ábra A fejlesztési fázisok kapcsolata Az egymást követő fejlesztési fázisok közötti összhang, ekvivalencia ellenőrzési folyamatát nevezzük verifikációnak.

Pontosabb definícióval ezt a következő módon fogalmazhatjuk meg: Verifikáció: Az a folyamat, amelyben meghatározzuk, hogy a vizsgált informatikai rendszer szoftvere teljesíti-e mindazokat a követelményeket, amelyeket egy előző fázisban specifikáltak a szoftver fejlesztési vagy előállítási folyamatában A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 86 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 87 ► Ezen a ponton azonban meg kell állapítanunk, hogy a biztonságkritikus szoftverek fejlesztése során a verifikációs folyamat tökéletes végrehajtása nem garantálja a végtermék tökéletes felhasználhatóságát. Amit a verifikálással garantálni lehet, az a kiindulási specifikációval való ekvivalencia teljesülése Abban az esetben viszont, ha a specifikálásban történt hiányosság vagy

tévedés, a végtermék nem fog minden tekintetben megfelelni a felhasználási követelményeknek. Szükség van tehát arra is, hogy vizsgálat alá vessük a szoftver-végterméket abból a szempontból, hogy megfelel-e a valódi rendeltetésének. Erre nézve külön vizsgálati eljárásra van szükség, amit validációnak nevezünk. Ennek definíciója a következő: Validáció: A teljes szoftver vizsgálata és kiértékelése azzal a céllal, hogy meghatározzuk, minden szempontból megfelel-e a felhasználói követelményeknek. Egy biztonságkritikus rendszernél a következőket kell igazolni: • A funkcionális megfelelőséget. • A teljesítményben való megfelelőséget. • A biztonsági követelmények teljesülését. A validációs eljárásban tehát külön kell azt vizsgálni, hogy a teljes rendszer biztonságos-e. Az erre szolgáló tesztelésben a legkülönfélébb helyzeteknek kell kitenni a vizsgált rendszert, azzal a céllal, hogy annak a biztonságot

nem veszélyeztető működéséről győződhessünk meg. Ennek a folyamatnak lehet olyan eredménye, amely specifikációs hiányosságokra utal Ilyenkor vissza kell térni a kiindulási specifikációhoz, azt a szükség szerint módosítani, majd a módosításokat az összes fejlesztési fázison keresztül lépésenként végigvezetni, a velejáró verifikációs eljárásokkal egyetemben Természetesen megismétlendő a végső validálás is Magától értetődik, hogy a fenti eljárás nem valósítható meg üzemi körülmények között, mégpedig biztonsági okokból. A megoldás az, hogy a teljes szoftver rendszer számára egy számítógépen szimulált környezetet hoznak létre, amelynek keretén belül a tesztelési-validálási folyamatot el lehet végezni. A verifikáció és a validáció a fejlesztési folyamat két összefüggő velejárója, a két eljárás mindig együtt kezelendő. Szokás ezeket így „V & V” eljárásnak is rövidíteni. A

dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 87 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 88 ► Ha összehasonlítást teszünk a két megközelítés között, akkor a következő tömör megkülönböztetést tudjuk tenni: • A verifikáció végső soron arra ad választ, hogy a termék előállítása helyesen történt-e. • A validáció arra ad választ, hogy a helyes terméket állítottuk-e elő. A fentiekhez még a következő fontos megjegyzést fűzzük: Nem minden szoftverfejlesztés követeli meg a V & V eljárás végrehajtását. Az olyan esetekben, amikor teljes bizonyossággal kijelenthető, hogy a kiindulási specifikációban nincsen semmilyen hiányosság, nincs szükség a validálásra. Ekkor elegendő a specifikációval való összhangot bizonyítani, vagyis egyedül csak verifikálni Ilyen eset

lehet például egy jól definiált algoritmust vagy számítási eljárást megvalósító szoftver elkészítése, ami akár egy igen nagy, összetett rendszert is adhat eredményül. A biztonságkritikus rendszerek azonban nem ebbe a kategóriába esnek, itt mindig szükség van mind a két V-re. 5.3 A verifikáció és a validáció fázisainak tervezése Amikor egy biztonságkritikus rendszer tervezése történik, a teljes ráfordításnak igen jelentős részét képezi a verifikációnak és a validációnak a megtervezése. Következésképpen az előre való tervezés lényeges mind a költségek becslése, mind pedig minimalizálása szempontjából Mivel a verifikálás és a validálás egyaránt a tesztelésen alapul, a tesztek megtervezése igen fontos része lesz a fejlesztési folyamatnak. A tervezés egyik területe a szoftveregységek, vagyis a modulok ellenőrzése, a másik pedig a modulok összeintegrálásának ellenőrzése. A teljes rendszer validálása a

rendszerfejlesztés utolsó fázisai közé tartozik, viszont ennek a tevékenységnek a megtervezése már egy korai szakaszban meg kell hogy történjék Ennek az a legfőbb indoka, hogy a validációs terv befolyásolni tudja magának a projektnek a további menetét. A validációs szempontoknak a figyelembe vétele a tervezés egy korai szakaszában jelentős megtakarításhoz vezethet a későbbi szakaszok ráfordításában. Az 5.3 ábra szerinti folyamatot tekintve látható, hogy a projekt korai fázisai információs kapcsolatban vannak a későbbi fázisokkal, amit a szaggatott vonalak fejeznek ki. A diagram jobboldali ága a megvalósítási, ill a tesztelési tevékenységeket képviseli. Amint a rendszer az egyes modulok- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 88 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 89

► ból teljes egésszé kezd összeépülni, úgy kell az építési állapotokat összevetni a nekik megfelelő tervezési állapotokkal. Így például egy adott modul megvalósítását a modul tervével összehasonlítva kell tesztelni, míg a teljes rendszert a rendszer specifikációja alapján teszteljük. Az erre vonatkozó teszttervezési tevékenységet be lehet iktatni a V-diagramba, amint azt az 5.4 ábra mutatja Az ábrából világosan kitűnik, hogy a baloldali ág minden egyes fázisának egy újabb fázisba való transzformációjához meg kell tervezni a transzformáció helyes végrehajtásának verifikálását. A rendszer validálása megköveteli, hogy a rendszer összes szempontját, továbbá az összes működési módját tekintetbe vegyük. Ez többek között azt jelenti, hogy a különböző technológiákon alapuló biztonsági mechanizmusokat is vizsgálni kell, mint például a hardvert, vagy a mechanikus, esetleg hidraulikus részeket, és az ezekhez

kapcsolódó külső kockázatcsökkentő megoldásokat Mielőtt egy rendszert megvalósítanának, végső validálását meg kell tervezni, az összes olyan tényező figyelembevételével, amelyek a biztonságot befolyásolják Az IEC 1508 szabványtervezet 1995-ös változata megad egy követelménylistát az általános validációs tervekre vonatkozóan. (IEC: International Electrotechnical Commission, Nemzetközi Elektrotechnikai Bizottság) A követelménylistát az alábbiakban ismertetjük: a) Annak leírása, hogy a validálás mikor hajtandó végre. b) Annak megadása, hogy ki hajtja végre a validálást. c) A rendszerműködés figyelembe veendő módjainak megadása, az alábbiak szerint: – A használat előkészítése – Indítás – Automatikus üzemeltetés – Manuális üzemeltetés – Félautomatikus üzemeltetés – Állandósult állapotbeli működés – Újraállítás (reset-elés) – Teljes leállítás – Karbantartás – Előrelátható

abnormális feltételek kezelése d) A biztonságra kiható rendszerek megadása, és azon külső kockázatcsökkentő eszközök megadása, amelyeket validálni kell mindegyik működési módban. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 89 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza Követelmények elemzése ◄ 90 ► Üzemeltetés/ Karbantartás Követelmények dokumentációja Bizonylatolt rendszer Teszttervezés Rendszerspecifikálás Validálás/ Bizonylatolás Rendszerspecifikáció Verifikált rendszer Teszttervezés Felső szintű tervezés Rendszer tesztelése Rendszer terve Teszttervezés Részletes tervezés Modulok terve Összeintegrált rendszer Rendszer összeintegrálása Teszttervezés Konstrukciós tervezés Kódolás Tesztelt modulok Modulok tesztelése Modulok 5.4 ábra Az életciklus

V-modellje a teszttervezéssel A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 90 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 91 ► e) A validálás technikai stratégiája. f) Intézkedések, technikák, eljárások, amelyek arra használandók, hogy mindegyik biztonsági funkcióról el legyen döntve, hogy az megfelel-e az általános biztonsági követelményeknek. g) Hivatkozások az általános biztonsági követelmények dokumentumaira. h) A szükséges környezet, amelyben a validálás tevékenységet el kell végezni. i) Az elfogadási/elutasítási kritériumok. j) Irányelvek és szabályok a validációs eredmények kiértékelésére vonatkozóan. A következő alpontokban a tesztelési folyamatok különböző fázisainak részletesebb ismertetésével foglalkozunk, modul szinttől kezdve, a rendszer szintig

bezáróan. 5.4 Egységek, modulok tesztelése A legtöbb programozási nyelv lehetővé teszi a programkód kisebb- nagyobb darabokban történő előállítását (függvények, szubrutinok). Ezt az egyre bonyolultabbá váló alkalmazások strukturált fejlesztése is motiválta. A moduláris fejlesztés lehetővé teszi a moduláris vagy egységenkénti tesztelést. Az egységtesztelés egy tesztelési szintet képvisel, megjelenhet a szoftver-életciklus tesztelési fázisának elemeként vagy a kódolással szorosan összekapcsolódva. Mint tesztelési szint kapcsolódik mind a különböző magas szintű tesztelési stratégiákhoz (megközelítésmódokhoz) és mind bizonyos tesztelési technikákhoz (konkrét eljárások) is. Előbbiek meghatározzák az egységtesztelés kereteit (általános tesztelési stratégia), formáját és hatékonyságát (a szinthez kapcsolódó stratégia) és az utóbbiak kiválasztását (a szinthez kapcsolódó stratégia megkívánta

technikák). Az egységtesztelés jórészt white-box jellegű strukturális tesztelési keretbe illeszkedik Ezt az indokolja, hogy a nagy méretű programok strukturális tesztelése bonyolult, illetve a funkcionális tesztek a már integrált rendszer specifikációjára épülnek. A white-box jelleg segíti a tesztelést a fejlesztési fázisban Ez a keret meghatározza az alkalmazott módszereket és technikákat és a tesztelés értékeléséhez választott kritériumokat. Természetesen a modulok tesztelésénél is alkalmazandók black-box módszerek a specifikációnak való megfelelés tesztelésére. Az egységtesztelés tipikus teszteset tervezési eljárása a következő: a modul szerkezetének elemzése white-box módsze- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 91 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 92

► rekkel, majd az így előállított tesztesetek kiegészítése a specifikáció tesztelésére szolgáló black-box módszerekkel előállított tesztesetekkel. Az egység- vagy modultesztek jelentik a szoftverfejlesztés közbeni legalacsonyabb szintű tesztelést. Ilyenkor a szoftver egyes önálló egységeinek tesztjét a program többi részétől elszigetelten végzik. A modultesztek tehát lehetővé teszik, hogy a programot ne csak teljes egészben az elkészülte után teszteljük, hanem a tesztelést már kisebb építőelemeinek elkészülte után is elvégezhessük. A modultesztelést magát a tesztelési fázis végrehajtása is motiválta Egyrészt lehetővé teszi a tesztelési folyamat komplexitásának kezelését (kisebb modulok tesztelésére kell csak összpontosítani), másrészt megkönnyíti a felfedezett hibás működés okának és a hibák helyének pontosabb azonosítását, és végül lehetőséget ad a tesztelés párhuzamosítására több modul

egyidejű tesztelésével. Az így létrehozott tesztesetek nem csak egyszer használatosak a fejlesztés során a hibamentes kódolás ellenőrzésére, hanem mindannyiszor végre kell hajtani őket, ahányszor a szoftveren változtatást végzünk vagy a modult egy új, másik környezetben használjuk fel (regressziós tesztelés) A modultesztek során teszteljük az adott modul és a modult a rendszerhez csatoló interfész funkcionális működését. A modul tesztelése egy tesztkörnyezetben történik, mely lehetővé teszi a tesztesetek ellenőrzött végrehajtását. A modul a tesztkörnyezettel kombinálva alkot egy működő rendszert. Ennek a rendszernek a szerkezetét, kialakítását, erőforrás igényét a követett modultesztelési stratégia határozza meg Kétféle megközelítésmód képzelhető el: az egyik esetben a modulok egymástól teljesen függetlenül kerülnek tesztelésre (izolációs tesztelés), illetve a tesztelendő modul már korábban tesztelt

modulokkal kombinálva kerül tesztelésre (inkrementális tesztelés). A tesztkörnyezetek egy tesztvégrehajtó egységből és egy kiegészítő részből állnak. A tesztvégrehajtó egység a tesztesetek elvégzését biztosítja a megfelelő input paraméterek beállításával, a tesztelendő modul végrehajtásával és a kimenő paraméterek kiolvasásával. A kiegészítő rész a modul eredeti környezetét helyettesíti a teszt során ún. csonkokkal, melyek a tesztelés alatt álló modulból a környezetbe irányuló hívásokat kezelik le és szolgáltatnak visszatérési értékeket. 5.41 A modultesztelés szükségessége és előnyei A gyakorlatban a jól tervezett egységtesztek ugyanannyi erőfeszítés árán hozhatók létre mint az adott egység program kódja. Az egységtesztek elvégzése a hibák nagy részét feltárja és a javítások után a fejlesztők egy A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 92 ►

Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 93 ► sokkal hatékonyabb integrációs fázisba kezdhetnek, tudva azt, hogy megbízható komponensekkel dolgoznak. A jól megvalósított egységtesztelés tehát jobb idő kihasználást biztosít. A modultesztelés nem csak azt bizonyíthatja, hogy a kód azt teszi, amit kódoltak. Ehhez azonban az szükséges, hogy a kódot a specifikációjának tükrében teszteljük. Így nem csak több kódolási hibát, de specifikációbeli hibákat is felderíthetünk. Amennyiben egy specifikáció nélküli modult kell tesztelni, akkor a kód visszafejtésével egy vázlat specifikációt kell létrehozni a modul feltételezett működésére vonatkozóan. Az integrációs, vagyis az alkalmazást egészében tekintő tesztek nem alkalmasak a hibák jórészének felderítésére. Az ok az, hogy a nagyobb kód integrációk sokkal

komplexebbek. Amennyiben a szoftvert alkotó modulok nem estek át egységtesztelésen már maga a szoftver futásának elérése, tesztesetek végrehajtása nélkül, sem kis feladat. Az integrációs tesztelés során nagyon nehéz lehet olyan helyzetek teremtése, hogy egy bizonyos egység végrehajtásra kerüljön és ráadásul kimerítően tesztelve legyen, vagyis az egységszintű alapos tesztelés elérése integrációs tesztelés közben sokkal komplexebb feladat, mint az egyes egységek elszigetelt tesztelésénél. Ennek a következménye pedig az lesz, hogy a szoftver bizonyos részei nem kerülnek tesztelésre és felderítetlen hibák maradnak a benne. Alkalmazás Potenciális hibák Modulok Teszt input 5.5 ábra Az egységszintű hibák felderítése integrációs tesztelés közben nehéz A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 93 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A

dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 94 ► Teszt input Modul Potenciális hibák 5.6 ábra Az egységtesztelés jobb lefedettséget eredményez A szoftver minőségének biztosítása gyakorlatilag az életciklus minél korábbi szakaszában végrehajtott teszteléssel lehetséges. Minél később kerül felderítésre egy hiba, annál magasabb a javítási költsége. Az egységtesztek létrehozása, karbantartása sokkal könnyebb és kényelmesebb mint a későbbi fázisokban végrehajtott teszteké. 5.7 ábra Különböző típusú tesztek egymáshoz viszonyított relatív időigénye A következőkben az egységtesztelés három alapvető szervezési megközelítése, és az egyes stratégiák előnyeinek és hátrányainak leírása következik. A három stratégia összehasonlításához egy egyszerű, az ábrán látható modulhierarchiát fogunk használni. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom

Vissza ◄ 94 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 95 ► A B H C D E F I J G 5.8 ábra Modul hierarchia példa Az ábra a hierarchia szintjeit mutatja: hogyan függenek a felsőbb szinteken lévő egységek az alsóbb szinteken lévőktől (hívási hierarchia). 5.42 Izolációs tesztelés Az izolációs tesztelés során a tesztelés alatt álló modul az általa hívott és az őt hívó moduloktól elszigetelten kerül tesztelésre. Az egységek tetszőleges sorrendben tesztelhetők, mivel egyik egység tesztelése sem kívánja meg más modulok teszteltségét. Minden egyes modulhoz szükség van egy tesztvégrehajtó komponensre és az összes általa hívott egységeket helyettesítő csonkokra. A Te szt é h jtó B H C D Te szte lé s l tt E Cso nk F Cso nk I J G Cso nk 5.9 ábra Izolációs modul tesztelés Amennyiben a

tesztelendő egység a „D”, akkor az ábrán látható tesztvégrehajtó egységre és csonkokra van szükség. A teljes program (hierarchia) egységtesztelése egy lépésből áll, a tesztek sorrendje érdektelen és a tesztek akár párhuzamosan is végezhetők. A tesztelés egyetlen lépése azt jelenti, hogy az összes egységhez el kell készíteni egy tesztvégrehajtó komponenst A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 95 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 96 ► és ha függ más egységektől, akkor az azokat helyettesítő csonkokat is, majd el kell végezni a tesztelést. Az izolációs tesztelés előnyei Könnyebb egy elszigetelt egység alapos, kimerítő tesztelése, amikor is az egységtesztelés mentes a többi egységgel való kapcsolat okozta komplexitástól. Az izolációs tesztelés

biztosítja a legkönnyebb utat a megfelelő strukturális tesztlefedettség eléréséhez, és ennek a lefedettségnek az elérési nehézsége nem függ az adott egység hierarchiabeli helyétől. Mivel egy tesztben csak egy egység kerül tesztelésre, a tesztvégrehajtó egységek egyszerűbbek mint a bottom-up tesztelésnél, ugyanakkor a csonkok általában egyszerűbbek a top-down teszteléshez szükséges csonkoknál. Izolációs egységtesztelésnél az egységtesztek nem függnek egymástól, így az egységtesztelési fázis átfedheti a szoftver életciklus részletes tervezési és kódolási fázisát. Tetszőleges számú egység tesztelhető párhuzamosan, ami rövid egységtesztelési fázist eredményezhet, ez pedig lehetővé teszi a szoftverfejlesztés összidejének csökkentését. További előnye az egységek hierarchiából való eltávolításának, hogy az egy egységen végrehajtott módosítások csak az adott egység tesztjének a változtatását vonják

maguk után és nincsenek hatással más egységek tesztjeire. Az izolációs megközelítés teljesen szétválasztja az egység- és az integrációs tesztelést, ez által lehetővé teszi, hogy a fejlesztők a szoftver életciklus egység tesztelési szakaszában valóban csak egységtesztelésre, míg integrációs teszteléskor csak integrációs tesztekre koncentráljanak. Az izolációs tesztelés az egyetlen teljesen tiszta egységtesztelési megközelítés, míg mind a bottom-up és mind a topdown tesztelés egy hibrid egység és integrációs tesztelésre vezet. Ellentétben a top-down és a bottom-up stratégiákkal, az izolációs egységtesztelésre nincsenek hatással a modulok egymás közötti hivatkozásai Az izolációs tesztelés hátrányai Az izolációs tesztelés egyik legfőbb hátránya, hogy nem biztosítja az egységek korai integrációját. Az integrációval meg kell várni a szoftver életciklus integrációs fázisát (Ez csak bizonyos esetekben

valódi hátrány) Az izolációs tesztelési megközelítés megköveteli strukturális tervezési információk rendelkezésre állását és tesztvégrehajtó modulok és csonkok írását. Mivel ezt az egységhierarchia minden szintjén el kell végezni ezért ez költségesebb lehet mint az inkrementális megközelítés esetében. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 96 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 97 ► 5.43 Top-down tesztelés Top-down egységteszteléskor az egyes modulok az őket hívó modulokból kerülnek tesztelésre, de elszigetelve az általuk hívott moduloktól. Először a hierarchia csúcsán álló modul kerül tesztelésre, az összes hívott modult csonkok helyettesítik. A tesztelés a csonkok tesztelendő egységekkel történő helyettesítésével folytatódik, ahol a mélyebb

szinten lévő hívott egységek helyett megint csonkok állnak Ez a folyamat addig ismétlődik, míg a legalsó szintű egységek is tesztelésre kerülnek. A top-down teszteléshez tehát szükség van teszt csonkokra, de nincs szükség speciális kiegészítő tesztvégrehajtó egységekre. A Te szte lve B Te szte lve H C Te szte lve D Te szte lé s l tt E Cso nk F Cso nk I J G Cso nk 5.10 ábra Top-down modul tesztelés Az ábra a „D” egység teszteléséhez szükséges már tesztelt egységeket és csonkokat mutatja top-down tesztelés esetén. A tesztelés több szekvenciális lépésből áll Tesztelni kell a felső szintű egységet a hívott egységek csonkokkal való helyettesítésével, majd ezután a csonkokat helyettesíteni kell ugyanilyen módon az aktuális tesztelendő egységekkel. A top-down tesztelés előnyei A top-down egységtesztelés az egységek korai, szoftver integrációs fázis előtti integrációját biztosítja. Valójában a top-down

egységtesztelés egy kombinált egységtesztelési és integrációs stratégia. Mivel a modulok részletes tervezése top-down jellegű és a top-down egységtesztelés a teszteket így a modulok tervezési sorrendjében hajtja végre, a fejlesztési időt csökkentheti a szoftver életciklus részletes tervezési és kódolási fázisát átlapoló egység tesztelés. Konvencionális strukturált tervezés esetén a hierarchia csúcsán lévő egységek biztosítják a szoftver magas szintű funkcióit, míg a mélyebben lévő egységek implementálják a részleteket. A top-down egy- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 97 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 98 ► ségtesztelés ebből kifolyólag a „látható” funkcionalitás korai integrációját biztosítja és egy erősen követelmény orientált

megközelítéshez vezet az egységtesztelés során. Top-down egységteszteléssel azonosítható az alsóbb szintű egységekben megvalósított redundáns funkcionalitás, mert ez nem fedhető le tesztekkel (A magasabb szintű egységek elrejtik). A top-down tesztelés hátrányai A top-down tesztelést a csonkokkal lehet irányítani, a tesztesetek több csonkot is használhatnak egyszerre. Minden egyes tesztelt egységgel a tesztelés egyre komplikáltabb lesz és így költségesebben kifejleszthető és karbantartható Ahogy a tesztelés lefele halad az egységhierarchiában, úgy egyre nehezebb azt a strukturális lefedettséget elérni mely a nagy integritású és biztonság kritikus alkalmazásoknál szükséges, illetve amit a szabványok előírnak. A strukturális lefedés nehézsége problémákat okoz a redundáns funkcionalitás és a nem tesztelt funkcionalitás elkülönítésében. Bizonyos alsó szintű funkcionalitás tesztelése gyakorlatilag teljesen

lehetetlenné válhat. Egy egységen végrehajtott módosítás gyakran befolyásolja a hierarchiában azonos vagy az alacsonyabb szinten lévő egységek tesztelését Tekintsük a példa „D” egységének módosítását Természetesen a „D” egység tesztjeit meg kell változtatni és ismételni. Ezenkívül az „E, F, G, H, I, J” egységek tesztjeit, melyek használták a „D” egységet szintén meg kell ismételni. Valószínűleg meg is kell változtatni ezeket a teszteket a „D” egység módosítása miatt, mindezt annak ellenére, hogy az „E, F, G, H, I, J” egységek maguk nem változtak. Ez magas teszt karbantartási és újratesztelési költségeket jelent változtatások esetén. A top-down tesztesetek tervezése megköveteli, hogy rendelkezzünk arra vonatkozó információval, hogy mikor hív a tesztelés alatt álló modul más modulokat. Az egységek tesztelésének sorrendjét az egységhierarchia határozza meg, az alsóbb szintű egységeknek

várniuk kell a felsőbb szintű egységek teszteltségére, hosszú egységtesztelési fázist eredményezve A példában szemléltetett egységek viszonylag egyszerű hierarchiát alkotnak, valós programokban a modulok egy részére egynél több másik modul is hivatkozik 5.44 Bottom-up tesztelés Bottom-up egységteszteléskor a modulok az őket hívó moduloktól elszigetelten kerülnek tesztelésre, de a valódi hívott modulokat használják saját hívásaikhoz. Először a legalsó szinten lévő modulokat kell tesztelni, majd ezeket kell használni a felsőbb szintű egységek tesztjeinél, vagyis már tesztelt hívott egységekkel kerül sor a tesztelésre. A folyamatot addig kell is- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 98 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 99 ► mételni, míg a hierarchia

csúcsán álló egység is tesztelve nem lesz. A bottom-up tesztelés tesztvégrehajtó egységeket kíván, de nincs szükség csonkokra. A Te szt é h jtó B C 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 tesztelés Az ábra a „D” egység teszteléséhez szükséges tesztvégrehajtó egységet és korábban tesztelt egységeket mutatja bottom-up megközelítés esetén. A tesztelés ismét egy több lépésből álló szekvencia. Külön tesztvégrehajtó egységek segítségével tesztelni kell a legalacsonyabb szintű egységeket. Ezután tesztvégrehajtó egységekkel tesztelni kell a következő szinten lévő modulokat, melyek a már korábban tesztelt alacsonyabb szintű egységeket hívják. Az eljárást a hierarchia csúcsán lévő egység teszteléséig kell végezni A bottom-up tesztelés előnyei A top-down egységteszteléshez hasonlóan a bottom-up tesztelés is

biztosítja az egységek korai, szoftverintegrációs fázis előtti integrációját. A bottom-up egységtesztelés is egy kombinált egységtesztelési és szoftverintegrációs stratégia. A teszteseteket teljes egészében a tesztvégrehajtó egységek határozzák meg, nincs szükség csonkokra Ez az egységhierarchia alján álló modulok tesztelését relatív egyszerűvé teszi. A bottom-up tesztelés tesztesetei a funkcionális tervezési információkból származtathatók, nincs szükség strukturális tervezési információkra, bár teljes lefedettség eléréséhez hasznosak lehetnek. A bottom-up tesztelés az alacsonyszintű funkcionalitás korai integrációját biztosítja, a felsőbb szintű funkcionalitás az egységhierarchián felfelé haladva szintenként adódik ehhez hozzá. Ebből kifolyólag ez a tesztelési stratégia jól használható objektumok tesztelésére A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 99 ►

Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 100 ► A bottom-up tesztelés hátrányai Ahogy a tesztelés felfelé halad az egységhierarchiában úgy válik a bottomup egységtesztelés mind bonyolultabbá és ezért egyre nehezebben kifejleszthetővé és karbantarthatóvá. Ezzel párhuzamosan egyre nehezebbé válik kielégítő strukturális lefedettséget elérni. Egy egység megváltoztatása gyakran hatással van a hierarchiában felette lévő egységekre. Tekintsük a példa „H” egységének megváltoztatását. Triviális, hogy a „H” egység tesztjeit meg kell változtatni és meg kell ismételni Ezenkívül meg kell ismételni és esetleg változtatni az „A, D, E” egységek tesztjeit is hiszen ezen tesztek használták a tesztelt „H” egységet, bár maguk az „A, D, E” egységek nem változtak. Vagyis a változtatások jelentős újra

tesztelési költséggel járnak Az egységek tesztelési sorrendjét az egységhierarchiában elfoglalt helyük korlátozza. A magasabb szinteken lévő egységek tesztelésével meg kell várni az alacsony szintű egységek tesztelésének befejezését, ami hosszú egységtesztelési fázishoz vezet. Az először tesztelésre kerülő egységek kerülnek legkésőbb tervezésre, így az egységtesztelés nem fedheti át a szoftver életciklus részletes tervezési fázisát. A top-down teszteléshez hasonlóan itt is jelentősen nehezíti a tesztelést, ha egy egységre több másik egység is hivatkozik. 5.45 Egységtesztelési stratégiák összehasonlítása Az izolációs egységtesztelés a legjobb választás egységtesztelésre. Ha egy megfelelő integrációs stratégiával egészül ki, akkor segít lerövidíteni a fejlesztési időt. Az izolációs egységtesztelést követően az egységek top-down, bottom-up sorrendben vagy bármilyen megfelelő kombinációban

integrálhatók. Ez a módszer a legkedvezőbb magas strukturális lefedettség elérésére A top-down stratégia költségesebb, mint az izolációs stratégia Ezt a tesztek nagyobb komplexitása és változtatások komoly hatása okozza. A top-down stratégia nem jó választás egységtesztelésre, hanem inkább a már tesztelt egységek integrálásának megfelelő eszköze. A bottom-up megközelítés jó egységtesztelési stratégia lehet különösen, ha objektumokat és egység újra felhasználást tekintünk. Azonban a bottom-up megközelítés inkább a funkcionális, mint a strukturális tesztelés irányába mutat Ez a megfelelő strukturális lefedettség elérésében okozhat gondot, például biztonságkritikus alkalmazások esetén. A bottom-up tesztelés nem megfelelő stratégia a legtöbb szoftverprojekt rövid időkorlátjai miatt A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 100 ► Szoftver-minőségbiztosítás

Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 101 ► 5.5 Integrációs tesztelés és rendszertesztelés A modul szintű tesztelést követően magasabb szinteken kell a tesztelést tovább folytatni. Ezek a tesztelési szintek párhuzamosak a fejlesztési „V” életciklus megfelelő szintjeivel. Így tehát a magasabb szintű tesztelés több szintet jelent. Legalacsonyabb szinten idetartoznak a modulok rendszerbeli együttműködését (integrációját) ellenőrző integrációs tesztek A következő, ún funkcióteszt szinten már tisztán black-box jellegű teszteket végzünk a külső specifikációnak való megfelelés ellenőrzésére Ebben a tesztelési fázisban szerepet kell kapnia a negatív teszteknek is A következő szint a rendszertesztek szintje. Itt nem a rendszer funkcióit teszteljük, hanem a rendszer eredeti céljainak való megfelelőségét 5.51 Integrációs tesztelés A

tisztán integrációs tesztek a szoftver életciklus integrációs fázisában kerülnek végrehajtásra, és a különböző modulok hierarchikus függéseinek, interakcióinak ellenőrzésére szolgálnak. Ebben a tesztelési fázisban általában nehéz az egyes modulok programkódjának teljes lefedése,és nem is ez a cél, a hangsúly a modulok kapcsolódási pontjainak tesztelésén van: interfészek, inter-modul üzenetkezelők. A kooperáló modulokból felépített rendszerek állapotát az egyes modulok közötti interakciók is meghatározzák. Elképzelhető, hogy egy rendszer annak ellenére hibásan működik, hogy az összes alkotó komponense egyenként korrekt. Az egész rendszer szekvenciális működését moduljainak a kapcsolata is befolyásolja. Ezek a tesztek továbbra is tartalmaznak white-box jellegű struktúrális teszteket. (A white-box integrációs tesztek külön hangsúlyt kaptak az objektum orientált fejlesztési módszerek megjelenésével.)

Alkalmazás Modulok Potenciális hibák Teszt input 5.12 ábra Az integrációs tesztelés a modulok interakcióit ellenőrzi A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 101 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 102 ► Az integrációs tesztekkel kapcsolatban a következő stratégiai kérdést lehet feltenni: az összes, már korábban egyenként tesztelt modult egyszerre kombinálva az alkalmazássá hajtsuk végre az integrációs tesztelést, vagy kövessünk egy olyan stratégiát, mely a modulokat egyenként kombinálja a már egységben tesztelt modulokkal az újabb tesztelendő rendszerré? Az első megközelítésmódot hívják „big-bang” integrációnak, míg a második az inkrementális integráció. Az inkrementális integráció stratégiái megegyeznek az inkrementális egységtesztelés

stratégiáival, hiszen az inkrementális egységtesztelés integrációs elemeket hordoz magában, vagyis hibrid stratégiának tekinthető. Ebből kifolyólag tehát itt is top-down és bottom-up integrációról beszélhetünk. A két technika közül az integrációs tesztelési célokat inkább a bottom-up stratégia szolgálja. Az életciklus integrációs fázisában ugyanis már rendelkezésre állnak a legalacsonyabb szintű modulok. 5.52 Rendszertesztelés Ez utóbbi tesztelési fázis a megfogalmazott céloknak a követelmények meghatározásakor specifikációvá történő alakításánál elkövetett hibák feltárását szolgálja. Mivel a termék szempontjából ez az egyik legkritikusabb szakasz a fejlesztés során, a rendszertesztelés egy létfontosságú szakasza a tesztelésnek. A rendszertesztelés nehézségét az jelenti, hogy a célokat meghatározó dokumentumok nem elég részletesek ahhoz, hogy konkrét tesztesetek származtathatók legyenek belőlük,

míg a külső specifikáció használata túlmutat a rendszertesztelés céljain. A rendszerteszteléshez használt teszteseteket a rendszer céljainak elemzéséből és felhasználói dokumentációjából kiindulva kell elkészíteni. A problémát az okozza, hogy a rendszer céljai nem határozzák meg a célok eléréséhez szükséges funkciókat, melyeknek a reprezentálódása viszont szükséges volna a tesztesetek tervezésénél. A rendszerteszteket lehetőleg a fejlesztőktől független és a végfelhasználók helyzetét ismerő szervezetnek kell végeznie Annak ellenére, hogy nem létezik általánosan elfogadott módszertan a rendszertesztek létrehozására és elvégzésére, a rendszertesztek az alábbi pontokban ismertetett kategóriákba sorolhatók Szolgáltatástesztelés Az egyik legalapvetőbb dolog, amit tesztelni kell egy rendszeren, hogy valóban nyújtja-e azokat a szolgáltatásokat melyeket céljai között megjelöltek. Ez abban különbözik a

funkcióteszteléstől, hogy nem a szoftverspecifikációra épül A teszt során meg kell határozni, hogy a célok leírásában A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 102 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 103 ► megadott tevékenységeket az ott leírtak szerint el lehet-e elvégezni a szoftverrel. Ez a fajta tesztelés az esetek egy részében elvégezhető a felhasználói dokumentáció alapján Mennyiségi tesztelés Ez a típusú tesztelés azt jelenti, hogy a szoftver működését nagy mennyiségű adattal teszteljük a kapacitáskorlátok ellenőrzésére. A mennyiségi tesztelés viszonylag erőforrás igényes, olyan értelemben, hogy a nagy mennyiségű megfelelő adat előállítása, majd a tesztelés maga is időigényes lehet, és az adatok is komoly tárolókapacitást igényelhetnek.

Löket-terheléses tesztelés (Stressz-tesztelés) A löket-terheléses tesztelés a tesztelt rendszert valamilyen szempontból erős terhelésnek, stressznek teszi ki. Ez a fajta tesztelés nem keverendő össze a mennyiségi teszteléssel: a stressz-tesztelésnek fontos tényezője az idő, itt tehát nagy mennyiségű adat rövid idő alatti feldolgozásáról van szó. A stressz-tesztelés általában fontos eleme folyamatirányító, valósidejű vagy biztonság kritikus rendszerek tesztelésének. A tesztelés során tehát olyan intenzív feldolgozást kívánó helyzeteket teremtenek, melyek szélsőségesek ugyan, de nem elképzelhetetlenek a rendszer működése során. A rendszer, valós helyzetekben megnyilvánuló, robosztusságának ellenőrzésére végeznek olyan stressz-teszteket is, melyek a valóságban soha elő nem forduló feltételeket jelentenek. Használhatósági tesztelés A szoftver minőség egyik modern megközelítése a „használat közbeni

minőség” fogalma. A használat közbeni minőség azt jelenti, hogy egy termék egy meghatározott felhasználó által, egy meghatározott felhasználási körben használva, meghatározott célok hatékony és produktív elérésére, mennyire kielégítő és mennyire vezet megelégedésre. Vagyis a használhatósági minőséget hatékonysági teljesítménymutatókkal és a megelégedettséggel lehet mérni A használhatósági tesztelés célja tehát az emberkomputer interakció minőségének ellenőrzése, azaz, hogy mennyire egyszerű megtanulni a szoftver használatát, mennyire kielégítő használni Ezek a kérdések általában a szoftver felhasználó felületének tervezésével függenek össze. A tesztelés során a felhasználó teljesítményére vonatkozó kvantitatív (idők, pontosság, elvégzett feladatok száma) és a megelégedettségre, véleményre vonatkozó kvalitatív (kérdőívek, megjegyzések) adatokat A dokumentum használata |

Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 103 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 104 ► gyűjtenek. Ezen adatok alapján azonosíthatók a használhatóságot befolyásoló hibák Biztonsági tesztelés A biztonsági tesztelés célja, hogy felfedje az adatbiztonsággal és adatvédelemmel kapcsolatos hibákat. Az adatvédelem az adatok elérését és a jogosultságokat szabályozza, míg az adatbiztonság az adatok helyességét, integritását jelenti Tesztesetek létrehozásához előnyős lehet a hasonló rendszerek már felderített biztonsági hiányosságainak ismerete Teljesítménytesztelés A programok egy részénél a teljesítmény vagy a hatékonyság specifikálva van különböző terheléseknél és konfigurációkra meghatározott válaszidők és feldolgozási sebességek formájában. A tesztesetek célja annak a

demonstrálása, hogy a rendszer nem képes a megadott teljesítménycélok kielégítésére. A teljesítmény tesztelés általában megköveteli hogy ismerjük az adott program dinamikus viselkedését és olyan tesztkörnyezetek használatát melyek képesek tetszőleges események időmérésére, az időt is tartalmazó naplózására. Konfigurációtesztelés Bizonyos programoknak eltérő operációs környezetekben is működniük kell. Ezek a különböző környezetek jelenthetnek eltérő hardver konfigurációkat (adott esetben teljesen különböző architektúrákat), különböző operációs rendszereket ill különböző szoftver installációkat A konfigurációtesztelés sok esetben különböző konfigurációkban elvégzendő teljesítménytesztelést jelent A céloknak megfelelően, lehetőleg minél nagyobb számú konfigurációra kell elvégezni a teszteket. Bizonyos esetekben elég a teszteket elvégezni a minimum és maximum konfigurációkra. Sokszor a

programoknak korábbi rendszerekhez kell kapcsolódniuk, vagy a program egy korábbi változatát váltják le. Ezekben az esetekben tesztekkel ellenőrizni kell a kompatibilitási célok elérését vagy a konverziós eljárásokat A konfigurációs tesztelést segítheti, ha a tesztelő környezet képes a már elkészített tesztesetek automatizált végrehajtására a különböző konfigurációkban. Erre legalkalmasabbak az adat vezérelt tesztkörnyezetek Megbízhatósági tesztelés Természetesen mindenféle tesztelésnek az a célja, hogy növelje a szoftver megbízhatóságát, de ha program céljai között megbízhatósággal kapcsola- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 104 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 105 ► tos speciális kitételek szerepelnek, akkor külön megbízhatósági teszteket

is kell végezni. Általában igen nehéz a teszteléshez rendelkezésre álló idő alatt a rendkívül alacsony meghibásodási ráta követelményeknek megfelelő rendszerek tesztelése. Bizonyos megbízhatósági paraméterek érvényességére matematikai modellek alapján adhatunk becsléseket A megbízhatósági teszteknek adott esetben ki kell terjedniük a rendszer programozási, hardver- vagy adathibák bekövetkezte utáni felállására, működésbe visszaállására. A teszteknek érinteni kell ezen visszaállító eljárásokat (Gondoljunk a modern programozási nyelvek kivételkezelő mechanizmusaira) Ezeknek a teszteknek a végrehajtását segítik az olyan tesztkörnyezetek melyek képesek hibainjektálásra, hibás működés kiváltására (hardver hibák szimulálása). Dokumentáció-tesztelés A felhasználói dokumentáció minősége elsősorban a használhatóságot befolyásolja. Másrészt, mint láttuk a rendszertesztelést meghatározza a felhasználói

dokumentáció pontossága. Ezen okokból kifolyólag tehát szükséges e dokumentáció ellenőrzése pontosság és világos érthetőség szempontjából. A dokumentációban szereplő összes illusztratív példát le kell képezni tesztesetekké és végre is kell hajtani velük a tesztelést. 5.6 Validációs tesztelés A validációs folyamatokban egyrészt a rendszer funkcionális téren elvárt működésének ellenőrzésére van szükség, másrészt pedig az ezen túlmenő, további felhasználói elvárások teljesülését is igazolni kell. Az utóbbi kritérium elsősorban a biztonságkritikus rendszerek esetében válik fontossá Itt szükség van arra, hogy a rendszer olyan tulajdonságait, működési módjait is megvizsgáljuk, amelyeket a tervezési specifikáció nem definiált. Az 5.3 alpontban már foglalkoztunk a validációs tesztek megtervezésére vonatkozó külön előírásokkal, amelyek kitérnek a vizsgálatok különböző területeire Az egyes

tesztelési folyamatokat ezen előírások szerint kell lebonyolítani. A biztonságos működés teljesülésének igazolása megköveteli, hogy minél több olyan tesztet hajtsunk végre, amely a valóságos környezet eseményeit foglalja magában. Az előírt funkciók teljesítésének ellenőrzése után olyan bemeneti feltételeknek célszerű kitenni a rendszert, amelyek kritikus helyzeteket teremtenek elő. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 105 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 106 ► Az eddig bekövetkezett katasztrófák vizsgálata mindig azt az eredményt hozta, hogy több együttesen fellépő váratlan esemény kombinációja idézte elő a nem kívánt esetet. Mivel a tervezés során nem várható el, hogy minden lehetséges eseményre fel lehessen készülni, minden előfordulható

helyzetet végig lehessen követni, ezért ennek a pótlására egyedül a tesztelés ad módot. A tesztelésben megvan a lehetősége annak, hogy a tervezéstől független személy vagy csoport teremtsen olyan helyzeteket a vizsgált rendszer számára, amelyben kiderülhet, hogy az nem lett felkészítve az ilyenek megfelelő feldolgozására, kezelésére. Célszerű tehát arra törekedni, hogy minél több eseménykombináció kerüljön vizsgálatra, amelyek lehetnek szokatlanok, ill. kis valószínűséggel előfordulók Az ilyen irányultságú tesztek előállítására érdemes igénybe venni a véletlenszerű adatgenerálás módszerét is. Ugyanis a random bemeneti adatok között előfordulhatnak olyanok is, amelyek extrém üzemeltetési feltételeket írnak elő. 5.61 Időzítési szempontok Az ipari, gyártási, vagy közlekedési, repülési folyamatokat irányító biztonságkritikus rendszerek valós időben kell hogy üzemeljenek. A valós idejű rendszerekre

nézve olyan időkorlátok érvényesülnek, amelyeken belül kell a rendszernek a külső eseményekre reagálni, és a megfelelő választ adni. Az egyes időkorlátok függenek az adott külső események kategóriájától, vagyis a különböző eseményekhez különböző reagálási időkorlátok vannak rendelve. A valós idejű megkötések kielégítése sok esetben igen komoly követelményt jelent mind a hardver, mind pedig a szoftver oldaláról. Ugyancsak nehéz feladat annak az igazolása is, hogy a megkötések feltételeit teljesíti az adott berendezés Az igazolási feladat megoldása két részből áll: • A rendszerkövetelményekből meg kell határozni az időzítési korlátozásokat. • Meg kell mutatni, hogy ezek a korlátozások ki vannak elégítve. Az első feladat jóval nehezebb, mint amilyennek látszik, mivel sok időkorlát valaminek a következménye, ahelyett, hogy kifejezetten deklarálva lenne. Amikor a specifikáció természetes nyelven van

leírva, akkor különösen nehéz a leírásból azonosítani és számszerűsíteni az összes időzítési következményt. Miután az időkorlátok azonosítva lettek, szükségessé válik annak verifikálása, hogy azok mindegyike ki van elégítve. A hardver ilyen irányú A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 106 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 107 ► vizsgálata eléggé kidolgozottan hajtható végre, dinamikus teszteléssel, vagy szimulációs ellenőrzéssel. A dinamikus teszteléshez, programozható időbeállítási lehetőségekkel rendelkező nagysebességű mérőberendezések állnak rendelkezésre. A jelentkező problémák az olyan aszinkron tevékenységekkel vannak kapcsolatban, mint amilyen a külső rendszerekkel való kommunikáció, vagy pedig a kívülről jövő mérési adatok

érzékelése. A szoftver időbeli sajátságainak vizsgálata már általában sokkal bonyolultabb, a viselkedés összetettsége következtében. A rendszer dinamikus tesztelése a valódi futási körülmények között végezhető, de a lehetséges esetek teljes végigpróbálása már többnyire komoly nehézségekbe ütközik. Emiatt nem bizonyítható, hogy az időkorlátok betartása minden esetben, minden működési helyzetben teljesül. 5.62 Környezeti szimuláció A biztonságkritikus rendszerek esetében gyakran nincs arra lehetőség, hogy a rendszert teljes egészében a valós működési körülmények között vessük vizsgálat alá. Például, ha egy nukleáris erőmű biztonsági leállító rendszerét teszteljük, akkor nem tehetjük meg azt, hogy a leállítás menetének ellenőrzésekor a reaktort egy esetlegesen veszélyes állapotba juttatjuk. Ugyanígy nem tehető meg az sem, hogy egy vasúti irányítórendszert a valós pályaudvari forgalom

fenntartása alatt tesztelünk. Az ilyen szituációkban az elterjedten alkalmazott megoldás a rendszer valós környezetének a szimulációja. A szimulációs környezet megteremtése történhet hardver, ill szoftver révén, és a kettő kombinációjával is. Ez a megoldás nemcsak a biztonságot garantálja a vizsgálati folyamatok idejére, hanem jóval hatékonyabb, szabadabb, gyorsabb, átfogóbb és teljesebb tesztelést tesz lehetővé a működésre vonatkozóan. A vizsgálatokba természetesen nemcsak a statikus működés, hanem a dinamikus is bekapcsolható, az időkorlátok ellenőrzésével A biztonságorientált rendszerek tesztelésekor használt szimulátorokkal szemben is szigorú minőségi követelményeket kell támasztani ahhoz, hogy megbízható legyen a velük végzett tesztelési folyamat. A szimulátorok minőségének meghatározását több tényező befolyásolja, melyek közül az alábbiakban sorolunk fel néhányat: • A szimulált változók: Mely

környezeti változók vannak figyelembe véve, és melyek vannak elhanyagolva. • Az alkalmazott modellek pontossága: Azoknak a modelleknek a pontossága, amelyek a különböző környezeti hatásokat reprezentálják. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 107 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 108 ► • A számítások pontossága: Az egyes változók kiszámításánál alkalmazott felbontási fok és pontosság. • Az időzítések figyelembevétele: A számítási sebesség hatása a szimulációra. A szakirodalom tanúsága szerint jelenleg még nincsen általánosan elfogadott módszer a szimulátorok minőségének meghatározására, eldöntésére. Ennek az a fő oka, hogy a különböző tényezők, paraméterek az alkalmazásoktól függően erősen eltérnek egymástól. A gyakorlatban a

szimulátorok értékelése elsősorban a felhasználási tapasztalatokon alapszik A biztonságkritikus projektekben a szimulátorok felhasználásán alapuló tesztelési eredmények nagyon fontos szerepet játszanak a validációs folyamatokban. A megbízható felhasználáshoz arra van szükség, hogy a szimulátorok fejlesztése is szigorú elvek szerint történjék. Ugyancsak ajánlatos a fejlesztést attól a rendszertől függetlenül végezni, aminek a teszteléséhez a szimulátor fel lesz felhasználva, annak érdekében, hogy csökkentsék a közös tervezési hibák kockázatát A validálás elvégzésére vonatkozóan az IEC 1508 szabvány tervezete olyan előírásokat tartalmaz, amelyek szerint a magas biztonsági követelményekkel fejlesztett rendszerek validálását feltétlenül független szervezeteknek kell elvégezni. Olyan szervezeteknek tehát, amelyeknek semmilyen kapcsolata nincsen a fejlesztő intézménnyel. 5.7 A tesztelés költsége A

tesztelési-diagnosztizálási folyamatok végrehajtása meglehetősen időigényes és költségigényes feladat. Ez még akkor is így van, amikor jól megtervezett tesztkészlet áll rendelkezésre A hibás működés feltárása, a hiba detektálása után szükség van ugyanis a hiba okának, helyének pontos meghatározására, a diagnosztizálásra. Ez a tevékenység az, ami a költségeket jelentősen növeli A hibahely meghatározása akkor is szükséges, amikor egy szoftver üzemeltetése során, vagy forgalomba hozatala után derül ki a hibás működés, a fejlesztés tesztelési folyamatán kívül esve. Magától értetődik, hogy minden modulokból felépülő rendszernél növekedni fog a hibakeresés és hibajavítás költsége, ha arra az építési folyamat egy későbbi szakaszában kerül sor, ahhoz képest, hogy egy korábbi szakaszban történt volna meg ez. Hardver esetében az összegyűlt több évtizedes tapasztalat azt mutatja, hogy az építkezési

lépcsők emelkedésével ez a költség minden újabb lépcsőnél 10-szeresére növekszik. A megfigye- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 108 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 109 ► lések alapján, szoftver téren sem várhatunk el kedvezőbb adatokat. Sőt, mivel a hardvertechnológia folyamatai jóval kialakultabb, megszabottabb rendben hajtódnak végre, a szoftvernél ennél nagyobb arányú költségugrásokra számíthatunk. Az exponenciális növekedési trend érvényesülését az 5.13 ábrán szemléltetjük Mindezek alapján kijelenthetjük, hogy nagy jelentősége és komoly költségcsökkentési kihatása van annak, hogy egy adott szoftverhibát a fejlesztési folyamat minél korábbi szakaszában szűrjünk ki. Egy későbbi szakaszban ugyanaz a hiba már jóval nagyobb ráfordítással

távolítható el (Költség) Követelmények Kódolva Kibocsátva (Idő) 5.13 ábra A tesztelési költségek változása A hibák felfedésének és javításának költségeit sok tényező határozza meg. Ilyenek például: a fejlesztők, tesztelők bére a ráfordítási időtől függően, a gépidő költsége, az infrastrukturális költség, továbbá piacra vitt szoftvernél a felhasználóknál tett cserék költsége. Az utóbbi esetben, ha például egy kompájler vagy egy operációs rendszer javított változatának cseréjére van szükség, az eladott tételszámtól függően a költség óriásira nőhet. Egy publikált adat, amely egy amerikai szoftverfejlesztő cégtől származik (C. Kaner, J Falk, H Q Nguyen, USA, 1993): • Fejlesztési költség: 75 $ / utasítás • Karbantartás: 4.000 $ / utasítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 109 ► Szoftver-minőségbiztosítás Tesztelési stratégiák

és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 110 ► Látható, hogy a két stádiumban fellépő költségek két nagyságrendnyit térnek el egymástól. Számos szoftverfejlesztő cégtől gyűjtött adatok átlagolása alapján az 5.1 táblázatban szereplő iránymutató költségmegoszlást valószínűsítette A. Jarvis és V Crandall (USA, 1997): 5.1 táblázat Egy hiba kijavításának költsége a szoftver fejlesztési életciklusában Specifkáció/ Tervezés 10–100$ Programozás Tesztelés 100–300$ 500–1.500$ Installálás/ Karbantartás 10.000$– milliók $-ban A fejlesztést végző intézményeknek érdemes állandó költségfigyelést végezni a hibajavítás területén. Ehhez fel kell jegyezniük az összes olyan ráfordítást, amely a hibakeresésre és javításra vonatkozott. Előfordulhat olyan eset is, amikor egy-egy hiba miatt nagyobb áttervezést, átalakítást kell végrehajtani a

szoftveren. Ez is jelentős költségnövekedéssel járhat A biztonság-orientált rendszereknél a későn észlelt hibák nemcsak a javítási költségben jelentkezhetnek, hanem a rendszer téves működése által okozott károkban is, ami ugyancsak költségnövelő tényező. Az ilyen rendszereknék fokozott jelentősége van a korai hibaelhárításnak A tesztelési ráfordítások a fejlesztés tekintélyes részét teszik ki. Az erre irányuló költségek csökkentése ezért nagyon fontos. A mérésre a következő kifejezés által definiált számot (tesztköltségi tényező, test cost factor – TCF) szokás használni: Tesztköltségi tényező = Tesztelés költsége Tesztelés költsége + Tervezés költsége A tesztköltségi tényező értéke a létrehozott alkalmazás természetétől, sajátságaitól függ. Erősen valószínűsíthető, hogy értéke mind a komplexitás, mind pedig a biztonsági szint növekedésével együtt növekszik. A hasonló

jellemzőkkel bíró rendszerek tényezői közötti különbség azt tükrözi, hogy a fejlesztő teamek milyen képességgel és sikerrel kísérelték meg csökkenteni az ellenőrzési ráfordításokat. Azt mutatja, hogy mennyire sikerült nekik jól tesztelhető rendszert létrehozni A gyakorlati tapasztalatok szerint a A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 110 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 111 ► tesztköltségi tényező tipikusan a 0,25–0,75 közötti sávban mozog. (Irodalmi adat: N Storey, Nagy-Britannia, 1996) 5.8 Bizonylatolás Bizonylatolás (certification): Annak igazolása, hogy a termék minden tekintetben megfelel a hatósági előírásoknak, szabványoknak, követelményeknek. A bizonylatolást minden országban egy erre a célra létrehozott hatóság írja elő. Ilyen előírás

vonatkozhat például a repülőgépekre, amelyek csak akkor kerülhetnek forgalomba, vagyis szállhatnak fel, ha erre megvan a megfelelő bizonylat. A forgalomba helyezéshez szükséges bizonylatok minden légi járműre elő vannak írva. A biztonságkritikus rendszerekre nézve is hasonló jellegű előírások vonatkoznak, melyek országonként változnak. Az esetek többségében állami hatóságokra tartozik a bizonylatok előírási rendjének kidolgozása és betartatása. A biztonságkritikus rendszerek esetében a biztonságról kell meggyőzni a megfelelő szabályozó szervet. Ez általában igen nehéz feladat A fejlesztőnek meg kell mutatnia, hogy minden fontosabb hazárd azonosítva lett, és gondoskodás történt az elkerülésükről, továbbá hogy a rendszer kellő védelmet kapott az illetéktelen hozzáférés és helytelen kezelés ellen. A bizonylat kiadáshoz ugyancsak szükség lehet annak igazolására is, hogy az adott rendszer miden pontban megfelel-e az

összes ide vonatkozó szabvány előírásainak. A fejlesztő és kivitelező cégnek részletesen dokumentálnia kell a fejlesztésnél használt módszereket, továbbá a tesztelésnél használt megoldásokat is. Mindezeken túl szigorúan alá kell támasztani azt az állítást, hogy a rendszer kellőképpen biztonságos, és az is marad a teljes életciklusa alatt. A bizonylat kiadásáig terjedő munka meglehetősen nagy volumenű, és ehhez még igen gondos, alapos tervezést követel meg. A biztonságkritikus rendszerek gyártói mindenképpen rá vannak utalva arra, hogy az általuk fejlesztett berendezések megkapják az üzembe helyezéshez szükséges bizonylatot. Az erre vonatkozó követelmények változnak az alkalmazástól és az országtól függően Például az orvosi elektronika területén Nagy-Britanniában a bizonylatolás önkéntes, az Egyesült Államokban és Németországban viszont szigorúan kötelező. A polgári repülésben és a nukleáris

erőműveknél a bizonylatolás mindig kötelező Az esetek többségében a teljes rendszerre vonatkozik az engedélyezési előírás, máskor pedig csak a kritikus komponensekre. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 111 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 112 ► A szoftvert tartalmazó termékek különleges figyelmet érdemelnek, amellett külön problémákkal járnak mind a fejlesztő, mind pedig a bizonylatolási szabályzatot kidolgozó hatóságok számára. Az ilyen rendszerek megbízható tesztelése nem csak magának a rendszernek az ellenőrzését követeli meg, hanem a fejlesztési folyamatok egészének az ellenőrzését is. Utóbbi egyrészt a felhasznált módszerek, fejlesztési technológiák vizsgálatát jelenti, másrészt pedig a fejlesztést végző személyzet hozzáértésének

vizsgálatát is. Az üzemeltetéshez előírt bizonylat kiadásához szükség van annak igazolására is, hogy az adott rendszer biztonságos. Az ehhez végrehajtandó folyamatot nevezzük biztonságigazolásnak. A bizonylatozás részeként kezelendő biztonságigazolás ugyancsak előírások szerint kell hogy végbemenjen Példaként megadunk egy listát, amely azt sorolja fel, hogy milyen dokumentumok elkészítésére van szükség a biztonságigazoláshoz A listára vonatkozó javaslatot az Angliában szervezett, állami támogatású projekt (CONTESS projekt, 1995) keretében dolgozták ki: • A biztonságkritikus rendszer leírása. • A biztonsági tervezésben részt vevő személyzet kompetenciájának igazolása. • A biztonsági követelmények specifikációja. • A hazárdok és kockázatok analízisének eredményei. • A kockázatok csökkentésére alkalmazott módszerek részletezése. • A tervezési elemzések eredménye, amely azt mutatja meg, hogy a

rendszer tervezése minden szempontból elősegíti a biztonsági célok elérését. • A verifikációs és validációs stratégia. • Az összes verifikációs és validációs tevékenység eredményei. • A biztonsági vizsgálatok eredményei. • Azon események feljegyzése, amelyek a rendszer üzemeltetése során léptek fel. • A rendszeren végrehajtott változtatások feljegyzése, és annak bizonyítása, hogy a rendszer továbbra is megőrizte biztonságosságát. A bizonylatolás tehát végső soron magában kell hogy foglalja a rendszer verifikálásának, validálásának jóváhagyását, valamint az ezeken túl még meglevő hatósági előírások, szabványok betartásának ellenőrzését is. Kiterjedhet a rendszer biztonságos üzemeltetésének ellenőrzésére is A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 112 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata

| Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 113 ► Összefoglalva a következőket állapíthatjuk meg: A bizonylatolás három követelményrendszer kielégítésének elismerését, elfogadását szolgálja: • A specifikációs követelményeknek való megfelelést (verifikáció). • A felhasználói követelményeknek való megfelelést (validáció). • A hatósági előírásoknak való megfelelést. 5.9 A formális módszerek szerepe A formális módszerek matematikai alapokon álló eljárások, amelyeket az informatikai rendszerek • specifikálására, • tervezésére, valamint • analízisére használnak fel. A felsorolt felhasználási módok egyaránt vonatkoznak a hardverre és a szoftverre. Az ide tartozó formális megközelítés a diszkrét matematika, a számítógépes nyelvek és fordítóprogramok, a matematikai nyelvészet, valamint a matematikai logika felhasználásán, ill. továbbfejlesztésén alapszik Jelentősége a matematikai

precizitás és szigorúság átfogó kihasználásában rejlik, ami pontos, ellentmondásmentes és egyértelmű megoldásokat segít elő. Ebben a felfogásban az eddig leírt megoldások valójában informális specifikációs és tervezési módszereken alapultak. A specifikáció általában valamilyen verbális, leírásos alapon van elkészítve. Ez a leírás lehet pontatlan, nem egyértelmű, nem teljes, esetleg ellentmondásokat is tartalmazhat A formális megközelítés precíz matematikai technikáinak alkalmazása éppen arra irányul, hogy ezeket a hiányosságokat ki lehessen küszöbölni. (Ismeretes, hogy a formalitást teljesen nélkülöző jogalkotás állandó velejárója a törvények közötti ellentmondások megléte, valamint hiányos törvények megszületése, amelyek tele vannak „joghézaggal”. A műszaki világban ugyanígy keletkezhetnek „specifikációs hézagok” is, amelyek például súlyos következményekkel járhatnak a biztonságra

nézve.) Az alapvető feladat tehát az egyértelmű, pontos és ellentmondásmentes specifikáció megteremtése. Ebben az irányban már régóta komoly törekvések történtek. Ilyenek például a szoftverfejlesztésben az ún. CASE-eszközök (CASE: ComputerAided Software Engineering, számítógéppel segített szoftvertechnológia), vagy a grafikus specifikációs eszközök a rendszerek leírására. Ezek ún A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 113 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 114 ► formalizált módszerek, amelyek szisztematikusak, és nagymértékben elősegítik a pontos tervezést, azonban még nem garantálják a kívánt cél elérését. Ugyanis teljes mértékben a tervezőtől függ az alkalmazásuk mikéntje, még akkor is, ha komoly segítséget jelentenek számára. Arról van szó,

hogy a tervezőnek ezek a munkáját könnyítik meg, teszik gyorsabbá, egy sereg manuális, ill. munkaigényes feladatot levéve a válláról, de a tervezés helyessége egyedül a tervezőn múlik A hibázási lehetőségeket lényegesen csökkentik, de meg nem szüntetik. A formális módszerek ettől különböznek. Olyan formális nyelveken alapulnak, amelyek igen precíz szabályokat hordoznak magukban. A tervezőnek ezeket a szabályokat kötelező betartani, mert a nyelv fordítóprogramja kijelzi a szabályok megszegését Ez egyértelmű specifikációt eredményez, másrészt pedig a szabályok betartása lehetővé teszi azt is, hogy egy külön szoftver automatikusan tudja ellenőrizni és kimutatni a tervezési hibákat, ellentmondásokat is. Az ilyen nyelvek elnevezése: • rendszerspecifikációs nyelv, vagy • formális specifikációs nyelv. A formális leírás legnagyobb előnye az, hogy lehetővé teszi a tervezési folyamat helyességének számítógéppel

segített ellenőrzését. A specifikáció és a végtermék közötti fejlesztési út több fázisból áll. Az egyes fázisok közötti átmenetet több esetben automatikus transzformáció tudja biztosítani. Ez azt jelenti, hogy egy tervezési fázis eredménye szolgál bemenő információként a soron következő fázist megvalósító tervezőprogram számára, amely program átalakítja a bemeneti reprezentációt az új fázis kimeneti reprezentációjára. A folyamat nem minden esetben automatizált még. Ekkor külső tervezői közreműködésre kerül sor Az átalakítás, transzformáció során szükség van annak bizonyítására is, hogy az új reprezentáció ekvivalens az őt megelőzővel. Különböző szoftver eszközök állnak rendelkezésre a bizonyítás elvégzéséhez, vagyis a verifikációhoz, de ezek jelenleg még nem teszik lehetővé a teljesen automatikus végrehajtást, vagyis itt is szükség van a tervező közreműködésére. Végül is a

formális módszerek használata nem jár a tapasztalt tervezők munkájának megtakarításával, viszont megváltoztatja a mérnöki tevékenység, döntéshozatal módját, formáját. A formális megközelítés alkalmazásának legfőbb értelme abban van, hogy nagyobb megbízhatósággal teszi lehetővé a tervezési és verifikációs folyamatok végrehajtását. Mindezt az 514 ábrán szemléltet- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 114 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 115 ► jük. Az ábrán lefelé haladva a V-modell tervezési ága valósul meg, felfelé haladva pedig az ellenőrzési, tesztelési ága. Formális specifikáció Transzformáció és ellenőrzés Verifikáció 1. tervezési fázis Transzformáció és ellenőrzés Verifikáció 2. tervezési fázis • • • • • • •

• • Transzformáció és ellenőrzés Verifikáció Végső tervezési fázis 5.14 ábra A formális módszerek alkalmazásának folyamata A formális módszerek egyaránt vonatkoznak a hardver-tervezésre és a szoftver-tervezésre. A két szféra egymással párhuzamosan haladó fejlesztési folyamatát az 515 ábra mutatja be A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 115 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 116 ► Felhasználói követelmények Specifikálás Hardverspecifikálás Szoftverspecifikálás Hardvertervezés Szoftvertervezés Hardvermegvalósítás Szoftvermegvalósítás Összeintegrált rendszer 5.15 ábra A hardver és szoftver tervezési és előállítási folyamata Ha a szoftver folyamatát tekintjük, láthatjuk, hogy az a specifikációs fázissal veszi kezdetét. Ez

transzlálandó át a szoftvertervbe, majd a terv a szoftver-implementációba. Mivel a specifikáció pontosan definiálja, hogy mit kell teljesítenie a programnak, ezért kivihetőnek látszik egy olyan fajta fordítóprogram előállítása, amely a specifikációt közvetlenül forráskódba alakítja át. Ehhez tehát egy olyan kompájlerra van szükség, amely a terve- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 116 ► Szoftver-minőségbiztosítás Tesztelési stratégiák és folyamatok A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 117 ► zési specifikációt fogadja inputként. A forráskód alapján (például C nyelven) már egy normál fordítóprogram fogja generálni a megvalósított programot Ugyanez az út a hardver esetében is felvázolható. Ekkor egy „hardver kompájler” veszi inputként a hardver-specifikációt, ebből előállítja a szükséges logikai terveket, a

logikai kapcsolási rajz formájában, ezt követően a fizikai terveket, mint például a nyomtatott huzalozású kártyák tervét, valamint a logikai elemeket realizáló integrált áramkörök (IC-k) layout-jának tervét. Ismét megjegyezzük, hogy jelenleg még messze vagyunk a fenti folyamatok teljesen automatizált megvalósításától, jóllehet folyamatos fejlesztési erőfeszítések történnek ezen cél elérésére. Az itt összegyűlt és jól bevált eszközök mindenesetre kitűnő segítséget tudnak nyújtani a jól felkészült tervezőmérnökök és szoftverfejlesztők számára. A hardverben például nagy jelentőségre tett szert az USA Védelmi Minisztériuma által szabványosított VHDL nevű hardver-leíró és szimulációs nyelv (Hardware Description Language). A VHDL egy magas szintű nyelv, amely kitűnően alkalmas a hardver logikai és időbeli működési módjainak definiálására. Több jól bevált „silicon compiler” (szilícium kompájler)

létezik már, amely az integrált áramkörök tervét generálja a hardver-tervből. A szoftverben egyre inkább terjedőben van például az UML (Unified Modeling Language, egységes modellező nyelv) felhasználása. Az UML az objektumorientált szoftvertervezést támogatja, grafikus megjelenítéssel párosulva Az UML-t magában foglaló Rational Rose elnevezésű keretrendszer már több nyelvre, mint például C ++, JAVA, képes forráskódot generálni. Jóllehet a formális módszerek alkalmazása számos fontos előnnyel jár, a felhasználás ugyanakkor jelentős mértékű megszorításokat is jelent a tervezési módszerekre nézve. Tudvalevő, hogy egy lánc erősségét a leggyengébb szeme határozza meg, ezért a formális bizonyításokat a fejlesztési folyamat mindegyik állomásánál el kell végezni annak érdekében, hogy a maximális hasznunk származzon ebből. Mindez komoly kihatással van a projekten belül alkalmazható tervezési módszerekre is. A

formális bizonyítások végrehajtása ugyanakkor erősen támaszkodik a matematikai technikákra, amitől sok mérnök idegenkedik Ennek a gondnak a csökkentése továbbképző tanfolyamok megtartását követeli meg. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 117 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 118 ► 6. Objektum-orientált szoftvertesztelés Alapvető kérdés objektum-orientált (OO) rendszerek tesztelésével kapcsolatban, hogy lehet-e alkalmazni OO rendszerek vizsgálatakor a nem OO rendszerek tesztelésére használt módszereket. Természetes válasz lehet a kérdésre, hogy miért ne lehetne, hiszen az OO programozási paradigma is a procedurális nyelvek továbbfejlesztéseként született meg. A C++ nyelv például a C nyelv kiterjesztése, ugyan ma már nem feltétlenül generálható minden C++

kóddal ekvivalens C kód, mint a nyelv kialakulásakor, azonban a nyelv megtartotta az alapvető utasítás készletét, csak jelentősen kiterjesztette azt. A problémát egy kicsit közelebbről megvizsgálva azonban sokkal bonyolultabb a kép. Egyazon szoftver problémának OO, ill nem OO környezetben történt megoldása egymástól lényegesen különbözhet struktúrájában és egyéb – tesztelhetőség szempontjából fontos – jellemzőjében Ezek a különbségek egyrészt az OO tervezési metodikából, másrészt a használt OO nyelv (környezet) sajátosságaiból következhetnek. A következő fejezetben először röviden összefoglaljuk, az OO rendszerek tesztelési szempontból fontos jellemzőit. Bemutatjuk, hogy a nem OO rendszerek teszteléshez használt módszerek OO rendszerek tesztelésére történő alkalmazásakor milyen problémákkal kell szembenézni. Ezután ismertetjük azokat a technikákat, amelyek segítségével megoldhatjuk az ismertetett

problémákat. 6.1 Az OO rendszerek jellemzői tesztelhetőségi szempontból Az OO típusú tervezésnek, problémamegoldásnak két olyan jellemzője van, mely problémák forrása lehet teszteléskor: • Problémák szétdarabolása. • Adatrejtés. A OO környezetek sajátossága, hogy lehetőséget ad a problémák szétdarabolására, és a részproblémák hierarchikus megoldására. A OO tervezés egyik alapideológiája, hogy igyekezzünk a megoldandó feladat elemzésével azt olyan kisebb egységekre, részfeladatokra osztani, amelyeket már köny- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 118 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 119 ► nyebben meg lehet oldani. Ennek eredménye általában, hogy az OO rendszerek nagyszámú, egymással aktívan kapcsolatban levő, együttműködő komponensekből

állnak. A tesztelt rendszer ilyen jellegű felépítése elsősorban az izolációs (elhatárolásos) tesztelés esetén lehet kedvezőtlen Az OO programozás másik jellemzője a komponensek jól definiált interfészen keresztül történő elérése, és ezzel párhuzamosan a nem publikus adatok és funkciók elrejtése. Az adatok és függvények elrejtése a tesztelés során igen sok gondot okozhat, ha a szoftverünk működését meg szeretnénk figyelni, ill. irányítani szeretnénk, egy adott működési állapotba szeretnénk juttatni A problémák további forrásai lehetnek nyelvi sajátságok. Ilyen pl a C++-ban használatos virtuális függvények. Egy adott objektum osztály virtuális függvényeit a leszármaztatott osztályban fölül lehet definiálni. Ha egy fölüldefiniált virtuális függvényt hívok meg a szülő osztályra mutató pointeren keresztül, akkor az adott pointer típusától (előéletétől) függően a szülő osztály, vagy valamelyik

gyermek osztály függvénye fog ténylegesen meghívódni. Logikailag ezt úgy tekinthetjük, mintha az adott helyen egy speciális elágazás utasítás lenne, mely a pointer típusától függően különbőző vezérlési ágat, különböző függvényt választ. Az ilyen kódba rejtett, implicit elágazások kezelése igen nehéz tesztelés során. Mindenképpen szót kell ejteni arról, hogy az OO paradigmában széles körűen használt polimorfizmus (egyazon kód használati környezettől függő értelmezése) milyen hatással van a tesztelésre. A fenti példa, a C++ virtuális függvények kezelése is polimorfizmus, de sokkal egyszerűbb példákat is mondhatunk polimorfizmusra: template-ek használata, azonos nevű függvények paraméterlistától függő meghívása, szülő osztályban definiált függvények fölüldefiniálása, ill. használata Ezek a nyelvi lehetőségek elsősorban a tesztelés alaposságának mérésekor (lefedettségi analízis) okozhatnak

problémát. A tesztelés alaposságának jellemzésekor a tesztelő rendszerek általában strukturális mértékszámokat (utasítás lefedettség, út lefedettség stb.) használnak OO kód esetén ezeknek a mértékszámoknak a közvetlen használata igen megtévesztő lehet. Vegyünk egy nagyon egyszerű példát Egy G (gyermek) osztály egy S (szülő) osztályból származik. Tételezzük fel, hogy van az S osztálynak egy F függvénye, amit G nem definiál felül. Ha G osztályt teszteljük, természetesen teszteljük az F függvényt is, melynek kódja az S osztályban van definiálva. Ha az S osztály kód lefedettségét vizsgáljuk, akkor a G osztály tesztelése után az S osztálybeli F függvény A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 119 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 120 ► kódját pl. az

utasítás lefedettség mértékszám lefedettnek fogja tekinteni Ez természetesen nem jogos, mert az F függvény meghívása nem az S osztály környezetéből, hanem a G osztály környezetéből történt. Láthatjuk tehát, hogy a procedurális nyelvek tesztelésénél használt mértékszámok változatlan használata OO rendszerek tesztelésekor nem fejezi ki helyesen a tesztelés alaposságát. Ezért egyrészt kidolgoztak az OO rendszerek tesztelésének alaposságának jellemzésére alkalmas egyedi mértékszámokat, valamint a strukturális teszteléskor használt mértékszámok OO rendszerekben használható változatát. 6.2 Tesztelés nem OO rendszerekben Az OO rendszerekben alkalmazott tesztelési módszerek ismertetés előtt röviden összefoglaljuk a hagyományos, nem OO rendszerek tesztelésekor használt tipikus teszt környezetek módszereket leírását, azok előnyeit. A tipikus, „hagyományos” szoftverfejlesztés procedurális nyelven történik, top-down

tervezési metodika szerint. Az ilyen alkalmazásokat tipikusan ún dinamikus teszteléssel ellenőrzik Készítenek egy teszt környezetet, melynek feladatai a következők: • bemenetek biztosítása a tesztelendő szoftver (Software Under Test: SUT) számára, • SUT működtetése, • kimenetek, esetleges belső változók megfigyelése. Az ilyen tesztelési megközelítés mind modul, mind integrációs, mind rendszer tesztelés esetén jól használható. A leggyakrabban használt tesztelési módszer az – elsősorban modul teszteléskor használt – izolációs tesztelés. Ekkor a teszt környezet a fenti feladatokon túl lehetőséget ad a szoftver nem tesztelt részeinek szimulálására ún. csonkok definiálása formájában A csonkok helyettesítik a nem tesztelt program függvényeit. A függvények működésének megfelelően a csonkokat is meghívhatja a SUT, a különbség annyi, hogy a csonkok működése ismert és garantáltan helyes. Helytelen működés

esetén a hiba a SUT-ban van. Az izolációs tesztelés előnyei a következők: • A szoftver komponensei egyenként is tesztelhetőek, adott esetben még a többi rész elkészülte előtt. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 120 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 121 ► • Tesztelhető először a komponensek belső működése, majd ezt követően az interfészek. • A tesztkörnyezet egy adott szoftver egymást követő verzióiban újrahasználható. • A tesztelés megfelelő teszt környezet esetén jól automatizálható. Az izolációs tesztelés hátránya, hogy a tesztelőnek definiálnia kell a csonkokat. Ezt a feladatot lényegesen megkönnyítheti, ha olyan módon lehet az egy alkalommal tesztelt komponensek határait megválasztani, hogy kevés kapcsolata legyen a tesztelt rendszer többi

komponensével. 6.3 Hagyományos tesztelési módszerek alkalmazása OO környezetben 6.31 Izolációs tesztelés Az izolációs tesztelés alkalmazásakor a legnagyobb gondot a környezet kialakítása jelenti. Az OO rendszerek – mint említettük – tipikusan sok egymással szoros kapcsolatban levő komponensből állnak. Ezért nehéz a komponensekhez a teszt környezet elkészítése, túl sok többletmunkát igényel a nagyszámú csonk definiálása. Problémát jelent a teszt környezet (csonkok) újrafelhasználása is. A OO rendszerek előszeretettel használják a megírt kódot többször is (pl.: öröklés). A teszt környezet változatlan formában történő újra-használata általában nincs lehetőség, az esetek túlnyomó többségében jelentős többletmunkát igényel az adaptáció. Az izolációs technikát ezért általában nem gyakran használják OO rendszerek tesztelésekor. Ezzel szemben a bottom-up tesztelést, mely sok vonatkozásban hasonló az

izolációs technikához, annál többször. 6.32 Bottom-up tesztelés A bottom-up tesztelés esetén is a tesztelő részekre osztja a SUT-ot. Az egyes önállóan tesztelt részeket azonban rétegeknek nevezzük, mert azok rétegesen épülnek egymásra. Legelőször a tesztelő azokat a komponenseket, osztályokat teszteli, amelyek nem függenek más osztálytól, nem hívnak semmilyen más osztálybeli függvényt Utána azok az osztályok következnek, amelyek csak ettől az először tesztelt osztálytól függenek A csak már tesztelt osztályra épülő osztályok tesztelése addig tart, míg az egész szoftvert le nem teszteltük. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 121 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 122 ► A legnagyobb problémát a körkörös hivatkozások jelentik, ha van olyan csoportja az

osztályoknak, amelyek körkörösen hivatkoznak egymásra. Ekkor vagy egyszerre teszteljük az összes, körben szereplő osztályt, vagy az izolációs technikát használjuk, vagyis a hivatkozott osztályok egy részét a teszt környezet segítségével (csonkok formájában) implementáljuk. Összefoglalva a bottom-up tesztelés módszerének előnye, hogy nem kell csonkokat definiálni. Hátránya, hogy egy adott rétegben levő komponensek belső működését, ill a komponensek közötti interfészt egyszerre, ugyanazon tesztesetekkel teszteljük. Így adott esetben nehéz lehet a hiba forrásának lokalizálása. További hátránya a bottom-up tesztelésnek, hogy nem tesztelhető egy adott réteg viselkedése abban az esetben, ha az alatta levő réteg hibásan működik, hiszen egy réteg tesztelése csak az alatta levő rétegek tesztelése után következik. Elképzelhető, hogy a szoftver szerencsétlen felépítése, a körkörös függések következtében nem osztható

megfelelően rétegekre. Emiatt a gyakorlatban gyakran használják a bottom-up tesztelést kombinálva az izolációs technikával 6.4 OO rendszerek tesztelési technikái OO rendszerek tipikus tesztelési feladatainak megoldására több technika született ezek közül ismertetjük a legfontosabbakat. Ezek a technikák általában a hagyományos (procedurális nyelvi környezetben fejlesztett) szoftverek tesztelésére kidolgozott módszerek alkalmazását teszik lehetővé, vagy könnyítik meg OO környezetben. 6.41 Tesztelhetőségre tervezés Általánosan megállapítható, hogy OO rendszerek tervezésekor érdemes figyelembe venni a tesztelhetőségi szempontokat, a szoftvert tesztelhetőre tervezni. A tesztelhetőség olyan általános szempontokként fogalmazható meg mint: • Kerülni kell a nem feltétlenül szükséges kapcsolatokat osztályok között. • Lehetőséget kell adni az adatok (belső változók) megfigyelésére, beállítására. • Kerülni kell a

virtuális függvények felesleges használatát. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 122 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 123 ► A fenti kitételek sajnos nagyon általánosak, és ami rosszabb, az OO programozás eszköztárát lényegesen korlátozzák. Az esetek nagy többségében a szabályok betartása a kód hatékonyságának csökkenéséhez, az OO tervezés előnyeinek elvesztéséhez vezetne. Ezért a fenti szabályok betartásának realitása megkérdőjelezhető A fenti általános szabályoknál gyakorlati szempontból ígéretesebb lehetőség az Absztrakt Bázis Osztályok (ABO: Abstract Base Classes) használata. Ennek a tesztelhetőre tervezési technikának a lényege, hogy az osztályok interfészét egy külön osztályban valósítják meg absztrakt (függvénytörzs nélküli

virtuális) függvényekként Ekkor ugyan a rendszerben levő osztályok száma megnő, azonban könnyebben lehet az egyes osztályokat egymástól elhatárolni, és alkalmazni az izolációs technikát. 6.42 Wrapper osztályok használata Mint korában már említettük, az OO rendszerekben nehézséget okoz az objektumokban használt rejtett adatok megfigyelése és beállítása. Ezt a problémát lehet megoldani az ún. wrapper (csomagoló, köpeny) osztályok segítségével. A wrapper osztályok használatának másik indoka, hogy megkönnyítik a tesztesetek dokumentálását A wrapper osztályok ötlete nagyon egyszerű. Az egyes osztályok belső változói, függvényei nem elérhetőek a külvilág számára. A nyelvek többsége (pl: C++, Java) lehetőséget ad azonban egyes osztályok közötti speciális viszony (friend) deklarálására, ami lényege, hogy a két osztály kódjából elérhetővé válik a másik osztály belső változói és függvényei. A wrapper

osztályok segítségével ezt a lehetőséget használhatjuk ki tesztelésre. A tesztelő környezetben minden osztályhoz létrehozhatunk egy wrapper osztályt, amely a deklarációk megfelelő megadásával elérheti a tesztelt osztály belső változóit. Ekkor a wrapper osztályban készíthetünk függvényeket a belső változók megjelenítésére, beállítására. A wrapper osztályok használatának másik célja, hogy a megfigyelése és dokumentálása a tesztelt rendszer működésének. Ebben az esetben az wrapper osztályt a tesztelt osztállyal azonos interfésszel hozzuk létre. A tesztelt osztály tesztelésekor annak függvényei helyett mindig a wrapper osztály függvényeit hívjuk meg. A wrapper osztály adott függvény meghívásakor dokumentálja a meghívás tényét, a hívási paramétereket, majd meghívja a tesztelt osztály eredeti függvényét. A függvényhívásból történő visszatéréskor a wrapper A dokumentum használata | Tartalomjegyzék |

Felhasznált irodalom Vissza ◄ 123 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 124 ► osztály megint csak dokumentálhatja, esetleg ellenőrizheti a visszatérési értékeket. A wrapper osztály használatát mutatja 61 ábra Class A public Class B függvény hívás public return private private Wrapper Class B Class A public függvény hívás Class B public public return private private Teszt dokumentáció 6.1 ábra Wrapper osztályok használata a tesztesetek dokumentálására 6.43 Tesztelés állapot-átmeneti diagram alapján Az állapot átmeneti diagramm alapján történő tesztelés az OO rendszerek azon tulajdonságát használja ki, hogy az objektumok működése jól modellezhető egy állapot automatával. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 124 ►

Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 125 ► Teszteléskor egyes osztályok, ill. az osztályokat megtestesítő objektumok működését egy-egy állapot automatával, ill annak működését reprezentáló állapotátmenet diagrammal írjuk le A tesztelt szoftver rendszer reprezentációja a hozzá tartozó objektumokat leíró automaták halmaza lesz. Az egyes objektumokhoz tartozó automaták kapcsolatát, a teljes rendszer működését egy rendszer szintű állapot automatával írhatjuk le. Az globális rendszer a külső hatásokra, a bemenetekre ad válaszokat. A bemeneteket a rendszer szintű automata fogadja, és továbbítja az egyes objektumok, vagyis az őket reprezentáló automaták felé Az egész rendszer így eseményvezérelten működik, a bemenetek hatása végig szalad az egész rendszeren. külsô esemény válasz szál receptor emitter

tesztelt rendszer határa komponens osztályok állapot modelljei 6.2 ábra Esemény terjedése állapot-átmeneti automata alapján történő teszteléskor Létezik állapot-átmeneti diagram alapján történő tesztelést támogató rendszer, melyben egyszerűen definiálhatóak az automaták, és követhető a rendszer működése. 6.5 Mértékszámok használata Mint már említettük, a strukturális mérőszámok használata OO rendszerek tesztelése esetén torz mérési eredményt eredményezhet. Ennek a problémának megoldására egyrészt definiáltak speciálisan OO rendszerek tesztelésének alaposságát jól jellemző mérőszámokat, másrészt kidolgoz- A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 125 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 126 ► ták egy a strukturális mérőszámok számolásának OO

rendszerek tesztelésekor használható módszerét. Ezeket a származtatott mértékszámokat nevezzük környezetfüggő mértékszámoknak. Elsősorban OO szoftverteszteléshez definiált mértékszámok: • Belépési pont lefedettség – Entry point coverage. • Kölcsönös hívás lefedettség – Call-pair coverage. Környezetfüggő mértékszámok: • Öröklésfüggő lefedettség – Inheritance context coverage • Állapotfüggő lefedettség – State based context coverage • Szálfüggő lefedettség – Thread based context coverage 6.51 Belépési pont fedettség – Entry point coverage Objektum-orientált rendszerek elsősorban integrációs funkcionális tesztelésénél használt mérőszám. Azt mutatja meg, hogy egy adott objektum publikus interfészében definiált függvények mekkora hányadát hívtuk meg a tesztelés folyamán. A mértékszám előnye, hogy alkalmas az esetlegesen nem megvalósított, így nem felhívható függvények

felderítésére. 6.52 Kölcsönös híváslefedettség – Call-pair coverage Általában integrációs tesztelésnél használt mérőszám. Arányszám, ami megadja, hogy két objektum között lehetséges függvényhívások mekkora hányada került ténylegesen meghívásra a teszt végrehajtása során. Ugyan azon függvény különböző kódrészletekből történő hívásait megkülönbözteti. 6.53 Környezetfüggő mértékszámok A strukturális mértékszámok OO környezetben, mint láttuk, nem szolgáltatnak megfelelő támpontot a tesztelés alaposságára vonatkozóan. A fő probléma abból adódik, hogy a kód újrahasználása, ill. a polimorfizmus miatt egy adott kódrészlet (adott FVG-beli ág, csomópont, út stb.) a program különböző helyeiről, különböző (program) környezetből meghívható A meghívott kód működése függhet a meghívási (aktivizálási) környezettől, így az alapos teszteléshez hozzátartozik az adott kódrészlet minden

lehetséges környezetből történő meghívása, tesztelése. A környezetfüggő mértékszámok pontosan ezt oldják meg. Minden hagyományos strukturális mértékszámból származtathatunk környezet A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 126 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 127 ► függő mértékszámot, ráadásul többet is attól függően, hogy a kód hívási (aktivizálási) környezetének milyen jellemzőjét vesszük figyelembe. Ha a teszteléskor az osztályhierarchiát vesszük figyelembe mint környezetet, akkor az ún. „örökölt kód lefedettségi” (inheritance context coverage) mértékszámokat kapjuk. Az örökölt kód lefedettség számítása szempontjából egy örökölt függvény meghívása különbözik, ha a szülő és ha a gyerek osztályból hívódik meg. 6.54

Öröklésfüggő döntés lefedettség – Inheritance context decision coverage A döntés lefedettség örökölt kód lefedettség alapján számolt környezet függő mértékszám változata. Számításának menete: I(c)=i/I. Ahol i egyenlő a teszt során végrehajtott elágazások számának összegével, olyan módon számolva, hogy a különböző elágazások bejárását (döntések meghozatalát) objektum környezetenként megkülönböztetjük. I az elágazások összes száma megszorozva az elágazásra hivatkozó környezetek számával. 6.55 Állapotfüggő lefedettség – State based context coverage Olyan környezet függő mértékszám csoport, ahol a hívási környezet figyelembevételekor nem csak a hívó objektum típusát, hanem annk aktuális állapotát is figyelembe vesszük. Ezeket a mértékszámokat az állapot-átmenet diagramm alapján történő tesztelés során használják 6.56 Szálfüggő lefedettség – Thread based context coverage

Többszálú alkalmazások tesztelése esetén lehetnek hasznosak, amikor a mértékszám számításakor a hívó szál azonosítóját is figyelembe vesszük. A szálak azonos közös kódot hajtanak végre, tesztelési szempontból fontos, hogy egy adott kódrészlet melyik szál környezetében került végrehajtásra. A mértékszám úgy viselkedik, mintha a különböző szálaknak külön kódja lenne, és annak lefedettségét mérnénk. 6.6 Konkrét tesztelő rendszerek 6.61 Cantata++ A Cantata++ C++ nyelvű szoftverek egység és integrációs tesztjeihez használható A teszteket a felhasználó által írt scriptek vezérlik. A teszt a A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 127 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 128 ► tesztelendő forráskód, a teszt script és a „Cantata++ Test Harness”

fordításával, ill. linkelésével keletkező futtatható program, mely futtatva egy teszteredmény fájlt hoz létre. Az így keletkezett program lehetővé teszi a teszt futtatását, dokumentálását és megismétlését. A Cantata++ teszt scriptek C++ nyelven íródnak és tulajdonképpen egy main függvényből állnak, ami végrehajtja a tesztelendő szoftveregységet. Egy „SM Tool” nevű egység lehetővé teszi, hogy a Test Harness és ezen az interfészen keresztül a teszt script hozzáférhessen a tesztelendő egység implementációja által elzárt olyan részletekhez, mint adat elemek és más egységek felé irányuló interfészek. Ez az egység végzi a forráskód beműszerezését, mely C++ friend deklarációk és wrapping formájában jelentkezik. A csonkok (stub) írása a felhasználóra marad, de megadható, hogy teszteléskor az egyes meghívásokkor milyen visszatérési értékei legyenek a szimulált függvénynek. A teszt scriptekben ellenőrizhetők

az adatelemek értékei ill ellenőrizhetők azok az adatterületek melyek értékeinek nem szabad változniuk a teszt futása alatt A Cantata lehetővé teszi hogy mérjünk különböző végrehajtási időket és összehasonlítsuk őket meghatározott követelményekkel. A Cantata++ biztosít eszközöket arra, hogy a leszármaztatott osztályok tesztelésére teszteket származtassunk le az alap osztály tesztjeiből (parallel inheritance hierachy). A beműszerezés ellátja a kódot teszt lefedettségi metrikák meghatározásához szükséges adatgyűjtő részekkel. A következő lefedettségi metrikák mérhetők: statement coverage, decision coverage, boolean expression coverage, call-pair coverage, call coverage, modified condition coverage. A Cantata rendelkezik egy statikus analizátorral is, mely kód metrikák meghatározására alkalmas, pl a Halstead-féle szoftver metrikák, a McCabe-féle ciklomatikus metrikák, nyelvi konstrukciók száma – sorok száma,

megjegyzések, függvény paraméterek stb. Meghatározhatók különböző objektum orientált szoftver metrikák is, pl. Chidamber és Kremerer metrikák, osztály entrópia metrikák stb. 6.62 SGI Tester A Tester az sgi ProDev debugger-csomag dinamikus teszt lefedettség analízis eszköze. A Tester nem biztosít egy komplett tesztvégrehajtó környezetet, csupán a végrehajtható kód speciális beműszerezésére szolgál, teszt lefedettségi adatok gyűjtésére, és lehetővé teszi ezen adatok grafikus felületen való elemzését. C, C++ és Fortran programokhoz használható A folyamat a következő: a felhasználó definiálja, hogy milyen kód moduloknál milyen jellegű lefedettségi adatokat kell gyűjteni. A rendszer ez alapján A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 128 ► Szoftver-minőségbiztosítás Objektum-orientált szoftvertesztelés A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza

◄ 129 ► generál egy speciális végrehajtható fájlt, melyet futtatva lehet elvégezni a tesztelést. A tesztelés végeztével rendelkezésre állnak a lefedettségi adatok, melyek elemzéséhez a ProDev rendszeren belül speciális grafikus megjelenítők tartoznak. Az alkalmazható lefedettségi metrikák: forrás sor lefedettség, function entry point coverage, arcs (call-pair) coverage, decision coverage, block coverage. A rendszer script nyelve lehetővé teszi olyan parancssor orientált programok automatizált tesztelését, melyek viselkedését indításukkor megszabhatjuk. 6.63 Aprobe Az Aprobe egy tesztelő, debuggoló és teljesítmény-optimalizáló rendszer. Az általa alkalmazott műszerezési eljárás abban különbözik a szokásos tesztelő környezetekétől, hogy a tesztelendő programot a forráskód újrafordítása és linkelése nélkül teszi alkalmassá a tesztelésre. Az Aprobe minimálisan módosítja csak az eredeti program működését és

így alkalmas real-time alkalmazások egység és integrációs tesztelésére is. A tesztelendő program és a műszerezés interakciója csak a teszt végrehajtásakor kezdődik. A műszerezést ún próbák írásával végezhetjük A próbák az eredeti végrehajtható kóddal mint patch-ek egy „dynamic action linking” nevű eljárással kerülnek kapcsolatba. Mivel a tesztelendő alkalmazás teljesen szétválik a próbáktól ezért könnyű önálló, újra felhasználható próbákat készíteni. Bizonyos tesztmérések, metrikák meghatározása elvégezhető a forráskód nélkül is, más által fejlesztett rendszereken. Amennyiben a végrehajtható kód tartalmaz debug információkat, amely összeköti a forrással (nem szükséges rendelkeznünk a forráskóddal), akkor próbáinkban hivatkozhatunk a forrás terminológiájára. A próbákat egy C-szerű script nyelven lehet megírni Tartalmazhatnak saját változókat, hozzá férhetünk a tesztelt program saját

változóihoz, mérhetünk végrehajtási időket (teljesítménytesztelés), függvények ki- és belépési pontjain módosíthatjuk a bemenő paramétereket, ill. a visszatérési értéket Ez utóbbiak segítségével lehetőségünk van hiba injektálásra, stressz tesztelésre vagy hibajavítási elképzelések kipróbálására. Aprobe próbákkal előállíthatunk teszt lefedettségi metrikákat és használhatjuk optimalizálási profil készítésre is. Mivel a script nyelv egy teljes programozási nyelv, létrehozhatunk vele automatizált tesztelésre alkalmas környezetet. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 129 ► Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Felhasznált irodalom Vissza ◄ 130 ► Felhasznált 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. A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 130 ► Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Felhasznált

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 1–41, 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 József Sziray: Verification and Validation

of Software Systems. Research Study, Széchenyi University, Győr, 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 Péter Arató, Tamás Visegrády, István Jankovits, Szabolcs Szigeti: HighLevel Synthesis of Pipelined Datapaths. Panem Publishing Ltd, Budapest, 2000. Pataricza András, Majzik István, Csertán György, Bartha Tamás: Formális módszerek az informatikában. Jegyzet, 185 old, Budapesti Műszaki Egyetem, 2000 Z. Navabi: VHDL: Analysis and Modeling of Digital Systems McGraw-Hill Publishing Company, Inc., USA, 1993 Sudhakar Yalamanchili: VHDL: Starter’s Guide. Prentice-Hall, Inc, USA,

1998. Richard S. Wiener, Lewis J Pinson: The C++ Workbook Addison-Wesley Publishing Company, Inc., USA, 1990 A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 131 ► Szoftver-minőségbiztosítás A dokumentum használata | Tartalomjegyzék | Felhasznált irodalom Felhasznált irodalom Vissza ◄ 132 ► Kondorosi Károly, László Zoltán, Szirmay-Kalos László: Objektum-orientált szoftverfejlesztés. Computer Books Kiadói 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. Balázs Benyó, József Sziray: Testing Principles for Object-oriented Software. Research Study, Széchenyi University, Győr, 2001. A dokumentum használata |

Tartalomjegyzék | Felhasznált irodalom Vissza ◄ 132 ►