GUI Testing - Revision history

Juliant at 16:14, 6 November 2006

2006-11-06T16:14:10Z

2006-11-02T23:44:53Z

2006-11-02T22:43:49Z

2006-11-02T22:38:12Z

2006-11-02T22:38:03Z

2006-11-02T00:21:14Z

‎Capture & Replay

2006-11-02T00:20:03Z

‎Overview

2006-11-01T23:27:58Z

‎Capture & Replay

2006-11-01T23:24:43Z

‎Overview

2006-11-01T20:04:33Z

← Older revision		Revision as of 16:14, 6 November 2006
Line 45:		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]]

← Older revision		Revision as of 23:44, 2 November 2006
Line 58:		Line 58:

	http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications		http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications
		+
		+	http://c2.com/cgi/wiki?GuiTesting

← Older revision		Revision as of 22:43, 2 November 2006
Line 45:		Line 45:

	See '''[[GUI Replay]]''' for a discussion about test case execution.		See '''[[GUI Replay]]''' for a discussion about test case execution.
		+
		+
		+	==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

← Older revision		Revision as of 22:38, 2 November 2006
Line 27:		Line 27:


−	==Programmatic===	+	==Programmatic==

	Another approach is to specify the user interaction thoroughly programmatic. The programmer writes a script which then is executed on the AUT.		Another approach is to specify the user interaction thoroughly programmatic. The programmer writes a script which then is executed on the AUT.

← Older revision		Revision as of 22:38, 2 November 2006
Line 25:		Line 25:

	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.		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.

← Older revision		Revision as of 00:21, 2 November 2006
Line 21:		Line 21:


−	The test case can then be run (replayed) which sends the recorded event sequence to the AUT. During the replay it ~~checkis~~ if the current execution state of the AUT matches the defined assertions.	+	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.

@@ Line 7: / Line 7: @@
 *: 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.
+*: 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).

@@ Line 14: / Line 14: @@
 ==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 have some sort of protection against layout changes, caputred 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.
+The test case can then be run (replayed) which sends the recorded event sequence to the AUT. During the replay it checkis if the current execution state of the AUT matches the defined assertions.
 See '''[[GUI Capture]]''' for a discussion about the capturing part.

@@ 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:
 * Test case generation
-*: To generate a test case one has to specify the user interaction with the AUT and the properties that has to be checked.
+*: 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 and then the properties have to be checked.
+*: 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 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
-*: Depending on the type of GUI testing, even small layout changes in the AUT break all available tests.
+*: Depending on the type of GUI testing, even small layout changes in the AUT break the available tests.
 ==Capture & Replay==

@@ Line 23: / Line 23: @@
 See '''[[GUI Capture]]''' for a discussion about the capturing part.
-See '''[[GUI Test Case generation]]''' for a discussion about how to specify the test case.
+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.