Tests Creation

Tests Creation

Using the following QuickTest components

Designing Tests

Keyword View

Test Objects

Active Screen

Checkpoints

Object Property Values

Tables, Text, Bitmaps, Databases

Configuring Values

Actions

Data Tables

Designing Tests

You can create a test by recording the operations you perform on your application or using the keyword-

driven methodology. After you create your test, you can enhance it using checkpoints and other special

testing options.

In some cases, you may want to let QuickTest generate test steps by recording the typical processes that

you perform on your application. As you navigate through your application, QuickTest graphically displays

each step you perform as a row in the Keyword View.

While creating your test, you can insert checkpoints into your test.

When you test your application or site, you may want to check how it performs the same operations with

different data. This is called parameterizing your test.

Keyword View

The Keyword View enables us to create and view the steps of our test in a modular,

table format. Working in the Keyword View does not require any programming

knowledge. The programming required to actually perform each test step is done

automatically behind the scenes by QuickTest.

Keyword View

QuickTest Recorded Object Hierarchy

Keyword View

Actions are the highest level of the test

hierarchy. They contain all the steps that are

part of that action. In the Keyword View, you

can view either the flow of all the action calls

in the test, or the content of a specific

reusable action, using the options in the

Action toolbar.

The Action toolbar is available only if at least

one of the actions in your test is reusable.

Each action is comprised of steps. During a

recording session, each step is recorded as

a row in the Keyword View. For example, the

Keyword View could contain these rows.

For every step in the Keyword View,

QuickTest displays a corresponding line of

script in the Expert View. If you select a

specific row in the Keyword View and switch

to the Expert View, the cursor is located in

the corresponding line of the script.

These rows show the following three steps that are all performed on the Welcome: Mercury Tours page of the Mercury Tours sample web site: mercury is entered in the userName edit box.

•The encrypted string 3ee35 is entered in the password edit box.•The Sign-In image is clicked.•The Documentation column translates each of the steps into understandable sentences.

QTP Recorded Object Hierarchy

The recorded object hierarchy comprises one or more levels of test objects. The top level is the object that represents a window, dialog, or

browser type object, depending on the environment. Depending on the actual object on which you performed an operation, that object may be

recorded as a top level object or a second level object, for example, Window > WinToolbar or a third level object, for example, Browser >

Page > WebButton.

Even though the object on which you record may be embedded in several levels of objects, the recorded hierarchy does not include these

objects. For example, even if the WebButton object on which you record is actually contained in several nested WebTable objects, which are all

contained within a Browser and Page, the recorded hierarchy is only Browser > Page > WebButton.

An object that can potentially contain a lower-level object is called a container object. All top-level objects in the recorded hierarchy are

container objects. If a second-level object contains third-level objects according to the QuickTest recorded object hierarchy, then that object is

also considered a container object. For example, in the step Browser > Page > Edit > Set "David", Browser and Page are both container

objects.

If the selected step is a container object, the new step is inserted as the first sub-step of the container object.

If the selected step is at the lowest level of the recorded hierarchy, the new step is inserted as a sibling step immediately after the selected step.

Test Objects

Object Repository Types

Object Repository Window

Test Object Properties

Locating Objects

Object Repository Types

QTP has to learn the interface of an application to be able to work with it. It does by learning the application's objects and

their corresponding property values and storing these object descriptions in an object repository.

local object repository - stores objects in a file that is associated with one specific action, so that only that action can

access the stored objects.

shared object repository - stores test objects in a file that can be accessed by multiple tests (in read-only mode).

Why we have to modify OR - If one or more of the property values of an object in your application differ from the property values

QuickTest uses to identify the object, your test may fail. Therefore, when the property values of objects in your application change, you

should modify the corresponding test object property values in the corresponding object repository so that you can continue to use your

existing tests.

Object Repository window - To modify test objects stored in a local object repository.

Object Repository Manager - To modify test objects in a shared object repository.

Note:-

If an object with the same name is located in both the local object repository and in a shared object repository associated with the

same action, the action uses the local object definition.

If an object with the same name is located in more than one shared object repository associated with the same action, the object

definition is used from the first occurrence of the object, according to the order in which the shared object repositories are

associated with the action.

Selection between Local or Shared Object Repositories

To choose where to save objects, we need to understand the differences between local and shared object

repositories.

In general, the local object repository is easiest to use when you are creating simple record and run tests,

especially under the following conditions: You have only one, or very few, tests that correspond to a given application, interface, or set of objects.

You do not expect to frequently modify test object properties.

You generally create single-action tests.

Conversely, the shared object repository is generally the preferred option when:

You are creating tests using keyword-driven methodologies (not using record).

You have several tests that test elements of the same application, interface, or set of objects.

You expect the object properties in your application to change from time to time and/or you regularly need to

update or modify test object properties.

You often work with multi-action tests and regularly use the Insert Copy of Action and Insert Call to Action

options.

Object Repository Window

Open the Object Repository window for a specific action or

component by choosing Resources > Object Repository or

clicking the Object Repository button .

The Object Repository window displays a tree of all objects in

the current component or in the selected action (including all

local objects and all objects in any shared object repositories

associated with the selected action or component).

Local objects are editable (black); shared objects are in read-

only format (gray).

Active Screen

The Active Screen provides a snapshot of your application in a recording session and enables

you to insert additional steps on the test objects captured in that screen after the recording

session. To view the Active Screen pane, click the Active Screen button or choose View > Active

Screen.

We can decide if and how much information you want to capture and save in the Active Screen.

The more information you capture, the easier it is to add steps to your test using the many Active

Screen options.

Checkpoints

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

expected value for that property. This enables you to identify whether your Web site or application is

functioning correctly.

When we add a checkpoint, QuickTest adds a checkpoint to the current row in the Keyword View and

adds a Check CheckPoint statement in the Expert View. By default, the checkpoint name receives the

name of the test object on which the checkpoint is being performed.

Types of Checkpoints

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, and so forth.

Image Checkpoint checks the value of an image in your application or Web page. For example, you can check that

a selected image's source file is correct.

Bitmap Checkpoint checks an area of your Web page or application as a bitmap. For example, suppose you have a

Web site that can display a map of a city the user specifies.

Table Checkpoint checks information within a table. For example, suppose your 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.

Continued…

Text Checkpoint checks that a text string is displayed in the appropriate place on a Web page or application.

Text Area Checkpoint checks that a text string is displayed within a defined area in a Windows application,

according to specified criteria.

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.

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.

Database Checkpoint checks the contents of a database accessed by your application.

XML Checkpoint checks the data content of XML documents in XML files or XML documents in Web pages and

frames.

Supported Checkpoints

The table shows the types of

checkpoints supported for each add-in

environment that is supported by

default with the QuickTest

Professional

Image Checkpoint Properties Dialog Box

Modifying Checkpoints

You can modify the settings of existing checkpoints. For example, you can choose to use parameters, or you

can use filters to specify which image sources and links to check.

To modify a checkpoint:

In the Keyword View or Expert View, right-click the checkpoint that you want to modify and select Checkpoint

Properties. Alternatively, select the step containing the checkpoint and choose

Edit > Step Properties > Checkpoint Properties. The relevant checkpoint dialog box opens.

Modify the properties and click OK.

Planning and Preparing to Create a Test

Before you start creating your test, you should plan it and prepare the required infrastructure.

Determine the functionality you want to test.

Decide which information you want to check during the test.

Consider changing the way that QuickTest identifies specific objects.

Decide how you want to organize your object repositories.

Find out whether an object repository containing the objects you are testing already exists.

Determine whether you need to create any new user-defined functions or whether you should associate

any existing function libraries with your test.

If you are recording steps, evaluate the types of events you need to record.

Consider increasing the power and flexibility of your test by replacing fixed values with parameters.

Consider using actions to streamline the testing process.

Configuring Values

QuickTest enables you to configure the values for properties and other items by defining a value

as a constant or a parameter.

Constant. A value that is defined directly in the step and remains unchanged for the duration of the test.

Parameter. A value that is defined or generated separately from the step and is retrieved when the specific

step runs. For example, a parameter value may be defined in an external file or generated by QuickTest.

Setting Values in the Configure Value Area

select an item in a dialog box containing a

Configure value area, such as the Checkpoint

Properties dialog box, you can select Constant

or Parameter to set the value. The default is

Constant.

select Parameter for a value that is already

parameterized, the Parameter box displays the

current parameter definition for the value.

Actions

You can divide your test into actions to streamline the process

of testing your application or Web site.

A test comprises calls to actions. When you create a new test,

it contains a call to a single action.

An action consists of its own test script, including all of the

steps recorded in that action, and any objects in its local object

repository.

Each action is stored together with the test in which you

created it. You can insert a call to an action that is stored with

the test and, depending on the properties of the action, you

may also be able to call an action stored with another test.

Using Multiple Actions in a Test

When you create a test, it includes one action. All the steps you record and all the modifications you make while

editing your test are part of a single action.

You can divide your test into multiple actions by creating new actions and inserting calls to them, or by inserting

calls to existing actions.

There are three kinds of actions:

non-reusable action. an action that can be called only in the test with which it is stored.

reusable action. an action that can be called multiple times by the test with which it is stored (the local test), as

well as by other tests.

external action. a reusable action stored with another test. External actions are read-only in the calling test,

but you can choose to use a local, editable copy of the Data Table information for the external action.

Creating New Actions

We can create new actions and add calls to them during a

recording session or while designing or editing your test.

To create a new action in your test:

If you want to insert a call to the new action from an existing action

in your test, click the step after which you want to insert the new

action. To insert a call to the new action from the test flow as a top-

level action, click any step.

Choose Insert > Call to New Action or click the Insert Call to

New Action button. The Insert Call to New Action dialog box

opens.

Nesting Actions

To call an action from within an action. This is called nesting. By nesting actions, you can:

Maintain the modularity of your test.

Run one or more actions based on the results of a conditional statement.

Continued…

In the Expert View, the test might look something like this:

Browser("Membership Preference").Page("Membership Preference").WebRadioGroup("MemType").Select DataTable("memtype",

dtGlobalSheet)

Mem_Type=Browser("Membership Preference").Page("Membership Preference").WebRadioGroup("MemType").GetROProperty

("value")

If Mem_Type="paid" Then

        RunAction "Paid_Mem", oneIteration

ElseIf Mem_Type = "free" Then

        RunAction "Free_Mem", oneIteration

Else

        RunAction "Preferred", oneIteration

End If

Data Tables

QuickTest enables you to insert and run steps that

are driven by data stored in the Data Table.

The Data Table has the characteristics of a

Microsoft Excel spreadsheet, meaning that you

can store and use data in its cells and you can

also perform mathematical formulas within the

cells.

During the run session, QuickTest creates a run-

time Data Table—a live version of the Data Table

associated with your test.

During the run session, QuickTest displays the

run-time data in the Data Table pane so that you

can see any changes to the Data Table as they

occur.

Thank You!