Download feature - EE Times

feature
GUI testing traditionally meant finding the most appropriate access point to inject test cases.
The challenge, however, is in making the GUI tests repeatable. Here’s a homegrown framework that
allows test input to be managed, replacing manual test cases.
GUI testing—
exposing visual bugs
M
BY NIALL MURPHY
y approach to testing a graphical user interface (GUI) has always
been to find the most appropriate access point to manually inject
test cases. This article will discuss the challenges of trying to
make GUI tests repeatable, and we’ll look at a homegrown framework that allows test input to be managed.
To test a GUI, we need a framework
that gives us the ability to inject test cases easily and to observe the output. Ideally, in a test system, the output can be
stored, and then a subsequent test run
can be compared with a previous run to
provide regression testing. By regression
testing, we mean that we have proven
that the new version under test has not
broken anything that used to work for
the previous version.
If we consider a non-GUI issue like
message processing, you might intro-
duce a test set of messages and then the
application’s message store, or inbox, will
contain those messages. If the inbox
from one run is compared with the next,
there are two possible outcomes. The inboxes may be identical—this means that
the new functionality has not broken
previous features. In some cases, you
might have expected changes to result
from new functionality in the system
under test—in other words, the output
should have changed but didn’t, telling
us that the new features are not working.
www.embedded.com | embedded systems design
| DECEMBER 2009
25