facebook-pixel

Teszttervezési technikák – 2. rész

Bevezető

Miért van erre szükség a tesztelés világában? A teszttervezés nem más, mint a tesztelési projektnek a megtervezése, vagyis tesztelés során e „sorvezető” mentén haladunk lépésről-lépésre. Bár a teszttervezés alapvetően a tesztmenedzser feladata, bizonyos esetekben előfordulhat, hogy nekünk kell elkészíteni, ezért fontos a teszttervezési technikák gyakorlati ismerete.

Teszttervezési szempontból nem mindegy, hogy milyen funkciójú programot/weboldalt tesztelünk, így az sem mindegy, hogy milyen technikával állunk a teszteléshez, és ezek a technikák hogyan néznek ki a gyakorlatban.

Ezek a cikkek kezdő és gyakorlott tesztelőknek egyaránt szólnak, hiszen még ISTQB vizsgát letett gyakorlott tesztelők esetében is előfordulhat, hogy megfeledkeznek bizonyos technikákról [link1][link2]. Cikksorozatunk ezen könnyen használható technikákat hivatott bemutatni, hogy segítsen feleleveníteni/rálátást adni arra, hogy melyik típusú teszteléshez melyik teszttervezési technikát ajánlott alkalmazni – mindezt átfogóan szemléltetve, a teljesség igénye nélkül.

Ok-hatás analízis

Valamennyi funkcionális tesztelési mód közül azok a legszigorúbbak és egyben a legtöbb gondolkodást igénylik, amelyek a döntési tábla alkalmazásán alapulnak [További vonatkozó cikk], hiszen itt tisztán logikai alapon fogalmazzuk meg a szükséges teszteseteket. Nagyon jól alkalmazhatóak olyan esetben, amikor sokféle logikai kapcsolatot tartalmazó feladathoz kell teszteseteket generálni.

Általános megjelenítése egy mátrix, melynek oszlopai definiálják a teszteseteket, sorai pedig a teszteseteket leíró feltételeket, illetve lehetséges lépéseket.

Első lépésként alaposan át kell tanulmányozni a funkcionális követelményeket. A feladat pontos megfogalmazása és megértése elengedhetetlen az eljárás használatához. Ha ezzel megvagyunk, akkor beszámozunk minden okot és okozatot (hatást), amivel találkoztunk. Egy döntési tábla alapvetően négy részből tevődik össze:

  • Először a sorokat elnevezzük a specifikációban megállapított okokkal, majd
  • felsoroljuk a hatásokat, azaz az okok egy kombinációjára a rendszernek milyen állapotot kell elérnie
  • A tesztesetek az oszlopokban fognak kialakulni
  • Minden egyes oszlopban feltüntetjük, hogy a tesztesetben teljesül-e egy feltétel, és hogy a feltételkombinációhoz tartozó hatás megvalósul-e

Ha egy feltétel igaz egy tesztesetben, akkor azt a táblázatban I betűvel jelöljük, míg hamis esetben H betűvel. Azokban az esetekben, amikor egy input érték nem releváns az eredmény szempontjából, mert a tesztelés szempontjából értelmetlen, azt kötőjellel (-) jelöljük.

1. PÉLDA

Vegyünk ki pénzt egy bankjegykiadó automatából.

Ehhez az alábbi feltételek teljesülése szükséges:

  • A bankkártyánk érvényes
  • Helyes PIN kódot adtunk meg
  • Legfeljebb háromszor próbálkoztunk a PIN kód megadásával
  • Van elegendő pénz a gépben is, és a számlánkon is

A gép az alábbi műveletekre képes:

  • Kártya visszautasítása
  • PIN újbóli bekérése
  • Kártya elnyelése
  • Új kívánt összeg bekérése
  • Kifizetés

this is a text describes a picture

Eset 1:

Okok: Azt feltételezzük, hogy a bankkártyánk nem érvényes, így az okokban felsorolt többi feltétel nem teljesül, ezért lettek kötőjellel jelölve. (Érvénytelen bankkártyával sem a PIN kód nem tesztelhető, sem a számlán lévő elegendő pénz).

Hatások: Mivel érvénytelen bankkártyával próbáltunk meg pénzt felvenni, a kártya azonnal visszautasításra kell, hogy kerüljön, így a többi hatás már nem valósulhat meg.

Eset 2:

Okok: A bankkártyánk érvényes, de nem adtuk meg helyesen a PIN kódot, és nem próbálkoztunk meg újbóli PIN kód megadásával.

Hatások: A kártya nem került visszautasításra (hiszen a példa szerint érvényes), viszont a helytelen PIN kód megadás következtében a rendszernek újra be kell kérnie a PIN kódot, így a rendszer nem viszi tovább a folyamatot.

Eset 3:

Okok: Érvényes a bankkártyánk, de adtuk meg jól a PIN kódot, és a PIN kódot beütve legfeljebb 3x próbálkoztunk.

Hatások: A kártya nem került visszautasításra (hiszen a példa szerint érvényes), viszont a helytelen PIN kód megadás következtében a rendszernek újra be kell kérnie a PIN kódot, de 3x sikertelen próbálkozás után az automata elnyelte a bankkártyánkat.

Eset 4:

Okok: Érvényes a bankkártyánk, jól adtuk meg a PIN kódot (így a háromszori PIN kód megadásra nem kerül sor), de nincs elegendő összeg a számlánkon.

Hatások: A kártya nem került visszautasításra (hiszen a példa szerint érvényes), nem kellett újra PIN kódot bekérni, nem nyelte el a kártyát, de a hibás összeg beütése miatt új összeget kér be.

Eset 5:

Okok: Ebben az esetben minden feltétel maradéktalanul teljesül, azaz érvényes a bankkártyánk, jól adtuk meg a PIN kódot (így a háromszori PIN kód megadásra nem kerül sor), a megfelelő összeget ütöttünk be, így az automata kiadja a pénzt.

Hatások: A kártya nem került visszautasításra (hiszen a példa szerint érvényes), nem kellett újra PIN kódot bekérni, nem nyelte el a kártyát, a beütött összeg elfogadásra került, így az automata kiadja a pénzt.

Az összes lehetséges kombináció úgy írható le matematikailag, hogy a specifikációban szereplő összes oknak 2 állása lehet: igaz vagy hamis. Így minden okvariációhoz 2 hatásvariáció tartozik. Tehát ha csak egy okunk van, akkor ezek szerint két tesztesetünk lesz. Ha két okunk van, akkor az előző két tesztesetet 2-vel kell szorozni, hiszen minden eddigi tesztesetet meg kell vizsgálni úgy, hogy a második ok igaz vagy a második ok hamis. Ha három okunk van, akkor a két okot tartalmazó eseteket (2*2=4 esetet) kell megvizsgálni a harmadik ok igaz és hamis ágán is. Tehát megint 2-vel kell szorozni az eddigi esetek számát. Vagyis a jelen példa esetén a variációk száma 24 =16 variáció lesz. Mivel ez matematikai megközelítés, az összes variáció általában jóval több, mint a valóban lehetséges variációk száma, mert vannak olyan ok-együttállások, amik nem lehetségesek (pl. a lenti, 2.példa alapján: a vásárlónak nincs pontgyűjtő kártyája, de mégis kéri a kedvezményt).

2. PÉLDA

Egy áruház pontgyűjtő kártyát bocsát ki. Minden vásárló, akinek van ilyen kártyája, minden vásárlása során dönthet, hogy 5% kedvezményt kér a számla összegéből, vagy a kártyán lévő pontjait növeli meg. Az a vásárló, akinek nincs ilyen kártyája, szintén megkaphatja az 5% kedvezményt, ha 50.000 Ft felett vásárol.

A bemeneti feltételek (okok) ebben az esetben:

  1. Van-e pont pontgyűjtő kártya?
  2. Kéri-e a kártyatulajdonos a kedvezményt?
  3. 50.000 Ft felett van-e a vásárlás összege?

A kimeneti feltételek (hatások):

  1. Nincs kedvezmény
  2. Kedvezmény jóváírása
  3. Pontok jóváírása

this is a text describes a picture

Eset 1:

Okok: Van pontgyűjtő kártya, nem kéri a vásárló a kedvezményt – mivel van kártyája, ebből következően érvénytelen az az ok, hogy a vásárlás összege eléri-e a kedvezményre jogosító összeget.

Hatások: A vásárló nem kap kedvezményt, így kedvezmény jóváírást sem kap, viszont megkapja a vásárlás utáni pontok jóváírását.

Eset 2:

Okok: Van pontgyűjtő kártya, és a vásárló igényt tart a kedvezményre – mivel van kártyája, ebből következően érvénytelen az az ok, hogy a vásárlás összege eléri-e a kedvezményre jogosító összeget.

Hatások: A vásárló megkapja a kedvezményt, jóvá is lesz írva a kártyáján, de így már pontgyűjtésre nem lesz jogosult.

Eset 3:

Okok: Nincs pontgyűjtő kártya, így a kedvezmény igénylése érvénytelen feltétel, és a vásárlás összege nem haladja meg az 50.000 Ft-ot.

Hatások: Mivel a vásárlás nem haladta meg a kedvezményre jogosító 50.000 Ft-ot, így kedvezményt nem kap – kártya hiányában pedig pont sem írható jóvá.

Eset 4:

Okok: Nincs pontgyűjtő kártya, így a kedvezmény igénylése érvénytelen feltétel, de a vásárlás összege meghaladja az 50.000 Ft-ot.

Hatások: Mivel az 50.000 Ft-os feltétel teljesült, így a vásárló jogosulttá válik a kedvezményre, melyet jóvá is írnak. (Pontot nem kap, mert nincs kártyája.)

A feladat összes kombinációja matematikailag így írható fel: 2³= 8 variációs lehetőség számolható ki (2 szorozva az okok számának hatványával). Mivel ez matematikai megközelítés, ami tesztelési szempontból értelmetlen variációkat is tartalmaz, értelemszerűen kiszűrjük ezeket.

Megosztás

Facebook
LinkedIn
Twitter

Nem szeretnél lemaradni az új bejegyzésekről?

Tartalomjegyzék

Egyéb
Erdei Krisztián

AI-t tesztelnél? Mutatunk egy módszert!

Az AI alkalmazások létrehozásában, szakértőként felhívjuk az ügyfelek figyelmét az ehhez kapcsolódó sajátosságokra. Mivel a szoftvertermékek speciálisak, a minőségbiztosításuk is az. Az AI alkalmazások teszteléséről,

Egyéb
Erdei Krisztián

Szoftvertesztelés a mesterséges intelligenciával

Mit nyerhetünk és mire vigyázzunk? A mesterséges intelligencia napjainkban egyre meghatározóbb szerepet tölt be a szoftvertesztelés területén. Az elmúlt egy év során jelentős változások történtek

Érdekel a tesztelés világa?

Dolgozz velünk hazai és nemzetközi projekteken

egy csoport ember ül egy asztalnál laptopokkal

Várj, ne maradj le legújabb szakmai cikkeinkről

Iratkozz fel hírlevelünkre és minden hónapban elküldjük a legizgalmasabb cikkeket

egy laptop számítógépet tartó szemüveges férfi
egy süti csokireszelékkel
Tájékoztatjuk, hogy a honlap felhasználói élmény fokozásának érdekében sütiket alkalmazunk. A honlapunk használatával ön a tájékoztatásunkat tudomásul veszi.