So che questa è una domanda molto semplice. Per alcune applicazioni software esiste un numero quasi infinito di casi di test per un'applicazione. Non è pratico testare tutti i casi di test. Come decidiamo quando interrompere i test? (diverso da "quando i soldi si esauriscono").
Il libro di Glenford Myers L'arte del test del software ha un principio semplice ma ben fondato regola per questo: il test è completo quando hai smesso di trovare bug. O, più praticamente, quando la velocità con cui trovi nuovi bug rallenta notevolmente.
I bug tendono a "cluster" in alcuni moduli e in determinate funzioni: nel momento in cui trovi un bug in uno, sai che dovresti cercare ulteriormente altri bug. Per trovare i bug, puoi utilizzare il tecniche di blackbox testing, whitebox testing e test di mutazione. Finché trovi bug, sai che il tuo processo di test funziona!
Per visualizzare i tuoi progressi, mostra il numero di bug che la tua squadra ha trovato al giorno. Se il grafico si abbassa, allora sai che le tecniche utilizzate dalla tua squadra non le troveranno comunque. Certo, se credi che le tue tecniche non siano all'altezza, allora leggi il libro di Myers e applica i principi.
Ora, c'è una possibilità che potresti essere a corto di mancanza di una nuova patch di bug, e il tasso di individuazione dei bug sarebbe notevolmente aumentato se avessi continuato a testare per un po 'di più. Tuttavia, se ritieni che le tue tecniche siano valide, è improbabile.
La risposta semplice dipende dal sistema. Se stai scrivendo software embedded per un monitor cardiaco o strumenti di monitoraggio della sicurezza per un reattore nucleare, lo standard è molto più alto rispetto a quando stai scrivendo una piattaforma di blogging.
Questa è davvero una domanda per un buon tester di sistema (e io non ne sono uno) ma ci provo.
La tua misura di base sarà la copertura del test: quanta parte dell'applicazione è stata effettivamente testata (sia per test unitario che funzionalmente).
Devi valutare ogni potenziale caso d'uso (e parametri per quel caso d'uso) per la probabilità che venga effettivamente utilizzato (quindi potresti abbandonare i casi limite), complessità (le cose più semplici hanno meno probabilità di contenere errori, o meno probabilmente contenere bug difficili da trovare), costo da testare (in termini di tempo) e potenziale impatto di un difetto se scoperto in quell'area (è qui che entra in gioco il reattore nucleare e la piattaforma di blogging).
Sulla base di tale valutazione è necessario capire quali di questi verranno testati e in quanti dettagli. Una volta che hai una lista del genere, il team (incluso un product manager / project manager / rappresentante degli utenti) può consultare l'elenco e stabilire la priorità in base ai vincoli che hai.
Una tecnica utile a cui pensare è che puoi anche variare i casi d'uso che sono testati con ogni versione. Ad esempio potresti avere una lista di casi di test non critici e testarne metà con una versione e metà con la successiva (poi alternata). In questo modo aumenterai la copertura totale del test per lo sforzo (anche se a rischio di introduzione di bug di regressione).
Ciò potrebbe estendersi anche ai test della piattaforma: se supporti due back-end del database (o più browser), prova metà della app su una, l'altra metà sull'altra e poi cambia la prossima versione.
(Penso che questo si chiami come striping ma non citare me su quello.)
E poi l'ultima cosa a cui pensare non è ciò che si prova ma ciò che si risolve effettivamente quando vengono scoperti i problemi. È normale dire "correggi tutti i bug" ma la realtà è che ci sono delle pressioni temporali e non tutti i bug sono uguali. Anche in questo caso, la pulizia del bug regolare con tutte le parti interessate è la migliore strada da seguire. Ciò è particolarmente rilevante quando una correzione di bug può essere particolarmente intrusiva in quanto il lavoro aggiuntivo di test e test di regressione che genera può superare il vantaggio della correzione.
Quando il rischio associato all'uso del software è stato ridotto a un livello accettabile.
"I test del programma possono essere utilizzati per mostrare la presenza di bug, ma mai per mostrare la loro assenza!" --Edatore Dijkstra
Qualcosa di buono da tenere a mente quando si fanno test, automatizzati o meno. Puoi solo provare che non hai trovato altri bug, non che non ce ne sono più.
Ma più occhi metti su una sezione di codice, più puoi essere sicuro della sua corretta operatività. È molto simile alla citazione di Knuth sull'ottimizzazione in questo senso: puoi testare le cose sbagliate molto facilmente, e puoi testare i momenti sbagliati nel tuo sviluppo.
Essenzialmente, vuoi essere coperto in due grandi posti:
Il software supera i test BDD che dimostrano che soddisfa i requisiti specificati. Il software non può nemmeno essere chiamato fatto se questo non è vero.
I segmenti più critici, complessi e insicuri hanno test adeguati per fornire sicurezza? Se si tratta di un core loop, o qualcosa che dovevi ottimizzare o hackerare: mettici un test. Se è complicato e ha molte divisioni logiche: mettici un sacco di test su di esso. Se non riesci a testare l'unità, o se è incorporata troppo in profondità per testare praticamente direttamente: assicurati che il codice sia stato revisionato e il codice indirettamente testato a mano.
Se aspetti che il progetto finisca, avrai davvero un numero molto grande di casi di test. Se consegni continuamente, concentrandoti su piccole consegne, avrai meno casi di test a ogni iterazione e sarai in grado di testare tutto. Se non riesci a eseguire piccole consegne, assegna le priorità e avvia i test dalla massima priorità e vai a testare fino a quando non devi fermarti.
Se stai parlando di test unitari e stai facendo TDD (scrivendo prima i test), questo non è un problema: basta interrompere il test quando le funzioni sono terminate.
In TDD incrementale, scrivi un test che fallisce, quindi implementa la più piccola quantità di codice che può farlo passare, quindi refactoring. Continua ad aggiungere test in questo modo finché il metodo non è completo.
Ecco un ottimo esempio.
Anche gli statistici hanno preso in considerazione questo problema - in realtà già negli anni 1970-80. Date le ipotesi appropriate su come vengono scoperti i bug, tentano di stimare il numero di bug dai dati del test. Questo viene quindi utilizzato per determinare quando interrompere in base all'ottimizzazione di una funzione di perdita. Vedi ad esempio link ... per un breve trattamento di uno dei documenti su questo problema, incluso il codice R su come farlo in pratica.
Ovviamente un problema sarà sempre l'ipotesi sul processo di scoperta dei bug. Ad esempio, nel trattamento di cui sopra si presume che i bug vengano scoperti indipendentemente l'uno dall'altro. In pratica, correggere un grosso bug può, ad esempio, causare nuovi bug, ecc. Ma dà un inizio e un senso di intolleranza.
Quando è arrivata la data di spedizione. Non c'è fine alla sperimentazione di un software. Ma poi di nuovo c'è qualcosa di noto come programma. Dovrai testare la maggior parte delle tue funzionalità nei tempi programmati e correggere i bug che incontri. Non c'è modo di garantire che il software sia perfetto.
Le prime cose da testare sono il "percorso felice", i casi limite e gli input non validi. Se ci sarà più di un utente concorrente, dovrai testare problemi di concorrenza come il blocco e le condizioni di gara. Se l'app utilizza risorse esterne, dovrai verificare come si comporta l'applicazione quando tali risorse non sono disponibili. Dopodiché, puoi usare il codice per cercare elementi che potrebbero causarne la rottura e testare quelli. Quando passano tutti questi test, il rapporto costi / benefici di ulteriori test inizia a salire, quindi è ragionevole fermarsi a quel punto.
Tutto si riduce a una questione di fiducia. Ti senti sicuro che il sistema è stato testato abbastanza?
Ovviamente, il "livello di confidenza" è molto soggettivo poiché non puoi mai sentirti completamente sicuro, ma abbastanza sicuro - e questo è ciò che stiamo cercando. Per questo, è necessario creare un elenco di indicatori, comunemente noto come definizione di fatto e dovrebbe essere qualcosa su cui tutto il tuo team è d'accordo.
Ecco alcuni "indicatori di Done" correlati al test:
Se riesci a controllare questi punti, probabilmente puoi affermare di aver provato abbastanza.
Mai, penso che non finirai mai i test in un sistema .. ci sono tantissime variabili che non puoi gestire.
Ma, come sappiamo, non puoi testare "per sempre", quindi penso che il limite dipenda fondamentalmente da:
Quando le persone che devono firmare sulla distribuzione sono soddisfatte.
o in alcuni casi la maggioranza delle parti responsabili è soddisfatta.
Leggi altre domande sui tag testing development-process