CSC/ECE 517 Fall 2009/wiki2 10 mk: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
==Problem Statement==
==Problem Statement==
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing.  In this wiki we aim at covering the the different approaches, including patterns and tools for GUI testing.
Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing.  In this wiki we aim at covering the the different approaches, including patterns and tools for GUI testing.


==Some problems of GUI testing==
==Some problems of GUI testing==
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.  
*GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.  
*ScreenScrapper/Replay*givelink* based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no regression tests*givelink*. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: test harnesses, capture/replay tools, and model-based methods
*[http://en.wikipedia.org/wiki/Data_scraping#Screen_scraping ScreenScrapper] based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no [http://en.wikipedia.org/wiki/Regression_testing regression tests]. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: [http://en.wikipedia.org/wiki/Test_harness test harnesses], [http://www.citeulike.org/user/V/article/2682599 capture/replay tools], and [http://en.wikipedia.org/wiki/Model-based_testing model-based methods]
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the  usage of the GUI, only provides limited testing Example: JUnit
*The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the  usage of the GUI, only provides limited testing.
*There are tools which try to capture GUI widgets rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: Winrunner, Abbot, and Rational Robot4
*There are tools which try to capture [http://en.wikipedia.org/wiki/GUI_widget GUI widgets] rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: [http://en.wikipedia.org/wiki/HP_WinRunner Winrunner], [http://www.testingfaqs.org/t-gui.html#Abbot Abbot], and [http://www-01.ibm.com/software/awdtools/tester/robot/index.html Rational Robot]

Revision as of 22:55, 9 October 2009

GUI Testing Frameworks

Problem Statement

Most software developed in recent years has a graphical user interface (GUI). The only way for the end-user to interact with the software application is through the GUI. Hence, acceptance and system testing of the software requires GUI testing. In this wiki we aim at covering the the different approaches, including patterns and tools for GUI testing.

Some problems of GUI testing

  • GUIs are tested manually, often by the developers themselves. This is very unreliable and expensive. For new GUIs or those being significantly changed, quality is low, and failures at integration time or during user acceptance tests are common.
  • ScreenScrapper based GUI test does a nice job but to a certain extent. Even though they are cheap, the problem with these tests are that if you change the screen layout all existing tests become useless, which means you have no regression tests. Another problem here is that test creators can't start writing tests ill the GUIs are finished. Example: test harnesses, capture/replay tools, and model-based methods
  • The user has an extremely wide choice of actions. The user could click on any pixel on the screen using manual tools to mimic the usage of the GUI, only provides limited testing.
  • There are tools which try to capture GUI widgets rather than mouse coordinates. These tools, however, require a significant amount of manual effort to be effective, including developing test scripts and manually detecting failures.Modifications to the GUI require changes to the scripts as well. Example: Winrunner, Abbot, and Rational Robot
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki2_10_mk&oldid=24696"