Thursday, July 17, 2008

QTP 9.2 - Functionality Tool

Are you new to HP Quick Test Pro 9.2 (QTP)? Say yes and you are at the right place, at the right time. This article is for newbie’s who want to start their carrier with QTP or have just started with QTP. The article will give you a brief overview of various features of QTP, and since it is for newbie’s we won’t be going into too much details of every feature.

What is QTP 9.2?


* HP Quick Test Pro 9.2 is a functional automation and regression testing tool
* QTP provides record and playback of events
* Uses VBScript as the scripting Language
* Provides keyword view and expert view to view test cases.
* Latest versions of QTP is 9.5 (launched in mid Jan 2008)
* Previous version of QTP: 6.5, 8.0, 8.1, 8.2, 9.0, 9.1
* QTP was previously owned by Mercury Interactive®



With introduction of QTP 9.5, Trial version of QTP 9.2 is not available. QTP 9.5 does not have any huge enhancement and hence most of the features discussed in this article will still hold


When you launch QTP for the first time, Add-in manager window is displayed

What is Add-in?

* QTP requires Add-in for recognizing object of a specific environment
* By default QTP 9.2 comes with 3 Add-ins: Web, ActiveX and VB
* Some of the Add-ins available for QTP 9.2 are

1. Terminal Emulator (TE)
2. .NET
3. Java
4. SAP
5. Siebel
6. Stingray
7. VisualAge
8. Web Services

* QTP does not require any Add-in to work on Standard windows application
* Add-ins can only be loaded when starting QTP

Once the selected Add-ins are loaded, QTP window will show up

Hit the record button to start recording. If you are recording for the first time, the Record and Run Settings dialog box opens as shown below


What all tabs are shown in above dialog would depend on Add-ins that is loaded. Using above dialog we can set on what all application should QTP record on.

Note: If QTP does not record anything on your application then make sure you have the correct settings specified in Record and Run Settings…

Keyword view


The Keyword View enables you to create and view the steps of your test in a keyword-driven, modular, table format. This is the only view where complete Test flow can be viewed.

Expert View

In Expert View, QTP displays each operation performed on the application in the form of a script, comprised of VBScript statements. Complete test flow is not available/visible in this view.

Test and Run-time Object

* QTP works on objects in Application Under Test (AUT) by storing object description
* This object description is known as a Test Object
* Each Test Object supports predefined sets of Methods and properties
* The actual object in the AUT which is identified for a Test Object is called the Run-time object.
* A Test Object can always be present without the AUT
* Run-time object can only be present when AUT is up and running


Object Spy

Object Spy is a tool that can be used to spy Test and run time object for looking at properties and methods supported by object being spied



Test Object Properties Run-time Object Properties

Object Identification

* QTP uses three types of properties when identifying a object

1. Mandatory – Always learn these properties for the object
2. Assistive – Learn in case Mandatory properties are not enough to identify the object uniquely
3. Ordinal identifiers – Learn in case both mandatory and assistive properties are not able to recognize the objects correctly


* Ordinal identifiers are of three types

1. Index – index of object (0, 1, 2 …)
2. Location – Location of the object on the screen (0, 1, 2 …)
3. CreationTime – Used only for Browser. Launchtime of browser (0, 1, 2 …)


Object Identification Settings

Launch from menu Tools->Object Identification…


Here we can Add/Remove properties from/to Mandatory and Assistive properties. Objects in application represent certain special characteristics which allow QTP to map them QTP Test object. For window objects this characteristic is mostly define by ”regexpwndclass“. In case application developers don’t use standard class names while creating object QTP won’t be able to identify the object correctly. Below is a checkbox in Search window recognized by QTP as WinObject

By clicking on the ”User Defined…“ button on Object identification settings window, we can add such objects and map. Once added QTP will now be able to recognize the object correctly

Object Hierarchy

* QTP uses object hierarchy to identify object inside a AUT
* Consider the object spy image shown below. The Web Edit ”q“ is a child of WebTable ”Advanced Search“



* QTP only adds those objects from hierarchy which are necessary for it to identify the object later.
* In this case QTP will add

Browser(”Google“).Page(”Google“).WebEdit(”q“).Set ”test“ (WebTable object ignored)

* QTP cannot be configured to record such objects automatically.


Object Repository (OR)

* QTP works on object in application by storing information about the object in Object repository
* All objects on which user takes an action while recording are automatically added to object repository
* ”Browser“, ”Google“, ”q“ are three different objects that would be present in OR for the below generated statement

Browser("Browser").Page("Google").WebEdit("q").set ”Test“

* Copying and pasting code from one script to another script does not work in QTP as the OR does not get copied to the new script
* There are two types of Object Repositories in QTP

1. Shared OR: Can be used by multiple scripts. A central location to store all objects
2. Per-Action OR: Every action has its individual object repository


Per-Action Object Repository



* Default repository
* Specific to actions (Will be used only for a particular action)
* Preferable when application is not dynamic with respect to time
* Cannot be reused


Shared Action repository

* Can be updated by all actions accessing it
* Preferable when application is dynamic with respect to time
* Used in most automation projects
* Needs maintenance and administration

Action

* Provides way of grouping code into business logic
* Are pretty similar to Functions in VBScript
* Have their own Data Table and Object Repository (in case of per-action object repository)
* Supports input and output parameters
* Actions are of two types: normal and re-usable
* Re-usable actions can be called in other Test.
* QTP does not allow calling another test within a test
* TestFlow represent the top level action. Complete test flow can only be viewed in Keyword views

Inserting Actions

* There are three ways to insert a Action in a test

1. Insert Call to New…
2. Insert Call to Copy…
3. Insert Call to Existing…


* Insert Call to New… - Creates a new action and adds a call to the same
* Adds below line to the code

RunAction "Cancel Ticket", oneIteration


Actions - Insert Call to Existing…

* Insert Call to Existing – User to insert call to a re-usable action located within the same test or some other test
* This inserts the call to the existing action. In case the action in present in some other test case then a read only copy of action is inserted


Actions – Insert Call to Copy…

* Insert Call to Copy - Inserts call to an existing re-usable action and creates an editable copy of that action
* Actions cannot be deleted from a Test from Expert view. To delete a action one must go to the keyword view and delete the action
* An action call cannot be inserted directly by writing code in Expert View, it has to be added through the GUI first.

Action Iterations

An action can be run for 1 or more rows from its Local Data Table.

* QTP supports there types of iteration modes

1. Run one iteration only
2. Run on all rows
3. Run from Row to Row

* Similar to Action, a test can also be run for multiple iterations from Global Data Table

Why Parameterization?


* Parameterization allows us to pick different values at run time.
* Reduces Time and Effort.
* Usage of data drivers allows us to use the same data for various input boxes.
* Parameterization can also be done for checkpoints.


Data Table

* Data Table is excel like spreadsheet which can be user for parameterizing a test case
* DataTable are of two types

1. Global Data Table – Data table for Test flow
2. Local data table – Data table for every action

* In below scenario only Global Data table would be used

1. Login User
2. Book one ticket
3. Logout User

* In below scenario both Global and Local data tables would be used

1. Login User (Pick data from Global Data Table)
2. Book multiple tickets (Pick data from Local data table)
3. Logout

Local Data Table

Global Data Table

* Data table value can be accessed using the below methods

1. DataTable(”“, dtGlobalSheet)
2. DataTable(”“, dtLocalSheet)
3. DataTable(”“,““)


Run-time Data table

* Any changes made to Data table during run-time is stored in run-time data table.
* Run-time data table is available in the test results summary of a test
* DataTable values can be changed at run-time by using below

DataTable(”OrderConf“, dtGlobalSheet) = ”ABCD1234“


Environment Variables

* Environment variables are global variables available to all Actions
* They can be used to run a test case on different environment
* To add a new Environment variable go to Test -> Settings…->Environment (Tab)
* Environment variables are of two types

1. Built-in
2. User-Defined

* Built in environment variables give information about the system and the current test

* User-defined Environment variables added in the Environment tab of Test Settings are Read-only during the test run
* Environment variables can be added during runtime also using code

Environment.Value(”OrderNumber“) = ”ABCDEF“

* Environment variables can be loaded at run-time from a XML file using the below code

Environment.LoadFromFile ”C:\TestEnvironment.xml“

* The Environment XML file has to be in below format





APP_URL

http://test1.appserver.com






Parameters

* Parameters provide another way of parameterizing the test cases
* There are two types of parameters

1. Test parameters
2. Action parameters

* Test parameters can be set in Test->Settings…->Parameters (Tab)
* Test parameters value can be provided when replaying the test
* Test arguments can be accessed in the test using TestArgs(”“)

Action Parameters

* Used to pass parameters to Action
* Output parameters can only be used when Action is being called for a single iteration
* Ex – RunAction "Login", oneIteration, "TestUser", "TestPass", out
* A parameter can be accessed using

Parameter(”“)



Resources

* Scripts written in VBScript language can be add as a Resource to the test
* All code written in the script is available across all Actions
* A VBScript can also be loaded in an Action by using ExecuteFile function. Ex –

ExecuteFile ”C:\Init.vbs“

* In case of multiple files QTP combines all the files into a single one and executes the code. The files are combine in bottom to top order

Checkpoints

* Checkpoints are verification points in a test
* Test without checkpoint would never have a pass status
* Checkpoints can be of types

– Built-in checkpoints

– Custom checkpoints

* Types of Built-in checkpoints available are

1. Standard checkpoints: Verify properties of an object
2. Text checkpoints: Verify text presence between two strings
3. Text Area checkpoint
4. Bitmap checkpoint
5. Accessibility checkpoint
6. Database checkpoint
7. XML Checkpoint


* Only Database and XML checkpoints can be inserted in idle mode.
* Rest all checkpoints can only be added during Recording or through Active screens.
* Checkpoint code

Browser("Google").Page("Google").WebEdit("q").Check CheckPoint("Verify TextBox_Standard")



Custom Checkpoints

* Custom checkpoints can be created using Code

loginExist = Browser().Page().Link(”text:=Login“).Exist(0)

If loginExist then

Reporter.ReportEvent micPass, ”Check Login“, ”Login link exists“

Else

Reporter.ReportEvent micFail, ”Check Login“, ”Login link does not exists“

End if

* Custom checkpoint can be made flexible based on implementation and are preferred over Built-in checkpoints


Test Results

Test results provide a execution summary of the complete test case


* There are different types of status in test results summary:

1. Passed
2. Failed
3. Done
4. Warning
5. Information


Descriptive Programming


* Alternate way of writing test cases without having objects in object repository
* Descriptive programming can be done in two ways

1. Using object description
2. Using string description


* In DP objects are identified by describing all the identification properties
* String description DP

Browser(”title:=Google“).Page(”title:=Google“).WebButton(”name:=Search“).Click

* Object Based DP

Set btnSearch = Description.Create : btnSearch(”name“).Value = ”Search“

Set brwGoogle = Description.Create : brwGoogle(”title“).value = ”Google“

Set pgGoogle = Description.Create : pgGoogle(”title“).value = ”Google“

Browser(brwGoogle).Page(pgGoogle).WebButton(btnSearch).Click

* Description objects can also be used to get all child objects matching a criterion. Ex –

Set oDesc = Description.Create

oDesc(”name”).Value = ”txt_.*“

oDesc(”name”).RegularExpression = True

Set allMatchingObjects = Browser().Page().ChildObjects(oDesc)

Msgbox allMatchingObjects.Count

Msgbox allMatchingObjects(0).GetROProperty(”name“)

* By default all property values are considered as regular expression patterns
* When using string description all regular expression must be used with escape character for literal meaning. Ex - …Link(”text:=Logout \(Tarun\)“).Click


* DP based Object repository can be created in any file
* Code can be copied from one script to another without copying the object repository
* Custom implementation of object is easier. Ex –


objStrDesc = ”Browser(”“title:=Test““).Page(”“title:=Test““).Link(”“text:=Login““)“

Execute ”Set obj = ” & objStrDesc

obj.Click

QTP Misc information

* QTP and the AUT has to be on the same machine
* QTP can be controlled remotely from another machine
* QTP scripts cannot be run without QTP

No comments:

Quality Center


Quality Center

A Quality Center project is a database for collecting and storing data relevant to a testing process. For QuickTest to access a Quality Center project, you must connect to the local or remote Web server where Quality Center is installed. When QuickTest is connected to Quality Center, you can create tests and save them in your Quality Center project. After you run your tests, you can view the results in Quality Center.


Quality Center helps you maintain a project of all kinds of tests (such as QuickTest tests, business process tests, manual tests, tests created using other Mercury products, and so forth) that cover all aspects of your application's functionality. Each test in your project is designed to fulfill a specified testing requirement of your application. To meet the goals of a project, you organize the tests in your project into unique groups.

You can instruct QuickTest to automatically submit a defect to a Quality Center project for each failed step in your test. You can also manually submit a defect for a specific step to Quality Center directly from within your QuickTest Test Results window. These options are only available when you are connected to a Quality Center project.

Saving Tests to a Quality Center Project

When QuickTest is connected to a Quality Center project, you can create new tests in QuickTest and save them directly to your project. To save a test, you give it a descriptive name and associate it with the relevant subject in the test plan tree. This helps you to keep track of the tests created for each subject and to quickly view the progress of test planning and creation. In QuickTest, click Save or choose File > Save to save the test. The Save Test to Quality Center dialog box opens and displays the test plan tree.

The Save Test to Quality Center dialog box opens only when QuickTest is connected to a Quality Center project. To save a test directly in the file system, click the File System button to open the Save QuickTest Test dialog box. You can return to the Save Test to Quality Center project dialog box by clicking the Quality Center button.

Submitting Defects to a Quality Center

When viewing the results of a run session, you can submit any defects detected to a Quality Center project directly from the Test Results window.

To manually submit a defect to Quality Center: or click the Choose Tools > Quality Center ConnectionQuality Center Connection button to connect to a Quality Center project. Choose Tools > Add Defect or click the Add Defect button to open the Add Defect dialog box in the specified Quality Center project. The Add Defect dialog box opens. You can modify the defect information if required. Basic information about the test and any checkpoints (if applicable) is included in the description. Click submit button.

To automatically submit defects to Quality Center: Choose Tools > Options or click the Options button . The Options dialog box opens. Click the Run tab. Select the Submit a defect to Quality Center for each failed step check box.