AutoIt Library/en

Aus expecco Wiki (Version 2.x)
(Weitergeleitet von AutoIt Library)
Wechseln zu: Navigation, Suche

Introduction

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.

Installation

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 "C:\Program Files\AutoIt3". The only component needed by expecco is the AutoIt dll, which should be in "C:\Program Files\AutoIt3\AutoItX\AutoItX3.dll".

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:

DLL AutoIt Mapping.png

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.

Command Overview

The following overview only describes the most useful building blocks. Please refer to the Official AutoIt Documentation and The Function Reference for a full list and more detailed description.

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:

AutoIt DLL Block Example.png

If any function is missing, take those as a guide on how to add your own AutoIt calling action block.

Connect / Disconnect

Window Specific Functions

Window Control Specific Functions

Option Setting

Process Handling

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.

Examples

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:

AutoIt WaitForWindow1.png

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:

WebLogin with ConfirmPassword1.png

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:

AutoIt ConfirmPassword1.png



Back to Online Documentation.



Copyright © 2014-2016 eXept Software AG