Ho visto un'affidabilità del sistema espressa in questo modo:
Rel = N. di test eseguiti / Somma di arresti anomali o altri eventi critici
Ha senso e quale è in realtà l'output?
Ho visto un'affidabilità del sistema espressa in questo modo:
Rel = N. di test eseguiti / Somma di arresti anomali o altri eventi critici
Ha senso e quale è in realtà l'output?
No. Quella metrica mostra un fondamentale fraintendimento sia del testing che dell'affidabilità.
I test possono solo dimostrare la presenza di bug, ma mai l'assenza. Una suite di test dimostra che un sistema è capace di funzionare come previsto (incluse le modalità di errore conosciute), ma tranne nei casi più semplici non può mai dimostrare che funzionerà sempre come progettato. La dimensione di una suite di test è assolutamente irrilevante. Le suite di test più grandi non sono necessariamente migliori, potrebbero semplicemente essere un sintomo di elevata complessità del sistema. Una piccola suite di test potrebbe significare che nessuno si è preso la briga di scrivere molti test.
Una suite di test con una buona copertura si traduce in una migliore affidabilità, poiché i problemi vengono rilevati (e possono essere risolti) prima che il sistema venga distribuito. Tuttavia, ciò richiede una buona copertura (non solo un gran numero di test) e che qualcuno sta effettivamente risolvendo i problemi. È del tutto possibile scrivere una suite di test molto ampia con una copertura molto ridotta, ad es. quando si esegue il test di un solo sottosistema specifico, ma non si verificano altri sottosistemi.
L'affidabilità viene solitamente definita come la probabilità o la frequenza dei guasti, quando si utilizza un sistema in un ambiente specificato. Se in un periodo di tempo T osserviamo n di errori, la nostra affidabilità espressa come frequenza è approssimativamente r = n/T . Il numero di test non è un parametro qui. Tuttavia, è possibile verificare l'affidabilità replicando l'ambiente specificato e eseguendo il sistema lì. Dopo più sessioni, è possibile decidere con una certa sicurezza se il sistema soddisfa i requisiti di affidabilità. Sfortunatamente, questa strategia è quasi inutile per testare programmi deterministici, perché i programmi non hanno usura.
Esempi perché la formula affidabilità = dimensione della suite di test / numero di errori non funzionerà:
Lascia che i sistemi A e B siano identici, con la stessa dimensione della suite di test (= 42). Ci aspettiamo la stessa affidabilità. Ora lasciamo A eseguire per due giorni e osserviamo tre errori. Finiamo con l'affidabilità di 42/3 = 14. Quindi eseguiamo B per due minuti e osserviamo un errore. Finiamo con un'affidabilità di 42/1 = 42.
Nonostante A e B siano identici, ci ritroviamo con metriche di affidabilità diverse perché la formula non dipende dal tempo.
Lascia che il sistema A sia un sistema semplice con un singolo test e B un sistema complesso con 1000 test. Corriamo entrambi per lo stesso tempo e osserviamo un errore ciascuno. Pertanto, A ha l'indice di affidabilità 1, mentre B ha l'indice di affidabilità 1000. B 1000 volte più affidabile di A ? È improbabile, considerando che B probabilmente ha molte altre modalità di errore non rilevate.
Leggi altre domande sui tag testing metrics statistics reporting