The Test Object Model

Relevant for: GUI tests and components

UFT tests your dynamically changing application by learning and identifying test objects and their expected properties and values. To do this, UFT analyzes each object in your application in much the same way that a person would look at a photograph and remember its details. By learning and classifying objects, UFT creates a test object model.

How UFT learns objects

UFT learns objects just as you would. For example, suppose as part of an experiment, Alex is told that he will be shown a photograph of a picnic scene for a few seconds during which someone will point out one item in the picture. Alex is told that he will be expected to identify that item again in identical or similar pictures one week from today.

Before he is shown the photograph, Alex prepares by thinking about which characteristics he wants to learn. Obviously, he notes whether it is a person, inanimate object, animal, or plant. Then, if it is a person, he remembers the gender, skin color, and age. If it is an animal, he remembers the type of animal, its color, and so forth.

The tester shows the scene to Alex and points out one of three children sitting on a picnic blanket. Alex notes that it is a Caucasian girl about 8 years old. In addition, he realizes that one of the other children in the picture also fits that description. In addition to learning his planned list of characteristics, he also notes that the girl he is supposed to identify has long, brown hair.

Now that only one person in the picture fits the characteristics he learned, he is fairly sure that he will be able to identify the girl again, even if the scene the tester shows him next week is slightly different. Since he still has a few moments left to look at the picture, he attempts to notice other, more subtle differences between the child he is supposed to remember and the others in the picture—just in case.

UFT uses a very similar method when it learns objects.

First, it "looks" at the object being learned and stores it as a test object, determining in which test object class it fits. UFT might classify the test object as a standard Windows dialog box (Dialog), a Web button (WebButton), or a Visual Basic scroll bar object (VbScrollBar), for example.

Then, UFT "considers" the description properties for the test object. For each test object class, UFT has a list of mandatory properties that it always learns. When UFT learns an object, it always learns these default property values, and then "looks" at the rest of the objects on the page, dialog box, or other parent object to check whether this description is enough to uniquely identify the object. If not, UFT adds assistive properties, one by one, to the description, until it has compiled a unique description. If no assistive properties are available, or if those available are not sufficient to create a unique description, UFT adds a special ordinal identifier, such as the object's location on the page or in the source code, to create a unique description.

Back to top

How UFT uses the test object model

The test object model is a large set of object types or classes that represents the objects in your application. Each test object class has a list of description properties that UFT learns 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.

Example: Suppose you add a Search button with the following HTML source code:

<INPUT TYPE="submit" NAME="Search" VALUE="Search">

UFT identifies the object as a WebButton test object. In the object repository, UFT creates a WebButton object with the name Search, learns a set of description properties for the object, and decides to use the following properties and values to uniquely identify the Search WebButton:

When you run a test or component, UFT identifies each object in your application by its test object class and its description (the set of description properties and values used to uniquely identify the object).

Back to top

Test object hierarchy

The UFT test object hierarchy comprises one or more levels of test objects. The top level object may represent a window, dialog box, or browser type object, depending on the environment. The actual object on which you perform an operation may be learned as a top level object, a second level object, for example, Window.WinToolbar, or a third level object, for example, Browser.Page.WebButton.

If an object in your application is embedded in several levels of objects, the testobject hierarchy does not include these objects. For example, if a WebButton object in your application is contained in several WebTable object inside a Browser and Page, the learned object hierarchy is only Browser.Page.WebButton.

An object that can potentially contain a lower-level object is called a container object. All top-level objects in the object hierarchy are container objects. If a second-level object contains third-level objects according to the UFT object hierarchy, then that object is also considered a container object. For example, in the step Browser.Page.Edit.Set "David", Browser and Page are both container objects.

Back to top

Defining object properties

View and modify properties and operations for test objects:

Back to top