qtp framework(2)

8/6/2019 QTP Framework(2)

http://slidepdf.com/reader/full/qtp-framework2 1/100

QTP Frame Work60696016.doc

Confidential . Credence systems of 100

QTP

Frame Work




Table of Contents

1. Automation Architecture .......................................................31.1 Design ........................................................................................................................ 31.2 Approach for Test Automation .................................................................................. 4

2. Introduction to QTP ........................................................ 112.1 QTP Environment Compatibility ............................................................................. 122.2 Versions of QTP ......................................................................................................13

3. Add-Ins ............................................................................... 213.1 Types of Add-Ins .....................................................................................................213.2 Conditions for Add-ins ............................................................................................22

4. Conventions ......................................................................... 234.1 Test Case Naming Conventions: ..............................................................................23

4.2 Script and Action Naming Conventions: ................................................................ 234.3 Variables and Constants: ..........................................................................................254.4 DataSheet Naming and Parameter Naming Conventions: ....................................... 264.5 Function Naming Conventions ................................................................................ 27

5. Settings ............................................................................... 285.1 QTP Test Settings .................................................................................................... 285.2 Record and Run Settings ..........................................................................................295.3 Active Screen Capture Level ...................................................................................295.4 Object Repository ....................................................................................................305.5 Expert View ............................................................................................................. 325.6 Setting related to the Application Used: .................................................................. 35

6. Objects ............................................................................... 386.1 Objects ....................................................................................................................38

7. Data Table .......................................................................... 407.1 Datatable Object and related Functions: ................................................................. 407.2 Organizing Data Sheets for Global & Local variables ............................................ 417.3 Parameterizing using Data driven Wizard .............................................................427.4 Importing and Exporting Datasheets: ...................................................................46

8. Actions ................................................................................ 498.1 Actions Settings ....................................................................................................... 498.2 Iterations using rows ................................................................................................508.3 Action Template .......................................................................................................51

8.4 Script Startup ...........................................................................................................518.5 Splitting Actions, Re-usable Actions, Internal/External Actions ............................ 52

9. Object Repository ................................................................ 539.1 Per Action/Shared Object Repository: .....................................................................539.2 Merging of two object repositories: .........................................................................559.3 Limitations: ..............................................................................................................57

10. Variables ........................................................................... 5810.1 Action Parameters ................................................................................................59





10.2 Test Parameters ......................................................................................................6110.3 Environment Variables ..........................................................................................6310.4 Variable passing from one Action to another .......................................................6410.5 Scope of Variables ................................................................................................. 66

11. Check Points ...................................................................... 68

11.1 Types of Checkpoints ............................................................................................ 6811.2 Output Values for Verification ..............................................................................70

12. Reusable Library ................................................................ 7212.1 Introduction ...........................................................................................................7312.2 How to establish a Reusable Library .....................................................................7312.3 How to use this Reusable Library......................................................................... 75

13. Regular Expressions .......................................................... 7513.1 Description ............................................................................................................. 75

14. Recovery Scenario ............................................................ 8014.1 Exceptional Handling using Recovery Scenarios .................................................. 8114.2 Sample for Recovery Scenario: ........................................................................... 87

15. Optional Steps ................................................................... 9315.1 Description: ........................................................................................................93

16. Reporting ........................................................................... 9516.1 Different Options for Reporting .............................................................................9616.2 Functions used for Reporting ..............................................................................9716.3 Reporting Formats .................................................................................................99

1. Automation Architecture

1.1 Design





1.2 Approach for Test Automation

Description





Approach for Test Automation is used for building a strategy for automation startingfrom the Requirement phase till the deployment phase. Approach for automation beginswith finding out the conditions and business rules given by the client and groupingsimilar conditions, business rules together as Test cases or Test Scenarios.

Steps involved in Approach for Test Automation are as follows:

• Requirement gathering from the client

• Understanding and Analyzing the Requirement

• Grouping the requirement into Test cases

• Preparing the Design for Automation

• Building Scripts depending on the Design

• Review of Scripts at Offshore

• Delivery to the Client

For example in the Unilever project:

Since it is Project for Automation of SAP, Team was divided into two,SAP Consultants.Testing Team.

Requirement gathering from the client included knowledge transfer at onsite, where allthe transactions including the customized transactions where explained to the SAPConsultants of satyam, Under standing of requirements was done at the client side,Depending on the flow of transactions, all the transactions where grouped together asdifferent scenarios. While SAP Consultants where onsite for gathering Requirements,

Work done at the offshore was to analyze on the appropriate version of the QTP Tool to be used and to get licenses for QTP, user accounts for SAP access, Installation of QTPand SAP. All the Identified Scenarios which consists of different transactions where explained toTesting Team. Then common functionalities where identified, and grouped together asdifferent Test cases.

After defining different Test cases, design for automation of scripts was done, whereReusability was one of the main aspects, where all the transactions, which are common inthe scenarios, are identified as Reusable transactions.

Automation Framework:

For Quality deliverables, important things that should be followed are:

• Following common coding structure for all the scripts





• Consistent coding conventions

• Use of Reusability for making code efficient and minimal

• Efficient use of Object Repository

• Use of Error and Exception handling Functions

• Use of Data table object, Environment variables for using data

For example in the Unilever project:

Coding Structure used is that there will a main Action for all the scripts which is namedas corresponding Test case name, This Action intern will call all the other actions (EachTransaction used in the script would be an action) in the script. Importing and

Exporting of sheets is also done in this main action. Importing of sheets is done at the beginning before calling other actions and exporting of sheets is done at the last. Sheetscorresponding to all the actions in the scripts are imported, so that the data in the fields of the imported sheets are used as input data to the script, output data from the script is alsocollected and exported to the corresponding sheet.

There are many transactions which are reused in the scripts, similar transactions(Actions) are made as reusable so that its not required to record those transactions againand again, which ever transaction was common among scripts, were recorded in onescript and is reused in all the scripts where the transaction is required.

Error handling in the unilever automation is done by using Recovery Scenario whereeach Recovery scenario calls a function which handles the recovery by exiting all theother transactions (actions) when recovery fires. Major types of Recovery used in this project where Popup Window, Object state and on Error Recoveries. In Error handling using Recovery, all the common types of exceptions or errors are given

common Recovery scenarios using regular expressions, which minimized the number of Recovery scenarios and Functions used.

Design for Structure of Scripts used in Unilever Project:

Main Action, which calls all the other Called Actions





Actions (transactions) in the script

Calls

Ex: S014_001 (Action Name) Ex: ME21N (Action NameWhich is same as theTransaction name inSAP)


Main Action

in the Script

<Action Name>

<Action Name>




Design of the Approach for Test Automation is given below


Identification of Test Cases for Automation

Identification of Common Functionality

Coding Standards, Naming Conventions & Templates

Application Login,Logout, CommonFunctionality

Related code etc

Tool & ApplicationSettings, Restoring,Object Repository,

Recovery, House

Keeping etc

General librarycontaining Stringhandling, Date handling,File Handling, DataTable handling

Error handling, LogReporting,messaging etc

Script Development using Record & Play back

Building the Re-Usable Library

Deliver the script after Verification & Validation




Design for Automation of Test cases for Unilever Foods:

It’s a description of Automating a test case belongs to SAP by explaining a scenarioS014-081

Scenario Objective: Moving a Material from Raw Material Storage Location to aProduction Storage Location, Creating a Transfer Requirement and a Transfer Order.

Note: The phase in blue color indicates where more efforts are required in analyzing andrecording to generate a script.

QTP Framework in SAP Automation


Actions for the Transactions Login, LB01,MM03, LT04, LT012 and Logoff.

Common Functions are LT12, MM03

Coding Standards & Naming Conventions like ‘The file name as per convention - Scenario name’, ‘The Action named as per transaction ID’

ApplicationLogin, Logoutand commonfunctions likeLT12, MM03

Recoveries aregAlready_exist.qrsS014_164_Material_Not_Maintained.qrs

Error handling like OnError Resume Next,Reporting likereporter.ReportEventetc

Business Transactions Scripts are LB01 and LT04

Building the Re-Usable Library like ‘Thecommon functionality being reused’




• Applications with Long Life span – Longer the application in production

greater the benefits from automation.

• Avoiding dynamic screens. Though possible to automate this increases the

complexity of the script.

• Avoiding screens where objects are created dynamically

• Avoiding business scenarios where complex hardware is involved

• Selecting a row in a table results in an additional challenge from. Some

automation tools provide the facility to read each row in a table and for

focusing on a specific row. If the numbers of rows were very high the

execution time of the script would be high. This leads to performance

issues of the recorded script. Hence, it is better to prove the business

scenario wherein tables with row selections figure by identifying a fixed

row number. This scenario is faced very frequently in enterprise

applications as in pricing tables and leads to the complexity of the script

and subsequently the effort.

• Avoiding scenarios that require high degree of coding while automating so

that script’s complexity is reduced and high maintainability of the script is

ensured.

2. Introduction to QTP





2.1 QTP Environment Compatibility

QTP (version) supports a wide range of working environments and thereby can be usedfor practically any application.

Core Environments Supported by QTP:

- Windows applications (MFC)- Visual Basic- Java- ActiveX

Enterprise Applications:

- SAP- Siebel

- PeopleSoft- Oracle

Web Technologies:

- HTML- DHTML- JavaScript

Browsers:

- Internet Explorer - Netscape- AOL

Emerging Technologies:

- .NET winforms, webforms, web services- J2EE Web services- XML, WSDL, UDDI

Terminal Emulators:

- 3270- 5250- VT100

Server Technologies:





- Oracle- Microsoft- IBM- BEA- ODBC

- COM / COM+

Multimedia:

- Flash- RealAudio / RealVideo- Windows Media Player

Operating Environment

Operating SystemsSupported: Windows XP/2000/NTWindows 95/98/ME

Databases Supported: (Not Applicable)Networks Supported: TCP/IPProgramming

Languages Supported:

JavaScriptJavaHTMLVisual Basic (VB)XML

Middleware Supported: Microsoft .NET

2.2 Versions of QTP

QTP 6.5:

To successfully install and run QTP6.5, following minimum systemrequirements are required :

Computer/Processor: IBM-PC or compatible with a Pentium® II 266 MHzmicroprocessor (366 MHz recommended).

Operating System:

Windows® 98 Second Edition, Windows® 2000— Service Pack 3,Windows NT® 4.0—Service Pack 6a,Windows® Me, or Windows® XP—Service Pack 1.





Memory: 128 MB of RAM (256 MB recommended)

Free Hard Disk

Space: 150 MB of free disk space for a compact installation or 200 MB for a typical or complete installation

Browser: Microsoft Internet Explorer 5.0–6.0.

Supported Environments

QuickTest Professional supports creating, recording, and running tests in theenvironments described below.

Standard Windows Applications

Win32 API

MFC

Visual Basic Applications

Visual Basic 6.0

Browsers

• Microsoft Internet Explorer 5.01–6.0 (required)

•

Netscape Navigator 4.06–4.7x (optional)

• Netscape 6.1, Netscape 6.22, and Netscape 6.23 (optional)

• AOL 5.0 and 6.0 (optional)

ActiveX Grid Controls

In addition to basic support of ActiveX properties and methods,QuickTest Professional supports context-sensitive recording andverification on the following ActiveX Grid controls:





Name ProgId

FarPoint Spreadsheet 2.5 FPSpread.Spread.1




FarPoint Spreadsheet 3.0 (OLEDB) FPSpreadADO.fpSpread.2


FarPoint Spreadsheet 6 (OLEDB) FPSpreadADO.fpSpread.4

Microsoft Grid 1.0 MSGrid.Grid

Microsoft DataBound Grid 5.0 MSDBGrid.DBGrid

Microsoft Flex Grid 6.0 MSFlexGridLib.MSFlexGrid.1

Sheridan Data Grid 2.0 SSDataWidgets.SSDBGridCtrlApt.1


Apex True DataBound Grid 5.0 TrueDBGrid50.TDBGrid


Apex True OLE DB Grid 6.0 TrueOleDBGrid60.TDBGrid

ActiveX Calendar Controls

In addition to basic support of ActiveX properties and methods,QuickTest Professional supports context-sensitive recording andverification on the following ActiveX Calendar controls:

Name ProgId

Microsoft Date and Time Picker Control 6.0 (SP4) MSComCtl2.DTPicker.2

Microsoft MonthView Control 6.0 (SP4) MSComCtl2.MonthView.2





Multimedia Applications

QTP6.5 supports testing on the following multimedia applications:

• Microsoft Windows MediaPlayer controls, version 6.0 and higher

• RealPlayer controls supported for Internet Explorer browsers (thecontrols within applications containing browser controls are notsupported)

• Macromedia Flash 4 or 5 objects that are ActiveX controls inInternet Explorer. You can also test Macromedia Flash 6 clipscontaining only Flash 4 or 5 commands.

Additional Environments

QuickTest Professional add-ins support other environments such asJava, .NET Windows and Web Forms, SAP solutions, Oracle, Siebel,PeopleSoft, Web Services, and terminal emulator applications. For moreinformation about QuickTest Professional add-ins, contact your salesrepresentative or Mercury Interactive Customer Support.

Note for QuickTest Professional 6.0 and earlier: Java support and Oracle support are now available as separate add-ins toQuickTest Professional 6.5 and are no longer part of the core product.

QTP 8.0:





Name ProgId







FarPoint Spreadsheet 6 (OLEDB) FPSpreadADO.fpSpread.4

Microsoft Grid 1.0 MSGrid.Grid

Microsoft DataBound Grid 5.0 MSDBGrid.DBGrid

Microsoft Flex Grid 6.0 MSFlexGridLib.MSFlexGrid.1





Apex True OLE DB Grid 6.0 TrueOleDBGrid60.TDBGrid

ActiveX Calendar Controls

In addition to built-in support for ActiveX properties and methods,QuickTest Professional supports context-sensitive recording andverification on the following ActiveX Calendar controls:

Name ProgId

Microsoft Date and Time Picker Control 6.0 (SP4) MSComCtl2.DTPicker.2

Microsoft MonthView Control 6.0 (SP4) MSComCtl2.MonthView.2





Microsoft Excel

When using Microsoft Excel files with QuickTest Professional 8.0(for example, to import or export data to or from the Data Table), you canwork with Microsoft Excel 2000, 2002, 2003, and XP.

Microsoft Query

When using Microsoft Query with QuickTest Professional 8.0 (for example, for Database checkpoints), you can work with MicrosoftQuery 2000, 2002, 2003, and XP.

Additional Environments

QuickTest Professional add-ins support other environments such asJava, .NET Windows and Web Forms, SAP Solutions, Oracle, Siebel,PeopleSoft, Web Services, and terminal emulator applications. For moreinformation on QuickTest Professional add-ins, contact your salesrepresentative or Mercury Interactive Customer Support.





3. Add-Ins

3.1 Types of Add-Ins

QTP version Add-ins

8.2

Java add-in 6.5Oracle add-in 6.5

Siebel add-in 8.0Terminal Emulator add-in 8.0. Net add-in 8.2

Default Add-Ins: Active X Controls,Web &Visual Basic

8.0

. Net add-in 6.5.1Sap add-in 6.5.1Java add-in 6.5PeopleSoft add-in 6.5Oracle add-in 6.5Terminal Emulator add-in 6.5

Default Add-Ins: Active X Controls,Web &Visual Basic

6.5 . NetWebJavaXML

Default Add-Ins: Active X controls,Multimedia, Visual Basic, Web

Note: Quick Test Professional Siebel add-in 6.5 and Web services add-in 6.0 cannot beused with Quick Test 8.0.

• The add-ins for Quick Test Professional 6.0 cannot be used with Quick TestProfessional 6.5. If you are using Quick Test Professional 6.5, you will need toget the 6.5 version of your add-in.





3.2 Conditions for Add-ins

3.2.1 Java Add-In

When testing Java applets in a Web browser, you must load the Web add-in as well as theJava Add-in, and use the Web tab of the Record and Run SettingsDialog box to specify your record and run preferences. To test Java applets or applications running on Netscape 4.x’s built-in JVM (not Java Plug-ins), confirm that the Netscape 4.x browser is already installed before installing the Quick Test ProfessionalJava Add-in. When testing Java applets in a Web browser web Add-in as well as javaadd-in must be loaded .To create a checkpoint, parameterize a step, or to add a methodfrom individual java applets, the Java Add-in must be loaded.

3.2.2 .Net Add-In

The .Net add-in is required to support objects developed in .Net .In some cases, eventhough the application has been developed using .Net, when the page is sent to the browser, it is a plain HTML page. Quick Test Professional can recognize HTML controlslike edit fields, buttons etc. without the .Net add-in. However, if a Web applicationcontains complex controls like ActiveX or other controls developed in .Net like ASP.Netserver controls, it is required to use the .Net add-in to achieve object recognition.

3.2.3 Sap Add-In

The Sap add-in is required for all SAP applications. In SAP application Grid Tables,Status Bar messages, Labels can be identified only if SAP Add-in is installed.





Use Case

Test Case

Condition1 Condition2 Condition3 ………

Test Case Test script

Condition 1 Action1

Condition2 Action2 Therefore for a Test Script corresponding to a Test Case named TC_001 would beQTS_001.The hierarchy should be maintained in case the use cases or test cases arenested.

E.g.: TC_01_014 would have a QTP Test Script as QTS_01_014.

Action Naming:

Each Test Script can contain one or more Actions, with one or more actions representinga test Condition.Actions can be named in 2 ways:

1. Functionality of the Action2. Hierarchy of the Action in the Test Script.

1. Functionality of the Action:

Typically Actions are segregated by their functionality in the Test Script.Therefore it would be easier to understand the Action if the name of the actionrepresents the Functionality.

For E.g.: An Action written or recorded for logging the user should be named asLogin or Authentication for easy understandability.An Action for booking tickets should be named as Book_Tickets

An Action for exiting the application named as Exit.

This also adds a huge advantage when the Actions are madereusable. Reusable Actions can be used between various scripts. When an Actionis to be made reusable the action should be named as REUSE_(Action name).

Example: REUSE_Login.





2. Hierarchy of the Action in the Script:

Since Actions are a part of the Test Script, for purpose of Clarity and tracking,Actions can be named as per Hierarchy.

For e.g.: Test Case Name TC_01

QTP Test Script Name QTS_01

Name of 1st action in the Script QTS_01_01

Similarly Name of 9th Action in the ScriptQTS_01_09

4.3 Variables and Constants:

QTP Scripts are in VB Script. Therefore, the naming conventions for variables can be

followed alike VB Script Naming Conventions.

General Conventions followed in VBScript are:

Data Type Prefixes:

By using data type prefixes, your variables always indicate what they are designed for.I'm using just six prefixes:

Prefix Data Types Example

b Boolean (true or false) bChecked = True

d Date/time dStartTime = Now

iAll numeric data types(Byte, Integer, Currency, Long, Single, Double)

iTax = iPrice * 0.076

o Objects Set oFile = Nothing

s Strings sTitle = "Welcome!"

u User interface elements uPara.style.display = "block"

Constants Prefix:

Usually there are only a handful of constants in any scripts. Indicating the data typetherefore is less important for constants. Prefix letter c for all constants can be used.e.g. Const cTitle = "Welcome!"UDocument.title = cTitle





4.4 DataSheet Naming and Parameter Naming Conventions:

Every QTP Test Script contains 2 types of sheets.1. Global data sheet2. Local data sheets

The Global data sheet, which is a common sheet for all the actions of the script, isnamed by default as dt_globalsheet. This can be renamed as Global for all the Scripts for consistency.

Typically, Each Action in the Script contains one data sheet, which is local to theAction. This is by default, named after the Action to which it belongs. Therefore thename of the datasheet follows directly the name of the Action, which when named

following its naming conventions, can be used efficiently for the data sheet too.

Parameter Naming:

Various Types of Parameters used in QTP are:

1) Test Parameters

a) Test Input Parameters: These should be named as IN_(relevant variable name).‘In’ denoting that it’s an input parameter for the Test in whole. The name following IN

should be a relevant name for the variable, denoting the purpose of its use. This shouldalso comply with the standard variable naming conventions.Example: IN_bFlag, IN_iIncrement etc.,

b) Test Output Parameters: On the similar lines of Input Parameters, these should benamed as OUT_(relevant variable name). OUT representing that it’s an output parameter.Example: OUT_sStatus.

2) Action Parameters

a) Action Input Parameters: These are local to Action of a Test. These can be named asACTIN_(variable name). ACTIN denoting that it’s an Action Input Parameter.Example: ACTIN_iResult

b) Action Output Parameters: These could be named as ACTOUT_(var name).





Example: ACTOUT_bFlag

3) Environment Variables:

Environment variables are either built-in or User defined. Built-in variables cannot bedeclared named by the user, so their naming convention is not discussed.

User Defined Environment Variables are either Internal or External.Internal Variables: ENV_INT_(variable name)

External Variables: ENV_EXT_(Variable name)

4.5 Function Naming Conventions

Functions should be named as Func_(name). This can provide clarity and difference between a Reusable Action and a Function that can be used within Actions.Example: Func_Save , Func_Add





5. Settings

5.1 QTP Test Settings

Before Running or Recording any test on QTP, the QTP Test settings need to be set as per the requirements of the Test. Setting these Test Settings before starting a Test plays acrucial part in the behavior of the test.

These can be found at the path Test>Settings. A dialog box pops up, in which varioustabs are present which allow one to set

• Properties of the test like Add-Ins used

• Run time Preferences

• Resources like files, data tables, and repository to be used.

• Parameters required in the Test.

• Environment variables used

• Web navigation• Recovery Scenarios

Note: For further details about the use of each tab, refer to QTP Test Settings


http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/QTP%20Test%20Settings.doc






5.2 Record and Run Settings

After Setting the Test Settings at Test>Settings, the next important settings for actually

recording the application and running it for Testing are to be set at the Test>Record andRun Settings. This dialog box opens automatically, when recording a test for the firsttime. The details of which application to record are set in this dialog box.

For further details about these settings refer to Record and Run Settings.

5.3 Active Screen Capture Level

One of the most useful fetaures of QTP is the various views it provides, out of whichActive view is the most unique.The selection of the appropriate Active Screen Capturelevel influences the storage space, properties stored and the view of the Active screen.The selection can be made by going to Tools>Options>Active Screen.

The Active screen settings can also set at the Test>Record and Run Settings.

The active screen capture level can be set to any of the 4 levels i.e. Complete, Partial,Minimum and None.


http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Record%20and%20Run%20Settings.doc







For details about each capture level, refer to ActiveScreen Capture Level.

5.4 Object Repository

When a test is recorded, QTP adds each object on which an operation is performed, tothe Tools>object repository. Objects can be added to the repository while editing thetests too.While recording, Objects are added to the repository in either of the two ways:

a. Object Repository per Action

b. Shared Object Repository.


http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Active%20Screen%20Capture%20Level.doc






The settings can be changed by going to

Test>Settings>Resources>Object Repository Type

In the Per-Action mode, objects are identified and separated on the basis of each

action and the corresponding object repository for the test is created in the testfolder.In the Shared mode, the user may choose a location to save the sharedobject repository files for all the tests.

All the Objects recorded during a test,and their properties can be seen andmanipulated in the Tools>Object Repository.There are provisions in this ObjectRepository Dialog box to add new objects,spy objects, find and replace propertyvalues etc.





The First Section of Object Repository Dialog Box contains provisions toa. Add Objects : A Button to add new objects to the repository. b. Highlight: To highlight the object selected in the repository, when the application

is open.c. Object Spy: To Spy any Object, to see its Properties.d. Export: To Export any objects to an outside location.

The second section of the dialog box contains provision to Find, Replace, Add, andRemove the properties of an object in the Repository also set any default values for the properties.

5.5 Expert View

While recording Tests in QTP, there are 3 important views that enable us to understandclearly, the various representations of the Script. They are

a. Expert View b. Keyword View: Hierarchical Representation of Actionsc. Active Screen View: Pictorial view of the currently active Screen.





Fig: Keyword view and Active Screen view corresponding to one expert view statement

5.5.1 Step Generator:

If the user is familiar with VBScript, the user can add and update statements and enhancethe tests and components with programming. After the test or an Action is recorded, its power and flexibility can be increased by adding recordable and non-recordable VBScriptstatements as required for tasks like Check Points,Datatables etc.,.These additional stepscan be added either manually or using Insert>Step >Step Generator .whenever a step isadded to a script, then any Syntax errors of the step can be Identified in its Keywordview.





The Step Generator enables you to add steps quickly and easily, by selecting from a rangeof context-sensitive options and entering the required values.The generated step getsadded at the position of cursor in the expert view.The Step Generator enables you to add steps quickly and easily, by selecting from a rangeof context-sensitive options and entering the required values. In the Step Generator dialog box you can define steps that use:• test object methods and properties• utility object methods and properties• calls to library functions, VBScript functions, and internal script functions

5.6 Setting related to the Application Used:

The different kind of Applications that can be tested using QTP are windowsapplications,web based(java and .Net),SAP,Oracle etc.Apart from the windowsapplications using MFC and simple web applications(which can be run with default add-ins), rest all applications require a special Add-in to be purchased to do the testing.Each





Add-in which is bought and installed, results in a new tab in all the setting dialog boxes ,using which various setting options can be chosen.It purely depends on the type of application , how to choose a particular setting option.

Example of a SAP Add-in :

Fig: The Add-in manager dialog with SAP add-in





Fig: Record and Run Settings with a SAP Add-in.For detailed information of the settings of the tabs other than the special tabs refer Record

and run settings.


http://smb//hrbnt006/Quality_Data/ra18713/Mahesh&RK/29-12/Reference%20documents/Record%20and%20Run%20Settings.doc







6. Objects

6.1 Objects

Objects are the things which contains different properties and methods.

For Example: Window is said to be an object which consists of properties such asExist, GetROProperty and methods such as ChildObjects, Activate, maximize,minimize etc.

Property:

Property describes about the object defined, each object has different properties,

which is necessary to describe the object, which differentiates the given objectwith other objects.

For example: If we take a window object, we first have to define to which class it belongs to which is one of the property, it belongs to a window class. Exist is a property which is common to many objects which returns true if that object exists.

Methods:

Methods are functions, which are used for changing the properties of the objectthat is in order to manipulate with the object properties we use.

For example: If we take a window object, Activate is a method used to activatethe window object, thus by using Activate method Activate property of the present window object is set to true, thus the window object will be activated if not in activated mode.





Sample for Object hierarchy:

In the above sample of code, there are two main Objects, one is Dialog andthe other is Window object. This objects contain child objects, For Dialogobject which is named as “Login” has WinEdit object with name as “Agent Name:” as childobject, here Set is the method used to set a text into theWinEdit object.

“Set” is the method associated with “WinEdit” object


“Dialog” Object

Child Objectfor “Dialog”Object

Method for “WinEdit”Object

WinEdit

Dialog Parent Objectnamed as “Login”

Child Objectnamed as “Agent Name:”




7. Data Table

In QTP scripting there are many objects that are used, One of the Objects used inQTP scripting is DataTable Object.

7.1 Datatable Object and related Functions:

Description

Basic use of Datatable object is to create an object for adding, deleting, updating dataof an excel sheet used.

Main functions of the datatable object:

• Importsheet : This function is used to Import sheet into the script, so that allthe data in the imported sheet can be used in the script.

Syntax:

Datatable.Importsheet(“nameofExcelfilewithpath”,“nameofthesourcesheet”, “nameofthedestinationsheet”)

• Exportsheet : This function is used to Export sheet from the script, all thedata including output values are stored in the default sheet for the action, thissheet is exported and stored in a specified location using this function.

Syntax:

Datatable.Exportsheet(“nameofExcelfilewithpath”,“Nameofthesheet”)

• Addsheet : Used for adding a sheet into the script file.

• GetRowCount: This function is used to get the no of rows in a particular sheet.

Syntax:

Datatable.AddSheet(“Sheetname”).GetRowCount





• GetCurrentRow: This function is used to get the current row of a particular sheet.

When an action is run by using run setting as “run on all rows”, that actionwill run as many times as the number of rows in the excel sheet of the action,in order to find the row for which action is running currently we useGetCurrentRow function.

Syntax:

Datatable.GetSheet(“Sheetname”).GetCurrentRow

7.2 Organizing Data Sheets for Global & Local variables

Description

There are two types of sheets in any QTP Script, they are

GlobalsheetLocalsheet

Globalsheet: Globalsheet in any script is unique, Globalsheet is used in order to store

values in the sheet and the values stored in Globalsheet can be used in all the actions. For storing a value in the global sheet we use the following function:

Datatable.Value(“Fieldname”,”Global”) = Value

For using the values from the global sheet we use the following function:

Value = Datatable.Value(“Fieldname”,”Global”)

Localsheet: Each and every action in the script will have its own Localsheet, name of the

Localsheet of a particular action is same as the action name.

For using the data from the Local sheet we use following function:

Datatable.Value(“Fieldname”,dtlocalsheet)Or

Datatable.Value(“Fieldname”,”Sheetname”)





Organization of Global and Local sheets with the actions used in the script are shown below:

7.3 Parameterizing using Data driven Wizard

Description

The Data Driver enables you to quickly parameterize several (or all) propertyvalues for test objects, checkpoints, and/or method arguments containing the sameconstant value within a given action.

You can choose to replace all occurrences of a selected constant value with a parameter, in the same way that you can use a Find and Replace All operationinstead of a step-by-step Find and Replace process. QuickTest can also showyou each occurrence of the constant so that you can decide whether or not to parameterize the value.

If any property of an object is taken, that property can be parameterized using Data

driven Wizard,


Action name:“Login”

GlobalSheet

Local Sheet for “Login”Action




Different steps for parameterization using Data driven Wizard is as follows:

• Go to tool bar option Tools and select Data Driver option

• We will get a list of all the properties of all the objects which can be

parameterized (i.e. for all the objects where a value for a property is given inthe script)

For example consider script for entering Login name which is as followsDialog("Login").WinEdit("Agent Name:").Set "name"

The Set property of WinEdit Object appears in the list of Datadriver with “name” asValue representing the Set property of “Agent Name” Editbox, which is as given below:

• Select a value which should be parameterized and click on “Parameterize” button.

• There will be two options to be selected as given below:





Step-by-step Parameterization: Enables you to view the current values of each stepcontaining the selected value. For each step, you can choose whether or not to parameterize the value, and if so, which parameterization options you want to use, theNext button is enabled when you select this option, this will enable us to select an other

instance of the constant selected and parameterize that instant, it will continue the same process till all the instances of the given value are done.





Parameterize all: Enables you to parameterize all occurrences of the selected valuethroughout the action.When you select this option the Parameter details area is enabled. The Finish button isenabled when you select this option.





Here Parameter tab can be selected using the button given at the “Parameter” radio button, and in the next screen select the datatable Field from where the property for which the value belongs is parametererized, click on “Finish” button thus all the instancesof the value selected for parameterization will be parameterized.

7.4 Importing and Exporting Datasheets:

Description

Importing and Exporting of Datasheets are used for reading, writing and manipulating thedata in an excel sheet.

Importing Datasheet:

Description

Imports a sheet of a specified file to a specified sheet in the run-time Data Table. Thedata in the imported sheet replaces the data in the destination sheet (see SheetDest

argument).





Note: All the fields in the imported sheets should match with the data used in the script.There are two functions for Importing, Importing the whole excel file and Importing thesheets in the file.

Function for Importing the whole Excel file:

Imports the file into the script with all the sheets which are there in the excel file.

Note: Sheets in the excel file should match with the Actions in the script to use the dataefficiently, since action name and corresponding sheet name should be same.

Syntax:

Import “filenamewithpath”

Function for Importing the sheets from the excel file:

Imports the specified sheet into the script.

Syntax:

Importsheet “filenamewithpath”,”sourcesheetname”,”destinationsheetname”

Exporting Datasheet:

Description

Exports a specified sheet of the run-time Data Table to the specified file.

• If the specified file does not exist, a new file is created and the specified sheet issaved.

• If the current file exists, but the file does not contain a sheet with the specifiedsheet name, the sheet is inserted as the last sheet of the file.

• If the current file exists and the file contains the specified sheet, the exportedsheet overwrites the existing sheet.

Same as Importing, There are two functions for Exporting, Exporting the whole excel fileand Exporting the sheets in the file.

Function for Exporting the whole Excel file:

Exports the file into the script with all the sheets which are there in the excel file.





Syntax:

Export “filenamewithpath”

Function for Exporting the sheets from the excel file:

Exports the specified sheet into the script.

Syntax:

Exportsheet “filenamewithpath”,”sourcesheetname”,”destinationsheetname”





8. Actions

8.1 Actions Settings

You can use the Run tab of the Action Call Properties dialog box to instruct QuickTest torun only one iteration on the called action, to run iterations on all rows in the Data Table,or to run iterations only for certain rows in the Data Table.





8.2 Iterations using rows

The Run tab includes the following options:

Option Description

Run one

iteration

only

Runs the called action only once, using the row in the action's datasheet that corresponds to the current global iteration number. If theaction's data sheet contains fewer rows than the global sheet, the lastrow of the action's data sheet is used for each subsequent testiteration.

For example, suppose an action's data sheet has two rows and theglobal sheet has four rows. If you choose to run one iteration only

for the action and you choose to run iterations on all rows of theglobal data sheet, then during each iteration of the test, this actionwill run only one iteration. The data that the action parameters useduring each repetition of the test are based on the iteration number for the test.During the first iteration of the test, Data Table parameters in theaction take data from the first row of the action's data sheet. In thesecond iteration of the test, Data Table parameters in the action takedata from the second row of the action's data sheet. In the third andsubsequent iterations of the test, the Data Table parameters in theaction continue to take data from the second i.e. the last row of the

action's data sheet.

Run on all

rows Runs the called action with the number of iterations according to thenumber of rows in the action's Data Table.

Run from

row __ to

row __

Runs the called action with the number of iterations according to thespecified row range.

The Run tab of the Action Call Properties dialog box applies to individual action callsand refers to the rows in the action's data sheet.





8.3 Action Template

Creating an Action Template

If you want to include one or more statements in every new action in your test, you can

create an action template. For example, if you always enter your name as the author of anaction, you can add this comment line to your action template. An action template appliesonly to actions created on your computer.To create an action template:

1. Create a text file containing the comments, function calls, and other statementsthat you want to include in your action template. The text file must be in thestructure and format used in the Expert View.

2. Save the text file as ActionTemplate.mst in your <QuickTest Installation

Folder>\dat folder. All new actions you create contain the script lines from the

action template.

Only the file name ActionTemplate.mst is recognized as an action template.

To view the Action template refer to ActionTemplate.mst

8.4 Script Startup

• Check for the required add-ins for an application.• Include action template for every test containing script id, Action name, Action

Description, Recovery scenario used etc.

• Every action, scenario must be specified with an appropriate name.

• Check for mandatory input fields for all iterations in the datasheets that are beingimported.

Example:The Resources tab of the Test Settings dialog box can be used to associate specific fileswith the test, such as Data Table files.

The option area Other location instructs Quick Test to use data stored in the specifiedData Table location. The Data Table can be any Microsoft Excel (.xls) file.





For a sample external file refer to Sample External File

• Check for the “Data table iterations” under the test settings for which the test hasto be run.

For further details refer to QTP test settings doc.

8.5 Splitting Actions, Re-usable Actions, Internal/External Actions

Actions help divide your test into logical units, specific activities that you performin your application.

A test is made up of calls to actions. When you create a new test, it contains a call to asingle action or create tests that call multiple actions by inserting calls to them, to makethe design more modular and efficient tests.


http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/external_data.xls








There are three kinds of actions:

• reusable action —an action that can be called multipletimes by the test with which is stored in the local test as well as byother tests.•

external action —a reusable action stored with another test.External actions are read-only in the calling test. They can bemodified only in the test with which they are stored.• Non-resuable-actions —an action that can be called onlyin the test with which it is stored, and can be called only once.

For further details on creation & splitting of actions refer to Actions.

9. Object Repository

9.1 Per Action/Shared Object Repository:


http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Actions.doc

http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Actions.doc




Setting the Shared /per action Object Repository option

To set only one test to use the Shared Object Repository option:

1. Click the "New" button or go to File -> New to open a new test.

2. Go to Test -> Settings.3. Select the Resources tab.4. In the Object repository type box, select one of the options:

• Select "Per-action" to set the Object Repository mode for your test to the ObjectRepository per action mode.

Below are some of the factors based on which Per Action option is selected





The Object Repository File Merge Utility allows users to merge object repository filesinto a single file. This utility is intended for an advanced user that builds powerful tests.

The Merge Utility allows you to merge the content of one Object Repository to another one thus giving you the flexibility and the power in controlling the content of the Object

Repository and the ability to dynamically change this content.

Conflicts:

The implementation of the merge algorithm is quite simple when the object repositoryfiles have different objects in them, or if all objects had only exact replicas in other files.Due to the nature of the operation it is often not the case. For example, if we try to mergetwo object repositories from tests that were recorded at different time points, betweenwhich some test objects properties have changed (e.g. whether a button is enabled) thenthe same object exists in the two repositories with different properties. We call this adescription conflict as the two objects have the same name, but different descriptive properties. It can also be that the user has decided to modify the automatically assigned

logical name of an object (for example, in order to create a shorter name) in onerepository but not in the other. In this case, two objects will exist with different logicalnames, but with the same descriptive properties. We call this a name conflict.

Resolving Conflicts:

It is not trivial to identify and handle conflicting objects. The user might want to mergetwo objects that were not initially the same, or decide to keep two objects that for theinexperienced eye would seem identical. For example, recording on web browsers wouldlikely generate identical logical names for browsers that have nothing in common. It isalso likely that if the text on a button has changed, new tests would record a new logical

name for it, even though the object behavior has not changed. It is therefore possible toeither keep the two objects (and their subtrees) separated, to assume that the two objectsare actually the same object, or to ignore one of the conflicting object. We will discussthese choices later in detail.

Note: The Merge Utility works only on machines where QTP8.0 is installed.

Merge Object Repositories Utility

Main Window:

This utility is designed to supply simple access to the functionality implemented by the





ObjectRepositoryMgr COM component. As the operation is not trivial, the UI has manyoptions to select, so we will discuss the different options in detail.

For different options of Merging refer to Merging of Object Repositories.

9.3 Limitations:

1. Mercury Interactive recommends that you keep the Object Repository under 1 MB and perform regular backups. If the size crosses more than 1MB loading of object repositorytakes lot of time .

2. The limitation on the number of Actions is 255. The reason is that each Action has adata 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.


http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Merging%20of%20Object%20Repositories.doc

http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Merging%20of%20Object%20Repositories.doc




Note: If you are calling reusable Actions, you may be able to have more than 255Actions within the script. This can be accomplished if you are calling the same Actionmore than one time within the script. The data sheet for the Action will only be loadedonce. This applies to "call to" Actions only.

Example:In a new script, insert a "call to" a reusable Action. When the Action is added to thescript, you will see the data sheet added to the data table. Insert another "call to" to thesame Action. The data sheet will not be added again.

10. Variables

In QTP scripting there are mainly 3 types of variable that we use. They are:





• Action Parameters.

• Environment Variables.

• VB Variables, which we declare in the script.

10.1 Action Parameters

Action parameters enable you to transfer values between actions and their nestedactions in your test, from your test to a top-level action, or from a step in a top-level action back to the script or action that ran (called) your test. For example,you can output a value from a step in a nested action and store it in an outputaction parameter, and then use that value as input in a later step in the calling parent action.

You define the parameters that an action can receive and the output values that it can

return in the Parameters tab of the Action Properties dialog box. You specify the actualvalues that are provided to these parameters and the locations in which the output valuesare stored in the Parameter Values tab in the Action Call Properties dialog box.

You can specify input parameters for an action so it can receive input values fromelsewhere in the test. Input values for an action can be retrieved from the test (for a top-level action) or from the parameters of the action that calls it (for a nested action). Youcan also specify output parameters for an action, so that it can output values for use later in the test, or pass values back to the application that ran (called) the test.

Setting Action Parameters

You can specify input parameters for an action so that steps in the action can use valuessupplied from elsewhere in the test. Input values for an action parameter can be retrievedfrom the test (for a top-level action) or from the parameters of the action that calls it (for a nested action). You can specify output parameters for an action, so that it can returnvalues for use later in the test. For each input or output action parameter, you define aname and a type. You can also specify a default value for each action input parameter, or you can use the default value that QuickTest provides for the parameter value type thatyou choose. The default value is saved with the action and is used by the action if a valueis not defined for a parameter in the action call. You can define, modify, and delete input

and output parameters in the Parameters tab of the Action Properties dialog box.





To add a new input or output action parameter:

1. Click the Add button next to the Input parameters or Output

parameters lists to add a new parameter to the appropriate list. A row for the new parameter is added to the relevant list.2. Click in the Name box and enter a name for the parameter.3. Select the value type for the parameter in the Type box. You can selectone of the following types:o String —A character string enclosed within a pair of quotation

marks, for example, "New York". If you enter a value and do not include thequotation marks, QuickTest adds them automatically when the value is inserted inthe script during the test run. The default value is an empty string.o Boolean —A true or false value. If you select a Boolean value

type, you can click in the Default Value column and click the arrow to select aTrue or False value. The default value is True.o Date —A date string, for example, 3/2/2005. If you select a Date

value type, you can click in the Default Value column and click the arrow toopen a calendar from which you can select a date. The default value is today'sdate.





The Parameters tab contains two parameter lists:

• Input parameters —Specifies the parameters that receivevalues from sources that are external to the test or component.• Output parameters —Specifies the parameters that passvalues to sources that are external to the test or component.

You can edit an existing parameter by selecting it in the appropriate list andmodifying its details.

You can add and delete input and output parameters for your test or componentusing the parameter control buttons:

Option Description





Adds a parameter to the appropriate parameter list. Enter a name for thenew parameter and select the parameter type. You can enter a descriptionfor the parameter, for example, the purpose of the parameter in thecomponent. If you are defining an input parameter, enter a default valuefor the parameter in the Default Value column.

You define test or component parameters in the same way you defineaction parameters.

Removes the selected parameter from the test or component.

Defining Values for Input Parameters

When the test or component runs, QuickTest uses the default value for eachdefined input parameter if a specific value has not been defined for the parameter in either QuickTest or Quality Center.

When you run a test or business component from QuickTest, input parameter values for tests and components are taken from in the Input Parameters tab of theRun dialog box.

Using Test or Component Parameters

Once you have defined test or component parameters, you insert them in your testor component by specifying the test or component parameter name with theParameter reserved object, in the format: Parameter("ParameterName").

10.3 Environment Variables

QuickTest can insert a value from the Environment variable list, which is a list of variables and corresponding values that can be accessed from your test. Throughout thetest run, the value of an environment variable remains the same, regardless of the number of iterations, unless you change the value of the variable programmatically in your script.

There are three types of environment variables:

• User-Defined Internal —variables that you define within the test. Thesevariables are saved with the test and are accessible only within the test in which

they were defined.

You can create or modify internal, user-defined environment variables for your test in the Environment tab of the Test Settings dialog box or in theParameter Options dialog box.





Tip: You can also create environment output values, which retrieve valuesduring the test run and output them to internal environment variable parameters for use in your test.

• User-Defined External —variables that you predefine in the active

external environment variables file. You can create as many files as you want andselect an appropriate file for each test, or change files for each test run. Note thatexternal environment variable values are designated as read-only within the test.

• Built-in —variables that represent information about the test and thecomputer on which the test is run, such as Test path and Operating system. Thesevariables are accessible from all tests, and are designated as read-only.

Note: QuickTest also has a set of predefined environment variables that

you can use to set the values of the Record and Run Settings dialogoptions. You should not use the names of these variables for any other purpose.

10.4 Variable passing from one Action to another

QuickTest enables you to retrieve values in your test or component and to store them asoutput values. You can subsequently retrieve these values and use them as input at adifferent stage in the run session. You can pass variables from one action to another by

setting Action Call Parameter Values. You use the Parameter Values tab of the ActionCall Properties dialog box to specify the values of input action parameters used by thecalled action and to specify the locations in which you want to store output action parameter values. You can also parameterize the value used for a particular input action parameter using any available parameter type.

The actual input and output action parameters that an action can receive or return, andtheir types, are defined in the Action Properties dialog box. If you do not set a value for an input action parameter in the Action Call Properties dialog box, the default value thatis specified in the Action Properties dialog box is used.





You can specify a location in which to store the output action parameter values, whichcan be used in the called action.

To specify a location in which to store an output action parameter value:

1. In the Output parameters area, click in the Store In box for the

parameter and enter a variable name.





If we choose variable to store the value, then the value is stored in a run-time variable for the duration of the run session. You can accept thedefault name assigned to the variable or enter a different variable name.

Alternatively, you can click the output storage button in the Store In

box to open the Storage Location Options dialog box in which you canspecify a location for storing the output value. You can select to store thevalue in a test or action parameter, a Data Table parameter, or anenvironment parameter.

2. Repeat this procedure for each output action parameter value in the list.

10.5 Scope of Variables

Mainly there are two types of variables: action parameters and environment variables.An action's parameters are stored with the action and are the same for all calls to thataction. If you change the action parameters defined for an action, and then view theaction properties for a call to that same action in a different part of the test, you can seethe action parameters have changed. However, the actual values specified for input action parameters and the locations specified for action output parameters can be different for each call to the action. When you insert a call to a copy of an action, the copy of theaction is inserted with the action parameters and action call parameter values that were





defined for the action you copied. When you split an action, the action parameters arecopied to both actions. The action call values for the second action are taken from thedefault values of that action's parameters.

Environment variables can be accessed from your test. Throughout the test run,

the value of an environment variable remains the same, regardless of the number of iterations, unless you change the value of the variable programmatically inyour script.

There are three types of environment variables:

User-Defined Internal —variables that you define within the test. Thesevariables are saved with the test and are accessible only within the test in whichthey were defined.

You can create or modify internal, user-defined environment variables for

your test in the Environment tab of the Test Settings dialog box or in theParameter Options dialog box.

User-Defined External —variables that you predefine in the activeexternal environment variables file. You can create as many files as you want andselect an appropriate file for each test, or change files for each test run. Note thatexternal environment variable values are designated as read-only within the test.

Built-in —variables that represent information about the test and the

computer on which the test is run, such as Test path and Operating system. Thesevariables are accessible from all tests, and are designated as read-only.





11. Check Points

A checkpoint is a verification point that compares a current value for a specified propertywith the expected value for that property.

11.1 Types of Checkpoints

In QTP the following types of checkpoints can be inserted to check various objects in aWeb site or application.

• Standard Checkpoint checks the property value of an object in your application or Web page. The standard checkpoint checks a variety of objectssuch as buttons, radio buttons, combo boxes, lists, etc. For example, you cancheck that a radio button is activated after it is selected or you can check the value

of an edit field.

Note: Standard checkpoints are supported for all add-in environments

• Image Checkpoint checks the value of an image in the application or Web page.For example, we can check that a selected image's source file is correct.

Note: Image checkpoint can be created by inserting a standard checkpoint on animage object.

Image checkpoints are supported only for the Web environment

• Bitmap Checkpoint checks an area of a Web page or an application as a bitmap. For example, consider a Web site that can display a map of a city the user specifies. The map has control keys for zooming. We can record the new map thatis displayed after one click on the control key that zooms in the map. Using the bitmap checkpoint, we can check that the map zooms in correctly.

Note: Bitmap checkpoints are supported for all add-in environments

• Table Checkpoint checks information within a table. For example, supposean application or Web site contains a table listing all available flights from NewYork to San Francisco. You can add a table checkpoint to check that the time of the first flight in the table is correct.





• Database Checkpoint checks the contents of a database accessed by your Web site. For example, you can use a database checkpoint to check the contentsof a database containing flight information for your Web site.

Database checkpoints are supported by all environments.

• XML Checkpoint checks the data content of XML documents in XML filesor XML documents in Web pages and frames. XML checkpoints (Web page/frame) are supported for the Web environment; XML checkpoints (file) aresupported by all environments

For more specific information refer to Checkpoints

Adding checkpoints in a test in QTP

There are several ways to add checkpoints.

• To add checkpoints while recording• To add a checkpoint while editing the test

For more information refer to Checkpoints

11.2 Output Values for Verification

The following are the categories of output values that can be created:

• Standard Output Values• Text Output Values• Text Area Output Values• Database Output Values• XML Output Values


Adding output values in a test in QTP


http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Checkpoints.doc









• To add checkpoints while recording• To add a checkpoint while editing the test


Output Values Properties Dialog Box

The Output Value Properties dialog box enables you to choose which property values tooutput and to define the settings for each value that you select.Note: If you insert an output value on a Web page, the Page Output ValueProperties dialog box opens. This dialog except that it contains two additionaloption areas, HTML verification and All objects in page. These options arerelevant only for checkpoints and are disabled when defining output values.

The output values can be output to either of these locations:

• Global\Local Sheet

• Environment variables







• Action\Test Parameter.

This option is given in the output options dialog box

12. Reusable Library

Description





When forming a new product the traditional engineer can take advantage of ready-madesubassemblies. To the test engineer, reusable software components offer the same possibilities; the same components can be incorporated into many whole new systems,thus saving the considerable time and effort it can take to generate new software.

Starting with an introduction to software reuse and a discussion of its feasibility, theauthors go on to consider how the components that may be found could be used. Thereusable library was designed with reuse very much in mind, making it essentially asmall, but invaluable, library.

12.1 Introduction

In QTP we can create VBScript library files containing VBScript functions, subroutines,classes, modules, etc., and then associate the files with our test. We can call any VBScript

function, subroutine, etc., contained within any library file that is associated with our test.Any text file written in standard VBScript syntax can act as a library file.

a) Functions

i. Built-In

ii. User defined

We can specify the default library files for all new tests in the TestSettings dialog box (Test > Settings > Resources tab). We can also edit

the list of associated library files for an existing test in the Test Settingsdialog box. Note that once a test is created, the list of files specified in theTest Settings dialog box is independent of the files set as default in theTest Settings dialog box. Changes to the default library files list in theTest.

12.2 How to establish a Reusable Library

a. Defining Resource Settings for Your Test





We can use the Resources tab of the Test Settings dialog box to associate specific fileswith your test, such as VBScript library files and Data Table files, and to specify theobject repository mode and file to use for our test. We can also set the currentlyassociated library files and object repository settings as the default settings for all newtests.

b. Executing Externally-Defined Functions from Your Test

We can create a VBScript file and call its functions, subroutines, classes, etc., from anaction in your test or from an associated library file by inserting an ExecuteFile

statement in our action or library file.

When we run our test, the ExecuteFile statement executes all global code in the specifiedfile in order to make all definitions in the file available from the global scope of theaction's (or library file's) script.

To execute an externally-defined function:





1. Create a VBScript file using standard VBScriptsyntax.2. Store the file in any folder that you can access fromthe machine running your test.3. Add an ExecuteFile statement to an action in your

test or in an associated library file using the following syntax:

ExecuteFile FileName where FileName is the absolute or relative path of our VBScript file.

1. Use the functions, subroutines, classes, etc., from thespecified VBScript file as necessary in your action or within other functions in an associated library file.

12.3 How to use this Reusable Library.

13. Regular Expressions

13.1 Description





While creating checkpoints we have an option only to search or check for a specific textstring or a specific value of a property. To increase the flexibility and adaptability

of the tests we use regular expressions.Regular Expressions enable Quick Test to identify objects and text strings with varyingvalues.

A regular expression is a string that specifies a complex search phrase. By using specialcharacters we define the conditions of the search.

The most common expressions that can be used to create regular expressions are:

1. Using the Backslash Character

A backslash (\) instructs Quick Test to treat the next character as a literalcharacter, if it is otherwise a special character. The backslash (\) can also instruct

Quick Test to recognize certain ordinary characters as special characters.

For example, consider a Web site called:

mercurytours.mercuryinteractive.com

The period would be mistaken as an indication of a regular expression. Toindicate that the period is not part of a regular expression, you would write it asfollows:

mercurytours\.mercuryinteractive\.com

2. Matching Any Single Character

A period (.) instructs Quick Test to search for any single character (except for \n).For example:

welcome.

matches welcomes, welcomed, or welcome followed by a space or any other single character. A series of periods indicates the same number of unspecifiedcharacters.To match any single character including \n, enter: (.|\n)

3. Matching Any Single Character in a List

Square brackets instruct QuickTest to search for any single character within a list of characters. For example, to search for the date 1967, 1968, or 1969, write: 196[789]

4. Matching Any Single Character Not in a List





When a caret (^) is the first character inside square brackets, it instructs QuickTest tomatch any character in the list except for the ones specified in the string. For example:[^ab]

matches any character except a or b.

5. Matching Any Single Character within a Range

In order to match a single character within a range, you can use square brackets ([ ]) withthe hyphen (-) character. For instance, to match any year in the 1960s, write: 196[0-9]

A hyphen does not signify a range if it is displayed as the first or last character within brackets, or after a caret (^).For example, [-a-z] matches a hyphen or any lowercase letter.

6. Matching Zero or More Specific Characters

An asterisk (*) instructs QuickTest to match zero or more occurrences of the precedingcharacter. For example:ca*r matches car, caaaaaar, and cr.

7. Matching One or More Specific Characters

A plus sign (+) instructs QuickTest to match one or more occurrences of the preceding character. For example:ca+r matches car and caaaaaar, but not cr. 8. Matching Zero or One Specific Character

A question mark (?) instructs Quick Test to match zero or one occurrences of the preceding character. For example:ca?r matches car and cr, but nothing else.

9. Grouping Regular Expressions

Parentheses (()) instruct Quick Test to treat the contained sequence as a unit, justas in mathematics and programming languages.Using groups is especially useful for delimiting the argument(s) to an alternationoperator ( | ) or a repetition operator ( * , + , ? , { } ).

10. Matching One of Several Regular Expressions

A vertical line (|) instructs QuickTest to match one of a choice of expressions. For example: foo|bar causes QuickTest to match either foo or bar. fo(o|b)ar causes Quick Test to match either fooar or fobar.11. Matching the Beginning of a Line





A caret (^) instructs QuickTest to match the expression only at the start of a line,or after a newline character.For example: book

matches book within the lines— book, my book, and book list, while^book Matches book only in the lines— book and book list

12. Matching the End of a Line

A dollar sign ($) instructs Quick Test to match the expression only at the end of aline, or before a new line character. For example: book

Matches book within the lines—my book, and book list, while a string that isfollowed by ($), matches only lines ending in that string. For example: book$ Matches book only in the line— my book.

13.Matching Any AlphaNumeric Character Including the Underscore

\w instructs QuickTest to match any alphanumeric character and the underscore(A-Z, a-z, 0-9, _). For example:\w* causes QuickTest to match zero or more occurrences of the alphanumericcharacters—A-Z, a-z, 0-9, and the underscore (_). It matches Ab, r9Cj, or 12_uYLgeu_435.For example:\w{3} causes Quick Test to match 3 occurrences of the alphanumeric characters A-

Z, a-z, 0-9, and the underscore ( _ ). It matches Ab4, r9_, or z_M. 14. Matching Any Non-AlphaNumeric Character

\W instructs QuickTest to match any character other than alphanumeric charactersand underscores. For example:\W matches &, *, ^, %, $, and # . 15. Combining Regular Expression Operators

You can combine regular expression operators in a single expression to achievethe exact search criteria you need.For example, you can combine the `.' and `*' characters in order to find zero or more occurrences of any character (except \n).For example, start.*

matches start, started, starting, starter, etc.

You can use a combination of brackets and an asterisk to limit the search to acombination of non-numeric characters. For example:[a-zA-Z]*

Creating checkpoints with Regular Expressions





Regular expressions are generally used in the context of creating checkpoints tocheck a range of values.For more information on creating checkpoints with regular expressions refer Regular Expressions

Analyzing a Test with Regular ExpressionsWhen the test run is completed, the Test Results window opens.

1. Examine the checkpoint results.

In the results tree, expand (+) Test RegExpression Summary >

RegExpression Iteration 1 (Row 1) > Action1 Summary > Flight

Reservations > Fax Order No. 12

Select CheckPoint "Fax Order No\. [0-9][0-9]".

The checkpoint passed because the text was displayed in the format specified bythe regular expression.


http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Regular%20Expressions.doc

http://smb//Hrbnt006/quality_data/ra18713/Mahesh&RK/29-12/Reference%20documents/Regular%20Expressions.doc




14. Recovery Scenario

You can instruct Quick Test to recover from unexpected events and errors that occur inyour testing environment during a test run.

Unexpected events, errors, and application crashes during a test run can disrupt your testand distort test results. This is a problem particularly when running tests unattended—thetest is suspended until you perform the action needed to recover.The Recovery Scenario Manager provides a wizard that guides you through the processof defining a recovery scenario —a definition of an unexpected event and the operation(s)necessary to recover the test run. For example, you can instruct Quick Test to detect aPrinter out of paper message and recover the test run by clicking the OK button to closethe message and continue the test.

A recovery scenario consists of the following:

Trigger Event —The event that interrupts your test run. For example, a window that

may pop up on screen, or a Quick Test test run error. Recovery Operation(s) —The operation(s) that need to be performed in order to

continue running the test. For example, clicking an OK button in a pop-up window,or restarting Microsoft Windows.

Post-Recovery Test Run Option —The instructions on how Quick Test should proceed once the recovery operations have been performed, and from which point inthe test Quick Test should continue, if at all. For example, you may want to restart atest from the beginning, or skip a test step entirely and continue with the next step inthe test.

Recovery scenarios are saved in recovery scenario files. A recovery scenario file is alogical collection of recovery scenarios, grouped according to your own specificrequirements.

To instruct Quick Test to perform a recovery scenario during a test run, you must firstassociate it with that test. A test can have any number of recovery scenarios associatedwith it. You can prioritize the scenarios associated with your test to ensure that trigger events are recognized and handled in the required order.





When you run a test for which you have defined recovery scenarios and an error occurs,Quick Test looks for the defined trigger event(s) that caused the error. If a trigger eventhas occurred, Quick Test performs the corresponding recovery and post-recoveryoperations.

You can also control and activate your recovery scenarios during the test run by insertingRecovery statements into your test.

Note: If you choose On error in the Activate recovery scenarios box in the Recoverytab of the Test Settings dialog box, the recovery mechanism does not handle triggers thatoccur in the last step of a test. If you chose this option and need to recover from anunexpected event or error that may occur in the last step, you of a test can do this byadding an extra step to the end of your test.

14.1 Exceptional Handling using Recovery Scenarios

The Recovery Scenario Manager dialog box enables you to create recovery scenarios andsave them in recovery files. You create recovery scenarios using the Recovery ScenarioWizard, which leads you through the process of defining each of the stages of therecovery scenario. You then save the recovery scenarios in a recovery file, and associatethem with a specific test or tests.

Creating a Recovery File

You save your recovery scenarios in a recovery file. A recovery file is a convenient wayto organize and store multiple recovery scenarios together. You can create a new

recovery file or edit an existing one.

For more information on creating a Recovery File refer to Creating a Recovery File

Saving the Recovery Scenario in a Recovery File

After you create or modify a recovery scenario in a recovery file using the RecoveryScenario Wizard, you need to save the recovery file.

To save a new or modified recovery file:

1. Click the Save button . If you added or modified scenarios in an existing

recovery file, the recovery file and its scenarios are saved. If you are using a newrecovery file, the Save Attachment dialog box opens.

Tip: You can also click the arrow to the right of the Save button and select Save

As to save the recovery file under a different name.

2. Choose the folder in which you want to save the file.


http://smb//HRBNT006/Quality_Data/ra18713/Mahesh&RK/29-12/Reference%20documents/To%20create%20a%20recovery%20file.doc






3. Type a name for the file in the File name box. The recovery file is saved in thespecified location with the file extension .qrs.

Tip: If you have not yet saved the recovery file, and you click the Close button in theRecovery Scenario Manager dialog box, Quick Test prompts you to save the recovery

file. Click Yes, and proceed with step 2 above. If you added or modified scenarios in anexisting recovery file, and you click Yes to the message prompt, the recovery file and itsscenarios are saved.

Managing Recovery Scenarios

Once you have created recovery scenarios, you can use the Recovery Scenario Manager to manage them.

The Recovery Scenario Manager contains the following recovery scenario icons:

Icon Description

Indicates that the recovery scenario is triggered when a window pops upin an open application during the test run.

Indicates that the recovery scenario is triggered when the property values





of an object in an application match specified values.

Indicates that the recovery scenario is triggered when a step in the testdoes not run successfully.

Indicates that the recovery scenario is triggered when an open applicationfails during the test run.

The Recovery Scenario Manager enables you to manage existing scenarios by:

Viewing Recovery Scenario Properties

Modifying Recovery Scenarios

Deleting Recovery Scenarios

Copying Recovery Scenarios between Recovery Scenario Files


You can view properties for any defined recovery scenario.

To view recovery scenario properties:1 In the Scenarios box, select the recovery scenario whose properties you want to view.

2 Click the Properties button . Alternatively, you can double-click a scenario in theScenarios box. The Recovery Scenario Properties dialog box opens.

The Recovery Scenario Properties dialog box displays the following read-onlyinformation about the selected scenario:





3 Click the Open button and select the recovery scenario file to which you want

to copy the scenario, or click the New button to create a new recovery scenariofile in which to copy the scenario.

4 Click the Paste button . The scenario is copied to the new recovery scenario file.

Note: If a scenario with the same name already exists in the recovery scenario file, youcan choose whether you want to replace it with the new scenario you have just copied.

Setting the Recovery Scenarios List for Your Tests

After you have created recovery scenarios, you associate them with selected tests so thatQuick Test will perform the appropriate scenario(s) during the test runs if a trigger eventoccurs. You can prioritize the scenarios and set the order in which Quick Test applies the

scenarios during the test run. You can also choose to disable specific scenarios, or all

scenarios, that are associated with a test. You can also define which recovery scenarioswill be used as the default scenarios for all new tests.

Adding Recovery Scenarios to Your Test

After you have created recovery scenarios, you can associate one or more scenarios witha test in order to instruct Quick Test to perform the recovery scenario(s) during the testrun if a trigger event occurs. The Recovery tab of the Test Settings dialog box lists all therecovery scenarios associated with the current test.

Tip: When a trigger event occurs, Quick Test checks for applicable recovery scenarios in

the order in which they are displayed in the Recovery tab. You can change this order asdescribed in “Setting Recovery Scenario Priorities”

For more information on “adding a recovery scenario to a test” refer to Adding RecoveryScenario to a Test


You can view properties for any recovery scenario associated with your test.

To view recovery scenario properties:

1 In the Scenarios box, select the recovery scenario whose properties you want to view.2 Click the Properties button . Alternatively, you can double-click a scenario in theScenarios box. The Recovery Scenario Properties dialog box opens, displaying read-onlyinformation regarding the settings for the selected scenario.

Setting Recovery Scenario Priorities

You can specify the order in which Quick Test performs associated scenarios during atest run. When a trigger event occurs, Quick Test checks for applicable recovery


http://smb//HRBNT006/Quality_Data/ra18713/Mahesh&RK/29-12/Reference%20documents/Adding%20Recovery%20Scenario%20to%20a%20Test.doc







scenarios in the order in which they are displayed in the Recovery tab of the Test Settingsdialog box.

To set recovery scenario priorities:

1 In the Scenarios box, select the scenario whose priority you want to change.

2 Click the Up or Down button . The selected scenario’s priority changesaccording to your selection.3 Repeat steps 1-2 for each scenario whose priority you want to change.

Removing Recovery Scenarios from Your Test

You can remove the association between a specific scenario and a test using the Recoverytab of the Test Settings dialog box. After you remove a scenario from a test, the scenarioitself still exists, but Quick Test will no longer perform the scenario during a test run.

To remove a recovery scenario from your test:

1 In the Scenarios box, select the scenario you want to remove.

2 Click the Remove button . The selected scenario is no longer associated with thetest.

Enabling and Disabling Recovery Scenarios

You can enable or disable specific scenarios and determine when Quick Test activates therecovery scenario mechanism in the Recovery tab of the Test Settings dialog box. Whenyou disable a specific scenario, it remains associated with the test, but is not performed by Quick Test during the test run. You can enable the scenario at a later time.

To enable/disable specific recovery scenarios:

Select the check box to the left of one or more individual scenarios to enablethem.

Clear the check box to the left of one or more individual scenarios to disablethem.

To define when the recovery mechanism is activated:

Select one of the following options in the Activate recovery scenarios box:

Always —The recovery mechanism is activated after every step.

On error —The recovery mechanism is activated only after steps that return anerror return value.

Note that the step that returns an error is often not the same as the step that causesthe exception event to occur.

For example, a step that selects a check box may cause a pop-up dialog box toopen. Although the pop-up dialog box is defined as a trigger event, Quick Testmoves to the next step because it successfully performed the check box selection





step. The next several steps could potentially perform checkpoints, functions or other conditional or looping statements that do not require performing operationson your application. It may only be ten statements later that a step instructs Quick Test to perform an operation on the application that it cannot perform due to the pop-up dialog box. In this case, it is this tenth step that returns an error and

triggers the recovery mechanism to close the dialog box. After the recoveryoperation is completed, the current step is this tenth step, and not the step thatcaused the trigger event.

Never —The recovery mechanism is disabled.

Setting Default Recovery Scenario Settings for All New Tests

You can click the Set as Default button in the Recovery tab of the Test Settings dialog box to set the current list of recovery scenarios to be the default scenarios for all newtests. Any future changes you make to the current recovery scenario list only affect thecurrent test, and do not change the default list that you defined.

14.2 Sample for Recovery Scenario:

For adding a recovery Scenario:

Let us take an example of a popup window exception,

In Flight Application, when we give wrong password in the login dialog box then we getthe following popup window:

In order to handle this, take a new recovery scenario, in the “Select Trigger Event” screenof Recovery Scenario Wizard, select “pop-up window” Radio button as shown below,





In the next screen, we can specify Pop-up window condition, by spying the popupwindow, then details of the pop-up window appears as follows:





then in the next step, In the recovery operation screen select “keyboard or mouseoperation” radio button, then in the next step select “Press ENTER Key” radio button,

In the next screen select “Add another recovery operation” check box as given below:





then in the next step, In the recovery operation screen select “function call” radio button

Specify the path and name of the library file which has the appropriate function for entering the password and clicking “ok” button of “Login” dialog box.

In the “Post-Recovery Test Run Options” screen select “Repeat current step andContinue” radio button, give a name to the recovery scenario, thus the recovery will becreated.

Adding a Recovery scenario into the Test:

We can add the Recovery Scenario to our test in two ways.

1. We can add the Recovery Scenario to our test while we create a new RecoveryScenario by checking the “add Scenario to current test” check box in “Completing

the Recovery Scenario Wizard” screen of Recovery Scenario Wizard.





2. The other way to add Recovery Scenario to our test is by adding the requiredscenario file in the recovery tab of Test Settings Dialog box.





15. Optional Steps

15.1 Description:

When running a test, if a step does not succeed in opening a dialog box,QuickTest does not necessarily abort the test run. It bypasses any stepdesignated "optional" and continues running the test. By default,QuickTest automatically marks as optional steps that open certain dialog boxes. You can manually designate additional steps as optional.

If a dialog box may or may not appear at a particular instanse then thatdialog box actions performed can be set as optional, so that it proceeds tothe next step, if the screen or dialog box doesn’t appear or will continuethe normal flow.

Default Optional Steps:

There are some default objects, which QTP recognizes as optional, for those objects QTP by default sets as optional, those objects are as follows:

Dialog boxes with title bar as

Auto Complete

File Download

Internet Explorer

Netscape

Enter Network Password

Error

Security Alert

Security Information

Security Warning

Username and Password Required





Setting Optional Steps:

There are two ways of setting Optional steps:

1. We can directly Right-click a step in the Keyword View and choose

Optional Step. The Optional Step icon will be added next to the selected step.2. You can also add an optional step from the Expert View by addingOptionalStep to the beginning of the VBScript statement.

Example:

OptionalStep.Browser("browser_name").Page("page_n

ame").Link("link_name")





16. Reporting

The process of reporting is to customize the test results, and add the appropriatecomments and reports to the test results to increase the readability of it. Reporting can bedone in various formats.

Test Results Window

After a test run, we view the results in the Test Results window. By default, theTest Results window opens when a test run is completed. Note: You can open the Test Results window as a standalone application from theStart menu. To open the Test Results window, choose Start > Programs >

QuickTest Professional > Test Results Viewer.

The Test Results window contains the following key elements:

• Menu bar —Displays menus of available commands.• Test results toolbar —Contains buttons for viewing test results (chooseView > Test Results Toolbar to display the toolbar).





• Test results tree —Contains a graphic representation of the test results inthe test results tree.• Test results details —Contains details of the selected step.• Active Screen —Shows the active screen of the particular window or stepin the results.

16.1 Different Options for Reporting

There are 3 options for screen capture the screens to the results:

• Always – adds screen shots to the results for every step.

• On Errors – adds screen shots only on occurrence of error

• On Errors and Warnings – adds on both errors and warnings.

• Never

Note: If “Always” option is selected then the result file will occupy lots of memory, thusselection of “Always” option should be done only if the client wants to view all thescreen shots for reference during review.





16.2 Functions used for Reporting

1. ReportEvent Method

Reports an event to the Test Reports.

Syntax: Reporter.ReportEvent EventStatus, ReportStepName, Details [, in]

Argument Type Description

EventStatus Number or pre-definedconstant

Status of the report step: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 befailed 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 thereport, but does not cause the test to stop running,and does not affect the pass/fail status of the test.4 or micInfo: Applies an information status (andicon) to the step. This status does not affect the pass/fail status of the test.

ReportStepName String Name of the intended step in the report (objectname).

Details String

Description of the report event. The string will be

displayed in the step details frame in the test report .

in N/A Not in use.

Example

The following example uses the Report Event method to report that the checkpoint onthis window has passed.

Reporter.ReportEvent 0,"Fax Order No. 12","The check point for this window has

passed "

2. Filter Property

Retrieves or sets the current mode for displaying events in the Test Results. You can usethis method 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 beincluded in the report.

Syntax:

To retrieve the mode setting:CurrentMode = Reporter.Filter To set the mode:Reporter.Filter = NewMode The mode can be one of the following values:

Mode Description

0 or rfEnableAll

Default. All reported events are displayed in theTest Results.

1 or rfEnableErrorsAndWarnings

Only event with a warning or fail status aredisplayed in the Test Results.

2 or rfEnableErrorsOnly

Only events with a fail status are displayed in theTest Results.

3 or rfDisableAll

No events are displayed in the Test Results.

Example

The following example uses the Filter method to report the following events in the TestResults: 1, 2, 5, and 6.Reporter.ReportEvent micGeneral, "1", ""

Reporter.ReportEvent micGeneral, "2", ""Reporter.Filter = rfDisableAllReporter.ReportEvent micGeneral, "3", ""Reporter.ReportEvent micGeneral, "4", ""Reporter.Filter = rfEnableAllReporter.ReportEvent micGeneral, "5", ""Reporter.ReportEvent micGeneral, "6", "

3. ReportPath Property

Retrieves the folder path in which the current test's Test Results are stored.





Syntax

Path = Reporter.ReportPath

Argument Type Description

Path String The folder path in which the current test's Test Results are stored.

Example

The following example uses the ReportPath method to retrieve the folder in which thetest's Test Results are stored and displays the folder in a message box.dim PathPath = Reporter.ReportPath MsgBox (Path)

16.3 Reporting Formats

The results of the QTP runs are stored in the Results folder, which must be specified before starting the test run. The results are stored in 2 types of formats:

• QTP format – this is the format in which the results are displayed in the testwindow, opens with QTP

• XML format – the results are also stored in XML file, in which all the objects arestored in a hierarchy in .xml format. This is useful in transfer of the resultsinformation across platforms, since it is based on simple Unicode format.





Fig: results in XML format

qtp framework(2)

Documents