progettazione di un tool a supporto di un metodo per la selezione...

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica

tesi di laurea

Progettazione di un tool a supporto di un metodo per la selezione delle tecniche di test Anno Accademico 2011/2012 relatore Ch.mo prof. Roberto Pietrantuono candidato Franco Crimaldi matr. 534001692

Indice

Introduzione 1

1 Test e problema della selezione delle tecniche di test 3

1.1 L’ingegneria del software . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Che cosa è il processo di verifica e di validazione del software . . . 5

1.3 Il test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Il problema della selezione delle tecniche di test . . . . . . . . . . . 7

1.5 Metriche e qualità del software . . . . . . . . . . . . . . . . . . . . 9

1.6 Guasto, errore e fallimento . . . . . . . . . . . . . . . . . . . . . . 11

2 Un metodo per selezionare la tecnica di test 13

2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Acquisizione delle metriche . . . . . . . . . . . . . . . . . . . . . 15

2.3 Fault prediction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Modelli predittivi . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1 Regressione . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.2 Principal Component Analysis . . . . . . . . . . . . . . . . 20

2.4.3 Stepwise regression . . . . . . . . . . . . . . . . . . . . . . 21

2.4.4 Quale modello predittivo scegliere . . . . . . . . . . . . . . 21

2.5 Classificazione dei guasti . . . . . . . . . . . . . . . . . . . . . . . 22

iii

Progettazione di un tool a supporto di un metodo per la selezione delle tecniche di test

2.6 Caratterizzazione delle tecniche di test . . . . . . . . . . . . . . . . 24

2.6.1 Tecniche di test: test funzionale e test statistico . . . . . . . 26

2.6.2 Quale tecnica scegliere . . . . . . . . . . . . . . . . . . . . 29

3 Progettazione ed implementazione del tool 31

3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2 Requisiti del Framework . . . . . . . . . . . . . . . . . . . . . . . 31

3.3 Progetto del Framework . . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 Lo Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 Requisiti dello Scheduler . . . . . . . . . . . . . . . . . . . . . . . 37

3.6 Flusso di lavoro dello Scheduler . . . . . . . . . . . . . . . . . . . 39

3.7 Diagramma dei casi d’uso . . . . . . . . . . . . . . . . . . . . . . 40

3.8 Diagramma delle classi . . . . . . . . . . . . . . . . . . . . . . . . 43

3.8.1 Analisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.8.2 Specifica e progetto . . . . . . . . . . . . . . . . . . . . . . 49

3.8.2.1 Pattern MVC . . . . . . . . . . . . . . . . . . . . 49

3.8.3 Progettazione di basso livello . . . . . . . . . . . . . . . . 52

3.8.4 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . 56

3.9 Codifica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 Caso d’uso 59

4.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.2 Caratterizzazione del software sotto test . . . . . . . . . . . . . . . 61

4.3 Stima dei guasti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.4 Scelta della migliore tecnica di test . . . . . . . . . . . . . . . . . . 64

4.5 Inserimento guasti individuati . . . . . . . . . . . . . . . . . . . . 65

4.6 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

iv


Conclusioni e sviluppi futuri 69

Ringraziamenti 70

Bibliografia 71

v

Elenco delle figure

1.1.1 Strati di ingegneria del software (R.S. Pressman, 2005) . . . . . . . 5

1.6.1 Guasto, errore, fallimento (Domenico Cotroneo, Stefano Russo, De-

pendability: concetti fondamentali, 2005) . . . . . . . . . . . . . . 12

2.1.1 Organizzazione delle tecniche di test (Pezzè, Young, 2008) . . . . . 14

2.3.1 Tassonomia dei guasti (Laprie, 2004) . . . . . . . . . . . . . . . . . 18

2.6.1 Test Case Design (Pezzè,Young, 2008) . . . . . . . . . . . . . . . . 28

3.3.1 Architettura di un framework a supporto V&V . . . . . . . . . . . . 33

3.4.1 Correlazione metriche e tipi di guasti . . . . . . . . . . . . . . . . . 36

3.6.1 Diagramma di flusso Scheduler . . . . . . . . . . . . . . . . . . . . 40

3.7.1 Diagrammi dei casi d’uso generico . . . . . . . . . . . . . . . . . . 42

3.7.2 Diagramma dei casi d’uso Scheduler . . . . . . . . . . . . . . . . . 43

3.8.1 Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.8.2 Associazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.8.3 Ereditarietà . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.8.4 Contenimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.8.5 Diagramma delle classi: Scheduler . . . . . . . . . . . . . . . . . . 48

3.8.6 Diagramma delle classi vista progettuale: Scheduler . . . . . . . . . 51

3.8.7 Diagramma delle classi vista progettuale basso livello: Control . . . 53

vi


3.8.8 Diagramma delle classi vista progettuale basso livello: Model . . . 54

3.8.9 Diagramma delle classi vista progettuale basso livello: Scheduler . . 55

3.8.10 Sequence Diagram: rilascia piano . . . . . . . . . . . . . . . . . . 57

3.8.11 Sequence Diagram ad un più basso livello di astrazione: rilascia

piano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.1.1 Sintassi GREP (http://it.wikipedia.org/wiki/Grep) . . . . . 60

4.2.1 Finestra inserimento metriche . . . . . . . . . . . . . . . . . . . . . 62

4.3.1 Finestra stima dei guasti . . . . . . . . . . . . . . . . . . . . . . . 64

4.4.1 Finestra piano rilasciato . . . . . . . . . . . . . . . . . . . . . . . . 65

4.5.1 Finestra inserimento guasti individuati . . . . . . . . . . . . . . . . 66

4.5.2 Finestra piano aggiornato . . . . . . . . . . . . . . . . . . . . . . . 66

4.6.1 Grafico tecniche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

vii

http://it.wikipedia.org/wiki/Grep

Elenco delle tabelle

4.1 Metriche GREP v.4 . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2 Modelli predittivi . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3 Capacità nel rilevare guasti ODC per ogni tecnica . . . . . . . . . . 65

4.4 N° guasti alla prima iterazione della strategia manuale . . . . . . . . 67

4.5 DFault alla prima iterazione della strategia manuale . . . . . . . . . 67

4.6 N° guasti alla prima iterazione del tool . . . . . . . . . . . . . . . . 67

4.7 DFault alla prima iterazione del tool . . . . . . . . . . . . . . . . . 67

4.8 N° guasti test svolto in maniera automatica dopo aver trovato 8

guasti di tipo Assignment . . . . . . . . . . . . . . . . . . . . . . . 67

4.9 DFault test svolto in maniera automatica dopo aver trovato 8 guasti

di tipo Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . 67

viii

Introduzione

Questo lavoro di tesi ha come obiettivo il miglioramento dell’efficienza dei processi

di Verifica e Validazione ( V&V ) del software, che risultano di particolare interesse

soprattutto nei sistemi critici, sottolineando la necessità di definire una metodologia

che possa portare alla selezione della migliore tecnica di test per ogni scenario.

Un sistema critico è un sistema il cui fallimento o malfunzionamento può portare a

perdite catastrofiche in termini di costo, danni all’ambiente o perdita di vite umane.

L’affidabilità di tali tipologie di sistema, quindi, rappresenta un requisito cruciale

da soddisfare.

Le attività necessarie ad assicurare i livelli di qualità richiesti richiedono enormi

costi di Verifica e Validazione del software; è noto, inoltre, che essa sia una delle

fasi più costose dell’intero ciclo di sviluppo sia in termini di tempo che di risorse

impiegate.

Pertanto, la criticità e la complessità dei sistemi considerati pone nuove sfide agli

ingegneri del software, che devono sviluppare soluzioni capaci di assicurare un

elevato livello di qualità, tenendo bassi, nello stesso tempo, i costi e i tempi di

sviluppo.

È necessario, dunque, un metodo che aiuti la scelta delle tecniche di test, in accordo

alle condizioni ed alle caratteristiche del software sotto test.

Il metodo seguito in questa tesi è basato su due approcci complementari:

1. Il primo consiste nel costruire un insieme di modelli predittivi per caratte-

1


rizzare un’applicazione software considerando la prospettiva del tester; que-

st’ultimo è interessato a trovare quanti difetti siano presenti nella applica-

zione e di quale tipo siano. Questa fase porta alla produzione di modelli

che, partendo dalle metriche inserite, mirano a stimare il numero di gua-

sti per ogni tipo ODC. Le tipologie di guasti esaminati sono proprie della

Orthogonal Defect Classification.

2. Il secondo definisce una procedura che deve caratterizzare le tecniche di

test in termini di tipi di guasto ODC che sono più inclini a rilevare.

L’esposizione del lavoro è articolata come segue:

• cap. 1: Test e problema della selezione delle tecniche di test;

• cap. 2: Un metodo per selezionare la tecnica di testing;

• cap. 3: Progettazione ed implementazione del tool;

• cap. 4: Caso d’uso.

2

Capitolo 1

Test e problema della selezione delle

tecniche di test

1.1 L’ingegneria del software

L’ente Institute of Electrical and Electronic Engineers (IEEE) ha formulato una defi-

nizione per l’ingegneria del software: (1) Applicazione di una strategia sistematica,

disciplinata e misurabile allo sviluppo, esercizio e manutenzione del software: cioè

applicazione dell’ingegneria al software. (2) Studio di strategia di cui al punto (1).

Gli ingegneri del software devono:

• avere un approccio sistematico e organizzato per il loro lavoro;

• usare strumenti e tecniche appropriate;

• variare strumenti e tecniche a seconda del problema da risolvere, dei vincoli

di sviluppo e delle risorse disponibili.

Un processo software è un insieme di attività aventi per obiettivo lo sviluppo o

l’evoluzione di un sistema software.

La struttura di un processo di sviluppo software stabilisce quando, come e cosa fare

per creare un software di qualità; esso solitamente comprende le seguenti fasi:

3


1. comunicazioni: comunicazioni e collaborazioni con il cliente e stakeholder

al fine di raccogliere i requisiti;

2. pianificazione: stabilire un piano che definisca le operazioni da svolgere, i

rischi annessi e le risorse necessarie;

3. modellazione: creazione di modelli che consentano allo sviluppatore ed al

cliente di comprendere chiaramente i requisiti software e progettuali; questa

fase può essere divisa in due sotto-fasi complementari: l’analisi e la progetta-

zione;

4. costruzione: generazione del codice e delle attività di collaudo necessarie per

individuare gli errori;

5. implementazione: il sistema software viene fornito al cliente; questi valuta

il prodotto e dà eventualmente indicazioni.

Ad un più basso livello di astrazione un processo di sviluppo software solitamente

comprende le seguenti fasi:

1. specifica: definizione di ciò che il sistema dovrà fare e dei vincoli di proget-

tazione;

2. sviluppo: progettare e codificare il sistema software;

3. convalida: si verifica che il software sia esattamente ciò che il cliente richie-

de;

4. evoluzione: si modifica il software per adeguarlo ai requisiti dell’utente e del

mercato che cambiano.

Sul processo di sviluppo software fanno perno i metodi e gli strumenti dell’ingegne-

ria del software: i primi costituiscono il sapere tecnico alla costruzione di software

4


ed investono tutte le fasi, i secondi forniscono ai metodi un supporto automatizzato

in tutto od in parte.

Un modello di processo software è una descrizione semplificata del processo soft-

ware, osservato da un determinato punto di vista. Generici modelli di processo

software sono: Waterfall Model, Iterative Development Model, Incremental Model,

Component-based software engineering.

I metodi dell’ingegneria del software sono approcci strutturati per sviluppare soft-

ware di qualità a costi contenuti (Es. OOA, OOD, etc). Essi specificano i modelli

da usare, le regole a cui sottostare, e forniscono una guida alle attività dei processi

e alla relativa organizzazione.

Gli strumenti dell’ingegneria del software sono usati per aiutare le attività dei pro-

cessi software (Ad esempio: analisi, modellazione, debugging, testing).

Figura 1.1.1: Strati di ingegneria del software (R.S. Pressman, 2005)

1.2 Che cosa è il processo di verifica e di validazione

del software

Il collaudo è un insieme di attività che ha come obiettivo l’individuazione di errori

che sono stati commessi inavvertitamente durante la progettazione e realizzazione

del software. Esso fa parte di una fase più vasta chiamata verifica e validazione

(V&V).

5


La validazione è un processo che, partendo dai requisiti d’utente, punta a dimostrare

il soddisfacimento dei reali bisogni dell’utente da parte del sistema software. Data

l’informalità dei requisiti d’utente, la sola validazione non garantisce la correttezza

del software.

La verifica è un processo che, partendo dalle specifiche formali prodotte dall’ana-

lista, punta a dimostrare il soddisfacimento della specifica dei requisiti da parte del

sistema software.

Esistono due approcci fondamentali alla fase di verifica: sperimentale e analitico. Il

primo consiste nello sperimentare il comportamento di un software per analizzare

se questo si comporti secondo le aspettative (test del prodotto). L’altro consiste

nell’analizzare il prodotto e tutta la documentazione di progetto ad esso relativa

per ricavare indicazioni circa la correttezza del suo operare come risultato delle

decisioni progettuali effettuate.

Le due categorie di tecniche di verifica vengono anche classificate come dinamiche

e statiche, in quanto la prima, per definizione, richiede l’esecuzione del sistema

sotto verifica, mentre l’altra è basata sull’analisi di modelli statici del prodotto.

1.3 Il test

Il metodo più naturale e tradizionale per verificare un prodotto è quello di provarlo

in un certo numero di situazioni rappresentative, accertando che si comporti come

previsto. In generale, è impossibile testare un software in tutte le sue possibili con-

dizioni operative; pertanto risulta necessario trovare alcuni casi di test che fornisca-

no con una sufficiente evidenza che il prodotto avrà un comportamento accettabile

anche nelle situazioni in cui non è stato testato.

Il test è un’attività critica nell’ingegneria del software e dovrebbe essere eseguita

nel modo più sistematico possibile, definendo in maniera chiara i risultati che si

6


attendono e il modo in cui si vuole ottenerli. Nella pratica, invece, il test viene

eseguito in maniera non sistematica e senza applicare criteri predeterminati.

Il test può essere usato per dimostrare la presenza di malfunzionamenti, non per

dimostrare la loro assenza (tesi di Dijkstra, 1972).

Il test dovrebbe aiutare a localizzare gli errori e non solo a rilevarne la presenza.

Prima di rilasciare il software finale gli ingegneri devono testare sia i requisiti fun-

zionali che quelli non funzionali, utilizzando eventualmente più di una tecnica di

test.

In questa tesi, si confrontano due tecniche ampiamente utilizzate: test funzionale e

test statistico.

A tal proposito richiamiamo alcune importanti definizioni:

• caso di test: un caso di test è un insieme di input, condizioni di esecuzione

ed un criterio passato/non passato;

• specifica dei casi di test: la specifica dei casi di test è una specifica di un

requisito che deve essere soddisfatto da uno o più casi di test;

• test suite: un test suite è un insieme di casi di test.

1.4 Il problema della selezione delle tecniche di test

Uno dei problemi principali riguardanti il test del software è in che modo ottenere

un opportuno insieme di casi di test utili al fine di testare un software.

Questo insieme dovrebbe assicurare la massima efficacia con il numero minore pos-

sibile di casi di test; d’altro canto ci sono numerose tecniche di test disponibili,

molte non vengono utilizzate e solo alcune sono usate diffusamente.

Alcuni tester hanno ben poco presente le informazioni relative alle tecniche di test

disponibili, la loro utilità, quanto esse siano adatte per il progetto sul quale stanno

lavorando e come fondare la loro decisione su quali tecniche di test utilizzare.

7


Assai utile è fornire un catalogo contenente informazioni sufficienti per selezionare

le migliori tecniche adatte per un dato progetto. Questo assicura che le decisioni che

i tester prendono siano basate sulla conoscenza obiettiva delle tecniche piuttosto che

su percezioni, supposizioni e ipotesi.

Altra questione riguarda la differenza che c’è tra queste tecniche. Possiamo trovare

distinzioni nella letteratura per quanto riguarda gli aspetti meccanici e gli aspetti

di contesto delle tecniche. Tuttavia resta una questione ancora aperta quale sia la

tecnica di test più adatta in una determinata fase per un determinato progetto.

La verità è che, anche se esistono alcuni studi che mettono a confronto le tecni-

che, non ci sono studi che analizzano le condizioni di applicabilità di una tecnica o

che, per ogni tecnica, consentano di valutare quali siano i parametri o le condizioni

maggiormente rilevanti per la sua applicabilità.

Esistono due ragioni principali per cui gli sviluppatori e/o i tester non compiono

buone scelte riguardanti la tecnica di test:

• le informazioni disponibili sulle tecniche sono normalmente distribuite su di-

versi fonti di informazione (libri, articoli e anche persone). Ciò significa che

gli sviluppatori non hanno idea generale di quante tecniche siano disponibili

e di tutte le informazioni di interesse per ogni tecnica;

• non hanno accesso alle informazioni relative a ciascuna tecnica di test a meno

che non l’abbiano usata prima. Gli sviluppatori, inoltre, tendono a non condi-

videre le conoscenze acquisite con gli altri; ciò significa perdere la possibilità

di conoscere le esperienze degli altri.

Ci sono numerose tecniche che non sono universalmente applicabili, quindi ha

senso parlare di una necessità per la selezione.

È generalmente accettato che il processo di selezione preveda un confronto tra le

caratteristiche delle tecniche le cui condizioni di applicabilità sono più vicine alle

condizioni del progetto sul quale si sta lavorando.

8


Pertanto, il problema di selezionare la tecnica di test migliore può essere suddiviso

in due sotto-problemi:

• la corretta identificazione delle caratteristiche rilevanti per la selezione;

• la conoscenza riguardante l’insieme delle tecniche su cui si basa la selezione.

È ragionevole aspettarsi che le azioni prese da un tester, che intende effettuare una

selezione sistematica ed equilibrata delle tecniche di prova, siano:

1. elenco delle tecniche da cui la selezione deve essere effettuata;

2. valutare le caratteristiche rilevanti per le tecniche elencate;

3. valutare le caratteristiche del progetto in questione;

4. confrontare i risultati dei punti 2 e 3 e decidere quale sia la tecnica e/o le

tecniche più adatte per il progetto sul quale si sta lavorando.

Il problema che si cerca di superare è il seguente: il tester deve poter effettuare la

selezione delle tecniche di test basandosi non solo sulla sua conoscenza diretta od

indiretta.

1.5 Metriche e qualità del software

Le metriche del software sono lo strumento attraverso il quale l’ingegnere del soft-

ware misura e/o predice gli aspetti di processo (sviluppo, documentazione, manu-

tenzione, verifica), di prodotto (le specifiche, il codice, i casi di test, i progetti), delle

risorse, delle risorse umane coinvolte (in termini di capacità, produttività, skills) che

sono rilevanti nell’ingegnerizzazione del software.

E’ opportuno che le metriche siano indipendenti dallo sviluppo tecnico e dalle

scelte implementative in modo da poter confrontare tra loro tecniche e tecnologie

differenti.

9


Buone metriche devono essere utili non solo per descrivere aspetti del prodotto o

del processo, ma anche per costruire modelli in grado di predire parametri degli

stessi (ad esempio i costi o l’affidabilità). Per questo motivo esse devono essere

semplici e ben definite in modo che il processo di misurazione sia univoco, oggettivo

e facilmente ottenibile senza costi troppo elevati.

Una metrica caratterizza in modo quantitativo e misurabile gli attributi di una entità.

Una misura è un’empirica oggettiva assegnazione di un valore ad una entità al fine

di caratterizzare uno specifico attributo.

Lo scopo del lavoro di tesi è correlare la presenza di un determinato tipo di guasto ad

un insieme delle metriche del software per cui saremo interessati alle sole metriche

di prodotto.

Esse si suddividono in tre grandi classi:

• metriche dimensionali (size metrics), che si pongono l’obiettivo di calcolare

le dimensioni del sistema in esame in termini di linee di codice, commenti,

linee bianche;

• metriche di complessità (complexity metrics), che comprendono la comples-

sità ciclomatica e il flusso di informazioni;

• metriche di Halstead, quali il vocabolario di programma (n), length (L) e la

metrica di volume (V).

La qualità del software può essere definita come il rispetto di requisiti funziona-

li e prestazionali enunciati esplicitamente, la conformità agli standards di svilup-

po esplicitamente documentati e le caratteristiche implicite che ci si aspetta da un

prodotto software realizzato professionalmente.

Possiamo dividere le qualità del software in due categorie: interne ed esterne.

Le qualità esterne sono visibili agli utenti del sistema mentre le qualità interne

riguardano gli sviluppatori.

10


In generale gli utenti del software hanno interesse soltanto nelle qualità esterne, ma

sono le qualità interne che, in larga misura, hanno a che fare con la struttura del

software, e che influenzano grandemente le qualità esterne.

Per realizzare un prodotto software si utilizza un processo, le qualità del processo

sono spesso correlate con quelle del prodotto.

1.6 Guasto, errore e fallimento

A differenza dei sistemi fisici, la maggior parte dei guasti software riguarda errori

di progettazione e non di fabbricazione. Scoprire gli errori di progettazione è tanto

più difficile quanto più è complesso il software.

Di seguito sono riportate le definizioni di fault, error e failure:

1. un guasto o fault è uno stato improprio dell’hardware e/o del software del

sistema;

2. un guasto causa un errore: un errore o error è il comportamento scorretto di

un sistema (o parte di esso) che può indurre lo stesso a fornire un servizio non

conforme alle specifiche;

3. un fallimento o failure è definito come l’evento in corrispondenza del quale il

sistema cessa di fornire un servizio corretto.

Fault, error e failure sono legati da una precisa relazione definita in letteratura come

patologia del guasto.

Un fault può degenerare in un errore mediante attivazione (fault activation) ed in

tal caso il guasto si dice attivo altrimenti è dormiente. L’attivazione di un gua-

sto provoca la transizione del sistema da uno stato di corretto funzionamento ad

uno stato improprio (errore). Un errore può degenerare in un fallimento mediante

propagazione all’interfaccia utente.

11


Figura 1.6.1: Guasto, errore, fallimento (Domenico Cotroneo, Stefano Russo,Dependability: concetti fondamentali, 2005)

12

Capitolo 2

Un metodo per selezionare la tecnica

di test

2.1 Introduzione

Non c’è una singola tecnica di test che vada bene in tutte le circostanze, al contrario

si tende a combinare l’uso di varie tecniche; ciò capita perché tecniche diverse

risultano avere:

• diversa efficienza per diverse tecniche di guasti;

• applicabilità in diversi punti del progetto (ad esempio: l’ispezione va appli-

cata per validare i requisiti nelle prime fasi);

• obiettivi diversi per diverse tecniche di test (ad esempio: il test statistico serve

a misurare l’affidabilità);

• le tecniche di test vanno scelte cercando un giusto compromesso tra costo

richiesto per il test e qualità richiesta, ad esempio tecniche più costose solita-

mente si destinano a proprietà chiave che il software sotto test deve possedere.

13


Figura 2.1.1: Organizzazione delle tecniche di test (Pezzè, Young, 2008)

14


In passato, molti studi hanno trattato ed hanno comparato i benefici derivanti dalla

combinazione di più tecniche di test, sia attraverso approcci teorici sia attraverso

approcci pratici; resta, però, irrisolto il problema della selezione delle tecniche di

test a supporto di un processo di V&V.

Orthogonal Defect Classification (ODC), miglioramento di Root Cause Analysis

(RCA), è un metodo differenziatosi dagli altri per la capacità di misurare quantita-

tivamente i difetti del software.

La maggior parte degli studi effettuati in passato ha basato la scelta della tecnica

di test sui tipi di difetti riscontrati, invece pochissimi hanno basato tale decisione

anche sulle caratteristiche del prodotto.

L’ideale, al fine di decidere quale tecnica di test scegliere, sarebbe mettere in rela-

zione conoscenze relative alle tecniche di test e conoscenze relative al prodotto. Al-

tri studi, circa la tecnica di test da scegliere, decidono anche in base a caratteristiche

di rilevante importanza per il produttore e per gli utilizzatori.

Il nostro lavoro divide il problema in due sottoproblemi:

1. prevedere i guasti, date le metriche del software;

2. caratterizzare le tecniche rispetto ai guasti.

Questo secondo sottoproblema risulta essere particolarmente vincente perché in es-

so, all’occorrenza, si può tenere conto di caratteristiche utilizzate da qualsivoglia

studio.

2.2 Acquisizione delle metriche

Oggi esiste molta letteratura per la ricerca del miglior insieme di metriche che oc-

corrono per predire i guasti. In sintesi, però, non si può delimitare un insieme di

metriche che risultino essere buoni predittori per diversi prodotti.

15


L’unica cosa sicuramente necessaria è selezionare le metriche più utili in ogni or-

ganizzazione in accordo al tipo ed alla qualità del prodotto software che questa

produce. Il giusto modo di procedere è, quindi, quello di partire da questo insieme

di metriche, per poi rifinirle nel tempo in base a quali di esse si siano rivelate più

utili nella predizione.

Si ricorda che tali metriche possono essere ridotte tramite la Principal Component

Analysis (PCA).

Il passo successivo è la definizione di modelli statistici per prevedere la presenza di

guasti di ogni tipo ODC, utilizzando le metriche del software come predittori. Per

questo scopo, la letteratura propone diversi metodi; quelli utilizzati in questa tesi

sono i modelli di regressione multipla.

2.3 Fault prediction

Nel 1897 Pareto, studiando la distribuzione dei redditi, dimostrò che in una data

regione solo pochi individui possedevano la maggior parte della ricchezza. Questa

osservazione ispirò la cosiddetta "legge 80/20", una legge empirica che fu poi ri-

formulata anche da Joseph M. Juran, ma che è nota anche con il nome di principio

di Pareto (o principio della scarsità dei fattori), e che è sintetizzabile nell’affer-

mazione: «la maggior parte degli effetti è dovuta ad un numero ristretto di cause

(considerando grandi numeri)».

Questo principio può avere diverse applicazioni pratiche in differenti settori, ad

esempio in informatica.

Questo principio dice che:

• l’80% del tempo di esecuzione è impiegato solo dal 20% delle istruzioni di

un programma;

16


• l’80% delle operazioni degli utenti sono dovute al 20% delle funzioni a di-

sposizione di un applicativo;

• l’80% degli errori di codifica è riconducibile al 20% dei moduli;

• l’80% dei visitatori di un sito vede solo il 20% delle pagine.

Anche se gli studi in merito non sempre concordano sulle percentuali, è indubbio

che la maggioranza dei guasti è localizzata in piccole porzioni del codice di un

sistema. In questo scenario si è andata sempre più delineando la fault prediction:

si tratta di un metodo che cerca di localizzare quali siano i moduli o le porzioni di

codice con la più alta densità di guasti in modo da indirizzare in maniera mirata gli

sforzi e le risorse di test o le attività di re-design verso tali moduli; in sintesi essa si

pone l’obiettivo di individuare la fault proneness.

I modelli di fault prediction sono costruiti correlando inizialmente le “caratteristiche

del codice” con i dati noti sulle sue caratteristiche di predisposizione ai guasti, quali

la presenza o meno di guasti, la loro densità o la loro tipologia.

I modelli così costruiti a partire dai dati storici vengono poi utilizzati per predire la

predisposizione ai guasti dei software successivi. Le tecniche utilizzate per costruire

tali modelli sono principalmente tecniche statistiche, mentre le caratteristiche del

codice che vengono utilizzate per predirne l’inclinazione a presentare guasti sono

le metriche del software.

Diversi sono gli studi che, soprattutto negli ultimi anni, si stanno concentrando

sull’individuazione dei modelli più adatti allo scopo e diverse anche le metriche

considerate.

Per quanto riguarda le metriche utilizzate, rari sono gli studi che si occupano della

correlazione tra una singola metrica e la fault proneness, poichè è risaputo che, in

tal senso, un set di metriche sia più efficace.

17


Figura 2.3.1: Tassonomia dei guasti (Laprie, 2004)

2.4 Modelli predittivi

Per eseguire la predizione dei guasti, una volta stabilite le metriche software da

considerare, bisogna ricavare i modelli di previsione, che permetteranno di stimare

successivamente il numero di guasti presenti nel software in esame.

Gli studi in quest’ambito sono numerosi e le tecniche statistiche utilizzate a tal

scopo sono diverse.

In questa tesi si farà riferimento a due tecniche in particolare: la Principal Compo-

nent Analysis (PCA) e la Stepwise Multiple Linear Regression.

2.4.1 Regressione

Lo studio delle relazioni tra due o più variabili costituisce uno degli obiettivi prin-

cipali delle analisi statistiche.

18


Le relazioni tra variabili quantitative sono studiate dalla teoria della correlazione e

dalla teoria della regressione.

L’obiettivo della teoria della correlazione è l’individuazione (se esiste) di una rela-

zione tra due (o più) variabili oggetto di studio.

L’obiettivo della teoria della regressione è la misurazione della variazione di una

variabile quando cambiano i valori di un’altra (o più) variabile.

La covarianza è un indice che misura l’esistenza di una relazione lineare fra i valori

di due variabili X ed Y. Si dice covarianza tra due variabili X ed Y, e si indica con

COV (X ,Y ), la media aritmetica dei prodotti degli scostamenti:

COV (X ,Y ) =1n

n

∑i=1

(xi−Mx)(yi−MY ) (2.4.1)

valori positivi indicano l’esistenza di una relazione lineare diretta, valori negativi di

una relazione inversa; un valore pari o prossimo a 0 corrisponde all’assenza di un

legame lineare (ma non esclude legami di altro tipo - parabolico, sinusoidale, etc).

Si dice coefficiente di correlazione lineare tra due variabili X ed Y e si indica con

r(X ,Y ), o più brevemente con rxy, la media dei prodotti della loro covarianza diviso

il prodotto delle rispettive deviazioni standard:

r(X ,Y ) =1n

n

∑i=1

(xi−Mx)

σx

(yi−MY )

σy(2.4.2)

Nello studio delle relazioni tra due (o più) variabili, oltre a misurare l’entità del

legame esistente, si è anche interessati ad accertare come varia una di esse al variare

dell’altra (o delle altre), cioè ad individuare un’opportuna funzione che metta in

relazione due o più variabili (di cui una dipendente e le altre indipendenti). Nel

caso di una sola variabile indipendente si parla di regressione semplice, in presenza

di due o più variabili indipendenti si parla di regressione multipla.

Il legame più semplice tra due variabili è quello lineare, ossia, supponendo di di-

19


sporre di n coppie di osservazioni (yi,xi), il modello di regressione lineare semplice

è:

yi = a+βxi + ei (2.4.3)

dove:

• a è detta intercetta e rappresenta il valore a cui tende a stabilizzarsi la Y

quando la X è zero.

• b è detto coefficiente angolare e rappresenta la variazione che si realizza nella

Y per ogni aumento unitario in X .

La retta di regressione migliore è quella che più si avvicina all’insieme dei punti

corrispondenti alle coppie di valori (yi,xi).

2.4.2 Principal Component Analysis

La Principal Component Analysis (PCA) (Jolliffe, 2002), è una tecnica di appren-

dimento ampiamente utilizzata per la riduzione della dimensionalità, compressione

dei dati ed estrazione di caratteristiche.

Le componenti principali (Principal Component, PC) calcolate permettono di pro-

iettare i dati in uno spazio lineare (eventualmente a minore dimensionalità), dove la

varianza dei dati proiettati è massimizzata.

Ogni PC è espressa come :

PCi =m

∑j=1

ai jX jcon1≤ i≤ m (2.4.4)

dove:

• le X j sono le variabili originali.

20


• m è il numero di variabili.

• ai j sono coefficienti che esprimono il peso che la j-esima variabile originale

ha sull’i-esima PC.

Il modello di regressione lineare che si ottiene applicando questa tecnica è :

Y = a1PC1 +a2PC2 + . . .+anPCn (2.4.5)

dove:

• le Y è la stima dei guasti di un certo tipo ODC.

• ai j sono i coefficienti delle PC selezionate.

• PCi sono le PC selezionate.

2.4.3 Stepwise regression

La Stepwise Multiple Linear Regression è una tecnica statistica di regressione euri-

stica in cui la scelta delle variabili predittive è condotta attraverso una procedura au-

tomatica. Essa considera una parte dell’insieme iniziale delle variabili (predittori) e

tenta di aggiungere step-by-step una nuova variabile che migliora il modello oppure

prova ad eliminare una variabile con coefficiente non statisticamente significativo.

Questo porta ad un sottoinsieme minimo di variabili che forniscono il miglior mo-

dello.

2.4.4 Quale modello predittivo scegliere

Mentre la prima tecnica (PCA) ha il vantaggio di utilizzare variabili non correlate

e presenta il problema di avere variabili (PC) che non hanno un significato fisico,

ma sono una combinazione delle variabili originali, invece la Stepwise regression

21


non utilizza variabili totalmente incorrelate, ma conserva il significato fisico dei

predittori.

Per avere i migliori modelli di regressione, gli ingegneri potrebbero confrontare i

risultati di entrambe le tecniche; questi, per ogni modello, dovrebbero confronta-

re i risultati della PCA con quelli derivanti dalla Stepwise regression per poi sce-

gliere il migliore. Si tratta di scegliere tra il potere predittivo e persistenza della

significatività.

Scelto il modello più adatto, i tester possono ottenere i tipi di guasto stimati.

È importante sottolineare che, anche se i modelli costruiti possono produrre previ-

sioni accurate, i tester non dovrebbe avere l’ambizione di trattarli come se fossero

reali: le previsioni sono sempre legate alle applicazioni di specifici dati scelti come

campioni e per il contesto in cui essi vengono ottenuti.

D’altra parte, adottando sistematicamente un metodo all’interno di un’organizzazio-

ne, il numero di campioni aumenta con il tempo, ottenendo iterativamente modelli

di previsione sempre migliori.

2.5 Classificazione dei guasti

Nei sistemi moderni, i guasti software sono la causa principale di fallimento o

dell’erogazione di un servizio con prestazioni degradate.

Questo accade perché, mentre esistono tecniche di hardware faults avoidance e faul-

ts tolerance già consolidate e robuste, lo stesso non si può dire per le analoghe

tecniche applicate al software.

L’obiettivo delle attività di verifica è attivare tali faults durante la fase di test del

sistema in modo da eliminarli prima che esso diventi operativo. Sono state propo-

ste diverse classificazioni applicabili ai software faults, di volta in volta di natura

quantitativa o qualitativa, ognuna delle quali focalizza un particolare aspetto.

22


Nel seguito illustreremo brevemente la Orthogonal defects classification (ODC).

Orthogonal Defect Classification è lo schema di riferimento per la classificazione

dei guasti in funzione della loro semantica; introdotto nel 1992, l’ODC rappresenta

oggi il riferimento del settore relativo ai guasti e a tutte le attività ad essi connesse.

La tecnica ODC rende possibile l’organizzazione dei difetti in classi che consentono

di inferire sul processo di sviluppo software (in particolare su una fase: design,

development, test, etc).

La classificazione dei guasti si articola in due fasi: quando i guasti sono rilevati e

quando questi sono corretti. Quando il guasto è rilevato, si registrano le informa-

zioni chiave quali l’attività che è stata eseguita quando il guasto è stato rilevato, la

condizione che l’ha reso visibile, l’impatto del guasto reale o percepito dall’utente.

Quando il fault è eliminato, invece, devono essere registrati: il target (l’entità corret-

ta per rimuovere il fault), la sorgente (l’origine del fault), il tipo e l’età dell’elemento

oggetto del fault.

Il tipo di guasto è l’informazione più difficile da classificare: l’ODC definisce i tipi

semplici ed ortogonali, in modo da evitare confusione.

I difetti software vengono così definiti:

• ASSIGNMENT: il guasto coinvolge poche linee di codice, come l’inizializza-

zione dei blocchi di controllo o le strutture dati. L’assegnazione può essere o

mancante o non correttamente implementata;

• CHECKING: il guasto riguarda la logica del programma che non è riuscita

a validare correttamente i dati ed i valori prima di essere utilizzati. Esempi

sono la validazione mancante o validazione non corretta dei parametri o dei

dati negli statement condizionali;

• INTERFACE: i guasti corrispondono a errori di interazione con altri compo-

nenti, moduli o driver di dispositivi, attraverso macro, statement di chiamata,

blocchi di controllo o liste di parametri;

23


• SERIALIZATION: il guasto corrisponde alla serializzazione di risorse condivi-

se, incompleta o non corretta. Esempi sono deadlock o deadline non rispettate

in sistemi hard-real time;

• ALGORITHM: i guasti includono problemi di efficienza e correttezza dei task e

possono essere rimossi (re)implementando un algoritmo o strutture dati locali

senza dover modificare il design;

• FUNCTION: i guasti che interessano le funzionalità, le interfacce utente, in-

terfacce con l’hardware o strutture dati globali e non dovrebbero richiedere

modifiche del design formale. Di solito questi guasti riguardano una notevole

quantità di codice e si riferiscono alle capacità o implementate in modo non

corretto oppure non implementate del tutto;

• DOCUMENTATION: i guasti fanno riferimento alla pubblicazione e alla corre-

zione della documentazione relativa al software. Hanno una grossa significa-

tività solo nelle fasi iniziali del ciclo di sviluppo del prodotto;

• BUILD/PACKAGE/MERGE: i guasti si presentano per errori nelle librerie di

sistema, nel controllo delle versioni. Piuttosto che essere legati al prodotto

in fase di sviluppo, questi guasti sono principalmente dovuti al processo di

sviluppo e ai tool utilizzati.

La classificazione e la successiva analisi dei dati di ODC consentono agli ingegneri

di valutare le varie fasi del ciclo di vita del software e la maturità del prodotto.

2.6 Caratterizzazione delle tecniche di test

La pianificazione delle attività di test richiedono innanzitutto la conoscenza del-

le caratteristiche del software sotto test nonché le caratteristiche di tecniche che

potrebbero essere adottate per il software sotto test.

24


Ogni tecnica di test è caratterizzata in relazione a:

• tipi di guasto che sono più inclini a rilevare;

• calcolo del costo che l’esecuzione della particolare tecnica di test richiede;

• numero di guasti totali rilevati indipendentemente dal tipo.

Valutare l’atteggiamento verso il particolare tipo di guasto della particolare tecnica

è l’aspetto più rilevante per il nostro scopo. Il numero dei guasti rilevati per tipo è,

infatti, una informazione più specifica rispetto al numero totale di guasti: sapendo

che una tecnica rileva più guasti rispetto ad un’altra può non essere sufficiente per

scegliere la migliore tecnica. Una tecnica può essere in grado di rilevare guasti più

di un tipo che non è (più) presente nel software.

Se il software, in qualsiasi momento, è particolarmente influenzato da guasti di un

certo tipo, il tester può decidere di applicare una tecnica che è più incline verso quel

tipo piuttosto che una tecnica che rileva, in assoluto, più guasti.

La valutazione del numero di guasti totali rilevati può aiutare il tester a decidere di

ignorare le informazioni sui tipi di guasto (ad esempio, non c’è ancora abbastanza

abilità nell’organizzazione verso la tecnica ODC ).

Valutare il costo di rilevamento aiuta il processo decisionale considerando il budget

a disposizione per il test.

In questo lavoro di tesi le tecniche analizzate sono la tecnica di test funzionale e la

tecnica di test statistico. In generale, queste tecniche sono state concepite per per-

seguire obiettivi differenti e la loro applicazione è volta a migliorare alcuni aspetti

specifici del software sviluppato. Nel contesto di questo lavoro, l’obiettivo princi-

pale è quello di caratterizzare il loro comportamento riguardo al particolare tipo di

guasto che sono più inclini a rilevare.

Vale la pena notare che queste tecniche sono usate per la fase di test del sistema,

quindi dopo unità e test di integrazione.

25


2.6.1 Tecniche di test: test funzionale e test statistico

Il test funzionale è detto anche “black-box test” oppure “specfication-based test”

perché non c’è visibilità del codice; si derivano i casi di test dalle specifiche fun-

zionali dove per specifiche funzionali si intende la descrizione del comportamento

atteso del software.

Il test funzionale è tipicamente una tecnica di base per il progetto dei casi di test, che

possono essere progettati secondo vari criteri; tra tutti i criteri quello sistematico va

per la maggiore: si prova a selezionare input particolarmente rilevanti scegliendo

quei valori rappresentativi di classi che tendono a fallire spesso od a non fallire

mai. I valori di input, data la loro vastità, vengono suddivisi secondo un criterio di

equivalenza.

Un caso di test ideale rileva da solo una classe di errori che altrimenti avrebbero

richiesto l’esecuzione di molti test. Bisogna testare ogni categoria e l’esperienza

suggerisce che i guasti spesso si trovano a limite tra le categorie.

Come su menzionato, i casi di test vanno estratti dalla specifica attraverso quattro

semplici passi:

1. si decompone la specifica funzionale in caratteristiche testabili indipendente-

mente;

2. si selezionano dei valori rappresentativi di ogni input;

3. si formano le specifiche dei test (combinazioni input e comportamenti);

4. si producono e si eseguono i test effettivi.

Il fulcro della progettazione dei casi di test funzionali è il partizionamento dei pos-

sibili comportamenti di un programma in un numero finito di classi che possono es-

sere sostanzialmente corrette o non corrette. In pratica, il progettista dei casi di test

spesso deve anche completare il lavoro di formalizzazione della specifica per avere

una solida base di partenza per l’identificazione delle classi dei comportamenti.

26


Un importante effetto di questa fase è evidenziare le debolezze e le specifiche in-

complete. Derivare i casi di test funzionali rappresenta un processo analitico che

decompone le specifiche nei casi di test.

L’infinità di aspetti che devono essere considerati durante la specifica dei casi di

test funzionali rende il processo complesso e vulnerabile agli errori. Può capitare,

infatti, che anche i progettisti esperti non includano un caso di test importante. La

soluzione è un approccio sistematico per questo tipo di progettazione che aiuti a de-

comporre l’intero processo in attività elementari che affrontano ogni singolo aspetto

di quest’ultimo. In questo modo è possibile governare la complessità del processo

e separare le attività che possono essere automatizzate (è il caso delle specifiche

formali) e quelle che invece devono essere svolte necessariamente dall’uomo (si è

di fronte ad una grossa mole di specifiche informali).

L’obiettivo del test statistico è quello di migliorare l’affidabilità del software, intesa

come la probabilità che l’applicazione non fallisca durante la sua esecuzione.

Il test statistico prevede la generazione di casi test secondo la filosofia black-box,

ossia la stessa del test funzionale che non necessita della conoscenza del codice.

Tale tecnica prevede due fasi: stima del profilo operazionale (suddivisione in classi

delle funzionalità ) e selezione dei casi di test.

La prima fase si realizza raggruppando i casi di test in classi e seguendo un criterio

scelto a priori come la tipologia delle funzionalità del prodotto. Ad ogni classe

di test viene associata una probabilità di selezione con il criterio di rendere più

probabili la scelta delle principali funzionalità del software, che si suppone vengano

usate di più a runtime.

La sceonda fase (selezione dei casi test) viene realizzata scegliendo gli input in ma-

niera casuale, secondo la distribuzione associata alle varie classi, che permettono di

individuare la classe e il test da eseguire. I risultati ottenuti dai casi di test vengono

confrontati con un oracolo, così come avviene anche per il test funzionale.

Questa tecnica di test può essere interpretata come una euristica basata sui casi

27


Figura 2.6.1: Test Case Design (Pezzè,Young, 2008)

28


test del Functional Testing. Tale considerazione rende interessante verificarne il

comportamento in relazione al Functional Testing.

2.6.2 Quale tecnica scegliere

Trovati i modelli per stimare i guasti presenti nel software, bisogna scegliere quale

tecnica di test applicare.

Per scegliere, tra le tante, la tecnica corretta per un determinato prodotto, biso-

gna conoscerle approfonditamente, cosa che può essere ottenuta ragionevolmente

mettendole a confronto.

In questa tesi, si confrontano due tecniche ampiamente utilizzate nella fase di Veri-

fica: test funzionale e test statistico.

L’osservazione cruciale è: cercare di fornire supporto ai tester attraverso analisi em-

piriche. Questo supporto corrisponde a “come ottenere conoscenza e come sfruttar-

la”. La conoscenza in questo caso è intesa come prestazione delle tecniche usate e

relazione tra l’applicazione testata ed i guasti rilevati.

A partire dai guasti rilevati è possibile calcolare, a tal proposito, Ai, j (indice di

attinenza), che esprime quanto una tecnica di test i è capace di rilevare un guasto di

tipo j ( j = 1 . . .5 rappresenta uno dei 5 tipi ODC).

Il calcolo di Ai, j è semplice:

Ai, j =Vi, j/100 (2.6.1)

dove Vi, j è la percentuale di fault di tipo j rilevati dalla tecnica i in applicazioni pas-

sate della stessa tecnica; questo calcolo è fatto una tantum alla prima applicazione

della strategia.

Dall’indice Ai j si può ottenere una stima del numero di guasti che una tecnica i

prevede di rilevare (i guasti potenzialmente rilevabili dalla tecnica i); questo nuovo

indice è detto #DFaultsi (Detectable Faults) e si calcola come segue:

29


#DFaultsi(t) =5

∑j=1

#Fault j(t)∗Ai, j con i = 1 . . .N (2.6.2)

dove #Fault j è il numero di fault di tipo j previsti presenti nell’applicazione ad un

certo istante di tempo t ed N è il numero di tecniche di test.

La scelta della tecnica ricade su quella che presenta il #DFaultsi maggiore, vale

a dire si sceglie la tecnica che potenzialmente all’istante di tempo t è in grado di

rilevare più errori. Il calcolo del #DFaultsi deve essere ripetuto ogni qualvolta si

rilevi un nuovo guasto.

30

Capitolo 3

Progettazione ed implementazione

del tool

3.1 Introduzione

Data la complessità e la crucialità dei processi appartenenti ad un buon piano di

V&V si richiede, soprattutto in sistemi critici, la creazione e l’utilizzo di un fra-

mework che possa guidare l’intero ciclo di sviluppo del sistema software miglio-

randone l’efficienza dalla pianificazione alla sua esecuzione, integrando strategie di

gestione delle risorse, tecniche di test, di analisi, tool di V&V, gestione dei casi di

test e dei risultati, moduli per la valutazione della qualità finale e moduli per stime

dei tempi/costi necessari.

3.2 Requisiti del Framework

Un requisito è una frase che descrive qualcosa che il sistema farà e che tutti gli

stakeholders ritengono necessario per la risoluzione del problema.

I requisiti del framework sono i seguenti:

31


1. il framework dovrà acquisire la qualità richiesta al sistema da sottoporre al-

l’attività di V&V espressa in termini di coppia attributo/valore;

2. il framework dovrà acquisire le risorse disponibili destinate alle attività di

V&V;

3. basandosi sulle caratteristiche del software e delle tecniche di V&V che è

possibile adottare in azienda, il framework dovrà fornire una pianificazione

delle attività di V&V per ogni sottosistema, indicando per ognuna di esse i

tempi e le modalità di utilizzo delle tecniche, i tool da adottare, l’ordine di

esecuzione delle tecniche e le risorse da impiegare per ciascuna di esse;

4. il framework dovrà fornire una caratterizzazione del sistema software da ve-

rificare/validare, ossia una descrizione quantitativa delle caratteristiche del

sistema;

5. il framework dovrà fornire una caratterizzazione delle tecniche di V&V che

vengono adottate in azienda, ossia una descrizione quantitativa delle presta-

zioni osservate in termini di difetti rimossi, tempi di rimozione, tempi di

setup;

6. il framework dovrà permettere l’adozione di eventuali nuove tecniche e/o tool

di test/analisi sviluppate da terze parti e l’integrazione con le tecniche/tool

esistenti;

7. il framework dovrà fornire una stima della qualità del prodotto finale ed una

stima dei miglioramenti ottenuti, da sistema a sistema, nella fase di V&V

attraverso metriche di qualità di prodotto e di processo di V&V;

8. il framework dovrà tener memoria delle nuove conoscenze prodotte dalla

V&V di un sistema, relative sia alla caratterizzazione del software sia alla

caratterizzazione delle tecniche di V&V;

32


9. il framework dovrà fornire servizi per facilitare l’integrazione in vari processi

di sviluppo.

3.3 Progetto del Framework

L’architettura di un framework che possa fare quanto su menzionato è rappresentata

sotto:

V&V Techniques Manger

Planner

Resource Allocator Scheduler

MonitorAssessment

&Control

Knowledge base

Component Characteriza

tion

V&V Activities

Data

Process Data

New Testing Tool

Report Manager

Test Generator

Deployer Orchestrator Observer

Adapter

Complex and Critical System

Figura 3.3.1: Architettura di un framework a supporto V&V

Il componente Planner implementa la pianificazione delle attività di V&V sulla

base dei requisiti iniziali, degli obiettivi di qualità fissati entro determinati vincoli

temporali e di costo, delle risorse disponibili e delle caratteristiche del sistema da

validare.

33


Esso si avvale dell’utilizzo di due componenti: il Resource Allocator e lo Scheduler

delle tecniche di test ed analisi. Il componente Resource Allocator è responsabile di

determinare le politiche di allocazione delle risorse sulla base degli obiettivi definiti

e tramite l’uso di modelli matematici per l’ottimizzazione dell’utilizzo delle risorse

( budget, competenza e quantità del personale, tool, etc ). Le risorse disponibili

vanno distribuite tra i sottosistemi in esame.

Il componente Scheduler è, invece, responsabile della selezione delle tecniche da

adottare per ogni specifico sottosistema, determinando dunque quali tecniche sa-

ranno adottate ed in che ordine.

L’output del modulo Planner prevede:

• il rilascio di un piano di distribuzione ottimale delle risorse disponibili per la

V&V dei sottosistemi;

• la pianificazione temporale delle singole tecniche di V&V per ogni sottosi-

stema;

• l’assegnazione dei compiti al personale, guidata dalle caratteristiche del sot-

tosistema stesso e dalla conoscenza storica prodotta in azienda relativamente

alle prestazioni delle tecniche e alle attitudini osservate del personale impie-

gato.

Il modulo V&V Techniques Manager è responsabile dell’esecuzione effettiva del

piano di V&V ( generazione dei test e gestione dei report per una generica tecnica

di test/analisi ).

Il modulo Knowledge base è responsabile della memorizzazione di tutte le in-

formazioni prodotte, della memorizzazione delle referenze metriche-guasti e delle

referenze guasti-tecniche.

Il componente Monitoring, Assessment & Control contiene modelli di controllo di

processo e di predizione statistici, che danno una stima della qualità attuale del pro-

dotto e del tempo ancora necessario a completare il test per raggiungere gli obiettivi

34


di qualità (con una data confidenza). Esso agisce da intermediario tra i moduli che

pianificano ed eseguono il test ed il modulo Knowledge base.

I componenti Deployer, Orchestrator, Observer si occupano dell’interfacciamento

tra il framework ed il sistema da testare.

Il componente Adapter si occuperà di far interagire il framework con eventuali tool

esistenti.

3.4 Lo Scheduler

Il modulo Scheduler, come anticipato, è responsabile della selezione delle tecniche

da adottare per ogni specifico sottosistema, determinando dunque quali tecniche

saranno adottate ed in che ordine.

Basandosi su informazioni ricavate dal Resource Allocator relative alle risorse di-

sponibili per ogni sottosistema, il componente acquisisce ulteriori informazioni sul-

le caratteristiche del sottosistema per scegliere il mix di tecniche più idonee. L’idea

di fondo è che la scelta delle attività di V&V per ogni sottosistema dovrebbe essere

guidata dalle caratteristiche del sottosistema stesso, in quanto è noto che la stessa

tecnica, se applicata a sistemi diversi, dà risultati differenti se applicata a sistemi

diversi; questo perché sistemi diversi danno luogo a guasti di tipo diverso, che sono

più o meno propensi ad essere rilevati con una tecnica piuttosto che con un’altra.

Responsabilità di questo componente è perciò individuare le caratteristiche del sot-

tosistema che più possono influire sulla efficienza di una tecnica. Per realizzare

questa funzione, è necessaria una definizione preliminare delle metriche e uno sche-

ma di classificazione dei guasti da adottare all’interno dell’azienda (dati provenienti

dall’esperienza, metrica X individua guasto Y). In questo modo si riesce a sfruttare

la correlazione esistente tra metriche del software e tipi di guasti, utili per lo svilup-

po di modelli di predizione che, date le metriche in ingresso, forniscono una stima

del numero e del tipo di guasti che ci si aspetta di trovare in un software.

35


Knowledge base

Component

Characterization

V&V Activities

Data

Process Data

Metrics - ODC

ODC - Techniques

Figura 3.4.1: Correlazione metriche e tipi di guasti

Avendo una caratterizzazione dei guasti in termini di tipologia e numero, il com-

ponente individua le tecniche più adatte a rilevare quegli specifici guasti. Questa

conoscenza va necessariamente costruita dall’azienda nel tempo, collezionando in-

formazioni sulle attività di verifica svolte sui propri prodotti ed in particolare, evi-

denziando la relazione tra le tecniche ed i tipi di guasti che sono state in grado di

rilevare in progetti o release passate. Tali informazioni sono conservate dal mo-

dulo Knowledge base come V&V Activities Data (ODC - Tecniche) e vengono

aggiornate release dopo release.

Lo Scheduler si interfaccia con tale modulo tramite il modulo di Monitoring, As-

sessment & Control.

36


3.5 Requisiti dello Scheduler

I requisiti del componente Scheduler sono i seguenti:

1. il componente Scheduler dovrà accettare informazioni riguardanti le risorse

disponibili per il sottosistema da analizzare/testare;

2. basandosi sulle caratteristiche del software e delle tecniche di V&V che è

possibile adottare in azienda, il componente Scheduler dovrà fornire una pia-

nificazione delle attività di V&V per ogni sottosistema, indicando per ognuna

di esse i tempi e le modalità di utilizzo delle tecniche, i tool da adottare, l’or-

dine di esecuzione delle tecniche e le risorse da impiegare per ciascuna di

esse;

3. il componente Scheduler dovrà fornire una caratterizzazione del sottosistema

da verificare/validare, ossia una descrizione quantitativa delle caratteristiche

del sottosistema;

4. il componente Scheduler dovrà fornire una caratterizzazione delle tecniche

di V&V che vengono adottate in azienda, ossia una descrizione quantitativa

delle prestazioni osservate in termini di difetti rimossi, tempi di rimozione,

tempi di setup;

5. il componente Scheduler dovrà dare la possibilità all’utente di aggiungere

nuove informazioni relative alle caratteristiche del software ed alle prestazioni

delle tecniche di V&V osservate;

6. il framework dovrà tener memoria delle nuove conoscenze prodotte dalla

V&V di un sistema relative sia alla caratterizzazione del software sia alla

caratterizzazione delle tecniche di V&V.

Di seguito i requisiti ad un più basso livello di astrazione del componente Scheduler:

37


1. il componente Scheduler dovrà accettare informazioni riguardanti le risorse

disponibili per il sottosistema da analizzare/testare dal componente Resource

Allocator;

2. le caratteristiche del sottosistema dovranno essere espresse in termini di me-

triche di prodotto;

3. i guasti saranno caratterizzati da un tipo, in accordo alla classificazione ODC.

Un utente, nel corso dell’esecuzione delle attività di V&V, dovrà essere in

grado di memorizzare quali e quanti guasti sono stati rilevati e da quali tecni-

che;

4. il componente Scheduler dovrà ottenere una stima del numero e dei tipi di

guasti ODC che ci si aspetterà di trovare sottomettendo al componente Kno-

wledge Base le metriche del sottosistema da verificare/validare;

5. il componente Scheduler dovrà ottenere degli indici di attinenza delle tecni-

che verso ogni tipo di guasto, consultando il componente Knowledge Base;

6. il componente Scheduler dovrà fornire, per ogni specifico sottosistema, il pia-

no delle tecniche di V&V da adottare sulla base della stima dei guasti ODC

attesi e degli indici di attinenza: nel piano saranno specificate i tempi e le

modalità di utilizzo delle tecniche, i tool da adottare, l’ordine di esecuzione

delle tecniche e le risorse da impiegare per ciascuna di esse;

7. il componente Scheduler dovrà aggiornare il piano sulla base dei guasti che

vengono man mano rimossi. Tali guasti sono inseriti manualmente dall’uten-

te;

8. il componente Scheduler dovrà aggiornare una base di dati centrale che dovrà

contenere tutte le informazioni raccolte prima e dopo la sua esecuzione.

38


3.6 Flusso di lavoro dello Scheduler

In questa tesi si propone la progettazione e l’implementazione di un tool che sia

di supporto al tester; quest’ultimo è interessato a rimuovere dal software sotto te-

st quanti più guasti possibili e, inoltre, vuole condurre il lavoro di test tramite la

tecnica più efficiente.

Il tool è costituito dai seguenti passi:

1. caratterizzazione del software sotto test;

2. stima dei guasti;

3. scelta della migliore tecnica;

4. inserimento guasto individuato;

5. ripetizione passo 3 e 4.

39


Modelli predittivi

Stima dei guasti

Caratterizzazione software sotto test

Indici tecnica-guasti

Rilascio piano

Guasti trovati

Fine

No

Si

Inizio

Figura 3.6.1: Diagramma di flusso Scheduler

3.7 Diagramma dei casi d’uso

Un caso d’uso rappresenta le funzionalità del sistema da realizzare così come per-

cepite - all’esterno - dall’utente (modalità di utilizzo del sistema sistema da parte

degli attori) o le funzionalità che il sistema offre ai suoi utilizzatori.

I casi d’uso svolgono un duplice ruolo nello sviluppo di un sistema. Da un lato, so-

prattutto nelle fasi iniziali della progettazione, servono per chiarire cosa dovrà fare

il sistema. Ragionare sui casi d’uso con il committente e con le altre funzioni inte-

ressate è uno dei modi più efficaci ed efficienti per scoprire ed analizzare i requisiti

ai quali il sistema dovrà fornire un’implementazione. Dialogare su come il sistema

verrà utilizzato, nella comunicazione con persone non esperte nella progettazione

40


di sistemi, è certamente più facile che non guardare a come dovrà essere costruito,

alla sua strutturazione interna. Raggiungere un accordo con il committente sulle

modalità di utilizzo del sistema consente al progettista di affrontare con maggiore

tranquillità, e in separata sede, il suo mestiere specifico di progettazione.

Sull’altro fronte, i casi d’uso guidano l’intero progetto di sviluppo: costituiscono

il punto di partenza per la progettazione del sistema (lo studio dell’architettura, la

creazione dei modelli di analisi e disegno, la realizzazione del codice applicativo);

sono il riferimento primario per la definizione, la progettazione, l’esecuzione dei

test per la verifica di quanto prodotto; rappresentano delle naturali unità di rila-

scio per i progetti che seguono un approccio incrementale alla pianificazione della

realizzazione e dei rilasci.

Il diagramma dei casi d’uso è composto da 4 elementi essenziali:

• gli attori: sono i soggetti esterni al sistema che interagiscono con il sistema;

• i casi d’uso: sono le funzionalità che il sistema mette a disposizione dei suoi

utilizzatori;

• il sistema: è l’entità i cui utilizzi vengono descritti dall’insieme dei casi d’uso;

• le associazioni: ogni caso d’uso è collegato ad uno o più attori mediante una

associazione che ha il significato di “partecipazione”.

41


Sistema

Attore

Caso d'uso

Caso d'uso

Caso d'uso

Figura 3.7.1: Diagrammi dei casi d’uso generico

Altre nozioni importanti riguardante i casi d’uso sono:

• descrivere l’interazione tra attori e sistema, senza rivelare l’organizzazione

interna del sistema;

• essere redatti in modo da essere comprensibili anche ai “non addetti al lavo-

ro”;

• essere definiti a livelli diversi (sistema o parti del sistema);

• ragionare sui casi d’uso aiuta a scoprire i requisiti del sistema.

42


Scheduler

Attore

Ricava le caratteristiche del sottosistema

Richiede piano di V&V

Inserisce guasto

Aggiorna informazioni dopo rilevamento guasti

Figura 3.7.2: Diagramma dei casi d’uso Scheduler

3.8 Diagramma delle classi

Lo scopo di un diagramma delle classi è quello di rappresentare le classi all’interno

di un modello.

In un’applicazione Object Oriented le classi sono caratterizzate da attributi, opera-

zioni e relazioni con altre classi; il diagramma delle classi UML può rappresentare

tutte queste cose abbastanza facilmente.

La programmazione orientata agli oggetti (OOP, Object Oriented Programming) è

un paradigma di programmazione che permette di definire oggetti software in grado

43


di interagire gli uni con gli altri attraverso lo scambio di messaggi. È particolarmen-

te adatta nei contesti in cui si possono definire delle relazioni di interdipendenza tra

i concetti da modellare (contenimento, uso, specializzazione).

Tra gli altri vantaggi della programmazione orientata agli oggetti notiamo:

• fornisce un supporto naturale alla modellazione software degli oggetti del

mondo reale o del modello astratto da riprodurre;

• permette una più facile gestione e manutenzione di progetti di grandi dimen-

sioni;

• l’organizzazione del codice sotto forma di classi. Quest’ultima favorisce la

modularità e il riuso del codice.

Un diagramma delle classi rappresenta i tipi di entità in un modello.

L’elemento fondamentale del diagramma delle classi è un’icona che rappresenta

una classe:

ResponsabilitaResponsabilita

ProprietaProprieta

NomeClasse

Figura 3.8.1: Classe

Una classe è una entità che rappresenta una tipologia di oggetti od un oggetto che

ha proprie proprietà e svolge particolari operazioni.

Gli oggetti che costituiscono un sistema software non sono in generale isolati, ma

collegati ad altri oggetti con legami di varia natura, detti “relazioni”.

Le principali relazioni tra classi sono:

44


• la relazione di associazione;

• la relazione di generalizzazione-specializzazione;

• la relazione di contenimento.

Le relazioni tra classi definiscono il cosiddetto modello statico del progetto.

L’associazione tra due (o più) classi esprime un legame semantico tra le classi. Essa

è caratterizzata da:

• un nome: esprime il legame semantico tra le classi associate;

• un eventuale ruolo giocato dalle parti associate;

• la molteplicità dell’associazione: esprime la cardinalità delle connessioni tra

oggetti “istanze” delle classi associate e può essere di tipo

– uno a uno;

– uno a molti;

– molti a molti.

• la direzionalità (uni o bidirezionale): specifica il verso di percorrenza della re-

lazione ed attribuisce inoltre alla classe origine del percorso la responsabilità

di tenere traccia dell’associazione.

MetricSet Componentdescrive

Figura 3.8.2: Associazione

Un tipo particolare di associazione, proprio dei modelli Object-Oriented, è la rela-

zione di generalizzazione, un attributo di classe il cui valore è la lista delle classi (o

45


dei tipi) dalle quali la classe eredita le caratteristiche. La super classe raccoglie un

comportamento comune.

I diagrammi di queste associazioni sono chiamati strutture di ereditarietà.

L’ereditarietà può essere singola o multipla.

L’ereditarietà del tipo può essere distinta da quella della classe perché nella prima

si eredita solo la specifica e non l’implementazione. L’UML non ha una notazione

specifica per questo, ma utilizza una linea tratteggiata che termina con una freccia

per indicare l’ereditarietà dell’interfaccia.

Superclasse

Sottoclasse

Libro

eBook

RichiestaRestituzione

TitoloISBN

Libro

DimensioneNome classe

Figura 3.8.3: Ereditarietà

Un altro tipo particolare di associazione è la relazione di contenimento fra ogget-

ti (aggregazione) che può essere di tipo lasco o stretto, così come illustrato nei

diagrammi che seguono.

La relazione di contenimento lasco indica l’indipendenza del ciclo di vita dell’og-

getto contenuto dall’oggetto contenitore; l’oggetto contenuto potrà quindi esistere

anche indipendentemente dal contenitore. Ciò comporta la non responsabilità da

parte del contenitore per la creazione e distruzione dell’oggetto contenuto.

La relazione di contenimento stretto indica, concettualmente, che l’oggetto con-

tenuto non ha una vita propria ma esiste in quanto parte dell’oggetto contenitore.

46


L’oggetto contenitore, quindi, è anche responsabile della costruzione e distruzione

dell’oggetto contenuto.

Contenitore

Contenuta

MetricSet

Metric

Figura 3.8.4: Contenimento

3.8.1 Analisi

Un diagramma delle classi, nella fase di analisi, rappresenta una vista concettuale

del problema catturando i concetti principali del dominio del problema svincolan-

doli da come essi saranno rappresentati dal software.

47


Metric

MetricSet

TestPlan

OdcAssessment

Algorithm

Regression

Algorithm

Fault

TestingTechni

que

descrive

presenta

prevede

Algorithm

Technique

utilizza

1..

151

1..

1

1

0..

1

1

1..

Figura 3.8.5: Diagramma delle classi: Scheduler48


3.8.2 Specifica e progetto

In un diagramma delle classi, nella fase di specifica e progetto, vengono introdotti

concetti legati al dominio della soluzione (indica quali saranno le interfacce del

sistema).

3.8.2.1 Pattern MVC

Un design pattern descrive una soluzione generale a un problema di progettazio-

ne ricorrente riconosciuta da tutta la comunità scientifica, gli attribuisce un nome,

astrae e identifica gli aspetti principali della struttura utilizzata per la soluzione

del problema, identifica le classi e le istanze partecipanti e la distribuzione delle

responsabilità, descrive quando e come può essere applicato.

Model-View-Controller (MVC, talvolta tradotto in italiano Modello-Vista-Controllo)

è un pattern architetturale molto diffuso nello sviluppo di interfacce grafiche di

sistemi software Object-Oriented.

Il pattern MVC è stato creato con l’intento di disaccoppiare:

• rappresentazione del modello di dominio (model) ;

• interfaccia utente (view), non necessariamente GUI;

• controllo dell’interazione uomo-macchina (controller).

Questo schema, fra l’altro, implica anche la tradizionale separazione fra la logica

applicativa (in questo contesto spesso chiamata "logica di business"), a carico del

controller e del model, e l’interfaccia utente a carico del view.

I dettagli delle interazioni fra questi tre oggetti software dipendono molto dalle

tecnologie usate (linguaggio di programmazione, eventuali librerie, middleware e

via dicendo) e dal tipo di applicazione (ad esempio se si tratta di un’applicazione

web o di un’applicazione desktop).

49


Quasi sempre la relazione fra view e model è descrivibile anche come istanza del

pattern Observer, quando è necessario cambiare il comportamento standard dell’ap-

plicazione, a seconda delle circostanze, il controller implementa anche il pattern

Strategy.

50


Control insertM

etrics()

estim

ateFault()

setEstimatedFault()

releasePlan()

updateFault()

Planner

View

Estim

ateFault

InsertFault

InsertM

etrics

ReleasePlan

Model

Metric

MetricSet

TestPlan

OdcAssessment

Algorithm

Regression

Algorithm

Fault

TestingTechni

que

descrive

presenta

prevede

Algorithm

Technique

utilizza

1..

151

1..

1

1

0..

1

1

1..

Figura 3.8.6: Diagramma delle classi vista progettuale: Scheduler

51


3.8.3 Progettazione di basso livello

In un diagramma delle classi, nella fase di implementazione, le classi e le relazioni

indicano la reale struttura del software.

Da UML a Java:

1. gli attributi si mappano nelle variabili membro della classe; la visibilità è

public, protected o private; al costruttore della classe è demandata l’inizializ-

zazione ai valori di default degli attributi;

2. ai metodi UML corrispondo funzioni membro; la visibilità è public, protected

o private;

3. generalizzazione-Specializzazione: extends;

4. le aggregazioni lasche sono mappate facendo sì che il contenitore abbia una

variabile membro privata di tipo riferimento ad un oggetto di tipo contenu-

to, il contenitore dovrà, inoltre, definire un costruttore che riceva in input il

riferimento all’oggetto contenuto;

5. le aggregazioni strette sono mappate facendo sì che il contenitore debba crea-

re, tramite proprio costruttore, anche il contenuto; il main program ha l’unica

responsabilità di creare l’oggetto contenitore fornendo valori di inizializza-

zione sia per esso che per il contenuto;

6. le relazioni di associazione si traducono con una o più variabili membro di

tipo puntatore alla classe associata (a seconda della molteplicità dell’asso-

ciazione); ogni classe definisce un costruttore che riceva un puntatore alla

classe associata oppure definisce una funzione membro la cui semantica sia

“CollegaPartner(ClassePartner* p).

52


Figura 3.8.7: Diagramma delle classi vista progettuale basso livello: Control

53


Figura 3.8.8: Diagramma delle classi vista progettuale basso livello: Model

54


Figura 3.8.9: Diagramma delle classi vista progettuale basso livello: Scheduler

55


3.8.4 Sequence Diagram

Un Sequence Diagram è un diagramma previsto dall’UML utilizzato per descrivere

uno scenario.

Uno scenario è una determinata sequenza di azioni in cui tutte le scelte sono state

già effettuate; in pratica nel diagramma non compaiono scelte, né flussi alternativi.

Normalmente da ogni Activity Diagram sono derivati uno o più Sequence Dia-

gram; se per esempio l’Activity Diagram descrive due flussi di azioni alternativi,

se ne potrebbero ricavare due scenari e, quindi, due Sequence Diagram alternativi.

Dalla versione 2 dell’UML è stata introdotta la possibilità di indicare nello stesso

diagramma anche delle sequenze alternative.

Il Sequence Diagram descrive le relazioni che intercorrono, in termini di messaggi,

tra Attori, Oggetti di business, Oggetti od Entità del sistema che si sta rappresen-

tando.

56


ControlUsers

insertMetrics()

OdcAssessment

estimate()

Return:numOfFaultsAssessment

TestPlan

releasePlan()

Return: plan

Return: plan

Figura 3.8.10: Sequence Diagram: rilascia piano

57


Figura 3.8.11: Sequence Diagram ad un più basso livello di astrazione: rilasciapiano

3.9 Codifica

Scrivere codice di qualità non è un’impresa difficile, ma richiede particolari tecniche

ormai consolidate, anche se molte di esse sono state “dimenticate” con il tempo. La

conoscenza approfondita dei vari linguaggi di programmazione è un primo prere-

quisito imprescindibile. L’esperienza maturata nell’utilizzo dei linguaggi adoperati

è un patrimonio di grande valore sia per le persone che per l’organizzazione stessa.

Un secondo elemento di qualità è l’utilizzo di standard di programmazione. Questi

sono un insieme di regole di comprovata utilità ed efficacia che garantiscono l’uni-

formità del codice scritto da persone e gruppi di persone diverse. Alcuni sono stan-

dard relativi ai singoli linguaggi di programmazione e la loro conoscenza è quindi

inclusa nelle competenze relative ai linguaggi stessi. Altri sono standard relativi

alla documentazione del codice. Essi definiscono cosa, come e quanto documentare

all’interno del codice stesso.

La documentazione del codice è importante perché fornisce le informazioni neces-

sarie per poter intervenire sul codice in momenti successivi alla sua prima scrittura.

58

Capitolo 4

Caso d’uso

4.1 Descrizione

Ora che si è in possesso della tecnica, dei modelli e sono stati descritti i passi da

seguire, non resta che applicare il tool ad un caso di studio sul quale verificare la

corretta esecuzione dello Scheduler.

La validazione del mio tool è stata condotta confrontando i risultati ottenuti tramite

una sessione di test svolta in maniera manuale basata su una metodologia descritta

in studi passati.

Sia la metodologia manuale che la metodologia supportata dal mio tool si basano

sui seguenti passi:

1. caratterizzazione del software sotto test attraverso metriche del software;

2. prelievo indici di attinenza Ai j guasto/tecnica di test;

3. stima iniziale dei guasti ODC;

4. calcolo Detectable fault per ogni tecnica;

5. calcolo della tecnica di Testing “migliore”;

6. ripetizione dei passi 4 e 5 ad ogni fault rilevato.

59


L’applicazione da utilizzare per le campagne di test è GREP v.4.

GREP (General Regular Expression Print) è un comando dei sistemi Unix e Unix-

like, che ricerca in uno o più file di testo le linee che corrispondono ad uno o più

modelli specificati con espressioni regolari o stringhe letterali e produce un elenco

delle linee (o anche dei soli nomi di file) per cui è stata trovata corrispondenza. E’

comunemente utilizzato per ricercare le occorrenze di una o più parole in una serie

di file. Può generalmente essere impiegato anche con file binari, per esempio per

ricercare la presenza di particolari etichette all’interno di immagini digitali.

Si tratta di un’applicazione scritta in C con un numero di linee di codice leggermente

inferiore alle 15K.

La sintassi generale di GREP è:

Figura 4.1.1: Sintassi GREP (http://it.wikipedia.org/wiki/Grep)

I parametri facoltativi file indicano i nomi dei file su cui effettuare la ricerca. Se non

specificati, la ricerca viene effettuata sui dati letti dallo standard input. Specificando

più di un parametro file, ogni linea per cui è stata trovata una corrispondenza viene

preceduta dal nome del file che la contiene e dal suo numero di linea; in caso di un

solo parametro file (o nessuno),invece, viene indicato solo il contenuto della linea

stessa.

I parametri modello specificano il criterio di ricerca ed il comportamento predefi-

nito prevede che si tratti di espressioni regolari. Una linea trova corrispondenza

se soddisfa almeno uno dei modelli. Il doppio trattino – (facoltativo) indica che i

parametri successivi non sono da considerarsi opzioni.

Tra le opzioni principali vi sono:

• -i: ignora le differenze tra lettere maiuscole e minuscole;

60



• -n: precede ogni linea dei risultati con il numero di linea all’interno del file

(partendo da 1);

• -l: indica solo i nomi dei file in cui è stata trovata almeno una corrisponden-

za (ciascun file è elencato una sola volta, indipendentemente dal numero di

corrispondenze in esso trovate);

• -v: nega i modelli specificati, producendo un elenco delle linee che non

soddisfano alcun modello;

• -E: i modelli sono espressioni regolari estese invece che espressioni regolari

di base;

• -F: i modelli sono stringhe che vanno ricercate in maniera letterale;

• -c: produce per ciascun file solo il conteggio del numero di linee che corri-

spondono.

4.2 Caratterizzazione del software sotto test

Il tester inserisce le metriche attraverso l’apposita finestra (Figura 3.2.1)

61


Figura 4.2.1: Finestra inserimento metriche

Queste vengono innanzitutto normalizzate:

xi =xi−mini{xi}

maxi{xi}−mini{xi}(4.2.1)

Le metriche inserite sono:

62


Cyclomatic complexity 0.63Count line code 6863

Number function 146Count line comment 3681

Halstead’s effort 11315355Count statement declaration 1071Count statement excutation 5058Count declaration file code 4

Max nesting 9Sum Essential 985

Halstead’s lenght 3509.1428Max Cyclomatic complexity 478

Halstead’s bug delevered 7.5859Ratio Comment to Code 0.54

Count path 1513533324

Tabella 4.1: Metriche GREP v.4

4.3 Stima dei guasti

I guasti vengono stimati mediante i seguenti modelli predittivi:

Tipo ODC ModelloAssignment Y = 47.4898∗PC1 +4.58152Checking Y =−109.564∗PC1 +146.201∗PC2 +118.724∗PC3 +56.4317∗PC4

−158.168∗PC5 +101.589∗PC6−40.3216Interface Y = 7.46967∗PC1 +14.0394∗PC2 +19.9983∗PC3 +12.1492∗PC4−1.68737

Algorithm Y = 39.6801∗PC1 +56.9135∗PC2 +57.4433∗PC3−13.3648Function Y = 11.5112∗PC1−7.39981∗PC2 +15.9779∗PC3−2.00

Tabella 4.2: Modelli predittivi

Il tester visualizzerà la seguente finestra:

63


Figura 4.3.1: Finestra stima dei guasti

4.4 Scelta della migliore tecnica di test

A partire dai guasti rilevati è possibile calcolare Ai, j indice di attinenza, che esprime

quanto una tecnica di testing i è capace di rilevare un guasto di tipo j ( j = 1 . . .5

rappresenta uno dei 5 tipi ODC).

Il calcolo di Ai, j è semplice:

Ai, j =Vi, j/100 (4.4.1)

dove Vi, j è la percentuale di fault di tipo j rilevati dalla tecnica i in applicazioni pas-

sate della stessa tecnica; questo calcolo è fatto una tantum alla prima applicazione

della strategia.

Dall’indice Ai j si può ottenere una stima del numero di guasti che una tecnica i

prevede di rilevare (i guasti potenzialmente rilevabili dalla tecnica i ); questo nuovo

indice è detto #DFaultsi (Detectable Faults) e si calcola come segue:

#DFaultsi(t) =5

∑j=1

#Fault j(t)∗Ai, j con i = 1 . . .N (4.4.2)

64


dove #Fault j è il numero di fault di tipo j previsti presenti nell’applicazione ad un

certo istante di tempo t, ed N è il numero di tecniche di test.

La scelta della tecnica ricade su quella che presenta il #DFaultsi maggiore, vale

a dire si sceglie la tecnica che potenzialmente all’istante di tempo t è in grado di

rilevare più errori. Il calcolo del #DFaultsi deve essere ripetuto ogni qualvolta si

rilevi un nuovo guasto.

Da esperimenti condotti in precedenza si deduce che l’indice Ai j ha i seguenti valori:

Tecnica % guasti rilevatiAi, j Assignment Checking Interface Algorithm Function

Funzionale 57.14% 25.00% 33.34% 25.00% 100.00%Statistico 60.21% 61.24% 58.33% 74.95% 65.71%

Stress 48.89% 73.53% 75.00% 58.73% 25.00%Robustezza 42.86% 50.00% 66.67% 25.00% 00.15%

Tabella 4.3: Capacità nel rilevare guasti ODC per ogni tecnica

Il tool rilascerà il seguente piano:

Figura 4.4.1: Finestra piano rilasciato

4.5 Inserimento guasti individuati

Individuati e corretti i guasti, essi vengono inseriti nel tool attraverso l’apposita

finestra:

65


Figura 4.5.1: Finestra inserimento guasti individuati

A questo punto il tool ricalcola il DFault e ripresenta il piano delle tecniche:

Figura 4.5.2: Finestra piano aggiornato

4.6 Risultati

Risultati ottenuti tramite una sessione di test svolta in maniera manuale alla prima

iterazione della strategia:

66


Assignment Checking Interface Algorithm FunctionN° guasti 29 10 16 52 4

Tabella 4.4: N° guasti alla prima iterazione della strategia manuale

da cui è stato calcolato il DFault per le tecniche di test Functional e Robustness:

DFaut Functional 41,405DFaut Robustness 41,0966

Tabella 4.5: DFault alla prima iterazione della strategia manuale

Risultati ottenuti tramite una sessione di test svolta in maniera automatica alla prima

iterazione del tool:

Assignment Checking Interface Algorithm FunctionN° guasti 28.3 9.4 14.6 52.7 4.3

Tabella 4.6: N° guasti alla prima iterazione del tool


DFaut Functional 40,09DFaut Robustness 39.7

Tabella 4.7: DFault alla prima iterazione del tool

I valori così calcolati ci suggeriscono di iniziare con la tecnica di test Functional.

Risultati ottenuti tramite la sessione di test svolta in maniera automatica dopo aver

trovato 8 guasti di tipo Assignment:

Assignment Checking Interface Algorithm FunctionN° guasti 20.3 9.4 14.6 52.7 4.3

Tabella 4.8: N° guasti test svolto in maniera automatica dopo aver trovato 8 guastidi tipo Assignment


DFaut Functional 36.02DFaut Robustness 36.4

Tabella 4.9: DFault test svolto in maniera automatica dopo aver trovato 8 guasti ditipo Assignment

67


A questo punto si verifica la condizione per la quale si effettua lo switch tra le due

tecniche: si passa ad eseguire i test case della campagna di Robustness Testing, ciò

risulta ancora più evidente visualizzando il grafico sotto riportato:

Figura 4.6.1: Grafico tecniche

68

Conclusioni e sviluppi futuri

Nel presente lavoro di tesi è stata presentata un tool a supporto dell’attività di testing

per sistemi software. In particolare con la strategia messa a punto si vuole fornire

un approccio alla pianificazione delle attività di testing per sistemi software.

Considerando, infatti, gli esperimenti condotti, un tester avendo a disposizione una

caratterizzazione del software in termini di software metrics, può scegliere la giu-

sta combinazione di tecniche di testing più propensa a rilevare il maggior numero

di guasti tra quelli stimati essere presenti nel software basandosi non unicamente

su conoscenze pregresse ma su una metodologia che riesce a creare un’obiettiva

correlazione tra guasti, test e tecniche di test.

69

Ringraziamenti

Desidero innanzitutto ringraziare il Professor S. Russo per i preziosi insegnamen-

ti impartitimi sia durante i corsi di studio sia durante gli incontri dedicatimi per

l’attività di tirocinio e per la stesura della tesi.

Inoltre, ringrazio sentitamente il Professor R. Pietrantuono che è stato sempre di-

sponibile a dirimere i miei dubbi durante la stesura di questo lavoro.

Infine, ho desiderio di ringraziare con affetto i miei genitori ed i miei fratelli per il

sostegno ed il grande aiuto che mi hanno dato.

70

Bibliografia

[1] P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone, Basi di dati - Modelli e linguaggi

di interrogazione, Milano

[2] A. Bononi, G. Ferrari, Teoria della probabilità e variabili aleatorie con

applicazioni, Parma, 2005

[3] R. Chillarege, I. S.Bhandari, J. K. Chaar, M. J.Halliday, D. S.Moebus, B. K.

Ray, M. Y. Wong, Orthogonal Defect Classification-A Concept for In-Process

Measurements, 1992

[4] D. Cotroneo, S. Russo, R. Pietrantuono, Choosing Testing techniques

according to software features

[5] D. Cotroneo, S. Russo, Dependability: concetti fondamentali, 2005

[6] D. Cotroneo, R. Pietrantuono, S. Russo, Testing techniques selection based on

ODC fault types and software metrics, 2012

[7] S. Daultrey, Principle components analysis, 1976

[8] G. Denaro, M. Pezze’, An Empirical Evaluation of Fault-Proneness Models,

in proc of the 24th International Conference on Software engineering, 2002.

[9] G. Denaro, S. Morasca, M. Pezzè, Deriving models of software faultproneness

[10] P. Erto, Probabilità e statistica per le scienze e l’ingegneria, 2008

72


[11] Ghezzi, Jazayeri, Mandrioli, Ingegneria del software; Fondamenti e principi

[12] S.S. Gokhale, M.R Lyu, Regression Tree Modeling for the Prediction of

Software Quality,in Proc. of the third ISSAT 1997

[13] L. Guo, Y. Mai, B. Cukic, H. Singht, Robust prediction of fault-proneness but

random forests

[14] A. M. J. Hass, Guide to advance software Testing, Francia, 2008

[15] Hetzel, William C., The Complete Guide to Software Testing 2nd ed. , 1988

[16] Ian Sommerville, Software Engineering 8th. ed., 2006

[17] N. Nagappan, T. Ball, A. Zeller, Mining Metrics to Predict Component Failu-

res, in the Proc. of the 28th international conference on Software engineering

(ICSE ’06), 2006

[18] K. Naik, P. Tripathy, Software testing and quality assurance - Theory and

practice

[19] M. Pezzè, M. Young, Software Testing and Analysis: Process, Principles and

Techniques, 2008

[20] R. Pietrantuono, Reliability-oriented verification of mission-critical software

systems

[21] R. S. Pressman, Principi di ingegneria del software, Milano, 2005

[22] L. V. Tagliati, UML e Ingegneria del Software - dalla teoria alla pratica, 2003

[23] S. Vegas, Identifying the Relevant Information for Software Testing Technique

Selection

[24] S. Vergas, V. Basili, A Characterization Schema for Software Testing

Techniques, 2005

73


[25] http://docs.oracle.com/javase/6/docs/api/

[26] http://it.wikipedia.org/wiki/Grep

[27] http://www.ee.ucl.ac.uk/~mflanaga/java/Regression.html

74

http://docs.oracle.com/javase/6/docs/api/


http://www.ee.ucl.ac.uk/~mflanaga/java/Regression.html

progettazione di un tool a supporto di un metodo per la selezione...

Documents