Modelli di automazione dell'interfaccia utente e best practice per applicazioni desktop

La migliore pratica per l'UI Automation Testing è fare il meno possibile. Le interfacce utente cambiano frequentemente, il che significa che devi costantemente aggiornare la tua automazione. In genere è preferibile strutturare il codice del prodotto in un modo che consenta test automatizzati senza UI Automation.

Detto questo, non puoi sempre sbarazzarti di UI Automation. Parli dell'ufficio quindi presumo che tu stia codificando per Windows e utilizzando .Net. Faccio un bel po 'nel mio attuale lavoro. Ecco alcune delle cose che ho imparato.

1) Guarda le librerie di UIAutomation che sono state introdotte in .Net 3.0. Forniscono una libreria ampia e abbastanza semplice da usare per l'automazione. (Http://msdn.microsoft.com/en-us/library/ms753107.aspx)

2) Scarica UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)

3) Rendi le interfacce utente del tuo prodotto automatiche.

3a) Se è WPF, metti AutomationIDs su tutto.

3b) Prova a creare nomi di classi di controllo e finestra distintivi (nomi di classe UI, non nome della classe del codice sorgente). Se non sai cosa intendo, carica UI Spy e inizia a guardare windows. Nota quante finestre in diverse app hanno un nome di classe di # 32770. Questo è il nome della classe per una finestra di dialogo di Windows. Qualsiasi finestra che estende la finestra di dialogo e non imposta il proprio nome, si imposta automaticamente su questa. Ciò causa ogni sorta di dolore da un punto di vista dell'automazione dell'interfaccia utente.

4) Evitare dichiarazioni Thread.Sleep (). Prova ad usare i Camerieri (vedi i documenti di UIAutomation).

5) MAI mescolare il codice di prova con il codice di automazione dell'interfaccia utente. Creare librerie separate per eseguire l'automazione dell'interfaccia utente. Chiama queste librerie dai tuoi test. Quando l'interfaccia utente cambia, questo renderà molto più semplice l'aggiornamento dell'automazione.

6) Registra sempre un listener per un evento UI prima di eseguire l'azione che causerebbe l'attivazione dell'evento. In pratica, questo significa che lavorerai con i thread.

6a) Esempio: non iniziare ad aspettare un evento Finestra aperta dopo aver fatto clic su un pulsante per aprire la finestra. La finestra potrebbe aprirsi prima che il cameriere sia registrato e non ricevere mai l'evento.

7) Non dare per scontato che la finestra appena aperta sia quella che si desidera. Tutti i tipi di finestre potrebbero aprirsi inaspettatamente in Windows.

Potrei andare avanti di più, ma questo sta diventando un po 'lungo.

Crea test funzionali da casi d'uso riutilizzabili

Quando arriva il momento di testare la tua applicazione end-to-end, stai eseguendo test funzionali. Normalmente avrai una serie di requisiti che stai testando e sarai in grado di costruire vari casi d'uso che li rappresentano.

Ad esempio, considera il caso d'uso "Accedi come utente standard". Il framework di test attiva l'applicazione, attende la schermata di accesso, inserisce alcune credenziali, fa clic sul pulsante di accesso e verifica che lo schermo appropriato mostri che l'accesso è andato a buon fine.

Dopo aver utilizzato l'use case "Accedi come utente standard", ti basterà occupartene per fare qualcos'altro, forse il caso d'uso "Modifica i miei dettagli utente". Non vorrai ripetere tutto il codice dal caso d'uso "Accedi come utente standard", quindi basta fare un riferimento al codice del framework di test che fa quel bit.

Ciò implica che hai una sorta di test funzionale di over-arching contenente un elenco di casi d'uso. Questi casi d'uso contengono i metodi del framework di test per causare il comportamento dell'applicazione (fare clic sul pulsante X) e verificare il comportamento (lo schermo diventa blu).

Nel complesso, è possibile creare una serie di casi d'uso riutilizzabili che mirano a sequenze specifiche e testare risposte specifiche, e quindi aggregarle in vari test funzionali che sono strettamente correlati con i requisiti aziendali. Una volta ottenuto ciò, sei in una posizione ottimale per automatizzare completamente l'intero processo di creazione .

Se sei interessato a leggere ulteriormente I ' ho scritto su questo approccio altrove, ma l'articolo si rivolge alle applicazioni web in Java (usando Maven e SeleniumRC) piuttosto che alle applicazioni desktop che hai richiesto.