background image
<< Running Scripts to Check for Memory Errors | Create a custom style >>
<< Running Scripts to Check for Memory Errors | Create a custom style >>

Testing Controls in the AUT

Testing Controls in the AUT During Pilot Runs
5-39
Testing Controls in the AUT During Pilot Runs
Before you run a Pilot to test a functional area of the AUT, you can modify the
testing environment to ensure that your Pilots generate robust, stable scripts. This
section provides information about how to improve test results by selecting and
modifying the data entry styles used to test input controls, and by modifying the
properties of UI objects and interaction object components.
TestFactory exercises controls in the AUT differently during mapping than it does
during Pilot runs. The two major ways in which TestFactory behaves different
during mapping and testing are as follows:
þ
The Application Mapper exercises controls in a systematic fashion, while a Pilot
exercises controls in a more unpredictable fashion. For example, after mapping
starts, the Application Mapper exercises any interaction objects it finds before it
exercises UI objects located at the same level of the application map hierarchy.
After a Pilot run starts, TestFactory randomly exercises the objects it encounters.
It does not necessarily exercise an interaction object before it exercises
UI objects located at the same level of the application map hierarchy.
þ
TestFactory uses a wider variety of data entry types to test an input control in the
AUT than it uses to map it. For example, to exercise an input control during
mapping, the Application Mapper can use a required string case that you have
specified, or mouse actions such as double-left-click or right-click. To test the
same control, a Pilot can use several different types of entry data, including
required string cases, mask cases, as well as randomly-generated string cases,
integer values, and floating point values.
Without some direction from you, a Pilot can spend much of its run time testing
negative cases. To introduce more focus to your Pilots runs, you can assign data entry
styles to and modify the properties of UI objects and UI object components in the
application map. This section describes how to provide some direction to
TestFactory behavior during testing so that your Pilots generate rich scripts that
touch as much of the AUT source code and uncover as many defects as possible.
Selecting a Style and Modifying Data Entry Settings for UI Objects
and UI Object Components
If you run a Pilot to test an area of the AUT that contains an input control, the Pilot
uses a set of default entry data to exercise the control. The default entry data consists
of randomly-generated integers, float values, and string values. You can view the
default test data by clicking an input UI object in the application map and expanding
the Pilot properties in the Properties view.