Ugrás a tartalomhoz

Szoftverfejlesztés

Ficsor Lajos, Krizsán Zoltán, Mileff Péter

Bevezetés. A szoftverfejlesztés életciklus modelljei. A szoftver fejlesztés mint modellezési tevékenység. Fejlesztési módszertanok. Követelmény analízis. A szoftvertervezés folyamata. A Unified Modeling Language (UML). A használati eset modell. Strukturális diagramok. Viselkedés diagramok. Az analízis modell. A tervezési modell. Az implementációs modell. Tervezési minták. További fejlesztési tevékenységek áttekintése. Esettanulmány.

15. fejezet - További fejlesztési tevékenységek áttekintése

15. fejezet - További fejlesztési tevékenységek áttekintése

Valamely szoftver kifejlesztése a korábbi fejezetekben áttekintett nélkülözhetetlen folyamattevékenységek mellett számos további kisebb fejlesztési tevékenységen mehet át. Természetesen e fázisok bizonyos esetekben nélkülözhetők, melyet mindig a fejlesztendő szoftver komplexitása és típusa, valamint a környezet határoz meg.

Az alábbi fejezetben olyan további tevékenységeket tekintünk át, melyek igaz hozzátartoznak a szoftverfejlesztés irodalmához, bár nem szükségszerűek, de a fejlesztés menete megkívánhatja. A nélkülözhetőség kritériuma alól egyetlen egy tevékenység lesz a kivétel, maga a szoftvertesztelés. Ezt a tevékenységet minden szakirodalom szorosan a többi fontos tevékenység mellett szerepelteti, mint ahogy látni fogjuk teljesen jogosan.

Egy szoftver készítése során több különböző fázison megy keresztül. Az egyes fázisok után, de kitüntetetten bizonyos fázisokban elengedhetetlen a tesztelés folyamata. Ennek oka nagyon egyszerű. A fejlesztés folyamata megköveteli az emberi intelligenciát, és mivel az ember könnyen hibázik, szükségszerű, hogy az egyes fázisok elkészülte után valamilyen ellenőrzést hajtsunk végre a terven, kódrészleten, stb. Ennek hiányában a készülendő szoftver valószínűleg tele lesz hibákkal, melyet a megrendelő pedig nem fog elfogadni.

A szakirodalomban számos technika alakult ki a tesztelés folyamatának segítésére. A következőkben általánosan áttekintjük ezt a folyamatot.

15.1 Verifikáció és validáció

A verifikáció és a validációt (V & V) általánosan szoftvervalidációnak nevezik. Legfőbb célja, hogy megmutassa, a rendszer konform a saját specifi­kációjával, és hogy a rendszer megfelel a rendszert megvásárló ügyfél elvárásai­nak. Ez olyan ellenőrzési folyamatokat foglal magában, mint például szemléket, felülvizsgálatokat a szoftverfolyamat minden egyes szakaszában a felhasználói követelmények meghatározásától kezdve egészen a program kifej­lesztéséig. Röviden tehát:

  1. Verifikáció: a terméket jól készítetjük el?

  2. Validáció: a megfelelő terméket készítetjük el?

A verifikáció magába foglalja annak ellenőrzését, hogy a szoftver megfelel-e a specifikációnak, azaz eleget tesz-e a funkcionális és nem funkcionális követelményeknek. Általánosabban: a szoftver megfelel-e a vásárló elvárásainak.

A validáció ennél kicsit általánosabb fogalom. Végcélja az, hogy megbizonyosodjunk arról, hogy a szoftverrendszer „megfelel-e a célnak”. Azaz teljesül-e a vásárló elvárása, amibe beleértendő olyan nem funkcionális tulajdonságok is, mint a hatékonyság, hibatűrés, erőforrásigény.

A V & V két, egymást kiegészítő különböző perspektíva segítségével végzi az ellenőrzési folyamatot:

 

  1. Statikus: szoftverátvizsgálások. Olyan technikák, melyek kimondottan csak a rendszer reprezentációját elemzik. Ilyen a követelmény dokumentum, a tervek, és forráskódok.

  2. Dinamikus: a klasszikus értelemben vett szoftvertesztelés. Csakis az implementáció fázisában végezhető el. Valamely tesztadatok segítségével ellenőrzi, hogy a rendszer adott inputra megfelelő outputot nyújt-e.

Az átvizsgálási technikák közé tartoznak a programátvizsgálások, az automatizált forráskód elemzés és formális verifikáció. A rendszert csak akkor tesztelhetjük, ha elkészült egy végrehajtható változatának prototípusa. Az inkrementális fejlesztés előnye, hogy a különböző inkremensek külön tesztelhetők, és az egyes funkciók már hamarabb tesztelhetők.

Ne felejtsük el, hogy a tesztelési folyamat önmagában véve nagyon általános. A klasszikus értelemben vett „futtatom a programot és megvizsgálom jó lett-e az eredmény” csak egy részét képezi a teljes folyamatnak. A szakirodalmi tapasztalatok szerint az átvizsgálási folyamatot a szoftverfolyamat minden olyan lépésében használható és alkalmazni is kell, ahol már rendelkezésre áll valamilyen kézzel fogható, olvasható reprezentáció a rendszerről. Ez általában a követelmények feltárása fázisban a követelmények validálásaval kezdődik egészen a végleges rendszer leszállításáig. Nyugodtan kijelenthető, hogy gyakorlatilag minden részfolyamat validációja szükséges.

15.1 .1 A tesztelés folyamata általánosan

A kis programok kivételével a rendszerek nem tesztelhetők magukban, mint monolitikus egységek. Egy elkészült rendszer már túl komplex ehhez, ezért fontos, hogy a tesztelési folyamatot a fejlesztési modelltől függően lehetőleg minél kisebb komponensek vagy egységek szintjére szorítsuk le. Ez azt jelenti, hogy minden elkészült komponensnek, inkrementális fejlesztés esetén pedig minden inkremensnek rendelkeznie kell a működésüket igazoló tesztekkel. A fejlesztés során az elkészült részegységek így önmagukban tesztelhetők lesznek, melyek pedig a hibák jobb felderíthetőségéhez vezetnek. Az elkészült komponensek integrálása során új funkciókkal bővül a rendszer. Minden integrációs lépés azonban további teszteket von maga után, nem szabad megelégedni a komponensek külön-külön működő tesztjeivel. Az integráció nem várt hatásokat eredményezhet, melyeket csak szisztematikus teszteléssel deríthetünk fel.

A következő ábra egy háromlépéses tesztelési folyamatot mutat be, ahol teszteljük a rendszer komponenseit, majd az integrált rendszert, és végeze­tül a teljes rendszert a megrendelő adataival.

15.1. ábra - A tesztelési folyamat

A tesztelési folyamat

A programban felderített hibákat természetesen ki kell javítani. Ez olyan következménnyel járhat, hogy a tesztelési folyamat egyéb szakaszait is meg kell ismételni. Ha a programkomponensekben található hibák az integrációs tesztelés alatt látnak napvilágot, akkor a folyamat iteratív, a későbbi szakaszokban nyert információk visszacsatolandók a folyamat korábbi szakaszaiba.

A tesztelési folyamat szakaszai:

  1. Komponens (vagy egység) tesztelése: az egyedi komponenseket tesztelni kell, és biztosítani kell tökéletes működésüket. Minden egyes komponenst az egyéb rendszerkomponensektől függetlenül kell tesztelni.

  2. Rendszer tesztelése: a komponensek integrált egysége alkotja a teljes rendszert. Ez a folyamat az alrendszerek és interfészeik közötti előre nem várt kölcsön­hatásokból adódó hibák megtalálásával foglalkozik. Ezen túl érinti a validációt is, vagyis hogy a rendszer eleget tesz-e a rendszer funkcionális és nemfunk­cionális követelményeinek és az eredendő rendszertulajdonságoknak.

  3. Átvételi tesztelés: ez a tesztelési folyamat legutolsó fázisa a rendszer használata előtt. A rendszert ilyenkor a megrendelő adataival kell tesztelni, amely olyan hiányosságokat vethet fel ami, más esetben nem derül ki.

Az átvételi tesztelést alfa-tesztelésnek is szokták nevezni. A megrendelésre készített rendszerek egy egyedülálló kliensnek készülnek. Az alfa-tesztelési fo­lyamatot addig kell folytatni, amíg a rendszerfejlesztő és a kliens egyet nem ért abban, hogy a leszállított rendszer a rendszerkövetelményeknek megfelelő.

Amikor egy rendszer, mint szoftvertermék piacra kerül, gyakran egy má­sik tesztelés is végbemegy, amelyet béta-tesztelésnek nevezünk. A béta-teszte­lés magában foglalja a rendszer számos potenciális felhasználójához történő le­szállítását, akikkel megegyezés történt a rendszer használatára, és ők jelentik a rendszerrel kapcsolatos problémáikat a rendszerfejlesztőknek. Ezáltal a rendszer valódi használatba kerül, és számos olyan hiba válik felfedezhetővé, amelye­ket a rendszer építői esetleg nem láthattak előre. Ezután a visszacsatolás után a rendszer módosítható és kiadható további béta-tesztelőknek, vagy akár általános használatra is.

15.1 .2 A dinamikusan tesztelés

A szoftvertesztelés, mint dinamikus V & V a gyakorlatban inkább alkalmazott technika. Ekkor a programot a valós adatokhoz hasonló adatokkal teszik próbára. A kimenetek eredményei lehetőséget adnak anomáliák, problémák feltárására. Ezen tesztelés két fajtája ismert:

  1. Hiányosságtesztelés: célja a program és a specifikációja között meglévő ellentmondások felderítése. Az ilyen teszteket a rendszer hiányosságainak feltárására tervezik, nem a valós működés szimulálására.

  2. Statisztikai (vagy validációs) tesztelés: a program teljesítményének és megbízhatóságának tesztelése valós körülményeket szimulálva. Annak megmutatása, hogy a szoftver megfelel-e a vásárlói igényeknek.

A dinamikus tesztelés folyamatának általános modellje látható következő ábrán.

15.2. ábra - A szoftvertesztelési folyamat modellje

A szoftvertesztelési folyamat modellje

A teszteset nem más, mint a teszthez szükséges inputok és a rendszertől várt outputok speci­fikációja. A tesztadatok kifejezetten a rendszer tesztelésére létrehozott inputok. A tesztadatok néha automatikusan generálhatók, az automatikus teszteset-generálás viszont általában nem lehetséges. A tesztek outputjait csak azok tudják előre megjósolni, akik értik, hogy a rendszernek mit kellene csinálnia.

Beszélhetünk kimerítő tesztelésről is, ahol az összes lehetséges program-végrehajtási szekven­ciát teszteljük. A gyakorlatban nem praktikus, ezért a tesztelésnek a lehetséges tesztesetek egy részhalmazán kell alapulnia. Erre irányelveket kell kidolgozni a szervezetnek, nem pedig a fejlesztőcsoportra hagyni.