GUI Testing

Revision as of 14:44, 2 November 2006 by Juliant (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

1 Overview
2 Capture & Replay
3 Programmatic
4 Hybrid
5 Sources

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.