Mercury QuickTest Professional Scripting Guide

Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 1
QUICKTEST PROFESSIONAL SCRIPTING GUIDE
AUTHORISATION
Prepared By
Reviewed By Authorised By
Jose Barranco Mark Haley Barry Baker
Prabhakar Rao
Selvan Nithiy
VERSION HISTORY
Version
Date Prepared By
Reason for Change
V 1.0 04/08/2006 Jose Barranco Initial Draft
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 2
Content
Abstract ……………………………………………………. 3
1. Test Script Modularity ……………………………………. 4
1.1. Introduction ……………………………………………………. 4
1.2. Identifying Reusable Actions (Planning) ……………………. 4
1.3. Factors to consider when using Multiple Reusable Actions ……. 5
1.4. Reusable Actions organization ……………………………. 5
1.5. Working with functions ……………………………………. 5
1.6. VBS file organization ……………………………………………. 6
2. Data Driving Scripts ……………………………………………. 7
3. Script Presentation ……………………………………………. 10
3.1. Scripting Sections ……………………………………………. 10
3.1.1 Initialisation Section ……………………………………………. 10
3.1.2 Verification Section ……………………………………………. 10
3.1.3 Auxiliary Section ……………………………………………. 11
3.1.4 Cleanup Section ……………………………………………. 11
3.1.5 Return code ……………………………………………………. 11
3.1.6 Grouping Blocks ……………………………………………. 12
3.2. Code Layout ……………………………………………………. 12
3.2.1 Indentation ……………………………………………………. 12
3.2.2 Header ……………………………………………………………. 12
3.2.3 Comments ……………………………………………………. 13
3.3. Naming Conventions ……………………………………………. 13
4. Making Tests Robust ……………………………………………. 15
4.1. Synchronisation ……………………………………………. 15
4.1.1 Synchronisation Point ……………………………………………. 15
4.1.2 Exit and Wait Statements ……………………………………. 16
4.1.3 Global Timeout ……………………………………………. 16
4.2. Errors and Exception Handling for Test Scripts ……………. 17
4.2.1 Handling Errors ……………………………………………. 17
4.2.2 Handling Exceptions ……………………………………………. 18
5. Results Logging ……………………………………………. 20
6. Version Control ……………………………………………. 22
Appendix A: Error Codes ……………………………………. 23
Appendix B: Template for Test Script Header ……………. 27
Appendix C: VBScript Useful Objects ……………………. 28
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 3
Abstract
The process of building automated test scripts is similar to the process of software
development. Thus, Software Engineering best practices should be implemented to
ensure that the code is: readable and comprehendible, maintainable and reusable
where possible. Development of automated scripts should follow phases of Software
Development Life Cycle – Plan, Analysis and Design, Coding and Testing,
Deployment and Support. Appropriate review process should be organized to assure
quality of the deliverables for each of the phases. Well-designed re-usable test cases
should be considered as a Configuration Item, and it should be controlled by a
Configuration Management system, when it makes sense from the business
perspective.
This document provides an overview of Test Scripting Best Practices based on the
experience of implementing Test Automation tools by Mercury Interactive
Professional Services Organization as well as internal use of these tools by Mercury
Interactive QA Department, and the objective is to provide scripting guidelines and
techniques to be followed for effective test automation using Mercury’s QuickTest
Professional.
The following sections are covered in this document:
Test Script Modularity and Data Driving
Scripting presentation
Synchronisation
Error and Exception Handling
Result Logging
VBScript Useful Objects
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 4
1. Test Script Modularity
1.1 Introduction
When you plan a suite of tests you may realize that each test requires one or more
identical activities, such as a Logging Business Process that can be repeated a number
of times in different tests and different Business Processes.
Rather than recording the business process a number of times in a number of tests,
and enhancing this part of the script (e.g. with Ckeckpoints and Parameterisation)
separately for each test, you can create an action that performs the operation in the
application in one test.
Once you are satisfied with the action you recorded and enhanced, you can make the
action reusable and insert it into other tests. These external/reusable actions can then
be used and reused in every test case that requires similar functionality, enabling
testers to use a single action in hundreds of different test cases with little or not extra
effort. This eliminates many lines of redundant script code that used to be created,
stored and maintained for each business process.
Identifying Reusable Actions (Planning)
1.2 Identifying Reusable Actions (Planning)
The Business Analyst or SME (Subject Matter Expert) should identify possible
reusable activities (number of steps comprising a Business Process or Sub-Business
Processes) that can be implemented in a Reusable Action during the planning stage or
during the implementation of the Test Requirements
SMEs should plan for cases where discrete business processes can be built once and
used many times, and when it is possible SMEs will determine how tests (called
actions) should be placed in main calling tests and whether nesting tests are required
for the Business Process.
Figure 1. Reusable Actions in QuickTest Professional
Reusable
Action
LOGGING IN ACTION
Test 1
Test 2 Test 3
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 5
Once a number of reusable activities have been identified the team might also create
an action library as part of organising the Testing Project, so other testers can start
calling (using) the Reusable Actions.
In the real world, due to various constraints and limitations (e.g. company resources,
manpower, etc…) the reusable activities are identified during the recording process,
as the QTP Expert or Tester becomes familiar with the steps to follow in the AUT
(Application Under Test) in order to carry out a test.
1.3 Factors to consider when using Multiple Reusable Actions
When using multiple, reusable actions, keep the following in mind:
· Actions can be called or copied from another test
· Run settings have to be set per-action
· Parameters and data from the called test are reflected in the calling test
· An action can be deleted or an action call can be deleted
· You can position your action calls separately or nest them with other actions
· A test has a limitation of 255 actions (The reason is that each Action has a data
table sheet. The Formula 1 control has a limitation of 255 sheets so the
limitation is 255 Actions per test. You may be able to add additional Actions
after reaching the 255 "limit", however those Actions will not be able to access
a local data sheet.)
· A Reusable Action cannot received or return an array as a parameter, however
you can workaround it by passing a string with tokens (delimiter) specifying the
different elements.
1.4 Reusable Actions organization
Reusable actions should be grouped into libraries in the way that library includes no
more than 20 scripts. There is no technical limitation for the number of reusable
actions per library (QTP test), but rather convenience of library’s maintenance. Each
action should have detailed documentation – this should be done via QTP UI and thus
the information is available for the users while browsing the actions. The
documentation should include the action’s objective, parameters and return code. The
author’s name is stored automatically.
1.5 Working with functions
In addition to the test objects, methods, and built-in functions supported by the
QuickTest Test Object Model, you can define your own function libraries
containing VBScript functions, subroutines, modules, and so forth, and then
call their functions from your test.
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 6
1.6 VBS file organization
VB Script development standards should be applied for the organization of the VBS
library. The library should be loaded into as following:
1. Select Test->Settings menu in QTP - see Test Settings dialog
2. Select Resources tab in the Test Settings dialog
3. Click on the + button and click on the file button
4. Select All files option for the File Types in the File Open dialog
5. Navigate to the required VBS file
6. Click on Set as Default button in Test Settings dialog
Then, the functions can be used in QTP “as is” – no additional declaration is required.
The diagram below illustrates reusable actions in conjunction with reusable function
libraries.
VBScript
Function Library
Controller Script
Local Action External Action1 Local Action External Action4
External Action2 External Action3
External Action4
External Action1
External Action2
External Action3
External Action4
QTP Test
Library
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 7
2. Data Driving Scripts
Data driving testing puts a layer of abstraction between the data and the test
script, eliminating literal (hard-coded) values in the Quicktest test script.
Because data is separated from test script, you can:
· Modify test data without affecting the test script
· Add new test cases by modifyng test data, not the test script
· Share the same test data with many other scripts
The data your test uses is stored in the design-time Data Table, which is
displayed in the Data Table pane at the bottom of the screen while you insert
and edit steps.
The Data Table has the characteristics of a Microsoft Excel spreadsheet,
meaning that you can store and use data in its cells and you can also execute
mathematical formulas within the cells. You can use the DataTable, DTSheet
and DTParameter utility objects to manipulate the data in any cell in the Data
Table.
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 8
Methods available for Datatable, DTSheet and DTParameter
Datatable DTSheet DTParameter
AddSheet AddParameter Name
DeleteSheet DeleteParameter RowValue
Export GetCurrentRow Value
ExportSheet GetParameter ValueByRow
GetCurrentRow GetParameterCount
GetRowCount GetRowCount
GetSheet SetCurrentRow
GetSheetCount SetNextRow
Import SetPrevRow
ImportSheet
SetCurrentRow
SetNextRow
SetPrevRow
When you data drive a script, the script uses an object reference instead of the initial
hard-coded value. The object in the script will be a reference to the data table sheet
and column made through the data table object.
For further information regarding an object or an object method, users can left click
on the object or method and press F1.
Dialog(“Login”).WinEdit(“AgentName”).Set “1234” ‘hard-coded
Dialog(“Login”).WinEdit(“AgentName”).Set Datatable(“Agent”, dtLocalSheet)
‘data driven
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 9
When working with Quality Center and Data Tables, you must save the Data
Table file as an attachment in your Quality Center project before you specify
the Data Table file in the Resources tab of the Test Settings dialog box.
You can add a new or existing Data Table file to your Quality Center project.
Note that if you add an existing Data Table from the file system to a Quality
Center project, it will be a copy of the one used by tests not in the Quality
Center project, and thus once you save the file to the project, changes made to
the Quality Center Data Table file will not affect the Data Table file in the file
system and vice versa.
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 10
3. Script Presentation
When you write a script, you should always consider how the script might be used in
the future, as these scripts might be run repeatedly or be copied and used by other
testers. These testers might need to modify the scripts to fit their own needs.
At the very least, they will probably want to view the script code so they can better
understand what the script actually does, and how. In these situations, it is a good idea
if your scripts follow accepted organizational standards for such things as
commenting, formatting, and naming; following these standards makes it easier for
others to read, modify, and maintain the scripts.
3.1 Scripting Sections
There exist different stages (blocks or sections of code) during the implementation of
a script, and each of these sections will carry one specific function.
· Initialisation Section
· Verification Section
· Auxiliary Section
· Cleanup Section
· Return Code
3.1.1 Initialisation Section
Used for declaring variables and defining constants, the initialisation section should
always come first in a script. All dynamic test resources should be loaded in this
block. If a test needs a configuration other than the current one, the old configuration
should be saved in temporary variables, so that it is available for restoring in a
cleanup block. Depending on the objectives of the test, it should be able either to use
an application that is already running, an application that is brought to a required
initial state, or an application that is started from scratch by the test.
Shouldn’t dynamic test resources be read from a property file? This way you could
change the property file without having to change your code, recompile and re-link?
If a test needs a configuration other than the current one, the old configuration should
be saved and system variables should be changed to the required values. For example:
Extern.Declare micInteger,"WritePrivateProfileStringA",
"kernel32.dll","WritePrivateProfileStringA", micString, micString,
micString, micString
CurrValue = Environment.Value(“APPURL”)
Environment.LoadFromFile “c:\temp\myconfigdata.ini”
3.1.2 Verification Section
Each check block should consist of a set of actions followed by a verification point.
The verification points may be of two kinds – standard checkpoints available in the
test automation product, or programmed algorithmic checks; this is a custom or userdefined
checkpoint. Verification points should affect the status of the block and,
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 11
through it, the status of the test. Note that the status definition is automatically set for
standard checkpoints.
Example of a standard checkpoint:
Browser(“Browser”).Page(“Page”).WebList(“L1”).Check Checkpoint(“Arrivals
List”)
Example of a programmed algorithmic check:
ItemsCount1 = WebList(“List1”).QueryValue(“count”)
ItemsCount2 = WebList(“List2”).QueryValue(“count”)
if ItemsCount1 <> ItemsCount2 – 1 then
...
End If
3.1.3 Auxiliary Section
The auxiliary section creates some initial conditions for the execution of check
section. The blocks may contain checks relating to correct execution. In such cases,
failures should be reported according to the reporting standard for the check blocks.
The step name of an auxiliary block should be the same as that of the check block
using the execution results of this auxiliary block.
3.1.4 Cleanup Section
The last block of the implementation section should be a cleanup block. This block
should close all open files, unload libraries, remove temporary files, and restore
system configuration to its old values stored in the initialisation block. Typically, if a
test fails, the application should be closed as well. The correct technique is to combine
all these actions in a function that is called at any exit point. This section is al used to
clear variables and objects from memory; we can use it to inform the VBScript
garbage collector that we do not need those objects any longer.
fname.Close
Environment.Value(“APPURL”) = CurrValue
Set dbConnection = nothing
3.1.5 Return Code
Each main test should return its completion status. It should be 0 if the test passed and
another value if the test failed. The statement ExtRun should be at the end of the main
action if the test is implemented as a set of nested actions, or at the end of the last
action if the test is implemented as a sequence of actions.
ExitRun (0)
In addition to ExitRun, the following statements can be used to control the return
value of an action, iteration or component:
· ExitAction
· ExitActionIteration
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 12
· ExitglobalIteration
· ExitTest
· ExitTestIteration
· ExitComponent (when implementing BPT)
· ExitComponentIteration (when implementing BPT)
3.1.6 Grouping the blocks
To make test scripts more readable, auxiliary and check blocks, which create a
logically independent unit in a test, would be extracted in a function. If such function
is specific to a particular test, it should be stored in the functions section of the test
3.2 Code Layout
Follow these guidelines for the correct layout of your code:
3.2.1 Indentation
Screen space should be conserved as much as possible, while still allowing code
formatting to reflect logic structure and nesting. Every function, sub routine, loop and
logical condition should be aligned. Here are a few suggestions:
· Indent standard nested blocks four spaces.
· Indent the overview comments of a procedure one space.
· Indent the highest level statements that follow the overview comments four
spaces, with each nested block indented an additional four spaces.
3.2.2 Header
All scripts should begin with a brief comment describing what they do; this is called
the header. This description should not describe the implementation details (how it
does it) because these often change over time, resulting in unnecessary comment
maintenance work, or worse, erroneous comments. The code itself and any necessary
inline comments describe the implementation.
More details will be presented later on for scripting code, giving a description of
specific blocks of data or statements.
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 13
‘’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’
‘ SUMMARY: The test checks login procedure
‘
‘ DESCRIPTION: The test checks that login is performed
‘ when correct parameters are used
‘
‘ RETURN CODE: standard
‘
‘ APPLICATION: Flight
‘
‘ NOTES: The script requires DSN”app” to be set on the
‘ machines
‘
‘ AUTHOR: Brain Tester. 29/02/02
‘ UPDATED: Black Jack. 01/01/04
‘
‘’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’
3.2.3 Comments
Every important variable declaration should include an inline comment describing the
use of the variable being declared.
Variables, objects, classes sub routines and functions should be named clearly to
ensure that inline comments are only needed for complex implementation details.
At the beginning of your script, you should include an overview that describes the
script, enumerating objects, procedures, algorithms, custom checkpoints, and other
system dependencies. Sometimes a piece of pseudo-code describing the algorithm can
be helpful.
You can add comments to your statements using an apostrophe ('), either at the
beginning of a separate line, or at the end of a statement. It is recommended that you
add comments wherever possible, to make your scripts easier to understand and
maintain.
3.3 Naming Conventions
The main reason for using a consistent set of coding naming conventions is to
standardize the structure and coding style of a script or set of scripts so that you and
others can easily read and understand the code. Using good coding naming
conventions results in clear, precise, and readable source code that is consistent with
other language conventions and is intuitive.
The names of functions and variables should in lower case, beginning with upper case
for each segment of the name. The names of the constants should be in upper case.
For example:
MAXCHARNUMBER – constant for maximum of characters available for selection
GetFileSize – function to determine size of the file
Public functions names from the same module should start with a common prefix. For
example, names of functions from the module supporting operations on the financial
application should start with “Fin”, as in: FinCalculateTotals.
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 14
The names should be meaningful.
Use:
ItemsCount = WebList(“List”).QueryValue(“count”)
Instead of:
i = WebList(“List”).QueryValue(“count”)
Declarations for constants should be as follow:
const LIBPATHNAME = “X:\TESTS\LIB\”
All variables in Quick Test Professional are local (private) to the specific action.
The declaration syntax is as follows:
Dim MainItemsCount
Initialisation of variables
Dim MainItemsCount
MainItemsCount = 1
To enhance readability and consistency, use the following prefixes with descriptive
names for variables in your VBScript code.
Subtype Prefix Example
Boolean bln blnFound
Byte byt bytRasterData
Date (Time) dtm dtmStart
Double dbl dblTolerance
Error err errOrderNum
Integer int intQuantity
Long lng lngDistance
Object obj objCurrent
Single sng sngAverage
String str strFirstName
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 15
4. Making Tests Robust
There is no a set list of problems that might occur during the execution of a test, these
problems can vary and depend on the application you are building, technologies used,
settings and environment, user software configuration and so forth.
A tester will often find that with every new project comes a new set of problems.
Only experience can better one at trying to predict the problems before they arise.
Choosing the right test strategy is an important step to achieve efficient and robust test
automation. The following section describes some of the important methods that
teams should consider.
4.1 Synchronisation
When you run a test, your application may not always respond with the same speed.
For example, it might take a few seconds:
· for a progress bar to reach 100%
· for a status message to appear
· for a button to become enabled
· for a window or pop-up message to open
You can handle these anticipated timing problems by synchronizing your test to
ensure that QuickTest waits until your application is ready before performing a certain
step.
There are several options that you can use to synchronize your test:
4.1.1 Synchronisation Point
If you do not want QuickTest to perform a step or checkpoint until an object in your
application achieves a certain status, you should insert a synchronization point to
instruct QuickTest to pause the test until the object property achieves the value you
specify (or until a specified timeout is exceeded).
To insert a synchronization point:
1. Begin recording your test.
2. Display the screen or page in your application that contains the object for
which you want to insert a synchronization point.
3. In QuickTest, choose Insert > Synchronization Point. The mouse pointer turns
into a pointing hand.
4. Click the object in your application for which you want to insert a
synchronization point.
5. Enter the property name
6. Enter the property value
7. Specify the timeout
8. Click on “OK”
You can alternatively place a synchronisation point directly the Expert View, using
VBScript
Dialog(“Login”).WaitProperty “visible”, true, 10000
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 16
4.1.2 Exist and Wait Statements
You can enter Exist and/or Wait statements to instruct QuickTest to wait for a window
to open or an object to appear. Exist statements return a boolean value indicating
whether or not an object currently exists. Wait statements instruct QuickTest to wait a
specified amount of time before proceeding to the next step. You can combine these
statements within a loop to instruct QuickTest to wait until the object exists before
continuing with the test.
For example, the following statements instruct QuickTest to wait up to 20 seconds for
the Flights Table dialog box to open.
blnDone=Window("Flight Reservation").Dialog("Flights Table").Exist
counter=1
While Not blnDone
Wait (2)
blnDone=Window("Flight Reservation").Dialog("Flights Table").Exist
counter=counter+1
If counter=10 then
blnDone=True
End if
Wend
4.1.3 Global Timeout
If you find that, in general, the amount of time QuickTest waits for objects to appear
or for a browser to navigate to a specified page is insufficient, you can increase the
default object synchronization timeout values for your test and the browser navigation
timeout values for your test.
File > Settings > Run
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 17
4.2 Errors and Exception Handling for Test Scripts
4.2.1 Handling Errors
By default, if an error occurs during the run session, QuickTest displays a popup
message box describing the error. You must click a button on this message box to
continue or end the run session.
You can accept the popup message box option or you can specify a different response
by choosing one of the alternative options in the list in the “When error occurs during
run session” list in File -> Settings -> Run
· Pop up message box
· Proceed to next action iteration
· Stop Run
· Proceed to Next Step
When an error occurs, the information is sent to the Test Results, therefore
automatically logged for you.
Error codes can be also be trapped in your script, allowing branch testing, conditional
modularity or merely determining whether a specific block passes or fails.
Error codes will help you find solutions to problems you may encounter while
creating or running components. Quicktest Professional uses VBScript as scripting
language, therefore the errors that can be triggered are VBScript Error codes.
If a QuickTest operation fails the user can retrieve the error code at run time using the
GetLastError built-in function.
Dialog(“Login”).WinEdit(“AgentName”).Set “1234”
LastErr = GetLastError()
Msgbox “Error number: ” & LastErr & “ – Description: “ &
DescribeResult(LastErr)
The users can also trapped VBScript errors or raise their own errors in the script,
making the script more robust thus. Once an error is trapped, the user will take a
logical decision and if necessary exit the iteration or test gracefully, making sure a
message is sent to the Test Results providing enough information for the error, state
and end condition of the application under test.
This is done through the Err object, which is an intrinsic object with global scope;
therefore there is no need to create an instance of it in your code. The generator of an
error sets the properties of the Err object.
When a run-time error occurs, the properties of the Err object are filled with
information that uniquely identifies the error and information that can be used to
handle it. To generate a run-time error in your code, use the Raise method.
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 18
The Err object contains information about run-time errors, through the following:
Properties
· Description
· HelpContext
· HelpFile
· Number
· Source
Methods
· Clear
· Raise
The user can also enable or disable error handling; this is done through the On Error
Resume Next statement.
On Error Resume Next causes execution to continue with the statement immediately
following the statement that caused the run-time error, or with the statement
immediately following the most recent call out of the procedure containing the On
Error Resume Next statement. This allows execution to continue despite a run-time
error. You can then build the error-handling routine inline within the procedure. Note
that the error is not corrected, just ignored, and an error message is not displayed.
Use On Error GoTo 0 to disable error handling if you have previously enabled it
using On Error Resume Next.
Be aware that if you place the statements in a function, it will only apply to the
function and not the entire action or test.
Dim objFoo
' Enable error handling
On Error Resume Next
Set objFoo = Script.CreateObject("Foo")
If Err.number <> 0 Then
' Object couldn't be created
' Log error
Reporter.ReportEvent micFail, “Error in Foo”, Err.Description & “ – “ &
apgSeverityError & “ – “ & Err.Number
Else
' Use objFoo somehow
...
End If
' Reset error handling
On Error Goto 0
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 19
4.2.2 Handling Exceptions
Sometimes, you may not be able to predict where in the script an error or application
exception might occur. Therefore adding error-handling statements into the script is
not useful.
For these cases, you might choose to use recovery scenarios to catch and handle the
unpredictable/unexpected run exception.
You have to make you can understand the difference between a run time error and an
exception; while a run time error can be predicted e.g. an expected error message
dialog when a bad password is entered, an exception cannot be predicted and could
come from the application under test or from external sources e.g. “You have mail”
message or “Printer out of paper” message.
The recovery Scenario Manager allows the tester to create and manage recovery
scenarios to identify and take appropriate action when an exception occurs. You
ONLY use a recovery scenario for exceptional or unpredictable events, you should
handle expected errors (for example during a negative testing execution) and
predictable events directly in the test.
The Recovery Scenario Wizard leads you, step-by-step, through the process of
creating a recovery scenario. The Recovery Scenario Wizard contains five main steps:
1. defining the trigger event that interrupts the run session
2. specifying the recovery operation(s) required to continue
3. choosing a post-recovery test run operation
4. specifying a name and description for the recovery scenario
5. (for tests) specifying whether to associate the recovery scenario to the current
test and/or to all new tests
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 20
5. Result Logging
When a run session ends, you can view the run session results in the Test Results
window. By default, the Test Results window opens automatically at the end of a run.
If you want to change this behavior, clear the View results when run session ends
check box in the Run tab of the Options dialog box.
The Test Results window contains a description of the steps performed during the run
session. For a test that does not contain Data Table parameters, the Test Results
window shows a single test iteration.
If the test contains Data Table parameters, and the test settings are configured to run
multiple iterations, the Test Results window displays details for each iteration of the
test run. The results are grouped by the actions in the test.
You can define a message that QuickTest sends to your test results. For example,
suppose you want to check that a user name edit box exists in the application under
test. If the edit box exists, then a username is entered. Otherwise, QuickTest sends a
message to the test results indicating that the object is absent.
You can use the Reporter Utility object in your script to send a message to the Test
Results:
Associated Methods
· ReportEvent Method
Associated Properties
· Filter Property
· ReportPath Property
· RunStatus Property
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 21
The ReportEvent method reports an event to the Test Results, making sure that the
result is logged with the internal logging of the automation tool instead of sending it
to an external file.
The first argument of the method will determine the status of the report message (be
aware that this can either pass or fail the entire action and therefore the entire test, so
if a single step in your script fails, the entire test will fail impacting on the
requirement that has been linked to the test in the requirement coverage) , and this can
be one of the following:
· 0 or micPass: Causes the status of this step to be passed and sends the
specified message to the report.
· 1 or micFail: Causes the status of this step to be failed and sends the specified
message to the report. When this step runs, the test fails.
· 2 or micDone: Sends a message to the report without affecting the pass/fail
status of the test.
· 3 or micWarning: Sends a warning message to the report, but does not cause
the test to stop running, and does not affect the pass/fail status of the test.
The following examples use the ReportEvent method to report a failed step.
Reporter.ReportEvent 1, "Custom Step", "The user-defined step failed."
or
Reporter.ReportEvent micFail, "Custom Step", "The user-defined step failed."
You can use this property to completely disable or enable reporting of steps following
the statement, or you can indicate that you only want subsequent failed or failed and
warning steps to be included in the report.
The options are:
· RfEnableAll
· RfEnableErrorsAndWarnings
· RfEnableErrorsOnly
· rfDisableAll
Reporter.ReportEvent micGeneral, "1", ""
Reporter.ReportEvent micGeneral, "2", ""
Reporter.Filter = rfDisableAll
Reporter.ReportEvent micGeneral, "3", ""
Reporter.ReportEvent micGeneral, "4", ""
Reporter.Filter = rfEnableAll
Reporter.ReportEvent micGeneral, "5", ""
Reporter.ReportEvent micGeneral, "6", ""
You can also use the RunStatus property to retrieve the run status at the current point
of the run session:
If Reporter.RunStatus = micFail Then ExitAction
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 22
6. Version Control
Version Control of the QuickTest Professional scripts should be established using ClearCase
tool, and the integration between ClearCase and TestDirector, which is a separate add-in.
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 23
Appendix A: Error Codes
When an error occurs, it can be a QuickTest operation error or a VBScript error
QuickTest Run Operation Errors
The Run Error message box displayed during a run session offers a number of buttons
for dealing with errors encountered:
The message provides all the necessary information about the error, and the
information is also sent to the Test Resuls.
If an operation fail the user can retrieve the error code at run time using the
GetLastError built-in function.
Dialog(“Login”).WinEdit(“AgentName”).Set “1234”
LastErr = GetLastError()
Msgbox “Error number: ” & LastErr & “ – Description: “ & DescribeResult(LastErr)
VBScript Errors
Error codes will help you find solutions to problems you may encounter while
creating or running components. Quicktest Professional uses VBScript as scripting
language, therefore the errors that can be triggered are VBScript Error codes.
Run Time Errors:
Error Number Description
429 ActiveX component can't create object
507 An exception occurred
449 Argument not optional
17 Can't perform requested operation
430 Class doesn't support Automation
506 Class not defined
11 Division by zero
48 Error in loading DLL
5020 Expected ')' in regular expression
5019 Expected ']' in regular expression
432 File name or class name not found during Automation operation
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 24
92 For loop not initialized
5008 Illegal assignment
51 Internal error
505 Invalid or unqualified reference
481 Invalid picture
5 Invalid procedure call or argument
5021 Invalid range in character set
94 Invalid use of Null
448 Named argument not found
447 Object doesn't support current locale setting
445 Object doesn't support this action
438 Object doesn't support this property or method
451 Object not a collection
504 Object not safe for creating
503 Object not safe for initializing
502 Object not safe for scripting
424 Object required
91 Object variable not set
7 Out of Memory
28 Out of stack space
14 Out of string space
6 Overflow
35 Sub or function not defined
9 Subscript out of range
5017 Syntax error in regular expression
462 The remote server machine does not exist or is unavailable
10 This array is fixed or temporarily locked
13 Type mismatch
5018 Unexpected quantifier
500 Variable is undefined
458 Variable uses an Automation type not supported in VBScript
450 Wrong number of arguments or invalid property assignment
Syntax Errors:
Error Number Description
1052 Cannot have multiple default property/method in a Class
1044 Cannot use parentheses when calling a Sub
1053 Class initialize or terminate do not have arguments
1058 'Default' specification can only be on Property Get
1057 'Default' specification must also specify 'Public'
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 25
1005 Expected '('
1006 Expected ')'
1011 Expected '='
1021 Expected 'Case'
1047 Expected 'Class'
1025 Expected end of statement
1014 Expected 'End'
1023 Expected expression
1015 Expected 'Function'
1010 Expected identifier
1012 Expected 'If'
1046 Expected 'In'
1026 Expected integer constant
1049 Expected Let or Set or Get in property declaration
1045 Expected literal constant
1019 Expected 'Loop'
1020 Expected 'Next'
1050 Expected 'Property'
1022 Expected 'Select'
1024 Expected statement
1016 Expected 'Sub'
1017 Expected 'Then'
1013 Expected 'To'
1018 Expected 'Wend'
1027 Expected 'While' or 'Until'
1028 Expected 'While,' 'Until,' or end of statement
1029 Expected 'With'
1030 Identifier too long
1014 Invalid character
1039 Invalid 'exit' statement
1040 Invalid 'for' loop control variable
1013 Invalid number
1037 Invalid use of 'Me' keyword
1038 'loop' without 'do'
1048 Must be defined inside a Class
1042 Must be first statement on the line
1041 Name redefined
1051 Number of arguments must be consistent across properties
specification
1001 Out of Memory
1054 Property Set or Let must have at least one argument
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 26
1002 Syntax error
1055 Unexpected 'Next'
1015 Unterminated string constant
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 27
Appendix B: Tesmplate for test script header
An example of the comment block is as follows:
‘’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’
’
‘ SUMMARY: The test checks login procedure
‘
‘ DESCRIPTION: The test checks that login is performed
‘ when correct parameters are used
‘
‘
‘ RETURN CODE: standard
‘
‘ APPLICATION: Flight
‘
‘ NOTES: The script requires DSN”app” to be set on the
‘ machines
‘
‘ AUTHOR: Brain Tester. 29/02/02
‘ UPDATED: Black Jack. 01/01/04
‘
‘’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 28
Appendix C: VBScript Useful Objects
WScript.Shell
This object can be used to replay key sequences when the QuickTest standard
functions do not work. Many other things can be done with this object.
Set WshShell = CreateObject("WScript.Shell")
Dim path, lang
path = "HKLM\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\WOW\boot.description\language.dll"
lang = WshShell.RegRead(path)
msgbox lang
ADODB.Connection
This object can be used to connect to a database and query it.
Dim flightnumber
Dim dbexample
' Create the connection object.
Set dbexample = CreateObject("ADODB.Connection")
' Set the connection string and open the connection
dbexample.ConnectionString =
"DBQ=D:\app\flight32.mdb;DefaultDir=D:\app;Driver={Microsoft Access Driver
(*.mdb)};DriverId=281;FIL=MS
Access;MaxBufferSize=2048;MaxScanRows=8;PageTimeout=5;SafeTransactions=0
;Threads=3;UserCommitSync=Yes;"
dbexample.Open
' or use this method if a DSN entry was created.
'dbexample.Open("DSN=Flight32")
flightnumber = 6195
' Get the recordset returned from a select query.
Set recordset = dbexample.Execute("SELECT * from Orders WHERE Flight_Number
= " & flightnumber)
' Display the results of the query.
msgbox recordset.GetString
' Close the database connection.
dbexample.Close
Set dbexample = Nothing
QuickTest.Application
This object is QuickTest itself. This can be used to parameterize QuickTest before
running a test or while running a test. For further information, see the help from Help
> QuickTest Automation Object Model Reference.
Dim qtApp
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 29
Set qtApp = CreateObject("QuickTest.Application")
qtApp.Launch 'Start QuickTest
qtApp.Visible = True 'Make the QuickTest application visible
Set qtTest = qtApp.Test
qtTest.Run
InternetExplorer.Application
This object can be used to create an Internet Explorer object.
Set IE = CreateObject("InternetExplorer.Application")
IE.Visible = True
IE.Navigate "http://cso-intranet/main.xml"
IE.FullScreen = True
IE.MenuBar = False
IE.StatusBar = False
IE.ToolBar = False
Wait 3
MsgBox IE.Name
IE.Quit
Mercury.DeviceReplay
This object can be used to replay user actions (keyboard or mouse). This is a replay
solution when nothing is recorded and when SendKeys does not work.
Set oDev = CreateObject("Mercury.DeviceReplay")
oDev.MouseClick absx + 5, absy + 5, CLng(Btn)
Set oDev = Nothing
Scripting.FileSystemObject
This object can be used to manipulate files in the filesystem.
Public Function CompareFiles (FilePath1, FilePath2)
Dim FS, File1, File2
Set FS = CreateObject("Scripting.FileSystemObject")
If FS.GetFile(FilePath1).Size <> FS.GetFile(FilePath2).Size Then
CompareFiles = True
Exit Function
End If
Set File1 = FS.GetFile(FilePath1).OpenAsTextStream(1, 0)
Set File2 = FS.GetFile(FilePath2).OpenAsTextStream(1, 0)
CompareFiles = False
Do While File1.AtEndOfStream = False
Str1 = File1.Read(1000)
Str2 = File2.Read(1000)
CompareFiles = StrComp(Str1, Str2, 0)
Mercury QuickTest Professional Scripting Guide
Proprietary and confidential to Mercury Interactive Corporation unless otherwise noted.
Page 30
If CompareFiles <> 0 Then
CompareFiles = True
Exit Do
End If
Loop
File1.Close()
File2.Close()
End Function
' Example of use:
File1 = "C:\countries\apple1.jpg"
File2 = "C:\countries\apple3.jpg"
If CompareFiles(File1, File2) = False Then
MsgBox "Files are identical."
Else
MsgBox "Files are different."
End If
WinHttp.WinHttpRequest.5.1
This is an object for managing the HTTP protocol.
Public Function DownloadURLToLocal(URL, Target)
Set FSO = CreateObject("Scripting.FileSystemObject")
Set FileObj = FSO.OpenTextFile(Target, 2, True) ' Write mode
Set HTTP = CreateObject("WinHttp.WinHttpRequest.5.1")
HTTP.Open "GET", URL, False
HTTP.Send
FileObj.Write HTTP.ResponseText
FileObj.Close
Set HTTP = Nothing
Set FileObj = Nothing
Set FSO = Nothing
End Function
DownloadURLToLocal "http://cso-intranet/Mercury-General/examples/rpcrouter",
"C:\rpcrouter3.xml"
'XMLFile("rpcrouter.xml").Check CheckPoint("rpcrouter.xml_2")