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:

1. Identify the parts of the application that you want to test
2. Set up interaction objects to reflect Test Script requirements
3. Supply Test Data for objects that represent text controls
4. Restrict testing of specific objects

1.   Identify the parts of the application that you want to test

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 task, 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

2.   Set up interaction objects to reflect Test Script requirements

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:

3.   Supply Test Data for objects that represent input controls

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:

4.   Restrict testing of specific objects

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