Domanda

Sto lavorando sulla questione del test della mia GUI e non sono del tutto sicuro dell'approccio migliore qui.La mia GUI è costruita utilizzando un framework MVC tradizionale, quindi posso facilmente testare le parti logiche della GUI senza visualizzare la GUI stessa.Tuttavia, quando si tratta di testare la funzionalità della GUI, non sono sicuro se dovrei preoccuparmi di testare individualmente i componenti della GUI o se dovrei concentrarmi principalmente solo sul test funzionale del sistema.È un sistema piuttosto complesso in cui testare frequentemente la GUI implica l'invio di un messaggio al server e quindi l'osservazione della risposta sulla GUI.Il mio pensiero iniziale è che i test funzionali siano la strada da percorrere qui poiché ho bisogno di un intero sistema in esecuzione per testare davvero l'interfaccia utente.Sarebbero graditi commenti su questo argomento.

Grazie, Jeff

È stato utile?

Soluzione

Hai (almeno) 2 problemi: la complessità dell'ambiente (il server) e la complessità della GUI.

Esistono molti strumenti per automatizzare i test della GUI.Tutti sono più o meno fragili e richiedono una manutenzione praticamente costante a fronte dei cambiamenti di layout.C'è un vantaggio da ottenere dal loro utilizzo, ma è un vantaggio a lungo termine.

L’ambiente, invece, è un’area che può essere domata.Se la tua applicazione è progettata utilizzando la tecnica di inserimento/inversione delle dipendenze (in cui si "inietta" il componente server nell'applicazione), è possibile utilizzare una "finta" delle interfacce server pertinenti per consentire di creare script di casi di test.

La combinazione di queste due tecniche ti consentirà di automatizzare i test della GUI.

Un ultimo pensiero: buona fortuna!

Altri suggerimenti

Altri strumenti di test della GUI che posso offrire sono:Pensieri bianchi, PyWinAuto, AutoIt, AutoHotKey.

Una cosa da tenere a mente quando si tenta di automatizzare le GUI è che l'unico modo per farlo è creare la GUI pensando all'automazione.Schiaccia gli sviluppatori che pensano che le loro GUI non dovrebbero supportare la testabilità nelle prime fasi del progetto ed esponi felicemente tutti gli hook che possono aiutare nell'automazione su richiesta poiché le tue esigenze di test lo richiedono.

A seconda di dove ti trovi nello spettro di MVC (è un termine abusato), testare la vista potrebbe essere un processo meccanico per garantire che i metodi del modello corretti vengano chiamati in risposta agli input corretti alla vista per testare alcune validazioni lato client per chi lo sa.

Molti dei modelli che si sono evoluti da MVC (sto pensando visione passiva, controllore supervisore) stanno cercando di fare in modo che la visualizzazione richieda pochissimi test perché in realtà si tratta solo di collegare gli input dell'utente al presentatore o al modello (a seconda dell'esatta variante del modello che stai utilizzando).

"testare frequentemente la GUI comporta l'invio di un messaggio al server e quindi l'osservazione della risposta sulla GUI" Questa affermazione mi preoccupa.

Penso immediatamente che la GUI dovrebbe essere testata utilizzando un mock o uno stub del server per verificare che si verifichino le interazioni corrette e che la GUI risponda in modo appropriato.

Se sono necessari test funzionali automatizzati del server, non vedo la necessità di coinvolgere la GUI.

Mercury QuickTest Pro, Borland SilkTest e Ranorex Recorder sono alcuni strumenti di test della GUI.

Se la tua applicazione è basata sul Web puoi scrivere test utilizzando strumenti come WatiN O Selenio.

Se la tua applicazione è basata su Windows .NET, puoi provare Bianco.

Il mio consiglio:dimentica i tradizionali test della GUI.È troppo caro.La codifica dei test richiede molto tempo, gli strumenti non sono realmente stabili, quindi otterrai risultati dei test inaffidabili.L'accoppiamento tra il codice e il test è molto forte e dedicherai molto tempo alla manutenzione.

La nuova tendenza è ignorare i test della GUI.Vedere il modello ModelViewPresenter di Fowler come linea guida testo del collegamento

Il modo più chiaro in cui posso dirlo è:

Non perdere tempo a scrivere test GUI automatizzati.

Soprattutto quando lavori con un'app MVC: nel tuo caso, quando invii un messaggio al server, puoi assicurarti che il numero di messaggio corretto ritorni e venga eseguito.Puoi aggiungere alcuni casi aggiuntivi o un altro test completo per assicurarti che la GUI stia convertendo gli ID del messaggio nelle stringhe corrette, ma devi solo eseguire quel test una volta.

Incorporiamo il test della GUI nel nostro progetto e ha i suoi effetti collaterali.Gli sviluppatori tuttavia hanno un principio di progettazione fondamentale: Mantieni il livello della GUI il più sottile possibile!

Questo significa nessuna logica nelle classi della GUI.Separarlo nei modelli di presentazione responsabili della convalida dell'input, ecc.

Per i test su una macchina Unix utilizziamo il server Xvfb come DISPLAY durante l'esecuzione dei test.

Prova il test di usabilità del corridoio.È economico e utile:vai nel corridoio più vicino, prendi la prima persona che passa, falla sedere davanti al tuo computer e usa il tuo software.Guarda oltre le loro spalle, vedrai cosa cercano di fare, cosa li frustra e così via.Fallo alcune volte e nota gli schemi.

Quello che stai cercando è "test di accettazione". Il modo in cui lo fai dipende dai framework che stai usando, che tipo di applicazione stai creando e in quale lingua.Se cerchi su Google la tua particolare tecnologia e la frase sopra, dovresti trovare alcuni strumenti che puoi utilizzare.

ho trovato WinTask essere un ottimo modo per eseguire test della GUI.A condizione che non si cambi costantemente il modo in cui il sistema operativo fa riferimento a ciascun elemento dell'interfaccia utente, WinTask indirizza gli elementi dell'interfaccia utente per nome, quindi anche se il layout cambia, gli elementi dell'interfaccia utente possono comunque essere premuti/modificati/selezionati.

Da non perdere la "U" in "GUI"
Intendo:se quello che stai cercando di testare funziona bene e funziona come previsto, allora puoi seguire La risposta di Seb Rose.

Ma per favore, non dimenticare a L'interfaccia UTENTE deve essere realizzata pensando agli UTENTI, e non QUALSIASI utente ma l'UTENTE TARGET per il quale è stata creata la domanda.Quindi, dopo che sei sicuro che tutto funzioni come deve funzionare, metti alla prova ogni singola visualizzazione/schermata/modulo con un team composto da utenti che rappresentano ogni gruppo di utenti diversi che potrebbero utilizzare la tua applicazione:utenti avanzati, amministratori, utenti di MS Office, utenti di basso profilo di computer, utenti di alto profilo di computer...e poi, raccogli le critiche di ogni utente, crea un mix, ritocca la tua GUI se è necessario e torna di nuovo al test dell'utente della GUI.

Per provare SEMPLICE test GUI basato sul Web iMacros (Un semplice plug-in Firefox, ha una funzionalità interessante per inviare l'intero test a un'altra persona) Nota che Simple è stato scritto con le iniziali ...

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top