Quanti bug aspettarsi [chiuso]

Sì: link

"Over the past seven years, the Coverity Scan service has analyzed nearly 850 million lines of code from more than 300 open source projects including Linux, PHP and Apache. ... The analysis found an average defect density of .69"

E questo è solo un bug reperibile dai metodi formali di Coverity.

link ha più informazioni nelle risposte, suggerendo qualcosa fino a 10 bug per KLOC.

how many bugs should I expect? [...] how many bugs we probably haven't yet found.

Per rispondere, definisci le parole "bug", "expect" e "found":)

Per uno dei miei progetti recenti, inizialmente avevamo aggiunto test unitari positivi per le nostre API. Abbiamo trovato una serie di bug con una "densità" misurabile (cioè misurabile xx / 1KLOC).

Quindi, abbiamo iniziato ad aggiungere casi di test negativi. Abbiamo scoperto un'altra ondata di bug, che avrebbe aumentato la nostra densità a un yy / 1KLOC (con yy > xx).

Poi abbiamo aggiunto test con condizioni di memoria ridotta simulate (cioè abbiamo ottimizzato le API di allocazione della memoria per fallire alla prima allocazione e chiamato un'API, quindi fallire sulla seconda allocazione e chiamare l'API e così via, finché l'API non ne aveva abbastanza assegnazione di successo per avere successo). Abbiamo trovato una terza ondata di bug, con la maggior parte di loro "una libreria lasciata in uno stato non valido quando l'allocazione della memoria fallisce".

Poi ci siamo spostati sul testing fuzz e sul test completo dello scenario (una particolare sequenza di chiamate API per ottenere un determinato risultato) e abbiamo ottenuto una nuova misurazione dei bug.

TLDR : quanti bug riesci a trovare dipende da quello che consideri un "bug" (per noi è solo un bug se trovato dopo la fine dell'iterazione), per cosa stai provando, la tua metodologia di test e quali risorse puoi mettere in prova (persone, tempo, hardware, ecc.). Se KLOC come misura è lì dentro da qualche parte, si tratta di una misura secondaria (vale a dire dopo "che cos'è un bug", "cosa stai testando" e così via).

Bug Estimation è un campo accademico di ingegneria del software, e ha un bel po 'di ricerca dedicata ad esso. La maggior parte del lavoro che conosco, però, si concentra sulla previsione di futuri bug piuttosto che sulle metriche di qualità pura.

Assicurati che tutti siano sulla stessa pagina di ciò che si qualifica come un bug. Ciò dipenderà in gran parte da ciò che stai cercando di misurare. Ad esempio, se si desidera trovare il numero di bug rilevati dopo l'implementazione di una nuova funzione, si cercheranno i problemi creati per le funzionalità pochi giorni dopo la distribuzione.

Sfortunatamente, la tua stima è valida tanto quanto i dati che raccogli. Se la squadra di sviluppo invia più problemi per lo stesso bug o se metti bassi livelli di sforzo nella ricerca di bug, la tua stima lo rifletterà. Una possibile tecnica di mitigazione consiste nel testare la stima su un progetto simile di stima ma con un team di sviluppo / controllo qualità diverso. Anche questo, purtroppo, ha le sue insidie.

L'aspetto più importante è trattare una stima per quello che è: una stima. Sapere cosa significa la tua stima e come è stata fatta. Sapere quando la stima è pertinente al problema e quando non lo è. Buttalo fuori se non corrisponde ai tuoi dati. Non utilizzare mai una singola metrica come standard per la qualità del codice.

Ecco alcuni documenti che potresti trovare utili. Il numero 2. è un'analisi diretta dei bug in eclissi, che può fornire un esempio di come fare la tua stima:

1. link
2. link
3. link