Identifying objects using MSAA

Hi,

Recently I benefited from MSAA support in TestComplete and like to share with you the same.

The problem came up when I intended to automate few of the UI (windows application) controls. I tried this in a system where I have TestComplete 7.5 installed on Windows XP.

To be clearer on the issue, TestComplete shows the entire application as a single window (inside its object browser tree) without any child windows/controls. When I try to record the actions on the controls like text box and radio button, all were recorded as actions with respect to window co-ordinates and not with actual controls. Surely script will be having issues when relied on these co-ordinate related actions.

I am clear that TestComplete is not recognized or the application’s controls were not open enough to automate them.

This intuited to try MSAA mechanism and as expected, succeeded in automating all the controls on the above mentioned application with the help of exact object identification.

My questions on this issue:

1. What is MSAA?
2. How the TestComplete able to identify individual controls after configuring MSAA?
3. Why this feature is not available by default?

What is MSAA?

According to Wikipedia “Microsoft Active Accessibility (MSAA) is an API for user interface accessibility, designed to help Assistive Technology (AT) products interact with standard and custom user interface (UI) elements of an application (or the operating system), as well as to access, identify, and manipulate an application’s UI elements”.

Simply we can access UI controls and its properties when interfaced through MSAA mechanism.

TestComplete uses this technology to get access to UI control’s properties and methods which are not readily exposed. This is done with help of AUT window’s class name.  MSAA configuration can be done in the project properties as below in TestComplete,

1. Select ‘Project properties -> Open applications -> MSAA’.
2. In the ‘list of accepted windows’ list view, add new item and specify the windows class name whose child controls are not recognized.
3. Save the changes.

How the TestComplete able to identify individual controls after configuring MSAA?

Basically when above configuration is done, TestComplete will query for the UI control details using MSAA mechanism and populate them in the object browser.

And remember, TestComplete will able to identify the controls only if the object/window of AUT implements the IAccessible interface.

Why this feature is not available by default?

Just to avoid complexity, this feature is not available by default. If it is enabled then TestComplete object browser will be loaded with lot of windows and controls which we may not be using always which in turn affects system/execution performance. I guess this will be the reason behind limiting the MSAA configuration to projects and not even project suites.

To summarize, if you face any problem where any of the AUT UI controls were not recognized in TestComplete try to check the below items:

1. AUT is a windows application and TestComplete identifies only main window which has child windows/controls.
2. In the object tree, the last identified window has a wndclass property.
3. The Application/Window object implemented IAccessible interface.

Then MSAA should help you in automating these controls…

MSAA updates

MSAA has a new partner called UIA (Microsoft User Interface Automation) which is more advanced in querying the properties and methods.

According to Wikipedia, “UIA is similar to MSAA in that it provides a means for exposing and collecting information about user interface elements and controls to support user interface accessibility and software test automation. However, UIA is a newer technology that provides a much richer object model than MSAA, and is compatible with both Win32 and the .NET Framework. UIA is designed so that it can be supported across platforms other than Microsoft Windows. For controls and frameworks written from scratch, UIA is recommended today. While MSAA is handy for relatively simple controls, the technology doesn’t support the complexity of modern user interfaces.”

For more details on working with TestComplete and MSAA follow the link — http://smartbear.com/support/viewarticle/11501/

References: Wikipedia.org

Thanks & Regards,

Giri Prasad

Believe!!! There are 101 ways to automate…

Data handling support in TestComplete – Part 3

Using Data Storages:

When I say “Data storages” here, it’s the data sources like Excel, CSV, ADO table or simple text files which lie outside Test complete. Yes. We can have our data (test data/ expected data) independent of our Test complete projects. Also Test Complete supports good interfaces to get/set these data stored else where in the system.

Mostly when we need to build a robust Test automation framework or asking for a data driven approach, the answer might be just separate the data and the code (scripts) which uses it.

Few advantages when choosing this approach are:

1. Dependability is less which eases the development and upgrades.
2. Since data is kept outside of any automation scripts/tools, even novice users who have minimum implementation knowledge can manipulate the data easily.
3. Just pile up the data as new test cases are written for same implementation.

Test Complete provides DDT object which has methods and properties to connect to a data source, read data, assign back the results and iterate through the collection or rows and columns.

I have written a post https://automate101.wordpress.com/2010/07/27/data-driven-testing-with-testcomplete-part-2/ which explains the DDT object and sample scripts to fetch data from data sources.

a) Scope

Since these data sources lie outside TestComplete we can access them in from of the scripts and even across multiple projects. For example, single excel workbook can hold data in separate worksheets for different projects.

b) Easy Accessible:

The previously discussed (Project variables/Stores) data storage options require the help of Test Complete editor to view or edit the data stores in them. But this option doesn’t require Test Complete to be opened. Provides easy viewable options if excel or ADO table are used. Supports multiple connections to the data source and have manipulation of data inside scripts can be done with few statements

c) Adapting to changes

The scripts will be robust enough until we are modifying the schema of the data storages. Any point of time we can change the data source itself ie., data from excel sheets can be migrated to Ado tables with just minor changes in the driver scripts. Because the DDT object provides similar approach (methods and properties) for all the supported data storages.

Using Storages Object

Using “Storages” object we can manipulate data from special or complex storages like INI, XML, BINARY and REGISTRY files. As you know we cannot directly access these files like text files and require good methods for the same.

Our implementation may have requirements to store data using these file types. Also more complex, system/configuration related data or hierarchical data can only be stored in these types of files. If you are committed to use these data sources, Test Complete supports you with object called “Storages”. This is an add-on support and you need to make sure whether your tool has it. Just navigate to “File -> Install extension” dialog and verify where it is checked as shown below.

 

Storages add-on as extension in TestComplete

To use this feature in Test Complete, store the data in any of the formats like INI, XML, BINARY and REGISTRY and save the file. Inside the scripts use Storages object and its methods to manipulate data. Below you can find a sample JScript to read data from an INI file and displays them in test log.

function ReadINI()
{
 var objSection = Storages.INI("D:\\Employee.ini");
 Log.Message("Total Sections : " + objSection.SectionCount);
 var section;
 for(var idx=0; idx
 {
 section = objSection.GetSubSectionByIndex(idx);

 Log.Message("Section : " + section.Name + " has :-");

 for(var idy=0; idy
 {
 Log.Message("*** " + section.GetOptionName(idy) + " = " + section.GetOptionByIndex(idy));
 }
 }
}

Similarly using corresponding drivers we can use XML, Registry and Binary files.

a) Scope

Storages object cannot be used inside Script Extensions. Inside test complete you can access this object anywhere in the script. Also you can open the file, store them in “FileSection” object and pass as parameter to different functions.

b) Easy Accessible:

One advantage of using this object is we can manipulate complex and hierarchical file structures. Also the “FileSection” and “Section” objects gets the file similar to the physical view. For example the when we open a registry file, it returns as sections which in turn has options, thus enabling us to view the exact view of the file data.

c) Adapting to changes

The files can be stored independent of project. The Storages object uses similar kind of methods for all the 4 supported types. These two features helps us to change data and its corresponding code independent to each other.

Hope there are 101 ways to Automate !!!

Thanks & Regards,

Giri Prasad

Data handling support in TestComplete – Part 2

2. Stores:

In TestComplete each project can have its own ‘Stores’ test item. It is a collection of various file types which can be accessed by project scripts. It can be directly added to any project by simply right clicking the <Project_Name> -> Add -> New Item -> Stores.

Stores_as_project_item

The advantage of having such collection is, it gives access to complete repository of required data in various data formats. Mostly it can be used for verification of expected results and data source for across AUT.

The stores collections can accommodate data in below formats,

• DBTables – To store tables and queries.
• Files – To store Text or Data files of any type.
• Objects – Used to store object properties in XML format
• Regions – Image formats like BMP, JPEG, PNG, TIFF or GIF.
• Tables – To store AUT control’s data that display information in a tabular form.
• WebTesting – Web page controls/items used to compare and verify web pages.
• XML – To store xml documents.

When you record a scenario and need verification point to test, you will recognize/compare object/properties. These items are in turn added to Stores object by the recorder while saving the scripts. Generally when you use ‘Checkpoints’ in your script, the expected data/files will be stored under stores collection.

Manually also we can add items to the collection thru right clicking the stores item, select ‘New Item/Existing Item’ option and browse for suitable item/file.

a) Scope:

‘Global’ to its project. The stores items are saved inside the project itself by default. We can also alter the location to store in different path. But this makes some dependability while moving the projects. Both the script units and keyword tests has access to this collection.

b) Easy Accessible:

The stores collection is accessible using object called ‘Stores’ inside ‘ScriptExtensions’ and using objects – DBTables, Files, Objects, Regions, Tables, WebTesting, XML inside scripts. Through these object we can refer its corresponding methods which helps us greatly in manipulation our data during execution.

The objects – Files, Objects, Regions and XML has general methods to add files, compare them, check for existence, get them by name/index and delete them. The remaining objects – DBTables, Tables, WebTesting have methods based on the instances in them.

These objects/files are independent of script languages and TestComplete supports all the methods and properties to access these files in any of its five scripting languages supported.

c) Adapting to changes:

The items/collections present in the project can be added/ updated/ deleted any time by with fewer mouse click actions. TestComplete provides easy wizard like forms to add/update the items and well informed UI to view the data in the files. For example let us see how the data in XML file is shown in TestComplete.

XMLViewer_in_Stores

Just like the screen shot it displays our files (expected, checkpoints) in well understanding manner and provides options to update the files. You can simply switch over to the ‘Source’ tab here to edit the XML file and save to update it. Similarly the many of the ‘Stores’ files can be easily updated right inside test complete.

One more advantage in using Stores is we can update the stores object/files in one click. If the AUT has gone for any change and the expected results/checkpoints need to be updated to the latest version of the product, simply we can ask TestComplete to update the object instead of checking/comparing it. So when the tests run, TestComplete will update its stored objects based on the mapping in the Stores. Use the Tools -> Options dialog to configure the compare/update setup as below in the figure.

Update_Stores_Collections

To be continued..

Hope there are 101 ways to Automate !!!

Thanks & Regards,

Giri Prasad

Data handling support in TestComplete – Part 1

Hi All,

In testing/automation we deal with different types of ‘Data’ say Test data, Expected data, Configuration data and execution data, etc,. The dependability on test data changes based on the framework chosen for automating the AUT. Data Driven Testing has more dependability with the Test data and Expected data than other approaches. Overall we need a good mechanism to store, configure, and use them in to the scripts to effective automation.

So when I ask data handling for Automation, I might get answers from 2 categories.

1. Using scripting language
2. Using Automation tool

Since most of the script languages have a programmatic approach (Initialize, Use and Destroy) in handling the data and mostly they are not persistent across executions, we will move and concentrate to second option and get clarify on the support provided from tool perspective.

We must understand that data handling plays a key role in determining the success of a test automation implementation before moving to handle it. A complete analysis of our data handing requirement must be done before choosing an approach.

TestComplete supports DDT and provides various options to store data through it. Some of them are,

1. ProjectSuite/Project variables
2. Stores
3. Using Data Storages
4. Storages Object

I am going to consider the following criteria for each facility:

a.      Scope

b.      Easy accessible

c.      Adapting to change

1. Project Suite / Project variables:

The project suite and project items created using the TestComplete was designed to store data in them apart from project related properties. To use it, we have a choice of few available data types (String, Integer, Double, Boolean, Object, Table) and give a meaningful variable name to it. From the scope perspective, these Project suite/Project variables can be classified as ‘Persistent’ and ‘Temporary’.

Simply, Persistent variables hold their value between the test executions whereas Temporary variables will not. And Persistent variables have some advantage over distributed automation where we can have separate value for each remote host thru ‘Local value’. Also when your script is accessing and updating both persistent and temporary variables, in the next execution persistent variable will have the updated one whereas the temporary will hold its default value.

The properties of these variables are,

Name – Name of the variable (should follow basic naming convention).

Type – Any one data type to choose from – [String, Integer, Double, Boolean]. The temporary variables can also be of type Object and Table

Default value – The default value if any for the variable.

Local value – This is available only for persistent variables.  Local value to be used for remote host on distributed execution

Description – Summary to explain the variable usage

Scope:

Global to the declared item. As per the name says the project suite variables can be accessed across the project inside the suite and project variables are accessible across the scripts inside the project

Adapting to change:

Yes. We can modify these variables anytime during the execution inside the scripts and always available to change. Mostly these can be used where we need to same set of information across script unit and where value set by one script need to be accessed by another.

Easy accessible:

Syntax:

Project.Variables.<variable name>

ProjectSuite.Variables.<variable name>

As mentioned above can be accessed anywhere to ‘set’ or to ‘get’ the values. The TestComplete will give you code snippets for the defined variables.

Using Stores and data sources will be continued in next post…

Hope there are 101 ways to Automate !!!

Thanks & Regards,

Giri Prasad

Understanding Script Garbage Collection

In the course of test automation programming we declare many variables/array/objects and use them throughout the script (test) execution. So my questions are,

1. Is there any way to keep track of what is declared/assigned and released (variables)?
2. Is this depends on language/ platform?
3. If so, who is responsible for it – Automation Tool?, Host Environment?, or need to handle with code itself.
4. What is Garbage Collection (GC) and how it works?

It is completely true that scripting GC still remains an unrevealed area when compared to programming/development languages like Java and .NET languages. Any ‘Objections’ here?

The answer to the first question was, YES. There is a way to track all the variables, arrays and object or whatever you defined in the scripts.

This tracking may be done based on the few properties like,

1. Scope of the variable
2. Type of the variable
3. Validity of the variable

For example, we don’t want a variable to exist outside a function which is declared as private to it (or) a variable/object which is explicitly given to GC for clearing. For me simple way is, checking the validity of it.  Either by its existence property or equating to a null or undefined (VBScript / Jscript)

Dependency

Yes. It depends on the language you are using. Few languages like C, C++ doesn’t have its own GC mechanism. We need to allocate and release it. Whereas Jscript and Vbscript has…  More down in the post…

Who is responsible?

Recently when I ask the same question to an AutomatedQA customer agent (I was using TestComplete automation tool and Jscript), the answer was “TestComplete doesn’t have any Garbage Collection mechanism and relies on Windows Script Host (WSH) in Windows environment.” [Do you know any Automation tool having its own garbage collection mechanism? please comment…]

Now how the WSH actually does it?

GC is done in WSH based on the language used… For example ‘JScript GC’ is different from ‘VBScript GC’.

JScript engine will call the GC based on the following parameters,

• The number of variable allocations in the script
• The number of literal values that are used in the script
• The total size of the string values that are allocated in the script

When thresholds for these values are exceeded, garbage collection occurs.

JScript uses a non-generational mark-and-sweep garbage collector. It works like this:

• Every variable which is “in scope” is called a “scavenger”. A scavenger may refer to a number, an object, a string, whatever. It maintains a list of scavengers — variables are moved on to the scav list when they come into scope and off the scav list when they go out of scope.
• Every now and then the garbage collector runs. First it puts a “mark” on every object, variable, string, etc – all the memory tracked by the GC. (JScript uses the VARIANT data structure internally and there are plenty of extra unused bits in that structure, so we just set one of them.)
• Second, it clears the mark on the scavengers and the transitive closure of scavenger references. So if a scavenger object references a nonscavenger object then we clear the bits on the nonscavenger, and on everything that it refers to.
• At this point we know that all the memory still marked is allocated memory which cannot be reached by any path from any in-scope variable. All of those objects are instructed to tear themselves down, which destroys any circular references.

More on how VBScript has different GC,

VBScript, on the other hand, has a much simpler stack-based garbage collector. Scavengers are added to a stack when they come into scope, removed when they go out of scope, and any time an object is discarded it is immediately freed.

You might wonder why we didn’t put a mark-and-sweep GC into VBScript. There are two reasons. First, VBScript did not have classes until version 5, but JScript had objects from day one; VBScript did not need a complex GC because there was no way to get circular references in the first place! Second, VBScript is supposed to be like VB6 where possible, and VB6 does not have a mark-n-sweep collector either.

The VBScript approach pretty much has the opposite pros and cons. It is fast, simple and predictable, but circular references of VBScript objects are not broken until the engine itself is shut down.

In spite of all these actions we can call the GC (through code) to collect anytime using the Jscript method – CollectGarbage() (No equivalent in VBScript L) which will force the GC to run and collect the garbage objects.

(As got from Eric Lippert’s blog)

Here is the question on our coding practices —

We have a practice of tear down/Un-assigning a used variable to ‘Nothing’ (in VBScript) or ‘undefined’/’null’ (in Jscript). Does these statements really needed?

Can I say these are not needed when some one is taking responsibility of looking the GC operation and clearing when needed?

It may be one of the best practices to code it, but need a critical examination to use.

1. Use when any expensive object is declared. Example:- File pointers, ADO instances, etc.,
2. Use for globally declared objects. Since it will have valid existence throughout the execution, can be explicitly put down.
3. Use when you suspect the declared object may lead to circular references and may not be cleared properly even though GC can handle it. Need to be careful here in the order of discarding the object.

I welcome your experiences and opinions on the topic which can reveal new cases.

References:

http://support.microsoft.com/kb/942840

http://blogs.msdn.com/b/ericlippert/archive/2004/04/28/when-are-you-required-to-set-objects-to-nothing.aspx

Hope there are 101 ways to automate…

Thanks & Regards,

Giri Prasad