Browse Prior Art Database

A Technique for Regression Testing a Graphical User Interface (GUI)

IP.com Disclosure Number: IPCOM000015978D
Original Publication Date: 2002-May-10
Included in the Prior Art Database: 2003-Jun-21
Document File: 6 page(s) / 97K

Publishing Venue

IBM

Abstract

Abstract

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

Page 1 of 6

A Technique for Regression Testing a Graphical User Interface (GUI)

Abstract

We have found that tools for regression testing a graphical user interface (GUI) are lacking. The tools for this purpose that are available in the marketplace generally use a pixel comparison algorithm. This approach has only been moderately successful because the tools must use some form of pixel averaging to determine if a given test shows a regression. They do this because there exists a large amount of data that comprises the complete pixel set, and to compare all pixels for an exact match would make for unacceptable performance. However, the averaging technique gives rise to false hits or missed hits for a given regression.

We present in this paper a technique for performing GUI regression testing that does not involve a pixel comparison algorithm. The thrust of the paper is that if one assumes that the libraries linked against will perform a perfect job of 'painting the glass,' then it is the sequence of calls (and the parameters for these calls) to these libraries that require testing. Hence, we define a language of output for each call to the libraries and create files that contain a unique sequence of these calls with unique data. The output files in turn are regressionable if we keep the input to the GUI consistent between runs. Thus, we can inexpensively and exactly run GUI regression tests.

ProblemWe want to use automated regression testing for our GUI (also called the front end) for the ICAT suite of debuggers. Given the difficulties with the current tools for GUI regression testing (described in the abstract above), we needed to invent a technique that is more exact and less expensive than algorithms using pixel comparisons.

The solution required acceptable performance, repeatability, exactness (or proper hit ratio), and minimal invasiveness for the product code. Additionally, the solution needed to be implementable cheaply.

Solution

The solution involves an assumption about the 'glass' of the workstation, the video graphic adapter (VGA), and the library provided (e.g., the GIMP Tool Kit (GTK+) or the User Interface Class Libraries (ICLUI) from IBM Visual Age C++) that paints the glass. The assumption is that all of these pieces do their jobs perfectly. With this simplifying assumption, the output to regression test is the input to the GUI library.

Further, we define a language to describe this input uniquely. Hence, the regressionable output

1

Page 2 of 6

is the sequence of input events to the library described by this language.

Design details

The ICAT GUI regression tests require:

- input drivers

- the creation of request blocks within the GUI

- back end stubbing (or simulation)

- a language definition for the input to the 'painting' library

- output files to compare

The details for each of these elements follow.

Definition and collection of regression test input drivers (files)

The GUI regression test itself needs repeatable input test d...