Questo sito utilizza cookie di terze parti per inviarti pubblicità in linea con le tue preferenze. Se vuoi saperne di più clicca QUI 
Chiudendo questo banner, scorrendo questa pagina, cliccando su un link o proseguendo la navigazione in altra maniera, acconsenti all'uso dei cookie. OK

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

Il Test di unità, nello sviluppo di un sistema software, rappresenta il primo stadio del processo di test. Obiettivo del test è la prevenzione e la rilevazione dei difetti (faults)che determinano le deviazioni del programma dal comportamento atteso. In questa tesi l'obiettivo di rilevare difetti in ogni modulo costituente il sistema viene raggiunto attraverso l'analisi dei possibili cammini di esecuzione associati al flusso dati effettuando il test def-use, che consiste nella verifica di copertura delle catene definizione-uso del programma in esame. Scopo della tesi è la valutazione del test def-use nella rilevazione dei difetti logici presenti in moduli procedurali (C) e concorrenti (Java) con l'impiego del programma DefUseChecker appositamente implementato. I risultati raggiunti rivelano l'efficacia del test def-use nella rilevazione dei difetti logici, come i controlli ridondanti nei programmi procedurali e la potenzialità espressa dall'inserimento degli Interleavings-Control nella individuazione di errori di sincronizzazione nei programmi concorrenti.

Mostra/Nascondi contenuto.
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]).

Tesi di Laurea

Facoltà: Ingegneria

Autore: Simone Laico Contatta »

Composta da 112 pagine.

 

Questa tesi ha raggiunto 1698 click dal 20/03/2004.

 

Consultata integralmente una volta.

Disponibile in PDF, la consultazione è esclusivamente in formato digitale.