Condividi tramite


Impostazione dei test codificati dell'interfaccia utente per l'attesa di eventi specifici durante la riproduzione

In una riproduzione del test codificato dell'interfaccia utente è possibile fare in modo che il test attenda che si verifichino determinati eventi, ad esempio che venga visualizzata finestra, nascosto l'indicatore di stato e così via.A questo scopo, utilizzare il metodo UITestControl.WaitForControlXXX() appropriato, come descritto nella tabella seguente.Per un esempio di test codificato dell'interfaccia utente impostato in modo da attendere che un controllo venga abilitato tramite il metodo WaitForControlEnabled, vedere Procedura dettagliata: creazione, modifica e gestione di un test codificato dell'interfaccia utente.

Requisiti

  • Visual Studio Ultimate, Visual Studio Premium
SuggerimentoSuggerimento

È anche possibile aggiungere ritardi per le azioni tramite l'editor test codificati dell'interfaccia utente.Per ulteriori informazioni, vedere Procedura: inserire un ritardo prima di un'azione dell'interfaccia utente utilizzando l'editor di test codificato dell'interfaccia utente.

Metodi UITestControl.WaitForControlXXX()

Metodi UITestControl.WaitForControlXXX()

Descrizione

WaitForControlReady

Attende che il controllo sia pronto ad accettare l'input del mouse e della tastiera.Il motore chiama in modo implicito questa API in modo che tutte le azioni attendano che il controllo sia pronto prima di eseguire qualsiasi operazione.In scenari particolari è tuttavia possibile che sia necessario eseguire una chiamata esplicita.

WaitForControlEnabled

Attende che il controllo venga abilitato quando la procedura guidata esegue una convalida asincrona dell'input effettuando chiamate al server.È possibile ad esempio fare in modo che il metodo attenda l'abilitazione del pulsante Avanti della procedura guidata ().Per un esempio di questo metodo, vedere Procedura dettagliata: creazione, modifica e gestione di un test codificato dell'interfaccia utente.

WaitForControlExist

Attende per il controllo venga visualizzato nell'interfaccia utente.Si prevede ad esempio la visualizzazione di una finestra di dialogo relativa all'errore dopo l'esecuzione della convalida dei parametri da parte dell'applicazione.Il tempo impiegato per la convalida è variabile.È possibile utilizzare questo metodo per attendere la visualizzazione della finestra di dialogo relativa all'errore.

WaitForControlNotExist

Attende per il controllo non sia più visualizzato nell'interfaccia utente.È possibile ad esempio attendere che l'indicatore di stato venga nascosto.

WaitForControlPropertyEqual

Attende che alla proprietà del controllo specificata venga assegnato il valore indicato.È possibile ad esempio attendere che il testo dello stato venga modificato in Operazione completata.

WaitForControlPropertyNotEqual

Attende che alla proprietà del controllo specificata venga assegnato un valore opposto a quello specificato.È possibile attendere ad esempio che la casella di modifica sia di sola lettura, ovvero sia modificabile.

WaitForControlCondition

Attende che il predicato specificato sia di nuovo true.Può essere utilizzato per operazioni di attesa complesse (come le condizioni OR) per un determinato controllo.È possibile ad esempio attendere finché il testo dello stato non sarà Succeeded o Failed come illustrato nel codice seguente:

// Define the method to evaluate the condition 
private static bool IsStatusDone(UITestControl control) 
{ 
    WinText statusText = control as WinText; 
    return statusText.DisplayText == "Succeeded" || statusText.DisplayText == "Failed"; 
} 
// In test method, wait till the method evaluates to true 
statusText.WaitForControlCondition(IsStatusDone);

WaitForCondition``1

Tutti i metodi precedenti sono metodi di istanza di UITestControl.Questo è un metodo statico.Attende inoltre che il predicato specificato sia true, ma può essere utilizzato per operazioni di attesa complesse (come le condizioni OR) per più controlli.È possibile ad esempio attendere finché il testo dello stato non sarà Succeeded o finché non verrà visualizzato un messaggio di errore, come illustrato nel codice seguente:

// Define the method to evaluate the condition 
private static bool IsStatusDoneOrError(UITestControl[] controls) 
{ 
    WinText statusText = controls[0] as WinText; 
    WinWindow errorDialog = controls[1] as WinWindow; 
    return statusText.DisplayText == "Succeeded" || errorDialog.Exists; 
} 
// In test method, wait till the method evaluates to true 
UITestControl.WaitForCondition<UITestControl[]>(new UITestControl[] { statusText, errorDialog }, IsStatusDoneOrError); 

Di seguito viene descritto il comportamento di tutti questi metodi:

  • I metodi restituiscono True se l'attesa ha esito positivo e False ha esito negativo.

  • Il timeout implicito per l'operazione di attesa viene specificato dalla proprietà WaitForReadyTimeout.Il valore predefinito di questa proprietà è 60000 millisecondi (un minuto).

  • I metodi che accettano timeout espliciti in millisecondi sono sottoposti a overload.Quando tuttavia l'operazione di attesa comporta una ricerca implicita del controllo, o quando l'applicazione è occupata, il tempo di attesa effettivo potrebbe essere superiore a quello specificato.

Le funzioni precedenti sono efficaci e flessibili e dovrebbero soddisfare quasi tutte le condizioni.Qualora questi metodi non dovessero soddisfare le esigenze specifiche e fosse necessario inserire nel codice Wait o Sleep, è consigliabile utilizzare l'API Playback.Wait() anziché Thread.Sleep().Di seguito vengono illustrati i motivi:

  • È possibile utilizzare la proprietà ThinkTimeMultiplier per modificare la durata della sospensione.Per impostazione predefinita, questa variabile corrisponde a 1 ma è possibile aumentare o diminuire il valore per modificare il tempo di attesa in tutto il codice.Se si sta ad esempio effettuando test in maniera specifica su una rete lenta, o in qualsiasi altro caso di prestazioni ridotte, è possibile modificare in 1,5 questa variabile in un punto (o nel file di configurazione) per aumentare ovunque del 50% il tempo di attesa.

  • Playback.Wait() chiama internamente Thread.Sleep() (dopo il calcolo precedente) in blocchi più piccoli in un ciclo For durante la verifica di un'operazione di annullamento/interruzione dell'utente.In altre parole, Playback.Wait() consente di annullare la riproduzione prima della fine dell'attesa, mentre Sleep potrebbe non funzionare o generare un'eccezione.

SuggerimentoSuggerimento

L'Editor test codificati dell'interfaccia utente consente di modificare facilmente i test codificati dell'interfaccia utente.Utilizzando tale editor è possibile individuare, visualizzare e modificare i metodi di test.È inoltre possibile modificare le azioni dell'interfaccia utente e i relativi controlli associati nella mappa dei controlli dell'interfaccia utente.Per ulteriori informazioni, vedere Modifica di test codificati dell'interfaccia utente utilizzando l'editor di test codificato dell'interfaccia utente.

Istruzioni utili

Per ulteriori informazioni, vedere Test per una distribuzione continua con Visual Studio 2012 – Capitolo 5: automazione dei test di sistema.

Vedere anche

Attività

Procedura dettagliata: creazione, modifica e gestione di un test codificato dell'interfaccia utente

Procedura: inserire un ritardo prima di un'azione dell'interfaccia utente utilizzando l'editor di test codificato dell'interfaccia utente

Concetti

Verifica del codice mediante l'automazione interfaccia utente

Composizione di un test codificato dell'interfaccia utente

Configurazioni e piattaforme supportate per i test codificati dell'interfaccia utente e le registrazioni delle azioni

Altre risorse

Creazione di test codificati dell'interfaccia utente