Csak a tesztemen keresztül!

Szakmai gondolatok informatikai rendszerek teszteléséről.

Gazda

Friss topikok

  • Akron: @Verhás Péter: Az ügyfeled a cég (vezérigazgatóval, Józsi nénivel) A cég ellenőrzi le és veszi át ... (2018.01.31. 14:09) Miért UAT
  • Verhás Péter: @ hrgy: Egy kicsit felhúztam magam, de sebaj. A lényegi állításokban igazad van, ám a személyekre... (2011.10.09. 00:25) A tesztelés nem mindenható
  • crix: Ez a hozzáállás. Sajnos most is. Aztán csodálkoztak itt a népek, amikor bevállaltam a hétvégi munk... (2011.10.05. 16:56) Újra fizetni kell
  • crix: és milyen specifikáció mentén ment át az ügyfél? elég blind? (2011.10.05. 13:41) Ügyfélteszt
  • fqqdk: fitnesse, concordion, és cucumber integráció lesz? (2011.03.05. 13:42) Automatizált tesztelés és üzleti tesztelés

Társblogok

Blog

Szakmai gondolatok informatikai rendszerek teszteléséről.

A minőségi szoftverhez három dolog kell: tesztelés, tesztelés és tesztelés.

Így tesztelünk mi.

Linkblog

Terheléses teszt eredmény ellenőrzése

2009.07.06. 10:00 | Verhás Péter | 3 komment

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.

 

 

A bejegyzés trackback címe:

https://csakatesztemenkeresztul.blog.hu/api/trackback/id/tr931227977

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

vicziani · http://jtechlog.hu 2009.07.06. 12:41:33

Üdv,

Amit láttam és működőképes volt, hogy Excelben előállítottak manuálisan, de az Excel függvényeit használva (random, stb.) egy tonna adatot, Excel-lel kiszámították a választ, és azt ellenőrizték.

Amúgy mik azok a "beégetéses tesztek"?

Verhás Péter · http://csakatesztemenkeresztul.blog.hu 2009.07.06. 15:15:05

Ha Excel-lel kiszámították az eredményt, akkor az algoritmust implementálták Excelbe is. Ez az az eset, amikor az algoritmus eredményét hasonlítom önmagához. Ilyenkor mindig benne van a pakliban, hogy az algoritmus hibás, vagy ugyanazt a hibát követjük el a rendszer kódolása, és az Excel program készítése közben.

Ez megint az az eset, hogy működhet, de tisztában kell lennie a hiba lehetőségével.

FutoBolond 2009.08.22. 10:28:43

Szia Péter, most olvasom vissza a nyári bejegyzéseket, remek a blog, főleg ennél a bejegyzésnél ragadtam le :)

Kis kiegészítés a terheléses tesztekhez: terheléses tesztnél nagyon gyakran nem csak igen/nem outputra számítunk. Sok rendszernél a terheléses tesztet mérésre is használjuk, ami bemeneti adat a későbbi méretezéshez. Elég lesz-e 8core a kiszolgáláshoz, vagy inkább 32-64 a nagyságrend, skálázható-e egyáltalán a rendszer, vagy megfogja memóriabusz, esetleg hogy a real-time rendszer képes lesz-e válaszidőket megfelelő ütemezéssel visszaadni.

Ehhez persze megfelelő reprezentativ teljesítménytesztet kell összeállítani. Webes felületek esetén néhány tipikus use case alapján, távközlésben még pontosabb forgalmi modellek alapján, stb.

Az persze külön kérdés, hogyan lehet a teszt-keretrendszer késleltetéseit, loggolási veszteségeket (ez gyakran nagyságrendileg lehet a mért rendszernél lassabb), egyebeket kiszűrni, de itt asszem, kezd offtopicba kanyarodni a téma.
süti beállítások módosítása