QTP-PPT-DAY3-CHAP2

© 2008, Cognizant Technology Solutions. All Rights Reserved. The information contained herein is subject to change without notice. Testing ServicesTesting Services

QTP Training

Utilizing a Shared Object Repository

Objectives

After completing this chapter, you will be

able to:

• Understanding Object Repository Types.

• Describe local versus shared object repositories.

• Use of the Object Repository Manager.

Object Repository TypesUnderstanding Object Repository Types

Test objects can be stored in two types of object repositories—a shared

object repository and a local object repository. A shared object repository

stores test objects in a file that can be accessed by multiple tests (in

read-only mode). A 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.

When we plan and create tests, you must consider how you want to store

the objects in your tests. You can store the objects for each action in its

corresponding local object repository, or you can store the objects in your

tests in one or more shared object repositories. By storing objects in shared

object repositories and associating these repositories with your actions, you

enable multiple actions to use the objects. For each action, you can use a

combination of objects from your local and shared object repositories,

according to your needs.

Object RepositoryYou can also transfer local objects to a shared object repository, if required.

This reduces maintenance and enhances the reusability of your tests because

it enables you to maintain the objects in a single, shared location instead of

multiple locations.

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.

Local objects are saved locally with the action, and can be accessed only

from that action. When using a shared object repository, you can use the

same object repository for multiple actions. You can also use multiple object

repositories for each action.

Object RepositoryWhen we open and work with an existing test, it always uses the object

repositories that are specified in the Associated Repositories tab of the Action

Properties dialog box or in the Associate Repositories dialog box.

Shared object repositories are read-only when accessed from tests; you edit

them using the Object Repository Manager.

Note for users of previous QuickTest versions: When you open a test that

was created using a version of QuickTest earlier than version 9.1, you are

asked whether you want to convert it or view it in read-only format.

Whether you choose to open it in read-only format or convert it, the object

repositories are associated to the test as follows:

➤ If the test previously used per-action repositories, the objects in each

per-action repository are transferred to the local object repository of each

action in the test.

➤ If the test previously used a shared object repository, the same shared

object repository is associated with each of the actions in the test, and

the local object repository is empty

Object Repository ChoiceDeciding Whether to Use Local or Shared Object Repositories

To choose where to save objects, you 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.

Object Repository Choice

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.

Shared Object Repository

When we use shared object repositories, QuickTest uses the shared object

repositories you specify for the selected action. You can use one or more

shared object repositories. (You can also save some objects in a local object

repository for each action if you need to access them only from the specific

action.

After you begin creating your test, you can specify additional shared object

repositories. You can also create new ones and associate them with your

action. Before running the test, you must ensure that the object repositories

being used by the test contain all the objects in your test. Otherwise, the test

may fail.

You modify a shared object repository using the Object Repository Manager

Shared Object Repository

When working with a shared object repository:

➤ If you record operations on an object that already exists in either the shared

or local object repository, QuickTest uses the existing information and does

not add the object to the object repository.

➤ If a child object is added to a local object repository, and its parents are in a

shared object repository, its parents are automatically moved to the local

object repository.

➤ QuickTest does not add an object to the shared object repository as you

record operations on it. Instead, it adds new objects to the local object

repository (not the shared object repository) as you learn objects or record

steps on them (unless those same objects already exist in an associated

shared object repository).

Object Repository WindowUnderstanding the Object Repository Window

You open the Object Repository window for a specific action by choosing

Resources > Object Repository or clicking the Object Repository button.

The Object Repository window displays a tree of all objects in the selected

action (including all local objects and all objects in any shared object

repositories associated with the selected action).

Object Repository Window

For each test object you select in the tree, the Object Repository window

displays information on the test object, its type, the repository in which it is

stored, and its test object details. Local objects are editable (black); shared

objects are in read-only format (gray).

While the Object Repository window is open, you can continue using

QuickTest, and you can continue modifying test objects and object

repositories. You can also resize the Object Repository window if needed.

The Object Repository window reflects any changes you make to an

associated object repository in real time. For example, if you add objects to

the local object repository, or if you associate an additional object repository

with the current action, the Object Repository window immediately displays

the updated content.

Object Repository ManagerYou open the Object Repository Manager by choosing Resources > Object

Repository Manager. The Object Repository Manager enables you to open

multiple shared object repositories and modify them as needed.

You can open as many shared object repositories as you want copy, drag, and

move objects between different shared object repositories, as well as perform

operations on a single object repository

Merging Shared RepositoriesQuick Test Professional provides the ability to merge existing assets from two

object repositories into a single shared object repository using the Object

Repository Merge Tool. This tool enables you to merge two shared object

repositories (called the primary object repository and the secondary object

repository), into a new third object repository, called the target object Repository.

Objects in the primary and secondary object repositories are automatically

compared and then added to the target object repository according to

preconfigurable rules that define how conflicts between objects

are resolved.

After the merge process, the Object Repository Merge Tool provides a graphic

presentation of the original objects in the primary and secondary object

repositories, which remain unchanged, as well as the objects in the merged

target object repository. Objects that had conflicts are highlighted. The conflict of

each object that you select in the target object repository is described in detail.

The Object Repository Merge Tool provides specific options that enable you to

keep the suggested resolution for each conflict, or modify each conflict

Resolution individually, according to your requirements.

The Object Repository Merge Tool also enables you to merge objects from the

local object repository of one or more actions into a shared object repository

Merging Shared Repositories

Object Conflicts ➤ Similar Description Conflict

Two objects which have the same name and the same object hierarchy, but which have slightly different descriptions. In this conflict type, one of the objects always has a subset of the properties set of the other object.

By default, the conflict resolution settings for conflicts of this type are configured so that the target object repository takes the object that has fewer identifying properties than the object with which it conflicts.

➤ Same Name Different Description Conflict

Two objects which have the same name and the same object hierarchy, but differ somehow in their description (for example, they have different properties, or the same property with different values).

By default, the conflict resolution settings for conflicts of this type are configured so that the target object repository takes the object from both files. The object that is added from the secondary file is renamed by adding an incremental numeric suffix to the name

➤ Same Description Different Name Conflict

Two objects which have identical descriptions, have the same object hierarchy, but differ in their object names.

By default, the conflict resolution settings for conflicts of this type are configured so that the target object repository takes the object name from the primary source file.

Object Conflicts

Resolving Object Conflicts Conflicts between objects in the primary and secondary object repositories are resolved automatically by the Object Repository Merge Tool according to the default resolution settings that you can configure before performing the merge However, the Object Repository Merge Tool also allows you to change the way the merge was performed for each individual object that causes a conflict.

Filtering the Target Repository PaneMerging two object repositories can result in a target object repository

containing a large number of objects. To make navigation and the location

of specific objects easier in the target object repository pane, the Object

Repository Merge Tool enables you to filter the objects in the pane and show

only the objects that had conflicts that were resolved during the merge.

To filter the objects in the target object repository pane:

1.Choose Tools > Filter or click the Filter button. The Filter dialog box opens.

2 .Select a radio button according to the objects you want to view in the target

object repository.

➤ Show all objects. Shows all objects in the target object repository

➤ Show only objects with conflicting descriptions. Shows only objects in the

target object repository that had description conflicts

3 .Click OK. The objects in the pane are filtered and the target object

repository displays only the requested object types. A progress bar is

displayed in the status bar during the filter process.

© 2008, Cognizant Technology Solutions. All Rights Reserved. The information contained herein is subject to change without notice.

Thank you

Testing ServicesTesting Services