PyUseCase

PyUseCase è un software di grafica di prova per PyGTK.
test GUI mantenibile con un caso d'uso del registratore
Registrazione l'intento, piuttosto che la meccanica
Il modo più naturale per creare test tramite un'interfaccia utente è quello di effettuare semplicemente le azioni che si desidera eseguire e avere uno strumento in grado di registrare e poi riprodurre in seguito. Questo è un modo semplice e veloce per creare test GUI ed esistono molti strumenti che fanno questo.
La maggior parte di strumenti paio delle prove strettamente alla GUI
I problemi iniziano quando si ha un paio di test e le modifiche GUI. La registrazione può essere un ottimo modo per creare le prove, ma è un modo terribile per mantenere un gran numero di loro. E 'soggetto a errori, frustrante e richiede molto tempo una volta che avete alcuni test. La prima generazione di strumenti registrato posizioni dei pixel e si è rotto, non appena si è cambiato la risoluzione dello schermo. Oggi gli strumenti affare in termini di meccanica GUI: trovare un tavolo con un certo nome e fare clic nella terza colonna della quarta fila. Possono sopravvivere schermo cambia e minori ri-arrangiamenti di GUI ma non molto altro. Gli script registrati sono densi e non trasmettono lo scopo della prova, e sono un libro chiuso a tutte le persone non tecniche (e talvolta a tutti tranne che l'autore dello strumento).
Il problema è essenzialmente di accoppiamento. Le prove e la GUI sono strettamente accoppiati tra loro e non possono comodamente variare indipendentemente l'uno dall'altro. Questo punto è fatto bene da Robert C. Martin nel suo blog qui e la sua conclusione è che il test GUI è intrinsecamente fragile e si dovrebbe fare come poco di lui, come si può farla franca.
Questo sembra piuttosto disfattista però. C'è grande valore di essere in grado di dimostrare ciò che i test fanno per un utente del sistema. Se i test bypassare l'interfaccia utente allora tale processo richiede una buona dose di abilità tecnica e un sacco di fiducia da parte del vostro utente. E comunque, gli sviluppatori di software a risolvere i problemi di accoppiamento per tutto il tempo. La risposta è, come al solito, di introdurre un altro livello di indirezione.
Rompere l'accoppiamento con una mappa UI
Uomini d'affari e degli utenti in genere lavorano in casi d'uso. Queste sono le descrizioni di alto livello di una sequenza di azioni in una lingua che comprendono: cioè quella del dominio. L'idea di un "caso d'uso del registratore" è quindi uno strumento in grado di registrare e riprodurre tali sequenze e quindi catturare l'intento dell'utente. Ciò permetterà una maggiore comprensione, meno dipendenza dal forma esatta della GUI e facile regolazione di test esistenti senza ricorrere a cliccare di nuovo tutti i pulsanti.
Il meccanismo di base è che noi manteniamo una mappatura tra le azioni che possono attualmente essere eseguite con la nostra interfaccia grafica e le dichiarazioni in questa lingua dominio. Modifiche GUI allora significa che questo singolo mappatura deve essere aggiornato, ma le prove possono rimanere intatta, continuando a descrivere ciò che deve essere fatto sul piano concettuale. Questa mappatura prende la forma di un file esterno in PyUseCase 3.0 e l'imminente JUseCase 3.0, mentre nelle versioni precedenti che prende la forma di strumentazione nel codice dell'applicazione.
Controllo del comportamento tramite registri e TextTest
Così il nostro registratore caso d'uso in grado di registrare e riprodurre casi d'uso per noi. Ma come possiamo controllare che ciò che vediamo sullo schermo è corretta? La maggior parte degli strumenti grafici farlo consentendo la script di test di contenere "asserzioni", che sembrano un po 'del widget e controllare che alcune proprietà di essa è pari ad un valore hardcoded. Ciò crea ancora più dipendenza layout grafico attuale e non possono essere "registrato" in qualsiasi modo naturale, ma deve essere programmata in dopo il fatto. No "caso d'uso" sarebbe naturalmente contenere le seguenti informazioni: se così fosse si sarebbe trasformato in uno script di test.
Questa discussione non è sul sito TextTest per niente. Se siamo in grado di ottenere solo la nostra applicazione per la produzione di una registrazione di quanto GUI sembra possiamo controllare ciò che fa attraverso il monitoraggio del contenuto di tale registro utilizzando TextTest. PyUseCase 3.0 fa per voi: si genera un tipo di registro ASCII-art dell'aspetto grafico attuale e controlla modifiche. L'applicazione può integrare con la propria registrazione come desidera. Con altri registratori casi d'uso l'applicazione deve costruire il proprio registro per questo scopo al momento.
Sincronizzazione test di codice strumentazione
Quasi tutte le attività di test GUI sono afflitti da problemi con assicurandosi lo script attende abbastanza a lungo prima di procedere quando succede qualcosa in background. Le soluzioni vanno da modi arcane attendere per qualche widget per avere un certo aspetto (ancora più dipendenze su GUI-meccanica) per le dichiarazioni "sonno" liberamente sparsi. Quale esito negativo quando viene caricato il sistema e causano i test funzionino molto più lentamente di quello che altrimenti sarebbe. Chiunque, senza una profonda conoscenza del codice è mal equipaggiato per risolvere tali problemi, ma farlo è una parte vitale del test di scrittura.
Usa-case Registratori introducono il concetto di un "Evento di applicazione". Questo è fondamentalmente una certa strumentazione nel codice che indica al registratore caso d'uso che è successo qualcosa che ha bisogno di essere aspettato, consentendo così il registratore per registrare e riprodurre attende così come scatti. Questi sono descritti in maggiore dettaglio qui.
macro di registrazione così come le prove
Di alto livello, "casi d'uso" facilmente manipolabili sono utili per altre cose che il test. Sono inoltre estremamente utile per gli utenti del sistema che può creare le proprie macro per sequenze di azioni che svolgono di frequente.
Questi sono conosciuti come "scorciatoie GUI" qui. Un registratore caso d'uso in genere consentire a un'applicazione per richiedere un "barra degli strumenti" da essa, che contiene i controlli per la registrazione e riproduzione che possono essere inseriti nella GUI dell'applicazione, se lo desideri. Oltre a consentire agli utenti di creare le macro, possono anche essere usati per creare astrazioni livello ancora più alto per la "lingua test" descritto sopra, aiutando tester nell'eseguire azioni ripetute per raggiungere un determinato schermo per il test. Questi sono descritti in maggiore dettaglio qui.
Ulteriori informazioni possono essere trovate nella home page del progetto

Cosa c'è di nuovo in questa versione:.

• Supporto di base per wxPython era ha aggiunto.
• Ci sono anche una serie di miglioramenti e correzioni di bug per PyGTK. In particolare, gtk.Dialog.run è ora supportata senza richiedere modifiche al codice sorgente.
• Python 2.6 e PyGTK 2.12 o versioni successive sono ora necessari.
• L'interfaccia basata strumentazione lascito è stato rimosso.

Requisiti

• Python
• PyGTK
• TextTest