Tesztelési alapok

Egy nagyon gyakori hiba házi feladatoknál és egyéb önálló munkáknál, hogy a megoldás tesztelésénél a tesztesetek erősen hiányosak. Az informatikus BSc tantervből sajnos fájóan hiányzik egy részletesebb tesztelés rész (bár előkerülnek néhol azért olyan fogalmak mint ekvivalencia partíciók, black box tesztelés stb.). Álljon itt egy nagyon gyors (felületes) áttekintés a specifikáció alapú teszttervezési módszerekről.

Adott a következő programunk, amit majd meg kell írni és tesztelni:

Get-PhoneBook.ps1 -Container <string> -OutFile <fájlnév> -ExcludeWrongUsers

A program lekérdezi a felhasználókat egy LDAP címtárból a megadott nevű konténerből, kiírja az eredményt a megadott OutFile fájlba, valamint kihagy bizonyos felhasználókat, ha meg van adva az ExcludeWrongUser kapcsoló. A Containernek létező objektumra kell mutatnia, és az elérését egy LDAP-specifikus formátumban, egy úgynevezett Distinguished Name (DN) sztringként kell megadni. A kimeneti fájlnak meg nem szabad a futás előtt léteznie.

Hogyan álljunk neki a tesztek tervezésének? Az összes lehetséges bemeneti paraméterértéket nem tudjuk végigpróbálni (hiszen ha korlátoznánk is a bemeneti paraméterek hosszát 255 karakterre, akkor is rengeteg eset lenne, számoljunk utána, hogy mennyi!), úgyhogy pár lényegesre kell szorítkozni. Viszont szeretnénk, hogy semmi "fontos" eset ne maradjon ki. Gondoljuk tehát először végig, hogy milyen lehetséges típusai vannak az egyes paramétereknek (~ ekvivalenciaosztályok meghatározása):

• Container:
  • Nincs megadva (I)
  • Meg van adva, de nem létezik ilyen DN-ű konténer (I)
  • Meg van adva, és létezik ez a konténer (V)
• OutFile
  • Nincs megadva (I)
  • Meg van adva, de létezik a fájl (I)
  • Meg van adva, és nem létezik a fájl (V)
• ExcludeWrongUsers
  • Meg van adva (V)
  • Nincs megadva (V)

Az egyes esetek mellett jelöltük, hogy (V) valid - helyes vagy (I) invalid - helytelen ez az osztály.

Hogyan lesznek ebből tesztek? Az egyik gyakran használt elv az, hogy végig kell próbálni minden helytelen típust, hogy megbizonyosodjunk, hogy a programunk helyesen kezeli-e azt a hibát. Viszont nem érdemes egyszerre több hibás értéket is megadnunk, mert akkor azok elfedhetik egymás hatását (pl. ha a legelső lépésként a megvalósításban kilépünk, ha nincs OutFile megadva, akkor hibás OutFile esetén sose fogunk eljutni a DN ellenőrzéséig). Ezek alapján a következő teszteseteket származtathatjuk (TC - test case - teszteset):

• TC1: Container nincs megadva (I) | OutFile helyes (V) | Exclude mindegy (V)
• TC2: Container megadva de nem létezik ilyen (I) | OutFile helyes (V) | Exclude mindegy (V)
• TC3: Container helyes (V) | OutFile nincs megadva (I) | Exclude mindegy (V)
• TC4: Container helyes (V) | OutFile megadva, de létezik (I) | Exclude mindegy (V)

Ezekhez a tesztesetekhez kell utána konkrét értékeket választani. Tehát legalább 4 teszteset kell a hibás bemenetek kezelésének ellenőrzéséhez. De természetesen lehet több is, ha tovább bontjuk az egyes osztályokat (pl. a hibás DN-ben lehet az OU rész a rossz, de lehet a DC rész a hibás).

Mehetünk tovább a helyes esetek ellenőrzésére. Itt a cél az, hogy minden helyes osztály szerepeljen egyszer, tehát:

• TC5: Container helyes (V) | OutFile megadva, és nem létezik (V) | Exclude meg van adva (V)
• TC6: Container helyes (V) | OutFile megadva, és nem létezik (V) | Exclude nincs megadva (V)

Ez még kevés a teszt specifikációjához, mert a program erősen érzékeny arra, hogy milyen felhasználók vannak a címtárban. Dióhéjban annyi, hogy ha a felhasználó mail vagy telefon mezője üres, akkor azokat le kell cserélni not available szövegre alapból. Ha meg van adva az ExcludeWrongUsers, akkor ezeket ki kell hagyni a kimenetből. Látszik, hogy a TC5 és TC6 eseteknek csak akkor van értelme, ha megszabjuk, hogy milyen felhasználók vannak a címtárban, és ezeket definiáljuk a teszteset részeként. 

Mik a lehetséges osztályok a felhasználók esetén? A mail kitöltve/nincs kitöltve és a telefon kitöltve/nincs kitöltve értékeket kell majd vizsgálni, és ezeket lehet elrontani a program implementálása során, tehát jó lenne ezek kombinációját megnézni. Készítsünk olyan teszt felhasználókat, akiknél

• User1 | mail megadva | telefon megadva
• User2 | mail megadva | telefon nincs megadva
• User3 | mail nincs megadva | telefon megadva
• User4 | mail nincs megadva | telefon nincs megadva

Miért nem jó pl. hogy ha User2-t elhagyjuk? Ekkor az olyan implementáció is átmegy a teszteken, aki az ExcludeWrongUsers esetén csak a mail tulajdonság kitöltöttségét figyeli (mert pl. elfelejtette a programozó, elrontotta a feltételek vizsgálatát).

Akkor készen vagyunk a 4 helytelen + 2 helyes teszt (4 féle teszt felhasználóval) lefuttatása után? Nyilván nem, ez csak a legalapvetőbb ellenőrzéseket hajtotta végre. Innentől kezdve mindenki saját kreativitása / tipikus programozói hibák figyelembevételével / korábbi hibák alapján vehet hozzá további teszteket. Ötletek:

• A feladatban az adott Container összes alkonténerében is keresni kell, tehát a teszt felhasználókat érdemes egy legalább 3 szintű hierarchiában elrendezni.
• A program hatékonyságát úgy lehet vizsgálni, ha nem csak 4, hanem sokkal több felhasználót kérdezünk le vele. 
• Elkezdjük a szélsőséges eseteket nézni: nincs kitöltve a felhasználó neve, speciális karakter van a Container vagy a felhasználó DN-jében, ugyanolyan dispalyname értékkel rendelkező felhasználók is vannak a címtárban, megadunk egy mail címet és utána kitöröljük stb.

Természetesen sok egyéb technika létezik tesztesetek szisztematikus származtatására, de alapszinten a fent vázolt elég jól használható.

Mit nyerünk még ezzel? Ha ezt a feladat megoldása előtt gondoljuk végig, akkor kapunk egy nagyon jó kis specifikációt arról, hogy milyen eseteket kell majd kezelnünk a programunkban (lásd Test-driven development ötlete).

További információ:

1. International Software Testing Qualifications Board (ISTQB). Foundation Level Syllabus. 2011. URL: http://istqb.org/downloads/viewdownload/16/15.html
   1. (Ez egy magas szintű összefoglaló arról, hogy alapszinten mivel kéne tisztában lenni tesztelés kapcsán. Túl sok magyarázat nincs benne, de áttekintésre és tudásfelmérésre ideális.)
2. Majzik István, Micskei Zoltán. Szoftverellenőrzési technikák (vimim148), BME MIT, MSc tantárgy. URL: http://www.inf.mit.bme.hu/edu/courses/szet/materials

A leírással kapcsolatos hibákat, visszajelzéseket Micskei Zoltánnak küldjétek.