A tesztelés célja a szoftverfejlesztésben a szoftver minőségének biztosítása. Ennek megfelelően a tesztelés módszertanának is elsődleges célja a szoftver minőség biztosításának segítése. Olyan tesztelési módszertant kell követni a szoftver élettartama, tehát a fejlesztése, bevezetése és üzemeltetése során, amelyik elősegíti, hogy az egyéb, a szoftverminőséget segítő eszközökkel együtt garantálni lehessen a szoftver jó minőségét, használhatóságát, hogy a szoftver segítsen az alkalmazó cégnek vagy intézménynek a céljai elérésében.
A szoftver minősége akkor jó, ha a szoftver képes a célját betölteni, és ennek megfelelően a szoftvert alkalmazó intézmény, vállalat intézményi, üzleti céljait a szoftvertől elvárt mértékben képes segíteni. Ez a minőségdefiníció egyrészről rendkívül általános, másrészről viszont pontosan meghatározza azt az értéket, amelyet a szoftvernek kell előállítani. Az általánosság miatt a fenti definíció direkt módon ugyan nem használható a tesztelések tervezése és módszertan kialakítása során, de minden más definíciónak, amely vagy amelyek a szoftver minőséget határozzák meg valamilyen aspektus szerint, összhangban kell lennie a fenti definícióval. Minden olyan kérdés, amelyik a szoftverminőséggel kapcsolatban felmerül akár konkrét, akár általános módszertani szinten olyan választ kell, hogy kapjon, amelyik a szoftverminőség általános definíciója szerinti szoftver használati cél elérését segíti.
Az általános definíció szerinti szoftverminőség ugyanazon szoftver esetében más és más lehet különböző felhasználóknál, különböző elvárások és szoftverhasználati célok esetében. Ha alacsony a szoftverrel szembeni elvárás, vagy más célra akarják használni a szoftvert akkor a minőség megítélése is más lesz. Ennek megfelelően a projektek során a szoftverhasználat céljait kell először definiálni, majd pedig azt, hogy milyen módon kell a projekt során ezen célok elérését mérni, tesztelni.
A szoftverminőség értékelésére vonatkozó általánosan elfogadott nemzetközi szabvány az ISO 9126. A szabvány célja, hogy a szoftverfejlesztési projektek során általánosan ismert emberi hibákból adódó minőségi hibákat segítsen felismerni, és kiküszöbölni. A szabvány a szoftverminőségre is egy modellel szolgál, amely modell hat kategóriára, és azon belül számos alkategóriára osztja azokat a tulajdonságokat, amelyeket figyelembe kell vagy lehet venni a szoftverminőség értékelése, és így a tesztel tervezése , végrehajtása és kiértékelése során.
A funkcionalitás olyan tulajdonságok halmaza, amelyek a szoftver működésének funkcióival kapcsolatosak, és amelyek szükségesek a szoftverrel szemben támasztott működési igények kielégítésére. A funkcionalitás témakörébe tartozó fogalmak.
A funkcionális megfelelés azt határozza meg, hogy a szoftver mennyire felel meg a specifikációnak. Ez aránylag jól mérhető, és definiált fogalom, ez az a minőségi elem, amelyet a funkcionális tesztekkel lehet mérni.
A megfelelőség, amely azt határozza meg, hogy a szoftver mennyire felel meg arra a célra, amire szánták. Bár ez a fogalom sokkal inkább szubjektív lehet, mint a megfelelés és nehezebben, vagy egyáltalán nem mérhető de sokkal közelebb áll a szoftverminőség általános definíciójához. Törekedni kell arra, hogy a megfelelés mérése során, elsősorban a mérés, azaz a funkcionális tesztek tervezésekor ne veszítse a tervező szem elől a megfelelőséget a megfeleléssel szemben.
A precizitás olyan fogalom, amely arról szól, hogy milyen mértékben, milyen pontosan felel meg a szoftver a követelményeknek.
Az együttműködés fogalmára akkor kell különösen gondot fordítani, amikor a szoftvernek együtt kell működnie más szoftver alkalmazásokkal. Ebben az esetben az egyes szoftveralkalmazások közötti adatcsere szabványos, vagy speciális (ú.n. proprietary) felületeken keresztül valósul meg. A az együttműködés vizsgálata a speciális felületek használata esetén mindenképpen szükséges, de szabványos felületek használata esetén is fontos lehet, ha műszaki lehetőség van a szabvány különböző módokon történő használatára, implementálására.
A biztonság olyan funkcionális fogalom, amely arról szól, hogy a szoftver milyen biztonsággal használható, illetve milyen veszélyeket jelenthez a szoftver használata. A szoftverminőség értékelése során a biztonság értékelése külön terület, amelyet biztonsági szakemberek bevonásával lehet végezni.
A megbízhatóság fogalma arról szól, hogy a szoftver mennyire stabilan működik, és milyen szinten adja azt a teljesítményt (beleértve a funkcionalitást), amelyik megfelel az elvárásoknak. A megbízhatóságot szokás mérni (tesztelni) mérési időszakra (beégetési tesztek), vagy speciális feltételek között (sokk teszt). A megbízhatóság témakörébe tartozó fogalmak a
fejlettség, amely arról szól, hogy a szoftver mennyire lett kifejlesztve, mennyire „fejlődött ki” az fejlesztés és a használat során. Várható, hogy egy szoftver az élettartama során az újabb verziók kiadásával egyre érettebbé válik, illetve nagyobb funkcióváltások során az értettség időlegesen csökken, majd ezt követően a hiba javító verziókkal az értettség, és ezzel a megbízhatóság növekszik.
visszaállási képesség arra jellemző, hogy a rendszer mennyire tud extrém, a működést vagy annak egy részét akadályozó külső körülmények elmúlását követően visszaállni a normál működésre. Általában az a kívánatos, hogy a szoftverrendszerek az extrém körülmények között se veszítsenek adatot, és az extrém körülmények elmúlását követően automatikusan álljanak vissza a normál működési módra. Ugyanakkor lehetnek olyan alkalmazások, amelyek esetében megengedhető vagy akár kötelező a manuális, emberi beavatkozást igénylő visszaállítás a normál működési módra. Ennek oka lehet a túl magas, és az előnyöket el nem értő költség, amelyet az automatikus visszaállás kifejlesztése követelne meg, vagy biztonsági megfontolások, amelyek csak azt követően engedik meg a normál üzemre való visszaállást, amikor az üzemeltetés megbizonyosodott arról, hogy az extrém körülmények nem csökkentették a rendszer biztonságát.
hibatűrés azt jellemzi, hogy a rendszer mennyire marad működőképes egy vagy több elem meghibásodása esetén. Ez különösen fontos olyan esetben, amikor a működés kiesése komoly hátrányt jelent a szervezet céljainak folyamatos elérése érdekében. Extrém példák olyan rendszerek, amelyek személyek épségének, egészségének védelmét üzemeltetik, tipikusan beépülő gépjármű, veszélyes üzemi és egészségügyi rendszerek. A hibatűrés vizsgálata elvi vizsgálattal és hibák előidézésével teszteléssel is történik.
A használhatóság arra jellemző, hogy a rendszert mennyire könnyű használni, mennyi energiát kell a használónak belefektetni a rendszer használatába. A használhatóság alacsony szintje nem csak a használati költségeket növeli, hanem egy bizonyos szint alatt növeli a hiba lehetőségeket, és így kihathat a szoftveralkalmazás biztonságára, és megfelelőségére is. A használhatóság témakörébe olyan fogalmak tartoznak, mint a
tanulhatóság, amely arra jellemző, hogy a rendszer kezelését, használatát mennyire nehéz, vagy éppen könnyű megtanulni.
érthetőség a tanulhatósággal szoros összefüggésben arról szól, hogy mennyire érthető a rendszer működése. Értelemszerűen egy érthetően működő rendszer megtanulása is könnyebb.
üzemeltethetőség fogalma azt határozza meg, hogy mennyi energiát igényel a rendszer üzemeltetése, használata. Ez a tanulhatóság és az érthetőség mellett olyan tényezőket is figyelembe vesz, mint a környezet kialakítása, napi karbantartási igénye.
A hatékonyság a rendszer által nyújtott teljesítmény, és az eközben felhasznált erőforrások közötti arányt határozza meg. A hatékonyságot olyan erőforrások mentén érdemes megvizsgálni, amelyek költsége szignifikáns, és amelyek gazdasági és/vagy műszaki okok miatt korlátozottak. Így tipikusan a háttértárak mérete, memória és processzor használat, de ebbe a témakörbe tartozhatnak olyan erőforrások is, mint üzemeltető személyzettől igényelt karbantartási munkák mennyisége. A hatékonyság vizsgálata során két területet kell mindenképpen vizsgálni.
Az egyik az erőforrások használata
A másik az időszükséglet.
Az időszükséglet vizsgálata azért különül el a többi erőforrás felhasználásától, mert az idő, mint erőforrás speciális. Míg diszk terület, memória és processzorkapacitás bővítése elvileg lehetséges az időnél ez nem képzelhető el. Tipikusan például offline, tehát nem üzem közbeni mentési folyamatoknak üzemszünet alatt, általában hétvégén, vagy estétől reggelig le kell futniuk.
A karbantarthatóság arra jellemző, hogy a szoftveralkalmazás mennyire módosítható, mennyi energiát kell egy módosításhoz a munkába fektetni. Ezen belül meg szokták említeni a szoftver
stabilitását, amelyik arra jellemző, hogy egy szükséges módosítás a szoftver kódjában mennyire módosít olyan funkciókat, amelyek a módosított résztől távol vannak (nem keverendő össze a rendszer üzemeltetési stabilitásával). Amennyiben a rendszer összetett és nem lett a belső struktúrája megfelelően megtervezve, nem modulokból áll amelyek jól definiált belső felületeken keresztül érik el egymás szolgáltatásait, akkor a szoftver stabilitása alacsony lesz, egy kódrészlet megváltoztatása olyan funkciók hibáit is előidézhető, amely funkciók látszólag nem is függnek a módosított kódtól.
analizálhatóság egy olyan fogalom, ami arra jellemző, hogy a szoftvert mennyire könnyű, vagy éppen nehéz megérteni, vizsgálni. A szoftverkód vizsgálata szükséges minden olyan esetben, amikor valamilyen változtatást kell végrehajtani a programon, legyen az új funkció bevezetése, vagy hiba javítása. A kód elemzése nélkül csak az a személy tudja a kódot módosítani, aki azt készített (és még nem felejtette el). Gyakorlatilag minden kódmódosítás egyik előkészítő lépése a kód analízise, még akkor is ha ez nem különül el láthatóan a módosítás folyamatában.
változtathatóság arra jellemző, hogy mennyire könnyű vagy éppen nehéz a kódot változtatni. Ez a tulajdonság szorosan összefügg a stabilitás és az analizálhatóság kérdésével, hiszen ha azok rosszak, akkor a kód változtathatósága is rossz.
tesztelhetőség arra jellemző, hogy a szoftver illetve az egyes kódrészek mennyire könnyen tesztelhetőek. A szoftverek működőképességét a használatbavétel előtt csak a teszteléssel lehet bizonyítani, ezért minden kódnak tesztelhetőnek kell lennie. Elvileg nincs olyan kód, amelyet ne lehetne tesztelni, hiszen (elvileg) akár az egész éles környezetet is fel lehet építeni még egyszer tesztkörnyezetként, és ha máshol nem, de abban a környezetben a programnak mindenképpen futnia kell. A tesztelhetőség kérdése igazából az, hogy a szoftverkód tesztelhető-e elfogadható költségekkel. Ennek megfelelően a kódokat gyakran olyan programozási struktúrák alkalmazásával kell elkészíteni, amelyek nem feltétlenül a használhatóságot, hanem a könnyebb (értsd olcsóbb) tesztelhetőséget segítik.
A hordozhatóság az utolsó nagy témakör a szoftverminőség fogalmi rendszerében. Ez a fogalom arra jellemző, hogy mennyire könnyű a rendszert installálni, lecserélni, hozzáigazítani a környezethez. Ebben a témakörben a szokásos felmerülő fogalmak a
installálhatóság, ami arra jellemző, hogy mennyi energiát, munkát (költséget) igényel a rendszer üzembe helyezése megfelelő hardver és hálózati környezetben.
lecserélhetőség arra jellemző, hogy a szoftver mennyire könnyen cserélhető le más rendszerre, vagy a rendszer egy újabb verziójára. Ez azért nehéz fogalom, mert általában a lecserélhetőségbe bele szoktuk érteni a másik, bevezetendő rendszer tulajdonságait is. Amikor azonban egy szoftver minőségéről beszélünk, akkor a lecserélhetőségről a helyette alkalmazandó új szoftvertől függetlenül kell gondolnunk, és szét kell választanunk a cserélési folyamatban azokat a tulajdonságokat, amelyek a kiváltandó rendszer lecserélhetőségére jellemzőek a bevezetendő rendszer installálhatóságára való jellemzőktől. A lecserélhetőségre jellemző tipikus tulajdonság az adatok export képessége, például képes-e a rendszer az adatokat szabványos (pl. XML) formátumban exportálni, hogy utána az egyszerű segédprogramokkal betölthető legyen az új rendszerbe.
adaptálhatóság arra jellemző, hogy a rendszert mennyire könnyű hozzáigazítani megváltozó körülményekhez. Ez jelenthet műszaki körülményt, például másik adatbázis-kezelővel kívánjuk használni a rendszert, de jelenthet működési igény változást is, például jogszabály követés, amely esetben előfordulhat, hogy a rendszer szoftverkódját is módosítani kell.
Hordozhatósági megfelelés, ami nagyon hasonló a funkcionális megfelelés fogalmának, de itt elsősorban azt jelenti, hogy a szoftver mennyire felel meg azoknak a nem feltétlenül, sőt elsősorban nem funkcionális követelményeknek, amelyek a hordozhatóságot segítik elő. Ilyen tipikusan a használt adatbázis-kezelő, alkalmazás szerver, middleware rendszerek szabványoktól eltérő specialitásainak elkerülése.
A tesztelés célja, hogy segítse a szoftverminőség kontrolljának egyes részeit, összetevőit. A tesztelés önmagában nem elegendő a szoftverminőség garantálásához. Nem lesz jobb egy szoftver ha csak teszteljük, és nem javítjuk ki a hibákat. Ugyanakkor vannak olyan szoftverminőségi mutatók is, amelyek nem javíthatóak teszteléssel.
A tesztelés feladata kettős. Egyik feladata, hogy bizonyítsa a szoftver minőségét, a másik, hogy segítse a szoftverminőség javítását (tipikusan a hibakeresést). Ezek a feladatok az szoftverfejlesztés során a tervezéstől az üzemszerű működésig tartanak. A fejlesztés korai fázisában a hibakeresésen, mint fő feladaton van a hangsúly, és kevésbé a helyes működés bizonyításán. A szoftver fejlődése során a fontosság folyamatosan kerül át a hibakeresésről a helyes működés bizonyítására, és az átadási fázisra ez a feladat súlyozás teljesen megfordul, és az ügyfél általi átvételi tesztek során szinte nem is számít, hogy az egyes tesztek mennyire segítik a szoftverben esetleg még maradt hibák megkeresését, azon túlmenően, hogy létüket demonstrálhatóan bizonyítják, ha vannak hibák.
Ezzel párhuzamosan a tesztelés elvégzése, mint feladat is átkerül a fejlesztő, szállító cégtől az átvevő, üzemeltető céghez, intézményhez. A korai fázisban a tesztelés a szállító feladata, azt saját hatáskörben, saját felelősségére és rizikójára végzi. Ebben a fázisban a megrendelő nem is vesz részt a tesztelésben, és nem is érintett ezekben a tesztekben azon túlmenően, hogy bizonyos tesztelési módszertant megkövetelhet a szállítótól, mint általános rezsimet a szállító általános minőségének ellenőrzésére.
A szállítás során az egyes fázisokban a tesztelés folyamatosan átkerül a megrendelő felelősségi körébe. Ez teljesen összhangban van az egyes tesztek céljával: minőség bizonyítás és hibakeresés. A szállító számára direkt módon nem érték a szoftver minőségnek a bizonyítása, csak annyiban, amennyiben az érdekei a megrendelő érdekein keresztül realizálódnak. A szállító számára a tesztelés elsősorban hibakeresést segítő eszköz. A megrendelő ugyanakkor nem érdekelt a hibakeresésben, nem is ért hozzá feltétlenül, és nem a feladata és általában az eszközei sincsenek meg hozzá. A megrendelő számára a tesztelésben az a fontos, hogy az bizonyítja számára, hogy a szoftver megfelelő minőségű, és így a tesztelés a megrendelő számára csökkenti az szoftver esetleges minőségi hiányosságaiból adódó üzleti kockázatot.
Az átvételi teszt — mint az egyik utolsó teszt a szállítási fázisban és amely lezárja az elfogadás, és teljesítési fázist — teljes felelőssége az megrendelőé, még akkor is ha annak kivitelezésében a szállító segíti szakmai tudásával, vagy éppen a rendszer ismeretével a megrendelőt. Azonban ebben az esetben is pontosan tudatában kell lennie a megrendelő képviselőinek, hogy a megrendelő és a szállító ebben a fázisban a tesztelés szempontjából részben ellenérdekelt. A szállító érdeke ebben a fázisban a tesztek helyes lefutása, hiszen ez az ami a gazdasági célját, a szoftverszállítás teljesítését segíti, ekkor már függetlenül a szoftver minőségétől. A szállító érdeke azonban a szoftver minőségének biztosítása, és a szoftver átvétel megtagadása, ha a szoftver nem éri el azt a minőségi szintet, amelyet a megrendelő megkövetel a szállítótól a szerződéses keretek között.
Emiatt a megrendelő cég vagy intézmény nem ruházhatja át a tesztelés késői fázisait a szállítóra. A tesztelés felelőssége még akkor is a megrendelőn marad, ha az átvételi tesztek tervezését és technikai kivitelezését a szállítótól független harmadik, szakmailag kompetens félre bízza.
Ahogyan a tesztelés célja a fázisok során eltolódik a hibakeresés felől a bizonyítás felé, ennek megfelelően a tesztelés technológiája, és kivitelezése is eltolódik a technikai, fejlesztői szintről egyre inkább a felhasználói szint felé.
Természetesen a tesztek minden fázisban technikailag megalapozottak kellenek, hogy legyenek, különben nem képesek betölteni a feladatukat, de a fejlesztés korai szakaszában a tesztek megjelenés és a tesztek eredményének a prezentációja részletes és technikai. A fejlesztés későbbi szakaszában a tesztek eredménye átlátható, olvasható, egyszerűen értelmezhető kell, hogy legyen. Amíg a hibakeresés a tesztelés fő feladata, addig a teszt eredményének minden olyan adatot tartalmaznia kell, amelyik a hibakeresést segíti. Ezért a tesztelés eredménye ebben a fázisban gyakran szöveges naplófájlok formájában jelenik meg, amelyet a fejlesztők használnak információ forrásként. A tesztelés későbbi fázisában ez a teszteredmény forma használhatatlan lenne. Annak eldöntése, hogy egy teszt hibátlanul lefutott, és így bizonyítja-e a szoftver minőségének azt a szeletét, amelyet bizonyítani hivatott nem követelheti meg hosszú, és könnyen „elnézhető” naplófájlok vizsgálatát. A teszteket úgy kell kivitelezni, hogy azok eredményének értelmezése, magyarán annak eldöntése, hogy a teszt sikeres volt-e vagy sem szinte emberi hibalehetőség nélkül elvégezhető legyen. Így tipikusan egy átvételi teszt futtatási eredménye tipikusan egy „teszt sikeres” vagy „hibás teszt” kiírás, vagy zöld – piros jel egy eredmény lapon.
A teszteket úgy kell elkészíteni, hogy megfeleljenek a konkrét teszt céljának. Ennek elérésére a teszteknek
hatásos
hatékonynak
költséghatékonynak
gyorsnak
definiáltnak
értékelhetőnek
reprodukálhatónak
kell lenniük.
Amikor egy tesztet megvizsgálunk, akkor hatásos ha a teszt sikeres futtatása nagy valószínűséggel bizonyítja, hogy a tesztelt minőségi kritérium a szoftver alkalmazása során is megfelelő lesz. Ha például tesztelünk egy funkciót, akkor nem teszteljük végig az összes létező bemeneti adattal a teszt rendszert, mert ez fizikai képtelenség. A tesztünk mégis lehet hatásos, ha olyan tesztadat-sort használunk, amelyik tartalmaz mintát a legfontosabb esetekre, és amelyek alapján joggal köveztethetünk arra, hogy a szoftver minden bemenő adatra megfelelőképpen fog viselkedni.
A teszt akkor hatékony, ha nem csak hatásos, de nem fogyaszt feleslegesen erőforrásokat. A fenti funkcionális teszt példánál maradva a teszt nem hatékony ha több olyan bemenettel is teszteli a szoftver működését, amelyek esetében az egyik lefutása esetén nem marad kétség, hogy a többivel is működni fog a rendszer.
A teszt költséghatékonysága azért is fontos, mert sokszor a tesztelés igényeit figyelembe nem vevő tervezés olyan szoftver eredményez, amelyiknek a tesztelése csak nagyon nagy költséggel végezhető el, és emiatt sokszor el is marad. Ennek a következménye, hogy a szoftver hibái csak a szállítási fázist követően a jótállási fázisban derülnek ki, amikor egyrészről a szoftver már üzemben van és így minden minőségi deficit üzleti hátrányt jelent a megrendelőnek; másrészről pedig ebben a fázisban a megrendelő jóval kisebb érdekérvényesítő erővel rendelkezik a szállítóval szemben.
A szoftverrendszereket úgy kell megtervezni, és kivitelezni, hogy azok a szoftver élettartama során, tehát nem csak a szállítási fázis lezárásáig hanem azt követően is költséghatékonyan tesztelhetők legyenek.
A költséghatékonyságnál nem csak a tényleges kiadásokat kell figyelembe venni, hanem azokat a költségeket is, amelyek sokszor nem kerülnek pénzbeli kifejezésre. Ilyen tipikusan a tesztelésre fordított idő, a szükséges koncentráció, a kiértékelés ideje és hibázási lehetőség a kiértékelés során.
A teszt sebessége szorosan összefügg a hatékonysággal és a költséghatékonysággal. Az, hogy egy teszt elég gyors-e beleérthető az előző kettőbe, de az idő, mint speciális, nem többszörözhető erőforrás, szükségessé teszi, hogy a teszt sebességét mindenképpen, mint külön kritériumot vegyük figyelembe.
A tesztnek definiáltnak kell lennie. Ez azt jelenti, hogy pontosan elő kell írni a teszt futtatásának kritériumait, az előfeltételeket, hogy hogyan kell a tesztet végrehajtani, milyen módon kell a teszt eredményét begyűjteni és az eredményt értékelni. Gyakori hiba, hogy nincsenek definiálva a teszt előfeltételei, és emiatt a teszt reprodukálhatósága csökken. Más esetekben a teszt eredményeinek begyűjtése nincs definiálva vagy az eredmények értékelése és e miatt a teszt sikeressége vagy sikertelensége egyes esetekben definiálatlan.
A teszt eredményeknek értékelhetőnek kell lenniük. Ezt a definiáltsággal összefüggő fogalmat attól függetlenül is ki kell emelni, mert nem elegendő, hogy a teszt eredménye definiált, ha az nem értékelhető. Definiált például ha egy teszt eredménye egy megabájt méretű bináris fájl, amely nem tartalmazhat egy meghatározott szekvenciát. Ezt az eredményt azonban további segéd programok nélkül nem tudja a teszt végrehajtója értékelni, ez az eredmény ilyen módon nem értékelhető. A konkrét esetben a példa azzá tehető, ha a kiértékelő program használatát is a teszt részévé tesszük, és definiáljuk, hogy mely programmal, és milyen módon kell elemezni a keletkezett bináris fájl.
Végül és nem utolsó sorban a teszteknek reprodukálhatóaknak kell lenniük. A tesztelés, mint minőség bizonyítási eszköz semmit nem ér ha néha működik egy teszt eset, néha meg nem. A reprodukálhatóság nagymértékben elősegíthető ha a teszt hatásos, definiált és értékelhető, de nem garantálja a teszt reprodukálhatóságát. Lehetnek a tesztelt működés során olyan külső körülmények, üzemelési paraméterek, amelyek változnak a tesztfuttatások között és amelyek hatással vannak a teszt eredményre, de nem a teszt bemenő paraméterei. Ezeket a hatásokat a tesztek elkészítése során amennyire lehet ki kell küszöbölni. Amennyiben a teszt nem reprodukálható, különböző időben látszólag azonos körülmények között a teszt különböző eredményeket ad, akkor az általában instabil, hibás működésre utal, és a szoftverminőségi szint bizonyítására alkalmatlan.
A gyakorlatban a szoftverfejlesztés élettartama során különböző teszteket szoktak használni. Ezek a tesztek sokszor egymásra épülnek, és amennyiben valamelyik teszt hibát tár fel, meg kell vizsgálni a hiba kijavítását követően, vagy annak során, hogy kell-e valamilyen tesztet készíteni a hiba ismételt előfordulásnak megakadályozására az alsóbb szinteken.
Ennek az az oka, hogy egy hiba nem csak egyszer fordulhat elő. Annak ellenére, hogy a szoftver kódban egy kijavított hibás kód megszüntet egy hibajelenséget, nem biztos, hogy a hibát is kiküszöbölte. Elvileg is csak annyit lehet állítani, hogy bizonyos teszt adatokra, bizonyos inputra már nem jelenik meg a hiba. Ugyanakkor előfordulhat, hogy más adatokra, vagy a kód egy másik részének megváltoztatása esetén a hiba ismételten jelentkezik. Ez tipikusan abban az esetben fordul elő, amikor a hiba kijavítása nem kellő körültekintéssel, és kellően általánosan történik meg.
Mivel egy hiba kijavítása annál olcsóbb, minél alacsonyabb szintű teszt során derül ki a hiba, ezért érdemes a kijavított hibákra is minden szinten teszteket készíteni, kiegészíteni a meglevő teszt eseteket.
Az egymás után következő tesztek a fejlesztési fázisoknak megfelelően egyre nagyobb részeket tesztelnek, míg végül a felhasználói elfogadási teszt már az egész rendszert teszteli. Ennek megfelelően azok a tesztek, amelyek csak egy részt tesztelnek, a többi, a teszt által nem vizsgált részt a tesztelési környezettel helyettesítik, szakszóval mock-olják a környezetet. Ebből a szempontból is érdemes megkülönböztetni a különböző teszteket, az alapján, hogy a tesztelt részek és a mock környezet milyen felületen kapcsolódik egymáshoz. Amennyiben a megrendelő, vagy megbízott technikai szakemberei részt vesznek a felhasználói elfogadási tesztet megelőző teszteken is, nagyon fontos tisztázni, hogy a mock környezetek közül mi az amit a szállító biztosít, és mi az amit a megrendelői oldalnak kell nyújtania. Amennyiben a szállító biztosítja a mock környezetet vagy annak egy részét a megrendelői oldalnak különös gondot kell fordítania arra, hogy meggyőződjön a mock környezet megfelelőségéről.
A fejlesztési és átadási fázisoknak megfelelően szokásos tesztek:
fejlesztési unit tesztek,
modul tesztek,
integrációs tesztek,
funkcionális tesztek,
terheléses tesztek,
shock tesztek,
tartóssági teszt,
felhasználói elfogadási tesztek (UAT),
üzembehelyezési teszt.
A unit tesztek a fejlesztési unitokat tesztelik, és ezeket a teszteket a megfelelő iparági gyakorlat szerint a fejlesztők készítik el az egyes unitok fejlesztése során. Egy unit tipikusan lehet egy Java class, amihez általában egy teszt class-t készítenek, amelyik futtatása során teszteli a Java class-t. A unit tesztek futtatása általában minden fordítás során megtörténik, és a fordításvezérlő rendszerek többnyire a szintaktikai hibával egyenértékűnek tekintik, ha egy unit teszt nem fut le sikeresen.
Ideális esetben az egyes unit tesztek függetlenek egymástól. Az éles futtatás során történő egymástól való függőséget mock osztályokkal valósítják meg a unit tesztek, amelyek megfelelő, külső fél által fejlesztett mock könyvtárak segítségével hozhatók létre.
A unit teszt értelme, hogy az egyes unitokat egyenként, egymástól függetlenül lehet tesztelni, és ezzel bizonyítani, hogy az egyes részek megfelelően működnek. Sokszor a unit teszt kódja a fejlesztői dokumentáció része, amely természetéből adódóan abszolút precízen írja le a unit működését.
A unit tesztek biztonságossá teszik a unitok módosítását, például a nagyobb teljesítmény kedvéért. A fordítási időben lefutó unit teszt azonnal megmutatja, ha a módosított kód nem felel meg a korábban megírt unit tesztnek, és gyakorlatilag nem sikerül a fordítás, amíg a kód nem megfelelő (regressziós teszt).
A unit tesztek esetében gyakran merül fel a kód lefedettség fogalma, ami azt jelenti, hogy az adott unit minden egyes programsora meghívásra került-e a unit teszt futtatása során. Nem feltétlenül követelmény még egy szigorúan szabályzott fejlesztői környezetben sem a teljes lefedettség, mert vannak olyan kódok, amelyeket nem érdemes tesztelni. Ilyenek tipikusan a fejlesztői környezet által automatikusan generált setter és getter metódusok. Ugyanakkor a teljes lefedettség sem garantálja a kód hibátlanságát. Ha minden egyes kódsor legalább egyszer futott a unit teszt alatt, az még nem garantálja, hogy minden kódsor a lehetséges lefutások minden kombinációjában, a kód összes lehetséges lefutási útvonalán tesztelve lett, és még kevésbé, hogy az összes lehetséges adattal lett tesztelve, ez triviális programok kivételével ugyanis elvileg sem lehetséges.
Unit tesztet akkor tekintünk megfelelőnek, ha a unit minden dokumentált funkcióját teszteli minden lehetséges bemeneti adatcsoporttal. (Egy adatcsoportba tartozónak tekintünk két bemeneti adathalmazt, ha az várható, hogy az egyik helyes kezelése esetén a unit a másikkal sem fog hibásan futni.) Ennek megfelelően a unit teszt elkészítéséhez valójában nem is szükséges a unit kódjának ismerete, csak a funkciók ismerete, és néha alkalmazott fejlesztési szabály az is, hogy a unit tesztet a unit kódjának megírása előtt készítik el. Ennek következtében nem is a unit tesztre, hanem a kódra lehet jellemző, ha van olyan lényeges kódsor, amit a unit teszt nem fed le nem használ. Az ilyen kódsor valószínűleg szükségtelen.
A unit teszt szállítási szempontból a forráskód része, és a megrendelő akkor követelheti meg a szállítótól a unit tesztek kódjainak szállítását, ha a forráskód átadása is a szállítás része. Általában a unit teszteket a megrendelői oldalon nem ellenőrzik sem tartalmilag, sem pedig teszt futtatás során. A unit tesztek meglétét és minőségét a megrendelői oldalnak legfeljebb szúrópróba szerűen kell ellenőriznie. Ezzel a megrendelő nem a kódot, hanem a szállító a minőségét ellenőrzi.
A modul teszteket a QA szállító a szállított, és tesztelésre készre jelentett modulokon végzi, általában mint fekete doboz teszteket. Modulnak olyan egységeket tekintünk ebben az esetben, amelyek üzemeltetési szempontból külön egységként jelennek meg. A felhasználó számára gyakran nem jelennek meg az egyes modulok, nem feltétlenül kell ismernie az egyes modulokat és azok egyedi funkcionalitását. Lehetnek olyan modulok, amelyek nem is biztosítanak egyáltalán végfelhasználói funkcionalitást, csupán más modulok veszik igénybe az általuk nyújtott szolgáltatásokat.
A modulokra jellemző, hogy jól definiált, általában szabványos felületeken keresztül kommunikálnak egymással. A modultesztelés során az ezeken a felületeken keresztül elért vagy nyújtott szolgáltatásokat mock modulokkal helyettesíti a tesztelő rendszer. Szabványos felületek esetében erre kész eszközök állnak általában rendelkezésre, saját felületek esetében a teszt mock modulokat ki kell fejleszteni. Ez a fejlesztés a QA folyamatban külön költséget jelenthet amennyiben a szállító nem szállítja a mock modulokat. Mivel a külön fejlesztett mock modulok maguk is lehetnek a tesztelés során hiba források ezért különösen fontos tesztelési szempontból is a szabványos felületek használata.
Különösen érdekes azoknak a moduloknak a tesztelése, amelyek humán felületen keresztül is kommunikálnak, azaz kezelői felületük is van. Ezek a felületek általában nem annyira jól definiáltak, mint a gépi felületek. Ennek az oka, hogy az ember, mint a felületet használó „modul” intelligens, és egészen más módon értelmez egy felületet, mint egy gép. Egy felhasználói felület lehet úgy is jól használható, hogy géppel nehezen tesztelhető, és lehet úgy is nehezen használható, hogy közben pontos definíció szerint épül fel.
A felhasználói felületek gépi teszteléséhez léteznek különböző módszerek, amelyek a tesztelés végrehajtása során az emberi viselkedést (begépelt karakterek, egérrel történő kattintások) ismétlik el, és így a tesztek regressziós futtatása automatizálható. Sok esetben azonban az ilyen tesztek fals hibát jeleznek, például egy megnyomható gomb arrébb kerül, és az automatizált teszt a gomb mellé kattint mert nem veszi észre automatikusan a változást úgy, ahogy egy ember észrevenné. Emiatt az ilyen felületek tesztelése teljes mértékben nem automatizálható.
A tesztek során nem csak a garantált, „szállított” külső felületeket teszteljük, hanem az egyes modulokat külön, egymástól szeparáltan vizsgáljuk, a másik, éppen nem tesztelt modul által nyújtott interfészeket pedig mock szolgáltatásokkal biztosítjuk. Ezzel nem csak a publikus interfészeket teszteli az integrációs teszt, hanem azokat az interfészeket is, amelyekkel az egyes modulok egymás között kommunikálnak. Ez lehetővé teszi a modulok valódi modularitását és kiválthatóságát a későbbiekben a definiált és tesztelt interfészeken keresztül.
Az integrációs tesztek során a már összekapcsolt modulok működését teszteljük. Ilyenkor már nem az egyes modulok működését vizsgáljuk, hanem azt, hogy az egyes modulok valóban együtt tudnak-e egymással működni, integrálódnak-e. Elvileg ha a modul tesztek nem találtak hibát, akkor az integrációs teszteknek is sikerülniük kell, feltéve, hogy a tesztelő mock implementációk, amelyek a modul tesztek során a nem tesztelt modulok által nyújtott felületeket implementálják tökéletesek és minden szempontból megfelelnek a valós környezetnek. Ez azonban a gyakorlatban nm biztosítható, és elvileg sem cél olyan mock modulokat készíteni, amelyek 100%-ig emulálják a modulok viselkedését.
Az integrációs tesztek során kiderülő hibák olyan hibák, amelyek egyben jelzik a modul tesztek valamilyen hibáját is, vagy olyan hibák, amelyek még korábban elkövetett terezési hibára utalnak. Az integrációs tesztek során feltárt hibák esetében mindig meg kell vizsgálni, hogy az adott hiba miért nem derült ki a modul tesztelés során, és vagy javítani kell a modulteszten új teszteset felvételével, vagy valamelyik mock modul kódját, vagy konfigurációját kell módosítani a hiba alapján, és megismételni a modultesztet, ellenőrizve, hogy a módosított formában felfedezi-e a hibát.
Az integrációs tesztek során kiderülő hibák zöme konfigurációs hiba. Ebben az esetben a modulok összekapcsolásának paraméterei a nem megfelelőek. Az ilyen hiba kijavítása nem a kódban történik, hanem a teszt rendszere konfigurációjában, és mint ilyen nem is tekinthető a rendszer hibájának. Amennyiben az derül ki, hogy a hiba a rendszer kódjában van, akkor vissza kell lépni a kód kijavításához, a unit tesztek, modul tesztek kibővítéséhez és ezt követően lehet megismételni az integrációs teszteket.
Ezek a visszalépések adminisztráció és időigényesek. Az adminisztráció célja az, hogy minden tesztelés, és kód módosítás követhető legyen, és így a később kiderülő hibák esetén tudni lehessen, hogy egy új hibáról van-e szó, ami egyszer már fellépett és javítva lett, de valamilyen oknál fogva ismételten fellépett, vagy egyszerűen a hibát még nem javított ki fejlesztő. Ez könnyen előfordulhat nagyobb léptékű fejlesztés során, amikor a modul tesztek során több száz hiba derül ki. Sok esetben az iteratív tesztelési folyamatban nem vár a projekt addig, amíg a modul tesztben feltárt összes hibát kijavítják, hanem elkezdik az integrációs teszteket tudva, hogy lesznek olyan hibák, amelyek definíció szerint a modul tesztekből öröklődnek, és meg kell, hogy jelenjenek.
Az átlapolódó tesztelési fázisok oka, hogy ebben a projekt struktúrában gyorsabban lehet előre haladni, az ismételt tesztelések extra költségén. A tesztek végrehajtása azonban, főleg ha automatizált tesztekről van szó, nem olyan magas, mint a tesztek kialakításának költsége, ezért általában a projektek során az egyes teszt fázisok átlapolódnak.
Az integrációs tesztek sikeres lefutása esetén bizonyítják, hogy az egyes modulok képesek együttműködni. Ez különösen abban az esetben fontos az egész rendszer tesztelése előtt, ha a különböző modulokat különböző szállítók szállítják. Az integrációs teszt ebben az esetben ki kell, hogy egészüljön olyan monitoringgal és elemzési lehetőséggel, amelyik azt tudja vizsgálni, hogy az egyes modulok közötti felületen milyen kommunikáció zajlik. Ebben az esetben ugyanis nagyon fontos, hogy a két modul közötti integráció hiánya melyik modul nem megfelelő működése miatt történik, és ezt a tesztnek műszakilag ki kell tudnia mutatnia vitathatatlanul.
A modulok kapcsolódási felületeinek ellenőrzése hálózati figyelő eszközökkel, vagy a kommunikációt továbbító és naplózó egyszerű proxy alkalmazásokkal lehetséges. Ilyen jellegű forgalom rögzítés az integrációs teszt során egyébként is ajánlott, akkor is ha a teszt értékelésének nem része a naplófájlok elemzése. Ezek akkor lehetnek hasznosak, ha egy későbbi teszt során valamilyen hiba a felszínre kerül, következtetni lehet a hiba okára és helyére ha kideríthető a naplófájlok alapján, hogy a hiba már korábban is meg volt, csak nem vette észre a teszt, vagy pedig a fejlesztések során keletkezett.
A funkcionális tesztek a legismertebb tesztek. Azt hivatottak eldönteni, hogy a szállított szoftver rendszer helyesen végzi-e a funkcióit, amelyeket elvárnak tőle. Tulajdonképpen a unit tesztek, a modul és az integrációs tesztek is funkcionális tesztek, de céljuk az egyedi unit, modul, illetve a modulok kapcsolódásának a tesztelése az integrációs teszt, és nem azon funkcióknak a tesztelése amelyek a megrendelő számára fontosak. Úgy is megkülönböztethető a unit, modul és integrációs teszt a funkcionális teszttől, hogy bár az első három is funkciókat tesztel ezek a funkciók elsősorban belső funkciók és nem azok, amelyek a felhasználó számára is direkt módon érdekesek. A felhasználó számára fontos, úgynevezett felhasználói funkciók a belső funkciókra épülnek, így ezek működése is alapvető, de nem a funkcionális teszt vizsgálatának direkt tárgyai.
A funkcionális tesztek lehetnek manuális és automatizált tesztek. Mint minden tesztnek tervezettnek kell lennie, és nem ad-hoc jellegűnek. A funkcionális tesztek elvégzése előtt pontosan meg kell határozni, hogy milyen teszt esetek lesznek, és definiálni kell az egyes teszt eseteket. A teszt esetek definiálása során nem csak műszaki, hanem projekt menedzsment paramétereket is figyelembe kell venni. Így tipikusan a funkcionális teszt előkészítése során a tervben a következőket kell rögzíteni minden egyes teszt esetre:
funkció
súly
előfeltételek
előkészítés
végrehajtás
dokumentálás
értékelés
A funkció mondja meg, hogy a szoftver rendszer melyik funkciója az, amit a teszt vizsgál. Egy teszt leltár során világosan látni kell, hogy nem maradt-e ki olyan funkció amelyet a megrendelő a szállítótól követel, és amelyet teszt nem vizsgál. Amennyiben teszt nem bizonyítja egy funkció működőképességét a funkciót nem lehet biztonsággal működőnek, meglevőnek tekinteni.
A teszt súlya adja meg, hogy mennyire fontos a teszt sikeres lefutása. Lehetnek olyan teszt esetek, amelyek sikertelen lefutása valamely funkció hiányát, vagy hiányosságát jelzik, de a funkció hiánya, vagy hiányossága nem olyan súlyos, hogy emiatt a projekt ne léphessen a következő fázisba. Tipikusan ilyenek a felhasználói felület ú.n. kozmetikai hibái, amelyek a használhatóságot nem csökkentik, de ergonómiai hatásuk hosszabb távon lehet. Ilyen esetben a rendszer átvehető, mert a használatba vétel, még a csökkent funkcionalitással is nagyobb gazdasági haszonnal kecsegtet, mint egy később használatba vett javított rendszer. Természetesen az a szempont sem elhanyagolható, bár nem a tesztelés szigorúan vett hatáskörébe tartozik, hogy a szállító a szállítást követően kijavítja-e ezeket a hibákat szavatossági körben.
Tipikus teszt eset súlyok lehetnek a
blokkoló
komoly
fontos
apró
kozmetikai
hibák.
A blokkoló hiba olyan amelyik megakadályozza a rendszer használatát, amíg a rendszerben ilyen súlyos hiba akárcsak egy is van a rendszer nem tudja ellátni a feladatát.
Komoly hiba az, amely mellett még elképzelhető a rendszer üzembe helyezése, de a rendszer gazdasági haszna lényegesen kisebb, mint ha a hiba nem lenne. Ilyen lehet egy fontos, de nem életbe vágó funkció hiánya, vagy egy olyan funkció hiánya, amely a program használata során csak egy későbbi időpontban válik szükségessé, például évváltáskor. Ilyen esetben a szoftver rendszer használatba vehető, de általában a szállítótól a megrendelő csak részteljesítést fogad el, és a hiba kijavítása is szigorú határidő mellett történik.
Fontos, hogy amennyiben a rendszer átvételre kerül komoly hibával, akkor a szoftverszállítási projektmenedzsmentben a rizikó menedzsment foglalkozzon azzal a kérdéssel, hogy milyen következményei vannak annak, ha a szállító nem szállítja a javítást az elvárt, vagy a projektben kalkulált legvégső határidőig.
Fontos hiba az, amelyik nem akadályozza meg a rendszer használatát, és nem csökken a rendszer gazdasági haszna sem, de a használat költségesebb, vagy (ezzel egyenértékűen) nehézkesebb, mint ha a hiba nem lenne jelen. A fontos hibák kijavítását joggal várja el a megrendelő a szállítótól, de ezek javítása nem feltétlenül az átadás, és a teljesítés során történik.
Apró hibáról beszélünk olyan esetben, amikor a hiba jelenlétével együtt is jól használható a rendszer. Egy hiba kozmetikai akkor ha gyakorlatilag funkció nem sérül csak a felhasználói felületen van olyan eltérés a tervezettől, amely észlelhető.
A teszt esetek súlyának elsősorban átvételi tesztek során van szerepe, ahogyan a fentiekben részleteztük is, hogy az átvételre milyen hatással kell lennie a hibáknak a súlyozástól függően. A teszt tervnek, amennyiben az átvételi teszt meg kell határoznia azt is, hogy az egész teszt mikor tekinthető sikeresnek. Természetesen blokkoló hiba egy sem fordulhat elő, de komoly, fontos, apró és kozmetikai hibákra is meg lehet és érdemes adni maximális számot, ami tipikusan az összes teszt eseten 5-10%-a.
A teszt előfeltételei olyan feltételek, amelyek nem tartoznak ugyan a teszt előkészítés teendői közé, de szükségesek ahhoz, hogy a tesztet végre lehessen hajtani. Ilyenek a tesztelendő rendszer és a mock részek installálása, ami az egész tesztelés, és nem a teszt eset előkészítéséhez tartozik, vagy a megfelelő sávszélesség, amennyiben az nem triviális. A teszt tervben azokat az előfeltételeket kell felsorolni, amelyekkel szemben várható, hogy előfordulhat, hogy nem állnak rendelkezésre, és ez különösen akkor fontos ha valamelyik előfeltétel hiánya olyan hibás tesztfutást eredményez ami miatt fals negatív értékelést kaphat a teszt, holott csak az előfeltételek nem voltak adottak.
Az előkészítésben olyan teendőket kell felsorolni, amelyek nem a teszt részei, de amelyeket a teszt eset elindítása előtt végre kell hajtani, hogy a tesztelt rendszer a teszt eset végrehajtására megfelelő állapotba kerüljön. Ezek a lépések általában minden alkalommal végrehajtandók a teszt eset ismételt futtatása esetén is, és hasonlóan az előfeltételekhez figyelni kell arra, hogy a teszt hibája esetén nem a hibás teszt előkészítés-e a valódi ok.
A végrehajtás részben azt kell leírni, hogy hogyan kell magát a tesztet végrehajtani. A végrehajtás leírásában nagyon precízen, egyértelműen és konkrétan kell fogalmazni, hogy ki legyen zárva a teszt végrehajtásának különböző lehetősége. Amennyiben például várni kell egy eredményre, akkor nem megfelelő az olyan megfogalmazás, hogy „kivárható időn belül megjelenik az eredmény az ablakban”. Az, hogy mi a kivárható idő a tesztelő személyétől, hangulatától is függhet, így a teszt eredménye nem determinált. Helyes megfogalmazás viszont, hogy „10mp-en belül megjelenik az eredmény az ablakban”.
A dokumentálás részben azt kell leírni, hogy a teszt végrehajtása során a teszt jegyzőkönyvben milyen adatokat kell rögzíteni, illetve a számítógépes rendszerben vagy a tesztelőkörnyezetben keletkezett állományok közül melyeket kell begyűjteni, és csatolni a teszthez, mint dokumentumokat.
Az értékelés rész pontosan és precízen kell, hogy definiálja, hogy mikor tekinthető a teszt sikeresnek. Nem létezhet olyan fogalom, hogy egy teszt majdnem sikeres, vagy tulajdonképpen sikeres. Ha olyan értékeléssel találkozunk, hogy a teszt „egyes részei” sikeresen lefutottak, az valószínűleg azt jelenti, hogy valójában a teszt esetet szét kellene vágni több tesztre. Egy funkcionális teszt lehet sikeres, vagy sikertelen.
Az átvételi tesztek során a funkcionális teszteket a teszt tervekből derivált teszt jegyzőkönyvekkel kell dokumentálni, ahol minden egyes teszt esetre rögzíteni kell, az előfeltételek ellenőrzését és az ellenőrzés eredményét, az előkészítés lépéseit, a végrehajtást, a dokumentáció begyűjtését, illetve a dokumentációt és végül az értékelést (sikeres, vagy sikertelen).
Az átvétel során ha egy teszt azért nem sikerült, mert voltak megfelelőek az előfeltételek, akkor tesztelési szempontból a tesztet sikertelennek kell tekinteni. Így teszt csak akkor kerülhet elfogadásra, ha minden blokkoló súllyal rendelkező teszt eset sikeresen lefutott, és a megadott maximális hibaarányon kívül sikeresen futott minden más súlyú teszt eset.
A terheléses tesztek elsődleges célja nem a rendszer funkcionális működésének ellenőrzése, hanem a rendszer terhelés alatti viselkedésének vizsgálata. A terheléses tesztek között van a terheléses teszt, a sokk teszt és a tartóssági teszt. Ezek mellett lehetséges más terhelés típusú teszteket is definiálni, de ez az a három alaptípus, amelyik a legfontosabb.
Ezeknél a teszteknél a rendszer teljesítményét mérjük, és ehhez definiálni kell a konkrét rendszerre a teljesítmény fogalmát. Pontosan meg kell határozni, hogy mik azok a mérőszámok, amelyeket a rendszer tesztelése során mérni akarunk, és milyen értékeket tudunk elfogadhatónak tekinteni.
Ezek az értékek a terminológia szerint kulcsfontosságú teljesítmény mérők (Key Performance Indicators, KPI), amelyekre a teszt terv minőségi értékeket ír elő, valamint definíció szerűen meghatározza ezek mérésének pontos módszertanát, és azt, hogy az egyes PKI-k egyenként, és összességükben hogyan garantálják a rendszer szolgáltatási szintjeit, amelyet a Service Level Agreement (SLA) megkíván.
A terheléses teszt a rendszer terhelésre adott válaszát vizsgálja. A terheléssel kapcsolatos tesztek körében nem egységes a terminológia, így ide szokták érteni a túlterhelési vagy sokk teszteket, a beégetési (burn) vagy más néven tartóssági teszteket.
A terheléses teszt feladata, hogy ellenőrizze, a rendszer képes az elvárt válaszidőkön belül nyújtani a funkcionalitását olyan terhelés alatt, amilyen terhelésnek az éles rendszerben lesz maximálisan kitéve.
A terheléses tesztek természetszerűleg csak olyan rendszeren végezhetők, amelyek hardver és kapacitás szempontjából megegyeznek az éles rendszerrel, ellenkező esetben a kapott eredmények nem fognak megfelelni az éles rendszernek. Ha a terheléses teszt alatt a rendszer sokkal lassabb, mint azt elvárjuk, de a hardver is kisebb teljesítményű, az még nem jelenti azt, hogy az éles rendszeren sem lesz képes az elvárt teljesítményt hozni. Ugyanakkor fordítva is igaz, ha a terheléses tesztet nagyobb rendszeren végezzük (ezt nem tipikus), mint ami az éles rendszeren áll majd rendelkezésre a sikeres terhelési eredmények nem garantálják, hogy az éles rendszeren is megfelelő lesz a teljesítmény.
Amíg a funkcionális jellegű tesztek esetében nem fontos, hogy a rendszer teljesítménye azonos legyen az éles rendszerével, addig a terheléses tesztek esetében ez alapvető. Ez a terheléses teszteket költségessé teszi, és ezért ezeket csak a sikeres funkcionális tesztek lezárását követően, és később nem ismételten végzik olyan hardveren, amelyet csak ideiglenesen rendelnek a projekt céljaira.
A terheléses teszt eredménye gyakran nem olyan egyértelmű, mint a funkcionális teszteké. A kapott válaszidőket statisztikai módszerekkel lehet érdemes elemezni, vizsgálni a válaszidők minimum, maximum értékét, eloszlását. A gyakorlatban sokszor elegendő az olyan statisztikai kritérium, mint megadni két három értéket a válaszidőkre és megkövetelni, hogy a teszt alatt a válaszok 90%-s, a legkisebb, 97% a második legkisebb stb. kritérium időértéknél kisebb legyen. Gyakran a rendszerrel szemben megkövetelnek maximális válaszidőt is, amely túllépése esetén a kérést meg nem válaszoltnak tekintik, és a terhelési kérdések megválaszolási arányára is egy 100% közeli, de annál természetesen kisebb értéket adnak meg.
A terheléses tesztek során a terhelések megfelelnek a rendszer funkcióinak, és általában a tipikus funkciókkal terhelik a rendszert a funkciók közötti olyan eloszlással, amelyik tipikusan várható az éles környezetben is. Ezek a terhelések azonban nem vizsgálnak minden funkciót. És a funkciók helyes eredményeit sem ellenőrzi általában a terheléses teszt sem valós időben, sem pedig azt követően. Ennek oka, hogy az ellenőrzés valós időben a tesztelt rendszernél lényegesen nagyobb erőforrást igényelne, ami rendkívüli, a legtöbb projekt számára financiálisan elviselhetetlen mértékben megnövelné a tesztelés költségét. A teszt lefutását követő időszakban, a naplófájlok vizsgálatából megállapítani a funkcionális megfelelőséget pedig gyakran nem lehetséges. Ezért a terheléses tesztek során a funkcionális megfelelőséget csak szúrópróba szerűen ellenőrzik a tesztelő rendszerek, illetve azt vizsgálják minden egyes válasz során hogy a visszaadott válasz nem a terhelés következtében általában fellépő rendszerhiba.
A sokk teszt során a rendszert olyan terheléssel teszteljük, amely rövid ideig sokkal magasabb, mint a maximálisan megkívánt terhelés. A teszt célja annak vizsgálata, hogy a rendszer képes meghibásodás nélkül elviselni az extrém terhelést, és nem történik ennek hatására adatvesztés, vagy más meg nem engedhető hiba, illetve a rendszer képes-e a terhelés lecsökkenését követően automatikusan visszaállni normál üzemre.
Nem kívánalom a rendszerekkel szemben, hogy a sokk időtartama alatt funkcionálisan helyesen működjenek, csak az, hogy ne történjen olyan változás a rendszerben, amely a normális működést a későbbiekben gátolja.
A sikeres sokk teszt bizonyítja, hogy a rendszer nem támadható hatékonyan (Denial of Service) DoS támadással, és hasonló terhelés esetén is a lehetőségekhez képest automatikusan helyreáll a működés, és nem történik adatvesztés.
Vannak olyan módon felépített rendszerek, amelyek költséghatékonysági okok miatt eleve úgy vannak tervezve, hogy a nominális terhelésnél nagyobb terhelést nem viselnek el, és összeomlanak. Az ilyen rendszereket általában terhelés elosztó rendszerek, tűzfalak védik a túlzott terheléstől. Természetszerűleg a sokk tesztek során a tesztelésbe ezeket az elemeket is be kell vonni, és valójában ilyen esetekben a tesztek a terhelés limitáló tűzfalak funkcionalitását tesztelik, nem a szállított szoftver rendszerét.
A sokk terheléseknél a következőket vizsgáljuk:
A rendszer a terhelést követően visszaáll a normál működésre.
A rendszer a terhelés alatt és azt követően sem enged jogosulatlan hozzáférést.
A rendszer a terhelést követően nem használ indokolatlan erőforrást (memória vagy más erőforrás szivárgás jele).
A sokk tesztek kivitelezésénél gondosan oda kell figyelni arra, hogy a rendkívül nagy terhelést milyen módon állítja elő a tesztelő rendszer, gyakran sok gépről, hálózati elemeken keresztül kell létrehozni a terhelést. Meg kell határozni a teszt tervezése során a sokk mértékét, és azt is, hogy a terhelés milyen sebességgel és emelkedéssel fut fel, mennyi ideig tart és milyen a lefutása. Ezekre az értékekre nincs általános szabály, ezeket a várható, vagy elképzelhető túlterheléseknek, vagy éppen a rendelkezésre álló terhelő erőforrásoknak, és a tesztelésre fordítható időnek megfelelően szokás beállítani.
A rendes működésre való visszaállás idejét azonban a megkívánt rendelkezésre állási paraméterek alapján kell megkövetelni, és előre rögzíteni a teszt tervben. Ebben figyelembe kell venni, hogy a rendszer milyen görbe szerint áll vissza a rendes üzemre, milyen szolgáltatási szint érhető el a visszaállás alatt, illetve, hogy mennyi idő a rendszert leállítani és újraindítani. Csak olyan visszaállási idő fogadható el, amelyik rövidebb, mint az egész rendszer újraindítása (ellenkező esetben nagyobb szolgáltatási szint érhető el a rendszer újraindításával), illetve annál nem sokkal nagyobb abban az esetben ha a visszaállási idő alatt is elérhető a szolgáltatás megnövekedett, de használható válaszidőkkel. Tipikusan a visszaállási idő pár perctől néhány óráig tarthat a rendszer összetettségétől függően.
A tartóssági teszt hasonló a sokk teszthez, de nem egyszeri kirívóan nagy terhelésnek teszi ki a rendszert, hanem hosszan terheli azt, és azt vizsgálja, hogy a rendszer képes-e hosszú időn keresztül folyamatosan a specifikációs paramétereknek megfelelően működni.
A tartóssági teszt sikeressége biztosítja, hogy a rendszer hosszú időn keresztül képes ellátni a feladatát, és biztosítani azokat a gazdasági előnyöket, amelyeket a rendszertől a megrendelő elvár. A tartóssági teszt két esetben tekinthető sikeresnek. Az egyik, amikor a rendszer semmilyen működési degradációt nem mutat a teszt alatt. Ebben az esetben a teszt azt mutatja, hogy a tesztelési időszak alatt a rendszer ugyanolyan jól és ugyanolyan jó paraméterekkel működik, mint közvetlenül indulás után.
A működési degradáció lehet olyan paraméter változása, amelyet a felhasználók éreznek, tipikusan a rendszer válaszidejének megnövekedése, de lehetnek olyan paraméterek változása is, amelyeket a felhasználók direktben nem tapasztalnak, de műszakilag biztosnak lehet tekinteni, hogy hosszabb távon a felhasználók által érzékelt paraméterek is degradálódnának. Ilyen tipikusan a memória elfolyás, vagy diszk terület betelése, vagy a rendszerben felgyülemlő halott szálak, adatbázis kapcsolatok elfogyasztása, és fel nem szabadítása. Ezek a paraméterek általában valamilyen rendszer erőforrás elfogyasztását és fel nem szabadítását jelentik.
A másik eset, amikor a tartóssági tesztet sikeresnek kell tekinteni, ha a rendszer ugyan mutat a teszt ideje alatt valamilyen degradációt, ez azonban nem olyan mértékű, hogy egy megkövetelt folyamatos üzemelési periódus alatt ne lenne elfogadható. A megkövetelt folyamatos üzemelési periódus az az időtartam, ameddig a rendszernek folyamatosan üzemelnie kell újraindítás, karbantartás nélkül. Ha a rendszer üzemeltetése során az üzletileg megkívánt rendelkezésre állás megengedi, hogy a rendszert naponta újraindítsák, akkor a tartóssági teszt elegendő ha egy napig tart. Ha a rendszerben ez alatt van némi degradáció, akkor a rendszert lehetséges napi újraindítással üzemeltetni.
A rendszer természetesen ilyen esetben nem tökéletes. A rendszerben valamilyen hiba van, amely a degradációt okozza, de az üzemelés ezzel a hibával együtt is elfogadható. Ennek ellenére az ilyen hibák kijavítására is törekedni kell akár az átadás, vagy a határidőknek és a gazdasági előnyöknek megfelelően a szavatossági időtartam alatt. Ennek oka nem csak az, hogy a rendszerkarbantartás, újraindítás költséget jelent, hanem az is, hogy minden felfedezett és ismert, de be nem határolt hiba rizikót jelent, és nem garantálható, hogy változó üzemelési körülmények között a degradáció nem növekszik, vagy akár nem akadályozza meg teljesen a rendszer funkcionalitását (teljes leállás, akár adatvesztés).
A be nem határolt hibák veszélye nem csak a tartóssági teszteknél létezik, de ez az a tesztelés, amelyiknél a legnagyobb súllyal kell figyelembe venni az ilyen jelenségeket. A funkcionális, terhelési és sokk teszteknél fellépő hibák oka általában könnyebben behatárolható, és akár javítható a hiba vagy, becsülhető a hiba működésre való kihatása. A tartóssági teszteknél sokkal gyakrabban fordul elő, hogy a hiba jelenség nem drasztikus, nem egy adott funkcióra és ennek egy adott kódrészletre specifikus és emiatt nehezen behatárolható a hiba helye.
A tartóssági tesztek azok, amelyek a legtovább tartanak, hiszen ha egy rendszernek képesnek kell lennie folyamatosan üzemelni egy hónapon keresztül, akkor a tartóssági teszt sem lehet ennél rövidebb. Ez azért fontos kérdés, mert ez a kritérium nem feltétlenül az a követelmény, amelyet a megrendelő a szállítóval szemben megfogalmaz. A megrendelői követelmények megfogalmazása során gyakran olyan kitételek szerepelnek, mint „a rendszernek képesnek kell lennie folyamatosan üzemelnie”, amiből elvileg végtelen hosszú tartóssági teszt következne. Valójában a tartóssági teszt hosszát az üzleti és üzemeltetési követelmények határozzák meg, amelyek nem feltétlenül jelennek meg direktben a szállító felé követelményként. Ezért a megrendelői oldalon a tartóssági teszt hosszát szokták sokszor követelményként feltüntetni.
A felhasználói elfogadási teszt a hivatalos átadási, átvételi teszt. Erre a tesztre akkor kerül sor, amikor a szállító a többi tesztet már lefuttatta, és úgy ítéli meg, hogy a rendszer alkalmas az átadásra, nincsen benne olyan hiba, amelyik megakadályozza a teljesítést.
A felhasználói elfogadási teszt (User Acceptance Test, vagy UAT) elfogadója a megrendelő, és nem a felhasználó. Sok esetben ez a két személy ugyanaz, de nagyobb rendszereknél nem a felhasználó az aki a rendszer gazdasági előnyeiért felel, ő csak kezeli, és ezért az elfogadás felelőssége gazdasági értelemben a szállítás igazolása sem az ő feladata. Mégis ez a terminológia terjedt el, mert ugyan nem a felhasználó a felelős, de mégis az a személy aki ezeken a teszteken, mint a megrendelő a tesztek végrehajtására delegált képviselője részt vesz.
Sokszor az UAT-ot csak mint funkcionális tesztet tekintik,és valóban a leggyakrabban az UAT tényleges végrehajtása során csak a funkcionális tesztet hajtják lépésről lépésre végig. Ennek az oka, hogy a terheléses tesztek ismételt végrehajtása nagyon költséges lenne, és nem is járna műszaki előnyökkel. A terheléses teszteket általában a megrendelő képviselőjének, vagy képviselőinek jelenlétében és felügyeletével hajtják végre, és ezek elfogadott jegyzőkönyve az UAT része.
Az UAT funkcionális teszt végrehajtása során a megrendelő és a szállító a teszteket együtt hajtják végre olyan módon, hogy a teszt végrehajtás ellenőrzéséért és a teszteredmények kiértékeléséért a megrendelő a felelős. Az UAT minden esetben formális jegyzőkönyvvel rögzített és dokumentált.
Az üzembehelyezési teszt az éles rendszeren történik és célja annak ellenőrzése, hogy a rendszer az éles környezetben is megfelelően működik, nem történtek installációs, konfigurációs hibák.
Ezt a tesztet sokszor nem tekintik tesztnek, hanem az üzembehelyezés részének. Mégis érdemes a tesztek közé sorolni és úgy kezelni, mint a korábbi teszteket, mert ugyanolyan precízen és hasonló elvek mentén kell végrehajtani, és ellenőrizni, mint a funkcionális teszteket.
Az üzembehelyezést követően a rendszer elkezd működni, és éles inputokkal működik. Üzletileg kritikus rendszereknél az üzemelés során is folyamatosan figyelni kell, hogy a rendszer működik-e, és ez nem csak az üzletileg kritikus rendszereknél hanem minden rendszernél különösen fontos az éles indulást követően.
Arról meggyőződni, hogy a rendszer helyesen működik csak úgy lehet, ha definiáljuk a helyes működés kritériumait, és azt, hogy ezeket milyen módon fogjuk mérni, a mérési eredményeket kiértékelni.
Az üzembehelyezési teszthez ugyanazokat az SLA-nak megfelelő PKI-kat kell mérni, mint amiket az üzemelés során, de ezeket ki lehet egészíteni további indikátorokkal, amelyek mérése nem üzemeltetési cél a folyamatos üzem során, de a beüzemelés során fontos információt adhat a rendszer állapotairól.
Az üzembehelyezési teszt tervezése és végrehajtása során, mivel ekkor már éles rendszer üzemel, különösen gondosan kell ügyelni arra, hogy ne legyenek olyan teszt lépések, amelyek a rendszer környezetét, azokat a rendszereket, amelyeket üzemszerűen használnak a felhasználók, feleslegesen terhelik, esetleg működésüket gátolják.
A teszt tervek elkészítése a rendszer követelmény specifikációja alapján történik. Ennek megjelenési formája az iparági gyakorlatban általában CRC kártyákat, követelmény diagrammokat vagy más UML leírást jelentenek.
A tesztesetek kidolgozása során minden egyes teszt eset definiálja, hogy mely követelményt milyen mértékben fed le a teszt futtatása. Ennek nyilvántartása UML szerkesztő eszközben történhet, amely biztosítja, hogy tervezés során bármikor lekérdezhető a követelmények tesztek által történő lefedettsége, valamint minden teszthez lekérdezhető, hogy mely követelményeket tesztel, és fordítva minden követelményhez meghatározható, hogy mely tesztek azok, amelyek biztosítják a követelmény teljesülését.
Ezzel a követelmények változása során is folyamatosan nyilvántartható, hogy mely tesztek azok, amelyeket módosítani kell, mely tesztek váltak esetleg feleslegessé, és milyen új teszteket kell tervezni a követelmények változott halmazának lefedettségéhez.
Sokszor a teszt tervek elkészítéséhez szövegszerkesztőt, Wiki rendszert használnak. Ez utóbbinak az lehet az előnye, hogy vannak olyan Wiki alapú rendszerek, amelyek a formális tesztleírásokat automatikusan végre is tudják hajtani, így a tesztek automatizálása a teszt definíciókból indul ki minimalizálva az emberi hiba lehetőségét.