I test Gui richiedono troppo tempo - qual è il tuo approccio?

Question

abbiamo un tipico stack di applicazioni Web. ci sono 120 test di selenio (webdriver) che vengono eseguiti contro l'applicazione. questo dura circa 1 ora. li eseguiamo come parte della nostra catena di compilazione "compile> unit test> test di integrazione> test gui". i test dell'interfaccia grafica richiedono molto tempo e ci stiamo chiedendo come strutturarli meglio. al momento sono test di casi "caso felice e infelice". sono abbastanza stabili, cioè non falliranno a causa di errori del programmatore.

vogliamo ridurre i tempi di costruzione e la maggior parte sono i test GUI. vogliamo farlo basandoci sui "viaggi del cliente", cioè specificare (insieme agli uomini d'affari) alcuni casi d'uso tipici e testarli (percorso felice) invece di testare troppo .....

come si fa a strutturare i tuoi test gui? qui ci sono alcune idee che mi sono venute in mente

• eseguire solo felice percorso mette alla prova
• fare un "test di percorso del cliente", vale a dire fare diverse prove di percorso felici in uno ("cliccando attraverso le pagine")
• solo prendere le "top 10" specificati dal business (mission critical)
• primi 10 + "tutto il resto", come nightly build (una sola volta)

Gradirei le vostre idee

grazie marcel

Answer 1

La notte è un momento perfetto per i test di selenio - devi solo ricordare di mettere un "Non spegnere me!" nota adesiva sul tuo computer :).

Inoltre, c'è sempre Selenium Grid quando la notte inizia a essere troppo breve per eseguire tutti i test. Con Grid, puoi eseguire i test su più macchine in parallelo!

Abbiamo diversi test suites applicabili a diverse situazioni. Prima di una versione principale (per testare, pre-live, produzione), tutto funziona. Solitamente (su base giornaliera o anche oraria nei giorni di punta) viene eseguita solo la suite "Il percorso normale accelerato di un utente attraverso l'applicazione". E se qualcuno "risolve" un grosso bug, allora vengono eseguiti i test relativi a quella parte dell'applicazione.

Answer 2

Un'ora mi sembra assolutamente soddisfacente.

Un suggerimento potrebbe essere quello di decidere quali test vengono sottoposti a test di fumo e devono essere eseguiti ogni notte. Vale a dire, i test che mostrano la funzionalità core principale della tua applicazione Web sono ancora intatti e funzionanti - altri test più dettagliati possono essere eseguiti in momenti diversi (una volta ogni pochi giorni?).

Detto ciò, il nostro richiede circa 2 ore: l'unico problema si presenta quando un test non è riuscito, lo si aggiusta, lo si impegna, ma poi si deve attendere molto tempo per verificare che sia stato corretto sul server CI.

Answer 3

TeamCity consente di eseguire build in parallelo sulla stessa macchina, quindi i test della GUI non dovrebbero essere nella catena di build insieme ai test di unità e integrazione. I test dell'interfaccia utente dovrebbero avere un database separato e una build separata in modo da non perdere tempo da sviluppatori, tester manuali o altri stakeholder. TeamCity raccoglierà tutte le statistiche, invierà e-mail su errori di compilazione e così via.
Il passo successivo è la parallelizzazione.Come Slanec ha dichiarato che è possibile utilizzare la griglia (non sono necessarie diverse macchine) con Mbunit (C#) o TestNG (java). Con l'aiuto di Grid puoi ridurre il tempo di esecuzione dei test, ad es. di 10 volte quindi ci vorranno solo 6 (!) minuti per eseguire tutti i test.
Inoltre puoi combinare alcuni dei tuoi test in quelli più grandi (ma questo porterà a tempi crescenti per scoprire i motivi del fallimento e rendere i test difficili da mantenere).
Dopo questi passaggi, i test Gui possono essere eseguiti dopo ogni commit di origine e fornire una risposta rapida sullo stato degli errori dell'applicazione.

Answer 4

Ottima domanda, grandi risposte.

Un'altra considerazione è che è possibile dare la priorità ai test da 120 gui: è possibile eseguirli in un ordine in modo tale che i più importanti o quelli che hanno maggiori probabilità di errore vengano eseguiti per primi. Questo non aiuta a ridurre i tempi di compilazione, ma aiuta a ottenere un feedback utile da una build più veloce.

Questa priorità (la top 10) non deve essere corretta, ma può cambiare per versione/iterazione/storia/giorno completata, ecc. Ad esempio, è possibile eseguire prima i test più recenti. O quelli che sono stati modificati più di recente. O quelli che coprono la maggior parte del codice che è stato modificato più di recente.

Per quanto ne so, non ci sono strumenti in grado di supportarlo immediatamente, anche se c'è una certa ricerca (accademica) in corso nell'area di prioritizzazione dei casi di test.