Test strutturale di programmi procedurali e orientati agli oggetti, sequenziali e concorrenti

Introduzione Indipendentemente dalle tecniche di sviluppo usate non è mai possibile assumere che il software sia corretto e di conseguenza deve essere verificato. Obiettivo del test è la prevenzione e la rilevazione dei difetti (faults) che determinano le deviazioni del programma dal comportamento atteso [8]. Nel I° capitolo di questa tesi viene definito il test strutturale per programmi procedurali. Il test strutturale, detto anche white-box testing, consiste nell’esame della struttura interna di un programma per la valutazione del grado di copertura di determinati costrutti, come ad esempio la copertura delle istruzioni e dei cammini. In particolare, il test data-flow è un metodo di test strutturale, progettato per verificare le unità, basato sulla selezione dei cammini associati al flusso dati del programma. Vengono utilizzate le catene definizione- uso del programma per condurre la selezione dei casi di test. Una catena definizione-uso (d,u,v) associata alla variabile v consiste di un nodo sorgente contenente una definizione d di v, un nodo destinazione contenente l’uso u di v e la variabile v stessa, tale per cui la definizione di v alla sorgente possa raggiungere la destinazione senza che lungo il cammino v sia ridefinita. Per programmi procedurali, nel II° capitolo, è stato affrontato il test def-use, che consiste nella verifica di copertura delle catene definizione-uso del programma. Scopo della tesi è la valutazione dell’efficacia del test def-use nella rilevazione dei difetti logici. Le informazioni definizione-uso necessarie sono state ottenute con lo strumento d’analisi di flusso FLANT (FLow ANalysis Tool [2] e [3]), mentre le tracce dei cammini di esecuzione sono state generate tramite il gdb (GNU debugger). La verifica di copertura delle catene definizione-uso (d,u,v), effettuata dal programma DefUseChecker, viene svolta cercando nelle tracce un cammino libero da ridefinizioni di v da d a u per ogni variabile v. Il test def-use è stato effettuato su 9 programmi procedurali di dominio pubblico. La percentuale di copertura delle catene raggiunta tramite i casi di test generati varia da un minimo del 17,9% ad un massimo del 100%. I motivi di una così ampia oscillazione sono illustrati al punto 2.4. Il motivo principale che permette solo una copertura parziale delle catene definizione-uso consiste nella presenza di infeasible-paths: esistono cioè cammini di flusso da d a u per una variabile v in cui le condizioni logiche che lo rendono percorribile sono mutuamente esclusive o non possono essere mai verificate. Nel III° capitolo vengono presentate le tecniche di test per la programmazione orientata agli oggetti. Contrariamente alla intuizione i metodi tradizionali di test non possono essere applicati direttamente a programmi orientati agli oggetti; infatti gli aspetti propri della natura del paradigma orientato agli oggetti quali l’ereditarietà e il polimorfismo introducono problemi non presenti nel software procedurale. L’information-hiding e l’attenzione posta nei sistemi orientati agli oggetti all’astrazione aprono la strada al test funzionale ([6] e [20]); tuttavia il test strutturale, che costituisce una strategia complementare al test funzionale, continua a rivestire una notevole importanza [19]. Le tecniche di test funzionali e strutturali possono individuare errori che sono locali ad un metodo di una classe, ma non sono sempre adatti ad individuare difetti dovuti alle interazioni tra metodi. Nasce così la necessità di un test basato sullo stato dell’oggetto ([10], [11], [35], [36] e [37]). Nel IV° capitolo viene affrontato il test di programmi concorrenti e in particolare il test strutturale di programmi paralleli a memoria condivisa ([30], [31] e [32]).