Testování grafického uživatelského rozhraní - Graphical user interface testing

v softwarové inženýrství, grafické testování uživatelského rozhraní je proces testování produkt grafické uživatelské prostředí aby bylo zajištěno, že splňuje jeho specifikace. To se obvykle provádí pomocí různých testovací případy.

Generování testovacích případů

Generovat sadu testovací případy, testovací designéři pokusit se pokrýt všechny funkce systému a plně procvičovat GUI sám. Obtíž při plnění tohoto úkolu je dvojí: vypořádat se s velikostí domény a se sekvencemi. Tester navíc musí čelit dalším obtížím regresní testování.

Na rozdíl od a CLI (rozhraní příkazového řádku), může mít GUI další operace, které je třeba otestovat. Relativně malý program jako např Microsoft WordPad má 325 možných operací GUI.[1] Ve velkém programu může být počet operací snadno řádově větší.

Druhým problémem je problém se sekvenováním. Některé funkce systému lze dosáhnout pouze sekvencí událostí grafického uživatelského rozhraní. Například pro otevření souboru může být nutné, aby uživatel nejprve klikl na nabídku Soubor, poté vybral operaci Otevřít, pomocí dialogového okna určil název souboru a zaměřil aplikaci na nově otevřené okno. Zvýšení počtu možných operací exponenciálně zvyšuje problém se sekvenováním. To se může stát vážným problémem, když tester vytváří testovací případy ručně.

Regresní testování je často výzvou i pro GUI. Grafické uživatelské rozhraní se může významně změnit, i když základní aplikace nikoli. Test navržený tak, aby sledoval určitou cestu v grafickém uživatelském rozhraní, může poté selhat, protože tlačítko, položka nabídky nebo dialogové okno mohly změnit umístění nebo vzhled.

Tyto problémy vedly problémovou doménu testování GUI k automatizaci. Pro automatické generování bylo navrženo mnoho různých technik testovací sady které jsou úplné a simulují chování uživatelů.

Většina testovacích technik se pokouší navázat na ty, které se dříve používaly k testování programů rozhraní příkazového řádku (CLI), ale při použití v grafických uživatelských rozhraních mohou mít problémy se škálováním. Například, Konečný státní stroj modelování na základě[2][3] - kde je systém modelován jako stroj s konečným stavem a program se používá ke generování testovacích případů, které procvičují všechny stavy - může dobře fungovat v systému, který má omezený počet stavů, ale může být pro GUI příliš složitý a nepraktický (viz taky modelové testování ).

Plánování a umělá inteligence

Nový přístup k generování testovacích sad, přizpůsobený technikou CLI[4] zahrnuje použití plánovacího systému.[5] Plánování je dobře prostudovaná technika z umělá inteligence (AI) doména, která se pokouší vyřešit problémy, které zahrnují čtyři parametry:

  • počáteční stav,
  • stav cíle,
  • - soubor operátorů a -
  • soubor objektů, se kterými lze pracovat.

Plánovací systémy určit cestu z počátečního stavu do stavu cíle pomocí operátorů. Jako jednoduchý příklad plánovacího problému, vzhledem ke dvěma slovům a jediné operaci, která nahradí jedno písmeno ve slově jiným, může být cílem změnit jedno slovo na jiné.

v [1] autoři použili plánovač IPP[6] předvést tuto techniku. Nejprve se analyzuje uživatelské rozhraní systému, aby se určily možné operace. Tito se stanou operátory použitými v problému plánování. Dále je určen počáteční stav systému a je specifikován stav cíle, o kterém se tester domnívá, že by umožnil cvičení systému. Systém plánování určuje cestu z počátečního stavu do stavu cíle, který se stane testovacím plánem.

Použití plánovače ke generování testovacích případů má oproti manuálnímu generování některé specifické výhody. Plánovací systém ze své podstaty generuje řešení problémů s plánováním způsobem, který je pro testera velmi přínosný:

  1. Plány jsou vždy platné. Výstupem systému je buď platný a správný plán, který používá operátory k dosažení stavu cíle, nebo vůbec žádný plán. To je výhodné, protože při ručním vytváření testovací sady může být zbytečné mnoho času kvůli neplatným testovacím případům, o kterých si tester myslel, že budou fungovat, ale ne.
  2. Systém plánování věnuje pozornost objednávce. K testování určité funkce musí být testovací případ často složitý a musí následovat cestu přes grafické uživatelské rozhraní, kde jsou operace prováděny v určitém pořadí. Pokud je provedeno ručně, může to vést k chybám a také může být poměrně obtížné a časově náročné.
  3. A konečně, a co je nejdůležitější, plánovací systém je zaměřen na cíl. Tester se zaměřuje na generování testovacích sad na to nejdůležitější, testuje funkčnost systému.

Při ručním vytváření testovací sady se tester více zaměřuje na to, jak testovat funkci (tj. Konkrétní cestu přes grafické uživatelské rozhraní). Pomocí plánovacího systému je o cestu postaráno a tester se může zaměřit na to, jakou funkci otestovat. Další výhodou toho je, že plánovací systém není při generování cesty nijak omezen a může často najít cestu, kterou tester nikdy neočekával. Tento problém je v boji velmi důležitý.[7]

Další metoda generování testovacích případů GUI simuluje začínajícího uživatele. Expertní uživatel systému má tendenci sledovat přímou a předvídatelnou cestu prostřednictvím grafického uživatelského rozhraní, zatímco začínající uživatel by sledoval náhodnější cestu. Začínající uživatel pravděpodobně prozkoumá více možných stavů grafického uživatelského rozhraní než odborník.

Potíž spočívá ve generování testovacích sad, které simulují využití systému „nováčkem“. Použitím Genetické algoritmy k řešení tohoto problému.[7] Cesty pro začátečníky v systému nejsou náhodné cesty. Za prvé, začínající uživatel se časem naučí a obecně nebude opakovaně dělat stejné chyby, a za druhé, začínající uživatel se řídí plánem a pravděpodobně má určité znalosti domény nebo systému.

Genetické algoritmy fungují následovně: sada ‚genů 'je vytvořena náhodně a poté jsou podrobena určitému úkolu. Geny, které nejlépe splní úkol, jsou zachovány a ty, které nikoli, jsou zahozeny. Proces se znovu opakuje s přežívajícími geny, které se replikují a zbytek sady se vyplní více náhodnými geny. Nakonec jeden gen (nebo malá sada genů, pokud existuje určitá prahová hodnota) bude jediným genem v sadě a je přirozeně nejvhodnější pro daný problém.

V případě testování grafického uživatelského rozhraní funguje metoda následujícím způsobem. Každý gen je v podstatě seznam náhodných celočíselných hodnot určité pevné délky. Každý z těchto genů představuje cestu přes GUI. Například pro daný strom widgetů by první hodnota v genu (každá hodnota se nazývá alela) vybrala widget, se kterým bude pracovat, následující alely by pak vyplnily vstup do widgetu v závislosti na počtu možných vstupů do widgetu (například rozevírací seznam by měl jeden vstup ... vybranou hodnotu seznamu). Úspěch genů hodnotí kritérium, které odměňuje nejlepší „nováčkovské“ chování.

Systém, který provádí toto testování pro okenní systém X, je však popsatelný v.[7] The X okno systém poskytuje funkčnost (přes XServer a protokol editorů) dynamicky odesílat vstup GUI do a získávat výstup GUI z programu bez přímého použití GUI. Například lze volat XSendEvent (), aby simuloval kliknutí v rozevírací nabídce atd. Tento systém umožňuje vědcům automatizovat tvorbu a testování genů, takže pro každou danou testovanou aplikaci lze vytvořit sadu testovacích případů pro začínající uživatele.

Spuštění testovacích případů

Nejprve byly strategie migrovány a adaptovány z testovacích strategií CLI.

Zachycení polohy myši

Populární metodou používanou v prostředí CLI je snímání / přehrávání. Přehrávání záznamu je systém, kde je obrazovka systému v různých časech během testování systému „zachycena“ jako bitmapová grafika. Toto zachycení umožnilo testeru „přehrát“ proces testování a porovnat obrazovky ve výstupní fázi testu s očekávanými obrazovkami. Toto ověření by mohlo být automatizováno, protože obrazovky by byly identické, pokud by případ prošel, a jiné, kdyby případ selhal.

Používání snímání / přehrávání fungovalo ve světě CLI docela dobře, ale při pokusu o jeho implementaci v systému založeném na GUI existují značné problémy.[8] Nejviditelnějším problémem, který člověk najde, je to, že obrazovka v systému GUI může vypadat jinak, zatímco stav základního systému je stejný, což ztěžuje automatické ověřování. Je to proto, že grafické uživatelské rozhraní umožňuje grafickým objektům měnit vzhled a umístění na obrazovce. Písma se mohou lišit, barvy nebo velikosti oken se mohou lišit, ale systémový výstup je v zásadě stejný. To by bylo zřejmé uživateli, ale není to zřejmé pro automatizovaný ověřovací systém.

Zachycení události

V boji proti tomuto a dalším problémům šli testeři „pod pokličku“ a shromažďovali data interakce GUI ze základního systému oken.[9] Zachycením „událostí“ okna do protokolů jsou nyní interakce se systémem ve formátu, který je oddělen od vzhledu grafického uživatelského rozhraní. Nyní jsou zachyceny pouze proudy událostí. Je nutné provést určité filtrování proudů událostí, protože proudy událostí jsou obvykle velmi podrobné a většina událostí přímo nesouvisí s problémem. Tento přístup lze usnadnit použitím MVC například architekturu a co nejjednodušší zobrazení (tj. zde GUI), zatímco model a řadič mají veškerou logiku. Dalším přístupem je použití softwaru vestavěný pomocná technologie, používat HTML rozhraní nebo a třívrstvá architektura díky tomu je také možné lépe oddělit uživatelské rozhraní od zbytku aplikace.

Dalším způsobem, jak spustit testy na grafickém uživatelském rozhraní, je zabudovat ovladač do grafického uživatelského rozhraní, aby bylo možné do softwaru odesílat příkazy nebo události z jiného programu.[7] Tato metoda přímého odesílání událostí do a přijímání událostí ze systému je při testování velmi žádoucí, protože vstupní a výstupní testování lze plně automatizovat a eliminovat chyby uživatelů.

Viz také

Reference

  1. ^ A b Atif M. Memon, Martha E. Pollack a Mary Lou Soffa. Využití přístupu založeného na cíli ke generování testovacích případů pro GUI. ICSE '99 Sborník z 21. mezinárodní konference o softwarovém inženýrství.
  2. ^ J.M. Clarke. Automatické generování testů z modelu chování. In Proceedings of Pacific Northwest Software Quality Conference. IEEE Press, květen 1998.
  3. ^ S. Esmelioglu a L. Apfelbaum. Automatické generování testů, jejich provádění a reportování. In Proceedings of Pacific Northwest Software Quality Conference. IEEE Press, říjen 1997.
  4. ^ A. Howe, A. von Mayrhauser a R. T. Mraz. Generování testovacích případů jako problém plánování AI. Automated Software Engineering, 4: 77-106, 1997.
  5. ^ Atif M. Memon, Martha E. Pollack a Mary Lou Soffa. Hierarchické generování testovacích případů GUI pomocí automatizovaného plánování. IEEE Trans. Softw. Eng., Sv. 27, č. 2, 2001, str. 144-155, IEEE Press.
  6. ^ J. Koehler, B. Nebel, J. Hoffman a Y. Dimopoulos. Rozšíření plánovacích grafů na podmnožinu ADL. Lecture Notes in Computer Science, 1348: 273, 1997.
  7. ^ A b C d D. J. Kasik a H. G. George. Směrem k automatickému generování testovacích skriptů pro začínající uživatele. In MJ Tauber, V. Bellotti, R. Jeffries, JD Mackinlay a J. Nielsen, redaktoři, Proceedings of the Conference on Human Factors in Computing Systems: Common Ground, strany 244-251, New York, 13. – 18. Dubna 1996, Stiskněte ACM. [1]
  8. ^ L.R. Kepple. Černé umění testování GUI. Dr. Dobb’s Journal of Software Tools, 19 (2): 40, únor 1994.
  9. ^ M. L. Hammontree, J. J. Hendrickson a B. W. Hensley. Integrované nástroje pro sběr a analýzu dat pro výzkum a testování na grafických uživatelských rozhraních. In P. Bauersfeld, J. Bennett a G. Lynch, redaktoři, Proceedings of the Conference on Human Factors in Computing System, strany 431-432, New York, NY, USA, květen 1992. ACM Press.