Your actions as you use the application-under-test. These user actions include keystrokes and mouse clicks that help you navigate through the application.
The Recording Process Part1
When you record a GUI script, Robot records:
Your actions as you use the application-under-test. These user actions include keystrokes and mouse clicks that help you navigate through the application.
Verification points that you insert to capture and save information about specific objects. A verification point is a point in a script that you create to confirm the state of an object across builds. During recording, the verification point captures object information and stores it as the baseline. During playback, the verification point recaptures the object information and compares it to the baseline.
The recorded GUI script establishes the baseline of expected behavior for the application-under-test. When new builds of the application become available, you can play back the script to test the builds against the established baseline in a fraction of the time that it would take to perform the testing manually.
The Recording Workflow
Typically, when you record a GUI script, your goal is to:
Record actions that an actual user might perform (for example, clicking a menu command or selecting a check box).
Create verification points to confirm the state of objects across builds of the application-under-test (for example, the properties of an object or the text in an entry field).
The following figure outlines the general process for recording a GUI
script.
Before You Begin Recording
You should plan to use Robot at the earliest stages of the application development and testing process. If any Windows GUI objects such as menus and dialog boxes exist within the initial builds of your application, you can use Robot to record the corresponding verification points.
Consider the following guidelines before you begin recording:
Establish predictable start and end states for your scripts.
Set up your test environment.
Create modular scripts.
Create Shared Projects with UNC.
These guidelines are described in more detail in the following sections.
Establishing Predictable Start and End States for Scripts
By starting and ending the recording at a common point, scripts can be played back in any order, with no script being dependent on where another script ends. For example, you can start and end each script at the Windows desktop or at the main window of the application-under-test.
Setting Up Your Test Environment
Any windows that are open, active, or displayed when you begin recording should be open, active, or displayed when you stop recording. This applies to all applications, including Windows Explorer, e-mail, and so on. Robot can record the sizes and positions of all open windows when you start recording, based on the recording options settings. During playback, Robot attempts to restore windows to their recorded states and inserts a warning in the log if it cannot find a recorded window. In general, close any unnecessary applications before you start to record. For stress testing, however, you may want to deliberately increase the load on the test environment by having many applications open.
Creating Modular Scripts
Rather than defining a long sequence of actions in one GUI script, you should define scripts that are short and modular. Keep your scripts focused on a specific area of testing for example, on one dialog box or on a related set of recurring actions.
When you need more comprehensive testing, modular scripts can easily be called from or copied into other scripts. They can also be grouped into shell scripts, which are top-level, ordered groups of scripts.
The benefits of modular scripts are:
They can be called, copied, or combined into shell scripts.
They can be easily modified or rerecorded if the developers make intentional
changes to the application-under-test.
They are easier to debug.
Creating Shared Scripts with UNC
When projects containing GUI or Manual scripts are to be shared, create the project in a shared directory using the Uniform Naming Convention (UNC). UNC paths are required for GUI test scripts and Manual test scripts that are run on Agent computers. For more information about creating a shared directory, see the Rational Suite Administrators Guide or the Rational Administrator Help.
Enabling IDE Applications for Testing
Robot provides specialized support for testing the objects in applications that are created in many integrated development environments (IDEs).
To successfully test the objects in Oracle Forms, HTML, Java, C++, Delphi, and Visual Basic 4.0 applications, you need to enable the applications as follows before
you start recording your scripts:
Oracle Forms Install the Rational Test Enabler for Oracle Forms. Run the Enabler to have it add the Rational Test Object Testing Library and three triggers to the .fmb files of the application.
HTML While recording or editing a script, use the Start Browser toolbar button from Robot to start Interne Explorer or Netscape Navigator if they are not already running.
Java Run the Java Enabler to have it scan your hard drive for Java
environments such as Web browsers and Sun JDK installations that Robot
supports. The Java Enabler only enables those environments that are currently installed.
C/C++ To test the properties and data of ActiveX controls in your applications, install the Rational ActiveX Test Control. This is a small, nonintrusive custom control that acts as a gateway between Robot and your application. It has no impact on the behavior or performance of your application and is not visible at runtime. Manually add the ActiveX Test Control to each OLE container (Window) in your application. For instructions, see the documentation that
comes with your C/C++ development environment.
Visual Basic 4.0 Install the Rational Test Enabler for Visual Basic. Attach the Enabler to Visual Basic as an add-in. Have the Enabler add the Rational ActiveX Test Control to every form in the application. This is a small, nonintrusive custom control that acts as a gateway between Robot and your application. For information, see Visual Basic support, making Visual Basic applications testable in the
Robot Help Index.
Delphi Install the Rational Object Testing Library for Delphi and the Rational Test Delphi Enabler. Run the Enabler, and then recompile your project to make it Delphi testable. For information, see Chapter 17, Testing Delphi Applications.
You can install the Enablers and the ActiveX Test Control from the Rational Software Setup wizard. For instructions, see the Rational Server Products Installation Guide.
Setting GUI Recording Options
GUI recording options provide instructions to Robot about how to record and
generate GUI scripts. You can set these options either before you begin recording or early in the recording process.
To set the GUI recording options:
1. Open the GUI Record Options dialog box by doing one of the following:
Before you start recording, click Tools > GUI Record Options.
Start recording by clicking the Record GUI Script button on the toolbar. In the Record GUI dialog box, click Options.
2. Set the options on each tab.
3. Click OK.
Naming Scripts Automatically
Robot can assist you in assigning names to scripts with its script autonaming feature.
Autonaming inserts your specified characters into the Name box of a new script and appends a consecutive number to the prefix.
This is a useful feature if you are recording a series of related scripts and want to identify their relationship through the prefix in their names. For example, if you are testing the menus in a Visual Basic application, you might want to have every script
name start with VBMenu.
To turn on script autonaming:
1. Open the GUI Record Options dialog box.
2. In the General tab, type a prefix in the Prefix box.
Clear the box if you do not want a prefix. If the box is cleared, you need to type a name each time you record a new script.
3. Click OK or change other options.
The next time you record a new script, the prefix and a number appear in the Name box of the Record GUI dialog box.
In the following figure, the autonaming prefix is Test. When you record a new script, Test7 appears in the Name box because six other scripts begin with Test.
If you change the script autonaming prefix by clicking Options in the Record GUI dialog box, changing the prefix, and then clicking OK, the name in the Name box changes immediately.
Controlling How Robot Responds to Unknown Objects
During recording, Robot recognizes all standard Windows GUI objects that you click, such as check boxes and list boxes. Each of these objects is associated with one of a fixed list of object types. The association of an object with an object type is generally based on the class name of the window associated with the object.
During recording, Robot recognizes all standard Windows GUI objects that you click, such as check boxes and list boxes. Each of these objects is associated with one of a fixed list of object types. The association of an object with an object type is generally based on the class name of the window associated with the object.
The prefix in the Script autonaming box appears as the name of the new script. A consecutive number is appended to the prefix.
Click to change the prefix for script autonaming.
Robot also recognizes many custom objects defined by IDEs that Robot supports, such as Visual Basic, Oracle Forms, Java, and HTML. For example, if you click a Visual Basic check box, Robot recognizes it as a standard Windows check box. This mapping is based on the objects Visual Basic assigned class name of ThunderCheckBox.
These built-in object mappings are delivered with Robot and are available to all users no matter which project they are using.
During recording, you might click an object that Robot does not recognize. In this case, Robots behavior is controlled by a recording option that you set. You can have Robot do either of the following:
Open the Define Object dialog box, so that you can map the object to a known object type. Mapping an object to an object type permanently associates the class name of the
objects window with that object type, so that other objects of that type are recognized.
Automatically map unknown objects encountered while recording with the Generic object type. This permanently associates the class name of the unknown objects window with the Generic object type.
This is a useful setting if you are testing an application that was written in an IDE for which Robot does not have special support and which therefore might contain many unknown objects. When an object is mapped to the Generic object type, Robot can test a basic set of its properties, but it cannot test the special properties associated with a specific object type. Robot also records the objects x,y coordinates instead of using the more reliable object recognition methods to identify the object.
These custom object mappings are stored in the project that was active when the mappings were created.
To control how Robot behaves when it encounters an unknown object during recording:
2. In the General tab, do one of the following:
Select Define unknown objects as type Generic to have Robot
automatically associate unknown objects encountered while recording with the Generic object type.
Clear Define unknown objects as type Generic to have Robot suspend
recording and open the Define Object dialog box if it encounters an
unknown object during recording. Use this dialog box to associate the
object with an object type.
3. Click OK or change other options.
Selecting an Object Order Preference
Robot uses a variety of object recognition methods to uniquely identify objects in the application-under-test that are acted on during recording sessions. For example, Robot can identify a check box in the application-under-test by its object name, associated label or text string, index value, or ID value.
These recognition methods are saved as arguments in script commands so that Robot can correctly identify the same objects during playback.
Robot has two predefined preferences for the recognition method order for each standard object type. While recording an action on an object, Robot tries each method within the selected preference in sequence until it finds a method that uniquely identifies the object.
The following table describes the two predefined preferences.
To change the object order preference:
1. Open the GUI Record Options dialog box. (See Setting GUI Recording Options
on page 2-5.)
2. Click the Object Recognition Order tab.
3. Select a preference in the Object order preference list.
4. click Ok.
This will continue in The Recording Process Part2..Keep visting the site..
Subscribe to this comment's feed
| < Prev | Next > |
|---|
