This post is not about performance testing with TestComplete.
This post is about tweaking TestComplete configuration parameters to make it less “greedy” on resources, especially CPU, while performing run-time recognition of a complex GUI.
This will mostly be useful to experienced test automation engineers who create their own scripts without record/playback and hard-coded GUI name mapping.

When TestComplete 9 was released, many (including me), complained about dramatic performance degradation in real-time GUI recognition mechanism (using FindChild family of methods). Though some parts of recognition chain started working actually faster, the first step – acquiring process handle – was taking very long time. Remarkably, SmartBear’s Support Team responded very quickly and initiated its own investigation based on the code examples provided. They even quickly released a patch. However, the solution is a complex treatment. Automation engineers need to know of the mechanics of the new GUI recognition engine and settings that tweak it.

How It Works*

* Parts of it I learnt myself through years of working with TestComplete, but I’d like to give a main credit to TestComplete support engineers who shared insights of the inner mechanics.

Recognition through properties

The tool does not actually “see” picture on the screen. It uses specified (pre-captured hard-coded or dynamically calculated) expected values of the properties of GUI-representing objects to find a match. Once an object with matching properties is found, the tool gets a handle of it, but still does not “see” any visual representation.

Parent-Child hierarchy

GUI representation follows a “parent – child” hierarchy. Window contains a button, button contains a label. A parent can have many children, but each child has only one parent.

GUI recognition properties have to be a unique set in the context of the parent if you want recognition to be reliable.

Depth-First Search

To find objects with matching properties TestComplete uses depth-first search algorithm which ensures quick exhaustive search down the chain of parents but makes the search longer if the target object belongs to parent chains further in the hierarchy.

Handling objects

Although software applications are unique on their own, presentation layer components (windows, buttons, lists, text boxes) are essentially the same and come in a finite small number. Yet the challenge of an automation tool is to recognize a particular class implementing the GUI element in order to get a hold of its properties and methods.

On the abstract, wrapping class for all the buttons is a single object, but in the underlying the wrapper must support button classes implemented in different libraries, for example, Dot Net and Delphi. For that purpose, TestComplete has “extensions”, loading of which is controlled.

What You Can Do*

* Use combination of these methods to find a setup best meeting your needs.

Disable unused extensions

Go to “File \ Install Extensions” and revisit the list – its pretty big. If you for sure don’t work with certain application types then disable loading of extensions for them.

Limit search depth

Whenever applicable, limit the depth of search. To see the difference in performance, you can try the following example:

  Dim PropNames, PropValues, IEProcess

  PropNames = Array("processname", "index")
  PropValues = Array("iexplore", 1)

  Set IEProcess = Sys.FindChild(PropNames, PropValues, 100, True)

  PropNames = Array("processname", "index")
  PropValues = Array("iexplore", 1)

  Set IEProcess = Sys.FindChild(PropNames, PropValues, 1, True)

Use Process Filter

You can instruct TestComplete to “ignore” all but specified processes. Go to “Tools\ Current Project Properties” -> “Open Applications\ Process Filter”.

The effect of this setting is that TestComplete doesn’t have to scan GUI of other processes and doesn’t have to load wrappers for all kinds of objects.

This setting might give you the best performance win; however, it can only be switched manually, which is inconvenient while running a batch that tests application in different browsers.