- 1 Introduction
- 2 Installation
- 3 Command Overview
- 4 Tips & Tricks
- 5 Examples
AutoIt is a freeware BASIC-like scripting language designed for automating the Windows GUI and general scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys).
AutoIt was initially designed for PC "roll out" situations to reliably automate and configure thousands of PCs. Over time it has become a powerful language that supports complex expressions, user functions, loops and everything else that veteran scripters would expect.
The expecco AutoIt plugin wraps some of those low level functions into easier to use building blocks. This makes it a powerful combination:
- allows for non-programmers to create scripts which remote-control other applications
- integrates smoothly with web-application tests (for example, to automate native-window dialog boxes which pop up from web applications - especially: certificate and single-sign on queries)
- integrates smoothly with database, telecom or automation scenarios.
No attempt was made to support AutoIt's scripting facilities. These are better implemented using expecco's own mechanisms for looping, alternatives, assertions etc.
The AutoIt package itself is not part of the expecco installation package. It must be downloaded separately from the AutoIt web page (https://www.autoitscript.com/site/autoit/downloads).
Download the AutoIt package and install it with its default settings.
Typically, the software is installed in "
The only component needed by expecco is the AutoIt dll, which should be in "
If this is in your path (try "set" on the "cmd.com" command line), you are ready to use it. Otherwise, either change the path setting, or go to the expecco dll-mapping settings, and add a corresponding entry to the mapping table:
Notice that the low-level interface to the AutoIt library is implemented (in the AutoIt library) by DLL-calling action blocks. There, only the name of the library (not its absolute path) is defined. This avoids the need to change the library when the dll is located at a different location. Also notice, that the DLL-mapping is stored in the user settings, not in the project itself.
Be aware, that not all functions of the library are present in the expecco action block library. For many, corresponding action blocks are already present in the standard library (math, timing, file access etc.).
Only the window handling actions are present and each is implemented as a DLL-calling block. For example, the "WinActivate" block (as described below) is:
If any function is missing, take those as a guide on how to add your own AutoIt calling action block.
Connect / Disconnect
- AutoIt [ Connect ]
Connects to the remote AutoIt server or local dll and returns a handle to the interface
- AutoIt [ Disconnect ]
Closes the connection to the interface
Window Specific Functions
- AutoIt [ Activate ]
Activates (gives focus to) a window.
- AutoIt [ Active ]
Checks to see if a specified window exists and is currently active.
- AutoIt [ Close ]
Closes a window.
- AutoIt [ Exists ]
Checks to see if a specified window exists.
- AutoIt [ SetState ]
Shows, hides, minimizes, maximizes, or restores a window.
- AutoIt [ MinimizeAll ]
Minimizes all windows.
- AutoIt [ MinimizeAllUndo ]
Undoes a previous WinMinimizeAll function.
- AutoIt [ Wait ]
Pauses execution of the script until the requested window exists.
- AutoIt [ WaitActive ]
Pauses execution of the script until the requested window is active.
- AutoIt [ WaitClose ]
Pauses execution of the script until the requested window does not exist.
- AutoIt [ MenuSelectItem ]
Selects a specific menu item.
Window Control Specific Functions
- AutoIt [ Click ]
Sends a mouse click command to a given control.
- AutoIt [ Send ]
Sends a string as keyboard input to a given control.
- AutoIt [ GetText ]
Retrieves text from a control.
- AutoIt [ SetText ]
Sets text of a control.
- AutoIt [ Option ]
Changes the operation of various AutoIt functions/parameters.
- AutoIt [ Run ]
Runs an external program.
Tips & Tricks
Local vs. Remote Applications
You can access and control both local and remote applications via this plugin. When interfacing to a local application, expecco uses the AutoIt dll to directly interact with the tested application. To control remote applications, the AutoIt proxy "autoitRemoteServer.com" must be up and running on that host(s). This proxy implements a message-passing interface via a socket interface to forward AutoIt commands from the expecco-host to the application's host. The proxy must be started on the target host with:
autoitRemoteServer.com hostnameOrIpAddress portNumber
Notice that the "autoitRemoteServer.com" possibly opens a security leak, as it allows for external programs to connect and control/manipulate the windows on the screen. Therefore, it is recommended to restrict the access and make sure that only the test-system on which expecco runs gains access to it. The parameter "hostnameOrIpAddress" restricts remote access to that single host. Use "localhost" or "127.0.0.0" if you want to deny any external access, and only allow the expecco which runs on the same host to connect to it. Otherwise specify your own hostname or IP address.
The "portNumber" parameter is optional. The default is 9998.
So, if the application to be tested executes on "hostA", and expecco on "hostE", open a command interface on "hostA" and enter "
autoitRemoteServer.com hostE". Use "hostA" as the destination-parameter of the connect block.
If you use "localhost" as destination parameter to the connect block, the AutoIt local interface (without remote proxy) will be used. In that case no autoitRemoteServer needs to be run on the local host. Otherwise the connect block try to connect to autoitRemoteServer on the specified host.
Please note, that the autoitRemoteServer may provide only a reduced set of the AutoIt functions. Please refer to the Interface Plugin Library for more information.
Applications and Windows Versions
Notice that many Microsoft applications may show different control ids in their components in different Windows versions and/or language settings. For example, the "
calculator.exe" application looks similar in a German language setting to its English counterpart. However, the control keys are different. It is important to keep this in mind and prepare the test suite, to remain portable across different and also future Windows versions.
A good strategy is to build an application specific control key library or specify the control keys in an environment. This can then be modified, or loaded depending on the OS version. We highly recommend the use of attachment files to keep that information separate from the actual test sequence.
Waiting for an Application's Window to Appear
The following little network waits for a window (given by its window-title) to appear. It does this in an endless loop, so the caller must take care to shut it down after a while. Here is a "Wait for Window to Appear" implementation:
Confirming a Password Dialog in a Web-Browser Session
Using the previous block, we can automatically answer a password request, which might pop up when a web-application session is started in selenium. The following example is especially interesting, as it combines web-browser interaction, using selenium with low-level windows automation, using AutoIt.
So, we combine the web-login with the dialog-confirmer as follows:
Notice, that in this real-world example, three AutoIt dialog confirmers are started in parallel. They execute concurrently with the web-browser's login procedure. These parallel processing threads are cancelled when the login step has finished. The three confirmers care for different types of boxes which appear depending on the type of browser used: as it happened in that particular application, Firefox was asking for the chip-card password, whereas Internet Explorer wanted the user to confirm the use of a particular certificate. Some of these dialogs only appear once per session, as the browsers seem to cache this data. Thus, if the browser does not ask for a password (in a second run, for example), the login step succeeds immediately and terminates the box-wait actions.
The three dialog-confirmer look very similar; here is the "Answer Firefox Password Dialog" block's implementation:
Back to Online Documentation.