Report di copertura del codice separati per i test di unità e integrazione o un rapporto per entrambi?

Soprattutto, è necessario disporre e analizzare la copertura combinata (totale). Se ci pensi, questo è il modo più naturale per definire correttamente i rischi e focalizzare lo sforzo di sviluppo del test.

La copertura combinata mostra quale codice non è coperto dai test affatto , ovvero è più rischioso e deve essere prima studiato. Rapporti di copertura separati non saranno di aiuto in questo caso, in quanto questi non ti permettono di scoprire se il codice è stato testato in qualche modo o non testato affatto.

Anche l'analisi della copertura separata può essere utile, ma sarebbe meglio fare dopo con l'analisi combinata e preferibilmente coinvolgere anche i risultati dell'analisi della copertura combinata.

Lo scopo dell'analisi di copertura separata è diverso da quello combinato. L'analisi della copertura separata aiuta a migliorare la progettazione della tua suite di test, al contrario dell'analisi della copertura combinata che è destinata a decidere sui test da sviluppare, non importa quale.

"Oh questo divario non è coperto solo perché abbiamo dimenticato di aggiungere quel semplice test di unità (integrazione) nella nostra suite di unità (integrazione), aggiungiamolo" - la copertura e l'analisi separate sono molto utili qui, come quella combinata potrebbe nascondere le lacune che vorresti coprire in una particolare suite.

Dal punto di vista di cui sopra, è comunque desiderabile avere anche risultati di analisi di copertura combinata per analizzare casi più difficili. Pensaci, con questi risultati, le tue decisioni di sviluppo dei test potrebbero essere più efficienti grazie alle informazioni sulle suite di test "partner".

"C'è un buco qui, ma sviluppare un test unitario (integrazione) per coprirlo sarebbe veramente ingombrante, quali sono le nostre opzioni? Controlliamo la copertura combinata ... oh è già trattato altrove, cioè, coprirlo nella nostra suite non è di fondamentale importanza. "

Non menzioni il tuo strumento di test. Molte hanno funzioni "combinate" che consentono di aggregare i risultati di più sessioni o suite. Se desideri una metrica di copertura aggregata, esplora la funzione di combinazione nel tuo strumento di copertura.

Ora, possiamo parlare dell'elefante nella stanza?

Non c'è un cucchiaio. E non c'è "percentuale di copertura totale". Almeno, non semplice.

La percentuale di copertura è una metrica prontamente comprensibile presentata per aiutare a comprendere la portata, la profondità e la gamma di suite di test. Ma come ogni benchmark semplice, è molto facile diventare target fissato su questo valore come una specie di talismano magico di "testing completo" ".

Supponiamo che tu abbia raggiunto la gloria di "copertura di prova del 100%". Yay! Ma cosa significa? Il 100% delle linee di codice sono testati, giusto? Allora che dire di questa linea?

launch_missile = launch_authorized and launch_cmd_given else previous_launch_status

"Coprire" quella linea significa qualcosa - ma non un intero lotto, perché ci sono una varietà di condizioni che sono True o False con una certa probabilità, ma è improbabile che tu abbia provato tutte le combinazioni di quelle condizioni. Anche se quella linea è coperta una dozzina di volte, se una delle condizioni è relativamente rara, non sei arrivato vicino a testare tutti i risultati reali che potrebbero verificarsi nella pratica. Per renderlo più chiaro, un esempio più sintetico:

engage_laser = (laser_armed and safety_disengaged) or random.random() < 0.0000003

Quante volte dovresti coprire quella linea per testarla in modo esaustivo? Quante volte dovresti copiarlo per testarlo in combinazione con tutte le altre variabili del programma (con le loro probabilità, probabilmente altrettanto rare)?

Non sto dicendo che le metriche di copertura sono inutili. In realtà sono grandi . Si concentrano su uno dei problemi chiave: quanto è stato testato il mio sistema software? Aiutano a passare da "abbiamo alcuni test" a "abbiamo accuratamente testato".

Ma mentre lavori su "punteggi combinati", la realtà è che il tuo punteggio sarà tipicamente per "copertura informativa" piuttosto di "condizione", "predicato" o copertura "percorso" . Quindi, qualunque sia il numero che i tuoi punteggi aggregati ti danno, è improbabile che ti dia un'immagine reale di quanto dei tuoi potenziali stati e combinazioni di stati del programma siano stati testati. Mentre stai lavorando per aumentare la percentuale di copertura, prendi in considerazione anche la misurazione della copertura dei tuoi predicati. Ti darà una visione più realistica - e quasi invariabile, più sobria - dell'estensione del test.