Test object model

Relevant for: GUI tests and components

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

In this topic:

Learning objects

OpenText Functional Testing 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. Because 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.

OpenText Functional Testing 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. The test object might be classified as a standard Windows dialog box (Dialog), a Web button (WebButton), or a Visual Basic scroll bar object (VbScrollBar), for example.

Next, the description properties for the test object are considered. For each test object class, there is a list of mandatory properties that are always learned. After learning these default property values, the rest of the objects on the page, dialog box, or other parent object are checked, to see whether this description is enough to uniquely identify the object. If not, assistive properties are added to the description, one by one, until a unique description is compiled. If no assistive properties are available, or if those available are not sufficient to create a unique description, a special ordinal identifier is added, such as the object's location on the page or in the source code, to create a unique description.

Back to top

Using 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 are learned about the object, a sub-set of these properties that can uniquely identify objects of that class, and a set of relevant operations that a test can perform on the object.

When you run a test or component, each object in your application is identified 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 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 test 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 Object Model Reference.

• 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 an object repository.

• 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