Grafikus felhasználói felület tesztelése

a tesztcsomag generálásának újszerű megközelítése, CLI technikából adaptálva, tervezési rendszer használatát foglalja magában. A tervezés egy jól tanulmányozott technika a mesterséges intelligencia (AI) tartományból, amely négy paramétert érintő problémákat próbál megoldani:

  • kezdeti állapot,
  • célállapot,
  • operátorok halmaza és
  • objektumok halmaza, amelyeken dolgozni kell.

a tervezési rendszerek az operátorok segítségével meghatározzák az útvonalat a kezdeti állapottól a célállapotig. A tervezési probléma egyszerű példájaként, ha két szót és egyetlen műveletet adunk, amely egy szó egyetlen betűjét helyettesíti egy másikkal, a cél az lehet, hogy az egyik szót egy másikra változtassuk.

a szerzők a tervező IPP-t használták ennek a technikának a bemutatására. A rendszer felhasználói felületét először elemzik a lehetséges műveletek meghatározása érdekében. Ezek válnak a tervezési problémában használt operátorokká. Ezután egy kezdeti rendszerállapotot határozunk meg, és egy olyan célállapotot határozunk meg, amely a tesztelő szerint lehetővé tenné a rendszer gyakorlását. A tervezési rendszer meghatározza az utat a kezdeti állapottól a célállapotig, amely teszttervvé válik.

a tervező használata a tesztesetek előállításához bizonyos előnyökkel jár a kézi generáláshoz képest. A tervezési rendszer természeténél fogva olyan megoldásokat generál a tervezési problémákra, amelyek nagyon hasznosak a tesztelő számára:

  1. a tervek mindig érvényesek. A rendszer kimenete vagy egy érvényes és helyes terv, amely az operátorokat használja a célállapot eléréséhez, vagy egyáltalán nincs terv. Ez azért előnyös, mert sok időt lehet pazarolni egy tesztcsomag kézi létrehozásakor olyan érvénytelen tesztesetek miatt, amelyekről a tesztelő úgy gondolta, hogy működni fog, de nem.
  2. a tervezési rendszer figyelmet fordít a megrendelésre. Gyakran egy bizonyos funkció teszteléséhez a tesztesetnek összetettnek kell lennie, és a GUI-n keresztül kell haladnia, ahol a műveleteket meghatározott sorrendben hajtják végre. Ha kézzel történik, ez hibákhoz vezethet, és meglehetősen nehéz és időigényes is lehet.
  3. Végül, és ami a legfontosabb, a tervezési rendszer célorientált. A tesztelő a tesztcsomag generálását a legfontosabbra összpontosítja, tesztelve a rendszer funkcionalitását.

tesztcsomag kézi létrehozásakor a tesztelő jobban összpontosít egy funkció tesztelésére (azaz a GUI-n keresztüli konkrét útvonalra). Egy tervezési rendszer használatával az útvonal gondoskodik, és a tesztelő arra összpontosíthat, hogy milyen funkciót teszteljen. Ennek további előnye, hogy a tervezési rendszer semmilyen módon nincs korlátozva az útvonal generálásakor, és gyakran találhat olyan utat, amelyet a tesztelő soha nem várt. Ez a probléma nagyon fontos a leküzdéshez.

a GUI tesztesetek generálásának másik módszere egy kezdő felhasználót szimulál. Egy szakértő felhasználó a rendszer hajlamos követni a közvetlen és kiszámítható utat egy GUI, míg a kezdő felhasználó követné egy véletlen utat. A kezdő felhasználó ezután valószínűleg több lehetséges GUI állapotot fedez fel, mint egy szakértő.

a nehézség abban rejlik, hogy olyan tesztkészleteket generálunk, amelyek szimulálják a ‘kezdő’ rendszerhasználatot. A probléma megoldására genetikai algoritmusokat javasoltak. A rendszeren keresztüli kezdő utak nem véletlenszerű utak. Először is, egy kezdő felhasználó idővel megtanulja, és általában nem követi el ugyanazokat a hibákat, másodszor pedig egy kezdő felhasználó követi a tervet, és valószínűleg rendelkezik valamilyen domain vagy rendszer ismeretekkel.

a genetikai algoritmusok a következőképpen működnek: a ‘gének’ halmaza véletlenszerűen jön létre, majd valamilyen feladatnak van kitéve. Azokat a géneket, amelyek a legjobban teljesítik a feladatot, megtartják, és azokat, amelyek nem, eldobják. A folyamat ismét megismétlődik a túlélő gének replikálásával, a készlet többi részét pedig több véletlenszerű gén tölti ki. Végül egy gén (vagy egy kis génkészlet, ha van valamilyen küszöbérték) lesz az egyetlen gén a készletben, és természetesen a legjobban illeszkedik az adott problémához.

GUI tesztelés esetén a módszer a következőképpen működik. Minden gén lényegében egy meghatározott hosszúságú véletlenszerű egész értékek listája. Ezen gének mindegyike utat képvisel a GUI-n keresztül. Például egy adott widget-fa esetében a gén első értéke (minden értéket allélnak nevezünk) kiválasztja a működtetni kívánt widgetet, majd a következő allélek kitöltik a widget bemenetét a widget lehetséges bemeneteinek számától függően (például egy lehúzható listamezőnek egy bemenete lenne…a kiválasztott listaérték). A gének sikerét egy olyan kritérium pontozza, amely jutalmazza a legjobb ‘kezdő’ viselkedést.

az X ablakrendszer tesztelésére szolgáló, de bármely ablakrendszerre kiterjeszthető rendszert a. Az X Window system (az xserveren és a szerkesztői protokollon keresztül) lehetővé teszi, hogy dinamikusan küldjön GUI bemenetet a programba, és megkapja a GUI kimenetet a programból anélkül, hogy közvetlenül használná a GUI-t. Például hívhatjuk az XSendEvent() függvényt, hogy szimuláljunk egy kattintást egy legördülő menüben, és így tovább. Ez a rendszer lehetővé teszi a kutatók számára, hogy automatizálják a gén létrehozását és tesztelését, így bármely vizsgált alkalmazáshoz egy sor kezdő felhasználói teszt eset hozható létre.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.

Previous post Grand Central csomagmegőrző + Szekrények
Next post szimbolikus színek Japánban