Esecuzione di test di automazione dell'interfaccia utente sul server di build

Question

Usiamo UI Automation e Nunit per creare test UI test per l'applicazione WPF. Abbiamo creato test che funzionano bene quando li esegui da un computer locale. Questi test non vengono mai eseguiti correttamente sul nostro server di build (utilizzando TeamCity). Build si blocca sempre dopo aver aperto la finestra dell'applicazione. Ma se ho effettuato l'accesso (desktop remoto), sul nostro server di build vengono eseguiti correttamente anche tutti i test di automazione dell'interfaccia utente. Quindi immagino che probabilmente abbia qualcosa a che fare con l'esecuzione della sessione di Windows attiva. Qualche idea su come convincere il nostro server di build a creare una sessione di Windows attiva o qualsiasi altra soluzione per eseguire quei test sul server di build?

Answer 1

Non hai molte opzioni. Elencherò i due che conosco, prima l'opzione preferita:

• Imposta una macchina virtuale sul tuo server di build. Le build vengono eseguite nella macchina virtuale. Puoi bloccare l'host (alias tuo buildserver) mantenendo le cose al sicuro.
• Mantieni sempre qualcuno connesso. Questo rapporto di lavoro crea un problema di sicurezza. Puoi alleviare un po 'questo problema rimuovendo il mouse, la tastiera e lo schermo e accedi al buildserver solo tramite RDP o qualcosa di simile.

---

Modifica

Dai un'occhiata a questo TestComplete FAQ : Può TestComplete eseguire script quando il computer è bloccato?

Answer 2

OK, sto solo indovinando qui.

Prova ad eseguire il servizio TeamCity con un utente del server di build locale anziché con l'account di sistema. Forse devi accedere con quell'account una volta, prima di iniziare una nuova build.

Answer 3

Sembra che tu abbia bisogno di eseguire i test con una sessione interattiva invece di un servizio. Aggiunta di " Consenti al servizio di interagire con il desktop " potrebbe aiutare, ma questo non è più supportato in Vista apparentemente.

Se puoi eseguire i tuoi build interattivi come una riga di comando, non un servizio che dovrebbe funzionare anche.

Eseguivamo i nostri test UIAutomation utilizzando l'agente di caricamento di Visual Studo 2008 per distribuirli, eseguendo come strumento da riga di comando su VM senza problemi.

Sono anche d'accordo sul fatto che probabilmente non dovresti eseguire test dell'interfaccia utente su un server di build una parte della tua build giornaliera.

Answer 4

  

Build si blocca sempre dopo aver aperto la finestra dell'applicazione.

Test che istanziano l'interfaccia utente? Non funzionerà, ad es. se ottieni una finestra di dialogo modale la build si bloccherà. Questo è il motivo per cui è stato inventato il modello MVP, per isolare il codice di presentazione attivo da una vista concreta.

Stai usando una vista simulata nei tuoi test automatici?