Analisi e metriche sulla copertura del codice nel testing software

Analisi sulla copertura del codice 

La copertura del codice (test coverage nel mondo accademico, code coverage per i professionisti) è un metodo di misura usato nel software testing che descrive il grado con cui viene esaminato il codice sorgente di un programma. E’ intrinsecamente un’attività di testing del tipo “white box” perché richiede la conoscenza e l’accesso al codice stesso, piuttosto che il solo uso delle interfacce fornite, e spesso necessita anche della sua ricompilazione con speciali comandi. Questo permette a coloro che eseguono questo tipo di test di esaminare parti di codice che raramente vengono analizzate e assicurare che i punti più importanti vengano controllati.

Usare la copertura del codice è un modo per tentare di aumentare la copertura dell’insieme dei possibili comportamenti anomali così che si arrivi a provare l’assenza di difetti, o almeno l’assenza di una certa classe di difetti.

L’analisi sulla copertura del codice (test coverage analysis) è il processo di

• Trovare, all’interno di un programma, aree di codice che non vengono utilizzate dall’insieme dei test case
• Creare test case addizionali per aumentare il livello di copertura
• Determinare una misura quantitativa di copertura del codice, che è indirettamente collegata con la qualità

Un aspetto opzionale dell’analisi sulla copertura del codice è quella di identificare i test case ridondanti che non incrementano il livello di copertura.

Le tecniche di copertura del codice sono state tra le prime tecniche inventate per il testing sistematico del software.

Per automatizzare questo processo si usa un analizzatore di copertura del codice, detto coverage analyzer o coverage monitor.

Alcune considerazioni di seguito esposte ci suggeriscono i punti di forza di questa di questa tecnica di testing:

• Bug collegati al controllo del flusso comportano che si possono scoprire bug variando il controllo di flusso stesso. Ciò avviene, ad esempio, quando un programmatore scrive”if (c)” invece di “if (!c)“.

• Si controllano malfunzionamenti senza sapere quali effettivamente potrebbero verificarsi.
• Errori di omissione.
• Codice non raggiungibile.

Chiaramente, l’analisi di copertura del codice svela bug plausibili ma non svela tutte le possibili classi di bug. L’analisi di copertura fornisce più vantaggi quando viene applicata ad un programma che ha un numero elevato di decisioni, piuttosto che ad applicazioni basate in maniera principale solo sui dati, come un’applicazione sui database.

Metriche basilari

Nella metà degli anni ’70, Goodenough e Gerhart, in una ricerca sulla capacità di testing per dimostrare l’assenza di errori in un programma, aprirono una breccia nella ricerca sul software testing, evidenziando come la questione centrale consista nella domanda : “Qual è un criterio di test?”, cioè un criterio che definisca quello che deve costituire un test adeguato.

Da allora, i criteri di test hanno avuto un maggiore peso nella ricerca. Un vasto numero di questi criteri è stato proposto ed esaminato; notevoli sforzi di ricerca hanno provato a fornire supporto per l’uso di un criterio piuttosto che di un altro.

Per misurare con dei parametri oggettivi la qualità del codice sorgente, vengono quindi usati dei criteri di copertura. Ne esistono di diversi, i più importanti sono:

1. Statement (o line) coverage: E’ stata eseguita ogni linea di codice?
2. Decision coverage: Sono stati eseguiti i punti di decisione (almeno una volta il valore vero e quello falso)?
3. Condition coverage: Sono stati eseguiti tutti i punti di valutazione (tutte le possibili sotto-espressioni con il valore vero / falso) ?
4. Function coverage: Il programma svolge tutte le sue funzioni?
5. Path (o edge)coverage: Sono stati eseguiti tutti i possibili percorsi attraverso una parte del codice?