Tool per l’automazione della GUI Windows e considerazioni sul loro utilizzo

Talvolta vi sono situazioni in cui sarebbe utile automatizzare una serie ripetitiva di operazioni che devono essere svolte tramite uno o più applicativi. Uno di questi scenari è sicuramente il caso dell’automazione dei test su di un softwar, ma per una trattazione di questo scenario e dei tools a disposizione si veda il post What are the best UI Test Automation Tools?.

Di seguito invece alcune considerazioni personali sull’uso dei tool per l’automazione della GUI Windows negli scenari di produttività individuale, ovvero in quegli scenari in cui si desidera velocizzare operazioni ripetitive che un utente svolge spesso con uno o più applicativi che non permettono nativamente un’automazione (per esempio le macro di office) o una semplificazione del processo (ad esempio tramite una modifica dell’applicativo).

Considerazioni iniziali e scelta del tool

Prima di valutare l’adozione di un tool per l’automazione della GUI Windows occorre tenere presente che tali per essere duttili necessariamente dovranno prevedere un’automazione basata su una un linguaggio di scripting finalizzato ad interagire con la GUI Windows e che quindi dovrà necessariamente essere un linguaggio ad hoc e non un linguaggio di scripting comune come PowerShell, VbScript, Javascript, etc… Questo significa che occorre prevedere una curva di apprendimento del linguaggio di scripting e dal momento che il linguaggio è di fatto legato al tool occorre anche scegliere un tool che sia molto diffuso e con un’alta probabilità di essere manutenuto ed aggiornato per un lungo lasso di tempo.

In altre parole l’adozione di un tool di automazione della GUI Windows ha senso se le attività di automazione sono di una certa complessità, ovvero se si desidera implementare automazioni che non richiedono solo la simulazione della pressione di una serie di tasti (a riguardo si vedano ad esempio i mie post PowerShell: avvio applicazione e input e Telnet script) o comunque attività che non si possano eseguire tramite linguaggi di scripting comuni o, se si possiedono competenze di programmazione, tramite programmi sviluppati ad hoc ad esempio tramite Visual Studio in C# o VB.Net.

Un’altra cosa da tenere presente è che dal momento che occorrerà investire tempo per apprendere l’uso del tool per l’automazione della GUI Windows e occorrerà mantenere tale conoscenza nel tempo dal momento che spesso l’automazione della GUI Windows potrebbe comportare a seguito di aggiornamenti di sistema o delle applicazioni di rimettere mano alla gestione dell’automazione. Quindi l’adozione di tool di automazione della GUI ha senso se tale conoscenza potrà essere impiegata anche in altre occasioni e non solo per risolvere la problematica di un caso specifico.

Fatte queste premesse per quanto riguarda la scelta del tool questa dovrà essere fatta tenendo presente le seguenti considerazioni:

• privilegiare i tools che hanno una maggiore adozione perché in questo modo sarà più probabile trovare informazioni per l’automazione di specifici casi;
• privilegiare i tools che presentano una certa garanzia di continuità dal momento che potrebbe essere necessario dover intervenire sulle automazioni a distanza di tempo, inoltre dal momento che il linguaggio di scripting per l’automazione è specifico per ogni tool il cambio di quest’ultimo comporterà molto probabilmente la riscrittura parziale degli script sviluppati;
• dato per scontato che il tool abbia tutte le caratteristiche necessarie in termini di funzionalità per gestire l’automazione, le considerazioni precedenti (punto 1 e punto2) sono da tenere in maggior considerazione rispetto alla curva di apprendimento del tool, che comunque deve essere messa in conto, o rispetto ad una apparente semplicità di un tool che perderà d’importanza man man che si utilizzerà il tool.

In base a queste considerazioni i tool che al momento mi sentirei di consigliare sono due:

• AutoIt un tool freeware, nato nel 1999 e giunto alla versione 3.3.14.5 rilasciata il 16 marzo 2018;
• AutoHotkey un tool free open source (GNU GPLv2), nato nel 2003 e giunto alla versione 1.1.30.01 rilasciata l’11 novembre 2018, di tale tool è in sviluppo anche una v2 a cui gli sviluppatori stanno lavorando dal 2011 che prevederà però alcune incompatibilità con la versione v1.

In realtà i due tool sono di fatto legati dal momento che AutoHotKey è nato come fork di AutoIt, quando questo era rilasciato come open source con la licenza GNU General Public License (GPL), per intergrare la funzionalità di hotkey, successivamente AutoIT nel 2006 è diventato un software closed source.

Entrambi i tool prevedono un setup o un’installazione di tipo portable, possono compilare uno script in un eseguibile per consentirne l’esecuzione in computer dove il tool non è installato ed entrambi possono generare scriot attivabili tramite la pressione di una combinazione di tasti.

Considerazioni sull’automazione della GUI Windows

L’automazione della GUI Windows non è sempre un’attività semplice dal momento che possono presentarsi comportamenti diversi dell’interfaccia come visualizzazione di finestre non previste in seguito a successive installazioni di applicazioni o tempistiche di risposta differenti in relazioni a quali applicazioni o servizi sono in esecuzione.

Per questo motivo quanto si gestisce l’automazione occorre cercare di prevedere le varie casistiche che possono presentarsi e strutturare lo script nel modo più semplice e strutturato possibile in modo che sia semplice metterci mano successivamente a distanza di tempo.

Di seguito un esempio di script di automazione scritto in AutoHotkey che trasforma in maiuscolo il testo selezionato, lo script si attiva premendo CRTL+ALT+m e si disattiva premendo CTRL+ALT+z:

; Termine script tramite CTRL+ALT+z
^!z::ExitApp

; Attivazione tramite CTRL+ALT+m
^!m::

; Eliminazione del contenuto corrente del clipboard
clipboard =

; Copia testo selezionato
Send ^c

; Attende un secondo che la clipboard contenga del testo
ClipWait, 1

; Trasforma in maiuscolo il contenuto del clipboard
StringUpper, clipboard, clipboard

; Incolla il testo nella clipboard
Send ^v

return

Di seguito invece lo stesso script scritto in AutoIt:

; Termine script tramite CTRL+ALT+z
HotKeySet(“^!z”, “Terminate”)

; Attivazione tramite CTRL+ALT+m
HotKeySet(“^!m”, “HotKeyPressed”)

While 1

Sleep(100)

WEnd

Func HotKeyPressed()

Local $sData = ClipGet()

; Eliminazione del contenuto corrente del clipboard
ClipPut(“”)

; Copia testo selezionato

Send(“^c”)

; Legge il testo memorizzato nella clipboard

$sData = ClipGet()

; Trasforma in mauscolo il contenuto del clipboard

ClipPut(StringUpper($sData))

; Incolla il testo nella clipboard

Send(“^v”)

EndFunc

Func Terminate()

Exit

EndFunc

Come è possibile notare gli script sebbene in linea di principio siano simili sono però differenti in termini di struttura. AutoHotkey è più vicino all’approccio di uno script, mentre AutoIt è più vicino all’approccio di un programma con una sintassi BASIC-like, questo significa che se si decidesse di cambiare il tool occorrerebbe mettere pesantemente mano agli script creati.

Considerazioni sulla sicurezza dei tool di automazione della GUI Windows

Ovviamente sia AutoIt che AutoHotkey possono essere utilizzati per scrivere malware o per automatizzare azioni malevole esattamente come è possibile usare per questi scopi linguaggi di scripting comuni. Quindi l’approccio che conviene tenere è quello di convertire gli script in exe senza distribuire i tool sui computer, ma dedicare un computer per lo sviluppo degli script o se necessario utilizzare su uno specifico computer la versione portable dei tool e terminata l’implementazione rimuove il tool o ancora meglio mantenere il tool su un dispositivo removibile da connettere al computer all’occorrenza.

Ovviamente è anche necessario mettere in sicurezza gli script sviluppati e gli exe generati se questi possono contenere informazioni particolarmente sensibili dal punto di vista della sicurezza dell’infrastruttura, si pensi ad esempio al caso in cui si sia deciso di sviluppare degli script che contengono pin, password, nomi o percorsi che riconducono a file riservati. E’ infatti molto semplice analizzare le informazioni contenute in un eseguibile ad esempio tramite tool come Resource Hacker. Premesso che inserire tali informazioni negli script in chiaro non una buona pratica di sviluppo e che sarebbe meglio se possibile richiedere le informazioni riservate all’utente in sede di esecuzione se proprio non è possibile evitare di avere informazioni “riservate” nel corpo dello script occorre valutare di l’offuscaziondegli exe generati tramite tool di terze parti.