Automation Object Model (AOM) and how is it used

The QuickTest Professional (QTP) / Unified Functional Testing (UFT) Automation Object Model (AOM) is an application programming interface (API) designed to write programs that automate your QTP/UFT operations. The AOM provides objects, methods, and properties that enable you to control QTP/UFT from another application.

The AOM enables you to automate test management.

You can control virtually every QTP (UFT-GUI) feature and capability using the objects, methods and properties included in the Automation Object Model. Automation scripts make it easy to perform any QuickTest operation multiple times in multiple tests without having to open the QTP/UFT application, for example,

•You can write a script that modifies the test object description properties in the Object Identification dialog box and performs an update run on all tests in a specified file folder.

•After installing a new add-in, an automation script can associate this add-in to all relevant tests.

•You can write an automation script to run a selected batch of tests. For each test, you can retrieve the associated add-ins list. Then, if the necessary add-ins are not already loaded, you can close QTP/UFT, load the necessary add-ins, reopen QuickTest, and run the test.

•You can define your settings for a test in QTP/UFT, then click "Generate Script" in the Generate tab of the Test Settings dialog box to generate an automation script based on the current test settings. You can then apply those same settings automatically to multiple tests using the whole automation script or excerpts from the generated file.

Example: Create and run an automation program from Microsoft Visual Basic that loads the required add-ins for a test, starts QTP/UFT in visible or minimized mode, opens the test, configures settings that correspond to those in the Options, Test Settings, and Record and Run Settings dialog boxes, runs the test, and saves the test.

Creating automation programs:

The Properties tab of the Test Settings dialog box, the General tab of the Options dialog box, and the Object Identification dialog box each contain a "Generate Script" button. Clicking this button generates a automation script file (.vbs) containing the current settings from the corresponding dialog box.

You can run the generated script as is to open QTP/UFT with the exact configuration of the QTP/UFT application that generated the script, or you can copy and paste selected lines from the generated files into your own automation script.

Generating an automation script for QTP/UFT options:

1.Go to Tools -> Options.

2.Select the General tab.

3.Click <Generate Script>.

4.Save the script to the desired location.

5.Click <OK> to close the Options dialog.

Generating an automation script for test settings:

1.Go to Test -> Settings.

2.Select the Properties tab.

3.Click <Generate Script>.

4.Save the script to the desired location.

5.Click <OK> to close the Test Settings dialog.

Generating an automation script for object identification settings:

1.Go to Tools -> Object Identification.

2.Click <Generate Script>.

3.Save the script to the desired location.

4.Click <OK> to close the Object Identification dialog.

The QTP/UFT Automation Object Model Reference file is a help file that provides detailed descriptions, syntax information, and examples for the objects, methods, and properties in the QuickTest Automation Object Model.

When QTP/UFT is installed is possible to open the Automation Object Model Reference from:

•The QTP/UFT program folder (Start -> Programs -> QTP/UFT -> Documentation -> Automation Object Model Reference)

•The QTP/UFT Help menu (Help -> Automation Object Model Reference)

Troubleshooting and Limitations – Windows-based SAP

Creating and Running Testing Documents

· Running a test on HTML elements embedded in an SAP GUI for Windows application may result in an "Object is disabled" error. This may happen if the HTML control is not ready for the test run.

Workaround: Add a Sync statement such as SAPGuiSession.Sync or a Wait statement to the script in order to run the test successfully.

· By default, the recording and running of steps on HTML elements embedded in an SAP GUI for Windows application is performed using the UFT Web Add-in. In some cases, steps recorded using the Web Add-in are inserted into the script before SAP Add-in steps that use the SAP Scripting API.

Workaround: Use the option of recording HTML elements embedded in SAP GUI application using the SAP Scripting Interface. To do so, stop recording, select the Record HTML elements using SAPGui Scripting interface check box in the SAP pane of the Options dialog box (Tools > Options > GUI Testing tab > SAP > General node). Then close and reopen the test and then begin recording again.

· If inserting a call to an external action or a copy of an action, and that action includes an SAPGuiTable.Input, SAPGuiGrid.Input, or SAPGuiAPOGrid.Input statement, the corresponding input data sheet is not copied to the Data pane with the action.

Workaround: Insert and run Datatable.AddSheet and Datatable.ImportSheet statements to import the sheet referenced by the action’s Input method. Ensure that the name of the data sheet exactly matches the name specified in the corresponding Input statement.

· In the SAP Enterprise Portal environment, occasional synchronization problems may occur during the test run when alternating between SAP Web and SAP Windows environments.

Workaround: Add a WaitProperty or Wait statement between the Web steps and the Windows steps.

· UFT can connect to SAP Logon or SAP Logon Pad application for recording and running tests on SAP GUI for Windows sessions. If using both SAP Logon and SAP Logon Pad processes on the computer, UFT connects to the latest process that was launched.

· Use the SAP tab of the Record and Run Settings dialog box to instruct UFT to open SAP GUI for Windows application. Do not use the Windows Applications tab of the dialog box for this purpose.

Working with Windows-based SAP Controls

· Separate toolbar controls (ones that are not part of a grid or other object) are supported by the SapGuiToolbar test object (GuiComponentType is 202), and the Object Spy recognizes them because they are separate objects.

Note that tree controls do not have associated toolbars. Toolbars displayed on top of tree controls are recognized as separate toolbars, and are therefore supported as described above.

· Toolbars inside grid controls are supported by the SapGuiToolbar test object (GuiComponentType is 204). However, the Object Spy does not recognize these toolbars because they are part of the grid. If not possible to add these toolbars to the object repository using the Add to repository option from the Active Screen or the Add Objects option in the Object Repository window. To add these toolbars to the object repository, record on them.

· Toolbars inside other controls (such as a toolbar within a text area control) are not supported.

· Microsoft Office controls within the SAP window are not supported.

· If recording the step of pressing an F4 key, and that key press results in setting new values for multiple fields, a step is recorded only for the field from which the F4 key was pressed, and therefore, only that field will be populated during the run.

· The SAP Editor control is not supported.

· UFT fails to run steps on SAP tree nodes that contain the ";" character.

· UFT does not automatically record standard Windows dialog boxes used by the SAP GUI for Windows application (such as the Open File and Save As dialog boxes). This is because the SAP scripting API does not support these dialog boxes. This may also occur when using SAP GUI for Windows with GuiXT.

Workaround: Do one of the following:

o Change to Standard Windows Recording mode (select Standard Windows Recording from the Recording Modes drop-down in the Record toolbar) to record on these objects. (Make sure that it is switched to Standard Windows Recording mode before performing the operation that opens the standard Windows control in the SAP application.)

o Use low-level recording to record on these objects.

o Use programmatic descriptions to run steps on these objects.

Checkpoints, Output Values, and the Object Spy

o To ensure that the correct object properties are captured with the checkpoint, always record a step that results in communication with the server (such as pressing Enter) before inserting a checkpoint or output value.

o It cannot be used the Object Spy or created checkpoints for the controls listed below. However successfully can be recorded and run steps on them.

o Toolbar buttons in grid controls.

o Internal controls in tree or table objects.

(For example, a radio button in a table cell or a check box in a tree.)

· Creating checkpoints or using the Object Spy on an object that is located in a currently inactive SAP screen (for example, if the screen is behind an invoked dialog box) is not supported. However, it can be created checkpoints on status bar messages (displayed in an inactive window) using the Record status bar messages option (Tools > Options > GUI Testing tab > SAP node > Record status bar messages).

· When running old 6.20 tests on a 6.40 client, checkpoints on radio buttons, check boxes, edit boxes, or regular buttons may fail due to changes to tooltip property values for these objects in the 6.40 client.

· UFT can estimate the number of rows in a table control, but it cannot retrieve the exact number because only the table content that is visible on the client is actually available. Data from non-visible rows are stored only on the back-end server. Therefore, when inserting or modifying checkpoints for a table control object, the number of rows specified in the Define/Modify Row Range dialog box may not be accurate.

· Do not perform any operations on the SAP GUI window (such as changing the transaction state or navigating to another window) while UFT retrieves the data for a table checkpoint even if it seems to take a long time, as this may cause severe problems.

· When inserting a checkpoint on a table or grid from the Active Screen, the actual table must be open in the SAP Gui for Windows application to extract the correct information from the table or grid.

Test Objects, Methods, and Properties

· When using the SAPGuiTable Input method, check the scrolling mode of the current table. If parameterizing a table with a Data pane sheet that contains more rows in the sheet than are displayed in the table’s current view, UFT tries to scroll down the table while running the test, to insert more rows from the data sheet. UFT supports two ways of scrolling rows in tables—by pressing the Enter key, or by pressing the PageDown key. By default, the Add-in for SAP Solutions tries PageDown if needed. Is available possible to configure the required mode using the second argument of the Input method.

· Right-click operations are not supported for the SAPGuiTextArea object.

· Drag-and-drop operations in the SAP Gui for Windows application are disabled when UFT is open.

Using the Active Screen

· Active Screen images are based on captured screen bitmaps. Therefore, objects that are not visible in the SAP GUI for Windows view are not part of the Active Screen image. Objects cannot be added to the script from the Active Screen if they were not in the captured view.

· Drop-down menus are not captured in the Active Screen. Active Screen technology captures the data after the menu is closed and the menu item is selected.

· While recording, UFT captures one Active Screen image for several steps. UFT records steps only when the SAP GUI for Windows client sends information to the SAP back-end server. When this occurs, all steps that were performed between the previous communication and the current one are added to the script. The last screen that was sent to the server is captured by the Active Screen for all steps recorded during that communication.

· When recording on Web elements inside SAP GUI for Windows applications, HTML images are not captured.

· Adding objects to the object repository (using the View/Add Object option, or creating checkpoint or output value steps) from an Active Screen created from a step recorded on a Web element inside a SAP GUI for Windows application generates an incorrect object hierarchy in the object repository.

SAP Scripting API

· For security reasons, the SAP scripting API prevents the recording of passwords. When recording the operation of inserting a password in a password box, UFT records a Set statement using asterisks (****) as the method argument value.

Workaround: Do one of the following:

o Configure and enable the Auto-logon settings in the SAP tab of the Record and Run Settings dialog box.

o Insert a step using one of the SAPGuiUtil object’s AutoLogon methods.

o Record the password normally during the recording session. After the recording session, modify the password step to use the SetSecure method, and enter the encrypted password value or parameterize the value.

Enable Support for SAP GUI for Windows

Prerequisite: Make sure that SAP GUI Scripting is installed

When installing SAP GUI for Windows application, it must be selected with the SAP GUI Scripting installation option. If not selected when installing the SAP GUI for Windows application, it is essential that this option should be reinstalled and select this option before setting the other configuration options described in this section.

Note: SAP provides a range of security mechanisms that enable the administrator to limit the use of SAP GUI Scripting by system, by group, by user, and by scripting functionality. To test SAP GUI for Windows applications, it must be ensured that these security mechanisms are not activated.

Enable scripting on the SAP application (server-side)

a. Confirm that having the proper support package and kernel patch levels installed.

b. Enable scripting on the SAP application. (By default, scripting is disabled.) Doing this by entering the Maintain Profile Parameters window with administrative permissions and setting the sapgui/user_scripting profile parameter to TRUE on the application server.

§ To enable scripting for all users, set this parameter on all application servers.

§ To enable scripting for a specific group of users, set the parameter only on application servers with the appropriate access restriction settings.

Note: If connecting to a server on which scripting is disabled, an error message displays when trying to record on the SAP GUI for Windows application.

Enable scripting on the SAP application (client-side)

This can be done on the SAP client only if the SAP GUI Scripting option is installed. If this option is not installed, reinstall the SAP GUI for Windows application and be sure to select the SAP GUI Scripting check box.

Eliminate warning messages

By default, two warning messages will regularly receive when using UFT with an SAP GUI for Windows application:

o When UFT connects to the Scripting API, the following warning message is displayed: A script is trying to attach to the GUI.

o When UFT opens a new connection using the Scripting API, the following warning message is displayed: A script is opening a connection to system <system_name>.

It is recommended to disable these warning messages in the SAP GUI for Windows application when working with UFT.

Check the connection speed on the SAP server

Confirm that the Low speed connection option is NOT selected for the server to which are connecting before recording and running GUI tests.

This is because when logging on to SAP using the Low speed connection option to communicate with the server, the SAP server does not send sufficient information for UFT to properly record and run tests. (UFT displays an error message if the Low speed connection option is selected.)

Set F1 Help to use the modal dialog box mode

Confirm that the modal dialog box option is selected. This enables UFT to record the display of F1 Help in the tests. (The F1 Help in the SAP GUI for Windows application can be displayed using either the Performance Assistant or as a modal dialog box.)

Set F4 Help to use the dialog display mode

Confirm that client is set to load F4 Help screens in Dialog mode. (The SAP GUI for Windows application cannot load F4 Help screens in Control mode when using the SAP GUI Scripting API (Enable Scripting option.)

Note: This is a per-user setting. It must be set this option on each client that would be tested using the UFT Add-in for SAP Solutions. Alternatively, the SAP system administrator can change the system default.

Run Automation Scripts on a Remote Computer

1. Set DCOM Configuration Properties on the Remote Computer

UFT automation enables UFT to act as a COM automation server. Therefore, to run a UFT automation script on a remote computer, it must be ensured that the DCOM configuration properties for that computer give the proper permissions to launch and configure the UFT COM server.

The procedure below describes the steps needful to perform on the remote computer to enable automation script to run on that computer. Note that the DCOM Configuration Property the appearance and names of the dialog boxes and options mentioned here may vary depending on the computer’s operating system.

To enable automation scripts to access a Unified Functional Testing computer remotely:

2. On the computer where the automation script will run, select Start > Run. The Run dialog box opens.

3. Enter dcomcnfg and click OK. The Distributed COM Configuration Properties dialog box or the Component Services window opens (depending on operating system) and displays the list of COM applications available on the computer.

4. Select QuickTest Professional Automation from the DCOM Config list and open the Properties dialog box for the application. (Click the Properties button or right-click and select Properties, depending on the operating system.)

5. In the QuickTest Professional Automation Properties dialog box, click the Security tab.

6. In the launch permissions section, select the custom option and click Edit.

7. Use the Add and Remove options to select the network users or groups for which it will be allowed or denied permission to launch UFT via an automation script. When finished, click OK to save the settings.

8. Repeat steps e and f for the configuration permissions section to select the users or groups who can modify UFT configuration options via an automation script.

9. In the QuickTest Professional Automation Properties dialog box, click the Identity tab and select the interactive user option.

10. Click OK to save the QuickTest Professional Automation Properties settings.

11. Click OK to close the Distributed COM Configuration Properties dialog box or the Component Services window.

12. Create an Application Object on the Remote Computer

After setting the necessary DCOM Configuration settings for a remote computer, it can be specified that computer in the application creation script line in the automation script, for example, using the optional location argument in the VBScript CreateObject function.

In VBScript, do this by specifying the computer name as the optional location argument of the CreateObject function. The computer name should be the same as the computer name portion of a share name. For example, to run an automation script on a computer called MyServer, it could be written:

Dim qtApp

Set qtApp = CreateObject("QuickTest.Application", "MyServer")

Get the handle number (HWND) of a running application

In some scenarios, it’s required to use the application’s handle (HWND) information as part of the properties used for identification . This usually happens when there are not enough available, unique or steady enough properties to help with the exact object identification.

The HWND if available, might help.

The HWND is available for a reduced set of objects, for example: In Windows based applications, for the Window and dialog classes. The example below shows how to retrieve the handle number of a running application/process in memory.


‘ This will display the HWND of the Window with a title equal to "Untitled – Notepad"

Extern.Declare micHwnd, "FindWindow", "user32.dll", "FindWindowA", micString, micString

hwnd = Extern.FindWindow(vbNullString,"Untitled – Notepad")

msgbox hwnd

When Recovery Scenario will wait for the Exist method timeout

For long operations if, after calling like:


the error message box appears, then the associated pop-up window Recovery Scenario does not work immediately, but waits until the Exist method timeout, which slows down the test.

This scenario is by design, because in the test first is the Exist(20) and then the error is raised so the script will wait for the Exist method to finish and then the pop-up window Recovery Scenario will activate.

A way to overcome that situation is by using custom function that will overwrite the default Exist method. Below is the function:

Function exist1(obj,arg)

For i = 1 To arg

If Parameter("Param1")=1 Then

Exit For



End If


End Function

RegisterUserFunc "Window","Exist","exist1"

The script is based on a loop that will repeat same steps depending of the argument in the Exist method. The If statement is used in order to control when the loop can stop.

This is controlled via Input parameter “Param1” and the default value of the parameter is 0, the value is changed from the function called within the Recovery Scenario – so when the recovery scenario is activated that will change the value of the parameter to 1 and this will force the Exist function to stop and continue with the test.

Create and run dynamic script statements

How can the object’s properties used on a descriptive programming approach be on a single concatenated string without using Description objects? For example having the following scenario:

Dim var1

var1 = "Hello"

If Window(" text:=Untitled – Notepad" ,"index:=0").Exist(0) = false then

SystemUtil.Run "notepad"

End if

Window("text:=Untitled – Notepad" ,"index:=0").Activate

Window("text:=Untitled – Notepad" ,"index:=0").Type var1

How to make the ( "text:=Untitled – Notepad" ,"index:=0" ) including the coma symbol (,) part of a dynamic statement or string appropriate for descriptive programming, because if the string is set to a variable and provided to the descriptive programming statement it will fail.


aux = "<all the properties>"



With strings similar to:

aux = "text:=Untitled – Notepad" ,"index:=0" ‘This will fail on this line due to syntax general error


aux = "text:=Untitled – Notepad,index:=0" ‘This will fail when used against the directly Test Object

Descriptive Programming feature doesn’t support working several properties on a single string.

One alternative, is offered by the Microsoft VBScript Engine, with built-in methods that evaluate (EVAL function) or execute (EXECUTE or EXECUTEGLOBAL statement) run-time VBScript statements which allow performing dynamic creation of scripting statements and then either evaluate or execute them.

•MSDN Reference – Execute Statement –

•MSDN Reference – ExecuteGlobal Statement –

•MSDN Reference – Eval Function –

Considering that QuickTest Professional (QTP) / Unified Functional Testing (UFT – GUI Testing) are based on VBScript itself, a combination of the mentioned statements and QTP / UFT code could work same as any other VBScript statement however the combination isn’t quality assured by Hewlett-Packard therefore their functionality can’t be assured. Please review the provided references to analyze when each statement is appropriate to the scenario’s requirements.

Using the logic provided and combining all concepts, a possible conversion of the QTP code shown above could result as follow:

Note: The below script is provided "AS-IS" for example purposes only.

Execute "Dim var1"

Execute "var1 = " & chr(34) & "Hello" & chr(34)

If EVAL("Window(" & chr(34) & "text:=Untitled – Notepad" & chr(34) & "," & chr(34) & "index:=0" & chr(34) & ").Exist(0) = false") then

Execute "SystemUtil.Run " & chr(34) & "notepad" & chr(34)

End if

Execute "Window(" & chr(34) & "text:=Untitled – Notepad" & chr(34) & "," & chr(34) & "index:=0" & chr(34) & ").Activate"

Execute "Window(" & chr(34) & "text:=Untitled – Notepad" & chr(34) & "," & chr(34) & "index:=0" & chr(34) & ").Type var1"