QTP Training

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

Testing Services

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 Types

Understanding Object Repository Types Test objects can be stored in two types of object repositoriesa 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 Repository
You 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 Repository
When 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 Choice

Deciding 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 Window

Understanding 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 Manager

You 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 Repositories

Quick 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.

Merging Shared Repositories

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

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

Object Conflicts
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.

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 Pane

Merging 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.

Thank you

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

Testing Services