RATIONAL ROBOT

Searched and learnt from the link:

http://forum.onestoptesting.com/forum_posts.asp?TID=6715

Learning Basics of Rational Robot

1. Features of Rational Robot

Rational Robot is an automated functional, regression testing tool for automating
Windows, Java, IE and ERP applications under windows platform. Rational Robot
provides test cases for common objects such as menus, lists, bitmaps and specialized test
cases for objects specific to the development environment. It integrates with tools like
Rational Test Manager, Rational Clearquest and Requisite Pro in the Rational Unified
Processor for Defect Tracking, Change Management and Requirement Traceability. It
also supports UI technologies like Java, the Web, all VS.NET controls, Oracle Forms,
Borland Delphi and Sybase Power Builder applications.

2. Rational Administrator
It is a tool for managing associations between Rational artifacts such as Test Datastores,
Requisite Pro projects and Rose models.

• Rational Projects are created using Rational Administrator

• Users and Groups can be maintained
• Project assets can be upgraded

3. Recording Options
Using Object oriented technology, Robot identifies an object by its name property not by
its location coordinates. There are two different options

• GUI - Functional Testing

• VU - Performance Testing

4. SQABasic language
SQABasic is similar to Microsoft Visual Basic. All the scripts will be in scriptname.rec
format. When you playback the script, Robot automatically compiles and runs the
script, which repeats your actions and executes the verification points.

5 Shell Scripts
It is a master script that calls other automated scripts and plays them back in sequence.
“callscript test1” is a command to call script named test1. Combined into a single shell
script, scripts can run in unattended mode and perform comprehensive test coverage. It
centralizes test results into one test log.

6 Low level Recording

Turn “Low Level Recording On” in Robot during recording, mouse and keyboard
actions are automatically stored in an external file.

7 Verification Points
Verification points verify that a certain action has taken place, or verify the state of an
object. There are 11 Verification points in Robot

• Alpha-numeric : Verifies alphanumeric data. Used for edit boxes,

pushbuttons, labels, text fields, etc.,
• Object Properties: Tests object attributes such as color, font and position.
• Menu: Verifies the menu values and optionally their state (enabled or disabled)
of a window
• Clip Board: Verifies the contents of the windows clipboard
• Window Existence: Tests to see if a particular window does or does not exist
on the screen.
• Region Image: Graphically compares an area of the screen you specify
• Window Image: Graphically compares an entire window such as a window box.
• Object Data: Test data contents of objects(eg. Dropdown)
• File Comparison: Compares the contents of the two files (size and the contents)
• File Existence: Checks for the existence of a specified file
• Module Existence: Used to verify whether a specified module is loaded into a
specified context, or loaded anywhere in memory.

When you are creating verification points, there will be two options – Wait State and
expected Results.
Wait states are useful when AUT requires an unknown amount of time to complete a
task. Using a wait state keeps the verification point form failing if the task is not
completed immediately or if the data is not accessible immediately.
Expected Results – Click Pass or Fail in the Verification Point Name dialog box.

8 Variable Window
During debugging, if you want to examine variable and constant values, you can
variables window. View->Variables.

9. Object Mapping
If AUT contains a custom object or any object that Robot does not recognize, you
can create a custom object mapping before start recording. By adding the object’s
class to the list of classes that Robot recognizes, and then associating the class to a
standard object type. Robot saves this custom class/object type mapping in the
project and uses it to identify the custom object during playback.

10 Debug Tools

Animate(F11) – Animation mode allows you to see each line of script as it executes.
Step Over(F10) – Use to execute a single command line within a script
Step Into(F8) – Use to being single step execution
Step Out(F7) – Use to step out of the called script and return to the calling script.
Go Until Cursor(F6) – Use to play back the active GUI script, stopping at the text
cursor location.

11 Library Files and Header Files

Header files have .sbh extensions and contain the procedure declarations and global
variables referred to in your script files. There are two types of library files. Those
with .sbl extensions can’t have verification points. Those with .rec extensions are stored
in the project and can have verification points. Both Header and library are in
\SQABAS32 in the project directory.

12 Image Masks used for dynamic objects

Image masks are used to hide an area of the screen. When you play back a script that
contains an Image VP and a mask, Robot ignores the masked area when comparing
actual results to the recorded baseline.

13 Data Pool
A Datapool is a test dataset that supplies data variables in a test script during playback.
Using datapools allows you to run multiple iterations of a script using different data each
time. It can be created and managed using Test Manager for data driven tests.

Features of Rational Robot:

1. It is a tool which is used to automate functional, regression testing of

client/server, web, ERP applications which are developed on wide range of
environments.

2. Rational Robot provides test cases for common objects such as menus, lists,
bitmaps and specialized test cases for objects specific to the development
environment.

3. It integrates with tools like Rational Test Manager, Rational Clearquest and
Requisite Pro in the Rational Unified Processor for Defect Tracking, Change
Management and Requirement Traceability. It supports windows platform.

4. It reduces the time and man power spent on functional testing. It covers both
visible and invisible objects. It also supports multiple UI technologies.

Components of Rational Robot:

 • Rational Administrator

• Rational Site Check

• Rational Test Manager Log

• Object properties, text, image, grid comparators

Rational Administrator:

1. It is a tool for managing associations between Rational artifacts such as Test

Datastores, Requisite Pro projects and Rose models.

2. It is used to create and manage projects and we associate Test Datastore,

Clearquest Datastore, Requisitepro Datastore and Rose Models.

Uses of Rational Administrator:

1. Create and manage rational projects within or outside configuration

management.

2. Connect, Delete, and Register (to see projects that are not in the machine) a
project.

3. Create and manage users and groups for rational test datastore.

4. Create and manage projects that contain rational requisitepro projects and
rational rose models.

5. Configure a SQL anywhere database server.

6. Manage security privileges for the entire rational projects.

Project:

1. Projects are created in rational administrator by someone having the

administrator privileges.

2. Projects are used to store testing information’s such as queries, verification

points, scripts and defects.

3. Projects are used to organize testing information’s and resources for easy
tracking.
 4. Each project has a database and several directory files.

5. Each rational component updates and retrieves the data from the active
project.

Rational Test Manage Log:

It is used to review and analyze the test results.

Rational Site Check:

It is used to manage internet and intranet websites.

Text, Grid and Image Comparator:

It is used to view and analyze the verification point playback.

Recording Options:

Using Object oriented technology; Robot identifies an object by its name

property not by its location coordinates. There are two different options

• GUI (Graphical User Interface) - Functional Testing

• VU (Virtual User) - Performance Testing

SQA Basic language:

SQABasic is similar to Microsoft Visual Basic. All the scripts will be in

scriptname.rec format. When you playback the script, Robot automatically
compiles and runs the script, which repeats your actions and executes the
verification points.

Shell Scripts:

It is a master script that calls other automated scripts and plays them back in
sequence. “callscript test1” is a command to call script named test1. Combined into
a single shell script, scripts can run in unattended mode and perform
comprehensive test coverage. It centralizes test results into one test log.

Low level Recording:

Turn “Low Level Recording On” in Robot during recording, mouse and
keyboard actions are automatically stored in an external file.
Verification Points:

Verification points verify that a certain action has taken place, or verify the
state of an object. It is also defined as the location in the instruction where the actual
result is compared with the expected result. There are 11 Verification points in
Robot

1. Alpha-numeric: Verifies alphanumeric data. Used for edit boxes, push

buttons, labels, text fields, etc….

2. Object Properties: Tests object attributes such as color, font and position.

3. Menu: Verifies the menu values and optionally their state (enabled or
disabled) of a window.

4. Clip Board: Verifies the contents of the windows clipboard.

5. Window Existence: Tests to see if a particular window does or does not exist
on the screen.
6. Region Image: Graphically compares an area of the screen you specify.

7. Window Image: Graphically compares an entire window such as a window

box.

8. Object Data: Test data contents of objects (e.g. Dropdown).

9. File Comparison: Compares the contents of the two files (size and the
contents).

10. File Existence: Checks for the existence of a specified file.

11. Module Existence: Used to verify whether a specified module is loaded into a
specified context, or loaded anywhere in memory.

When you are creating verification points, there will be two options – Wait State
and expected Results.

Wait states: Are useful when AUT requires an unknown amount of time to
complete a task. Using a wait state keeps the verification point from failing if the
task is not completed immediately or if the data is not accessible immediately.

Expected Results: Click Pass or Fail in the Verification Point Name dialog box.
Variable Window:

During debugging, if you want to examine variable and constant values, you
can Variable Window. View->Variables.

Object Mapping:

If AUT contains a custom object or any object that Robot does not recognize,
you can create a custom object mapping before start recording. By adding the
object’s class to the list of classes that Robot recognizes, and then associating the
class to a standard objects type. Robot saves this custom class/object type mapping
in the project and uses it to identify the custom object during playback.

Debug Tools:

1. Animate (F11) – Animation mode allows you to see each line of script as it
executes.

2. Step Over (F10) – Use to execute a single command line within a script.

3. Step Into (F8) – Use to begin single step execution.

4. Step Out (F7) – Use to step out of the called script and return to the calling
script.

5. Go Until Cursor (F6) – Use to play back the active GUI script, stopping at
the text cursor location.

Library Files and Header Files:

Header files have .sbh extensions and contain the procedure declarations and
global variables referred to in your script files. There are two types of library files.
Those with .sbl extensions can’t have verification points. Those with .rec extensions
are stored in the project and can have verification points. Both Header and library
are in \SQABAS32 in the project directory.

Image Masks used for dynamic objects:

Image masks are used to hide an area of the screen. When you play back a
script that contains an Image VP and a mask, Robot ignores the masked area when
comparing actual results to the recorded baseline.
Data Pool:

A Datapool is a test dataset that supplies data variables in a test script during
playback. Using datapools allows you to run multiple iterations of a script using
different data each time. It can be created and managed using Test Manager for
data driven tests.

Data pools pump different kind of test data into script each time a script
sends data to the server. During playback, script sends transactions.

A data pool consists of two files:

1. Data pool values are stored in text file with (.CSV extension)

2. Data pool column names are stored in (.SPC file)

.CSV and .SPC files are stored in data pool directory of your process.
Rational Test Manager:

To plan tests, manage test assets and to run queries and reports. It is used to

• Plan scripts: Records a script file.

• Create manage and run queries.

• Create manage and run reports.

• Create, manage log folders and logs.

Features of Test Manager:

1. TestManager is the open and extensible framework that unites all of the
tools, assets, and data both related to and produced by the testing effort.

2. Under this single framework, all participants in the testing effort can define
and refine the quality goals they are working toward.

3. It is where the team defines the plan it will implement to meet those goals.
And, most importantly, it provides the entire team with one place to go to
determine the state of the system at any time.
 4. Testers use TestManager to see what work needs to be done by whom and by
what date. Testers can also see what areas of their work are affected by
changes happening elsewhere in the development effort.

Test Manager Workflow:

The TestManager workflow supports the major testing activities:

• Planning tests

• Designing tests

• Implementing tests

• Executing tests

• Evaluating tests

Plan Test:

The activity of test planning is primarily answering the question,

"What do I have to test?" When you complete your test planning, you end up
with a test plan that defines what you are going to test. In TestManager, a test
plan can contain test cases. The test cases can be organized based on test case
folders.

Design Test:

The activity of test designing is primarily answering the question, "How am I

going to do a test?" When you complete your test designing, you end up with a test
design that helps you understand how you are going to perform the test case. In
TestManager, you can design your test cases by indicating the actual steps that need
to occur in that test. You also specify the pre-conditions, post-conditions, and
acceptance criteria.

Implement Test:

The activity of implementing your tests is primarily creating reusable scripts.

In TestManager, you can implement your tests by creating manual scripts. You can
also implement automated tests by using Rational Robot. You can extend
TestManager through APIs so that you can access your own implementation tools
from TestManager. Because of this extensibility, you can implement your tests by
building scripts in whatever tools are appropriate in your situation and
organization.

Execute Tests:

The activity of executing your tests is primarily running your scripts to make
sure that the system functions correctly. In TestManager, you can run any of the
following: (1) an individual script, which runs a single implementation; (2) one or
more test cases, which run the implementations of the test cases; (3) a suite, which
runs test cases and their implementations across multiple computers and users.

Evaluate Tests:

The activity of evaluating tests is determining the quality of the system-

under-test. In TestManager, you can evaluate tests by examining the results of test
execution in the test log, and by running various reports.

Rational Clear Quest:

1. Rational Clear Quest is a powerful and highly flexible defect and change
tracking system that captures and manages all types of change requests
throughout the development lifecycle, helping organizations quickly deliver
higher quality software.

2. Clear Quest scales to support projects of any size and integration with other
development solutions ensures that your entire team is tied into the defect
and change tracking process.

3. Used by everyone to Submit, modify and track changes in records and to

analyze the progress of the project by running queries, charts and reports.

4. Clear quest web: Used by everyone, to access clear quest across multiple
platforms through Netscape navigator, I.E., you can submit change requests
and run queries, charts and reports.

Rational Pure coverage:

 1. It automatically evaluates the completeness of your testing and pinpoints the
parts of code you are failing to reach.

2. It automatically evaluates what percentage of code has and has not been
exercised.

3. Identifies untested or insufficiently tested, functions procedures or methods.

4. Locates individually untested lines in your source code.

5. Customize data collection for max efficiency.

6. Merge’s and coverage’s data from multiple runs of a program.

Rational Purify:

Rational Purify is a run-time memory related error detection tool. It can

discover almost all kinds of memory related errors and helps programmers to get to
the root of the run time problems.
Refer: http://www.cs.cmu.edu/~aldrich/courses/654/tools/zhao-purify-02.pdf

Features and Benefits:

1. It can automatically pinpoints hard-to-find illegal memory accesses and

memory leaks in C/C++. It can find memory management issues in Java, C#,
VB and .NET code. It can check errors in Web Server code including JSP
and Jam Servlets.

2. It can check not only users’ source codes, but also libraries and even
components, No matter whether there are source codes for them. Code
coverage data that pinpoints untested code.

3. It permits programmers to control the error checking level for each code
module. It can quickly analyze executables, without any rebuilding.
Rational Quantify:

• It is used to identify bottlenecks and then reduce or eliminate them that are
used for performance tuning and engineering.

• It provides complete, accurate performance data and provides it with an

understandable and usable format so that you can see exactly where your
code is least efficient.

Rational Requisite Pro:

It is used to manage project requirements in most efficient manner. It has

two approaches:

1. Document Centric Approach – Msword.

2. Database Centric Approach - Multiple Databases.

RequisitePRO has different requirement types: Functional requirement

types, Technical requirement type, use case requirement type etc.

We put all our requirements in RequisitePRO and create test cases in test
manager and maintain traceability between them.

Rational Rose:
Rational rose is used to model, generate and reverse engineer code for
applications written in VB, Java etc. We can create Use-Case models, state
transition models etc.

A software designer uses Rational Rose to visually create (model) the

framework for an application by blocking out classes with actors (stick figures), use
case elements (ovals), objects (rectangles) and messages/relationships (arrows) in a
sequence diagram using drag-and-drop symbols. Rational Rose documents the
diagram as it is being constructed and then generates code in the designer's choice
of C++, Visual Basic, Java, Oracle8, CORBA or Data Definition Language.

Rational Soda:
 It automates the creation of software documentation, it extracts information
from software engineering tools such as rational rose and requisite pro using
templates in word, it formats the info and extracts into a report, it preserves the text
and we can use it to create document.
Refer: http://www.seqcm.com.tw/Product/IBM/SoDA.pdf

SQA Basic is the scripting language in Rational Robot:

Refer: http://www.wilsonmar.com/1robosqa.htm

Within Robot, when you pull down menu File > New, you see the different
types of files testers might create:

• SQA Basic Files.

• Project Header Files.

• GUI Shell Scripts.

SQA Basic Files:

• It contains procedural (programming) code to recognize objects and use

variables and constants in if-then-else, do-while, and other logical constructs.

• In larger projects, script code is modularized for reusability.

• Reusable code is organized into functions that are called from a script library
header file. The name of such header files is included in scripts that use those
functions.

Project Header Files:

• It structurally ensures that both function libraries and scripts that use them
declare those functions and global constants the same way.

• Header files declare constants, variables, custom sub procedures, and custom
functions which are common across an organization's scripts.

• This allows for code reuse in many scripts, thereby also standardizing
programming practices.
GUI Shell Scripts:

It calls script procedures (stored using a .rec file extension).Unlike functions,

procedures are executed without parameters.

STEPS IN USING RATIONAL ROBOT:

1. We create a project in administrator and we associate test data store,

RequisitePRO data store, clear quest data store and rose models.

2. We create users and permissions in rational administrator.

3. Then we create a Test Plan in Test Manager (Test Plan Name, Description,
In external Documents Tab attach Test Plan word document).

4. Then we create Test Case folders (like Integration Test Cases, System Test
Cases, and Performance Test Cases).

5. In Test Case folders, we insert test cases (Test Case Name, Test Case
description, Design steps, Pre-Condition, Post-Condition, Acceptance-
Criteria, Attach requirement from RequisitePRO or Rose Model from Rose
as Test Input for traceability).

6. For Manual test scripts, we can import the design and create a Manual test
scripts or we Automate the Robot script from design of test case by inserting
the necessary verification point.
 7. We can also create a Test Suite or Shell script by putting a Call command
and run the all test scripts together.

8. We run or playback the scripts and view the results in Test Log Viewer and
can analyze the results in comparators.

9. Submit any defects found in Clear Quest.

Definitions of some Rational Robot related terms:

Artifacts:

Are either final or intermediate work products produced and used during a project.
Artifacts capture and convey project information, and may take various shapes or
forms

Object-oriented technology:
A general term which describes tools, processes, and programming languages
concerned with the development of systems that consist of chunks of data known as
objects.

Object-oriented programming language:

A programming language that provides facilities for the definition and
manipulation of objects, an object being a collection of data which can receive
messages that change the values of its components.

Data-driven testing:
Is a term used in the testing of computer software for the creation of re-usable test
logic to reduce maintenance and improve test coverage. It is a methodology used in
test automation where test scripts are executed and verified based on the data values
stored in one or more central data sources or databases.

User guide for rational robot:

http://helpnet.vccs.edu/ASC/RationalRobot/UsingRationalRobot.doc

USING RATIONAL ROBOT:

Before you start using Robot, you need to have:

• Rational Robot installed.

• A Rational Project.

To open the Rational Login dialog box.

Click : Start > Programs > Rational Software > Rational Robot

1. Leave User Name and password as

is.
 2. Select a project. To change projects later, exit all Robot components and log
on again. (Projects are created in the Rational Administrator.)

3. Click to log on.

4. The Rational Robot window will open.

RECORDING A GUI SCRIPT:

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.

Guidelines before You Begin Recording:

• Establish predictable start and end states for your scripts.

• Set up your test environment.

• Creating Modular Scripts

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.

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 recording options. During playback, Robot attempts to restore
windows to their recorded states and inserts a warning into the log if it cannot find a
recorded window.
In general, close any unnecessary applications before you start to record.
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 re-recorded if the developers make

intentional changes to the application-under-test.

• They are easier to debug.

STEPS TO RECORD A GUI SCRIPT:

1. Click the Record GUI Script button on the toolbar to open the Record
GUI dialog box.
2. Type a name or select a script from the list.

To change recording options click .

When finished click .

Click to start recording.

The following events occur

• If you selected a script that has already

been recorded, Robot asks if you want to
overwrite it, Click Yes. (If you record over a previously recorded script, you
overwrite the script file; but any existing properties are applied to the new
script.)

• Robot is minimized by default.

• The floating GUI Record toolbar appears. You can use this toolbar to pause
or stop recording, display Robot, and insert features into a script.

3. To start the application-under-test, click the Display GUI Insert Toolbar

button on the GUI Record Toolbar

4. Click the Start Browser button on the GUI Insert toolbar

5. Fill in the dialog box and click .

6. To ensure the same coordinates are used each time the script is played back,
you should maximize the browser window, if necessary. Perform actions as
needed to navigate through the application.
7. Insert features as needed. You can insert features such as verification points,
comments, and timers.

8. When finished click the Stop Recording button on the GUI Record
toolbar.

9. The Robot main window appears.

The script you recorded appears in a Script window within the Robot main
window.

GUI Script Recording Workflow:

• Set up test environment

• Set recording options

• Start recording

• Perform user actions

 • Create verification points

• End recording

TESTING YOUR RECORDED SCRIPT:

After you record a script, you can:

• Play it back using the same version of the application-under-test.

• Edit and compile it.
• Debug it.

Playing Back the Script:

After you record a script, play it back to verify that it works as intended.
Use the same build of the application-under-test that you used to record the script.
After you play back the script, Robot writes the results to a log. Use Rational Test
Manager to view the log. The results should validate the baseline of expected
behavior for the application-under-test.

Editing and Compiling the Script:

After you play back a script, you may decide to edit the script to make it
more usable For example, you may want to insert manual code into the script. You
may also want to print your script or compile changes.

Debugging the Script:

You may need to debug your script to locate errors. Robot includes a
complete, built-in debugging environment to assist you in the development phase of
your GUI script.

The Playback button is used to playback a recorded script. Alternately, File >
Playback… can be used...
Rational robot tutorial link:
http://sqa.fyicenter.com/Rational_Robot_Tutorial/

Use Rational Robot To:

1. Use Robot to develop two kinds of scripts: GUI scripts for functional testing
and
sessions for performance testing.

2. Perform full functional testing. Record and play back scripts that navigate
through your application and test the state of objects through verification
points.

3. Perform full performance testing. Use Robot and TestManager together to

record and play back sessions that help you determine whether a multi-client

system is performing within user-defined standards under varying loads.

4. Create and edit scripts using the SQABasic and VU scripting environments.
The Robot editor provides color-coded commands with keyword Help for
powerful integrated programming during script development. (VU scripting
is
used with sessions in performance testing.)

5. Test applications developed with IDEs such as Java, HTML, Visual Basic,
Oracle Forms, Delphi, and PowerBuilder. You can test objects even if they
are
not visible in the application's interface.

6. Collect diagnostic information about an application during script playback.

You can play back scripts under a diagnostic tool and see the results in the
log. Robot is integrated with Rational Purify, Rational Quantify and
Rational Pure Coverage.
Analyzing Results in the Log and Comparators:

Use TestManager to view the logs that are created when you run scripts and
schedules.

Use the log to:

View the results of running a script, including verification point

failures, procedural failures, aborts, and any additional playback
information. Reviewing the results in the log reveals whether each script and
verification point passed or failed.

Use the Comparators to:

Analyze the results of verification points to determine why a script

may have failed. Robot includes four Comparators:

• Object Properties Comparator

• Text Comparator

• Grid Comparator

• Image Comparator

Script Properties:

1. The script's name, description, owner, purpose, and test environment.

2. Related assets such as test requirements.

3. Notes and specification files.

4. Custom keywords.

Adding Features to GUI Scripts:

The features that you can add to GUI scripts.

• Starting an application
 • Inserting a call to another script

• Inserting verification points

• Inserting timers

• Inserting comments

• Inserting log messages

• Inserting delay values

• Using the Insert menu

• Customizing SQABasic scripts

Uses for Timers:

You can use timers to measure general application performance and specific task
performance.

Measuring General Application Performance:

For general application performance, start a timer, perform a series of

actions and create verification points with the application-under-test, and then stop
the timer. When you play back the script, the timer measures the amount of time it
took for the application to complete all of the actions. The log shows the timing
results.

Measuring Specific Task Performance:

For specific task performance, you often use timers with verification points
that have wait state values. You use the wait state value to detect the completion of a
task before stopping the timer.

The following is an example of using timers for specific task performance testing:

1. During recording, start a timer.

2. Start an application task or transaction (for example, open an application

or start a database query).

3. Insert a verification point with a wait state.

Inserting Timers:

• Robot lets you insert start timer and stop timer commands to record and
write to the log the duration of events in a script. A timer measures the time
it takes to perform an activity.

• For example, you may want to record the time required to perform a
database transaction on a remote server, or how long it takes the same
verification point to execute on client machines with different hardware
configurations.

• You can insert any number of timers with different names into the same
script to measure a variety of separate tasks.

• You can nest timers within other timers (starting and stopping the second
timer before stopping the first timer). You can overlap timers (stopping the
second timer after stopping the first timer). However, you should stop a
timer before starting that same timer over again.

• If you start the same timer twice without stopping it, Robot terminates the
first occurrence when it starts the second. The timer is stopped automatically
at the end of the transaction.

Playing Back a Script that Includes Timers:

Do the following before you play back a script that includes timers:

1. Click Tools > GUI Playback Options.

2. In the Playback tab, clear Acknowledge results. This prevents a pass/fail

result message box from appearing for each verification point. You can still
view the results in the log after playback.

3. In the Playback tab, set the Delay between commands value to 0. This
removes any extra Robot timing delays from the performance measurement.
If you need a delay before a single command, click Insert > Delay and type a
delay value.

4. Click OK.

Before You Create a Verification Point:

 Before you create a verification point, consider the following:

1. What feature in the application do you want to test?

You want to verify that the Cut command places selected data on the
Clipboard.

2. To test the feature, what object or objects should you test?

The objects that you should test are the Cut command on the Edit menu and
the data on the Clipboard.

3. What kind of verification points do you want to create?

You create verification points to test that 1) the Cut command exists on the
Edit menu and is enabled, and 2) the Clipboard contains the information cut
to it.

4. What type of verification points do you create to accomplish the kind of

object testing that you want?

You create a script that contains two verification points -- an Object

Data verification point to test that the Cut command exists on the Edit menu
and that the state of the Cut command is enabled; a Clipboard verification
point to test that the selected information is actually placed on the Clipboard.

Tasks Associated with Creating a Verification Point:

• Start to create a verification point.

• Set a wait state.

• Set the expected result.

• Select and identify the object to test.

• Select a verification method.

• Select an identification method.

• Select the data or properties to test.

• Test column titles or menus (optional).

 • Edit the captured data (optional).

Inserting a Verification Point:

1. Do any of the following:

If recording, click the Display GUI Insert Toolbar button on the GUI Record
toolbar.

If editing, position the pointer in the script and click the Display GUI Insert
Toolbar button on the Standard toolbar.

2. Click a verification point button on the GUI Insert toolbar.

NOTE: To insert a File Comparison, File Existence, or Module Existence

verification point, open the Robot window (click the Open Robot Window
button on the GUI Record toolbar). Click Insert > Verification Point and
the appropriate menu command.

3. In the Verification Point Name dialog box, edit the name of the verification
point as appropriate.

Robot automatically names the verification point with the verification point
type, and adds a number if there is more than one of the same type in the
script.

4. Optionally, set the Wait state options. The wait state specifies how often
Robot should retry the verification point until it passes or times out, and how
long Robot should keep trying the verification point before it times out.

5. Optionally, set the Expected result option. When you create a verification
point, the expected result is usually that the verification point will pass -- for
example that a window does exist during playback. However, you can also
indicate that you expect the verification point to fail -- for example that a
window does not exist during playback.

6. Click OK.

Setting a Wait State for a Verification Point:

Using a wait value keeps the verification point from failing if the task is not
completed immediately or if the data is not accessible right away.

For example, suppose you create an alphanumeric verification point that tests for a
specific string in a text box. When you play back the script, Robot first looks for the
text box. The verification point fails immediately if the box does not exist. If Robot
finds the box, it checks for the string in the box. However, the string might not be
in the box yet (your application might be running slowly and the box might not be
updated yet). To solve this, include wait values so that Robot retries the test (checks
for the string) every two seconds. If the content of the box does not match the string
within 30 seconds, the verification point returns a failure indication to the script.

For verification points that verify the properties or data of an object, Robot must
first find the specified object before it can perform the verification point. After it
finds the object, the following happens:

• If no wait state is specified, the verification point passes or fails immediately.

• If a wait state is specified, then Robot does the following, as shown in this
pseudo-code example:

Loop until timeout period expires (as specified by Timeout After)

Wait for retry period (as specified by Retry every)
perform VP
If it passes, exit loop, else loop back
End loop

To add a wait state when creating a verification point:

1. Start to create the verification point.

2. In the Verification Point Name dialog box, select Apply wait state to
verification point.

3. Type values for the following options:

Retry every How often Robot retries the verification point during playback.
Robot retries until the verification point passes or until the timeout limit is
reached.

Timeout after the maximum amount of time that Robot waits for the
verification point to pass before it times out. If the timeout limit is reached
and the verification point has not passed, Robot enters a failure in the log.
The script playback either continues or stops based on the setting in the
Error Recovery tab of the GUI Playback Options dialog box.
Selecting and Identifying the Object to Test:

When you create certain verification points, you need to select the object to
test. You do this by pointing to the object with the Object Finder tool, or by
selecting the object from a list of all objects on the Windows desktop. When
you point to an object, you can use one of several methods to visually identify
the object before you actually select it.

There are two ways to select the object to test:

• Point to it in the application. This is useful for selecting visible objects.

• Select it from a list of all objects on the desktop. This is useful for selecting
hidden objects.

RATIONAL PROJECT AND RATIONAL

ADMINISTRATOR

A Rational project stores software testing and development information. All

Rational components on your computer update and retrieve data from the same
project.

A Rational project can consist of the following projects or associated projects

Functional Test project

Stores test assets such as scripts, Functional Test logs, object maps,
verification point baseline files, and script templates.

Rational Test project

Stores test assets such as test plans, test cases, test logs, reports, and builds.

Rational RequisitePRO project

Stores product or system requirements, software and hardware

requirements, and user requirements. When you associate a RequisitePRO project
with a project in the Rational Administrator, TestManager automatically uses the
requirements in the project as test inputs.

Rational Rose models

Stores visual models for business processes, software components, classes and
objects, and distribution and deployment processes.

Rational Clear Quest database

Stores change-request information for software development, including

enhancement requests, defect reports, and documentation modifications. When you
associate a Rational Clear Quest database with a project in the Rational
Administrator, you can submit defects directly from a log in TestManager into
Clear Quest. TestManager automatically fills in some of the fields in the Clear Quest
defect form with information from the log and automatically records the defect ID
from Clear Quest in the log.

How to Create a Project:

1. Open Rational Administrator.

2. Right click on “PROJECT” and choose the option “NEW PROJECT” from
the pop up menu.

3. A new project wizard dialog box appears.

 4. Enter the “PROJECT NAME” and browse a location to put the project.

5. Click on “NEXT”

6. If you want a password for your project, you can have a project. This
prevents others from deleting or editing your project.

7. Click on “NEXT”

8. Click on “FINISH”

How to Configure a Project:

• Create an associate RequisitePRO Project.

• Create an associate Test Data Store.

 To configure the test data store that will be part of your project, click Create in
the Test Assets group.

For projects involving more than one person, Rational recommends using
Sybase SQL Anywhere.

Accept the default and close Rational Administrator.

How to Use Ration Robot:

 1. Start Rational Robot

2. Click on File  New Script, type a name and description for the new script.

3. To start recording, click on File  Record GUI or Record  Insert at

Cursor.

4. A toolbar with title of GUI Record appears.

5. In the GUI Record toolbar click on the option display GUI Insert toolbar.

6. GUI Insert toolbar appears.

7. Choose start application or start java application or start browser for to start
the program to be recorded for testing.

8. After recording in the GUI Record toolbar, click on the Stop Recording icon.

9. View the Recoded Script Contents in the Rational Robot Window.

10. Save the script to a specific path.

11. To play the scripts again click on Playback Script Button or File  Playback.
Creating The Test Plan - Specifying Inputs to Test Inputs:

• Rational TestManager can retrieve Requirements from both Microsoft Excel

as well as Rational RequisitePRO. E.g. Excel.

• Open up Microsoft Excel and create 4 columns called Requirement Name,

Description, Status and Last Modified and set the formatting on the last

column to a format supporting Data and Time. Fill up the table as shown in

the screenshot below.

•

• Save this Excel document as TestManagerTutorial_Requirement in the same

location as the project (C:\TestManagerTutorial)

Starting Rational TestManager:

• Start Rational TestManager by clicking Start > Programs > Rational

Software > Rational TestManager.

• You must log into a Rational Administrator Project to continue. Select the

TestManagerTutorial Project we created earlier. Projects are created with

Admin user with a blank password. For this tutorial this will suffice,

however on actual projects you will want to create a username and password

for each member of the team. Just click OK to use the Admin username.

Creating the Test Plan Structure:

• When TestManager opens, click Plans on the bottom of left pane.

• Expand the Test Plans folder and right click Test Plan 1 and rename it to

Classics Online
 • Double click on the Test Plan to open

• Right click on the default folder to delete it

Creating the Test Plan Structure:

• Right click on the Test Plan name and click Insert Test Case folder

• Name the folder Verify Customer Name, enter a description and click okay
Repeat the previous steps to create the following Test Plan Structure
Connecting to the Excel Spreadsheet:

• If Excel is used to document our requirements, we need to establish the test

inputs from TestManager.

• Click Tools > Manage > Test Input Types

• Select Microsoft Excel and click Edit

Click the Sources Tab and Click Insert

Connecting to the Excel Spreadsheet:

• In the New Input Source window, type the name Application Requirements

• Click the Connection Data tab and in the Data Path field, click browse, and

browse to the Excel Spreadsheet we created earlier.

• Click the Set Configuration button and click yes on the Save dialog box that

pops up

• Fill the dialog window with the values shown below and press okay
Viewing the Test Inputs

• To view the test inputs, Click View > Test Inputs.

• Click the + next to the Application Requirements to view the requirements.

You can right click on a requirement and click properties to view its details