Come ridurre il tempo speso per il test?

Question

Ho appena guardato indietro nel progetto che è quasi finito di recente e ho trovato un problema molto serio. Ho passato la maggior parte del tempo in banca a testare il codice, riproducendo le diverse situazioni "potrebbe" causare errori di codice.

Hai qualche idea o esperienza da condividere su come ridurre il tempo speso per i test, in modo da rendere lo sviluppo molto più fluido?

Ho provato a seguire il concetto di test-driven per tutto il mio codice, ma ho trovato davvero difficile ottenerlo, ho davvero bisogno di aiuto da parte dei ragazzi senior qui.

Grazie

Re: tutte

Grazie per le risposte di cui sopra qui, inizialmente la mia domanda è stata come ridurre il tempo sulla prova generale, ma ora, il problema è giù a come scrivere l'automatizzare efficiente codice di prova

Cercherò di migliorare le mie capacità su come scrivere la prova per ridurre questa parte di tempo.

Tuttavia, ho ancora molta difficoltà a ridurre il tempo impiegato per riprodurre gli errori, ad esempio, un progetto di blog standard sarà facile da riprodurre, le situazioni potrebbero causare errori, ma un sistema interno su misura potrebbe non essere "mai" "può essere testato facilmente, è degno? Hai qualche idea su come costruire un piano di test su questo tipo di progetto?

Grazie ancora per le ulteriori risposte.

Answer 1

Il test di progettazione non riguarda il test (controllo qualità). È stato mal chiamato fin dall'inizio.

Si tratta di avere presupposti eseguibili dalla macchina e specifiche del comportamento del programma e viene svolto dai programmatori durante la programmazione per garantire che le ipotesi siano esplicite.

Poiché tali attività devono essere eseguite in un determinato momento del ciclo di vita del prodotto, è semplicemente uno spostamento del lavoro. Se è più o meno efficiente è un dibattito per un'altra volta.

Ciò a cui si fa riferimento non chiamerei test. Avere un forte TDD significa che la fase di test non deve essere invocata pesantemente per gli errori che potrebbero essere catturati molto prima che raggiungano una build di test (come lo sono i programmatori esperti con una buona spec e stakeholder reattivi in ​​un non-TDD ambiente).

Se pensate che i test in anticipo (runnable spec) siano un problema serio, immagino si tratti di quanto lavoro ci si aspetta che le relative fasi di sviluppo costino in termini di tempo e denaro?

Answer 2

Non c'è niente di intrinsecamente sbagliato quando si impiega molto tempo a testare se si prova in modo produttivo. Tenete a mente, lo sviluppo basato sui test significa scrivere i test (per lo più automatizzati) per primi (questo può richiedere molto tempo se si scrive una suite di test approfondita). Eseguire i test non dovrebbe richiedere molto tempo.

Answer 3

Il team di Subversion ha sviluppato un po 'di pretty good test routines, automatizzando l'intero processo.

Ho iniziato a utilizzare questo processo personalmente, ad esempio scrivendo i test prima dello implementando le nuove funzionalità. Funziona molto bene e genera test coerenti attraverso l'intero processo di programmazione.

SQLite ha anche un sistema di test decente con alcuni very good documentation su come è fatto.

Answer 4

Sembra che il tuo problema sia che non stai facendo test automatici. L'uso di test automatici di integrazione e unità può ridurre notevolmente il tempo impiegato per i test.

Answer 5

Nella mia esperienza con lo sviluppo basato su test, il risparmio di tempo arriva ben dopo aver scritto i test, o almeno dopo aver scritto i casi di test di base. La cosa fondamentale è che devi effettivamente scrivere i nostri test automatici. Il modo in cui hai formulato la tua domanda mi porta a credere che in realtà non stavi scrivendo test automatici. Dopo aver scritto i test, è possibile tornare indietro in un secondo momento e aggiornare i test per coprire i bug che non hanno trovato in precedenza (per un migliore test di regressione) e si può facilmente e velocemente ritoccare il codice con la semplicità che il codice funziona ancora come previsto dopo che l'hai sostanzialmente cambiato.

Answer 6

Una delle cose più difficili di qualsiasi progetto di dimensioni significative è la progettazione dell'archetettura sottostante e dell'API. Tutto questo è esposto a livello di test unitari. Se stai scrivendo prima i test, allora quell'aspetto del design si verifica quando codifichi i tuoi test, piuttosto che la logica del programma. Ciò è aggravato dal maggiore sforzo di rendere il codice testabile. Una volta che hai i tuoi test, la logica del programma è di solito abbastanza ovvia.

Detto questo, sembra che ci siano alcuni interessanti costruttori di test automatic all'orizzonte.

Answer 7

In primo luogo, è bene che si riconosce che hai bisogno di aiuto - ora andare a cercare un po ':)

L'idea è quella di utilizzare i test per aiutare a pensare a ciò che il codice dovrebbe fare, sono parte del tuo tempo di progettazione.

Si dovrebbe anche pensare al costo totale di proprietà del codice. Qual è il costo di un bug che passa alla produzione anziché essere prima riparato? Se sei in una banca, ci sono serie implicazioni nell'ottenere i numeri sbagliati? A volte, le cose giuste richiedono solo tempo.

Answer 8

Penso di aver capito. Sopra il livello di test degli sviluppatori, hai il livello di test del cliente, e suona come, a quel livello, trovi molti bug.

Per ogni bug che trovi, devi fermarti, togli il cappello di prova, metti il ​​cappello di riproduzione e calcola una precisa strategia di riproduzione. Quindi devi documentare il bug, magari metterlo in un sistema di tracciamento dei bug. Quindi devi mettere il cappello di prova su. Nel frattempo, hai perso qualsiasi configurazione su cui stavi lavorando e hai perso traccia di dove ti trovavi su qualunque piano di test stavi seguendo.

Ora, se ciò non dovesse accadere, se aveste molti bug, potreste fare i conti con i test, giusto?

È improbabile che l'automazione del test di guida con GUI possa aiutare a risolvere questo problema. Trascorrerai una grande quantità di tempo nella registrazione e nel mantenimento dei test, e quei test di regressione richiederanno una buona quantità di tempo per restituire l'investimento. Inizialmente, andrai molto più lentamente con la GUI, guidando i test rivolti ai clienti.

Quindi (invio) che ciò che potrebbe veramente aiutare è la qualità superiore/iniziale/codice che esce dalle attività di sviluppo. I micro-test, chiamati anche test degli sviluppatori o sviluppo guidato dai test in senso originale, potrebbero davvero essere d'aiuto. Un'altra cosa che può aiutare è la programmazione delle coppie.

Supponendo che non si possa prendere qualcun altro da accoppiare, passerei un'ora a guardare il sistema di tracciamento dei bug. Guarderei i 100 difetti passati e cerco di categorizzarli in cause principali. "Problema di allenamento" non è una causa, ma potrebbe essere "un errore".

Una volta che li hai catalogati e contati, inseriscili in un foglio di calcolo e ordinali. Qualunque sia la causa principale si verifica il più spesso è la causa principale che si impedisce prima. Se vuoi davvero essere fantasioso, moltiplica la causa principale di un numero che è la quantità di dolore che provoca. (Esempio: se in quei 100 bug hai 30 errori di digitazione nei menu, che sono facili da correggere, e 10 errori javascript difficili da riprodurre, potresti voler risolvere prima il problema di javascript.)

Questo presuppone che tu possa applica qualche "correzione" magica a ciascuna di quelle cause principali, ma vale la pena provare. Ad esempio: Le icone trasparenti in IE6 potrebbero essere perché IE6 non è in grado di elaborare facilmente i file .png. Quindi ha un trigger di controllo della versione che rifiuta .gif al momento del check-in e il problema è risolto.

Spero che questo aiuti.

Answer 9

hai scritto:

"Grazie per le risposte di cui sopra qui, inizialmente la mia domanda era come ridurre il tempo sulla prova generale, ma ora, il problema è giù a come scrivere il codice di prova automatico automatizzato . "

Un metodo che è stato dimostrato in più studi empirici per funzionare estremamente bene per massimizzare l'efficienza di test è il test combinatorio. In questo approccio, un tester identificherà CHE TIPI di cose dovrebbero essere testati (e li inserirà in un semplice strumento) e lo strumento identificherà COME testare l'applicazione. Nello specifico, lo strumento genererà casi di test che specificano quali combinazioni di condizioni di test devono essere eseguite in quale script di test e l'ordine in cui ogni script di test deve essere eseguito.

Nel August, 2009 IEEE Computer article I co-wrote with Dr. Rick Kuhn, Dr. Raghu Kacker, and Dr. Jeff Lei, ad esempio, si evidenzia un progetto di 10 studio ho condotto dove un gruppo di tester utilizzava i loro metodi di progettazione di test standard e un secondo gruppo di tester, testando la stessa applicazione, usava un generatore di casi di test combinatorio per identificare i casi di test per loro. I team che utilizzano il generatore di casi di test combinatori hanno rilevato, in media, più del doppio di difetti per ora del tester. Questa è una prova evidente dell'efficienza. Inoltre, i tester combinatori hanno trovato il 13% in più di difetti nel complesso. Questa è una forte prova di qualità/completezza.

Questi risultati non sono insoliti. Ulteriori informazioni su questo approccio sono disponibili su http://www.combinatorialtesting.com/clear-introductions-1 e la panoramica degli strumenti here. Contiene schermate e spiegazioni su come il nostro strumento rende i test più efficienti identificando un sottoinsieme di test che massimizzano la copertura.

anche la versione gratuita del nostro generatore di test case Hexawise sono disponibili all'indirizzo www.hexawise.com/users/new