Post on 31-Oct-2014
© 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