Tool Mentor: Structuring
the Test Implementation with Rational TestFactory
Purpose
This tool mentor describes how to use Rational TestFactory to to begin structuring
the test implementation to to enable generated tests to be implemented.
Related Rational Unified Process information:
Overview
In Rational TestFactory, you start to structure the test implementation using
the “application map” feature.
A well-developed application map reflects an accurate representation of the
user interface in the application-under-test (AUT). Each window and control
in the AUT is represented by a “UI object” in the application map.
For information about developing the application map, see Tool
Mentor: Setting Up the Test Environment in Rational TestFactory.
This tool mentor is applicable when running Windows 98/2000/NT 4.0.
To use Rational TestFactory to capture the results of the test model for automated
testing:
- Identify the parts of the application that you
want to test
- Set up interaction objects to reflect
Test Script requirements
- Supply Test Data for objects that represent
text controls
- Restrict testing of specific objects
After you have developed the application map, you can determine the areas of
the AUT that are appropriate for testing in Rational TestFactory.
A “Pilot” is the Rational TestFactory tool that automatically generates
test scripts. The locations at which you place Pilots in the application map
determine the controls in the AUT that they can test. A Pilot can test all the
available UI objects in the map that are in the branch under the Pilot's parent
object. If a control is represented by a UI object in that branch of the map
and the object is available, the Pilot will test it.
Review the test procedures created during the Design Test activity, with the
objective of identifying:
- The controls that must be exercised in a specific order.
- The controls for which Test Data must be provided.
- The windows or dialog boxes in which the controls are displayed.
The UI objects in the application map that correspond to the windows, dialog
boxes, and controls that you identify are good candidates for testing by Pilots
in Rational TestFactory. You can specify how TestFactory must test a control
in the AUT by setting the property values of its corresponding UI object.
Refer to the following topics in Rational TestFactory Help:
Pilots: What they are and how they work
Effective Pilot placement
A Test Script in which all the controls are located in the same window is a
good candidate for testing in Rational TestFactory. An “interaction object”
is the TestFactory feature that lets you specify the Test Script interaction
method for such controls.
An interaction object is a container to which you can add one or more UI objects
as “components.” The interaction object components represent the controls
that need to be exercised to take a specific path or perform a specific task
in the AUT. After you add the components for the interaction, you can configure
them to meet the Test Script requirements.
If you have more than one Test Script that tests controls in the same window,
you can specify the requirements for each Test Script in a separate interaction
object. The Pilot feature of TestFactory can test multiple interaction objects
in the same window during a single Test Suite execution or Pilot run.
Refer to the Using interaction objects to set up specific tests topic
in Rational TestFactory Help:
The Pilot feature of TestFactory performs many tests on as many of the available
UI objects as possible in the specific area of the map to which it has access.
By default, a Pilot exercises the objects in a random order, and supplies random
data values to objects that require input.
If there are controls in your Test Script that require specific Test Data as
input, you can use a “data entry style” to supply the necessary input
information. A data entry style is a group of the UI object properties that
specify test input for a UI object:
- A required string case that a TestFactory Pilot must use.
- A list of string cases that act as a datapool that a Pilot can pick from
randomly.
- A list of mask cases for which Rational TestFactory generates string values
that a Pilot can pick from randomly.
- Options that let a Pilot generate random integer, floating point, and string
values.
Rational TestFactory provides a set of predefined system data entry
styles that reflect standard types of input. You can create additional custom
data entry styles that are based either on system styles or on existing custom
styles. You can also override the settings in a system style or a custom style
for an individual object.
Refer to the Using data entry styles for input-type objects topic in
Rational TestFactory Help:
By default, all the controls in the AUT that are represented by UI objects
in the application map are eligible for testing. If a Pilot encounters a UI
object as it follows a path through the application map, the Pilot can include
the UI object in a generated Test Script. However, your AUT might contain mapped
controls that you do not want Pilots to test. Some examples are:
- An unstable control
- A control whose functionality causes a destructive action
(for example, a control that deletes a database)
- A control that you do not want to test
(for example, a print control or a control that opens Help)
If your AUT contains such controls, you can exclude its associated UI object
from testing. You can also limit the test actions that a Pilot performs on a
control. The properties of the UI object associated with a control reflect the
possible actions that a user can perform on the control.
Refer to the following topics in Rational TestFactory Help:
Excluding UI objects from testing
Change UI object test actions
Copyright
© 1987 - 2001 Rational Software Corporation
| 
Tool Mentors >
Rational TestFactory Tool Mentors >
Structuring the Test Implementation with Rational TestFactory
