|
For the technically interested this page offers a view behind
the scenes and explains some of the more advanced features of
QF-Test.
How it works
We are using the term System Under Test (SUT) for the
applications being tested, because it is possible to start any
number of programs from QF-Test to test a whole system at
once.
When the SUT is started by QF-Test, Java applications are
run in separate Java Virtual Machines (JVM). An extra layer of
code is executed to set up an RMI connection to QF-Test and
to install a custom EventQueue before control is
handed to the SUT itself. The EventQueue is needed
to keep track of all the GUI components in the SUT and to record
events. Special care has been taken to avoid that QF-Test
interferes with possible private EventQueues of
the SUT.
When QF-Test is replaying a test-sequence, the event data is
sent together with the data for the target component via the RMI
connection to the extra layer in the SUT. A robust algorithm for
component recognition is used to determine the component that
should receive the event. If the developers agree to set unique
names for interesting components, the component recognition is
foolproof. But even without names recognition is excellent,
because it is not just based on geometry. QF-Test takes the
hierarchical structure of the GUI into account and makes use of
whatever data is available for a component, like titles or
labels (even associated ones).
Finally the event is constructed and inserted artificially into
the system's EventQueue. To the SUT it is
indistinguishable whether an event was triggered by an actual
user or by QF-Test. These artificial events are more
reliable than "hard" events that could be generated with the
help of the AWT-Robot, for example, which could be used to
actually move the mouse cursor across the screen. Such "hard"
events can be intercepted by the operating system or other
applications. QF-Test employs the AWT-Robot only for simulation of Drag&Drop and for
illustrative purposes like self-running demonstrations, which
are more impressive if the mouse cursor follows the action.
All of the above and more is explained in detail in the technical reference of the
user manual.
Following is a list of miscellaneous features:
Component representation
The GUI components of the SUT are represented as individual
objects and are thus directly available to the tester.
Sub-items of complex components
For the complex components like lists, tables or trees
QF-Test provides special support to access their
contents. For example it is possible to check the contents
of a table cell or to target a mouse click relative to a
node of a tree, identifying the node by its displayed text,
independent of its position in the tree.
Tolerant timing
One of the major obstacles to executing an automatic test is
the fact that the runtime behavior exhibited by a program
changes with every run, depending on processor or network
load, the phase of the moon, etc. Small delays up to a
configurable limit are handled by QF-Test
automatically. Longer foreseeable delays can be handled
explicitely.
Variables and procedures
Common test patterns can be moved to procedures which
can be called from anywhere in a test suite. They can
be parameterized, making them highly reusable. A
similar mechanism lets you store static or dynamic
information in variables that can be retrieved later
during a test run. That way you can fetch the
contents of a table cell to compare them later to a
value displayed in a text field, for example.
References across files
Procedures can be called across file boundaries to support
the creation of shared libraries of common functions for
reuse in multiple tests.
Jython and Groovy scripting
Jython and Groovy interpreters are embedded into both QF-Test
itself and the SUT. The scripts can make use of
QF-Test's component recognition mechanism to get hold of
the actual Java components of the SUT. Since the whole
public Java API is readily accessible from scripts,
possibilities are endless.
|
