UFT Test object recognition

When creating and running GUI tests, UFT uses test objects to recognize objects in your application and then create test steps based on your application's objects. These test objects are based on UFT's test object model.

The test object model is a large set of object types or classes that UFT uses to represent the objects in your application. Each test object class has a list of description properties that UFT can learn about the object, a sub-set of these properties that can uniquely identify objects of that class, and a set of relevant operations that UFT can perform on the object.

When designing and running a test, there are two different types of objects:

Test objects

Test objects are stored representations that UFT creates to represent the actual objects in your application. UFT creates test objects by learning a select set of the properties and values of the objects in your application. UFT then stores the information on the object that will help it identify and check the object during the run session, and uses the data to recognize the application object during the run session.

Each test object is part of a larger test object hierarchy. For example a Link object can be part of a Page object inside a (Web) Browser object.

Top-level objects, such as Browser objects, are known as container objects, as they can hold lower-level objects, such as Page or Frame objects.

Run-time objects Run-time objects are the actual objects in your application on which UFT performs the actions (methods) during the run session. UFT learns the properties of run-time objects and translates them into test objects.

When UFT learns an object in your application, it adds a corresponding test object to an object repository. This object repository serves as a storehouse for the test objects. When UFT runs a test, it looks in the test's object repositories for the objects contained in the test steps.

When you add an object to an object repository, UFT:

  • Identifies the UFT test object class that represents the learned object in your application and creates an appropriate test object.
  • Reads the current value of the object's properties in your application and stores the list of description properties and values with the test object.
  • Chooses a unique name for the test object.

There are two different types of object repositories:

Shared object repositories

A shared object repositories is an object repository that exists independently of an individual test. The test objects in a shared object repository can be used in multiple tests/actions. This makes this type of object repository the preferred repository type for storing and maintaining your test objects as any updates you make to a test object are then applied to all tests using that shared object repository.

Local object repositories Local object repositories contain the test objects used in the context of a specific action. These type of object repositories cannot be used with other actions. By default all actions have a local object repository.

When you create an object repository, we recommend including the test objects you need for your testing purposes. This keeps the object repository relatively small and helps to simplify maintenance and object selection. Also, make sure that you provide logical names so that others can easily select the correct objects when creating or modifying tests.

Object repositories can also include checkpoint and output objects. Checkpoint object types are covered in Lesson 5: Parameterize steps and objects.

Next steps: