Miért nem vizsgáljuk (minden esetben) terheléses tesztnél, hogy funkcionálisan működik-e a rendszer. Ez a tisztázandó alapkérdés az elmúlt két blog bejegyzésből. Mi az a terheléses teszt, és egyáltalán...

Milyen teszteket végzünk egy informatikai rendszernél, és miért úgy végezzük őket, ahogy? Hogyan is kezdjem, hogy hatékony legyen? Akárhogy nézem, mindig visszajutunk az elejére, hogy miért is tesztelünk. Ugye azért tesztelünk, hogy az üzemi rendszer úgy működjön, ahogy az az üzleti igényeknek megfelel. Ez a cél üdvös, de a technikai feltételeknek nem felel meg. Informatikusként ritkán foglalkozunk az ügyfél üzleti igényeivel, és ha igen, akkor már nem mint informatikus tesszük ezt, hanem üzleti konzulensként. Ezért ehelyett a tesztek céljaként azt tűzzük ki, hogy a rendszer úgy működjön, hogy a működés megfeleljen a specifikációnak. Mivel ez a cél egy teszttel hatékonyan nem érhető el, ezért sokféle tesztet készítünk, amelyek a rendszer különböző aspektusait tesztelik, és sokszor egymásra épülnek. Ezek a tesztek lehetnek:

• fejlesztési unit tesztek

• integrációs tesztek

• rendszertesztek

• terheléses tesztek

• shock tesztek

• beégetéses tesztek

• felhasználói elfogadási tesztek (UAT)

• üzembehelyezési teszt.

Persze a konkrét terminológia és hogy milyen tesztek is vannak nincs kőbe vésve, mint a tízparancsolat, ebben nem kell egyetérteni. A tesztek egymásra épülnek, és ha egy teszt nem fut le hibátlanul megfelelően, akkor nincs értelme nekiállni a következő tesztnek. Néha az is előfordul, hogy egy tesztet kihagyunk, mert az a döntés, hogy a teszt által vizsgált hiba típusának kicsi a valószínűsége és nem éri meg gazdaságilag a teszt. Például lehet olyan döntés, hogy egy shock tesztet nem végzünk el, mert a rendszer megkívánt rendelkezésre állása az éles környezetben megengedi, hogy üzemi időben leálljon a rendszer, és amúgy sem várunk nagy terhelést.

(shock 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.)

És akkor most lépjünk vissza az bejegyzés alapkérdéséhez: mi az a terheléses teszt, ami a rendszertesztet (funkcionális tesztet) követi, és miért nem vizsgáljuk a funkcionális megfelelőséget terheléses teszt során (minden esetben).

Nos elsősorban azért, mert nagyon drága lenne. A terheléses teszteknél a rendszert terheljük, amikhez terhelő ágenseket használunk. Ezeknek az a feladata, hogy szimulálják a majd az éles rendszerben fellépő terhelést. Ehhez igen nagy mennyiségű adatra van általában szükség, amit általában programból generálunk a tesztek során (a nagy mennyiség miatt). Ráadásul ezeknek az adatoknak fontos az eloszlása is, hogy ne olyanok legyenek, amelyek a működést egy partikuláris vonal mentén futtatják végig. (Például ha mindig ugyanannak az ügyfélnek az egyenlegét kérem le, akkor a rendszer a második kérés után már nem nyúl adatbázishoz, kiszolgál a cache-ből, és fals eredményt kapok.)

Ha az ágenseknek ezen kívül még az is a feladatuk, hogy ellenőrizzék a válaszadatokat, akkor rendkívüli módon megnő az adatok előállításának költsége. Nem csak a bemenő adatokat kellene előállítani, hanem a válaszadatokkal is rendelkeznie kell az ágensnek, hogy azt összehasonlítva a kapott válasszal ellenőrizni tudja, hogy az jó-e. Erre szokták azt tenni, hogy írnak egy programot, ami kiszámolja a választ...

ÁLLJ! PIROS LÁMPA! STOP!

Ilyen programunk van, éppen azt teszteljük. Ha az ágensben is szerepel az algoritmus az ellenőrzéshez, akkor az algoritmus eredményét hasonlítom az algoritmus eredményéhez. Naná, hogy egyezni fog! Ez nem jó megoldás. Persze azért ez sem ilyen ha nem fehér akkor fekete. Ha tisztában vagyok az elvi megfontolásokkal, és figyelembe veszem, akkor mint „részleges” megoldást, ismerve a hiányosságokat azért felhasználhatom ezt a megközelítést is. Például sikeres funkcionális teszt után kis terhelés mellett végigszámoltatom a tesztelt rendszerrel a terheléses teszt bemenő adatokra a válaszokat, elteszem, és vizsgálom, hogy nagy terhelés mellett is ugyanazt válaszolja-e. Részleges megoldás.

Egy másik megoldás, hogy az eredményeket eltesszük (amúgy is eltesszük, hiszen a teszt dokumentációjának a része), és utólag ellenőrizzük manuálisan, szúrópróba szerűen, hogy jók-e a válaszok. Részleges megoldás.

Szintén szokásos megoldás, hogy a terhelő ágensek terhelése mellett a funkcionális tesztek is, saját ágenssel futnak és ellenőrzik, hogy a funkcionális tesztek rendben mennek-e terhelés alatt. Részleges megoldás.

A teljes megoldás, hogy manuálisan annyi adatot előállítsunk, amennyi a terheléses teszthez kell, és a válaszokat is ellenőrizzük. Ez általában annyira drága, hogy nem éri meg. A hibák igen nagy százaléka kiszűrhető a részleges megoldásokkal is.

Amit viszont nem szabad: a terheléses teszt során kapott válaszokat teljesen figyelmen kívül hagyni. De ez már kiderült két héttel ezelőtt.