Sviluppo di un tool per la verifica software di un sistema distribuito

Sviluppo di un tool per la verifica software
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
di un sistema distribuito
tesi di laurea
Sviluppo di un tool per la verifica software di un sistema distribuito
Anno Accademico 2007 / 2008
relatore
Ch.mo Ing. Massimo Ficco
correlatore
Ch.mo Ing. Roberto Pietrantuono
candidato
Valerio Perrotta
Matr. 534/2200
Sviluppo di un tool per la verifica software
di un sistema distribuito
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Obiettivo Tesi
Sviluppo di un tool per la verifica software di un
sistema distribuito
Il seguente lavoro di tesi nasce
nell’ambito del progetto Cosmic
Contesto
Safety and mission critical systems
DEFINIZIONI:
• Safety-critical, sistemi il cui fallimento (failure) può causare
danni fisici agli utenti (malattie o, in casi estremi, morte ) o
all’ambiente circostante
REQUISITI PRINCIPALI:
• alti livelli di affidabilità
• tolleranza ai guasti
• scalabilità delle prestazioni
• Mission-critical, sistemi in cui un failure può compromettere
la corretta riuscita di una operazione voluta.
Sviluppo di un tool per la verifica software
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
di un sistema distribuito
Testing di una piattaforma middleware
• Middleware CORBA-based per lo sviluppo di applicazioni “safety and mission critical” in ambiente
distribuito
• organizza i propri servizi in 13 componenti detti CSCI (Computer Software Configuration Item)
Modello a V
• Segue un modello di sviluppo detto a V
Focalizzeremo l’attenzione sui
“test di validazione”
• Ogni CSCI (13 in totale) presenta un certo numero di test
di validazione, per un totale di circa 125 test
Sviluppo di un tool per la verifica software
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
di un sistema distribuito
Preparazione e avvio dei Test di Validazione
PROBLEMA
• Procedura lunga e macchinosa (circa 11 minuti per
l’esecuzione del primo test, 4 minuti per i successivi)
e variabile da CSCI a CSCI
• L’utente è costretto ad interagire continuamente con
la macchina durante l’esecuzione di uno specifico test
• Scarsa leggibilità e comprensione dei risultati
OBIETTIVI :
• Automatizzare le fasi di preparazione e avvio dei test
• Eliminare l’interazione utente-macchina durante
l’esecuzione di uno specifico test
• Presentazione adeguata dei risultati dei test
Sequence Diagram
Sviluppo di un tool per la verifica software
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
di un sistema distribuito
Individuazione di un pattern comune
Studio di ogni singolo test
Preparazione ambiente
(solo per il primo test)
Individuazione di un pattern procedurale comune
Il pattern può essere suddiviso in 5
fasi sequenziali
E’ POSSIBILE, TRAMITE TALE PATTERN,
AUTOMATIZZARE L’85% DEI TEST DI VALIDAZIONE
Configurazione ambiente
(solo per il primo test)
Avvio demoni
(per ogni test)
Avvio test
(per ogni test)
Chiusura terminali e
uccisione demoni
(per ogni test)
Sviluppo di un tool per la verifica software
di un sistema distribuito
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
Sviluppo di un tool per l’automatizzazione dei test di validazione :
VALTTOOL
Due modalità di funzionamento :
• Manual : per l’esecuzione di un singolo test di validazione
AUTOMATICMODE
User
• Automatic : per l’esecuzione di un intero set di test di validazione
MANUALMODE
ARCHITETTURA DEL TOOL
• Interface, responsabile dell’interazione con l’operatore
• Modality, che indica la modalità di avviamento del tool
• Core Application, responsabile delle fasi di avvio e lancio dei test
Sviluppo di un tool per la verifica software
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
di un sistema distribuito
Implementazione di VALTTOOL (1/2)
Il tool si compone di :
• un’interfaccia Java, responsabile
dell’interazione con l’operatore;
• una cartella “ValidationTesterRemoto”,
contenente dei file di script di shell da
copiare sull’host remoto coinvolto nel
testing;
• file di script di shell necessari per la preparazione
automatica e l’avvio dei test, script che vengono richiamati
dall’interfaccia in base alle richieste dell’utente
Sviluppo di un tool per la verifica software
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
di un sistema distribuito
Implementazione di VALTTOOL (2/2)
Inoltre :
• un file di configurazione “config.xml” da cui
vengono prelevati gli input di default all’avvio di
ambedue le modalità di esecuzione del tool
• un file di testo “test.txt” contente l’elenco
completo dei test di validazione automatizzabili
• un file di testo “scenari.result” all’ interno del
quale verranno memorizzati i risultati dei test
eseguiti
Sviluppo di un tool per la verifica software
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
di un sistema distribuito
Esecuzione automatica dei Test di validazione utilizzando VALTTOOL
OBIETTIVI RAGGIUNTI :
• Possibilità da parte dell’utente di eseguire un intero
elenco di test (AutomaticMode) oppure un singolo test
(ManualMode) senza interagire con la macchina
• Riduzione del tempo di esecuzione dei test :
se si considera un singolo test si ha un risparmio di
tempo di circa 10 minuti (primo test) o 4 minuti (test
successivi); dunque, si passa da un totale di circa 7
ore ad un totale di circa 2 ore, con un risparmio di
tempo complessivo pari a 5 ORE
• Presenza di una repository dei risultati (AutomaticMode)
e chiara visione delle operazioni svolte durante
l’esecuzione di uno specifico test (ManualMode)
Sviluppo di un tool per la verifica software
di un sistema distribuito
Facoltà di Ingegneria
Corso di Studi in Ingegneria Informatica
CONCLUSIONI
Il tool per l’automatizzazione dei Test di Validazione di una piattaforma middleware
(VALTTOOL) :
• Automatizza le fasi di preparazione ed avvio dei test grazie all’individuazione di un pattern procedurale
comune all’85% dei test di validazione;
• Fornisce notevoli vantaggi in termini di tempo di esecuzione dei test di validazione
• Elimina l’interazione utente-macchina durante l’esecuzione di uno specifico test (lo lascio o no?)
SVILUPPI FUTURI
• Automatizzazione della totalità dei test di validazione (dall’attuale 85% al 100%)
• Definizione di una procedura per l’inserimento manuale di un nuovo caso di test non previsto dalla
documentazione e che non segua il pattern individuato