White Box Testing: Copertura delle istruzioni, decisioni e condizioni

White Box Testing: Copertura delle istruzioni, decisioni e condizioni

White Box testing

Nella strategia White-Box (White Box Testing), detta anche logic driven testing, viene presa in considerazione la struttura interna del sistema, analizzando il sistema come se fosse una scatola trasparente di cui si può vedere il contenuto.

La costruzione dei test-case deriva da un esame formale della logica interna del sistema, composta da algoritmi e strutture dati, senza analizzare il sistema nel suo complesso. Può essere interessante capire come sia possibile soddisfare il criterio di ottimalità, ovvero come sia possibile ricavare un insieme di test in grado di garantire il ritrovamento di tutti gli errori presenti nel sistema.

Una prima ridefinizione del criterio di ottimalità potrebbe essere la richiesta che ogni istruzione del programma venga eseguita almeno una volta, ma la sola esistenza di un ciclo all’interno del codice può generare errori che questo criterio non evidenzia.

Il criterio ottimale viene allora definito come la richiesta che tutti i cammini all’interno del grafo di controllo del programma vengano percorsi, ovvero la ricerca esaustiva di tutti i
cammini distinti esistenti nel programma. Nella figura che segue vediamo come anche un grafo semplice porti ad una quantità considerevole di cammini; partendo da questa osservazione, è facile capire come sia praticamente impossibile la ricerca esaustiva di tutti i cammini all’interno del grafo.
Se quindi la ricerca esaustiva non è proponibile, risulta necessario ricercare un insieme ottimale di cammini che assicurino la maggior probabilità di rilevare gli errori presenti nel software, con il minimo dei test. La ricerca dei cammini, sia essa esaustiva o meno, non assicura comunque che il software sia conforme alle specifiche del sistema, così come non è in grado di rilevare errori legati a particolari valori dei dati.

White Box Testing - Copertura delle istruzioni, decisioni e condizioni

Analizziamo adesso a grandi linee i criteri che rientrano all’interno della strategia White-Box.

Copertura delle istruzioni

Il criterio di copertura delle istruzioni o statement coverage, si prefigge lo scopo di trovare un insieme di test tale che sia garantito che ogni istruzione all’interno del software sia eseguita almeno una volta.

Copertura delle decisioni

Il criterio di copertura delle decisioni o decision coverage, nota anche con il nome di branch coverage, parte dal presupposto che è necessario esaminare ogni ramificazione all’interno del grafo sia per il valore di verità che per il valore di falsità della ramificazione.

Potrebbe sembrare sufficiente verificare tutte le decisioni, ma esistono almeno due eccezioni:

– un primo caso degenere si ha quando il software non presenta alcuna decisione;
– un secondo caso si ha quando una sezione di software presenti più di un punto di ingresso, per cui una parte di esso viene eseguita solo se si esegue a partire da un certo punto di ingresso in poi.

Il criterio di copertura delle decisioni viene perciò completato affermando che è necessario costruire un insieme di test-case tali per cui ciascuna decisione venga percorsa per i valori di verità e di falsità e che ciascuna istruzione sia eseguita almeno una volta.

Copertura delle condizioni

Non sempre però la copertura delle decisioni porta a test in grado di rilevare tutti gli errori, per cui si ricorre alla copertura delle condizioni o condition coverage.

Per soddisfare questo criterio, si deve scrivere un insieme di test-case tali che ciascuna condizione elementare all’interno di una decisione assuma tutti i possibili valori almeno una volta.

Come per la copertura delle decisioni, si dovrà affiancare questo criterio con la copertura delle istruzioni, al fine di verificare anche le possibili eccezioni nell’esecuzione dei test.

Copertura delle condizioni e decisioni

La copertura delle condizioni non implica però la copertura delle decisioni, quindi si dovrà fare ricorso alla copertura delle condizioni e decisioni.

Per soddisfare il criterio si deve ricercare un insieme di test-case tali da garantire che ogni condizione assume il valore di verità e falsità almeno una volta e che ogni decisione all’interno del software sia percorsa almeno una volta sia per il ramo vero che per il ramo falso.

Questo potrebbe apparire finalmente un criterio adeguato per il test strutturale di un programma, ma bisogna tenere conto che di norma una macchina non è in grado di verificare condizioni multiple senza spezzarle in più condizioni singole su cui lavorare.

Copertura delle condizioni multiple

Si arriva così al criterio di copertura delle condizioni multiple, laddove è necessario che l’insieme di test-case preveda tutti i possibili valori di ciascuna combinazione di condizioni presenti in una decisione.

Anche in questo caso si dovrà affiancare il criterio di copertura delle istruzioni, al fine di garantire anche la copertura nei casi eccezionali prima elencati.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *