Quick Test Professional

Quick Test Professional 9.2

Testing Process

Preparing to Record

Recording

Enhancing a Test

Debugging

Running the Test and Analyzing the Results

Reporting Defects

Add-in Manager

Default Add-ins

ActiveX

Visual basic

Web

Other Add-Ins

Siebel

Java

SAP

Oracle

.Net and many more

Quick Test Professional - Record & Run Modes

Recording Modes

Normal

Analog

Low level

Run Modes

Normal

Fast

QTP Window

Create a Test

Objectives

Create a basic test from a manual test case.

Run a test and check for errors.

The Object Repository

Object repository dialog box displays a test tree of all objects in the current action or the entire application.

Using Object repository we can

a) Identify the Object

b) View the Object Properties

Object Spy

Using the Object Spy, we can view the properties of any Object in the open application.

We can also view Object Methods.

How Quick Test Recognizes Objects

For each object class, QTP has a default set of properties that it always learns.

1.Mandatory Properties.

2.Assistive properties.

3.Ordinal Identifier.

Usually, only a few properties are needed to uniquely identify an object.

Synchronization

Synchronization point enables the anticipated time problems between the application and QTP.

A progress bar reaches 100% completion.

A status message appears.

A button becomes enabled.

A window opens and is ready for data entry.

A pop-up message appears in response to an operation.

How to synchronize the Test

We can synchronize the test by

1.Inserting a synchronization point

Insert  Step  Synchronization point

Window(“Flights”).WinButton(“Update order”).WaitProperty”enabled”,1,1000

2.Adding Exist and Wait statements

status=Window(“Flights”).Dialog(“Flights Table”).Exist

Wait(10)

Checkpoints

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

We can Insert checkpoint

1.From Menu

Insert  Checkpoint  Standard Checkpoint

2.From Keyword view

3.From the Active Screen

Checkpoint Types 1.Standard Checkpoint 2.Image Checkpoint 3.Table Checkpoint 4.Page Checkpoint 5.Text Checkpoint 6.Text Area Checkpoint 7.Bitmap Checkpoint 8.Database Checkpoint

Insert A Checkpoint From The Active Screen

A checkpoint can be added after a test is created.

Use the Active Screen to select the field on which the checkpoint will be added.

Right-click on the appropriate field and choose “Insert Standard Checkpoint”.

Regular Expressions

Regular expressions enable Quick Test to Identify Objects and text strings with varying values.

Use a Regular Expression

A regular expression is a string that specifies a complex search phrase. By using

special characters you define the conditions of the search.

Note: There are 4 steps to ensure that a regular expression is inserted correctly.

From the Checkpoint Properties window, ensure Constant is enabled and click on the note paper icon.

Check Regular Expression checkbox.

If QTP sees there are characters that can be misconstrued as a regular expression, it will ask you to treat it as a literal character. Generally, you will answer No.

Add the regular expression. For example, Figure 6-6 will use [A-Z a-z]+.

Parameters

Objectives

Describe and use multiple parameter types.

Drive data in multiple iterations.

Analyze errors during iterations.

Parameterize a checkpoint.

Input Parameters For Data driven Tests

Input Parameters For Data Driven Tests

A data-driven test is one that runs a set of user actions with multiple input values. Data driving allows one script to test application functionality with many sets of data.

Automated data driven testing frees you to perform more tests, thus increasing test coverage. Speed, repeatability, free resources to do other kinds of quality control.

Input Parameter

Input Parameters allow you to replace a static, recorded value in a step with a dynamic placeholder (parameter), which represents an expandable range of values.

Input parameter names and their values are located in QuickTest’s Data Table.

Input parameter values are input into the application from some outside data source.

Steps to Create An Input Parameter

To create an input data table parameter:

Select the step in the Keyword View that contains the recorded input value.

From the Value column, click on the current value.

Click on the parameterize button.

The Constant value appears in the Value Configuration Options dialog box.

Set the Parameter Value

In the VALUE CONFIGURATION OPTIONS dialog, select the Parameter radio button and ensure that Data Table is selected from the drop-down list.

From the Name drop down list, enter a unique column name to create a new column in your data table or choose an existing column name from the data table.

Use the default Global data sheet to store values.

Enter the values that QTP will input after the test executes.

Supply Data to the Parameter

The design-time table is the central location for storing input parameter values.

The number of rows in the data table will cause the same number of test execution iterations to be run.

As a default, the design-time data table is displayed at the bottom of the QuickTest screen.

If you want to show or hide the data sheet, click on the icon in the toolbar.

Verify The Test Run

View the Test Results window to verify that each of the rows from the Design Time Data Table was used during the test run.

Expand the tree for each iteration (Row#) to view specific information about the execution of the specific row.

Parameterize a Checkpoint

You can use parameterized expected values to make your checkpoints dynamic. They Can be set on:

An object property in the Object Repository.

A checkpoint on a parameterized field.

A Test with Multiple Actions

Actions can be divided into logical sections, like the main sections of a transaction, or by specific business processes.

When you create a new test, it contains one action. By dividing your tests into multiple actions, you can design more modular and efficient tests.

Types of Actions

There are two kinds of actions:

Regular (Non-reusable)

Reusable

Tests that contain reusable actions can be used:

Locally

Externally

Insert Call to a New Action

You can add a new action during or after recording.

Select Insert ? New Action from the QuickTest main menu. The Insert New Action window appears.

Or use the “lego” icon on the toolbar to insert new action.

Using Parameterized Data

Test data can be passed from one test to another test using the value of an input parameter.

This creates a data flow between business processes.

The value passed from one business process to another will come from the Data Table.

Be aware of any data dependencies that occur within the business process.

Copied, Existing or New Action

After reusable actions are created, they can be called into a “Main Calling” test in three ways:

Call to New Action

Call to Copy of Action

Call to Existing Action

Set Actions as Reusable

Create a reusable action from the Action properties dialog.

Check the checkbox and click OK. A message will appear stating a description of a reusable

action.

Call An Action

You can do number of things with a reusable action, such as:

Call it multiple times within a test.

Call it from other tests.

View the components of the action tree (you cannot modify them except in the original script)

Insert a call to an external action (the action is inserted in read-only format)

as local editable copy

use the (read only) data from the original

action

Insert copies of non-reusable actions into your test, but you cannot insert calls to non-reusable actions.

Recovery Scenarios

To instruct Quick test to recover from unexpected events and errors that occur in the testing environment during the run session.

A Recovery scenario consists of

a) Trigger Event

b) Recovery Operation

c) Post Recovery Run Option

Recovery Scenario Wizard

We can create the recovery scenario using recovery scenario wizard.

Recovery scenario wizard consists of

a) Define the trigger event that interrupts the run session

b) Specifying the recovery operations required to continue

c) Choosing a post recovery test run operation

d) Specifying a name and description for the recovery scenario

e) Specifying whether to associate the recovery scenario to the current test and / or to all new tests.

Recovery Scenario Wizard

Creating Tests without Object Repository

We can use programmatic descriptions to perform an operation on an object that is not stored in the Object Repository.

Types of Programmatic descriptions

a) We can list the set of properties and values that describe the object directly in a test statement.

e.g: Dialog(“name:=Login”).WinEdit(“attachedtext:=agentname”).Set”impetus”

b) We can add a collection of properties and values to a description object and then enter the description object in the statement.

Set myobject=Description.Create()

myobject(“attachedtext”).value:=“agentname”

myobject(“html tag”).value:=“a”

Dialog(“name:=Login”).WinEdit (myobject).Set”impetus”

Interact with Test Objects not stored in the Object Repository

You can also instruct QT to perform methods on objects without referring to the object repository without referring to the object’s logical name. To do this you provide QT with a list of properties and values that QT can use to identify the object or objects on which you want to perform a method

Enhance TestCases With Descriptive Programming

You can describe an object directly in a test statement by specifying property : = value pairs describing the object instead of specifying an object’s logical name.