Automazione dei test WPF e test dell'interfaccia WinForms senza codice (e senza albero di accessibilità)

Questa guida è per un QA engineer o uno sviluppatore che deve testare un'applicazione WPF o Windows Forms (WinForms).Mostra ciò che un'app di questo tipo dice a uno strumento di test e ciò che nasconde, registra un test passo dopo passo, sceglie le asserzioni che sopravvivono a un restyling, esegue il test a ogni build, e dice quando una libreria basata sul codice resta la scelta migliore.

Ciò che un'app WPF o WinForms espone a uno strumento di test, e ciò che nasconde

WPF e WinForms descrivono entrambi i loro controlli standard a Windows tramite UI Automation: un tipo, un nome, una posizione sullo schermo e, quando lo sviluppatore ne ha impostato uno, un AutomationId.Un lettore di schermo usa quella descrizione, e così fa ogni strumento di test che trova i controlli tramite locator.La stessa app contiene anche controlli che non dicono assolutamente nulla.

La documentazione stessa di Microsoft dice che un controllo senza un provider UI Automation è in gran parte opaco per UI Automation, che può riportare poco più della sua posizione.Quali app Windows non hanno un albero di accessibilità elenca i tipi di applicazione in cui questa è la regola e non l'eccezione.

Test automatici di un'applicazione WPF: registrare il test passo dopo passo

I test automatici di un'applicazione WPF cominciano con una sola registrazione, in GUI Test Runner-Recorder.Nulla viene aggiunto all'app: nessuna build di test, nessuna libreria, nessun AutomationId che non aveste già.L'esempio qui sotto registra un'app di inserimento ordini, e un'app WinForms si registra allo stesso modo.Vedete Registrare un test per tutte le opzioni.

1. 1

   Fare clic su Registra

   Aprite GUI Test Runner-Recorder e fate clic su Registra.Portate la vostra app nello stato da cui deve partire il test: la prima schermata del flusso, senza nient'altro aperto sopra.

2. 2

   Rispondere a “Che cosa vuole testare?” con Un'app

   Scegliete Un'app e selezionate il vostro programma tra quelli in esecuzione, oppure cercate il suo .exe se non è ancora aperto.Spuntate la casella che avvia l'app con il test e la chiude alla fine, così ogni esecuzione parte da un'app appena aperta.

   

   Ingrandisci

3. 3

   Usare l'app come farebbe un tester

   Digitate il nome del cliente, scegliete un prodotto nell'elenco, fate clic su Save e leggete la conferma.Ogni clic e ogni tasto vengono registrati, e il registratore ritaglia un'immagine di ogni controllo su cui fate clic, appena prima del clic.Premete il tasto Termina quando il flusso è finito.

4. 4

   Rispondere a “Cosa deve verificare questo test?”

   Tre schede chiedono cosa deve verificare il test: gli elementi visivi su cui avete fatto clic, il testo sullo schermo, e ciò che è comparso mentre lavoravate, come una finestra di dialogo o una conferma.Per un primo test lasciate le impostazioni predefinite, e salvate.

   

   Ingrandisci

5. 5

   Il test viene salvato in una cartella tutta sua, ed eseguito

   Un test chiamato Orders viene salvato come Orders\Orders.GTS, in una cartella tutta sua, dove i risultati e la cronologia di ogni esecuzione vengono conservati accanto a esso.Fate clic su Esegui test: il test riproduce i vostri clic e i vostri tasti come input reale, mirando a dove si trova ora ogni controllo, e termina con un report di affidabilità che dice cosa è stato superato e cosa è cambiato.

Potete anche saltare la registrazione e descrivere il flusso in un prompt a Claude, ChatGPT o a un modello di IA locale, uno dei nostri o uno vostro: il test viene creato allo stesso modo, con le stesse asserzioni.

Test dell'interfaccia WinForms: le asserzioni che sopravvivono a un restyling

I test dell'interfaccia WinForms, come i test WPF, vivono o muoiono di asserzioni che colgono un vero cambiamento e ignorano quelli innocui.GUI Test Studio ne offre tre tipi, ciascuno un blocco sulla timeline del test che chiunque nel team può aggiungere, spostare o modificare.

Tutte e tre ignorano il rumore che ogni schermo ha e colgono comunque ciò che una persona chiamerebbe un cambiamento: un colore sbagliato, un'icona mancante, una parola che ha cambiato maiuscole e minuscole, un controllo scivolato fuori posto.Asserzioni visive passa in rassegna le impostazioni di ciascuna.

L'area di ricerca

Ogni asserzione cerca il suo elemento all'interno di un'area di ricerca, una zona intorno al punto in cui l'elemento è stato registrato.L'area tiene separati gli elementi simili: un pulsante Save nella barra degli strumenti e un pulsante Save in una finestra di dialogo si distinguono dal punto in cui si trova ciascuno.Un'asserzione che dopo un secondo non ha trovato il suo elemento nella sua area guarda anche su tutto lo schermo, così una finestra che si è aperta più a destra non fa fallire il test, e il report di affidabilità dice dove è stato trovato l'elemento.

Un restyling del codice dietro un controllo

Un tema scuro, un tema a contrasto elevato, un'altra lingua

Le informazioni di accessibilità dell'app non cambiano con un tema, quindi un'asserzione che interroga l'app regge sia nel tema chiaro sia in quello scuro.L'immagine che confronta un'asserzione visiva invece cambia, e un profilo di baseline conserva una versione attesa per ambiente: eseguite il test con il profilo Modalità scura, accettate una volta ogni nuovo aspetto nel report di affidabilità, e lo stesso test controlla poi l'aspetto chiaro e quello scuro, ciascuno rispetto alla versione giusta.

Ingrandisci

Automazione dei test desktop su Windows a ogni build

L'automazione dei test desktop su Windows ripaga quando viene eseguita senza che nessuno la avvii. gtr-cli, l'esecutore da riga di comando, esegue un test esattamente come il pulsante Esegui test e risponde come si aspetta una pipeline: un test non superato fa fallire la build, un file JUnit riempie la scheda dei test, e ogni immagine di ciò che non è riuscito viene conservata in un'unica cartella.

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

Un'opzione indica lo strumento di CI, e gli errori compaiono poi nel suo stesso log, come annotazioni o voci di test, senza alcun plugin da installare:

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.Eseguire i test nella pipeline elenca ogni opzione, e Eseguite i vostri test end-to-end a ogni build configura passo dopo passo una build di TeamCity, con lo stesso comando per Jenkins, GitHub Actions, GitLab e Azure DevOps.

FlaUI, pywinauto e altri strumenti di test dell'interfaccia WPF: quando il codice è la scelta giusta

Due librerie open source sono ciò a cui uno sviluppatore ricorrerebbe altrimenti.FlaUI è una libreria .NET per i test automatici dell'interfaccia delle applicazioni Windows, tra cui WPF e WinForms, che incapsula le librerie UI Automation di Microsoft per un test scritto in C#.pywinauto, secondo la sua pagina GitHub, è un insieme di moduli Python per automatizzare l'interfaccia grafica di Windows, con due back-end: l'API Win32, quello predefinito, e UI Automation.

Entrambe sono una scelta sensata per un team orientato al codice i cui controlli sono tutti accessibili: i test vivono nel repository stesso dell'app, in un linguaggio che il team scrive ogni giorno, accanto ai test unitari, e uno sviluppatore che conosce l'albero dei controlli può scrivere un locator preciso per ogni elemento.Il costo si paga in tempo degli sviluppatori, per ogni locator e per ogni restyling che ne cambia uno, e un elemento che l'app non descrive richiede un'altra via d'accesso.

Le due cose non sono nemiche.Un team con un'app WPF piena di controlli personalizzati spesso tiene i test unitari nel codice e registra i test end-to-end, così le persone che conoscono meglio i flussi possono mantenerli, e vengono testati anche i controlli che l'app non descrive.

Punti chiave

• 1WPF e WinForms descrivono i loro controlli standard, e non dicono nulla di un grafico, di un indicatore, di una griglia disegnata dall'app o di molti controlli di terze parti.
• 2Una sola registrazione testa entrambi i tipi: il GTS Engine + AI interroga prima l'app e trova il controllo a vista quando l'app non dice nulla.
• 3Scegliete asserzioni che sopravvivono a un restyling: un'asserzione visiva, un'asserzione testuale e un'asserzione di layout falliscono solo quando lo schermo è sbagliato, e un profilo di baseline copre un tema scuro.
• 4Eseguitelo a ogni build con gtr-cli, in TeamCity, Azure DevOps, GitHub Actions, Jenkins o GitLab, su un desktop Windows sbloccato.
• 5FlaUI e pywinauto hanno ancora senso per un team orientato al codice i cui controlli sono tutti accessibili; il costo è il tempo degli sviluppatori per ogni locator.

Domande

Microsoft, Windows, WPF, Windows Forms, FlaUI, pywinauto, TeamCity, Azure DevOps, GitHub, GitLab e Jenkins sono marchi o progetti dei rispettivi proprietari.