Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
doc
QTP
Frame Work
Confidential
Page 1 of 100
121342730.doc
Table of Contents
1. Automation Architecture.......................................................3 1.1 Design........................................................................................................................3 1.2 Approach for Test Automation..................................................................................4 2. Introduction to QTP........................................................12 2.1 QTP Environment Compatibility.............................................................................12 2.2 Versions of QTP......................................................................................................13 3. Add-Ins...............................................................................21 3.1 Types of Add-Ins.....................................................................................................21 3.2 Conditions for Add-ins............................................................................................22 4. Conventions.........................................................................23 4.1 Test Case Naming Conventions:..............................................................................23 4.2 Script and Action Naming Conventions:................................................................23 4.3 Variables and Constants:..........................................................................................25 4.4 DataSheet Naming and Parameter Naming Conventions:.......................................26 4.5 Function Naming Conventions................................................................................27 5. Settings...............................................................................28 5.1 QTP Test Settings....................................................................................................28 5.2 Record and Run Settings..........................................................................................29 5.3 Active Screen Capture Level...................................................................................29 5.4 Object Repository....................................................................................................30 5.5 Expert View.............................................................................................................32 5.6 Setting related to the Application Used:..................................................................35 6. Objects...............................................................................38 6.1 Objects....................................................................................................................38 7. Data Table..........................................................................40 7.1 Datatable Object and related Functions:.................................................................40 7.2 Organizing Data Sheets for Global & Local variables............................................41 7.3 Parameterizing using Data driven Wizard.............................................................42 7.4 Importing and Exporting Datasheets:...................................................................46 8. Actions................................................................................49 8.1 Actions Settings.......................................................................................................49 8.2 Iterations using rows................................................................................................50 8.3 Action Template.......................................................................................................51 8.4 Script Startup...........................................................................................................51 8.5 Splitting Actions, Re-usable Actions, Internal/External Actions............................52 9. Object Repository................................................................53 9.1 Per Action/Shared Object Repository:.....................................................................53 9.2 Merging of two object repositories:.........................................................................55 9.3 Limitations:..............................................................................................................57 10. Variables...........................................................................58 10.1 Action Parameters................................................................................................59
Confidential
Page 2 of 100
121342730.doc
10.2 Test Parameters......................................................................................................61 10.3 Environment Variables..........................................................................................63 10.4 Variable passing from one Action to another.......................................................64 10.5 Scope of Variables.................................................................................................66 11. Check Points......................................................................68 11.1 Types of Checkpoints............................................................................................68 11.2 Output Values for Verification..............................................................................70 12. Reusable Library................................................................72 12.1 Introduction...........................................................................................................73 12.2 How to establish a Reusable Library.....................................................................73 12.3 How to use this Reusable Library.........................................................................75 13. Regular Expressions..........................................................75 13.1 Description.............................................................................................................75 14. Recovery Scenario............................................................80 14.1 Exceptional Handling using Recovery Scenarios..................................................81 14.2 Sample for Recovery Scenario:...........................................................................87 15. Optional Steps...................................................................93 15.1 Description:........................................................................................................93 16. Reporting...........................................................................95 16.1 Different Options for Reporting.............................................................................96 16.2 Functions used for Reporting..............................................................................97 16.3 Reporting Formats.................................................................................................99
1. Automation Architecture
1.1 Design
Confidential
Page 3 of 100
121342730.doc
Description
Confidential
Page 4 of 100
121342730.doc
Approach for Test Automation is used for building a strategy for automation starting from the Requirement phase till the deployment phase. Approach for automation begins with finding out the conditions and business rules given by the client and grouping similar 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 all the transactions including the customized transactions where explained to the SAP Consultants of satyam, Understanding of requirements was done at the client side, Depending on the flow of transactions, all the transactions where grouped together as different 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 QTP and SAP. All the Identified Scenarios which consists of different transactions where explained to Testing Team. Then common functionalities where identified, and grouped together as different Test cases. After defining different Test cases, design for automation of scripts was done, where Reusability was one of the main aspects, where all the transactions, which are common in the 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 Page 5 of 100
Confidential
121342730.doc
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 named as corresponding Test case name, This Action intern will call all the other actions (Each Transaction 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. Sheets corresponding 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 also collected 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 again and again, which ever transaction was common among scripts, were recorded in one script and is reused in all the scripts where the transaction is required. Error handling in the unilever automation is done by using Recovery Scenario where each Recovery scenario calls a function which handles the recovery by exiting all the other 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.
Called Actions
Confidential
Page 6 of 100
Ex: S014_001 (Action Name) Ex: ME21N (Action Name Which is same as the Transaction name in SAP)
Confidential
Page 7 of 100
121342730.doc
Tool & Application Settings, Restoring, Object Repository, Recovery, House Keeping etc
General library containing String handling, Date handling, File Handling, Data Table handling
Confidential
Page 8 of 100
Its a description of Automating a test case belongs to SAP by explaining a scenario S014-081 Scenario Objective: Moving a Material from Raw Material Storage Location to a Production Storage Location, Creating a Transfer Requirement and a Transfer Order.
Actions for the Transactions Login, LB01, MM03, LT04, LT012 and Logoff.
Coding Standards & Naming Conventions like The file name as per convention - Scenario name, The Action named as per transaction ID
Building the Re-Usable Library like The common functionality being reused
Error handling like On Error Resume Next, Reporting like reporter.ReportEvent etc
Business Transactions Scripts are LB01 and LT04 Note: The phase in blue color indicates where more efforts are required in analyzing and recording to generate a script. QTP Framework in SAP Automation
Confidential
Page 9 of 100
121342730.doc
Re-Usable Library: Generic Library calls for handling data, date, string etc Error handling Library Recovery Scenario Actions
Guidelines followed for identification of Test Cases for Automation Tests that need to run once and those that need frequent human intervention are usually not worth the investment to automate and have not been considered for automation. As Automated testing can be used to verify the performance of application paths that are used with a high degree of frequency when the software is running in full production e.g. creating customer records, Invoicing and other high volume activities where software failure would occur frequently have been considered.
Mission critical processes like core activities like sales order processing are prime candidates for automated testing and have been considered for automation.
Repetitive Testing
Confidential
Page 10 of 100
121342730.doc
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 scripts complexity is reduced and high maintainability of the script is ensured.
Confidential
Page 11 of 100
121342730.doc
2.
Introduction to QTP
Confidential
Page 12 of 100
121342730.doc
Server Technologies: - Oracle - Microsoft - IBM - BEA - ODBC - COM / COM+ Multimedia: - Flash - RealAudio / RealVideo - Windows Media Player Operating Environment Operating Systems Supported: Databases Supported: Networks Supported: Programming Languages Supported: Windows XP/2000/NT Windows 95/98/ME
(Not Applicable) TCP/IP JavaScript Java HTML Visual Basic (VB) XML Middleware Supported: Microsoft .NET
Confidential
Page 13 of 100
121342730.doc
128 MB of RAM (256 MB recommended) 150 MB of free disk space for a compact installation or 200 MB for a typical or complete installation Microsoft Internet Explorer 5.06.0.
Supported Environments QuickTest Professional supports creating, recording, and running tests in the environments described below. Standard Windows Applications Win32 API MFC Visual Basic Applications Visual Basic 6.0 Browsers
Microsoft Internet Explorer 5.016.0 (required) Netscape Navigator 4.064.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 and verification on the following ActiveX Grid controls:
Confidential
Page 14 of 100
121342730.doc
Name FarPoint Spreadsheet 2.5 FarPoint Spreadsheet 3.0 FarPoint Spreadsheet 3.5 FarPoint Spreadsheet 6.0
FarPoint Spreadsheet 3.0 (OLEDB) FPSpreadADO.fpSpread.2 FarPoint Spreadsheet 3.5 (OLEDB) FPSpreadADO.fpSpread.3 FarPoint Spreadsheet 6 (OLEDB) Microsoft Grid 1.0 Microsoft DataBound Grid 5.0 Microsoft Flex Grid 6.0 Sheridan Data Grid 2.0 Sheridan Data Grid 3.1 Apex True DataBound Grid 5.0 Apex True DataBound Grid 6.0 Apex True OLE DB Grid 6.0 FPSpreadADO.fpSpread.4 MSGrid.Grid MSDBGrid.DBGrid MSFlexGridLib.MSFlexGrid.1 SSDataWidgets.SSDBGridCtrlApt.1 SSDataWidgets.SSDBGridCtrlApt.3 TrueDBGrid50.TDBGrid TrueDBGrid60.TDBGrid TrueOleDBGrid60.TDBGrid
ActiveX Calendar Controls In addition to basic support of ActiveX properties and methods, QuickTest Professional supports context-sensitive recording and verification 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
Confidential
Page 15 of 100
121342730.doc
RealPlayer controls supported for Internet Explorer browsers (the controls within applications containing browser controls are not supported) Macromedia Flash 4 or 5 objects that are ActiveX controls in Internet Explorer. You can also test Macromedia Flash 6 clips containing only Flash 4 or 5 commands.
Additional Environments QuickTest Professional add-ins support other environments such as Java, .NET Windows and Web Forms, SAP solutions, Oracle, Siebel, PeopleSoft, Web Services, and terminal emulator applications. For more information about QuickTest Professional add-ins, contact your sales representative 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 to QuickTest Professional 6.5 and are no longer part of the core product.
Confidential
Page 16 of 100
121342730.doc
QTP 8.0:
System Requirements
To successfully install and run QTP8.0, you need the following minimum system requirements: Computer/Processor: Operating System: Memory: IBM-PC or compatible with a Pentium II 266 MHz microprocessor (366 MHz recommended). Windows 2000-Service Pack 3 or Service Pack 4, Windows XP-Service Pack 1, or Windows 2003 Server. 128 MB of RAM (256 MB recommended). 250 MB of free disk space for application files and folders, and an additional 120 MB of free disk space on the system disk (the disk on which the operating system is installed). After Quick Test Professional is installed, it is recommended to have at least 150 MB free disk space on the system disk for the operating system and Quick Test Professional to run correctly. Microsoft Internet Explorer 5.5 Service Pack 2-6.0.
Browser:
Supported Add-ins
The following external QuickTest 6.5.x add-ins are supported for use with QuickTest Professional 8.0:
Java Add-in 6.5 Oracle Add-in 6.5 PeopleSoft Add-in 6.5 Terminal Emulator Add-in 6.5 .NET Add-in 6.5.1 SAP solutions Add-in 6.5.1
Confidential
Page 17 of 100
121342730.doc
Note: Siebel Add-in 6.5, the .NET Add-in 6.5, the Add-in for SAP solutions 6.5, or any 6.0 add-ins,cannot be used with QuickTest Professional 8.0.1
(required) Netscape 6.1, Netscape 6.22, Netscape 6.23, Netscape 7.02, and Netscape 7.1 (optional) AOL 8.0 and 9.0 (optional)
ActiveX Grid Controls In addition to basic support of ActiveX properties and methods, QuickTest Professional supports context-sensitive recording and verification on the following ActiveX Grid controls:
Confidential
Page 18 of 100
121342730.doc Name FarPoint Spreadsheet 2.5 FarPoint Spreadsheet 3.0 FarPoint Spreadsheet 3.5 FarPoint Spreadsheet 6.0 ProgId
FarPoint Spreadsheet 3.0 (OLEDB) FPSpreadADO.fpSpread.2 FarPoint Spreadsheet 3.5 (OLEDB) FPSpreadADO.fpSpread.3 FarPoint Spreadsheet 6 (OLEDB) Microsoft Grid 1.0 Microsoft DataBound Grid 5.0 Microsoft Flex Grid 6.0 Sheridan Data Grid 2.0 Sheridan Data Grid 3.1 Apex True DataBound Grid 5.0 Apex True DataBound Grid 6.0 Apex True OLE DB Grid 6.0 FPSpreadADO.fpSpread.4 MSGrid.Grid MSDBGrid.DBGrid MSFlexGridLib.MSFlexGrid.1 SSDataWidgets.SSDBGridCtrlApt.1 SSDataWidgets.SSDBGridCtrlApt.3 TrueDBGrid50.TDBGrid TrueDBGrid60.TDBGrid TrueOleDBGrid60.TDBGrid
Microsoft Date and Time Picker Control 6.0 (SP4) MSComCtl2.DTPicker.2 Microsoft MonthView Control 6.0 (SP4) MSComCtl2.MonthView.2
Confidential
Page 19 of 100
121342730.doc
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 can work 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 Microsoft Query 2000, 2002, 2003, and XP.
Additional Environments QuickTest Professional add-ins support other environments such as Java, .NET Windows and Web Forms, SAP Solutions, Oracle, Siebel, PeopleSoft, Web Services, and terminal emulator applications. For more information on QuickTest Professional add-ins, contact your sales representative or Mercury Interactive Customer Support.
Confidential
Page 20 of 100
121342730.doc
3. Add-Ins
3.1 Types of Add-Ins
QTP version
8.2 Java add-in 6.5 Oracle add-in 6.5
Add-ins
Siebel add-in 8.0 Terminal Emulator add-in 8.0 . Net add-in 8.2 Default Add-Ins: Active X Controls, Web &Visual Basic . Net add-in 6.5.1 Sap add-in 6.5.1 Java add-in 6.5 PeopleSoft add-in 6.5 Oracle add-in 6.5 Terminal Emulator add-in 6.5 Default Add-Ins: Active X Controls, Web &Visual Basic
8.0
6.5
. Net Web Java XML 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 be used with Quick Test 8.0. The add-ins for Quick Test Professional 6.0 cannot be used with Quick Test Professional 6.5. If you are using Quick Test Professional 6.5, you will need to get the 6.5 version of your add-in.
Confidential
Page 21 of 100
121342730.doc
When testing Java applets in a Web browser, you must load the Web add-in as well as the Java Add-in, and use the Web tab of the Record and Run Settings Dialog box to specify your record and run preferences. To test Java applets or applications running on Netscape 4.xs built-in JVM (not Java Plug-ins), confirm that the Netscape 4.x browser is already installed before installing the Quick Test Professional Java Add-in. When testing Java applets in a Web browser web Add-in as well as java add-in must be loaded .To create a checkpoint, parameterize a step, or to add a method from 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, even though 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 controls like edit fields, buttons etc. without the .Net add-in. However, if a Web application contains complex controls like ActiveX or other controls developed in .Net like ASP.Net server 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.
Confidential
Page 22 of 100
121342730.doc
4. Conventions
The Conventions for Naming for test cases, Scripts and Actions vary from Project to Project depending upon the Client.
Confidential
Page 23 of 100
121342730.doc
Therefore for a Test Script corresponding to a Test Case named TC_001 would be QTS_001.The hierarchy should be maintained in case the use cases or test cases are nested. 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 representing a test Condition. Actions can be named in 2 ways: 1. Functionality of the Action 2. 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 action represents the Functionality. For E.g.: An Action written or recorded for logging the user should be named as Login 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 made reusable. Reusable Actions can be used between various scripts. When an Action is to be made reusable the action should be named as REUSE_(Action name). Example: REUSE_Login.
Confidential
Page 24 of 100
121342730.doc
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
Date/time dStartTime = Now All numeric data types iTax = iPrice * 0.076 (Byte, Integer, Currency, Long, Single, Double) Objects Set oFile = Nothing Strings sTitle = "Welcome!" User interface elements uPara.style.display = "block"
Constants Prefix: Usually there are only a handful of constants in any scripts. Indicating the data type therefore is less important for constants. Prefix letter c for all constants can be used. e.g. Const cTitle = "Welcome!" UDocument.title = cTitle
Confidential
Page 25 of 100
121342730.doc
2) Action Parameters a) Action Input Parameters: These are local to Action of a Test. These can be named as ACTIN_(variable name). ACTIN denoting that its an Action Input Parameter. Example: ACTIN_iResult b) Action Output Parameters: These could be named as ACTOUT_(var name).
Confidential
Page 26 of 100
3) Environment Variables: Environment variables are either built-in or User defined. Built-in variables cannot be declared 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)
Confidential
Page 27 of 100
121342730.doc
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 a crucial part in the behavior of the test. These can be found at the path Test>Settings. A dialog box pops up, in which various tabs 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
Confidential
Page 28 of 100
121342730.doc
For further details about these settings refer to Record and Run Settings.
Confidential
Page 29 of 100
121342730.doc
For details about each capture level, refer to ActiveScreen Capture Level.
Confidential
Page 30 of 100
121342730.doc
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 test folder.In the Shared mode, the user may choose a location to save the shared object repository files for all the tests. All the Objects recorded during a test,and their properties can be seen and manipulated in the Tools>Object Repository.There are provisions in this Object Repository Dialog box to add new objects,spy objects, find and replace property values etc.
Confidential
Page 31 of 100
121342730.doc
The First Section of Object Repository Dialog Box contains provisions to a. 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, and Remove the properties of an object in the Repository also set any default values for the properties.
Page 32 of 100
121342730.doc
In the Expert View, QTP displays each operation performed on the application in the form of a script. The script is comprised of VBScript statements and the view is a script editor with many script editing capabilities. For each object and method in an Expert View statement, a corresponding row exists in the Keyword View and a corresponding Active Screen in the Active Screen view, which enables easy traceability.
Confidential
Page 33 of 100
121342730.doc
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 enhance the 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 VBScript statements as required for tasks like Check Points,Datatables etc.,.These additional steps can be added either manually or using Insert>Step >Step Generator .whenever a step is added to a script, then any Syntax errors of the step can be Identified in its Keyword view.
Confidential
Page 34 of 100
121342730.doc
The Step Generator enables you to add steps quickly and easily, by selecting from a range of context-sensitive options and entering the required values.The generated step gets added at the position of cursor in the expert view. The Step Generator enables you to add steps quickly and easily, by selecting from a range of 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
Page 35 of 100
121342730.doc
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 :
Confidential
Page 36 of 100
121342730.doc
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.
Confidential
Page 37 of 100
121342730.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 as Exist, 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 object with 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 object that 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 activate the 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.
Confidential
Page 38 of 100
121342730.doc
Sample for Object hierarchy: Method for WinEdit Object Dialog Object
In the above sample of code, there are two main Objects, one is Dialog and the other is Window object. This objects contain child objects, For Dialog object 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 the WinEdit object. Dialog Parent Object named as Login
Child Object named as Agent WinEdit Name: Set is the method associated with WinEdit object
Confidential
Page 39 of 100
121342730.doc
7. Data Table
In QTP scripting there are many objects that are used, One of the Objects used in QTP scripting is DataTable Object.
Confidential
Page 40 of 100
121342730.doc
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 action will 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 use GetCurrentRow function. Syntax: Datatable.GetSheet(Sheetname).GetCurrentRow
Confidential
Page 41 of 100
121342730.doc
Organization of Global and Local sheets with the actions used in the script are shown below:
Global Sheet
Page 42 of 100
121342730.doc
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 in the script)
For example consider script for entering Login name which is as follows Dialog("Login").WinEdit("Agent Name:").Set "name" The Set property of WinEdit Object appears in the list of Datadriver with name as Value 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:
Confidential
Page 43 of 100
121342730.doc
Step-by-step Parameterization: Enables you to view the current values of each step containing 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, the Next 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.
Confidential
Page 44 of 100
121342730.doc
Parameterize all: Enables you to parameterize all occurrences of the selected value throughout the action. When you select this option the Parameter details area is enabled. The Finish button is enabled when you select this option.
Confidential
Page 45 of 100
121342730.doc
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 instances of the value selected for parameterization will be parameterized.
Confidential
Page 46 of 100
121342730.doc
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 the sheets 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 data efficiently, 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 is saved. If the current file exists, but the file does not contain a sheet with the specified sheet 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 exported sheet overwrites the existing sheet.
Same as Importing, There are two functions for Exporting, Exporting the whole excel file and 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.
Confidential
Page 47 of 100
121342730.doc Syntax: Export filenamewithpath Function for Exporting the sheets from the excel file: Exports the specified sheet into the script. Syntax: Exportsheet filenamewithpath,sourcesheetname, destinationsheetname
Confidential
Page 48 of 100
121342730.doc
8. Actions
8.1 Actions Settings
You can use the Run tab of the Action Call Properties dialog box to instruct QuickTest to run 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.
Confidential
Page 49 of 100
121342730.doc
The Run tab of the Action Call Properties dialog box applies to individual action calls and refers to the rows in the action's data sheet.
Confidential
Page 50 of 100
121342730.doc
Example: The Resources tab of the Test Settings dialog box can be used to associate specific files with the test, such as Data Table files. The option area Other location instructs Quick Test to use data stored in the specified Data Table location. The Data Table can be any Microsoft Excel (.xls) file.
Confidential
Page 51 of 100
121342730.doc
For a sample external file refer to Sample External File Check for the Data table iterations under the test settings for which the test has to be run. For further details refer to QTP test settings doc.
A test is made up of calls to actions. When you create a new test, it contains a call to a single action or create tests that call multiple actions by inserting calls to them, to make the design more modular and efficient tests.
Confidential
Page 52 of 100
reusable actionan action that can be called multiple times by the test with which is stored in the local test as well as by other tests. external actiona reusable action stored with another test. External actions are read-only in the calling test. They can be modified only in the test with which they are stored. Non-resuable-actions an action that can be called only in the test with which it is stored, and can be called only once.
9. Object Repository
9.1 Per Action/Shared Object Repository:
Confidential
Page 53 of 100
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 Object Repository per action mode. Below are some of the factors based on which Per Action option is selected
Confidential
Page 54 of 100
121342730.doc
Whenever there are no common objects across transactions Ease of building object repository. Loading of per Action object repository takes less time as the size is less
Select "Shared" to set the Object Repository mode for your test to the Shared Object Repository mode. Below are some of the factors based on which Shared Action option is selected Whenever there are common objects across transactions Maintenance of object repository is very easy Whenever size of object repository is 1MB
5. If you selected Shared in step 4, specify the Shared Object Repository file you want to use as the test's Object Repository file. To specify a file, enter the Object Repository file name or click the "Browse" button and select a resource file (*.tsr) from the Open dialog box. To create a new Shared Object Repository file, enter a new file name in the Shared box. Note: These steps need to be done in a new script. Once you have modified the script, you will not be able to change the option. To set all new scripts to use a Shared Object Repository: For Quick Test Professional 6.5 and above 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. Select the Shared option for the "Object-repository type". 5. Specify the Shared Object Repository file you want to use as the test's Object Repository file. To specify a file, enter the Object Repository file name or click the ellipse button <...> and select a resource file (*.tsr) from the Open dialog box. To create a new Shared Object Repository file, enter a new file name and path in the Shared box. 6. Click the "Set as Default" button. 7. Click <Apply> and <OK>.
Confidential
Page 55 of 100
121342730.doc
The Object Repository File Merge Utility allows users to merge object repository files into 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 repository files 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 merge two object repositories from tests that were recorded at different time points, between which some test objects properties have changed (e.g. whether a button is enabled) then the same object exists in the two repositories with different properties. We call this a description 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 one repository but not in the other. In this case, two objects will exist with different logical names, 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 merge two objects that were not initially the same, or decide to keep two objects that for the inexperienced eye would seem identical. For example, recording on web browsers would likely generate identical logical names for browsers that have nothing in common. It is also 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 to either keep the two objects (and their subtrees) separated, to assume that the two objects are actually the same object, or to ignore one of the conflicting object. We will discuss these 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
Confidential
Page 56 of 100
121342730.doc
ObjectRepositoryMgr COM component. As the operation is not trivial, the UI has many options to select, so we will discuss the different options in detail.
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 repository takes lot of time . 2. The limitation on the number of Actions is 255. The reason is that each Action has a data table sheet. The Formula 1 control has a limitation of 255 sheets so the limitation is
255 Actions per test. You may be able to add additional Actions after reaching the 255 "limit", however those Actions will not be able to access a local data sheet.
Confidential
Page 57 of 100
121342730.doc
Note: If you are calling reusable Actions, you may be able to have more than 255 Actions within the script. This can be accomplished if you are calling the same Action more than one time within the script. The data sheet for the Action will only be loaded once. 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 the script, you will see the data sheet added to the data table. Insert another "call to" to the same 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:
Confidential
Page 58 of 100
121342730.doc Action Parameters. Environment Variables. VB Variables, which we declare in the script.
Confidential
Page 59 of 100
121342730.doc
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 select one of the following types: o StringA character string enclosed within a pair of quotation marks, for example, "New York". If you enter a value and do not include the quotation marks, QuickTest adds them automatically when the value is inserted in the script during the test run. The default value is an empty string. o BooleanA 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 a True or False value. The default value is True. o DateA 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 to open a calendar from which you can select a date. The default value is today's date.
Confidential
Page 60 of 100
121342730.doc
o
0. PasswordAn encrypted password value. If you select a Password value type, the password characters are masked when you enter the password in the Default Value field. The default value is an empty string. o AnyA variant value type, which accepts any of the above value types. Note that if you select the Any value type, you must specify the value in the format that is required in the location where you intend to use the value. For example, if you intend to use the value later as a string, you must enclose it in quotation marks. When you specify a value of Any type, QuickTest checks whether it is a number. If the value is not a number, QuickTest automatically encloses it in quotation marks. If you are editing an existing value, QuickTest automatically encloses it in quotation marks if the previous value had quotation marks. The default value is an empty string. 4. If you are defining an input action parameter, click in the Default Value box and enter a default value for the parameter or you can leave the default value provided by QuickTest for the parameter value type. The default value is required so that you can run the action without receiving parameter values from elsewhere in the test. 5. If you wish, click in the Description box, then enter a description of the parameter, for example, the purpose of the parameter in the action.
o
To modify an existing action parameter: 1. Select the parameter you want to modify from the Input parameters or Output parameters list. 2. Modify the values as necessary in the edit boxes of the parameter row. To delete an existing action parameter: 1. Select the parameter you want to delete from the Input parameters or Output parameters list. 2. Click the Delete button . The parameter is removed from the list.
Confidential
Page 61 of 100
121342730.doc
The Parameters tab contains two parameter lists: Input parametersSpecifies the parameters that receive values from sources that are external to the test or component. Output parametersSpecifies the parameters that pass values to sources that are external to the test or component.
You can edit an existing parameter by selecting it in the appropriate list and modifying its details. You can add and delete input and output parameters for your test or component using the parameter control buttons:
Option
Description
Confidential
Page 62 of 100
121342730.doc
Defining Values for Input Parameters When the test or component runs, QuickTest uses the default value for each defined 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 the Run dialog box. Using Test or Component Parameters Once you have defined test or component parameters, you insert them in your test or component by specifying the test or component parameter name with the Parameter reserved object, in the format: Parameter("ParameterName").
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 the Parameter Options dialog box.
Confidential
Page 63 of 100
121342730.doc
Tip: You can also create environment output values, which retrieve values during the test run and output them to internal environment variable parameters for use in your test. User-Defined Externalvariables that you predefine in the active external environment variables file. You can create as many files as you want and select an appropriate file for each test, or change files for each test run. Note that external environment variable values are designated as read-only within the test.
Built-invariables that represent information about the test and the computer on which the test is run, such as Test path and Operating system. These variables 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 dialog options. You should not use the names of these variables for any other purpose.
Confidential
Page 64 of 100
121342730.doc
You can specify a location in which to store the output action parameter values, which can 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.
Confidential
Page 65 of 100
121342730.doc
If we choose variable to store the value, then the value is stored in a runtime variable for the duration of the run session. You can accept the default 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 can specify a location for storing the output value. You can select to store the value in a test or action parameter, a Data Table parameter, or an environment parameter. 2. Repeat this procedure for each output action parameter value in the list.
Confidential
Page 66 of 100
121342730.doc
defined for the action you copied. When you split an action, the action parameters are copied to both actions. The action call values for the second action are taken from the default 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 in your script. There are three types of environment variables: User-Defined Internalvariables that you define within the test. These variables 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 the Parameter Options dialog box. User-Defined Externalvariables that you predefine in the active external environment variables file. You can create as many files as you want and select an appropriate file for each test, or change files for each test run. Note that external environment variable values are designated as read-only within the test.
Built-invariables that represent information about the test and the computer on which the test is run, such as Test path and Operating system. These variables are accessible from all tests, and are designated as read-only.
Confidential
Page 67 of 100
121342730.doc
Standard Checkpoint checks the property value of an object in your application or Web page. The standard checkpoint checks a variety of objects such as buttons, radio buttons, combo boxes, lists, etc. For example, you can check 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 an image 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 that is 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, suppose an application or Web site contains a table listing all available flights from New York to San Francisco. You can add a table checkpoint to check that the time of the first flight in the table is correct.
Confidential
Page 68 of 100
121342730.doc
Note: You create a table checkpoint by inserting a standard checkpoint on a table object. Table checkpoints are supported for Web and ActiveX environments & for many other external add-in environments.
Text Checkpoint checks that a text string is displayed in the appropriate place in the application or a Web page. For example, consider an application or Web page that displays the sentence Flight departing from New York to San Francisco. We can create a text checkpoint that checks that the words "New York" are displayed between "Flight departing from" and "to San Francisco". Text checkpoints are supported for all add-in environments
Text Area Checkpoint checks that a text string is displayed within a defined area in a Windows application, according to specified criteria. For example, suppose your Visual Basic application has a button that says View Doc <Num>, where <Num> is replaced by the four digit code entered in a form elsewhere in the application. You can create a text area checkpoint to confirm that the number displayed on the button is the same as the number entered in the form. Text area checkpoints are supported for Standard Windows, Visual Basic, and ActiveX add-in environments Text area checkpoints are also supported for some external add-in environments.
Accessibility Checkpoint identifies areas of your Web site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. For example, guideline 1.1 of the W3C Web Content Accessibility Guidelines requires you to provide a text equivalent for every non-text element. You can add an Alt property check to check whether objects that require the Alt property under this guideline, do in fact have this tag. Accessibility checkpoints are supported for the Web environment
Page Checkpoint checks the characteristics of a Web page. For example, you can check how long a Web page takes to load or whether a Web page contains broken links. Note: You create a page checkpoint by inserting a standard checkpoint on a page object. Page checkpoints are supported for the Web environment
Confidential
Page 69 of 100
121342730.doc
Database Checkpoint checks the contents of a database accessed by your Web site. For example, you can use a database checkpoint to check the contents of 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 files or XML documents in Web pages and frames. XML checkpoints (Web page/frame) are supported for the Web environment; XML checkpoints (file) are supported by all environments For more specific information refer to Checkpoints
To add checkpoints while recording To add a checkpoint while editing the test
Standard Output Values Text Output Values Text Area Output Values Database Output Values XML Output Values
Page 70 of 100
121342730.doc
To add checkpoints while recording To add a checkpoint while editing the test
For more information refer to Checkpoints Output Values Properties Dialog Box The Output Value Properties dialog box enables you to choose which property values to output 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 Value Properties dialog box opens. This dialog except that it contains two additional option areas, HTML verification and All objects in page. These options are relevant 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
Confidential
Page 71 of 100
Confidential
Page 72 of 100
121342730.doc
When forming a new product the traditional engineer can take advantage of ready-made subassemblies. 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, the authors go on to consider how the components that may be found could be used. The reusable library was designed with reuse very much in mind, making it essentially a small, 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 Test Settings dialog box (Test > Settings > Resources tab). We can also edit the list of associated library files for an existing test in the Test Settings dialog box. Note that once a test is created, the list of files specified in the Test Settings dialog box is independent of the files set as default in the Test Settings dialog box. Changes to the default library files list in the Test.
Confidential
Page 73 of 100
121342730.doc
We can use the Resources tab of the Test Settings dialog box to associate specific files with your test, such as VBScript library files and Data Table files, and to specify the object repository mode and file to use for our test. We can also set the currently associated library files and object repository settings as the default settings for all new tests.
b. Executing Externally-Defined Functions from Your Test We can create a VBScript file and call its functions, subroutines, classes, etc., from an action 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 specified file in order to make all definitions in the file available from the global scope of the action's (or library file's) script. To execute an externally-defined function:
Confidential
Page 74 of 100
121342730.doc
1. Create a VBScript file using standard VBScript syntax. 2. Store the file in any folder that you can access from the 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 the specified VBScript file as necessary in your action or within other functions in an associated library file.
Confidential
Page 75 of 100
121342730.doc
While creating checkpoints we have an option only to search or check for a specific text string 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 varying values. A regular expression is a string that specifies a complex search phrase. By using special characters 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 literal character, 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. To indicate that the period is not part of a regular expression, you would write it as follows:
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 unspecified characters. 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 Page 76 of 100
Confidential
121342730.doc
When a caret (^) is the first character inside square brackets, it instructs QuickTest to match 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 ([ ]) with the 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 preceding character. 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, just as in mathematics and programming languages. Using groups is especially useful for delimiting the argument(s) to an alternation operator ( | ) 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
Confidential
Page 77 of 100
121342730.doc
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 linesbook, my book, and book list, while
^book
Matches book only in the linesbook 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 a line, or before a new line character. For example: book Matches book within the linesmy book, and book list, while a string that is followed by ($), matches only lines ending in that string. For example: book$ Matches book only in the linemy 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 alphanumeric charactersA-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 AZ, 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 characters and underscores. For example: \W matches &, *, ^, %, $, and # . 15. Combining Regular Expression Operators You can combine regular expression operators in a single expression to achieve the 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 a combination of non-numeric characters. For example:
[a-zA-Z]*
Page 78 of 100
121342730.doc
Regular expressions are generally used in the context of creating checkpoints to check a range of values. For more information on creating checkpoints with regular expressions refer Regular Expressions
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 by the regular expression.
Confidential
Page 79 of 100
121342730.doc
Confidential
Page 80 of 100
121342730.doc
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 event has occurred, Quick Test performs the corresponding recovery and post-recovery operations. You can also control and activate your recovery scenarios during the test run by inserting Recovery statements into your test. Note: If you choose On error in the Activate recovery scenarios box in the Recovery tab of the Test Settings dialog box, the recovery mechanism does not handle triggers that occur in the last step of a test. If you chose this option and need to recover from an unexpected event or error that may occur in the last step, you of a test can do this by adding an extra step to the end of your test.
Confidential
Page 81 of 100
121342730.doc
3. Type a name for the file in the File name box. The recovery file is saved in the specified location with the file extension .qrs. Tip: If you have not yet saved the recovery file, and you click the Close button in the Recovery 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 an existing recovery file, and you click Yes to the message prompt, the recovery file and its scenarios 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 up in an open application during the test run. Indicates that the recovery scenario is triggered when the property values
Confidential
Page 82 of 100
121342730.doc
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 Viewing Recovery Scenario Properties 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 the Scenarios box. The Recovery Scenario Properties dialog box opens.
The Recovery Scenario Properties dialog box displays the following read-only information about the selected scenario:
Confidential
Page 83 of 100
121342730.doc
General tabDisplays the name and description defined for the recovery scenario, plus the name and path of the recovery file in which the scenario is saved. Trigger Event tabDisplays the settings for the trigger event defined for the recovery scenario. Recovery operation tabDisplays the recovery operation(s) defined for the recovery scenario. Post-Recovery Operation tabDisplays the post-recovery operation defined for the recovery scenario.
Modifying Recovery Scenarios You can modify the settings for an existing recovery scenario. To modify a recovery scenario: 1 In the Scenarios box, select the scenario that you want to modify. 2 Click the Edit button . The Recovery Scenario Wizard opens, with the settings you defined for the selected recovery scenario. 3 Navigate through the Recovery Scenario Wizard and modify the details as needed. Deleting Recovery Scenarios You can delete an existing recovery scenario if you no longer need it. When you delete a recovery scenario from the Recovery Scenario Manager, the corresponding information is deleted from the recovery scenario file. Note: If a deleted recovery scenario is associated with a test, Quick Test ignores it during the test run. To delete a recovery scenario: 1 In the Scenarios box, select the scenario that you want to delete. 2 Click the Delete button . The recovery scenario is deleted.
Copying Recovery Scenarios between Recovery Scenario Files You can copy recovery scenarios from one recovery scenario file to another. To copy a recovery scenario from one recovery scenario file to another: 1 In the Scenarios box, select the recovery scenario that you want to copy. 2 Click the Copy button . The scenario is copied to the Clipboard. Page 84 of 100
Confidential
to copy the scenario, or click the New button file in which to copy the scenario. 4 Click the Paste button
Note: If a scenario with the same name already exists in the recovery scenario file, you can 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 that Quick Test will perform the appropriate scenario(s) during the test runs if a trigger event occurs. 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 scenarios will 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 with a test in order to instruct Quick Test to perform the recovery scenario(s) during the test run if a trigger event occurs. The Recovery tab of the Test Settings dialog box lists all the recovery 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 as described in Setting Recovery Scenario Priorities For more information on adding a recovery scenario to a test refer to Adding Recovery Scenario to a Test Viewing Recovery Scenario Properties 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 the Scenarios box. The Recovery Scenario Properties dialog box opens, displaying read-only information regarding the settings for the selected scenario. Setting Recovery Scenario Priorities You can specify the order in which Quick Test performs associated scenarios during a test run. When a trigger event occurs, Quick Test checks for applicable recovery
Confidential
Page 85 of 100
121342730.doc
scenarios in the order in which they are displayed in the Recovery tab of the Test Settings dialog 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 scenarios priority changes according 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 Recovery tab of the Test Settings dialog box. After you remove a scenario from a test, the scenario itself 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 the test. Enabling and Disabling Recovery Scenarios You can enable or disable specific scenarios and determine when Quick Test activates the recovery scenario mechanism in the Recovery tab of the Test Settings dialog box. When you 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 enable them. Clear the check box to the left of one or more individual scenarios to disable them. To define when the recovery mechanism is activated: Select one of the following options in the Activate recovery scenarios box: AlwaysThe recovery mechanism is activated after every step. On errorThe recovery mechanism is activated only after steps that return an error return value. Note that the step that returns an error is often not the same as the step that causes the exception event to occur. For example, a step that selects a check box may cause a pop-up dialog box to open. Although the pop-up dialog box is defined as a trigger event, Quick Test moves to the next step because it successfully performed the check box selection
Confidential
Page 86 of 100
121342730.doc
step. The next several steps could potentially perform checkpoints, functions or other conditional or looping statements that do not require performing operations on 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 recovery operation is completed, the current step is this tenth step, and not the step that caused the trigger event. NeverThe 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 new tests. Any future changes you make to the current recovery scenario list only affect the current test, and do not change the default list that you defined.
In order to handle this, take a new recovery scenario, in the Select Trigger Event screen of Recovery Scenario Wizard, select pop-up window Radio button as shown below,
Confidential
Page 87 of 100
121342730.doc
In the next screen, we can specify Pop-up window condition, by spying the popup window, then details of the pop-up window appears as follows:
Confidential
Page 88 of 100
121342730.doc
then in the next step, In the recovery operation screen select keyboard or mouse operation 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:
Confidential
Page 89 of 100
121342730.doc
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 and Continue radio button, give a name to the recovery scenario, thus the recovery will be created. 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 Recovery Scenario by checking the add Scenario to current test check box in Completing the Recovery Scenario Wizard screen of Recovery Scenario Wizard.
Confidential
Page 90 of 100
121342730.doc
2. The other way to add Recovery Scenario to our test is by adding the required scenario file in the recovery tab of Test Settings Dialog box.
Confidential
Page 91 of 100
121342730.doc
Confidential
Page 92 of 100
121342730.doc
Confidential
Page 93 of 100
121342730.doc
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 adding OptionalStep to the beginning of the VBScript statement. Example: OptionalStep.Browser("browser_name").Page("page_n ame").Link("link_name")
Confidential
Page 94 of 100
121342730.doc
16. Reporting
The process of reporting is to customize the test results, and add the appropriate comments and reports to the test results to increase the readability of it. Reporting can be done in various formats. Test Results Window After a test run, we view the results in the Test Results window. By default, the Test Results window opens when a test run is completed. Note: You can open the Test Results window as a standalone application from the Start 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 barDisplays menus of available commands. Test results toolbarContains buttons for viewing test results (choose View > Test Results Toolbar to display the toolbar).
Confidential
Page 95 of 100
121342730.doc
Test results treeContains a graphic representation of the test results in the test results tree. Test results detailsContains details of the selected step. Active ScreenShows the active screen of the particular window or step in the results.
Note: If Always option is selected then the result file will occupy lots of memory, thus selection of Always option should be done only if the client wants to view all the screen shots for reference during review.
Confidential
Page 96 of 100
121342730.doc
16.2
1. ReportEvent Method Reports an event to the Test Reports. Syntax: Reporter.ReportEvent EventStatus, ReportStepName, Details [, in] Argument Type Description 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 be failed and sends the specified message to the report. When this step runs, the test fails. 2 or micDone: Sends a message to the report without affecting the pass/fail status of the test. 3 or micWarning: Sends a warning message to the report, but does not cause the test to stop running, and does not affect the pass/fail status of the test. 4 or micInfo: Applies an information status (and icon) to the step. This status does not affect the pass/fail status of the test. Name of the intended step in the report (object name). Description of the report event. The string will be displayed in the step details frame in the test report . Not in use.
EventStatus
The following example uses the Report Event method to report that the checkpoint on this 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 use this method to completely disable or enable reporting of steps following the statement, or
Confidential
Page 97 of 100
121342730.doc
you can indicate that you only want subsequent failed or failed and warning steps to be included 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 0 or rfEnableAll 1 or rfEnableErrorsAndWarnings 2 or rfEnableErrorsOnly 3 or rfDisableAll Description Default. All reported events are displayed in the Test Results. Only event with a warning or fail status are displayed in the Test Results. Only events with a fail status are displayed in the Test Results. No events are displayed in the Test Results.
Example The following example uses the Filter method to report the following events in the Test Results: 1, 2, 5, and 6. Reporter.ReportEvent micGeneral, "1", "" Reporter.ReportEvent micGeneral, "2", "" Reporter.Filter = rfDisableAll Reporter.ReportEvent micGeneral, "3", "" Reporter.ReportEvent micGeneral, "4", "" Reporter.Filter = rfEnableAll Reporter.ReportEvent micGeneral, "5", "" Reporter.ReportEvent micGeneral, "6", "
3. ReportPath Property Retrieves the folder path in which the current test's Test Results are stored.
Confidential
Page 98 of 100
Description
String The folder path in which the current test's Test Results are stored.
The following example uses the ReportPath method to retrieve the folder in which the test's Test Results are stored and displays the folder in a message box. dim Path Path = Reporter.ReportPath MsgBox (Path)
Confidential
Page 99 of 100
121342730.doc
Confidential