Test object model

Relevant for: GUI tests and components

UFT One tests your dynamically changing application by learning and identifying test objects and their expected properties and values. To do this, UFT One 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 One creates a test object model.

In this topic:

How UFT One learns objects

UFT One 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 or its color.

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 One 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 One 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 One "considers" the description properties for the test object. For each test object class, UFT One has a list of mandatory properties that it always learns. When UFT One 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 One 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 One 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 One 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 One 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 One can perform on the object.

When you run a test or component, UFT One 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 One 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 One 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:

• Retrieve or modify values manually while designing your test or component, or use SetTOProperty statements during a run session.

  For details, see Test objects in object repositories, Retrieve and set values, and the SetTOProperty method in the Common Methods and Properties section of the UFT One Object Model Reference for GUI Testing.

• Use regular expressions in function libraries to identify property values based on conditions or patterns you define. For details, see Regular expressions.

• View or modify the values that are stored with your test or component in the Object Properties or Object Repository window. For details, see Maintain test objects in object repositories.

• View the current values of any visible object using the Properties tab of the Object Spy. For details, see Use the Object Spy.

Back to top