A rendszertesztelés egy magasszintű tesztelés, amelynek a célja, hogy a rendszerrel szemben támasztott funkcionális és nem-funkcionális követelményeknek való megfelelést ellenőrizzük azaz, hogy a követelmény specifikáció transzformációjában történt hibákat
124
felderítsük. A rendszertesztelést megelőzi a komponensek integrálása, amely az alkalmazott szoftverfolyamattól függően több módon is megvalósulhat. A rendszertesztelés az iteratív fejlesztési folyamatban a megrendelő számára leszállítandó inkremens, míg vízesés jellegű folyamat során a teljes rendszer tesztelését jelenti. A rendszertesztelés két különálló fázisra bontható:
1. Integrációs tesztelés. A rendszerintegráció a rendszer felépítését jelenti a komponenseiből. Az integrációs tesztelés az eredményül kapott rendszert ellenőrzi abból a szempontból, hogy az integrált komponensek megfelelően tudnak-e együttműködni. Ha az integrációs teszt során hibák merülnek fel az nagy valószínűséggel a legutoljára integrált komponenssel való együttműködés hibájára vezethető vissza. Az integrációs tesztelés célja elsődlegesen a rendszerszintű hiányosságok feltárása.
2. Kiadástesztelés. Ebben az esetben a rendszer egy olyan inkremense kerül tesztelésre, amely a megrendelő számára kiadható. A teszt célja megmutatni, hogy az inkremens megfelel-e az előírt funkcionális és nem-funkcionális követelményeknek. A kiadástesztelés egy fekete doboz tesztelés, amelynek során azt vizsgálják, hogy meghatározott inputok esetén, milyen outputokat szolgáltat a rendszer. Ha a funkcionális tesztelésbe a vásárlót is bevonják, akkor ezt elfogadási tesztelésnek nevezzük.
A két tesztelési fázis átfedheti egymást, ha a fejlesztésben az inkrementális fejlesztés elveit követjük és közbenső inkremenseket is le akarunk szállítani a megrendelő felé. Összefoglalva, általánosságban azt mondhatjuk, hogy az integrációs tesztelés során a rendszerben található hiányosságok felderítése a cél, míg a funkcionális tesztelésben a rendszerkövetelményeknek való megfelelés ellenőrzése az elsődleges. Azonban mindkét esetben végezhetünk validációs és hiányosságtesztelést is.
10.2.1 Integrációs tesztelés
A fejlesztés során az integrált komponensek lehetnek megvásárolt, újrafelhasználható, illetve újonnan kifejlesztett komponensek. A komponensek tesztelését és integrációját követően kerül sor az integrációs tesztelésre, amelynek célja, hogy az integrált komponensek együttműködésében található hibákat felderítsük. Az integrációs tesztelés elsődlegesen azt ellenőrzi, hogy ezek a komponensek képesek-e együttműködni azaz, hogy megfelelően vannak-e meghívva és interfészeiken keresztül a megfelelő adatokat, megfelelő típussal, megfelelő sorrendben és megfelelő időben küldik-e át. A rendszer-integráció során az egyes inkremensek újabb és újabb funkcióval bővülnek. A komponensek integrációjakor általában egy új funkciót biztosító összes komponens integrálásra kerül. A komponensek integrációja magában foglalja további kódok létrehozását, amely a komponensek együttműködését biztosítja az adott funkció létrehozásában. A komponensek integrálására két módszert a fentről lefelé és a lentről felfelé stratégiát alkalmazhatjuk. Az első esetben a rendszer vázát készítik el elsőként és ehhez integrálják a további komponenseket. A második esetben először a funkcionális működés alapjául szolgáló, alapvető szolgáltatásokat (pl. felhasználói felület, hálózati kommunikáció, stb.) nyújtó komponenseket integráljuk, majd a funkcionalitást biztosító komponensek kerülnek integrálásra. A gyakorlatban legtöbbször e két stratégiát vegyesen alkalmazzák és mind az alapvető szolgáltatásokat mind a funkcionalitást biztosító komponenseket inkrementumokban adják a rendszerhez.
Az integrációs hibák felderítését jelentősen megkönnyíti, ha a rendszer integrálása és tesztelése során inkrementális megközelítést használunk. Kezdetben csak minimális rendszert
125
hozzuk létre, majd ehhez a konfigurációhoz integráljuk a további komponenseket és teszteljük az új rendszerfunkciókat. Ha e tesztek során problémák merülnek fel, akkor ezek valószínűleg az új komponenssel való együttműködés miatt vannak. A probléma forrását ezáltal könnyebben meg tudjuk határozni, amely által egyszerűbb lesz a hiba felderítése és javítása.
A komponensek integrációjának sorrendjét az általuk biztosított funkció prioritása határozza meg. Nagyobb prioritással rendelkezhetnek például a gyakran használt rendszer funkciók. Sok esetben a fejlesztésbe bevont megrendelő szempontjai határozzák meg, hogy a következő inkremens milyen funkciókkal bővüljön.
Az új rendszerkomponensek integrálása és tesztelése során nagy jelentősége van a regressziós tesztelésnek. A regressziós tesztelés során nem csak az aktuálisan integrált komponens által biztosított rendszerfunkciókat teszteljük, hanem a korábbi inkremensek tesztelésére készített teszteseteket is újra lefuttatjuk. Erre azért van szükség, mert egy új komponens integrálása jelentős hatással lehet a már korábban integrált komponensek együttműködésére is, és olyan hibákat is felfedezhetünk, amelyek az egyszerűbb verzió tesztelésénél még nem jelentkeztek. Ha a regressziós tesztelés során probléma adódik, akkor ellenőrizni kell, hogy azok a problémák az előző inkrementumban vannak-e jelen, vagy az új komponens hozzáadása okozta-e őket.
10.2.2 Kiadástesztelés
A kiadás tesztelés során a megrendelőnek leszállítandó rendszerverzió tesztelését végezzük. Inkrementális fejlesztés esetén ez nem feltétlenül jelenti a kész teljes rendszer tesztelelését. A kiadás tesztelés elsődleges célja, hogy bizonyítsuk, hogy a rendszer megfelel a megrendelői követelményeknek azaz, hogy rendelkezik a specifikációban rögzített a funkcionalitásokkal és nem-funkcionális követelményekkel (például teljesítmény, üzembiztonság stb.). Ha ezek teljesülnek, akkor válik a rendszer kiadható termékké, és szállítható le a megrendelőnek. A kiadástesztelés általában egy fekete doboz tesztelés, amelynek során a teszteseteket a követelmény elemezés során nyert funkcionális követelmények alapján hozzuk létre. A rendszert fekete doboznak tekintjük, azaz arra vagyunk kíváncsiak, hogy milyen bemenetre milyen kimenet állít elő a rendszer, de nem vagyunk arra kíváncsiak arra, hogy azt hogy valósítja meg. Ennek folytán a kiadási tesztet funkcionális tesztnek is szokás nevezni.
Fontos, hogy nagyobb projektek esetén a "fekete doboz" típusú tesztelésnél ajánlott külön tesztelő és fejlesztő csapat elkülönítése és létrehozása.
126
9.2. ábra. A fekete doboz tesztelés folyamata.
A fekete doboz tesztelés folyamatát a 9.2. ábra ábrázolja. A kidolgozott tesztesetekben az input adatok a követelmény specifikációnak is megfelelő input halmazból kerülnek ki és a tesztelés akkor mondható sikeresnek, ha az output adatok a teszteset specifikációnak megfelelő tartományba esnek. Ha a kimeneti adatok nem felelnek meg a teszteset specifikációnak és az Oe halmazba esnek, akkor a teszt felfedezett egy, a szoftverrel kapcsolatos hibát. A hiányosság tesztelés esetén az inputokat olyan halmazból választjuk (Ie
input halmaz), amelyek valószínűséggel rendszerhibát okoznak és a kimenetek az Oe
halmazba esnek. Az Ie halmaz meghatározása a hasonló tesztesetekben szerzett tapasztalatok és gyakorlatok segíthetik.
A rendszer követelmények ellenőrzésének leggyakoribb módja a forgatókönyv alapú tesztelés, amelynek során a rendszer lehetséges használatának különböző forgatókönyvei alapján fejlesztjük ki a teszteseteket. Amennyiben a rendszer funkcionális követelményeinek modellezésére használati eseteket alkalmazunk, a használati esetek és az egyes forgatókönyveket leíró szekvencia diagramok a rendszer tesztelésének alapjául szolgálhatnak.
A forgatókönyvekből kiindulva számos tesztesetet készíthetünk, amelyek a forgatókönyvben végrehajtott műveleteket tesztelik. A forgatókönyv alapú tesztelés esetében a legvalószínűbb forgatókönyveket teszteljük először, amelyek a rendszer leggyakrabban használt részeinek tesztelését jelenti.
10.2.3 Teljesítménytesztelés
A rendszert teljes integrálása után lehetséges a rendszer nem-funkcionális tulajdonságainak tesztelése, mint például a teljesítmény és a megbízhatóság. A teljesítmény tesztelés célja, hogy ellenőrizzük, hogy rendszer a tervezett terhelések mellett helyesen tud-e működni, azaz a követelményekben megfogalmazott teljesítményre képes. A tesztelés során olyan tesztesetek készülnek, amelyek megfelelően reprezentálják a rendszer átlagos feladatainak eloszlását. A tesztelés során a rendszert egyre nagyobb terhelés alá helyezik mindaddig, amíg a rendszer
127
teljesítménye elfogadhatatlanná válik.
A teljesítményben mutatkozó hiányosságok kiszűrésére gyakran használják a stressz tesztelést. Ebben az esetben az előzőekkel ellentétben a teszteket úgy tervezzük, hogy azok nem a rendszerek átlagos használatát tükrözik és a tervezési határokat túllépő teljesítményre kényszerítik a rendszert. A stressz tesztelésnek ebben a tekintetben két funkciója van.
Egyrészt teszteli a rendszer működését, nem várt túlterhelések mellett. A rendszer túlterhelt állapotában is fontos, hogy a túlterhelés ne okozzon adatvesztést vagy a felhasználói szolgáltatások váratlan megszakítását. Másrészt elősegítheti olyan hiányosságok felderítését, amelyek a normális működés körülményei között nem jelennek meg. Ezek a hiányosságok normál használat során nem okoznának rendszerhibát, de a stresszterhelés által előidézhetünk olyan állapotot, amely során a rendszerhiba bekövetkezik.
10.3 Ellenőrző kérdések
1. Mi a célja a szoftverek tesztelésének?
2. Ismertesse a szoftvertesztelés folyamatát!
3. Sorolja fel a tesztelés főbb típusait!
4. Mi a hiányosságtesztelés?
5. Milyen szoftver komponenseket tesztelünk egységteszttel?
6. Mi jelent a regresszió tesztelés?
7. Mi a különbség az integrációs és kiadástesztelés között?
8. Mi a különbség az kiadás és elfogadási teszt között?
9. Mi a funkcionális tesztelés?
10. Mi a teljesítménytesztelés célja?
128
11 BEÁGYAZOTT RENDSZEREK FEJLESZTÉSE
A beágyazott rendszer a hardver és szoftverelemek egy olyan együttese, amely egy konkrét feladat ellátására terveztek, gyakran valós idejű működési követelményeknek kell megfelelnie. A beágyazott rendszerek olyan számítógépes eszközöket tartalmaznak, amelyek képesek egy rendszeren belül az alkalmazás-orientált célberendezések önálló működését biztosítani. A mindennapi életben napi szinten használunk, illetve találkozunk olyan gépekkel, eszközökkel, amelyek működése egy beépített számítógép-alapú rendszeren alapul, azaz egy beágyazott rendszert tartalmaznak. Az autók (ABS, ESP), háztartási eszközök, gyógyászati berendezések, mobiltelefonok, az ipari termelésben használt gépek stb. sorolhatók fel olyan példaként, amelyek nagy valószínűséggel tartalmaznak beágyazott rendszereket.
A beágyazott rendszereknek sokszor többféle kritériumnak is meg kell felelniük egyszerre, mint például a valós idejű működés, megbízhatóság és teljesítmény. A beágyazott szoftverek gyakran korlátozott hardver erősforrások mellett működnek, pl.
kevés felhasználható memória terület, billentyűzet és monitor hiánya.
A beágyazott rendszerek többsége egy valós idejű operációs rendszeren alapul. A beágyazott rendszer folyamatosan kapcsolatban áll a környezettel és az alkalmazás-orientált célberendezés vezérléséhez szenzorokon és érzékelőkön keresztül méréseket végezhet. Ezeket a feladatokat a rendszerbe ágyazott szoftver biztosítja, amely fogadja a hardvertől érkező jeleket és arra valós időben a bevatkozókon vagy működtetőkön keresztül választ ad.
A számítógép alapú rendszerek között számos olyan rendszer található, amelyeknél a rendszer meghibásodása veszélyt jelent az emberi életre vagy jelentős gazdasági és fizikai károkat okoz. Ezeket a rendszereket kritikus rendszereknek nevezzük. A jellegét tekintve számos beágyazott rendszer egyben biztonságkritikus rendszernek is tekinthető.
Ezért ebben a fejezetben először a biztonságkritikus rendszerekkel és azok fejlesztésével foglalkozunk, majd kitérünk a valós időben működő szoftverek tervezési kérdéseire is.