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 at the
lowest level of the recorded
hierarchy, the new step is
inserted as a sibling step
immediately after the
selected step.
If the selected step is a container object, the
new step is inserted as the first sub-step of the
container object.
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.

If an object with the same name is located in both the local object repository and in a shared object repository associated with the
Note: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 readonly 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 toplevel 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 runtime 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!