Come sapere quando interrompere il test?

So che questa è una domanda molto basilare. Per alcune applicazioni software esiste un numero quasi infinitamente elevato di casi di test per un'applicazione. Non è pratico testare tutti quei casi di test. Come decidiamo quando interrompere i test? (diverso da "quando finiscono i soldi").

Il libro di Glenford Myers The Art of Software Testing ha una regola semplice ma ben fondata 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 "raggrupparsi" in determinati moduli e determinate funzioni: nel momento in cui trovi un bug in uno, sai che dovresti cercare ulteriormente in esso per ulteriori bug. Per trovare bug, è possibile utilizzare le tecniche di test blackbox, test whitebox e test di mutazione. Finché trovi dei bug, sai che il tuo processo di test funziona!

Per visualizzare i tuoi progressi, traccia il numero di bug che il tuo team ha rilevato al giorno. Se il grafico si inclina verso il basso, allora sai che le tecniche utilizzate dal tuo team non le troveranno comunque. Naturalmente, se ritieni che le tue tecniche non siano all'altezza, leggi il libro di Myers e applica i principi.

Ora, c'è la possibilità che potresti essere a corto di perdere una nuova patch di bug e il tasso di ricerca di bug sarebbe notevolmente aumentato se avessi continuato i test per un po 'di più. Tuttavia, se ritieni che le tue tecniche siano valide, è improbabile.

La semplice risposta è che dipende dal sistema. Se stai scrivendo un software incorporato per un cardiofrequenzimetro o strumenti di monitoraggio della sicurezza per un reattore nucleare, lo standard è molto più elevato rispetto a quando stai scrivendo una piattaforma di blog.

Questa è davvero una domanda per un buon tester di sistema (e io non lo sono) ma ci proverò.

La tua misura di base sarà la copertura del test: quanta parte dell'applicazione è stata effettivamente testata (sia dal test unitario che dal punto di vista funzionale).

È necessario valutare ogni potenziale caso d'uso (e i parametri per quel caso d'uso) per la probabilità che venga effettivamente utilizzato (quindi è possibile abbandonare i casi limite), la complessità (le cose più semplici hanno meno probabilità di contenere bug o piuttosto hanno meno probabilità di contenere per trovare bug), costo per testare (in termini di tempo) e potenziale impatto di un difetto se scoperto in quella zona (qui entra in gioco il reattore nucleare contro la piattaforma di blog).

Sulla base di tale valutazione, è necessario capire quale di questi verrà testato e in quanti dettagli. Una volta che hai un elenco come quello, il team (incluso un product manager / project manager / rappresentante utente) può passare attraverso tale elenco e stabilire le priorità in base ai vincoli che hai.

Una tecnica utile a cui pensare è che puoi anche variare i casi d'uso testati con ogni versione. Ad esempio, potresti avere un elenco di casi di test non critici e testarne metà con una versione e metà con la successiva (quindi alternata). In questo modo si aumenta la copertura totale del test che si ottiene per lo sforzo (anche se a rischio di introduzione di bug di regressione).

Ciò potrebbe estendersi anche ai test della piattaforma: se si supportano due back-end di database (o più browser), testare metà dell'app su uno, l'altra metà sull'altro e quindi scambiare la versione successiva.

(Penso che questo sia indicato come striping ma non citarmi su questo.)

E quindi l'ultima cosa a cui pensare non è ciò che testate, ma ciò che effettivamente risolvete quando vengono rilevati problemi. È comune dire "correggi tutti i bug", ma la realtà è che ci sono pressioni di tempo e non tutti i bug sono uguali. Ancora una volta, regolari scrub di bug con tutte le parti interessate sono il modo migliore per procedere. Ciò è particolarmente rilevante nei casi in cui una correzione di bug può essere particolarmente invadente in quanto il lavoro aggiuntivo nel test di test e regressione che genera può superare i benefici 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!" --Edsger Dijkstra

Qualcosa di buono da tenere a mente quando si eseguono test, automatizzati o meno. Puoi solo provare che non hai trovato altri bug, non che non ce ne siano più.

Ma più occhi metti su una sezione di codice, più puoi essere sicuro del suo corretto funzionamento. È molto simile alla citazione di Knuth sull'ottimizzazione in questo senso: puoi testare le cose sbagliate molto facilmente e puoi testare nei momenti sbagliati nel tuo sviluppo.

In sostanza, vuoi essere coperto in due grandi posti:

1. 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.

2. I segmenti più critici, complessi e incerti hanno test adeguati per garantire la sicurezza? Se si tratta di un loop principale o di qualcosa su cui devi ottimizzare o hackerare: mettici alla prova. Se è complicato e ha molte divisioni logiche: metti molti test su di esso. Se non riesci a testarlo, o è troppo profondo per poterlo testare direttamente: assicurati che il codice sia stato rivisto e che il codice sia stato testato indirettamente a mano.

Se aspetti fino al termine del progetto, avrai effettivamente un numero molto elevato di casi di test. Se consegni continuamente, concentrandoti su piccole consegne, avrai meno casi di test ad ogni iterazione e sarai in grado di testare tutto. Se non puoi effettuare piccole consegne, dai la priorità e inizia i test con la massima priorità e prosegui fino a quando non devi interrompere.

Se stai parlando di unit test e stai facendo TDD (scrivendo prima i test), questo non è un problema: basta interrompere i test quando le funzionalità sono terminate.

Nel TDD incrementale, si scrive un test che ha esito negativo, quindi si implementa la minima quantità di codice che può farlo passare, quindi il refactor. Continuare ad aggiungere test in questo modo fino a quando il metodo non sarà completo.

Ecco un ottimo esempio.

Anche gli statistici hanno esaminato questo problema, in realtà già negli anni '70 e '80. Dati i presupposti appropriati su come vengono scoperti i bug, provano a 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 https://rpubs.com/hoehle/17920 ... per un breve trattamento di uno dei documenti su questo problema, incluso il codice R su come farlo in pratica.

Naturalmente un problema saranno sempre le ipotesi sul processo di individuazione 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 completa la sensazione di intestino.

Quando è arrivata la data di spedizione. Non c'è fine ai test per un software. Ma poi c'è qualcosa noto come programma. Dovrai testare la maggior parte delle tue funzionalità nel tempo programmato e correggere i bug che incontri. Non è possibile garantire che il software sia perfetto.

Le prime cose da testare sarebbero il "percorso felice", i casi limite e gli input non validi. Se ci sarà più di un utente simultaneo, dovrai verificare i problemi di concorrenza come il blocco e le condizioni di gara. Se l'app utilizza risorse esterne, dovrai testare il comportamento dell'app quando tali risorse non sono disponibili. Successivamente, è possibile utilizzare il codice per cercare elementi che potrebbero causare l'interruzione e testarli. Quando tutti questi test superano, 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 sia sufficientemente testato?

Ovviamente, il "livello di confidenza" è altamente soggettivo poiché non puoi mai sentirti completamente sicuro, ma abbastanza certo - ed è quello 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 team è d'accordo.

Ecco alcuni "indicatori fatti" relativi al test:

• La tua build e installazione sono completamente automatizzate e tutti i test (unità, interfaccia grafica, integrazione) vengono eseguiti automaticamente?
• Scrivi i tuoi test mentre (o preferibilmente prima) scrivi il codice, piuttosto che dopo?
• Ti senti abbastanza sicuro per eseguire il refactoring di codice di grandi dimensioni senza introdurre bug?
• Il livello di copertura del codice è abbastanza alto?
• Hai un tester dedicato nella tua squadra? È coinvolto quotidianamente durante tutto lo sviluppo e non solo alla fine?
• Il tuo tester manualmente (esplorativo) ha provato a romperlo senza successo?

Se riesci a controllare questi punti, allora probabilmente puoi dire di aver testato abbastanza.

Mai, penso che non finirai mai i test in un sistema ... ci sono così tante variabili che non puoi gestire.

Ma, come sappiamo, non puoi testare "per sempre", quindi penso che il limite dipenda essenzialmente da:

• Quando il rischio associato all'uso del software è stato ridotto a un livello accettabile. (come dice @Graham Lee)
• Chi è l'utente del sistema? puoi essere tu o il presidente degli stati uniti. Nel primo caso non ti interessa molto se appare un bug perché lo risolvi ed è fatto. Nel secondo caso non vuoi che venga visualizzato NESSUN bug.
• Qual è il tuo rapporto con il tuo cliente? Forse il cliente è tuo padre, quindi non è così terribile, o forse è una grande azienda.
• Quanto è grave per gli utenti del sistema un bug? Causerà la terza guerra mondiale o solo un brutto messaggio?

Quando le persone che devono firmare sulla distribuzione sono soddisfatte.

o in alcuni casi la maggioranza delle parti responsabili è soddisfatta.