In che modo la tecnica di test UI codificata è più favorevole di qualsiasi altra tecnica di test? Qual è il vantaggio principale dell'uso di un test dell'interfaccia utente codificato?
In che modo la tecnica di test UI codificata è più favorevole di qualsiasi altra tecnica di test? Qual è il vantaggio principale dell'uso di un test dell'interfaccia utente codificato?
I seguenti sono i vantaggi del test dell'interfaccia utente:
Ci sono anche molti svantaggi, principalmente che sono più fragili, quindi più difficili da mantenere e creare - ho trovato che di solito è vero.
Un'altra cosa contro di loro è che in genere i test dell'interfaccia utente richiedono un sistema dedicato (è necessaria l'interfaccia utente e nessun altro programma in esecuzione), diversamente dai test delle unità in cui è possibile eseguire 5 in parallelo. Ciò li rende impossibili da eseguire sul computer di uno sviluppatore prima di ogni check-in.
Poi hai tempo di esecuzione, il che rende molto difficile eseguirli ad ogni check-in. Nella maggior parte degli scenari i test dell'interfaccia utente vengono eseguiti solo di notte, settimanalmente o persino manualmente.
Esistono molte varianti di test piramide . La maggior parte delle persone afferma che ci dovrebbero essere molti più test unitari rispetto ai test dell'interfaccia utente, e per applicazioni ragionevolmente complesse anche altri tipi di test.
Non c'è nessuna ragione per cui i team utilizzano i test della GUI come parte del loro programma di integrazione o di test del sistema, e nessun tipo di test è il migliore in tutte le situazioni. Un rapido elenco di vantaggi basato su un articolo di Alvin Alexander :
Dove ho usato il test della GUI più estesamente è stato quando abbiamo dovuto supportare una GUI complessa su una grande matrice di sistemi. Avevamo un'app desktop per Windows che doveva essere eseguita su XP, Vista, 7 e un paio di sistemi operativi MS server, con alcuni extra dovuti ai service pack. Dal momento che abbiamo interagito con Microsoft Office, quelle varianti sono state moltiplicate dalle versioni di Office che abbiamo supportato. Quindi ogni versione doveva avere uno script di prova di parecchie ore di durata su ognuna delle 20 combinazioni dispari. Non è fattibile fare a meno di una serie di macchine virtuali e uno strumento di test della GUI.
Abbiamo registrato un numero di sessioni di utenti reali e gli analisti aziendali hanno generato i propri test, oltre al team di test aggiunto. Anche con l'eliminazione regolare degli script di test ci sono volute ore per eseguire il set completo.
Si noti che esistono due ampie categorie di strumenti. Gli strumenti "universali" registrano i clic del mouse / i tasti e confrontano gli screenshot. Gli strumenti di "ispezione" interrogano il programma sotto test per trovare i controlli e leggere i risultati. Molti strumenti possono fare entrambi e alcuni hanno librerie che puoi creare nel tuo programma per facilitare i test. I confronti degli screenshot sono sempre disponibili ma molto fragili (in XP abilitare il cambio di lingua della tastiera rende la barra delle applicazioni un pixel più in alto, come esempio di qualcosa che ha rotto un'intera serie dei nostri test). Ma gli strumenti intelligenti possono intervenire se i comandi vengono spostati, rinominati o il tipo di controllo cambia.
Considera la piramide di test nella parte superiore dell'interfaccia utente. Nel contesto di wpf con mvvm questo significa che l'unità testerà il tuo modello il più possibile. Quindi testiamo il tuo modello di visualizzazione il più possibile. Ciò lascia un po 'inesplorato l'interfaccia utente ed è qui che entra in gioco il test ui codificato. Quindi un po' di test dell'interfaccia utente codificato sarebbe probabilmente una cosa goood. Se lo usi troppo, testerai troppo e i test saranno lenti. In pratica, basta verificare che le perperle siano mapper correttamente per il modello di visualizzazione.
Leggi altre domande sui tag wpf visual-studio-2012