WinAppDriver: alternative per le app senza albero di accessibilità

Quando lo strumento di test non vede la vostra app

Puntate Inspect sul pulsante Salva della vostra applicazione, e mostra un unico riquadro vuoto.Il vostro locator non trova nulla, il test WinAppDriver fallisce, e comincia la ricerca di un'alternativa a WinAppDriver.

Raramente il problema è lo strumento.Quasi ogni strumento di test desktop chiede all'albero di accessibilità dell'applicazione dove si trova il pulsante, e alcune applicazioni non ne hanno uno.

Questa guida spiega come funziona l'automazione dei test desktop su Windows, quali applicazioni non riesce a vedere, e come testare comunque un'applicazione desktop Windows di questo tipo: trovando ogni elemento a vista, come fa una persona.

Come funziona l'automazione dei test desktop su Windows?

L'automazione dei test desktop è un software che pilota un'applicazione attraverso la sua interfaccia, come farebbe un tester, e controlla ciò che mostra.Su Windows, quasi tutta passa per Microsoft UI Automation, il framework di accessibilità che alimenta anche i lettori di schermo.

Ogni applicazione descrive la propria interfaccia a Windows sotto forma di albero.La finestra contiene riquadri, e i riquadri contengono pulsanti, campi ed elenchi, ciascuno con un nome, un tipo e una posizione sullo schermo.Microsoft Active Accessibility, o MSAA, è la tecnologia più vecchia che fa lo stesso per i programmi più datati.

Uno strumento di test legge quell'albero, trova un elemento con un locator come il suo AutomationId, il suo nome o un XPath attraverso l'albero, poi ci fa clic, ci digita dentro o ne legge il valore.

Questo funziona bene quando l'albero è completo.Microsoft fornisce la descrizione di ogni controllo standard Win32, Windows Forms (WinForms) e WPF, quindi questi compaiono nell'albero da soli.Un controllo personalizzato è diverso: i suoi sviluppatori devono scrivere quella descrizione, e senza di essa, dice la documentazione di Microsoft, il controllo è in gran parte opaco per UI Automation, che può riportare poco più della sua posizione.

WinAppDriver e le sue alternative leggono lo stesso albero

WinAppDriver, il Windows Application Driver di Microsoft, ha portato un'automazione in stile Selenium alle app UWP, Windows Forms, WPF e Win32 classiche.La sua ultima versione stabile su GitHub, la 1.2.1, risale a novembre 2020, seguita da una release candidate della 1.3 a luglio 2021.Il driver Windows di Appium costruito sopra di esso è ora contrassegnato come deprecato, e la sua documentazione indica il driver Appium WinCore come sostituto ufficiale.

Le alternative più comuni prendono ciascuna una strada diversa verso lo stesso albero:

• Appium WinCore e NovaWindows sono driver Appium che lavorano sugli elementi di UI Automation, da un test scritto in qualsiasi linguaggio supportato da Appium.
• FlaUI è una libreria .NET open source che incapsula le librerie UI Automation di Microsoft per i test scritti in C#.
• pywinauto è una libreria Python open source con due back-end: l'API Win32 e UI Automation.
• Coded UI, il framework di test dell'interfaccia di Visual Studio, è deprecato: Visual Studio 2019 è l'ultima versione che crea test con esso.
• TestComplete e Ranorex sono strumenti commerciali che identificano i controlli dalle loro proprietà, ed entrambi offrono un'automazione basata sulle immagini per i controlli che non riescono a riconoscere.

Anche le indicazioni più recenti di Microsoft per le app WinUI 3, i comandi winapp ui per gli agenti IA, leggono l'albero di accessibilità dal vivo e chiedono agli sviluppatori di impostare un AutomationId su ogni controllo interattivo.

Per gli strumenti di test web messi a confronto, vedete lo studio comparativo.

Quali app Windows non hanno un albero di accessibilità?

Puntate Inspect su una qualsiasi di queste, e spesso troverete un unico riquadro vuoto dove vi aspettavate un modulo.È la realtà quotidiana del test delle applicazioni legacy, e anche di molte app moderne.

A volte l'albero esiste, ma non potete toccare l'applicazione: un programma di un altro fornitore, un build bloccato per un audit, un team che non può aggiungere AutomationId per voi.Qualsiasi strumento che richieda un build di test, un agente dentro l'app o una modifica al suo codice è allora fuori portata.

Come controllare la vostra app in due minuti

1. 1

   Aprire uno strumento di ispezione

   Installate Accessibility Insights for Windows, lo strumento di ispezione di Microsoft, oppure usate Inspect del Windows SDK.

2. 2

   Passare il puntatore sugli elementi che servono ai vostri test

   Ciascuno dovrebbe comparire con un nome, un tipo e un AutomationId.

3. 3

   Leggere ciò che vedete

   Un unico riquadro per l'intera finestra, o elementi senza nome, significano che uno strumento basato sull'albero non può trovarli in modo affidabile.

Test basato sulle immagini: testare ciò che c'è sullo schermo

Il test basato sulle immagini è un'automazione dei test che trova gli elementi da come appaiono sullo schermo, non da ciò che l'applicazione dice di loro.È il modo in cui l'automazione dei test desktop funziona senza informazioni di accessibilità.Non richiede nulla all'applicazione: nessun albero, nessun locator, nessuna modifica al suo codice.Se potete vedere un elemento, un test può raggiungerlo.

SikuliX è il classico esempio open source: catturate un'immagine di ogni elemento e scrivete ogni passaggio come una riga di script.Gli strumenti commerciali lo offrono come ripiego.La documentazione di TestComplete, per esempio, dice che i suoi test basati sulle immagini possono essere registrati solo su app Android: su un'app desktop, catturate le immagini e aggiungete i comandi di test a mano.

Fatto in modo ingenuo, un test a vista ha punti deboli ben noti.Ognuno ha una risposta:

Un'alternativa a WinAppDriver che non ha bisogno dell'albero

GUI Test Studio è una suite di test GUI end-to-end per Windows che testa qualsiasi applicazione vediate sul vostro schermo, senza codice.Non sceglie tra l'albero e lo schermo.

Il GTS Engine + AI interroga prima le informazioni di accessibilità dell'applicazione, quando ce ne sono, e trova l'elemento a vista quando non ce ne sono.

Come GUI Test Studio trova gli elementi spiega come i due modi lavorano insieme.Ecco cosa significa per un'app senza albero, passo dopo passo.

1. 1

   Registrare l'app

   In GUI Test Runner-Recorder, fate clic su Registra e scegliete Un'app.Scegliete il programma tra le app aperte, oppure andate a cercarne uno che non è ancora in esecuzione.Spuntate la casella che lo avvia con il test e lo chiude alla fine, così ogni esecuzione parte da un'app appena avviata.Poi usate l'app come fate sempre.

   

   Ingrandisci

   Scegliere un'app tiene fuori dal vostro test una notifica di un altro programma, mentre ogni vostro clic e tasto viene comunque registrato.Vedete Registrare un test.

2. 2

   Ogni elemento viene conservato in due modi

   Ogni clic riceve un'asserzione visiva subito prima: un'immagine dell'elemento, il suo obiettivo visivo.Quando l'applicazione descrive quell'elemento a Windows, il test conserva anche quella descrizione.Quando l'app risponde con un unico riquadro vuoto, non c'è nulla che valga la pena conservare, e l'immagine da sola trova l'elemento.

   Alcuni programmi disegnano a mano i propri moduli e descrivono solo la finestra del modulo stesso.Il test conserva quella finestra, così un modulo che si è spostato viene ritrovato dove si trova ora.

3. 3

   Controllare ciò che viene mostrato

   Un'asserzione visiva controlla che un elemento sia sullo schermo e abbia l'aspetto giusto.Un'asserzione testuale chiede all'applicazione cosa dice un elemento, e legge le parole sullo schermo quando l'applicazione non sa dirlo.Un'asserzione testuale dinamica controlla un valore che cambia a ogni esecuzione, come una data o un numero d'ordine, dal suo formato.

   Ogni confronto ignora le piccole differenze di rendering che ogni schermo presenta e individua comunque le regressioni reali che una persona chiamerebbe un cambiamento: un colore sbagliato, un'icona mancante, una parola che è cambiata.Vedete Asserzioni visive.

4. 4

   Eseguirlo, ovunque si apra la finestra

   Il test riproduce i vostri clic e tasti come input reale di mouse e tastiera, puntati dove si trova ora ciascun elemento.Quando un controllo non ha trovato il suo elemento nella sua area di ricerca dopo un secondo, cerca anche in tutto lo schermo, così una finestra che si è spostata non fa fallire il test.Il report di affidabilità dice allora che l'elemento è stato trovato fuori dalla sua area di ricerca, e propone di allargarla in GUI Test Studio.

   Su un computer con più monitor, un test usa uno schermo o tutti, e ricorda quale.

   

   Ingrandisci

Citrix, Desktop remoto e macchine virtuali

Una sessione Citrix, Desktop remoto (RDP) o VMware Horizon arriva sul vostro computer come un'unica finestra di pixel.Alcuni strumenti possono raggiungerne i controlli solo se sono installati sul server remoto stesso, come descrive SmartBear per TestComplete.GUI Test Studio testa la sessione dal computer che la mostra, a vista, come qualsiasi altra finestra.

Scegliete Un'app e la finestra della sessione quando registrate, oppure Un'area dello schermo per un suo pannello.Un'app in una macchina virtuale funziona allo stesso modo: date alla macchina virtuale una dimensione di finestra fissa, uguale su ogni computer che esegue i test.Vedete Cosa potete testare.

Eseguire i test desktop a ogni build

gtr-cli, lo strumento di esecuzione da riga di comando, esegue un test esattamente come il pulsante Esegui test.Aggiunge ciò che serve a una pipeline: un codice di uscita, un file JUnit, e ogni prova di un errore in un'unica cartella.

gtr-cli run tests --countdown 0 --junit results\junit.xml --artifacts results\artifacts

Un test desktop viene riprodotto su uno schermo reale, quindi l'agente di build ha bisogno di una sessione desktop di Windows sbloccata.Una macchina virtuale con una dimensione dello schermo fissa funziona bene come agente di test.La guida CI/CD spiega la configurazione passo dopo passo.

Domande

WinAppDriver, Windows, Visual Studio, Selenium, Appium, FlaUI, pywinauto, TestComplete, Ranorex, SikuliX, Delphi, Java, Citrix, VMware Horizon ed Electron sono marchi dei rispettivi proprietari.