A Computerworld legközelebbi rendezvénye gyakorlati példákból merítve hívja fel a figyelmet a szoftvertesztelés fontosságára és lehetőségeire.

A szoftvertesztelés témaköre bő, hiszen már a tesztelés fogalmát definiálni magában is nehéz. Ha maradunk a tág definíciónál, akkor a szoftver tesztelés az adott szoftver sorba rendezett bemeneti adatokkal való ellátását, s a kimenet vizsgálatát jelenti, feltéve, hogy bemeneti adatnak vesszük az adatokat és az egyéb felhasználói interakciókat is. Ha elfogadjuk ezt a definíciót, hibának azt nevezhetjük, ha adott bemeneti adatsorra a szoftver hibás kimeneti adatsort állít elő. Fontos leszögezni, hogy detektálható hibáról akkor beszélhetünk, ha annak ismerjük legalább egy bemeneti adatsorát, így szoftverről gyakorlatilag azt sosem jelenthetjük ki, hogy hibamentes, esetleg azt, hogy nem tartalmaz detektálható hibákat.

Hibakeresésnél fontos mérőszám még a tesztkészlet hibafedése, azaz az az arányszám, amely a tesztkészletünk által detektálható hibákat veti össze az összes, elvi számításon alapuló összes hibával. A mai szoftverek komplexitása miatt a teljes hibafedés, akárcsak a hibamentesség, elérhetetlen, a cél mindig a lehető legjobb közelítés, azaz olyan tesztkészletek kidolgozása, melyek a legkisebb befektetett energiával a lehető legnagyobb hibafedést valósítják meg.

A hibákat a fenti definíció alapján két nagy körre érdemes bontani, hiszen egyáltalán nem mindegy, hogy a szoftver milyen ok miatt nem állítja elő a kívánt kimeneti adatot: lehet, hogy azért, mert a szoftver terve, specifikációja nem volt megfelelő, így az üzleti igényeket nem helyesen valósítja meg; lehet azonban azért is (és a klasszikus "hibát", azaz "bug"-ot erre értjük), mert a szoftverfejlesztők vétettek hibát, és amúgy a specifikáció (vagy az üzleti szándék) világos és helyes volt.

Amikor tehát biztonsági hibákról beszélünk, akkor szinte kizárólag programozói hibára utalunk, és a fejlesztők/szoftvergyártók szeretik is elhallgatni a sokkal fájóbb, nehezebben javítható specifikációs elégtelenségből származó hibákat.

Funkcionális és strukturális tesztelés
A szoftverek tesztelésének módszerét két nagy csoportra érdemes bontani. Az egyik, a funkcionális, más néven "black box" tesztelés. Ekkor csak az elvárt funkciók helyes működését vizsgáljuk anélkül, hogy a rendszer felépítését, forráskódját vizsgálnánk.

A strukturális tesztelés sokkal mélyebb tesztelést tesz lehetővé: célja a szoftver felépítésének, struktúrájának vizsgálata. Ezt nevezzük "white box" tesztelésnek is, hiszen a teszt során a cél, hogy a szoftver elágazásait minél alaposabban be tudjuk járni, minél nagyobb méretű kódbázist tudjunk tesztelni.

A tesztelés során fontos, hogy gátat szabjunk annak a pszichológiai nyomásnak, hogy azt akarjuk bizonyítani: a szoftver ellátja a feladatát, vagy nincsen benne hiba. A teszt célja, hogy lehető legtöbb hibát megtaláljuk. Éppen ezért kívánatos, hogy a tesztelést és a fejlesztést ne ugyanaz a személy, jobb esetben ne ugyanaz a szervezet végezze, hiszen a tesztelőnek érdektelennek kell lennie a szoftver hibáival kapcsolatban. Emellett a teszteket ne csak az elvárt működésre, biztosan jó bemeneti-kimeneti adatokra végezzük, hanem vizsgáljuk a rendszer működését érvénytelen bemeneti adatokkal, azaz kivételes körülmények között is.

Határérték-analízis
A tesztelési tapasztalatok azt mutatják, hogy a rendszerek bemeneti érték-tartományának közepéből választott teszt-értékek (esetek) sokkal kisebb valószínűséggel hoznak elő hibákat, mint a határértékek szélén lévők, esetleg azon kívül választott elemek. Pontosan ezért érdemes és jóval hatékonyabb a bemenet határértékeivel tesztelni a rendszert, nagyobb adathalmazok esetén pedig az első és utolsó elemekre további figyelmet fordítani. A határérték-analízist nem csak bemeneti, hanem kimeneti értékekre is lehet tesztelni, azaz olyan bemeneti értékeket érdemes választani, melyeket a kimeneti skála széleire képződnek le. Akár határérték-analízissel, akár klasszikus teszteléssel dolgozzunk, ez a megközelítés magában nem képes ok-hatás analízist biztosítani, azaz a különböző tesztesetek bemenetét és kimenetét kombinálni.

Fontos tehát az alap tesztesetekből egy ok-hatás döntési gráfot vagy táblázatot képezni, azaz mikor a lehetséges bemeneti teszteket kombinálva teszteljük a lehetséges kimeneti értékeket. Az elvárt teszt-eseteket előre kombináljuk, s előre felvázoljuk az ezekre várt válaszokat. A teszt innentől tehát mechanikus, hiszen pontosan tudjuk, hogy milyen bemeneti kombinációkra milyen kimeneteket kell kapnunk.

Ha előállnak az alap- és összetett tesztjeink, hasznos lehet egy funkciófedési táblázatot készíteni, melyben jelöljük, hogy az egyes tesztesetek mely funkciók működését vizsgálják, validálják. A táblázatból már jól látszik, hogy mely teszteseteket kell végrehajtanunk ahhoz, hogy minél nagyobb fedést kapjunk, illetve az is látszik, ha egy-egy funkciót nem fedtünk le tesztesettel.

Teljesítmény és speciális funkcionális tesztek
Nem beszélünk elég gyakran a teljesítménytesztelésről, amely a szoftvertesztelés elengedhetetlen része. Nem kézenfekvő azonban, hogy miért és mikor van erre szükség, illetve milyen módon lehet ezt végrehajtani.

A HP Magyarország vezető tanácsadója, László István szerint a teljesítménytesztelés elengedhetetlen ahhoz, hogy ne kerüljön üzembe performancia problémákkal szoftververzió, hiszen az a legkritikusabb műveleteket is ellehetetlenítheti...

A cikk folytatásához kattints ide!

• 7
• Vista
• XP