Utilizziamo UI Automation e Nunit per creare test di test dell'interfaccia utente per l'applicazione WPF. Abbiamo creato test che funzionano correttamente 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 sono connesso (desktop remoto), sul nostro server di compilazione anche tutti i test di UI Automation vengono eseguiti correttamente. 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 Windows attiva o altre soluzioni per eseguire tali test sul build server?Esecuzione di test di automazione dell'interfaccia utente sul server di build
risposta
Non hai molte opzioni. Io elenco i due che conosco, l'opzione più preferito prima:
- configurare una macchina virtualesul server di build. Le tue build vengono eseguite nella macchina virtuale. Puoi bloccare l'host (ovvero il tuo buildserver) mantenendo le cose sicure.
- Tenere qualcuno connesso tutto il tempo. Questo offcourse crea un problema di sicurezza. È possibile alleviare questo problema un po 'rimuovendo il mouse, la tastiera e lo schermo e accedere solo al buildserver tramite RDP o qualcosa di simile.
Modifica
Date un'occhiata a questo TestComplete FAQ articolo: Può TestComplete eseguire script quando il computer è bloccato?
OK, sto solo indovinando qui.
Provare ed eseguire il servizio TeamCity con un utente del server di generazione locale anziché con l'account di sistema. Forse devi effettuare il login con quell'account una volta, prima di iniziare una nuova build.
L'abbiamo già provato.Quando ho detto se sono connesso (desktop remoto), sul nostro server di compilazione anche tutti i test di UI Automation sono eseguiti correttamente, sono stato registrato come quell'utente e tutti i test sono in esecuzione sotto quell'utente. Il problema è, il secondo quando questo utente è bloccato test fallito. Hanno anche fallito se li eseguivo sul computer locale e bloccavo il computer durante l'esecuzione. – andreja
Sembra proprio che sia necessario eseguire i test con una sessione interattiva anziché con un servizio. Aggiungere "Permetti al servizio di interagire con il desktop" può essere di aiuto, ma questo non è più supportato in Vista.
Se è possibile eseguire le build interattive come riga di comando, non è un servizio che dovrebbe funzionare.
Abbiamo utilizzato i nostri test di UIAutomation utilizzando l'agente di caricamento 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 come parte della tua build giornaliera.
Grazie, ma come menzioni i servizi non sono più autorizzati a interagire con il desktop dell'utente in Vista e Windows Server 2008. Utilizziamo Windows server 2008. L'esecuzione come utente della console blocca anche il desktop e genera errori. – andreja
La generazione si blocca sempre dopo l'apertura della finestra dell'applicazione.
Test che creano un'istanza dell'interfaccia utente? Non funzionerà, ad es. se si ottiene una finestra di dialogo modale, la generazione si bloccherà. Questo è il motivo per cui è stato inventato il modello MVP, per isolare il codice di presentazione attivo da una vista concreta.
Si sta utilizzando una simulazione di test automatici?
Non credo che non funzionerà :) Non stiamo usando la vista finta. – andreja
Sebbene la progettazione del codice UI per essere testabile risolva una moltitudine di problemi, ci sono ancora alcuni scenari in cui si desidera testare cose che richiedono semplicemente un ambiente interattivo affinché il test sia significativo. (Non necessariamente test unitari, ma vuoi automatizzare anche i test di integrazione, giusto?) –
A volte vuoi solo verificare che facendo clic su un pulsante si apra la finestra di dialogo appropriata. (VUOI testare l'interfaccia utente.) – BrainSlugs83
Eseguiamo tutte le build nella macchina virtuale sul nostro server di build. E tutti i test vengono eseguiti con un account locale (non sistema). Non ha risolto il problema. Mantenere qualcuno connesso tutto il tempo non è un'opzione. Come ho detto, abbiamo 3 macchine virtuali, in cui questa build può essere eseguita. Quindi ogni volta che la build sceglie il vm più veloce disponibile. L'utente locale su VM è normalmente connesso, ma non possiamo assicurarci che non sia bloccato. E vorremmo davvero automatizzare questo processo il più possibile, quindi l'accesso manuale è l'opzione meno attraente. – andreja
@andreja, Ho aggiornato la risposta con un collegamento alla domanda e risposta di Testcomplete. Dubito che ci sia un altro modo per aggirare questo. Devi tenere qualcuno connesso. Non vedo dove questo pone un problema di sicurezza quando la VM è "sbloccata" e l'host è "bloccato" (ma non sono un amministratore di sistema). –
@andreja: se si desidera automatizzare l'accesso, è possibile impostare alcuni valori di chiave del Registro di sistema e l'utente di creazione verrà registrato dopo l'avvio della VM di compilazione. Se vuoi, posso cercare le chiavi di reg corrispondenti. –