Browse Prior Art Database

Externalize UI control identificaiton and playback customizations in the context of application dynamism for GUI automated testing tools using Modelling

IP.com Disclosure Number: IPCOM000201559D
Publication Date: 2010-Nov-15
Document File: 2 page(s) / 41K

Publishing Venue

The IP.com Prior Art Database

Abstract

Many GUI test automation tools recognize the GUI objects in the application to allow better maintenance and readability of the automation scripts. An auotmation tool developer need to do a considerable amount of effort to make it recognize these controls. This is becoming difficult by the advent of many UI toolkits. In this article, we talk of some mechanisms that these tool writers can use to support these toolkits.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 2

Externalize UI control identificaiton and playback customizations in the context of application dynamism for GUI automated testing tools using Modelling

Automation test engineers will have to create automation test scripts to test their application. These test scripts can be well maintained or easily understood if the test scripts refer the GUI objects as it is in the application. For eg: A button of a Dojo[1] toolkit internally consist of some html elements like DIVs and SPANs. It will be easy for an automation test engineer to refer that button as a button in the scripts rather than individual html elements.

To make the automation tool recognize that object, the developers of the tool have to understand the properties of the UI element. In the above example, they have to find the distinctive properties of the html elements that make up the button and then the tool should be made to use these properties to recognize the UI objects. These are generally coded into the product. This makes it harder to allow a developer to add or change any of these recognition properties. Moreover, these UI toolkits are still evolving and it becomes difficult for the tool developer to keep up with that pace making the support of these UI toolkits more challenging.

Tools like IBM Rational Functional Tester[2] provide two mechanisms to allow end users to add the capability of adding the recognition of the UI objects. One way is to use the powerful find()[3] API, which finds objects in the application under test that match the given properties. Please refer the links[3] and [4] specified in the references for more information of this API. Using this approach, end users can work with the UI object level that will be comfortable to them without the support from the automation test tool for the particular toolkit. However, in this approach, they will not be able to use the recording capability that an automation test tool provides.

The second way is to create a proxy code which could provide the required information of the object to the tool and hence the recognition can happen.With IBM Rational Functional Tester proxy software development kit (SDK)[5], one can extend automated functional testing support for the application's user interface controls...