Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica
tesi di laurea
Valutazione sperimentale di tecniche di testing per software in relazione ai tipi di fault Anno Accademico 2008/2009 relatore Ch.mo prof. Stefano Russo correlatore Ing. Roberto Pietrantuono candidato Giuseppe Scafuti matr. 885/187
Alla mia Famiglia
Indice I PRESENTAZIONE DEL LAVORO Introduzione 5 II BACKGROUND Capitolo 1. Concetti preliminari 9 1.1 Tecniche di Testing 10 1.1.1 Functional Testing 11 1.1.2 Statistical Testing 11 1.1.3 Robustness Testing 12 1.1.4 Stress Testing 13 1.2 Ortogonal Defect CLassification 14 1.3 Design of Experiments 16 Capitolo 2. Fondamenti Matematici 18 2.1 Test d’ipotesi 18 2.2 Analisi della Varianza Univariata e Multivariata 21 2.3 Regressione Lineare 30 2.4 Regressione Stepwise 35 2.5 Analisi delle Variabili Canoniche 37 III ESPOSIZIONE DEL LAVORO Capitolo 3. Procedura Sperimentale ed Esecuzione degli Esperimenti 41 3.1 Indagine sugli Obiettivi 42 3.2 Generazione del piano degli esperimenti 43 3.3 Campagna di Fault Injection 46 3.4 Raccolta dei dati sperimentali 47 Capitolo 4. Analisi dei dati 48 4.1 Analisi Univariata sulla Efficienza della Detection 49 4.1.1 ANOVA e Correlazione 50 4.1.2 Modello Lineare di Regressione Multipla 54 4.2 Analisi Univariata sul Detection Rate 59 4.2.1 ANOVA e Correlazione 59 4.2.2 Modello Lineare di Regressione Multipla 65 4.3 Analisi Univariata sulla Efficienza della Detection per tipi di fault ODC 68 4.3.1 ANOVA e Correlazione 69 4.3.2 Modello Lineare di Regressione Multipla 71 4.3.3 Analisi dettagliata dell'Efficienza per tipo di fault ODC 79
4.4 Analisi Multivariata 82 4.4.1 Analisi delle Variabili Canoniche 84 4.5 Verifica delle Assunzioni 85 4.5.1 Analisi della Varianza Univariata e Mutivariata 85 4.5.2 Modello di Regressione Lineare Multipla 89 IV CONCLUSIONI Conclusioni 92 Appendice A 97 Bibliografia 98
Introduzione
Per sottolineare la delicatezza e l’importanza del testing nel processo di sviluppo software
Gerald Weinberg dichiarò:
“ If builders built buildings the way programmers wrote programs, the first woodpecker
that came along would destroy civilization”
Anche se molto forte, tale affermazione trova riscontro nei fatti. Basti pensare ai tanti
disastri avvenuti o sfiorati negli ultimi 50 anni a causa dei software fault. Ad esempio il
caso del Mariner I progettato dalla NASA per essere inviato su Venere ed esploso 293
secondi dopo il decollo. La causa dell'esplosione fu una formula scritta senza un apice.
Oppure il software per la radioterapia del National Cancer Institute che somministrava
dosi doppie di radiazioni. Tale bug provocò 8 vittime e 20 feriti gravi. Questa premessa
evidenzia come la fase di testing sia ancora una sfida aperta alla comunità scientifica.
La parola testing è legata al concetto di qualità, più precisamente si riferisce all’insieme di
attività che permette di assicurare la qualità del software. L’IEEE definisce il Testing di un
sistema software come un processo finalizzato a rilevare guasti e valutarne le
caratteristiche.
Nonostante i suoi limiti, il Testing è una fase fondamentale nel ciclo di sviluppo software.
Durante e dopo il processo di implementazione, il programma che si sta sviluppando deve
essere verificato per assicurarsi che sia conforme alle sue specifiche. Tale fase prende il
nome di Verifica software. In questa fase, gli sviluppatori mirano a rilevare il maggior
numero di guasti (fault) possibili, per produrre sistemi affidabili e ad alta qualità.
Attualmente non è possibile affermare che a valle del processo di sviluppo, nel software
non sono presenti fault. Di tali fault non è possibile prevederne l’attivazione, né tantomeno
le conseguenze nel caso in cui si attivino.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
6
Ciò dipende da diverse cause: i limiti delle tecniche di testing impiegate, i vincoli
temporali legati al time-to-market, la complessità dei sistemi odierni e la loro crescente
dimensione [7][8] rendono l’attività di verifica particolarmente complicata e poco
efficiente.
La selezione delle tecniche di testing da applicare al prodotto è una scelta fondamentale
dell’attività di verifica, e ne determina l’efficienza. E’ necessario che gli sviluppatori
abbiano una approfondita conoscenza delle possibili tecniche esistenti.
Una modalità per approfondire tale conoscenza è porre le tecniche a confronto: operare,
cioè, una comparazione, dal punto di vista teorico o empirico. La maggior parte degli studi
presenti in letteratura compara le tecniche di testing da un punto di vista prettamente
teorico. Il punto debole di tale approccio è l’applicabilità di questi criteri nel mondo reale.
Difatti in tali lavori sono fatte delle forti assunzioni difficilmente verificabili nella pratica.
Ci sono quindi pochi studi che comparano le tecniche di testing in sistema software reali.
Questo lavoro di tesi propone una comparazione empirica delle tecniche di testing su
sistemi software in scala reale. Lo scopo ultimo è quello di fornire dei criteri per
migliorare l’efficienza del processo di testing.
Il lavoro è stato articolato in due fasi: Progettazione degli esperimenti ed Analisi dei dati
raccolti.
La prima problematica affrontata ha riguardato la selezione di criteri di valutazione su cui
comparare le tecniche e dei fattori che potessero potenzialmente influenzare l’efficienza
del testing. Tale scelta è stata eseguita cercando di riprodurre le più comuni condizioni in
cui si esegue il testing, con l'obiettivo di individuare le cause che influiscono su tale fase. I
criteri su cui è stata effettuata la valutazione sono stati: Efficienza (misurata con
Percentuale di fault rilevati sul totale dei fault presenti), Costo (Numero di fault rilevati
per ora) e Comportamento delle tecniche di testing per tipi di fault (Percentuale di fault
rilevati per tipo).
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
7
I fattori individuati sono stati: la specifica Tecnica di Testing adottata, , la Tipologia di
Software in esame, la Quantità di Fault inizialmente presenti nel sistema, e 5 variabili che
rappresentano i tipi di fault generalmente presenti nei software.
Successivamente, sulla base di tali fattori, è stato prodotto ed eseguito un piano degli
esperimenti, con filosofia Design of Experiments. Al fine di non rendere elevato il numero
degli esperimenti e poco significativi i dati raccolti, per i primi tre fattori è stato necessario
fissare le seguenti restrizioni. Le tecniche di testing su cui è stata focalizzata l’indagine
sono: Statistical, Stress, Robustness e Functional Testing. Le tipologie di software scelte
si riferiscono ad ampi e diffusi Target applicativi: Web Service, DBMS e Protocollo di
rete. Come rappresentativo di ognuno di essi sono stati rispettivamente assunti: Apache,
MySQL e Samba. Infine per Quantità di Fault si è inteso il numero totale di fault presenti
nel software (Alto, Medio e Basso).
Al fine di valutare l’efficacia della detection è stato necessario conoscere a priori il
numero di fault presenti nel software, oltre che il numero di fault rilevati. Quindi i test
sono stati condotti su versioni di software precedentemente sottoposti a una campagna di
fault injection.
A valle degli esperimenti, il secondo step è stato l'analisi dei dati raccolti, mediante
tecniche statistiche. I risultati ottenuti hanno evidenziato come l'efficienza del testing sia
principalmente funzione delle Tecniche di Testing, e come l’efficienza delle varie tecniche
sia legata al tipo di fault contenuti nel software.
In particolare, tra le varie considerazioni fatte a valle degli esperimenti (capitolo 4), si è
potuta osservar una sostanziale equivalenza tra l’efficacia prodotta dal Functional e quella
prodotta dallo Statistical Testing. Sul costo si è invece notata l’influenza della quantità di
fault inizialmente presenti nel Software. Il Detection Rate delle varie tecniche ha mostrato
risultati simili. Un buon trade-off tra i due aspetti analizzati è stato riscontrato
nell’utilizzo dello Statistical Testing. Si è infine osservato che le tecniche di testing
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
8
“dimostrative” (Functional e Statistical testing) e quelle “distruttive” (Stress e Robustness
testing) hanno come target della detection tipi di fault tra di loro ortogonali. Ciò giustifica
anche il diverso livello di efficienza e costo. Inoltre si sottolinea come un utilizzo
congiunto delle tecniche Statistical e Stress Testing permette di avere risultati buoni per
ogni classe di fault con costo contenuto.
I risultati del presente lavoro forniscono delle utili indicazioni quantitative per coloro i
quali sono addetti a pianificare l’attività di verifica dei sistemi software. La comparazione
presentata facilita infatti la selezione di una o più tecniche per il sistema da testare,
basando la scelta su risultati empirici e criteri oggettivi, piuttosto che sulla base della
propria esperienza o intuizione.
Capitolo 1
Concetti preliminari
Lo scopo di questo capitolo è quello di fornire le basi teoriche necessarie per la
progettazione degli esperimenti. In particolare il primo paragrafo si concentra sulla
esposizione delle tecniche di testing selezionate per l'indagine. In tale sezione è fornita una
overview di tali tecniche che cerca di evidenziarne pregi e difetti. Inoltre, volendo
effettuare una valutazione sperimentale di tecniche di testing, in relazione ai tipi di fault, è
stato necessario individuare una classificazione dei Fault. La classificazione scelta è stata
l'Ortogonal Defect Classification (ODC). Tale classificazione è ampiamente usata in
letteratura ed è funzionale al nostro scopo.
La progettazione degli esperimenti è stata condotta con filosofia Design of Experiments
(DoE). Tale metodologia fornisce dei criteri per la minimizzazione degli esperimenti con
l'obiettivo di non perdere il contenuto informativo della sperimentazione. Per poter meglio
comprendere il contenuto di questo capitolo è utile in tale fase fornire la seguente
terminologia [12]:
• Fault [or Defect]: un fault è uno stato improprio dell’hardware e/o del software
derivante da un componente non funzionante, da fenomeni di interferenza o da
errori di progettazione.
• Error : Un Error è la parte dello stato di un sistema che può indurre lo stesso al
fallimento ovvero a fornire un servizio non conforme alle specifiche (unproper
service). La causa di un errore è un fault. E’ possibile che un fault generi più di un
errore all’interno del sistema (multiple related error).
• Failure: Un failure è definito come l’evento in corrispondenza del quale il sistema
cessa di fornire il servizio corretto.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
10
Figura. Catena dei fault
Nei successivi paragrafi verranno approfonditi i concetti accennati in questa prima analisi.
1.1 Tecniche di Testing
In letteratura sono elencati diversi metodi e tecniche per eseguire il testing che permettono
di raggiungere obiettivi in differenti fasi del ciclo di vita del Software. E' possibile
classificare le tecniche di testing in base allo scope: Unit Testing, Component Testing,
Integration Testing e System Testing. Oppure in base agli obiettivi: Correctness Testing,
Performance Testing, Reliability Testing e Security Testing.
Essendo interessati a tecniche di testing che permettono di migliorare l'affidabilità del
sistema, per la comparazione sono state scelte le tecniche più adoperate a tale scopo:
Statistical, Stress e Robustness Testing.
A queste tre tecniche ne è stata affiancata una quarta: il Functional Testing, anch’essa
ampiamente adoperata in qualsiasi classe di sistemi. Tale scelta è stata fatta perchè lo
Statistical Testing viene generato dallo stesso operational profile utilizzato per il
Functional Testing. Insomma lo Statistical Testing può essere considerato come una
euristica basata sul Functional. Quindi risulta interessante verificare quali differenze si
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
11
evidenziano tra le due tecniche. Nei successivi paragrafi saranno esposti i concetti chiave
delle quattro tecniche.
1.1.1 Functional Testing
Il Functional Testing è una tecnica di Correctness Testing. Lo scopo principale è
verificare che il prodotto finale soddisfi le specifiche di progetto. Per effettuare tale
verifica i risultati forniti dal testing vengono confrontati con il cosiddetto Oracolo.
L'Oracolo è l'insieme dei risultati che ci si aspetta dai test affinché le funzionalità del
prodotto siano coerenti con le specifiche. Il Functional Testing è detto anche Black-Box.
L'approccio Black-Box prevede che i test case siano derivati direttamente dai requisiti
funzionali, senza considerare la struttura del programma finale [Perry90]. Il tester tratta il
software come una scatola nera (black-box) in cui sono visibili soltanto : Input, Output e
specifiche. Quindi vengono applicati una serie di Input e il tester osservando gli output e
l'oracolo determina se il comportamento del software è coerente con le specifiche. Non è
realistico che si testino tutte le possibili combinazioni di input. Quindi, il problema
principale sta nell'individuare il numero e l'insieme degli input necessario per poter
affermare che il test si è concluso. Sono state proposte varie soluzioni tra cui il Domain
Testing [15]. Il Domain Testing partiziona il dominio degli input in regioni, e considera i
valori interni ad ogni dominio appartenenti ad una classe di equivalenza. Quindi vengono
selezionati e testati un valore rappresentativo per ogni Dominio. In questo modo viene
coperto tutto l’input space. Il problema nell’applicare questa tecnica è la difficoltà di
definire correttamente i domini [15].
1.1.2 Statistical Testing
Lo Statistical Testing è una tecnica di Reliability Testing. In generale la Software
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
12
Reliability si riferisce alla probabilità di fallimento del sistema. Essa è relazionata a molti
aspetti del software, tra cui il Testing. In particolare il testing è un efficace metodo di
campionamento per misurare la Reliability.[5]
Lo Statistical Testing prevede la generazione di casi test secondo la filosofia black-box del
Functional Testing. Tale tecnica prevede due fasi: stima del profilo operazionale
(suddivisione in classi delle funzionalità ) e selezione dei casi test. La prima fase si
realizza raggruppando i casi test in classi, seguendo un criterio scelto a priori come la
tipologia delle funzionalità del prodotto. Ad ogni classe di test viene associata un
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 selezione dei casi test viene realizzata scegliendo gli input in maniera casuale, secondo
la distribuzione associata alle varie classi, che permettono di individuare la classe e il test
da eseguire. I risultati ottenuti dai casi test vengono confrontati con un oracolo, così come
avviene anche per il Functional Testing.
Questa tecnica di testing può essere interpretata come una euristica basata sui casi test del
Functional Testing. Tale considerazione rende interessante verificarne il comportamento
in relazione al Functional Testing.
1.1.3 Robustness Testing
In generale un sistema, un organismo o un progetto può essere definito “robusto” se
capace di reagire bene a variazioni (talvolta non predicibili) dell'ambiente operativo con
minimo danno, alterazione e perdita di funzionalità. Una definizione più precisa è data
dall'IEEE: per robustezza del sistema s'intende il livello in cui esso funziona correttamente
in presenza di input eccezionali o carico di lavoro eccessivo [IEEE1990]. Quindi il testing
oltre a valutare se il sistema soddisfa le specifiche deve assicurare che gestisca in maniera
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
13
opportuna anche comportamenti anomali. Il Robustness Testing per i normali PC non è
strettamente necessario, risulta invece fondamentale in sistemi critici (mission-critical).
Esistono varie tipologie di Robustness Testing. Molte sono equivalenti ed altre invece
definiscono un diverso tipo di test di robustezza. Le più conosciute sono: Boundary value
analysis/testing, Security testing, Recovery testing, Negative testing etc. La prima tecnica è
focalizzata sull'individuazione dei corner case, ossia la verifica del comportamento del
sistema per valori al di fuori o agli estremi del range definito dalle specifiche. Il security
testing verifica che non ci siano accessi non autorizzati al sistema e alle sue funzionalità.
Invece il Recovery Testing esamina il corretto funzionamento delle procedure di recovery
nel caso di fallimento del sistema. Il Negative testing punta a dimostrare dove il software
non funziona correttamente [Beizer 90]. In realtà il Robustness testing nella sua accezione
più ampia è un ibrido tra le varie tecniche elencate. Gli obiettivi principali si possono
riassumere nei seguenti punti:
Come per le precedenti tecniche i risultati ottenuti sono confrontati con un Oracolo.
Verifica delle funzionalità di error-handling(es., messaging, logging, monitoring)
Verifica delle funzionalità di recovery(es., fail-over, rollback, and restoration)
Osservazione e misura delle risposte del sistema a problemi esterni
Validazione ed esclusione di informazioni ricevute in input e già presenti nel sistema.
1.1.4 Stress Testing
Lo Stress testing ha diversi significati in funzione dell'ambito in cui è applicato. Per il
settore finanziario s'intende: l'insieme di strumenti che permette di individuare la
“migliore stima” di ciò che accadrà all'investimento se si verificano particolari condizioni
sfavorevoli. Nell'ambito medico aiuta a capire le cause del quadro clinico del paziente.
Mentre nel settore IT lo stress testing significa testare il software/hardware in particolari
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
14
condizioni come: elevato traffico di rete, massima utilizzazione delle risorse del sistema,
elevato numero di richieste di utilizzo di funzionalità etc. In altre parole, lo stress testing
permette di individuare il limite in cui il sistema sottoposto ad un heavy-workload presenta
ancora soddisfacenti livelli di consistenza, robustezza e performance[5]. Lo stress testing è
ritenuto importante in quanto:
Quasi il 90% del software/sistemi sono sviluppati con l'assunzione che essi saranno messi
in esercizio in uno scenario “normale”. Anche se si ritiene che il limite delle normali
condizioni di funzionamento sia attraversato tale previsione è sempre contenuta.
Il costo o l'effetto di un importante (o critico) fallimento di un sistema real time, in
condizioni di funzionamento estreme, può essere enorme (o può essere catastrofico per
l'organizzazione o l'entità possessore del software/sistema).
È sempre meglio essere preparati per condizioni estreme, piuttosto che lasciare che il
sistema vada in crash quando il limite di funzionamento normale è attraversato.
Prove eseguite dallo sviluppatore del sistema possono non essere sufficienti per aiutare a
svelare le condizioni che porteranno al crash quando viene messo in esercizio.
Anche per lo stress testing i risultati sono confrontati con un oracolo. Il criterio definito
dall'oracolo è molto semplice: se il sistema fallisce il test ha avuto successo.
1.2 Orthogonal Defect Classification (ODC)
I software defect sono causati da una varietà di ragioni che possono richiedere elaborate
descrizioni per spiegarne la natura [2]. Tra i più complessi ci sono errori causati da
specifiche ambigue, che potrebbero portare alla modifica di porzioni di codice che invece
sono corrette. L'dea alla base della classificazione ODC è quello di evitare descrizioni di
defect che potrebbero essere ambigue e prolisse. Per raggiungere tale scopo ODC prevede
un insieme di classi di defect tra di loro ortogonali, in maniera tale da poter raggruppare ed
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
15
isolare i defect [1]. Il procedimento di classificazione non è in realtà molto lontano da ciò
che fa un programmatore durante il debugging. Ad esempio un programmatore nel
momento in cui effettua una correzione implicitamente sceglie la classe di defect, in
quanto la tipologia di defect determina le azioni da effettuare per rimuoverlo. Sulla base di
queste osservazioni sono state definite le seguenti classi ortogonali di defect [1]:
• Assignment indica alcune linee di codice in cui è stata omessa o non effettuata
correttamente l'assegnazione dei valori a variabili o strutture dati complesse.
• Interface denota errori nella gestione delle interazioni tra moduli, componenti, liste
di parametri non corrette etc.
• Checking raggruppa le gestioni non corrette di condizioni logiche, test sui bit o su
range di valori etc
• Build/Package/Merge descrivono errori che si verificano a causa di problemi nelle
system library, gestione dei componenti etc.
• Documentation Error indicano errori presenti sulla documentazione e note per la
manutenzione
• Algorithm, fault che includono problemi di correttezza ed efficienza che hanno
effetto sui vari task e possono essere corretti reimplementando il codice o strutture
dati locali, senza richiedere cambiamenti della fase di progetto.
• Function, fault che interessano caratteristiche significative del software: end-user
interface, interfacce tra le architetture o strutture dati globali che richiedono
cambiamenti formali di progettazione.
La caratterizzazione dei fault è uno passo fondamentale nella definizione di una
metodologia per la loro emulazione. Necessaria per la loro classificazione è la definizione
di correttezza del software. Una definizione ampiamente condivisa in letteratura è: la
software correctness è la misura delle necessità degli end/customer user. [IEEE90]. Per gli
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
16
scopi del lavoro effettuato è stato assunto che i requisiti e le specifiche sono corrette. Ciò
implica che i fault presenti interessano solo parti di codice non corrette (es. non vengono
implementate delle funzionalità richieste nelle specifiche). In particolare si assume che: i
software fault che si vogliono emulare mediante fault injection sono fault originati durante
la coding phase e che non sono stati rilevati durante le procedure di testing. Quindi i fault
type ODC che verranno utilizzati in questo contesto sono i seguenti: Assignement,
Checking, Interface, Algorithm, Function. In tabella è riportata la distribuzione
percentuale dei fault classificati secondo lo schema ODC, più comunemente osservata nei
sistemi software, analizzata da diversi studi in letteratura [Maderia]
ODC Class defect Percentuale Assignment 21,40% Checking 25,00% Interface 7,30%
Algorithm 40,10% Function 6,10%
Tabella 1.1
1.3 Design of Experiments (DoE)
Il DoE gioca un ruolo essenziale nelle attività di progetto, quando si sviluppano nuovi
prodotti o si migliorano quelli esistenti. Alcune applicazione del DoE comprendono:
• la valutazione e il confronto di configurazioni di progetto
• la valutazione di alternative sui materiali
• la determinazione dei parametri chiave in quanto ad influenza sulle prestazioni.
Il DOE offre strumenti di programmazione ed interpretazione delle prove in grado di
valutare l’attendibilità e la generalità (in altri termini: l’oggettività) dei risultati conseguiti
[11]. Molti fattori minano l’attendibilità delle prove sperimentali:
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
17
• la scelta di una risposta che sia significativa del problema;
• gli errori di misura;
• gli errori “intrinseci” nella ripetibilità delle condizioni di prova;
la scelta delle variabili da investigare (il numero, le interazioni, la complessità nel
gestirle).
Per garantire l’oggettività dell’analisi sono necessari una buona conoscenza del problema
che consenta di definire la risposta più opportuna, valutare le variabili essenziali
all’indagine e le possibili sorgenti di disturbo. Da queste considerazione scaturisce la
scelta del piano più opportuno. Ogni piano deve essere condotto in osservanza delle regole
di casualizzazione delle prove, replicazione e raggruppamento (blocking) [11].
• Casualizzazione: l’ordine di esecuzione casuale consente una distribuzione degli
errori di tipo normale (ipotesi iniziale di molte elaborazioni dei risultati). Non
permette intromissione di disturbi legati alla sequenza temporale delle prove. Evita
quindi che prove a trattamenti simili siano “derivate” una dall’altra perché ad ogni
test si ri-azzera il set up della prova.
• Replicazione: ogni condizione di prova deve essere ripetuta più volte per consentire
la stima dell’errore insito nella risposta. Se si replica in successione (senza
casualizzare) ogni volta occorre re-inizializzare i livelli dei fattori in esame (per
non andare contro a quanto detto per la casualizzazione). Replicare in questo senso
non è ripetere la misura più volte, bensì eseguire più volte l’esperimento al fine di
abbattere l’errore sperimentale.
• Raggruppamento (blocking): molti studi si prefiggono di trovare i fattori
predominanti di un fenomeno, tuttavia la provenienza dei campioni di prova può
introdurre un errore di variabilità aggiuntivo; in questi casi si ricorre al blocking
delle prove. Ogni blocco si realizza con elementi provenienti dallo stesso batch.
Capitolo 2
Fondamenti Matematici
L'inferenza statistica è il procedimento per cui si deducono le caratteristiche di una
popolazione dall'osservazione di una parte di essa (detta campione) selezionata
solitamente mediante un esperimento casuale (aleatorio). Da un punto di vista concettuale
si tratta di tecniche matematiche per quantificare il processo di apprendimento tramite
l'esperienza. In particolare in questa sezione saranno esposti i fondamenti matematici e
concettuali necessari nell’ambito del Design of Experiment.
2.1 Test d'Ipotesi
La statistica inferenziale non si pone solo l'obiettivo di comprendere le caratteristiche di una
popolazione a partire dai dati raccolti su un campione rappresentativo, bensì anche di
verificare ipotesi fatte a priori su alcuni aspetti di interesse. l test d'ipotesi permettono di
raggiungere conclusioni su base probabilistica. Il procedimento é il seguente[4]:
a. Si formula l'ipotesi nulla (corrispondente ad affermare che non vi é effetto) e
l'ipotesi alternativa;
b. Si calcola la probabilità che l'ipotesi nulla sia vera;
c. Se il livello di probabilità é inferiore ad una certa soglia α prefissata
(generalmente 0.05), si rifiuta l'ipotesi nulla e si accetta l'ipotesi alternativa.
Tra le varie ipotesi che è possibile formulare, spesso si è interessati a verificare se le
differenze tra medie di p>2 gruppi sono o meno statisticamente significative. Si potrebbe
ricorrere al test t di Student e ripetere l’analisi tante volte quanti sono i possibili confronti
a coppie tra i trattamenti.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
19
Questo approccio, però, non garantisce un adeguato livello di protezione del test. La
probabilità di commettere un errore di Tipo I, cioè la probabilità α di trovare una
differenza significativa quando in realtà essa non esiste, è corretta per il singolo confronto
tra due medie.
Questo tasso d’errore, chiamato comparison-wise, all’aumentare del numero di confronti
determina un tasso d’errore per tutto l’esperimento, chiamato experiment-wise (o family-
wise), notevolmente maggiore. Se si effettua un singolo test t di Student tra due medie
con α = 0.05, tale confronto (comparison-wise) ha una probabilità di 0.95 di affermare il
vero e una probabilità p = 0.05 di commettere un errore di Tipo I. Se vengono effettuate N
ripetizioni del test t di Student, la probabilità di r = 0 errori di Tipo I sarà [9]:
Nel caso di N confronti tra coppie di medie, dunque, la probabilità di 0 errori di Tipo I è
uguale a
Si denota con
– α la probabilità d’errore di Tipo I del singolo test (comparison-wise),
– αT la probabilità d’errore di Tipo I per tutto l’esperimento (experiment-wise).
In generale, per N confronti indipendenti, la probabilità d’errore complessiva (experiment-
wise) è:
Nei confronti multipli è dunque necessario ricorrere a delle procedure che garantiscano un
adeguato livello di protezione nei confronti dell’errore di Tipo I.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
20
Esistono due soluzioni:
contrasti ortogonali: consentono un numero limitato di confronti che devono essere scelti
a priori
confronti post hoc: si usano quando i confronti tra trattamenti vengono decisi a posteriori,
sulla base dei risultati dell’esperimento.
Vari metodi possono essere utilizzati per controllare il livello di protezione complessivo
(experiment-wise) del test per i confronti post-hoc:
• Se nel piano sperimentale è inserito un trattamento che funge da controllo, il test
consente di confrontare separatamente ogni trattamento con il controllo.
• Permette di effettuare un numero qualsiasi di confronti tra coppie di trattamenti. La
differenza tra due medie è dichiarata significativa se Yi − Yj è maggiore di un
valore critico (Honest Significant Difference, HSD) che si ricava da opportune
tavole.
• Test di Sheffè - Permette confronti tra medie anche complessi. Mentre i test di
Dunnett e Tukey consentono solo di eseguire dei confronti a coppie tra medie, il
test di Scheffè può essere formulato nei termini di combinazioni lineari delle medie
della popolazione. Se vi è un gruppo di controllo e due trattamenti sperimentali
diversi, per esempio, è possibile eseguire un test sull’eguaglianza della media della
condizione di controllo e della media delle medie delle condizioni sperimentali.
• Il test di Bonferroni - consiste nell’usare il t test per confrontare due trattamenti
modificando il livello di protezione (1 − α) di ogni singolo confronto, in modo da
garantire il livello di protezione complessivo desiderato. Tale test a differenza
degli altri è molto conservativo.
• F-test - è un test per verificare l’uguaglianza delle varianze di due popolazioni
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
21
(ipotesi nulla). Indicando con S21 e S2
2 le stime campionarie delle varianze delle
due popolazioni(n ed m dimensioni delle popolazioni ) σ21 σ
22, si può utilizzare
la funzione ancillare:
La quale è una v.a. Z di Fisher con n-1 ed m-1 gradi di libertà e seguendo una
procedura simile a quella utilizzata per determinare l’intervallo di confidenza è
possibile stabilire se rifiutare o meno l’ipotesi nulla.
Test t di Student - viene impiegato per verificare delle affermazioni fatte sul valore medio
assunto da una variabile nell'itera popolazione di riferimento dello studio. Il ricercatore
dovrà formulare delle congetture nei confronti del vero valore assunto dalla media
aritmetica di una variabile aleatoria. Ad esempio può essere assunta come ipotesi nulla che
le differenze tra medie sono statisticamente non significative. Applicando il test del
rapporto di verosomiglianza si arriva alla statistica conosciuta come test t di Student
ricavando.
2.2 Analisi della Varianza Univariata e Multivariat a
L’analisi della varianza (ANOVA) è una tecnica statistica nata nell’ambito della ricerca
sperimentale, per valutare l’effetto di determinati fattori/variabili indipendenti ( di tipo
continuo o categorico ), sulla variabile/fattore dipendente ( di tipo continuo ). Essa
rappresenta un test di ipotesi, ossia permette di verificare se è possibile accettare o meno
che le medie tra due o più gruppi siano uguali. Tale test viene effettuato sotto l’assunzione
che le popolazioni campionate siano normalmente distribuite e che vi sia omogeneità delle
21
12S
Sσ
σ
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
22
varianze nelle varie condizioni sperimentali. L’analisi della varianza assume nomi diversi
a seconda di quante sono le variabili dipendenti e indipendenti:
• ANOVA a una via , quando si ha una sola variabile dipendente e una sola variabile
indipendente;
• ANOVA a due vie, quando si ha una sola variabile dipendente, e due variabili
indipendenti;
• MANOVA ( Multivariate Analysis of Variance ), quando ci son più variabili
dipendenti e più variabili indipendenti;
ANOVA a una via
Come mostrato in [4] esaminiamo i risultati, riportati in tabella, di un piano sperimentale
predisposto per un’analisi a una via, ossia finalizzata allo studio di un solo fattore a n
livelli disponendo di m osservazioni sperimentali per ciascun livello.
Livello del Fattore Osservazioni Media
1 x11 x12 ... x1m 1x
2 x21 x22 ... x2m 2x
i … xij … ∑=
=m
j
iji m
xx
1
n xn1 xn2 … xnm nx
111
>>=∑ =mnnxx
n
i i
Tabella 2.2.1
Per isolare l’aliquota della varianza globale imputabile al fattore in esame, consideriamo la
seguente identità:
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
23
∑e
∑∑∑∑∑== == =
−+−=−n
ii
n
i
m
jiij
n
i
m
jij xxmxxxx
1
2
1 1
2
1 1
2 )()()(
(2.2.1)
∑∑∑ +=fet
m
che esprime il fatto che la somma dei quadrati degli nm× scarti rispetto alla media
globale ( , detta devianza totale ) è ripartibile in due aliquote s-indipendenti costituite
rispettivamente dalla somma delle nm× differenze quadratiche rispetto alle medie
parziali ( ,detta devianza residua), e da m volte la somma delle differenze quadratiche
delle n medie parziali rispetto a quella globale ( , detta devianza spiegata ).
All’equazione (2.2.1) corrisponde, se il fattore in esame ha effetti significativi, il seguente
modello interpretativo della v.a. xij :
ijiijx εαµ ++= ;,....,1;,....,1 mjni == (2.2.2)
Essendo:
• µ , la costante E[x] “ valore medio globale ”, ossia il valore che caratterizza la
situazione sperimentale in cui sono state effettuate le osservazioni. Esso è il
risultato che si avrebbe, in assenza di errori e/o fluttuazioni sperimentali, se tutti i
trattamenti fossero uguali;
• iα , la costante ][ µ−ixE ”effetto imputabile al fattore in esame al livello i-esimo”;
• jiε , la v.a. “errore sperimentale”, relativo all’osservazione j-esima in
corrispondenza del trattamento i-esimo, con 2][,0][ σεε == jiji VarE .
In quanto “errori” sperimentali è del tutto plausibile supporre che le variabili aleatorie
jiε siano distribuite secondo Gaussiane s-indipendenti di media nulla e varianza 2σ .
Notiamo che necessariamente deve essere ∑=
=n
ii
1
0α , infatti:
}{}21
{}{111
µµµα −=−=−= ∑∑∑===
xnExnExEn
ii
n
ii
n
ii (2.2.3)
∑t
∑ fm
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
24
Nella (2.2.3) la somma iαµ + può essere interpretata come media iµ del gruppo (o classe)
di osservazioni corrispondenti al livello i-esimo del fattore in esame. Per cui l’analisi della
varianza, dal punto di vista concettuale, risulta essere l’estensione del test di Student
[§2.1] per verificare se esiste o meno una differenza significativa tra più di due medie iµ
corrispondenti a n popolazioni Gaussiane con uguale varianza.
Tuttavia, operativamente, il test utilizzato non è quello di Student, bensì quello di Fisher.
Verificare l’efficacia del fattore in esame significa sottoporre a test l’ipotesi nulla
},....,1,0{0 nii ===Η α , ossia l’effetto imputabile al fattore in esame non influisce
sulla variabile dipendente.
Ma se vera H0, la varianza di xij si riduce a quella dell’errore la varianza di ∑=
=m
j
iji m
xx
1
(media del gruppo i-esimo) diventa pari a m
2σ. Pertanto le devianze residua e spiegata,
divise per i corrispondenti gradi di libertà, cioè )]1([ −
∑
mne e
)1( −
∑
n
mf , risultano entrambe
stime corrette della varianza, 2σ . Si ricorda che i gradi di libertà corrispondono al numero di dati utilizzati che risultano algebricamente indipendenti. Quindi, essendo s-indipendenti, il loro rapporto :
)]1([
)1(
*−
−=∑
∑
nm
nm
Z
e
f
Costituisce, per definizione, una v.a. Z di Fischer con n-1 e n(m-1) gradi di libertà, di solito
indicata con Z* .
Quindi H0 è rigettata se al valore osservato:
)]1([
)1(
*−
−=∑
∑
nm
nm
z
e
f
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
25
è associata una coda di probabilità che esprime il p-value:
}Pr{*}Pr{ )1(),1( ℑ=<>−− αzZ mnn
essendo α la probabilità che definisce la zona di rigetto ℑ . Infatti se la varianza imputabile
al fattore in esame è significativamente più grande della varianza dell’errore sperimentale,
dobbiamo ritenere che ciò che abbiamo osservato è verosimilmente una conseguenza di una
realtà non conforme ad H0, ossia che la varianza delle ix è ben maggiore del valore m2σ
che avrebbero avuto se le xij avessero avuto varianza pari a 2σ ( perché funzioni solo diµ e
jiε , e non di iα ).
La tabella precedente sintetizza tutte le considerazioni fatte fin’ora, fornendo un’ulteriore
interpretazione della ripartizione (interclassi ed intraclassi) della varianza contenuta
nell’equazione (2.2.1). I gradi di libertà sono conteggiati sottraendo al numero di
determinazioni sperimentali utilizzate, il numero di equazioni linearmente indipendenti che
le legano.
Per esempio la somma degli scarti imputabili all’errore sperimentale utilizza mn× dati, che
però sono legati dalle n equazioni ∑=
=m
j
iji m
xx
1
, per cui i suoi gradi di libertà sono
effettivamente )1( −=−× mnnmn .
Orig. Della Varianza
Devianza Gradi di Libertà
Varianza S2
Valore Atteso di S2, E{S2}
Fattore Principale
∑=
−n
ii xxm
1
2)( 1−n )1( −
∑
n
mf ∑
=−+
n
iin
m
1
22
)1(ασ
Errore ∑∑= =
−n
i
m
jiij xx
1 1
2)( )1( −nm mn
e
)1( −∑ 2σ
Totale ∑∑= =
−n
i
m
jij xx
1 1
2)( 1−nm )1( −
∑nm
t
Tabella 2.2.2 ANOVA a una via
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
26
Dalla Tabella 2.2.2 si deduce che la varianza )]1([ −
∑
mne è sempre uno stimatore corretto di
2σ , mentre )1( −
∑
n
mf lo è solo se il fattore non ha effetto significativo ( e quindi H0 è vera).
Viceversa se il fattore è significativo, la varianza )1( −
∑
n
mf tende a sovrastimare il valore di 2σ
per cui ci aspettiamo, in questo caso, un valore del rapporto:
)]1([
)1(
*−
−=∑
∑
nm
nm
z
e
f
significativamente maggiore dell’unità. Da ciò scaturisce la logica del precedente test
d’ipotesi (a una coda) su cui è fondata l’analisi della varianza.
Per valutare la coda di probabilità di *}Pr{ zZ > , ossia il p-value, conviene adoperare le
routine presenti in molti tool per statistica oppure consultare i valori tabellati.
ANOVA a due vie
Spesso, oltre al fattore principale da studiare, esiste anche un altro fattore di cui è necessario
isolare l’effetto. Ciò può anche capitare perché si desidera stimare l’effetto dei blocchi
sperimentali, non confondendolo più con l’errore sperimentale. Conseguentemente, è
necessario analizzarlo nella stessa maniera utilizzata per analizzare l’effetto del fattore
principale.
B1 … Bj … Bb Media T1 x11 … x1j … x1b •1x
… Ti xi1 … xij … xib •ix
… Tn xn1 … xnj … xnb •nx
Media 1•x jx• bx• x
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
27
∑=
• =b
jiji bxx
1
; ∑=
• =n
iijj nxx
1
; ∑∑=
•=
• ==b
jj
n
ii bxnxx
11
Tabella 2.2.3
In questo caso la classificazione a due vie di un piano sperimentale del tipo di quello
rappresentato in tabella, deve trovare riscontro anche nel modello di analisi della v.a. xij :
ijjiijx εβαµ +++= ; ;,....,1;,....,1 mjni ==
In cui alle componenti del modello di ANOVA a una via, si aggiunge jβ , l’effetto
imputabile al secondo fattore in esame al livello j-esimo, essendo }{ µβ −= • jj xE . Segue
che 01
=∑=
b
jjβ , come già per le iα .
I dati sono raccolti come in tabella, e per isolare la nuova aliquota, della varianza globale,
imputabile al secondo fattore in esame, utilizziamo la seguente scomposizione analoga a
quella fatta per l’ANOVA a una via:
∑∑∑∑∑∑=
•=
•= =
••= =
−+−++−−=−b
jj
n
ii
n
i
b
jjiij
n
i
b
jij xxnxxbxxxxxx
1
2
1
2
1 1
2
1 1
2 )()()()(
∑∑∑∑ ++=bfet
nb
che esprime il fatto che la somma∑t, dei quadrati degli bn× scarti, rispetto alla media
globale è pari alla somma∑e, delle bn× differenze quadratiche rispetto alle medie
parziali (per riga e per colonna) più b volte la somma∑ f, delle n differenze quadratiche
imputabili agli n livelli del fattore principale, più infine n volte la somma∑b, delle b
differenze quadratiche imputabili ai b blocchi.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
28
Le quantità ∑te ∑e
sono dette rispettivamente devianza totale e residua. Le devianze
∑ fb e ∑b
n sono dette rispettivamente devianza spiegata dal fattore principale e dal
fattore secondario.
L’ANOVA a due vie è analoga a quella a una via, e può essere rappresentata come nella
seguente tabella:
Orig. Della Varianza
Devianza Gradi di Libertà
Varianza S2
Valore Atteso di S2, E{S2}
Fattore Principale ∑
=• −
n
ii xxb
1
2)( 1−n )1( −
∑n
bf ∑
=
−+n
ii nb
1
22 )1(ασ
Fattore Secondario ∑
=• −
b
jj xxn
1
2)( 1−b )1( −
∑b
nb ∑
=
−+b
jj bn
1
22 )1(βσ
Errore ∑∑= =
•• +−−n
i
b
jjiij xxxx
1 1
2)( )1)(1( −− bn )1)(1( −−
∑bn
e
2σ
Totale ∑∑= =
−n
i
b
jij xx
1 1
2)( 1−nb )1( −
∑nb
t
Tabella 2.2.3 ANOVA a 2 vie
MANOVA
L'Analisi Multivariata della Varianza (MANOVA) è una tecnica statistica che permette di
stimare come un insieme di variabili indipendenti influenzi o meno due o più variabili
dipendenti. Difatti MANOVA è una estensione dell'Analisi della Varianza Univariata. In
particolare la differenza con quest'ultima sta nella capacità di esaminare
contemporaneamente combinazioni di più variabili dipendenti. Il problema che
solitamente emerge nell'applicare tale tecnica sta nella selezione delle variabili dipendenti.
Tale scelta deve essere preceduta da uno studio teorico che giustifichi l'analisi congiunta.
Le assunzioni da verificare per poter applicare MANOVA sono:
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
29
1. Indipendenza delle osservazioni
2. Le matrici di varianza e coviarianza devono essere uguali
3. Distribuzione Multivariata Normale, ossia una generalizzazione della distribuzione
Normale Univariata nel caso di p-variabili.
4. Dimensione dei campioni con o un numero di osservazioni maggiore di venti o
almeno superiore al numero di variabili dipendenti.
Per poter applicare MANOVA è necessario che sia soddisfatta la prima assunzione. Per le
altre si ammettono delle violazioni purché siano minime. Per la seconda assunzione si
tollera una violazione se le dimensioni dei campioni sono simili. Invece per la terza
assunzione la violazione è tollerata se la dimensione del campione è contenuta. Per
dimensione contenuta si intende minore di 50 elementi per campione. L'ipotesi nulla per il
MANOVA test è che: i vettori delle medie delle variabili dipendenti siano uguali. I vettori
di medie (DV) hanno un numero di elementi pari al numero di trattamenti delle variabili
indipendenti considerate nel test. Per poter verificare l'ipotesi nulla sono disponibili tre
tipologie di test: Lambda di Wilks, Traccia di Pillai, Radice Massima di Roy. Tra i test
elencati, i più robusti alle eventuali violazioni tollerate delle assunzioni due e tre sono:
Lambda di Wilks e Traccia di Pillai. Mentre si suggerisce l'uso del test della Radice
Massima di Roy nel caso in cui siano verificate tutte e tre le assunzioni.
2.3 Regressione Lineare
Le rette di regressione con metodo dei minimi quadrati è una delle tecniche più antiche
della statistica moderna. La funzione matematica che può esprimere in modo oggettivo la
relazione di causa-effetto tra due variabili è chiamata equazione di regressione delle
variabile Y sulla variabile X. Essa a differenza delle semplici rappresentazioni grafiche
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
30
permette di tradurre le caratteristiche che possono essere evidenziate graficamente in
valori numerici, cioè in quantità che permettano a tutti di giungere alle medesime
valutazioni, a partire dagli stessi dati, sia nella stima dei parametri, sia nella applicazione
dei test. [Soliani]
In statistica la regressione lineare rappresenta un metodo di stima del valore atteso
condizionato di una variabile dipendente, o endogena, Y, dati i valori di altre variabili
indipendenti, o esogene, X1, X2,…, Xk : E[Yj | X1, X2, … , Xk] [4].
Si utilizza una regressione lineare in quanto l’interpretazione dell’equazione di regressione
è tanto più attendibile tanto più semplice è la curva, come quello di primo e secondo
ordine. Regressioni di ordine superiore sono quasi sempre legate a variazioni casuali; sono
effetti delle situazioni specifiche del campione raccolto e solo molto raramente esprimono
situazioni reali e permanenti [Soliani].
La regressione lineare può essere semplice o multipla, a seconda che il numero di variabili
indipendenti sia uno, oppure più di uno. Nel seguito del paragrafo faremo riferimento
direttamente alla regressione lineare multipla, avendo osservato che ci si può ricondurre
alla semplice considerando soltanto una variabile indipendente. La regressione è detta
lineare in quanto si suppone vi sia una relazione di tipo lineare tra le variabili indipendenti
e la variabile dipendente. Se è ragionevolmente auspicabile che la relazione non sia lineare
occorre effettuare delle trasformazioni sui dati per linearizzarli (talvolta solo sulle variabili
indipendenti e a volte anche su quella dipendente). Dopo la linearizzazione dei dati è
possibile applicare il metodo di regressione lineare. Bisogna comunque prestare attenzione
all’interpretazione dei dati ed al fatto che sono state applicate delle trasformazioni su di
essi.
Il modello di regressione lineare può essere sintetizzato dalla seguente equazione:
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
31
dove B0 è un termine costante e i termini Bi, i =1,2, … ,k sono i coefficienti di regressione
parziale che rappresentano la variazione che subisce la Y quando la Xi aumenta di una
unità, a parità delle altre variabili esplicative, ed e rappresenta un errore, detto residuo non
spiegato. Sulla base dei dati rilevati in fase di raccolta, vengono stimati dei coefficienti e si
cerca di ottenere quindi la stima del modello di regressione nella forma
Quando si effettua la stima, si cerca di minimizzare l’errore quadratico che si commette
effettuando la stima stessa. Questo metodo va sotto il nome di metodo dei minimi quadrati
(least mean square). Per illustrare il metodo occorre introdurre il concetto di residui. I
residui sono definiti come la differenza tra i valori osservati ed i corrispondenti valori
teorici che si collocano sulla retta (o iperpiano) di regressione:
Il metodo dei minimi quadrati consiste nel minimizzare la distanza al quadrato tra i valori
osservati e quelli stimati. Non si minimizza la differenza semplice in quanto differenze
positive potrebbero compensare quelle positive, e non si minimizza il valore assoluto della
differenza perché è più ostico da trattare rispetto al quadrato. Formalmente vogliamo che
Si fornisce un utile esempio nel caso bivariato con a = b0 e b = b1. Data la sommatoria da
minimizzare
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
32
La minimizzazione si ottiene annullando le derivate parziali della funzione somma rispetto
ai parametri a e b, risulta quindi
Risolvendo si ottengono i parametri cercati:
essendo
dove x ed y sono le medie osservate.
Sono di seguito presentate alcune caratterizzazioni ed alcuni indici che possono essere
calcolati dalle equazioni della retta (iperpiano) di regressione. È possibile scomporre la
devianza nel seguente modo:
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
33
dove
è detta devianza totale o SST (Sum of Square Total);
è detta devianza di regressione o SSR (Sum of Square of Regression);
è detta devianza residua o di errore o SSE (Sum of Square of Error).
Da queste grandezza, è possibile ricavare un importante indice che va sotto il nome di
indice di indeterminazione multipla, R2:
.
Questo indice è sempre compreso tra zero ed uno ed indica la quota di devianza (varianza)
della variabile dipendente Y spiegata dalla relazione lineare con le variabili esplicative. Si
può ritenere R2 come misura della bontà dell’adattamento (goodness of fit) del piano di
regressione ai punti osservati. Vale a dire, più prossimo a uno è il valore di R2, più piccolo
è la dispersione dei punti intorno al piano di regressione, e migliore sarà l’adattamento.
Quando si vuole effettuare un confronto tra modelli che presentano un numero di variabili
esplicative differenti, non si può fare affidamento sull’indice R2 poiché esso non tiene in
conto del numero di variabili presenti nel modello. A questo proposito si introduce un
nuovo indice chiamato adjusted R2, o R2 corretto, che consente di effettuare il confronto
tra modelli. Esso è un indice in genere più piccolo di R2 per costruzione e mostra la
proporzione di variabilità di Y spiegata da tutte le variabili X, corretto per il numero di
variabili di X utilizzate. Esso è dato da
dove n è il numero di osservazioni effettuate e k è il numero di variabili indipendenti.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
34
Aggiungendo quindi una variabile al modello, R2adj può anche diminuire (cosa che non
accadeva per R2).
Infine si presenta il parametro di errore standard definito come
Esso rappresenta la deviazione standard delle variazioni delle osservazioni intorno alla
retta di regressione. Si faccia attenzione nel giudicare il valore di tale indice, in quanto
esso deve essere sempre osservato considerando l’ordine di grandezza della risposta Y
all’interno del campione dei dati.
Alcune assunzioni devono essere effettuate per poter applicare la regressione lineare. Le
più importanti sono:
1. omoschedasticità, ovvero la varianza dell’errore è costante;
2. i residui seguono una distribuzione normale;
3. incorrelazione tra variabili indipendenti e residui.
Leverage degli Effetti
La tecnica di Leverage degli effetti fu introdotta dallo statistico Sally nel 1980 [JMP_stat].
Tale tecnica consiste nel “plottare” i residui di un fattore indipendente di cui si vuol
verificare la significatività nello stimare la risposta. Come rappresentato nelle successive
figure la linea orizzontale denota l’assenza dell’effetto attribuibile al fattore in esame,
mentre la retta in rosso è il regressore utilizzato per stimare il fattore indipendente. Se si
verifica che le curve di confidenza del regressore attraversano la linea orizzontale allora il
fattore è significativo, altrimenti no.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
35
Figura 2.3.1 Possibili risultati Leverage degli effetti
In figura 2.3.1 è possibile osservare un caso particolare in cui la curva di confidenza è
asintotica alla linea orizzontale. Anche in questo caso il fattore in esame è significativo ma
siamo di fronte ad un caso limite detto borderline. Tale interpretazione grafica consiste
algebricamente nel confrontare le differenze delle somme dei quadrati dei due gruppi di
residui (con o senza effetto del fattore), che rappresenta la somma dei quadrati dovuta
all’ipotesi nulla. Tale quantità viene poi utilizzata per ricondursi ad un F-Test.
2.4 Regressione Stepwise
La regressione stepwise è una metodologia statistica di regressione in cui la scelta delle
variabili predittive è condotta attraverso una procedura automatica. Di solito vengono
eseguiti una serie di F-test statistici. I principali approcci sono i seguenti:
� selezione in avanti o forward selection: si parte con un modello iniziale che non
contempla nessuna variabile se non la sola intercetta. A partire da questo modello si
selezionano una alla volta le variabili di regressione (regressori) come candidate ad un
possibile inserimento all’interno del modello. Ogni variabile che viene selezionata,
viene testata con un F-test e viene inserita nel modello se l’indice di significatività
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
36
statistica relativo al test effettuato è maggiore di un valore prefissato, detto p-enter. La
prima variabile regressore selezionata nel modello è quella con la più elevata
correlazione con la variabile dipendente. Appare utile illustrare brevemente il metodo
con un esempio: supponiamo che la prima variabile di regressione scelta sia una certa
variabile x1. Il secondo regressore scelto sarà quello caratterizzato dalla maggior
correlazione con i valori y, “corretti” dall’effetto della prima variabile regressore
considerata. Ci si riferirà a queste correlazioni come correlazioni parziali. Esse sono le
semplici correlazioni tra i residui della regressione:
e i residui dalle regressioni degli altri candidati sulla variabile x1, ovvero
Si supponga che la variabile con la più alta correlazione parziale sia x2, si effettua un
F-test per la significatività, e se il valore ottenuto dal test è superiore al valore p-enter
prefissato, si aggiunge la variabile x2 al modello. La procedura iterativa termina
quando sono state esaurite tutte le variabili di regressione o quando una variabile di
regressione conduce ad un valore del test F minore della soglia p-enter.
� Eliminazione all’indietro o backward elimination: tale procedura è in un certo senso
speculare alla procedura di selezione in avanti. Si parte da un modello che comprende
tutte le variabili di regressione e si selezionano una alla volta le variabili come
candidate all’eliminazione. Si esegue quindi una statistica F parziale per ogni variabile
di regressione, come se essa fosse l’ultima variabile ad entrare nel modello. Il valore
più piccolo di queste statistiche parziali è confrontato con un valore predefinito detto
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
37
p-remove. Se il valore restituito dal test è più piccolo di p-remove, la variabile di
regressione è rimossa, e la procedura è ripetuta di nuovo con il modello superstite.
Tale procedura è iterata sino a quando il più piccolo valore dell’F-test non è inferiore
al valore p-remove.
� Regressione “stepwise”: è un metodo che in un certo senso fonde i due approcci
precedenti. Ad ogni passo tutti i regressori considerati precedentemente nel modello
sono testati di nuovo attraverso la valutazione della relativa F, poiché un regressore
introdotto precedentemente può risultare ridondante in virtù della entrata di nuove
variabili di regressione. Sono presenti entrambe le soglie menzionate nei due metodi
precedenti che vanno a formare un intervallo [p-enter, p-remove] al quale i valori delle
statistiche F devono appartenere affinché le relative variabili di regressione
appartengano al modello finale.
Il software statistico [JMP_stat] utilizzato per effettuare le inferenze può essere utilizzato
solo per fattori categorici a 2 livelli. Nel caso in cui tali fattori abbiano un numero di
livelli superiori, il software effettua la scomposizione della variabile a n livelli, in n-1
variabili secondo una struttura gerarchica a albero. Come illustrato nel paragrafo [ §4.3 ].
2.5 Analisi delle Variabili Canoniche
L’Analisi delle Variabili Canoniche (AVC) è una tecnica di statistica multivariata che
permette riorganizzare i dati fornendo un punto di vista migliore per l’interpretazione dei
risultati. In particolare data una caratteristica (X i) che influenza due o più variabili di
uscita (Y1,Y2,…,Yk), permette di stabilire su quale di esse ha più peso nel determinare il
risultato. Questa peculiarità risulta particolarmente interessante per capire se è possibile o
meno raggiungere un trade-off tra le variabili di uscita [e-book stat].
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
38
Nell’AVC viene eseguita la riorganizzazione delle osservazioni sperimentali in un diverso
spazio, con un ridotto numero di dimensioni. In altre parole il dataset multivariato (con p-
variabili) può essere guardato come un insieme di punti nello spazio a p-dimensioni e
un'opportuna combinazione lineare di queste variabili permette di riorganizzare questo
spazio, in modo da agevolare l’interpretazione dei risultati. In particolare, con questa
riorganizzazione si mira a conservare la separazione (discriminazione) tra punti, pur
riducendo le dimensioni dello spazio [Soliani]. In questa situazione l’attenzione è in
genere rivolta alla discriminazione tra gruppi. Le variabili canoniche sono una
combinazione lineare delle variabili originali, finalizzata a massimizzare le differenze tra
gruppi, piuttosto che la variabilità totale. In altre parole, dato un insieme multivariato di
osservazioni sperimentali, si cerca una nuova prospettiva che, con un ridotto numero di
dimensioni, evidenzi al meglio le differenze tra gruppi, trascurando invece le differenze
tra individui. Come detto, le variabili canoniche si ottengono per combinazione lineare
delle variabili originali, secondo lo schema:
dove VC1 è la prima variabile canonica, X sono le p-variabili originali, n sono gli individui
sperimentali e a1, a2, ap, sono p-coefficienti di trasformazione, da scegliere in modo che la
risultante VC1 permetta la miglior separazione (discriminazione) possibile tra i gruppi [e-
book stat] . Dobbiamo ora considerare che i gruppi sono tanto meglio discriminati quando
più vicini sono gli individui nel gruppo (bassa variabilità entro gruppo) e quanto più
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
39
lontane sono le medie dei gruppi (alta variabilità tra gruppi); cioè i gruppi sono tanto
meglio discriminati quanto più è elevato il valore del test F nell'ANOVA univariata. Ed è
proprio questo il principio di fondo: scegliere a1, a2, ap in modo che se le VC risultanti
sono sottoposte ad ANOVA univariata, esse restituiscono il valore più alto possibile per il
rapporto F ('varianza tra gruppi/varianza entro gruppi').
Riepilogando, i coefficienti canonici sono utilizzati per creare una combinazione lineare
delle variabili originali e rappresentano quindi un metodo per riorganizzare le osservazioni
sperimentali in uno spazio diverso, con meno dimensioni, ma senza perdere la capacità di
differenziare i gruppi. In realtà, più che le variabili canoniche, interessa calcolare i
punteggi canonici dei centroidi di ogni gruppo (le medie delle variabili originali), cioè la
loro posizione nel nuovo spazio di riferimento. Le nuove coordinate dei centroidi
(punteggi canonici dei centroidi) possono essere ottenute allo stesso modo delle variabili
canoniche:, moltiplicando la matrice delle medie delle variabili standardizzate per la
matrice dei coefficienti canonici standardizzati.
Tutto ciò si può comodamente osservare in un biplot, nel quale vengono riportati i
punteggi canonici delle medie, insieme ai coefficienti canonici standardizzati, in forma di
vettori geometrici (uno per ogni variabile originale), che tirano le medie lungo la loro
direzione in modo tanto più intenso quanto più è alto il loro valore originale della
caratteristica rilevata. In conclusione l'analisi canonica costituisce un ottimo mezzo per
studiare graficamente le distanze tra gruppi e comprendere quali caratteristiche
contribuiscono meglio alla discriminazione. Anche se l'analisi canonica riveste
un'indubbia utilità per riassumere i dati, essa non potrà mai sostituire un'accurata analisi
puntiforme dei risultati dell'esperimento, altrimenti il rischio di perdere o confondere le
informazioni può essere abbastanza elevato.
Capitolo 3
Procedura sperimentale ed Esecuzione degli esperime nti
Il metodo scientifico è la modalità tipica con cui la scienza procede per raggiungere
una conoscenza della realtà oggettiva, affidabile, verificabile e condivisibile. Esso
consiste, da una parte, nella raccolta di evidenza empirica e misurabile attraverso
l'osservazione e l'esperimento; dall'altra, nella formulazione di ipotesi e teorie da
sottoporre nuovamente al vaglio dell'esperimento. In questo capitolo è presentata la
successione di step eseguiti per individuare gli obiettivi, il piano degli esperimenti e le
modalità con cui sono stati eseguiti.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
41
3.1 Indagine sugli Obiettivi
I criteri di valutazione utilizzati nell’indagine sono: Efficacia e Costo della detection,
Efficacia per Classi di Fault. Applicando il paradigma Goal/Question/Metric [13][14] è
stato prodotto un insieme di obiettivi e domande a cui lo studio intende dare risposta come
rappresentato in figura 3.1.1:
I. Efficacia
A. Quale tra le Tecniche di Testing sperimentata è più efficiente? 1. Quale tecnica rileva la percentuale maggiore di fault?
B. La percentuale di fault rilevati dipende dal tipo di Software? C. La percentuale di fault rilevati dipende dalla Quantità di fault?
II. Costo A. Quale tecnica di testing fornisce il miglior Detection Rate (Numero di fault rilevati
per ora)? B. Il Detection Rate dipende dal tipo di Software? C. Il Detection Rate dipende dalla Quantità di fault?
III. Trade-off
A. Quale Tecnica di Testing permette di raggiungere un buon trade-off tra costo ed efficienza?
IV. Efficacia per tipi di fault A. Quale Tecnica (o combinazione di tecniche) permette di avere una buona efficienza
sui vari tipi di fault? B. Le tecniche di testing “dimostrative”( Statistical e Functional Testing ) quali tipi di
fault rilevano? C. Le tecniche “distruttive”( Stress e Robustness Testing ) quali tipi di fault rilevano?
Figura 3.1.3. Framework Goal/Question/Metric
Il primo obiettivo (Efficacia globale) porta a una prima semplice domanda: Quale tecnica
permette di rilevare la percentuale maggiore di fault (I-A-1)? La comparazione tra le
tecniche di testing è fatta su più target applicativi, ognuno caratterizzato da un differente
numero di fault. Inoltre per ogni tipologia di Software sono considerati diversi livelli di
quantità di fault. Quindi è interessante determinare se la percentuale di fault rilevati è
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
42
funzione del programma testato e/o della quantità di fault presenti (I.C, I-B). Infine
essendo lo Statistical testing una euristica basata sul Functional Testing risulta
interessante osservare le differenze in termini di efficienza e costo tra le due tecniche
[§1.1.2].
Ad ogni tecnica è associato un costo. Dunque è interessante conoscere quanta sforzo
(costo) richiede l’applicazione di una tecnica (II-A) e capire se tale sforzo è legato alla
Tipologia di Software e alla Quantità di fault presenti (II-B, II-C).
Potrebbe essere interessante anche individuare un fattore (in particolare un tecnica di
testing) che permettesse di raggiungere un buon trade-off dei due obiettivi (III.A).
Invece osservando l’Efficienza per tipi di fault è possibile individuare quale combinazione
di tecniche permette di migliorare l’affidabilità (IV-A, IV-B) ed associare alla Tipologia di
Testing i tipi di fault che rileva (IV-C, IV-D).
3.2 Generazione del Piano degli Esperimenti
La generazione del piano degli esperimenti con filosofia DoE richiede come primo step la
selezione delle variabili (o fattori) dipendenti ed indipendenti. Le variabili dipendenti
indicano ciò che s’intende misurare a valle degli esperimenti. Mentre le variabili
indipendenti permettono di riprodurre le condizioni in cui effettuare gli esperimenti (come
la quantità e la tipologia di fault inizialmente presenti nel software), per individuare quali
di esse hanno effetto sulle risposte. Come emerso dal precedente paragrafo le variabili
dipendenti sono: Percentuale di Fault Rilevati su fault presenti (Efficienza), Numero di
fault rilevati per ora (Detection Rate) ed infine Percentuale di fault rilevati per tipo di fault
ODC (Efficienza per tipo di fault ODC). Essendo cinque il numero di classi ODC abbiamo
in tutto sette variabili dipendenti. Seguendo ciò che è stato esposto nell’indagine sugli
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
43
obiettivi le variabili indipendenti sono: Tecniche di Testing, Tipo di Software, Quantità di
Fault, Percentuale di Assignment Fault, Percentuale di Checking Fault, Percentuale di
Algorithm Fault, Percentuale di Interface Fault, Percentuale di Function Fault.
Le ultime cinque variabili sono continue e rappresentano la distribuzione percentuale dei
fault sulle varie classi ODC [§1.2]. A tale distribuzione viene associata una varianza del
10% come suggerito da [Emulation].
Le tecniche di testing su cui è stata focalizzata l'indagine sono: Statistical, Stress e
Robustness Testing. Tali tecniche sono tra le più utilizzate e ognuna di esse permette di
migliorare l'affidabilità. Alle tre tecniche elencate è stata aggiunta anche il Functional
Testing, in quanto dall'operational profile di quest'ultima si ricava lo Statistical Testing.
Insomma lo Statistical Testing può essere considerato come una euristica basata sul
Functional [§1.1.2]. Quindi risulta interessante verificare le differenze tra le due tecniche.
Le tipologie di software scelte si riferiscono ad ampi e diffusi Target applicativi: Web
Server, DBMS e protocollo di rete. Come rappresentativi di ognuno di essi sono stati
rispettivamente scelti per ogni classe: Apache Web Server, MySQL e Samba. Ognuno di
essi è stato preliminarmente caratterizzato da un certo numero di fault, per simulare la
presenza di guasti all’interno del software e valutare le prestazioni delle tecniche al variare
di tale parametro. Tale numero è stato stimato con opportuni regressori che stimano la
quantità di fault a partire da metriche di complessità. Per allargare la casistica è stata
prevista la variazione del numero di fault presente per ogni software (±65% del risultato
ottenuto dal regressore). In particolare sono stati considerati tre livelli: Alto, Medio e
Basso (Quantità di Fault). In tabella sono riassunti i livelli dei tre fattori categorici:
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
44
Tabella 3.2.1. Variabili Indipendenti Categoriche e trattamenti
Individuate le variabili, i loro livelli e valori è stato quindi generato il piano degli
esperimenti. Il tool utilizzato è stato JMP, con il quale sono state effettuate anche le
successive analisi statistiche.
Tabella 3.1.2. Piano degli esperimenti frazionario
V. I. Categorica Trattamenti
Tecniche di Testing
Robustness Testing
Stress Testing Statistical Testng Functional
Testing
Tipo di Software
Apache MySQL Samba
Quantità di fault
Alto Medio Basso
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
45
3.3 Campagna di Fault Injection
Al fine di valutare l’efficacia della detection è stato necessario conoscere a priori il
numero di fault presenti nel software, oltre che il numero di fault rilevati. Quindi i test
sono stati condotti su versioni di software precedentemente sottoposti a una campagna di
fault injection.
Il tool utilizzato per l’iniezione dei fault è stato Software Fault Injection (SFI). SFI
effettua l’iniezione dei fault modificando il codice sorgente. Questa sua caratteristica lo
rende diverso da altri tool come G-SWFIT, il quale va a modificare il codice binario per
iniettare i fault relativi a codice di alto livello [10]. Tale approccio rende il tool poco
partibile, in quanto richiede eterogeneità tra Hardware/OS/compiler. Inoltre mediamente il
9% dei cambiamenti di codice binario non corrispondono a nessun cambiamento per high-
level software fault [14]. SFI risolve tali problematiche ma ne presenta altre come: il
tempo di ricompilazione a valle dell’iniezione e la necessità di essere in possesso dei
sorgenti del Software. In tabella sono presenti i fault operator che utilizza SFI, i quali
rappresentano le tipologie di fault più frequenti[14].
Tabella 3.3.1 Fault Operator
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
46
3.4 Raccolta dei dati sperimentali
Gli esperimenti sono stati condotti dallo stesso operatore e sullo stesso PC le cui
caratteristiche sono riassunti in tabella.
Processore Intel Core Duo CPU @ 2 GHz T5750 SO Ubuntu 8.04 RAM 3 GB Hard Disk 250 GB
Tabella 3.4.1 Caratteristiche della macchina su cui sono stati condotti i test
La fase di raccolta dei dati è la prima fase di un procedimento sperimentale, e forse la più
importante. Raccogliere bene i dati è un requisito fondamentale per la validità e la
correttezza dei risultati successivi. Commettere errori in questa fase può essere molto
deleterio, per questo si è prestata particolare attenzione nella raccolta.
I dati raccolti sono poi stati riorganizzati secondo la Tabella 3.4.2
Tabella 3.4.2. Risultati degli esperimenti
Capitolo 4
Analisi dei Dati
Il DOE progettato per l’analisi comparativa delle tecniche di testing prevede: 8 variabili
indipendenti ( detti anche fattori o effetti ), 7 variabili dipendenti (dette anche variabili di
risposta), con un numero totale di esperimenti pari a 16.
Lo scopo di tale paragrafo è quello di individuare quali sono i fattori che sono
statisticamente più rilevanti nel determinare il valore delle variabili di risposta. Inoltre
mediante test d’ipotesi di Tukey, si cercherà di individuare anche come i vari livelli dei
fattori più significativi influenzano le variabili di uscita selezionate.
Dato il numero elevato di fattori da considerare nell’analisi delle risposte è stato adottato il
seguente modus operandi:
1. Analisi della varianza univariata e multivariata a più vie sui fattori categorici. Tale
tipo di test viene effettuato sui dati sperimentali.
2. Procedura Stepwise (opzionale), grazie alla quale riusciamo ad individuare un
sottoinsieme di fattori indipendenti che vengono poi utilizzati per costruire il modello
di regressione multipla.
3. Modello di regressione multipla con metodi dei minimi quadrati, ai dati stimanti
mediante il modello è stato applicata il metodo di leverage degli effetti. Tale tecnica
permette di individuare le variabili indipendenti che influenzano la risposta. I risultati
conseguiti sono generati dalle stime dei dati dunque soggetti ad un errore maggiore
rispetto alle conclusioni che si possono estrapolare direttamente dai dati sperimentali.
4. Test di Tukey, che permette di stabilire con un livello di protezione del 95%, se le
medie dei vari livelli di un fattore categorico, sono tra di loro significativamente
differenti. Cioè se le differenze tra le medie possono, o meno, essere attribuiti a una
fluttuazione fisiologica attribuibile all’errore sperimentale. Tale test è stato effettuato,
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
48
ove possibile, sia sui dati sperimentali che sulle stime dei dati estrapolati con il
modello di regressione multipla. I risultati ottenuti per quest’ultimi, a differenza dei
primi, devono essere interpretati con cautela , in quanto su di essi grava anche l’errore
associato al modello con cui vengono calcolate le stime.
La procedura di stepwise è stata applicata solo per le variabili di risposta, in cui il modello
di regressione multipla con tutte le variabili indipendenti presentava un coefficiente di
correlazione basso (ossia sulla Efficienza per tipo di fault ODC). Oltre alle tecniche
esposte è stata eseguita l’analisi multivariata mediante MANOVA e analisi delle variabili
canoniche sulla Efficienza della detection e Detection Rate. Tale analisi permette di
valutare quali fattori influenzano simultaneamente entrambe le risposte in esame. L’ultimo
paragrafo contiene le verifiche della assunzioni necessarie per poter effettuare i test
utilizzati. Nel seguito, le varie variabili di uscita sono esaminate tenendo presente lo
schema illustrato nei punti precedenti.
4.1 Analisi Univariata della Efficienza delle Detec tion
In questo paragrafo verranno esposti i test statistici applicati per interpretare i dati relativi
alla Efficienza della detection. In prima istanza verrà utilizzata l’Analisi della Varianza a
una e più vie per verificare quale fattore categorico influenza la riposta in esame. Si
cercherà inoltre di verificare se esiste una evidenza statistica che permetta di affermare che
esiste anche una interazione tra i fattori esaminati. In seconda battuta, i dati saranno
interpolati mediante un modello di regressione lineare multipla, con metodo dei minimi
quadrati. I dati così interpolati verrano quindi esamnati con tecnica di leverage degli
effetti, al fine di isolare i fattori che influenzano l’ Efficienza della detection. In questo
modo si cercherà una conferma del risultato dell’ANOVA (prove di convalida) e allo
stesso tempo si cercerà di capire in che direzione puntare per eventuali sviluppi futuri.
Infine sia sui dati sperimentali che su quelli interpolati verrano applicati test d’ipotesi, con
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
49
cui si cercherà di estrapolare informazioni relative all’influenza che i livelli dei fattori,
individuati con le precedenti tecniche, hanno sulla risposta.
4.1.1 ANOVA e Correlazione
L’Analisi della varianza è una tecnica può essere applicata ai fattori categorici. Nel caso in
esame i fattori sono i seguenti: Tecniche di Tecniche di testing, Quantità di fault,
Tipologia di Software. Verifichiamo con tale tecnica quale dei tre fattori può essere
considerato come fattore principale che influenza l’uscita. Per poter applicare ANOVA, è
stato verificato che le varianze dei vari fattori siano uguali [§ 4.5.1].
Nelle successive tabelle sono riportati i risultati per ANOVA a una via per tutti i fattori
categorici, ed ANOVA a due vie con interazione considerando come fattore principale le
tecniche di testing. Anche con ANOVA si considera l’ipotesi nulla e si verifica se è
statisticamente significativo rigettare o meno tale ipotesi.
H0 : La Variabile Indipendente in esame non influenza statisticamente
l’Efficienza della Detection
V.I. Categoriche
p-value (F-test )
Considerazioni
Tecniche di Testing
0,0003 L’ipotesi nulla può essere rigettata con un livello di significatività del 99,9997 %
Quantità di fault
0,5792 Non è possibile rigettare l’ipotesi nulla.
Software 0,41873 Non è possibile rigettare l’ipotesi nulla.
Tabella 4.1.1 Risultati ANOVA a una via per Variabili Indipendenti (VI) Categoriche
I risultati dell’ANOVA a una via riportati in tabella 4.4.1 ci permettono di osservare che
solo per le tecniche di testing è possibile rigettare l’ipotesi nulla con una significatività del
99.9987 %. Per gli altri due fattori indipendenti, invece, non è possibile rifiutare tale
ipotesi. Quindi questi due fattori potrebbero essere considerati dei fattori secondari (fattori
di disturbo). Per verificare questa ipotesi è stata eseguita l’ANOVA a due vie, utilizzando
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
50
come fattore principale le tecniche di testing e come fattore secondario (o di disturbo):
Quantità di fault , Tipologia di software e l’interazione tra fattore principale e fattore di
disturbo.
L’ipotesi nulla è che: il primo fattore, il secondo fattore o la loro interazione non abbiano
una influenza statisticamente significativa sulla Efficienza della detection.
1° Fattore p-value (F-test )
2° Fattore p-value (F-test )
Interazione p-value
Tecniche di Testing
0,000544 Quantità Di Fault
0,2662 0,5029
Tecniche di Testing
0,000350 Software 0,1534 0,1412
Quantità di Fault
0,432708 Software 0.4735 0.7656
Tabella 4.1.2. Risultati ANOVA a due vie con interazione tra i fattori
Dall’ANOVA a due vie (tabella 4.1.2) osserviamo che viene rigettata anche l’ipotesi che
la Quantità di Fault e la tipologia di software possano essere considerati come fattori
secondari. Inoltre, anche la loro interazione con le tecniche di testing non risulta essere
statisticamente influente sulla risposta.
Dai risultati ottenuti risulta evidente che l’unico fattore su è possibile approfondire
l’indagine è la Tecnica di Testing. Sono state quindi calcolate medie e deviazioni standard
della percentuale di fault rilevati dalle varie tecniche di testing.
Inoltre al fine di poter meglio interpretare i dati è stato applicato il test di Tukey per poter
capire se le differenze tra le varie stime sono o meno da imputare all’errore sperimentale
(intervallo di protezione del 95% ).
In figura è riportato il grafico a diamante (cfr. Appendice A), che meglio evidenzia i dati
posti in tabella 4.3.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
51
Grafico 4.1.1. Grafico a Diamante della Percentuale totale di fault rilevati delle varie tecniche di testing
Tabella 4.1.3. Stime della Percentuale Totale di Fault Rilevati
Osservando i dati posti in tabella 4.1.3, ed il grafico 4.1.1, osserviamo che essendo l’errore
standard della media non troppo grande, tali stime sembrano ben rappresentare il
comportamento della variabile di risposta. Notiamo che le stime fatte per Functional e
Statistical sono molto vicine, mentre più staccate sono le altre due. Per capire se tali
differenze tra le medie stimate sono effettivamente dovute al contributo dato da ogni
livello del fattore, oppure sono dovute al caso, è possibile effettuare il test di Tukey. Nelle
successive due tabelle sono riportate tutte le coppie cu cui è stato effettuato il test, con il
relativo p-value del test di Fisher ed un quadro riassuntivo che assegna ai livelli una
lettera. I livelli non connessi dalla medesima lettera sono significativamente differenti.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
52
H0: Le medie dei livelli del fattore in esame,
non sono significativamente differenti tra di loro
Tabella 4.1.4 Tutte le coppie comparate Tabella 4.1.5 Quadro riassuntivo dei risultati
Tale test fornisce un livello di protezione del 95% e osservando la tabella 4.1.4 ciò che
possiamo affermare è solo una significativa differenza tra il Robustness Testing e le altre
tecniche. Alla luce di questa affermazione anche i dati calcolati in precedenza sono da
trattare con cautela. Ossia non possiamo affermare che il Functional Testing sia
effettivamente la tecnica migliore, in questo contesto, bensì che con il livello di
significatività del 95% il robustness testing è la tecnica che ha efficienza peggiore.
Conclusa l’analisi per i fattori categorici si riportano in tabella i risultati ottenuti
calcolando la correlazione tra le variabili continue indipendenti e l’Efficienza della
Detection.
Variabili Continua
Indipedente
Correlazione
con Efficienza
Assignment 0,37
Checking -0,03
Interface -0,19
Algorithm -0,07
Function -0,17
Tabella 4.1.6. Correlazione tra le variabili continue indipendenti e l’Efficienza
Dai risultati riportati non si evince nessun tipo di correlazione importante (ossia maggiore
del 0,5). Solo per la classe di fault Assignment abbiamo una correlazione del 0,37, ma non
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
53
sufficiente per assumere che vi sia una forte correlazione. Si conclude quindi che non vi è
nessuna dipendenza significativa tra l’Efficienza e le variabili indipendenti continue.
4.1.2 Modello Lineare di Regressione Multipla
Per interpretare i dati a nostra disposizione è stato applicato metodo di regressione
multipla con metodo dei minimi quadrati. Tale modello presenta un coefficiente di
correlazione di 0.996947 e un coefficiente di correlazione corretto di 0.984737, dunque
possiamo utilizzare tale modello per analizzare i dati a nostra disposizione.
Il passo successivo è stato quello di applicare il metodo di Leverage degli effetti per capire
quale fattore abbia significatività nello stimare la risposta. Per utilizzare la leverage degli
effetti è necessario formulare l’ipotesi nulla, ossia l’ipotesi che è opposta a quello che
vogliamo dimostrare. Quindi l’ipotesi nulla per ogni fattore è :
HP0: Il fattore Indipendente in esame non ha un effetto significativo
sulla stima della variabile di risposta.
I grafici 4.1.2 e 4.1.3 sono riportati i risultati per ognuno dei fattori.
Grafico 4.1.2 Risultati Leverage degli effetti
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
54
Grafico 4.1.3 Risultati Leverage degli effetti
Tabella 4.1.7 . Quadro riassuntivo dei risultati della tecnica di Leverage degli effetti
Come mostrato in tabella 4.1.7, per tutte le variabili indipendenti continue è possibile
rigettare l’ipotesi che tali fattori abbiano una influenza sulla percentuale totale di fault
rilevati, essendoci un’evidenza statistica per farlo. Viceversa, per le tre variabili
categoriche è possibile accettare l’ipotesi che queste influenzino la variabile di uscita, con
i livelli di significatività riportati in tabella. Abbiamo quindi per le Tecniche di Testing una
conferma del risultato ottenuto con ANOVA. Mentre per Quantità di fault e Tipologia di
Variabile Indipendente
p-value (F-test )
Considerazioni
Perc. Assignment Fault 0.1741 Non è possibile rigettare l’ipotesi nulla.
Perc. Checking Fault 0.3022 Non è possibile rigettare l’ipotesi nulla.
Perc. Algorithm Fault 0.3140 Non è possibile rigettare l’ipotesi nulla.
Perc. Function Fault 0.3917 Non è possibile rigettare l’ipotesi nulla.
Perc. Interface Fault 0.4938 Non è possibile rigettare l’ipotesi nulla.
Tecniche di Testing 0.0017 L’ipotesi nulla può essere rigettata con un livello di significatività del 99,9983 %
Quantità di fault 0.0278 L’ipotesi nulla può essere rigettata con un livello di significatività del 99,9722 %
Software 0.0179 L’ipotesi nulla può essere rigettata con un livello di significatività del 99,9821 %
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
55
Software i risultati discordano. Ciò implica che possiamo confermare quanto detto per le
Tecniche di Testing precedentemente. Mentre non possiamo pronunciarci allo stesso modo
per gli altri due fattori categorici. Possiamo quindi assumerli come fattori di disturbo del
terzo o del quarto ordine. Per una conferma di questa affermazione sarebbero necessari
approfondimenti con un numero di prove sperimentali maggiore.
Comunque per tali fattori categorici indipendenti sono state calcolate media e deviazione
standard, al fine di valutare l’efficienza del testing. Inoltre per verificare se le differenze
tra le medie calcolate fossero o meno statisticamente significative, o imputabile all’errore
sperimentale, è stato applicato il test d’ipotesi di Tukey.
Tecnica di Testing
Nelle successive due tabelle sono riportate tutte le coppie cu cui è stato effettuato il test di
Tukey, con il relativo p-value del test di Fisher ed un quadro riassuntivo che assegna ai
livelli una lettera. I livelli non connessi dalla medesima lettera sono significativamente
differenti.
H0: Le medie dei livelli del fattore in esame, non sono significativamente
differenti tra di loro
Dalla analisi delle medie calcolate sulle stime estrapolate con il modello di regressione
multipla viene evidenziato un trend che nel precedente paragrafo non era emerso. Ciò
dovuto probabilmente al numero insufficiente di esperimenti. Questo dato è la differenza
tra le medie dello Stress testing e la coppia Functional e Statistical. Tale osservazione è
molto importante soprattutto per lo Statistical testing, il quale ha una efficienza molto
Tabella 4.1.8 Tutte le coppie comparate Tabella 4.1.9 Quadro riassuntivo dei risultati
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
56
vicina del Functional testing.
Quantità di Fault
Procedendo in maniera analoga a come illustrato per le tecniche di testing applichiamo il
test di Tukey a tutte le possibili coppie che si possono generare con i livelli del fattore
Quantità di Fault.
H0: Le medie dei livelli del fattore in esame, non sono significativamente
differenti tra di loro
Tabella 4.1.10. Tutte le coppie comparate Tabella 4.1.11 Quadro riassuntivo dei risultati
Dai dati presenti nelle due tabelle 4.1.10 e 4.1.11 si evince che: l’efficienza della detection
risulta essere significativamente migliore nel caso in cui vi siano un basso numero di fault
presenti. Viceversa un numero di fault più alto implica un deterioramento delle
prestazioni.
Software
Anche per il fattore tipologia di software è stato applicato il test di Tukey, al fine di valutare
se l’efficienza della detection presenta differenze significative in funzione del software.
Nelle successive due tabelle sono stati sintetizzati i risultati ottenuti con un livello di
protezione del 95% .
H0: Le medie dei livelli del fattore in esame, non sono significativamente differenti
tra di loro
Tabella 4.1.11 Tutte le coppie comparate Tabella 4.1.12 Quadro riassuntivo dei risultati
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
57
Come per il fattore quantità di fault, anche la tipologia di software influisce sulla
efficienza della detection. In particolare, la percentuale di fault rilevati risulta essere
significativamente migliore per il software Apache. Tale differenza è giustificata da un
miglior rendimento del Robustness Testing per tale Software.
.
Grafico 4.1.4 . Efficienza in relazione alle tecniche di testing applicate sui vari software
Nel grafico 4.1.4 In blu sono riportati le medie dei minimi quadrati dell’efficienza del
Robustness Testing sulle tre tipologie di software considerate. E’ evidente la differenza
che giustifica il risultato ottenuto dal test di Tukey.
Si ricordi che i risultati esposti in questo paragrafo sono estrapolati dai dati interpolati
mediante modello di regressione multipla, con metodo dei minimi quadrati. Quindi le
inferenze effettuate, mediante test d’ipotesi di Tukey, sono affette anche dall’incertezza
dovuta al modello di Regessione Lineare.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
58
4.2 Analisi Univariata del Detection Rate
I dati relativi al Detection Rate sono stati analizzati procedendo in maniera analoga a
come esposto nel paragrafo precedente per l'Efficienza della Detection. Dunque, in primo
luogo verrà applicata l'Analisi della Varianza a una e più vie per verificare quale fattore
categorico influenza la risposta in esame. Si procederà, quindi, con l'applicazione del
Modello di Regressione Lineare Multipla e i dati così interpolati verrano quindi esamnati
con tecnica di leverage degli effetti, al fine di isolare i fattori che influenzano il Detection
Rate. Comparando i risultati delle due tecniche statistiche si individueranno i fattori
indipendenti che influenzano statisticamente il Detection Rate. Mediante l'applicazione del
Test d'ipotesi di Tukey si procederà con l'esaminare come i singoli livelli dei fattori
selezionati con i precedenti test influenzano la risposta in esame.
4.2 ANOVA e Correlazione
L'Analisi della varianza a una via sarà applicata ai fattori : Tecniche di Testing, Quantità
di Fault, Tipologia di Software. Dai risultati ottenuti si selezioneranno le combinazioni di
fattori a cui sarà applicata l 'ANOVA a due vie con interazione. In tabella sono riportati i
risultati dell'ANOVA a una via. Per tutti e tre i fattori indipedenti vale la seguente ipotesi
nulla:
H0 : Il fattore indipendente in esame non influenza statisticamente il Detection Rate
Fattore Categorico
p-value (F-test )
Considerazioni
Tecniche di Testing
0,2806 Non è possibile rigettare l’ipotesi nulla
Quantità di fault 0,0052 L’ipotesi nulla può essere rigettata con un livello di significatività del 99,9948 %
Tipologia di Software
0,6002 Non è possibile rigettare l’ipotesi nulla
Tabella 4.2.1 ANOVA a una via
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
59
La quantità di fault, come presumibile, sembra influenzare fortemente il Detection Rate.
Per ciò che concerne le Tecniche di Testing l'ipotesi nulla non può essere rifiutata. Si
osserva che il p-value per cui si rifiuta l'ipotesi non è eccessivamente alto. Si procede
quindi con una ANOVA a due vie avente come fattore principale la Quantità di Fault e
fattore secondario le Tecniche di Testing. L’ipotesi nulla è che: il primo fattore, il secondo
fattore o la loro interazione non abbiano una influenza statisticamente significativa sul
Detection Rate.
1° Fattore p-value (F-test )
2° Fattore p-value (F-test )
Interazione p-value
Quantità di fault 0,0004 Tecniche di Testing
0,0117 0,2522
Quantità di fault 0,0102 Software 0,2399 0,7319
Tabella 4.2.2 Risultati ANOVA a due vie con interazione tra i fattori
A valle dei test statistici eseguiti è quindi possibile affermare che il Detection rate subisce
un’influenza statisticamente rilevante: dalle tecniche di testing e dalla quantità di fault. In
particolare le statistiche eseguite evidenziano una particolare influenza della Quantità di
Fault sulla risposta (99,9948 % ), sottolineata dall’analisi della varianza. L’influenza delle
tecniche di testing, invece, è da considerarsi come effetto secondario ( al 99,9883 % )
evidenziato dall’analisi della varianza a due vie. Al fine di poter meglio interpretare i dati
è stato applicato il test di Tukey per poter capire se le differenze tra le varie stime sono o
meno da imputare all’errore sperimentale (intervallo di protezione del 95% ). Nelle
successive due tabelle sono riportate tutte le coppie cu cui è stato effettuato il test, con il
relativo p-value del test di Fisher ed un quadro riassuntivo che assegna ai livelli una
lettera. I livelli non connessi dalla medesima lettera sono significativamente differenti.
H0: Le medie dei livelli del fattore in esame
non sono significativamente differenti tra di loro
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
60
Figura 4.2.1. Grafico a Diamante del Detection Rate per i vari livelli di fault presenti
Dai risultati in tabella e dal grafico a diamante(cfr. Appendice A) si nota la dipendenza del
detection rate dalla quantità di fault presenti. Questo trend sembra suggerire che il
detection Rate è tanto più alto, tanto più alta è la quantità di fault presenti. Per avere una
statistica più significativa è stato effettuato il test di Tukey. I risultati di tale test sono
riportati nelle due tabelle in figura.
Tabella 4.2.3 Tutte le coppie comparate Tabella 4.2.4 Quadro riassuntivo dei risultati
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
61
I risultati ottenuti sembrano avallare l’ipotesi precedente. Infatti il livello alto e basso sono
significativamente differenti ( 95% ), il livello medio è differente dal livello basso invece
non è possibile affermare che lo stesso abbia differenza significativa con il livello alto
(tabella a sinistra). Gli stessi test statistici sono stati applicati anche ai livelli del fattore
Tecniche di Testing. Nella figura 4.2.2 sono rappresentate le medie del detection rate in
base alle tecniche di testing esaminate. E’ possibile già notare come si abbia mediamente
una stima molto simile per tutte le tecniche, eccetto il Robustness testing. Il quale sembra
avere una influenza negativa sulla risposta.
Tabella 4.2.5. Stime del Detection Rate per le varie tecniche di Testing
Figura 4.2.2. Grafico a Diamante del Detection Rate delle tecniche di testing
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
62
Per interpretare meglio questi risultati applichiamo, anche in questo caso, il test di Tukey.
A differenza di quanto ci si aspettava dai dati raccolti non possiamo affermare che il
Robustness testing abbia valori significativamente differenti dalle altre tecniche.
Tabella 4.2.6 Tutte le coppie comparate Tabella 4.2.7 Quadro riassuntivo dei risultati
Infatti dalle tabelle 4.2.6 e 4.2.7 possiamo notare come nessuno dei confronti tra le coppie
di testing abbia prodotto p-value minore di 0.05. Di conseguenza non possiamo affermare
che vi siano significative differenze ma rimane comunque una indicazione data dalle stime
del detection rate.
Dall’analisi fatta mediante ANOVA a due vie è stato verificato come le tecniche di testing
siano un fattore secondario, cioè di disturbo. Tale osservazione può essere meglio
compresa se si osserva il grafico in figura 4.2.3 che presenta sia il grafico a diamanti per le
quantità di fault, che le stime del detection rate per le tecniche di testing divise a seconda
dalla distribuzione di fault. Risulta chiaro come la variabile di risposta sia influenzata
molto dalla quantità di fault, mentre le tecniche di testing fanno variare il detection rate in
un range che è vicino alla stima fatta in funzione della quantità di fault. Insomma la
tipologia di testing ha un effetto sulla risposta ma tale effetto non è macroscopico, bensì
può essere assimilato ad un rumore che pesa sul Detection Rate.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
63
Figura 4.2.3 Grafico a diamante del Detection Rate delle tecniche di testing per i vari livelli di fault
Conclusa l’analisi per i fattori categorici si riportano in tabella i risultati ottenuti
calcolando la correlazione tra le variabili continue indipendenti e il Detection Rate.
Variabili Continua
Indipedente
Correlazione con
Detection Rate
Assignment 0,26
Checking -0,05
Interface -0,13
Algorithm -0,02
Function -0,17
Tabella 4.2.8. Correlazione tra le variabili continue indipendenti e il Detection Rate
Dai risultati riportati non si evince nessun tipo di correlazione importante (ossia maggiore
del 0,5). Solo per la classe di fault Assignment abbiamo una correlazione del 0,26, ma non
sufficiente per assumere che vi sia una forte correlazione. Si conclude quindi che non vi è
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
64
nessuna dipendenza significativa tra il Detection Rate e le variabili indipendenti continue.
4.2.2 Modello Lineare di Regressione Multipla
Ai dati sperimentali raccolti è stato applicato il modello di regressione multipla con
metodo dei minimi quadrati. Tale modello presenta un coefficiente di correlazione di
0.987206 e un coefficiente di correlazione corretto di 0.936032, dunque possiamo
utilizzare tale modello per analizzare i dati a nostra disposizione.
Applicando il metodo di Leverage degli effetti ai dati interpolati sono stati individuati i
fattori che sono significativi nello stimare il Detection Rate con il modello utilizzato. Per
utilizzare la leverage degli effetti è necessario formulare l’ipotesi nulla, ossia l’ipotesi che
è opposta a quello che vogliamo dimostrare.
Quindi l’ipotesi nulla per ogni fattore è :
HP0: Il fattore in esame non ha un effetto significativo sulla stima della variabile di
risposta.
In figura sono riportati i risultati per ognuno dei fattori.
Figura 4.2.4 Grafici Leverage degli effetti
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
65
Figura 4.2.5 Grafici Leverage degli effetti
Dall’analisi grafica ( figura 4.2.4 e 4.2.5 ) possiamo concludere che:
Variabile Indipendente
p-value (F-test
)
Considerazioni
Perc. Assignment Fault 0.2644 Non è possibile rigettare l’ipotesi nulla.
Perc. Checking Fault 0.3158 Non è possibile rigettare l’ipotesi nulla.
Perc. Algorithm Fault 0.3177 Non è possibile rigettare l’ipotesi nulla.
Perc. Function Fault 0.3329 Non è possibile rigettare l’ipotesi nulla.
Perc. Interface Fault 0.3965 Non è possibile rigettare l’ipotesi nulla.
Tecniche di Testing 0.0215 L’ipotesi nulla può essere rigettata con un livello di significatività del 97,85 %
Quantità di fault 0.0060 L’ipotesi nulla può essere rigettata con un livello di significatività del 99.994 %.
Software 0.0734 Non è possibile rigettare l’ipotesi nulla.
4.2.9 . Quadro riassuntivo dei risultati della tecnica di Leverage degli effetti
Osservando i dati in tabella quindi dobbiamo accettare l’ipotesi nulla per le 5 variabili
continue, che rappresentano le percentuali di fault ODC iniettati nel codice, e per la
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
66
variabile categorica Tipologia di Software Per quanto riguarda i fattori categorici, risulta
molto netta e chiara la significatività statistica delle variabili : Tecniche di Testing (97,85
%) e Quantità di Fault (99.994 %.). Questo risultato conferma ciò che è emerso
dall'analisi della Varianza. E' utile a questo punto approfondire l'indagine e applicare il
test di Tukey ai vari livelli dei fattori in esame. Nelle successive tabelle vengono riassunti
i risultati per le tecniche di testing.
Tabella 4.2.10 Tutte le coppie comparate Tabella 4.2.11 Quadro riassuntivo dei risultati
Dai risultati in tabella si evince un andamento che si era già intuito precedentemente ma
che non aveva riscontro nell'analisi fatta con il test di Tukey. Abbiamo una differenza non
significativa tra Statistical, Functional e Stress Testing, mentre il Robustness Testing è la
tecnica che produce il più basso Detection Rate.
Nelle successive tabelle sono riportati i risultati per i livelli del fattore Quantità di Fault.
Tabella 4.2.12 Tutte le coppie comparate Tabella4.2.13 Quadro riassuntivo dei risultati
I risultati del test di confronto multiplo confermano il trend evidenziato anche con lo
studio dell'analisi della varianza. Ovvero il livello basso produce un detection rate
significativamente diverso dal livello alto e medio. Mentre i risultati per i livelli alto e
medio sono simili.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
67
4.3 Analisi Univariata sulla Efficienza delle Detection per tipi di fault ODC
In questo paragrafo sarà analizzata l'Efficienza della detection per tipi di fault ODC. A
differenza della procedura attuata nei paragrafi precedenti, il modello di regressione
multipla con tutti i fattori presenta un coefficiente di correlazione troppo basso. Quindi per
avere un buon modello è stato necessario considerare un sottoinsieme di fattori, la cui
selezione è stata effettuta applicando la Stepwise Regression. Tale tecnica richiede che le
variabili categoriche siano a due livelli. Dunque le variabili con un numero di livelli
maggiore sono state suddivise in un numero di variabili pari al numero di livelli meno
uno. In figura sono riportati i raggruppamenti effettuati sulle variabili categoriche del
modello in esame.
Figura 4.3.1 .Struttura ad albero del fattore Tecniche di testing
Figura 4.3.2 .Struttura ad albero del fattore Quantità di fault
Figura 4.3.3 .Struttura ad albero del fattore Software
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
68
Individuato il miglior sottoinsieme di variabili indipendenti è stato quindi applicato il
modello di regressione multipla con metodo dei minimi quadrati. Nei successivi paragrafi
sono esposti i risultati ottenuti per ogni risposta.
4.3.1 ANOVA e Correlazione
L’Analisi della varianza è una tecnica può essere applicata ai fattori categorici. Nel nostro
i fattori sono i seguenti: Tecniche di Tecniche di testing, Quantità di fault, Tipologia di
Software. Verifichiamo con tale tecnica quale dei tre fattori può essere considerato come
fattore principale che influenza l’uscita. Per poter applicare ANOVA è stato verificato che
le varianze dei vari fattori siano uguali [§ 4.5.1]. In tabella sono riassunti i risultati
dell’analisi della varianza per i fattori (colonne) in relazione all’Efficienza per tipo di fault
(righe). ANOVA prevede la formulazione dell’ipotesi nulla e verificare se è possibile
rifiutarla o meno.
H0 : Il fattore in esame non influenza statisticamente l’Efficienza della Detection per
il tipo di fault considerato
Tabella 4.3.1 Quadro riassuntivo risultati ANOVA
Dai risultati presentati in tabella 4.3.1 si conclude che è possibile rifiutare l’ipotesi nulla
solo in tre casi. Quindi è possibile affermare che l’Efficienza per i tipi di fault Assignment
Tecniche di Testing
Tipo di Software
Quantità di fault
Perc. Assignment Fault 99,999%
Perc. Checking Fault
Perc. Algorithm Fault 99,996%
Perc. Function Fault
Perc. Interface Fault 99,96%
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
69
e Algorthm è influenzata statisticamente dalle tecniche di testing, mentre l’efficienza sui
fault di tipo Interface dalla Quantità di fault presenti nel software. In tutti gli altri casi
viene accettata l’ipotesi nulla. Nella successiva tabella sono riportati le correlazioni tra
l’Efficienza per tipo di fault ( colonna ) e le variabili indipendenti che indicano la
percentuale di fault presenti ( riga ).
Tabella 4.3.2 Quadro riassuntivo Correlazione
Dai risultati emerge che esiste una dipendenza tra l’Efficienza su classi di fault meno
numerose e le classi di fault più numerose. Tale legame è giustificato dal fatto che nel caso
in cui siano meno presenti fault di tipo Assignment e Algorithm si hanno più fault di tipo
Interface, Checking e Function, quindi è più probabile che vi sia una maggiore percentuale
di detection per quest’ultimi tipi di fault.
Correlazione Efficienza
Assignment Fault
Correlazione Efficienza Checking
Fault
Correlazione Efficienza Interface
Fault
Correlazione Efficienza Algorithm
Fault
Correlazione Efficienza Function
Fault Perc. Assignment Fault
0,19 0,54 -0,17 0,30 -0,59
Perc. Checking Fault
-0,13 -0,18 0,76 -0,04 -0,07
Perc. Interface Fault
-0,08 -0,59 -0,25 -0,09 0,09
Perc. Algorithm Fault
0,01 0,015 -0,17 -0,04 0,62
Perc. Function Fault
-0,09 0,13 -0,22 -0,19 -0,37
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
70
4.3.2 Modello Lineare di Regressione Multipla
In questo paragrafo sono presentati i modelli di regressione multipla utilizzati per produrre
le statistiche relative all'efficienza per tipo di fault. Per ognuna di esse è stata applicata la
tecnica di leverage degli effetti per poter individuare le variabili fondamentali per stimare
la risposta del modello. Per analisi statistiche più dettagliate si rimanda al successivo
paragrafo.
Percentuale di Assignment Fault Rilevati
Coefficiente di correlazione : 0.79.
Come fatto anche per le altre variabili di risposta applichiamo la tecnica di Leverage degli
effetti. Innanzitutto enunciamo l’ipotesi nulla:
HP0: Il fattore in esame non ha un effetto significativo sulla variabile di risposta.
In figura sono riportati i risultati necessari per l’analisi grafica per ognuno dei fattori in
esame.
Figura 4.3.4 .Grafici Leverage degli Effetti per Efficienza Assignment Fault
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
71
Figura 4.3.5 Grafici Leverage degli effetti per Efficienza Assignment Fault
In primo luogo osserviamo la composizione delle variabili, che sono state generate
dall’analisi stepwise. Essa infatti può essere applicata solo per variabili categoriche a 2
livelli, dunque per poter essere applicata al nostro modello, viene effettuata un
raggruppamento con struttura ad albero.
Osserviamo solo per la tecnica di testing, con raggruppamento più generale, è possibile
rigettare l’ipotesi nulla, con un livello di significatività del 99.9998%. Quindi solo il
fattore tecnica di testing ha un’influenza statisticamente significativa sulla Percentuale di
Fault Rilevati di tipo Assignment.
Percentuale di Checking Fault Rilevati
Coefficiente di Correlazione: 0.71.
Come fatto anche per le altre variabili di risposta applichiamo la tecnica di Leverage degli
effetti. Innanzitutto enunciamo l’ipotesi nulla :
HP0: Il fattore in esame non ha un effetto significativo sulla variabile di risposta.
In figura sono riportati i risultati necessari per l’analisi grafica per ognuno dei fattori in
esame.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
72
Figura 4.3.6 . Grafici Levarage degli Effetti per Efficienza Checking Fault.
Dai diagrammi in figura 4.3.6 si osserva che per i fattori Software, Tecniche di testing e
Function, non è possibile rigettare l’ipotesi nulla. Dunque questi non sono variabili
significative per la percentuale di fault di tipo Checking rilevati. Viceversa, per i fattori
Assignment ed Interface, è possibile affermare che influenzano l’uscita, rispettivamente
con una significatività del 99.9678% e del 99.9522%.
Percentuale di Interface Fault Rilevati
Coefficiente di correlazione: 0.71.
Come fatto anche per le altre variabili di risposta applichiamo la tecnica di Leverage degli
effetti. Innanzitutto enunciamo l’ipotesi nulla:
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
73
HP0: Il fattore in esame non ha un effetto significativo sulla variabile di risposta.
In figura sono riportati i risultati necessari per l’analisi grafica per ognuno dei fattori in
esame.
Figura 4.3.7 . Grafici Leverage degli Effetti per Interface Fault
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
74
Dall’analisi grafica dei diagrammi di Leverage (Figura 4.3.7), si evince che non c’è
un’evidenza statistica che permetta di asserire l’influenza sulla risposta delle variabili:
Software e Assignment. Mentre è molto interessante evidenziare che, sulla percentuale di
Interface Fault rilevati, hanno peso variabili come Quantità di fault ( 99.9901% ),
Checking ( 99.9898% ) e tecniche di Testing ( 99.9678% ).
Percentuale di Algorithm Fault Rilevati
Coefficiente di correlazione: 0.81.
Come fatto anche per le altre variabili di risposta applichiamo la tecnica di Leverage degli
effetti. Innanzitutto enunciamo l’ipotesi nulla :
HP0: Il fattore in esame non ha un effetto significativo sulla variabile di risposta.
In figura sono riportati i risultati necessari per l’analisi grafica per ognuno dei fattori in
esame.
Figura 4.3.8 . Grafici Leverage degli Effetti per Algorithm Fault
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
75
Osservando i risultati in figura, possiamo concludere che i fattori per cui è possibile
rigettare l’ipotesi nulla sono la quantità di fault e le tecniche di testing, rispettivamente con
significatività si 99.9997% e di 99.9992%.
Figura . Diagramma di Levarage dei fattori selezionati.
Percentuale di Function Fault Rilevati
Coefficiente di correlazione: 0.92.
Come fatto anche per le altre variabili di risposta applichiamo la tecnica di Leverage degli
effetti. Innanzitutto enunciamo l’ipotesi nulla :
HP0: Il fattore in esame non ha un effetto significativo sulla variabile di risposta.
In figura sono riportati i risultati necessari per l’analisi grafica per ognuno dei fattori
Figura 4.3.8 . Grafici Leverage degli Effetti per Function Fault
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
76
Dai diagrammi in figura si osserva che per i fattori Assignment, Software, non è possibile
rigettare l’ipotesi nulla. Quindi solo per le Tecniche di Testing e Percentuale di
Assignment fault Presenti è possibile affermare che influiscono sulla percentuale di fault
rilevati di tipo Function, rispettivamente con una significatività del 99,9862% e del
99.83% .
Quadro Riassuntivo
In tabella sono riportate le tutte le variabili di uscita analizzate in questo paragrafo (
colonne ), con i relativi fattori da cui sono influenzate ( righe ), secondo l’indagine
statistica illustrata precedentemente. Nella cella d’incrocio tra righe e colonne, viene
riportato il livello di significatività, secondo cui quella variabile indipendente ( riga ),
influenza statisticamente la variabile di risposta ( colonna ). Si ricorda che l’analisi
condotta per le risposte presenti in tabella è stata effettuata sulle stime dei fattori,
dipendenti e non, calcolate mediante modello di regressione multipla con metodo dei
minimi quadrati.
Figura 4.3.9. Grafici Leverage degli Effetti per Function Fault
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
77
Percentuale Assignment
Rilevati
Percentuale Checking Rilevati
Percentuale Interface Rilevati
Percentuale Algorithm Rilevati
Percentuale Function Rilevati
% Assignment 99,9678% 99,93%
% Checking 99,9898%
% Interface 99,9522%
% Algorithm
% Function
Tecniche Testing 99,9998% 99,9678% 99,9992% 99,9862%
Quantità Fault 99,9901% 99,9997%
Software
Le celle evidenziate in rosso ( Tabella 4.3.4 ) sono i risultati confermati rispetto all’analisi
fatta con ANOVA e Correlazione. Quindi dall’applicazione del Leverage degli effetti sui
dati interpolati abbiamo individuato altre dipendenze significative. Ad esempio la
dipendenza dalle tecniche di Testing dell’Efficienza per gli Interface e Function Fault.
Invece abbiamo avuto la conferma che i fault di tipo Checking sono i più complessi da
rilevare. Difatti la relativa efficienza di Detection è funzione soprattutto della
distribuzione dei fault tra le classi Interface e Assignment.
Altro importante risultato riguarda invece la non influenza della tipologia di Software
sull’Efficienza per tipo di fault. Mentre la Quantità di fault nel caso di Efficienza per
Interface e Assignment fault ha un peso sulla risposta. Queste ultime due considerazioni
lette in un’ottica più vasta fanno meglio interpretare anche i risultati sull’Efficienza
Totale. Per la quale non si è potuto individuare se effettivamente i fattori Quantità di fault
e Tipologia di Software fossero influenti sull’Efficienza.
Tabella 4.3.4. Quadro riassuntivo risultati Efficienza per tipo di fault
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
78
4.3.3 Analisi dettagliata dell'Efficienza per tipo di Fault ODC
L’obiettivo di tale paragrafo è quello di esaminare in maniera più dettagliata come le
tecniche di testing pesino sulla detection delle varie tipologie di fault. Per effettuare tale
analisi è stato applicato il test di tukey sulle tecniche di testing, per ogni risposta riferita
alle Percentuali di fault delle classi ODC rilevati. E’ importante sottolineare che questi test
sono condotti sulle stime dei dati sperimentali ottenuti mediante modello di regressione
multipla con metodo dei minimi quadrati. Una migliore analisi richiederebbe un numero di
esperimenti maggiore. Comunque per chiarezza di esposizione in tabella sono riportate
solo i quadri riassuntivi dell’analisi, che permettono di individuare se sono presenti
differenze significative tra le stime di uno stesso fattore, per una certa risposta.
Tabella 4.3.5. Percentuale di Function Fault Rilevati
Tabella 4.3.6. Percentuale Algorithm Fault Rilevati
Tabella 4.3.7 . Percentuale Interface Fault Rilevati
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
79
Tabella 4.3.8. Percentuale Checking Fault Rilevati
Tabella 4.3.8. Percentuale Assignmnt Fault Rilevati
Dai dati riportati si osserva come solo per classi Assignment e Algorithm vi sia una
significativa differenza tra le stime delle percentuali di fault rilevate. In particolare per
entrambe vale che il robustness è la tecnica che presenta l’efficacia peggiore nella
rilevazione dei fault. Poi segue lo stress testing che presenta risultati significativamente
diversi dal Robustness, ma non da Functional e Statistical Testing. Questa situazione può
essere meglio capita se si osservano i dettagli dei risultati del test per tutte le coppie di
tecniche. In tabella 4.3.9 e 4.3.10 sono riportati i dettagli del test per le classi Assignemnt e
Algorithm.
Tabella 4.3.9 . Dettagli per % Algorithm Tabella 4.3.10. Dettagli % di Assignment
Osservando il test Tukey per la percentuale di fault rilevati per la classe Assignment
(tabella 4.3.10) sulla coppia Functional e Stress test rileviamo che la differenza tra le
percentuali rilevate è significativa, mentre tale non è tra Statistical e Stress. Questa
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
80
situazione non ci permette di affermare che le percentuali riferite allo stress testing sono
significativamente differenti da quelle dello Statistical e Functional.
Per tutte le atre classi ODC non è possibile affermare che le percentuali stimate siano
significativamente differenti, però queste lasciano comunque intuire un trend. Che risulta
simile a quello individuato nelle classi Assignment e Algorithm, eccetto che per i fault
rilevati di tipo Interface. I dati inerenti a tale classe evidenziano una percentuale molto alta
di fault rilevati dal Robustness Testing. Tale osservazione però non è stata confermata dal
test di Tukey essendo probabilmente il numero di esperimenti insufficiente.
Dall’analisi dell’efficienza per classi di fault ODC è stato osservato che:
• Il trend osservato per la percentuale totale di fault è stato riscontrato in maniera più
evidente sulle classi Assignment e Algorithm. Sono queste quindi le tipologie di
fault su cui le tecniche considerate hanno più effetto e su cui si determina la
differenza in termini di efficienza tra di esse. Del resto, essendo queste due classi
le più numerose tra le ODC è logico concludere che una alta efficienza nelle classi
Assignment e Algorithm porta ad un buon incremento della percentuale totale di
fault rilevati.
• L’unica classe in cui si è riscontrato un trend diverso è la classe Interface.
Osservando le stime riportate in tabella si evince che il Robustness testing è la
tecnica con percentuale di fault rilevata più alta. Tale affermazione è però da
approfondire, non essendo il numero di esperimenti tale da poter dire con una
significatività accettabile che questa affermazione è vera.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
81
4.4 Analisi Multivariata
Nei paragrafi precedenti sono state utilizzate tecniche statistiche che permettevano di
analizzare una sola variabili di risposta alla volta. In questo paragrafo invece sarà
effettuata l’analisi di coppie o terne di risposte influenzate dai fattori principali estrapolati
dalle analisi precedenti.
In particolare sarà applicata l'analisi della varianza multivariata dell'Efficienza e del
Detection Rate, rispetto ai fattori tecniche di testing e quantità di fault.
Dalle precedenti analisi effettuate utilizzando il metodo di Leverage degli effetti sui dati
interpolati è emerso che i fattori che influenzano significativamente le risposte esaminate
singolarmente risultano essere i fattori categorici. In particolare, si riporta in tabella 4.4.1
un quadro riassuntivo contente sulle righe i fattori e sulle colonne le risposte.
Nell’incrocio tra riga e colonna, se presente un valore, esso rappresenta la significatività
con cui affermiamo, secondo i dati sperimentali raccolti, che quel fattore ( riga ) influenza
una certa risposta ( colonna ).
Detection Rate Percentuale Fault Rilevati
% Assignment % Checking % Interface % Algorithm % Function Tecniche Testing 99.9997% 99.987% Quantità Fault 99,9722 % 99.996% Software 99,9821 %
Tabella 4.4.1 . Quadro riassuntivo
Volendo ora procedere con un’ulteriore analisi della influenza dei fattori su entrambe le
risposte, osserviamo che i fattori da analizzare sono tutti fattori categorici, quindi
utilizzeremo l’Analisi della Varianza Multivariata. Tale tecnica, permette infatti, di
analizzare come un fattore categorico, influisce su più variabili di risposta. Risulta
evidente dai risultati in tabella che i fattori da analizzare sono Tecniche di Testing,
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
82
Quantità di Fault e Software. Riportiamo in tabella i risultati relativi all’influenza di ogni
singolo fattore ( MANOVA a una via ). In tabella 4.4.2 sono presenti i valori dei quattro
test considerati, ricondotti al Test di Fisher.
Tecniche di Testing
Quantità di Fault
Software
Lambda di Wilk 0,00334782 <0,0001 0,63935457 Traccia di Pillai 0,03439456 0,00170000 0,60680969 Hotelling-Lawley 0,00143062 <0,0001 0,64896559 Radice Massima
di Roy
0,00015473 <0,0001 0,40681379
Tabella 4.4.2 MANOVA a una via
Dai risultati si evidenzia che è possibile restringere l’attenzione a due soli fattori, ossia
Tecniche di Testing e Quantità di Fault. Mentre è possibile scartare l’ipotesi che il fattore
software influenzi significativamente la coppia di variabili di risposta che stiamo
analizzando. Traiamo spunto da questa osservazione per approfondire l’analisi di questi
due fattori, cercando di stabilire se anche l’interazione di essi ha un’influenza
statisticamente significativa. Applichiamo quindi MANOVA a due con interazione, per
evitare inutili ripetizioni riportiamo in tabella 4.4.3 solo i risultati dell’interazione tra i
fattori.
Tecniche di Testing &
Quantità di Fault
Lambda di Wilk 0,52834104 Traccia di Pillai 0,46558569 Hotelling-Lawley 0,43484078 Radice Massima di Roy
0,17404031
Tabella 4.4.3 . Manova a a due vie con interazione
Essendo i risultati dei quattro test utilizzati, ricondotti al test di Fisher, tutti superiori al
0.05 dobbiamo rifiutare l’ipotesi di influenza dell’interazione. Possiamo quindi concludere
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
83
che dai test condotti sui dati sperimentali raccolti, i fattori categorici che hanno
un’influenza statisticamente significativa su entrambe le variabili di risposta esaminate
sono: le Tecniche di Testing e la Quantità di Fault.
4.4.1 Analisi delle Variabili Canoniche
Mediante l’analisi delle variabili canoniche (AVC) abbiamo cercato di capire come i vari
livelli dei due fattori indipendenti influenzino le risposte. Si rimanda al paragrafo [§2.5]
per un approfondimento su tale tipo di analisi. I risultati ottenuti mediante AVC sono
riassunti nel diagramma dei centroidi (Grafico 4.4.1). I punti dei centroidi rappresentano i
livelli dei fattori in esame e il cerchio indica l’intervallo di confidenza del 95%. Le linee in
verde indicano le direzioni delle variabili di risposte. I punti più son vicini ad uno dei due
segmenti in verde più è alta l’influenza che essi hanno su quella risposta. Per motivi di
chiarezza nel grafico solitamente non viene riportato il prolungamento del segmento in
verde verso il basso, il quale permette di individuare i fattori che influenzano
negativamente la risposta.
Grafico 4.4.1. Diagramma dei Centroidi Canonici
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
84
Dall’osservazione del Grafico 4.4.1 in primo luogo possiamo notare come per la
Percentuale totale di Fault Rilevati il Robustness testing abbia un effetto non positivo.
Discorso analogo vale per il Detection Rate nel caso di quantità di Fault Bassa. Queste
due prime considerazioni sono state già riscontrate nelle analisi precedenti e vengono
confermate anche dalla AVC. I risultati interessanti riguardano invece innanzitutto il
detection Rate sul quale risultano particolarmente determinanti per un buon risultato: i
livelli di Fault Medio ed Alto, e lo Stress Testing. Il Functional Testing sembra non avere
particolari effetti positivi sul Detection Rate, piuttosto permette di avere buone percentuali
di Fault Rilevati. Infine il risultato sicuramente più interessante riguarda lo Statistical
Testing, il quale influenza entrambi i fattori di risposta, difatti si trova vicino ad entrambi i
segmenti ma non è particolarmente vicino a nessuno dei due. Quindi è l'unico livello dei
fattori esaminati che permette di raggiungere un buon trade-off tra costo ed efficacia.
4.5 Verifica delle Assunzioni
Le tecniche statistiche utilizzate nei paragrafi precedenti, per poter essere applicate,
richiedono la verifica di determinate assunzioni. Nel primo paragrafo sono esposte le
assunzioni per poter applicare ANOVA e MANOVA. Mentre nel secondo paragrafo sono
verificate le assunzioni necessarie per poter applicare il modello di regressione multipla.
Si rimanda ai paragrafi [] [] per un maggiore dettaglio.
4.5.1 Analisi della Varianza Univariata e Multivari ata
L'analisi della varianza univariata e multivariata [§2.2] possono essere applicate se sono
verificate due condizioni:
1. Indipendenza degli esperimenti
2. Omoschedasticità delle varianze dei fattori su cui è applicato il test
La prima condizione è soddisfatta in quanto è stato randomizzato il piano degli
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
85
esperimenti generato con filosofia Design of Experiments. Per la verifica della seconda
condizione sono stati applicati più test. Tale scelta è la più adottata e suggerita in
letteratura, essendo i risultati dei test non sempre affidabili. In particolare i test utilizzati
sono stati: O'Brienn Test, Brown-Forsythe Test, Levene Test, Bartlett Test. Per tutti i test
l'ipotesi nulla è la seguente:
H0: Le varianze dei livelli della variabile in esame sono uguali
In tabella sono riportati i risultati riferiti alle variabili indipendenti: Tecniche di Testing,
Quantità di Fault e Software e alla variabile dipendente Efficienza della detection.
Tabella 4.5.1 Tecniche di Testing Tabella4.5.2 Quantità di Fault Tabella 4.5.3 Software
Per nessuno dei fattori è possibile rifiutare l'ipotesi nulla, dunque è possibile applicare
ANOVA. Si ripete il procedimento considerando come variabile dipendente il Detection
Rate.
Tabella 4.5.4 Tecniche di Testing Tabella4.5.5 Quantità di Fault
Anche in questo caso non è possibile rifiutare l'ipotesi nulla, dunque è lecito utilizzare
ANOVA. Si osservi come il test di Bartlett per la quantità di fault dia esito negativo. Ma
essendo un solo test su quattro a dare tale risultato l'ipotesi nulla non viene rifiutata.
Abbiamo quindi evitato di commettere un errore semplicemente utilizzando 4 test
d'ipotesi.
Utilizzando lo stesso procedimento è stata verificata l’assunzione di varianze omogenee
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
86
anche per l’efficienza per tipo di fault. Le tre tabelle (4.5.6; 4.5.7; 4.5.8) riassumono i
risultati per i tre fattori categorici su cui è stata applicata l’ANOVA.
O’Brien Brown- Forsythe
Levene Bartlett
% Residui Assignment Fault rilevati 0.82 0.76 0.69 0.92
% Residui Checking Fault rilevati 0.65 0.69 0.50 0.61
% Residui Interface Fault Rilevati 0.0.57 0.39 0.49 0.71
% Residui Algorithm Fault Rilevati 0.53 0.69 0.29 0.30
% Residui Function Fault Rilevati 0.13 0.10 0.51
Tabella 4.5.6. Risultati test omogeneità della varianza per Tecniche di testing
O’Brien Brown- Forsythe
Levene Bartlett
% Residui Assignment Fault rilevati 0.99 0.87 0.98 0.99
% Residui Checking Fault rilevati 0.15 0.003 0.13 0.41
% Residui Interface Fault Rilevati 0.37 0.13 0.04 0.43
% Residui Algorithm Fault Rilevati 0.53 0.64 0.30 0.62
% Residui Function Fault Rilevati 0.32 0.76 0.04 0.22
Tabella 4.5.7. Risultati test omogeneità della varianza per Quantità di fauult
O’Brien Brown- Forsythe
Levene Bartlett
% Residui Assignment Fault rilevati 0.34 0.19 0.34 0.29
% Residui Checking Fault rilevati 0.81 0.90 0.79 0.86
% Residui Interface Fault Rilevati 0.91 0.22 0.16
% Residui Algorithm Fault Rilevati 0.21 0.21 0.07 0.01
% Residui Function Fault Rilevati 0.82 0.98 0.98 0.87
Tabella 4.5.8. Risultati test omogeneità della varianza per Software
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
87
Per poter essere applicata l'Analisi della varianza multivariata devono essere soddisfatte le
seguenti assunzioni [§2.2]:
1. Indipendenza degli esperimenti
2. Dimensione degli insiemi di esperimenti non eccessivamente grande o maggiore del
numero di risposte analizzate contemporaneamente ( nel caso in esame: 2 )
3. Dimensione dei vari insiemi di esperimenti simile.
Per la prima osservazione vale ciò che è stato precedentemente detto per l'ANOVA. Le
altre due condizioni sono soddisfatte, in quanto le dimensioni i gruppi su cui sono fatte le
inferenze sono mediamente di 4 elementi. Abbiamo una violazione minima delle
assunzioni e quindi tollerabile.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
88
4.5.2 Modello lineare di regressione multipla
In questo paragrafo saranno verificate le assunzioni fatte sul modelli, essendo già state
fatte le considerazioni sulla bontà degli stessi [§2.3]. Riportiamo innanzitutto le tre
assunzioni necessarie per poter applicare il modello di regressione:
1. Omoschedasticità, ovvero la varianza dell’errore è costante.
2. I residui seguono una distribuzione normale.
3. Incorrelazione tra variabile indipendente e residui.
Per la verifica della prima ipotesi basta analizzare i grafici dei residui sulla risposta del
modello. A tal fine riportiamo i grafici dei residui calcolati per ogni modello, rispetto alla
variabile di riposta selezionata.
Figura 4.5.1 Grafici dei residui
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
89
Osservano i grafici in figura risulta evidente per tutti i modelli i residui delle variabili di
risposta sembrano non far supporre un andamento che precluda l’omoschedasticità.
L'omoschedasticità (dal greco, stessa varianza) è una condizione ideale nella quale si trova
una funzione di dati rappresentabili graficamente come dispersi in maniera abbastanza
omogenea al di sopra od al di sotto di una linea retta [Erto]. Una distribuzione casuale di
valori (X) si dice omoschedastica quando la media dei suoi residui (differenza tra il valore
teorico Y' ricavato dal modello costruito su X ed il valore reale incognito di Y) è pari a
zero e la varianza è costante [4].
Per la verifica della seconda ipotesi, sono stati calcolati i residui rispetto alla risposta dei
Figura 4.5.2 Grafici dei residui
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
90
vari modelli. Per dimostrare che tali valori si disponevano secondo una gaussiana è stato
utilizzato il test di Shapiro-Wilk. In tabella sono riassunti i risultati estrapolati per i vari
modelli, residui e risultati dei test. L’ipotesi nulla che vale per tutte le risposte dei vari
modelli è :
H0 : I Residui della Risposta provengono da una distribuzione Normale
Tipologia di Residui esaminati
p–value Esito
% Residui Assignment Fault rilevati
0,4243 L’ipoetesi nulla NON viene rifiutata, essendo il p-value maggiore di 0,05.
% Residui Checking Fault rilevati
0,9796 L’ipoetesi nulla NON viene rifiutata, essendo il p-value maggiore di 0,05.
% Residui Interface Fault Rilevati
0,7758 L’ipoetesi nulla NON viene rifiutata, essendo il p-value maggiore di 0,05.
% Residui Algorithm Fault Rilevati
0,7714 L’ipoetesi nulla NON viene rifiutata, essendo il p-value maggiore di 0,05.
% Residui Function Fault Rilevati
0,8691 L’ipoetesi nulla NON viene rifiutata, essendo il p-value maggiore di 0,05.
% Totale Fault Rilevati 0,7698 L’ipoetesi nulla NON viene rifiutata, essendo il p-value maggiore di 0,05.
Detection Rate 0,9200 L’ipoetesi nulla NON viene rifiutata, essendo il p-value maggiore di 0,05.
Tabella 4.5.9. Quadro Riassuntivo risultati verifica normalità dei residui
Dai dati in tabella 4.5.9 si evince che per tutti modelli utilizzati i residui associati alla
risposta sono distribuiti normalmente, affermazione che i test eseguiti permettono di fare
con un livello di confidenza del 95%.
Infine per ciò che concerne la verifica della terza ipotesi, ossia incorrelazione tra variabile
indipendente e residui, basta osservare i diagrammi di leverage presentati nei paragrafi
precedenti. Si nota come il regressore scelto, per i fattori selezionati, si adatti bene
all’andamento dei valori dei residui.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
91
Conclusioni
A valle degli esperimenti e delle inferenze statistiche effettuate sui dati nei precedenti
paragrafi, si cercherà di proporre un quadro riassuntivo, che evidenzi le considerazioni più
importati che sono emerse. In questo lavoro di tesi sono state esaminate due aspetti
fondamentali di quattro tecniche di testing: Percentuale di Fault Rilevati e Detection Rate.
Le condizioni in cui è stata fatta questa analisi tengono conto della distribuzione dei fault
sulle varie classi ODC, della quantità di fault presenti ed anche delle tipologie di software,
su cui le tecniche di testing sono state applicate.
In primo luogo, si è cercato di capire quali dei fattori considerati influisse sulle variabili di
risposta. Per ciò che concerne la Percentuale di Fault Rilevati, dall’analisi della varianza si
è ricavato come l’effetto fondamentale fosse associato esclusivamente alle tecniche di
testing, ma dall’analisi sul modello di regressione multipla si evidenzia che anche la
quantità di fault e il software sembrano avere una certa influenza. Questa seconda
osservazione, anche se fatta su un modello di regressione, non può essere né trascurata né
sottovalutata, dunque non è possibile affermare che l’efficienza della detection sia
funzione solamente delle tecniche di testing. Per poter eventualmente smentire o
confermare questa ipotesi sarebbero necessari un numero di esperimenti maggiore. Invece,
un risultato interessante emerso con più chiarezza riguarda il detection Rate. Si è
verificato infatti che quest’ultimo è fortemente influenzato dalla quantità di Fault presenti
nel sistema, e che le tecniche di testing hanno un peso nel migliorarne o peggiorarne
l’andamento. Il fattore tecniche di testing per il detection rate, a quanto emerge dall’analisi
della varianza, sembra comportarsi come un fattore di disturbo. Ossia perturba la risposta,
ma non in maniera calcata come accade per le Quantità di Fault. Soprattutto, ciò che
colpisce per il detection rate riguarda il fatto che la tipologia di Software su cui viene
effettuato il testing non sembri influire sulla risposta. Ciò ci permette di poter
generalizzare i risultati ottenuti, almeno per le tre categorie di software a cui appartengono
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
92
le applicazioni su cui sono stati condotti i test.
Percentuale Totale di Fault Rilevati
Come detto in precedenza, il fattore che più influenza tale risposta sono le tecniche di
testing. Confrontando le medie dei risultati ottenuti per le varie tecniche di testing, ciò che
sicuramente risulta più interessante è il risultato che riguarda il Funciotnal e lo Statistical
testing. Infatti sia sui dati sperimentali che sulle stime dei dati sperimentali, la differenza
tra le percentuali di fault rilevati è minima, e con il test di Tukey è stato confermato essere
frutto del caso ( con un livello di protezione del 95% ). Questo risultato è molto
importante, in quanto lo Statistical testing è una tecnica concepita per diminuire il tempo
di testing, e con questi risultati si evidenzia come ciò non determini un significativo
deterioramento dell’efficienza.
A differenza delle tecniche dimostrative, le tecniche distruttive presentano risultati
peggiori. Questo era prevedibile, in quanto il Robustness e lo Stress testing sono pensati e
progettati non tanto per rilevare il maggior numero di guasti possibile, quanto invece per
rilevare condizioni di errori eccezionali e di comportamento anomalo in condizioni di
sovraccarico (ossia per scovare particolari tipi di fault). Anche se entrambi hanno prodotto
risultati peggiori delle tecniche dimostrative, lo Stress testing ha fatto riscontrare una
percentuale di fault rilevati significativamente differente dal Robustness Testing. Tale
risultato è stato riscontrato sia sui dati sperimentali che sulle stime del modello di
regressione. La causa di questa differenza va cercata nella natura stessa delle due tecniche
di testing, infatti lo Stress testing può essere considerato a metà via, tra una tecnica
dimostrativa e una tecnica distruttiva. Un’altra importante osservazione riguarda
l’efficienza delle varie tecniche sulle varie classi di fault ODC. In particolare dai dati
analizzati è emerso che le tecniche dimostrative hanno una percentuale alta di detection
per le classi Assignment e Algorithm. Mentre le tecniche distruttive presentano una
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
93
efficienza maggiore per le classi Interface e Checking. In particolare il Robustness lavora
bene sulla classe Interface e lo Stress testing sulla classe Checking. Questi risultati
confermano ciò che era possibile intuire dalla natura delle due tipologie di testing. Infatti
le tecniche dimostrative mirano a rilevare una non corretta implementazione di una
funzionalità, nella maggior parte dei casi riguarda una mancata inizializzazione o una
parte di codice non correttamente implementata. Mentre le tecniche distruttive rilevano
una non corretta gestione dei valori limiti di una funzione o una non corretta espressione
di controllo, che può generare delle condizioni di comportamento anomalo. Da questi
risultati si può notare come le tecniche dimostrative (Statistical e Functional Testing) e le
tecniche distruttive (Stress e Robustness Testing) agiscano principalmente su sottoinsiemi
di classi ODC tra di loro ortogonali. Potremmo quindi affermare che: le due tipologie di
testing sono tra loro ortogonali rispetto alle classi di fault ODC obiettivo della detection.
Dall’analisi dell’efficienza per tipo di fault è emerso con chiarezza la conferma che le
tecniche di testing hanno un ruolo chiave. Altro importante risultato riguarda invece la non
influenza della tipologia di Software sull’Efficienza per tipo di fault. Mentre la Quantità
di fault nel caso di Efficienza per Interface e Assignment fault ha un peso sulla risposta.
Queste ultime due considerazioni lette in un’ottica più vasta fanno meglio interpretare
anche i risultati sull’Efficienza Totale. Per la quale non si è potuto individuare se
effettivamente i fattori Quantità di fault e Tipologia di Software fossero influenti
sull’Efficienza. Ciò che è possibile concludere che i fattori Quantità di fault e Tipologia di
Software hanno un effetto marginale sulla Efficienza. In particolare tra i due la Quantità di
fault sembra avere un peso maggiore.
Detection Rate
Dalle analisi fatte sui dati sperimentali e sulle stime ottenute mediante il modello di
regressione multipla è emerso che la Quantità di Fault e le Tecniche di testing sono i
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
94
fattori che maggiormente influenzano il Detection Rate.
La tipologia di software su cui viene effettuato il testing sembra quindi non influenzare il
Detection rate, dunque come già accennato in precedenza questi risultati possono essere
generalizzati. Cioè possono essere assunti validi, almeno per le tre categorie di software a
cui appartengono le applicazioni testate.
Per ciò che concerne la quantità di Fault è abbastanza intuitivo e immediato concludere
che tale legame è conseguenza della definizione stessa di Detection Rate. In quanto il
numero di fault rilevati in un’ora tende ad essere più alto, tanto più alto è il numero di
fault presenti.
Più interessante è stato osservare che le tecniche di testing presentano un detection rate
molto simile tra di loro. Infatti dal test di Tukey non è emersa nessuna differenza
significativa tra le medie stimate dai dati sperimentali. Osservando però i risultati ottenuti
con il modello di regressione multipla, il Robustness testing tenderebbe ad avere un rate
più basso rispetto alle altre tre tecniche. E’ importante sottolineare come fatto anche in
precedenza, che le tecniche di testing sono da considerarsi come un fattore disturbo sulla
risposta, su cui pesa principalmente il fattore Quantità di Fault.
In conclusione il detection rate è principalmente funzione di un fattore che non può essere
controllato direttamente dal tester, e soprattutto le tecniche di testing non permettono di
migliorarne granché il valore. Piuttosto rischiano di abbassare il rate, come accade per il
Robustness che del resto presenta una efficienza molto scarsa.
Con lo studio condotto mediante Analisi delle variabili canoniche, si è cercato di
effettuare una analisi che tenesse in conto di entrambe le risposte e di come i livelli dei
fattori tecniche di testing e quantità di fault influissero sulle risposte. Come riportato nel
diagramma dei centroidi, la conclusione di maggiore interesse riguarda lo Statistical
testing. Infatti essa è l’unica tra le tecniche di testing su cui è stata fatta l’indagine, che
influisce positivamente su entrambe le risposte. Del resto la natura di tale tipologia di
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
95
testing è appunto quello di garantire una buona efficienza, cercando di abbattere i tempi di
testing, ciò naturalmente influisce positivamente sul detection rate e sulla Percentuale di
Fault Rilevati.
Osservando inoltre anche i dati che riguardano l’efficienza per tipi di fault è lecito
concludere che al fine di avere un software più affidabile è opportuno combinare allo
Statistical Testing anche lo Stress Testing. Quest’ultimo infatti oltre a migliorare
l’efficienza per le classi di fault Interface e Checking permette di avere anche un buon
detection rate.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
96
Appendice A
In figura è presente un esempio che permette di capire meglio come interpretare il grafico
a Diamante. Tale tipo di rappresentazione consente di rappresentare graficamente Media,
Percentile a 95% e 5%, Intervallo di confidenza e dimensione del campione su cui sono
calcolate le stime.
Figura A.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
97
Bibliografia
[1] Chillarege, Inderpal S. Bhandari, Jarir K. Chaar, Michael J. Halliday, Diane S.
Moebus, Bonnie K. Ray, and Man-Yuen Wong , . “Orthogonal Defect Classification-A
Concept for In-Process Measurements” 1992
[2] Chillarege,Wei-Lun Kao and Condit “Defect Type and its impact on the Growth
Curve”1991
[3] Basili, Selby “Comparing the Effectiveness of Software Testing Strategies” 1987
[4] Erto P. “Probabilità e statistica per le scienze e l’ingegneria” McGraw-Hill. 2008
[5] Mauro Pezzè and Michal Young “Software Testing and Analysis: Process, Principles
and Techniques” John Wiley & Sons 2008
[6] Hair, J. F., Anderson, R. E., Tatham, R. L., & Black, W. C.. “Multivariate Data
Analysis (5th Edition)” Upper Saddle River, New Jersey: Prentice Hall 1998
[7] J. Musa, “Software Reliability Engineering” McGraw-Hill, 1996.
[8] M.R. Lyu, “Handbook of Software Reliability Engineering. IEEE” Computer Society
Press & McGraw-Hill, 1996.
[9] NIST/SEMATECH, In "e-Handbook of Statistical Methods". NIST/SEMATECH,
http://www.itl.nist.gov/div898/handbook/. 2004
[10] D. Cotroneo, R. Natella, A. Pecchia, S. Russo “An Approach for Assessing Logs by
Software Fault Injection”
[11] Francesca Campana “Scuola di Dottorato: Design of Experiments DOE” 2007
[12] A. Avizienis, J.C. Laprie, B. Randell, and C. Landwehr. “Basic Concepts and
Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and
Secure Computing”, 1(1):11–33, 2004.
[13] L. Lee, R.K Iyer “Software Dependability in the Tandem GUARDIAN” 1995
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
98
[14] H. Madeira, M.Vieira, D. Costa “On the Emolution of Software Fault by Software
Fault Injectoin ”, Proc. Int’l Conf. Dependable Systems and Networks (DSN ‘00),pp. 417-
426, 2000
[15] http://www.testingeducation.org/BBST/Domain.html
[PERRY90] William E. Perry “A standard for testing application software”, 1990
[IEEE90] “IEEE Standard Glossary of Software Engineering Terminology (IEEE Std
610.12-1990), IEEE Computer Soc.” Dec. 10, 1990.
[Beizer90] Boris Beizer “Software Testing Techniques. Second edition.” 1990
[Emulation] Joao A. Duraes and Henrique S. Madeira “Emulation of Software Faults:A
Field Data Study and a Practical Approach” 2006
[Soliani] L. Soliani “e-book: Manuale di Statistica per la Ricerca e la professione” Six-
Sigma 2007
[ebook_stat] http://unipg.it/~onofri/RTutorial/Tutorial/CVA.htm
[JMP_stat] JMP, A Business Unit of SAS “JMP Statistics and Graphics Guide 8.0.1”
2009
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
99
Ringraziamenti
Ore 3.19 a.m. del 9/12/2009 ed anche se stento ancora a crederci domani mi laureo. Questa volta
però definitivamente. Cioè basta! Basta con le giornate in auletta a studiare! Basta scendere alle
8:00 e tornare alle 20:00 a casa (in realtà ho smesso di farlo già da un po’)!! Basta osservare la
sovrabbondante presenza di uomini intorno a me! Basta pentirsi di non essersi iscritto a
giurisprudenza o scienze politiche (a buon intenditor poche parole…)! Basta vagare tra via
claudio, Agnano e Triennio per trovare un posto dove studiare…insomma BASTA! Forse tutto
questo, e non solo, mi macherà, anzi in realtà già mi manca. Ma inizia un altro capitolo della mia
vita che spero possa essere intenso, bello, appassionante e ricco di incontri con persone speciali
come sono stati questi anni all’università.
Le persone da ringraziare sono tante e spero di non dimenticare nessuno. Un grazie particolare è
per Papà, Mamma e la famiglia tutta (nonni, zii e cugini..) che per loro disgrazia mi sopportano da
quando sono nato e ciononostante non mi hanno mai fatto mancare il loro sostegno. Grazie a
Cristina e mio fratello Francesco a cui sono profondamente legato, anche se spesso non lo tratto
come meriterebbe. Un grazie speciale è per Generoso che in questi anni è stato sempre fonte di
saggi consigli.
Grazie al prof. Stefano Russo, mio relatore per la tesi, e all’ing. Roberto Pietrantuono per la
pazienza e per avermi dato la possibilità di realizzare un lavoro che mi ha coinvolto ed
appassionato. Grazie agli amici di Pastorano Street: Annarita, Luigi, Fiore (o’sbirr), Alessandro
Luca (DOF) e Marco(P10), che ho conosciuto praticamente in fasce e con i quali ho condiviso i
momenti più difficili e più intensi della mia vita. Un grazie è d’obbligo “all’allegra brigata” di
ragazzi dell’Ideatletica Aurora. In particolare a Gianni, Mario e Luigi va un ringraziamento per
tutte le risate che mi avete regalato e che porterò sempre nel cuore. Grazie allo strano e variegato
gruppo di studio con cui ho condiviso la mia carriera universitaria. Le partite di calcio durante
Elementi di Informatica sono sempre state le mie preferite.
Valutazione sperimentale di tecniche di testing per software
In relazione ai tipi di fault
100
Grazie a tutti i ragazzi che in questi anni ho conosciuto al PensioNIGHT: Nandolone, o’Galluzz,
Freda, Star, Forestiero, Peppe Tip Tip, Giggino, Umbi, Roberto, Ciro, I fantastici 4 della
quadrupla etc. Avendo nominato il pensionato non posso non ringraziare tutte le ragazze di casa
Borghese (in particolare Gilda perché a cummanne prorie esse !!), le ragazze del Bed, lo storico
appartamento di medicina con Mariantò, Emiliana (Valeria non mi son dimenticato di te…),
Alessandra etc… che in questi anni mi hanno più volte salvato dal triste panino o dalla pizza da
Gianluca offrendo succulenti pasti caldi pieni di affetto. Però il mio grazie non è solo per i pasti,
ma soprattutto per la compagnia e l’affetto che mi dimostrate.
Grazie ad Alessandra (o Alessia) perché nonostante i repentini sbalzi d’umore è un’amica fidata e
sincera.
Grazie al dott. Fasolino che per me è un amico fondamentale, che mi auguro di avere sempre al
mio fianco ( nonostante le fedi calcistiche diverse…anzi direi opposte ).
Quindi mi sembra di non aver dimenticato nessuno…………………………………….scherzo!!!!
Manca una persona importantissima in questi ringraziamenti. La persona tramite cui ho scoperto
un modo diverso di vivere il rapporto di amicizia, che ti permette di stare difronte ogni situazione
senza esserne intimorito. Perché oramai sono certo che c’è Qualcuno con me e non mi Lascerà
mai. Grazie Danilo.
Un ultimo pensiero va a delle persone che non ci son più Chiara, Paolo e nonna Francesca. Sono
sicuro che da lassù mi state guardando. Vi porto e vi porterò sempre nel cuore. Grazie.