Difference between revisions of "GUI Testing"
| (8 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
In GUI Testing one wants to assert certain properties of a graphical application, the application under test (AUT). Certain problems arise in this area: | In GUI Testing one wants to assert certain properties of a graphical application, the application under test (AUT). Certain problems arise in this area: | ||
* Test case generation | * Test case generation | ||
| − | *: To generate a test case one has to specify the user interaction with the AUT and the properties that | + | *: To generate a test case one has to specify the user interaction with the AUT and the properties that have to be checked. |
* Test case execution | * Test case execution | ||
| − | *: To verify the test case | + | *: To verify the test case the AUT has to be executed as if the user would issue the commands. During the execution the properties and assertions defined for the test have to be checked. |
* Level of testing | * Level of testing | ||
| − | *: GUI Testing can occur on multiple levels: From high level (did an issued action do the right thing) to low level (did the popup-menu appear at the right position and the right font). | + | *: GUI Testing can occur on multiple levels: From high level (did an issued action do the right thing) to low level (did the popup-menu appear at the right position and with the right font). |
* Regression testing | * Regression testing | ||
| − | *: Depending on the type of GUI testing, even small layout changes in the AUT break | + | *: Depending on the type of GUI testing, even small layout changes in the AUT break the available tests. |
==Capture & Replay== | ==Capture & Replay== | ||
| + | |||
| + | One method of GUI testing is ''Capture & Replay'' | ||
| + | |||
To address the problem of test case generation, event capturing can be used. In this approach, the tester performs the desired test manually while a capturing tool records all events which occured. Into this sequence of events the tester then inserts assertions at the desired position. | To address the problem of test case generation, event capturing can be used. In this approach, the tester performs the desired test manually while a capturing tool records all events which occured. Into this sequence of events the tester then inserts assertions at the desired position. | ||
| − | |||
| − | To have some sort of protection against layout changes, | + | The test case can then be run (replayed) which sends the recorded event sequence to the AUT. During the replay it checks if the current execution state of the AUT matches the defined assertions. |
| + | |||
| + | |||
| + | To have some sort of protection against layout changes, captured events should not just depend on the mouse position but also on the underlying widgets. This means that the action is not issued on a position but on a (somehow identified) widget and thus is not affected when the widget changes position. | ||
| + | |||
| + | |||
| + | ==Programmatic== | ||
| + | |||
| + | Another approach is to specify the user interaction thoroughly programmatic. The programmer writes a script which then is executed on the AUT. | ||
| + | |||
| + | |||
| + | The advantage of this method is the independence of the GUI position. Since the programmer will execute the actions directly or through the internal object structure, the test case will be more robust to changes in the GUI. | ||
| + | |||
| + | |||
| + | ==Hybrid== | ||
| + | |||
| + | An improvement could be to combine the two strategies. First the tester can use a capturing tool to create a script. The script is saved in a format which should make it easy for the tester to make modifications. | ||
| + | |||
See '''[[GUI Capture]]''' for a discussion about the capturing part. | See '''[[GUI Capture]]''' for a discussion about the capturing part. | ||
| Line 26: | Line 45: | ||
See '''[[GUI Replay]]''' for a discussion about test case execution. | See '''[[GUI Replay]]''' for a discussion about test case execution. | ||
| + | |||
| + | |||
| + | ==Framework== | ||
| + | |||
| + | See more information about the framework in: | ||
| + | |||
| + | [[GUI Testing/Framework]] | ||
| + | |||
| + | |||
| + | ==Sources== | ||
| + | |||
| + | The information presented here is combined from various sources including: | ||
| + | |||
| + | http://members.tripod.com/bazman/checklist.html | ||
| + | |||
| + | http://members.tripod.com/bazman/auto.html | ||
| + | |||
| + | http://erngui.com/prog/perl/guitest/ | ||
| + | |||
| + | http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications | ||
| + | |||
| + | http://c2.com/cgi/wiki?GuiTesting | ||
Latest revision as of 07:14, 6 November 2006
Overview
In GUI Testing one wants to assert certain properties of a graphical application, the application under test (AUT). Certain problems arise in this area:
- Test case generation
- To generate a test case one has to specify the user interaction with the AUT and the properties that have to be checked.
- Test case execution
- To verify the test case the AUT has to be executed as if the user would issue the commands. During the execution the properties and assertions defined for the test have to be checked.
- Level of testing
- GUI Testing can occur on multiple levels: From high level (did an issued action do the right thing) to low level (did the popup-menu appear at the right position and with the right font).
- Regression testing
- Depending on the type of GUI testing, even small layout changes in the AUT break the available tests.
Capture & Replay
One method of GUI testing is Capture & Replay
To address the problem of test case generation, event capturing can be used. In this approach, the tester performs the desired test manually while a capturing tool records all events which occured. Into this sequence of events the tester then inserts assertions at the desired position.
The test case can then be run (replayed) which sends the recorded event sequence to the AUT. During the replay it checks if the current execution state of the AUT matches the defined assertions.
To have some sort of protection against layout changes, captured events should not just depend on the mouse position but also on the underlying widgets. This means that the action is not issued on a position but on a (somehow identified) widget and thus is not affected when the widget changes position.
Programmatic
Another approach is to specify the user interaction thoroughly programmatic. The programmer writes a script which then is executed on the AUT.
The advantage of this method is the independence of the GUI position. Since the programmer will execute the actions directly or through the internal object structure, the test case will be more robust to changes in the GUI.
Hybrid
An improvement could be to combine the two strategies. First the tester can use a capturing tool to create a script. The script is saved in a format which should make it easy for the tester to make modifications.
See GUI Capture for a discussion about the capturing part.
See GUI Testing/Test Case generation for a discussion about how to specify the test case.
See GUI Replay for a discussion about test case execution.
Framework
See more information about the framework in:
Sources
The information presented here is combined from various sources including:
http://members.tripod.com/bazman/checklist.html
http://members.tripod.com/bazman/auto.html
http://erngui.com/prog/perl/guitest/
http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications
