All About the Apps
Showing results for 
Search instead for 
Do you mean 

Understanding the web test object model in HP Unified Functional Testing (UFT)

Anonymous_User1 ‎08-13-2013 10:00 AM - edited ‎11-03-2015 04:36 AM

This post was written by Motti Lanzkron, from the HP UFT R&D team.


The meaning of the following script line should be obvious to anyone using HP Unified Functional Testing (UFT):




It says “Click link ‘L’ on page ‘P’ of the browser ‘B’.  But is this line really that simple? Let’s drill down into each part of this step in order to understand why UFT’s designers chose to represent objects in this way.


Objectives of the object model

When deciding how to represent an object in an Application Under Test (AUT), we took several considerations into account:


  • Robustness - A test should fail only if there is something wrong with the functionality of the AUT. Changes with no functional effects (e.g. font change) should not affect the test outcome.
  • Maintainability- If the AUT changes in a way that affects the test, it should be easy to update the test in order to accommodate the changes in the AUT. This consideration raises a number of other considerations:
    • Readability -It should be obvious what a test does by reading it.  It’s not easy to maintain a test if you can’t tell what it’s doing.
    • Organization - Objects in the object repository should be organized in a logical manner so that it will be easy to find an object when looking for it. 


What is a Browser?

Today, a Browser is a tab. Before tabs were introduced, a browser was a software application used to access the Web.  The object hierarchy was very simple:




With the advent of tabbed browsers, we had to decide how Quick Test Pro (QTP) should represent a tab. The naïve answer would be to just add another level to the object hierarchy:




Unfortunately, this hierarchy has the following drawbacks:


  • Tests created on a tabbed browser will not work with a non-tabbed browser (even if only one tab is ever used)
  • Placing the tab under a specific browser is rarely a functional  issue, since a web page should be rendered identically whether it is created in a separate top-level window or as another tab. So putting the tab in the hierarchy would break the robustness objective we discussed at the beginning of this article.

The drawbacks to having the Browser object represent a specific tab were mostly esthetic, but it was still the best option.


Because there may be some functional significance to having separate tabs in the same browser, we added the OpenNewtab, IsSiblingTab and CloseAllTab methods to the Browser test object.( I’d like to know if anyone actually uses them… please leave us a comment below to let us know if you do.)


Nowadays, tabs can be ‘torn off’ from one browser instance and onto another.  So it seems clear that we made the correct decision.


Note: A minor compatibility issue that arose from this was that the window handle (HWND) for the Browser no longer refers to the top-level window.  Creating a regular Window test object with this HWND won’t allow you to call the Minimize or Move methods, or call any other method which is available in Window but not in Browser.


A Browser’s ‘Description’

The object identification dialog doesn’t list properties for a browser’s description. This means that if more than one browser is open, the description will use an ordinal identifier, such as creation time, as seen in the example below:



There isn’t actually a generic way to distinguish between browsers. Let’s say you open a browser on your homepage, navigate to your mail account to see what’s new, hang out in Facebook, and then navigate to your business application and start running tests.


If UFT used title as a default description property, the object repository would have many browser test objects – one for the homepage, one for the email page, one for Facebook, etc. - and it would be very hard to find the correct browser.  This breaks the organization principle discussed earlier.


However, if there is a consistent pattern to how you use your browsers, you can create a more robust description by using the opentitle, openurl  or openedbytestingtool  properties. For example, this screenshot shows how to use opentitle for all new browser objects, in the Object Identification dialog:



This example shows how to use openurl for a specific browser:



The following line of script shows how you can use descriptive programming to refresh a browser by its openurl property:




The Page object represents the top-level HTML document displayed in the current Browser. Since there can be only one top-level HTML document, each Browser will have only one page. So why do we need another layer in the hierarchy? Why not just make the Browser object represent the top-level HTML document as well as the tab window?


The answer is to preserve the test maintainability objective we described earlier.  We determined that we don’t want to create a new Browser test object whenever the HTML being displayed changes, as we would potentially have tests with many dozens (hundreds?) of test objects under the Browser. In order to prevent this, we created an artificial  split so that the controls that appear under the same Page test object are logically grouped together.


So if you have a login page and an accounts page you can find the username edit field without sifting through all the test objects that appear in the accounts page, because the appropriate controls are grouped logically.


Tip: You can modify the amount of page test objects created in UFT in Options > Web > Page/Frame Options.



A Frame object represents an HTML document under the main object (inside a FRAMESET or IFRAME.  There’s nothing particularly interesting about this, so let’s move on…



Prior to UFT 12.50, all the web test objects (Link, WebButton, etc.) under the Frame (or Page) object are siblings. UFT 12.50 lets you add further levels of hierarchy to help you organize the objects (see this post for details). This isn’t how they appear in the actual HTML though - the actual elements in an HTML document are typically nested in a deep hierarchy.  Here's an example of a web hierarchy as viewed with Internet Explorer's developer tools: 



Not only would adding all parent elements to the test make the test unreadable, it would also mean that the test will fail for every minor change in the HTML, and fail to meet our readability and robustness objectives respectively.


Although UFT flattens out the hierarchy when recording or learning an object, you can still create a hierarchy by yourself. If you drag a WebCheckBox under a WebElement in the Object Repository (or just nest them using descriptive programming), UFT will only look for the checkbox under its parent test object. This means that the description you give for the WebCheckBox only has to achieve uniqueness relative to its container, which can simplify things immensely for applications that contain many similar elements (such as the Add to cart link on an online store). 


For example, the following example shows how the HP Slate 7’s ‘Add to cart’ link on HP’s online store appears in the Object Repository Manager.  It is directly underneath the ‘Slate | HP Official Store’ page (other test objects were removed for clarity in the screenshot):




The ‘Add to cart’ link appears many times on the page, since there are many items which can be purchased.  This specific link is the third instance (ie. having an index of 2) on the page.  This makes the description dependant on the order of elements in the HTML, and violates the robustness principle.


We can simplify the locating of the object by adding the context element of HP Slate 7 to the hierarchy.  In this way, UFT only needs to locate the HP Slate 7, and then find the only ‘Add to cart’ link in the context of the HP Slate 7.  Since there’s only one link, we no longer need the ordinal identifier, as seen in the example below:




By default, UFT uses the html tag property as part of the description of all web test objects, even those for which it’s pretty obvious what the tag name will be. 




The reason for this is that in order to identify a test object UFT must check all the elements on the page to see whether they fit the description.  This can be a slow process for big pages with thousands of elements.  Fortunately, browsers support getting the elements of a specific tag, and if UFT can use this function it can perform the search on far fewer elements. Because the html tag is part of the description by default, you don’t usually have to think about it.  If you change an object’s description (in the object repository or in the object identification dialog) you should keep this in mind.  If you use descriptive programming and you’re seeing that performance is a bit slow, consider adding the html tag to the description.


Note to WebExtensibility authors:  Consider adding the html tag property to the description of new types.


In Conclusion

I hope that after reading this post you have a better understanding of why UFT represents controls the way it does (at least when using the Web addin). Some things that might have seemed arbitrary should now make some sense. Hopefully you even picked up a tip or two that will help you improve your web tests!


You can download HP Unified Functional Testing here.



If there are still things that still make you cry out, “What WERE they thinking?”, please tell us about it in the comment box below and perhaps it will give us ideas for future blog posts.



Thanks to Motti for providing this article!

About the Author


on ‎06-23-2015 12:40 PM

I use all broweser methods . I use one to colse all open browsers . It is nice to have functionalities to perform actions based on the requirement.

I wish we Hp UFT can support java langaugae. I have used RFT and it was easy to write functions in java to execute actipons based on manual test scripts.

on ‎07-02-2015 06:17 AM

Hi VijayIndy,


HP is releasing a new Functional Testing product very soon that supports Java.  It's called LeanFT - read the announcement or this blog post to learn more about the functionality it will provide.



on ‎05-20-2016 03:44 AM


I have a test suite which developed in IE 9. In which we had all the popup windows and sub windows. Recently we got a requirement to execute our test suite in Windows 10, Edge browser. Edge is not supporting any kind of popup windows, all of them will come as a new browser. 

Due to this we have to update our entire automation suite to accomodate this object hierarchy changes. Is there any easy way to accomodate these changes instead of updating the scripts line by line.

Note: We are completely into Descriptive programming and objects are getting created within the functions itself.

Thanks in advance


27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all