Qual è il tasso di errore accettabile per il software?

Question

Qual è il tasso di errore accettabile per il software?

#1 da (6 voti)
#2 da (3 voti)
#3 da (1 voti)

1

Dire che produco software con un algoritmo genetico . Per essere certo che il software funzioni correttamente in tutte le situazioni, dovrei testare tutte le situazioni, che potrebbero essere proibitamente (o infinitamente) molte. Così ho sviluppato il software con input di test in evoluzione (alcuni fissi, alcuni ereditati e altri casuali). Ora, con ogni generazione, la probabilità aumenta in modo misurabile che le funzioni più idonee saranno soluzioni generali, non solo soluzioni per i dati noti a portata di mano.

Come sviluppatori, siamo imperfetti e il nostro software potrebbe non funzionare, anzi, molto spesso. In generale, non abbiamo alcuna idea della probabilità di fallimento in un dato momento, sebbene potremmo essere in grado di discernere casi specifici in cui il software fallirà. Tutto quello che possiamo fare per ridurre il tasso di insuccesso è testare a fondo e praticare un buon sviluppo del software. Ma logicamente, distribuiamo software difettoso tutto il tempo.

Ti metterebbe a disagio come sviluppatore per sapere con quale frequenza il tuo software potrebbe non funzionare, ma per non sapere nulla dei casi specifici in cui potrebbe essere? Quale tasso di fallimento è accettabile? 0,01%? 0,0001%? Vorresti tenere un algoritmo genetico a un livello più alto di un umano quando si tratta di tassi di fallimento?

testing code-quality

posta Jon Purdy 12.10.2011 - 18:00

fonte

3 risposte

6

Stai chiedendo un assoluto categorico, senza fornire alcun tipo di contesto (come casi d'uso, requisiti, industria, clienti, utenti, ecc.).

Pertanto, la risposta è un assoluto categorico: 0,0%.

Se hai in mente un contesto specifico, il tasso di errore accettabile dipenderà interamente dal contesto.

risposta data 12.10.2011 - 18:05

fonte

3

Dipende davvero dall'applicazione.

Se il software controlla un reattore nucleare o un aeromobile in volo, allora il tasso accettabile è dello 0,0%

Se il software sta fornendo commenti agli utenti su un sito gratuito senza entrate pubblicitarie, il costo dell'opportunità di fallimento è abbastanza vicino allo zero, quindi potresti probabilmente tollerare una probabilità ragionevolmente alta, ad esempio 5% -10%, e testare il casi d'uso specifici che sono preziosi.

La frase spaventosa dal mio punto di vista (tipicamente incorporato) è

...know nothing about the specific cases in which it might [go wrong]

Io, forse troppo ottimisticamente, spero che la maggior parte degli sviluppatori metta più design, implementazione e sforzo di test nelle aree soggettivamente importanti del software.

Supponiamo che tu stia progettando un software per un distributore automatico. Se lo scarto dello 0,1% che ritieni accettabile si verifica nel codice che decide in quale modello far lampeggiare i LED quando la macchina è inattiva - è una macchina di fantasia - allora dubito che ti occuperesti anche di un cambio di campo. Se invece si verifica il guasto nel codice che decide la quantità di variazione o la quantità di cioccolato da fornire, si ha un problema molto più grande.

risposta data 12.10.2011 - 18:37

fonte

Leggi altre domande sui tag testing code-quality

Python's Django o IntraWeb di Delphi? DDD: cosa succede se l'aggregato dipende da altri aggregati

score 1 · Accepted Answer

Non sono sicuro del motivo per cui è importante che il tuo software sia stato scritto da uno sviluppatore o da un algoritmo genetico.

Da qualche parte dovrebbe esserci un documento dei requisiti che spiega gli input accettabili per il programma e gli output previsti per tali input. È possibile scrivere test unitari per testare piccole unità del programma e logica aziendale. Puoi fare in modo che i tester del QA usino il programma ed eseguano test più complessi. Dovresti cercare di ottenere una percentuale di errore dello 0% entro i limiti dei Requisiti . A volte un cliente accetterà un programma con un basso tasso di errore in alcune situazioni se ritengono che non sia abbastanza importante da giustificare il costo aggiuntivo per risolvere il problema.

Il tuo programma non ha bisogno di tenere conto di ogni scenario credibile sotto il sole, solo uno scenario mai concepibile come descritto dagli Utenti / Clienti / qualsiasi cosa ... E se iniziano ad avere ampi requisiti che includono tutto sotto il sole, allora chiedi loro di perfezionarli. Non c'è molto altro da dire, penso, a meno che tu non possa dare dettagli sulla tua situazione.