Local & Shared Object Repository in QTP/UFT

By : Thomas Hamilton Thomas Hamilton
Hours Updated

⚡ Smart Summary

Object Repository in QTP/UFT One stores the test objects and properties the tool uses to recognize your application, and it comes in two forms: a local repository per action and a reusable shared repository.

  • 🔘 Test object model: QTP learns object properties while recording and compares them with the run-time object during playback.
  • ☑️ Local by default: Every action starts with its own local repository, saved as ObjectRepository.bdb inside the action folder.
  • ✅ Shared repositories scale: A .tsr file lives outside the test and can be associated with many actions across many tests.
  • 🧪 Three broad steps: Create the repository, associate it with your actions, then edit it through the Object Repository Manager.
  • 🛠️ Read-only guard: A shared repository opens read-only in the Manager until File > Enable Editing is selected.
  • 📌 Current naming: QTP is now OpenText Functional Testing (UFT One), but the repository menus and file formats are unchanged.
Read More

Local and shared object repository structure in QTP and UFT One

What is Object Repository in QTP?

Object Repository is a collection of Test Objects and information that is recognized by QTP for working on it. When a user records a test, the objects and their properties are captured by default.

Because every step you automate has to point at a stored object, the repository is the layer that decides whether a script keeps running after the application changes. Understanding how objects get there comes first.

How Does Object Identification work in QTP?

  • QTP uses a “human” like technology for object identification
  • During Record time, QTP tries to learn the properties of a GUI object on which an operation is performed.
  • During Run-Time, UFT One compares the stored object properties with the actual properties of the object available on screen and uniquely identifies an object independent of its location on the screen
  • The stored object, together with its properties, is called the Test Object
  • During Run-Time, the actual object available on the application under test is called the Run-Time Object
  • This is the QuickTest “Test Object Model”
  • Information about the Test Objects is stored in the Object Repository
  • Add-ins help by instructing QuickTest in advance about the nature of the object to be recorded, so as to reduce the time required to learn its properties

Learn Object Identification with an example in the following video

Click here if the video is not accessible

Types of Object Repository

There are 2 Types of Object Repository in QTP

  1. Local Object Repository
  2. Shared Object Repository

The two differ in one respect only: who owns the objects. The local repository belongs to a single action, while the shared repository is an independent file that any action can borrow.

Local Object Repository

  • Local Object Repository is the default object repository
  • It is specific to actions and can be used only for a particular action
  • Local Object Repository is preferable when the application is not dynamic with respect to time
  • Local Object Repository cannot be reused
  • You can perform many operations in the local object repository, such as:
    • Highlight an object stored in a repository on the application under test
    • Check whether a particular object in your AUT is stored in the Object Repository
    • Cut, Copy, Paste, Modify and Delete Objects
    • In case you have accidentally modified the value of a property, you can update its description from the application using the update function.

The video below demonstrates working with the local object repository.

Shared Object Repository: Create, Associate, Edit

  • Global or Shared Object Repository is preferable when an application is dynamic and object descriptions change frequently
  • Between Shared and local object repository, the shared object repository is more commonly used in automation projects
  • However, it has maintenance and administration overheads as compared to the local object repository.

To create and use a shared object repository you need to perform three broad steps

  • Creating a Shared Object Repository
  • Associating a Shared Object Repository
  • Editing a Shared Object Repository

Let’s look at them one at a time

Step 1) Creating a Shared Object Repository

  • All repositories are local by default. To create a Shared Object Repository, in the Object Repository Dialog Box, Click File > Export Local Objects
  • Repository files have an extension .tsr. Give a suitable name, say “guru99”, and save
  • The Shared Repository File is now created

Step 2) Associating a Shared Object Repository

  • The next step is to associate the repository with your test, which enables you to use it
  • To associate a repository with a test, Click Resources > Associate Repository (labelled Associate Repositories in current UFT One versions)
  • You can select the Repository to associate with Actions available in your test.
  • You can now use this shared repository to develop your test

RELATED ARTICLES

Step 3) Editing a Shared Object Repository

  • You can use the Object Repository Manager to edit a shared repository.
  • Select Resources > Object Repository Manager. Open the Object Repository we created, “guru99”
  • By default, the repository is opened in Read-only mode. To enable editing, click File > Enable Editing
  • Once editing is enabled you can perform all the operations like cut, copy, paste and rename objects that you can also do in the Object Repository
  • Using the Object Repository Manager you can also compare two Object Repositories. QTP reports statistics on what is unique and what is common in both repositories
  • You can use the Object Repository Merge Tool to merge two repositories into one

The following video walks through the shared repository workflow.

Difference Between Local and Shared Object Repository

Most teams eventually run both kinds side by side, so it helps to see the trade-offs in one place before deciding where a new object belongs.

Criteria Local Object Repository Shared Object Repository
Availability Created automatically with every action Must be created, then associated with an action
Scope One repository per action; usable only by that action One file usable by many actions across many tests
File format Saved as ObjectRepository.bdb inside the action folder Saved as an external .tsr file
Editing Editable directly in the Object Repository window Read-only by default; edited through the Object Repository Manager
Reuse Cannot be reused Designed for reuse and version control
Maintenance A changed property must be fixed in every action A changed property is fixed once, for every associated test
Best suited to Small, stable applications and single-action learning tests Large or dynamic applications with several automation engineers

In short, the local repository is faster to start with and the shared repository is cheaper to maintain. Learning tests and one-off checks can stay local; anything a second person will run belongs in a .tsr file.

How to Add Objects Directly to a Shared Object Repository

Exporting local objects is only one route to a .tsr file. When you already know which controls the suite needs, it is quicker to build the shared repository first and never record at all.

  1. Select Resources > Object Repository Manager to open the Manager window.
  2. Choose File > New to start an empty shared repository, or open an existing .tsr file and select File > Enable Editing.
  3. Use the Add Objects option to point at the control you want to learn in the application under test, then confirm the selection.
  4. Repeat for every control the suite touches, renaming objects to something readable as you go.
  5. Select File > Save and store the file in your source-control folder alongside the test.
  6. Back in the test, select Resources > Associate Repository and attach the file to each action that needs it.

Two habits make this approach pay off. Name objects after their business role rather than their caption, because captions change more often than roles. Also keep one repository per application screen or module instead of one giant file, since smaller repositories load faster and produce far fewer merge conflicts.

FAQs

A local object repository is stored as ObjectRepository.bdb inside its action folder. A shared object repository is stored as a standalone .tsr file that sits outside the test and can be checked into source control.

Yes. Open the Object Repository window for the action and choose File, then Export Local Objects. QTP writes the action’s objects to a .tsr file, which you then associate with any action that needs them.

Yes. The Associate Repository dialog accepts several .tsr files per action and lets you set their priority order. When the same object name appears twice, the repository higher in the list wins.

The Object Repository Manager opens shared files read-only so two engineers cannot overwrite each other. Choose File, then Enable Editing, to take the write lock, and close the file when finished so colleagues can edit it.

AI-assisted identification in UFT One matches controls by visual appearance and label text rather than fixed properties, so a renamed class no longer breaks the step. Self-healing suggestions also flag stale repository descriptions after a UI change.

Copilot can draft the surrounding VBScript logic, loops and reporting, but it cannot see your repository. Object names must still come from the repository itself, so treat generated hierarchies as placeholders and verify each one with Object Spy.

No, it complements it. Descriptive programming builds an object description in code at run time, which suits dynamic controls, while the repository stays the better choice for stable screens and readable scripts.

Open both files in the Object Repository Manager and run the Object Repository Merge Tool. It reports which objects are common and which are unique, then lets you resolve each conflict before writing the merged .tsr file.

Summarize this post with: