Tool Mentor:  Capturing the Results of Test Design for Automated Testing Using Rational TestFactory

Purpose

This tool mentor describes how to use Rational TestFactory to capture the design decisions from the Design Test activity.

Related Rational Unified Process™ information:

• Activity: Design Test, refer to the section titled "Identify and structure test procedures"

Overview

In Rational TestFactory, you capture design decisions from the Design Test activity in the “application map.”

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 95/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 procedure requirements

Supply test data for objects that represent text controls

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

2.   Set up interaction objects to reflect test procedure requirements

A test procedure in which all the test controls are located in the same window is a good candidate for testing in Rational TestFactory. An “interaction object” is the TestFactory tool that lets you specify the test procedure conditions 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 procedure requirements.

If you have more than one test procedure that tests controls in the same window, you can specify the requirements for each test procedure in a separate interaction object. A Pilot can test multiple interaction objects in the same window during a single 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 text controls

A Pilot rigorously tests all of the available UI objects 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 text.

If there are controls in your test procedures that require specific test data, you can use a “data entry style” to supply the necessary information. A data entry style is a group of the UI object properties that specify testing information for a text object:

A required string case that a 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 a control, 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

Rational Unified Process