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

sfondo

Attualmente sto automatizzando alcuni test per un plugin per MS Office. Stiamo creando test codificati dell'interfaccia utente in VS 2010. Suppongo che potrei usare lo strumento " Coded UI test builder ", ma non si adatta davvero al mio caso particolare.

Per questo motivo ho creato la mia classe di UI Map e metodi di estensione per ciascun controllo / mappa dell'interfaccia utente in cui aggiungo diverse funzionalità di azione. Ad esempio, premere i pulsanti o affermare alcuni valori dell'interfaccia utente.

Gli scenari dei casi di test sono nelle classi di test.

Sono nuovo in questo settore e sono anche nuovo nel lavoro come tester di automazione.

La domanda

Le persone sarebbero così gentili da condividere la loro esperienza e i loro consigli su alcune buone pratiche per l'automazione dei test su applicazioni desktop dal punto di vista della programmazione / progettazione?

La migliore pratica per i test di automazione dell'interfaccia utente è fare il meno possibile. Le interfacce utente cambiano frequentemente, il che significa che devi costantemente aggiornare l'automazione. È generalmente preferibile strutturare il codice del prodotto in modo da consentire test automatizzati senza automazione dell'interfaccia utente.

Detto questo, non puoi sempre sbarazzarti dell'automazione dell'interfaccia utente. Hai parlato di Office, quindi suppongo che stai codificando per Windows e usando .Net. Faccio un bel po 'nel mio attuale lavoro. Ecco alcune delle cose che ho imparato.

1) Guarda le librerie UIAutomation che sono state introdotte in .Net 3.0. Forniscono una libreria estesa 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 UI del tuo prodotto automatizzabili.

3a) Se si tratta di WPF, inserire AutomationIDs su tutto.

3b) Provare a creare un controllo distintivo e nomi di classi di finestre (nomi di classi UI, non nome di classe del codice sorgente). Se non sai cosa intendo, carica UI Spy e inizia a guardare Windows. Nota quante finestre su diverse app hanno un nome di classe # 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, per impostazione predefinita è questa. Ciò provoca ogni sorta di dolore dal punto di vista dell'automazione dell'interfaccia utente.

4) Evitare le istruzioni Thread.Sleep (). Prova invece a utilizzare i camerieri (consulta i documenti di UIAutomation).

5) MAI mescolare il codice di test 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, ciò renderà molto più semplice l'aggiornamento dell'automazione.

6) Registrare 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 ottenere mai l'evento.

7) Non dare mai per scontato che la finestra appena aperta sia quella che desideri. Tutti i tipi di finestra possono aprirsi inaspettatamente in Windows.

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

Costruisci test funzionali da casi d'uso riutilizzabili

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

Ad esempio, considerare il caso d'uso "Accedi come utente standard". Il framework di test avvia l'applicazione, attende la schermata di accesso, inserisce alcune credenziali, fa clic sul pulsante di accesso e verifica che la schermata appropriata ora mostri che l'accesso ha avuto esito positivo.

Dopo aver eseguito il caso d'uso "Accedi come utente standard", ti consigliamo di fare questo per fare qualcos'altro, forse il caso d'uso "Modifica i miei dati utente". Non vorrai ripetere tutto il codice dal caso d'uso "Accedi come utente standard", quindi fai solo un riferimento al codice del framework di test che fa quel bit.

Ciò implica che si dispone di 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 verificarne il comportamento (schermo blu).

Nel complesso, è possibile creare un insieme di casi d'uso riutilizzabili che mirano a sequenze specifiche e testano risposte specifiche, quindi aggregarli in vari test funzionali che sono strettamente correlati ai requisiti aziendali. Una volta che hai messo tutto a posto, sei nella posizione ideale per automatizzare completamente l'intero processo di compilazione .

Se sei interessato a leggere più avanti ho scritto di questo approccio altrove, ma l'articolo riguarda le applicazioni Web in Java (usando Maven e SeleniumRC) piuttosto che le applicazioni desktop che hai richiesto.