Valutazione sperimentale di tecniche di testing per ... · Una modalità per approfondire tale...

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).



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



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.



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



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



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



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



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



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



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:



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.



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.



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



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σ

σ



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à:



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



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



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



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



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.



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:



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



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:



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



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:



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.



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.



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à



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



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].



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ù



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.



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 è



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



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:



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



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



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,



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



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



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 )


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.



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.



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



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



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 %



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




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




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.



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



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.



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



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.




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



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.


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.



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 è



64

nessuna dipendenza significativa tra il Detection Rate e le variabili indipendenti continue.


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



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



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.


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.



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



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%



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



70


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



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.


effetti. Innanzitutto enunciamo l’ipotesi nulla :



esame.



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.


effetti. Innanzitutto enunciamo l’ipotesi nulla:



73



esame.

Figura 4.3.7 . Grafici Leverage degli Effetti per Interface 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






esame.

Figura 4.3.8 . Grafici Leverage degli Effetti per Algorithm 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





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



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



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



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



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



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.



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,



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



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



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



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



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


Levene Bartlett



% Residui Interface Fault Rilevati 0.37 0.13 0.04 0.43


% 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


Levene Bartlett



% Residui Interface Fault Rilevati 0.91 0.22 0.16


% Residui Function Fault Rilevati 0.82 0.98 0.98 0.87

Tabella 4.5.8. Risultati test omogeneità della varianza per Software



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.



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



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



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


% Residui Interface Fault Rilevati


% Residui Algorithm Fault Rilevati


% Residui Function Fault Rilevati


% 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.



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



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



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



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



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.



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.



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



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



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.



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.

Date post:	11-Jul-2020
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

Valutazione sperimentale di tecniche di testing per ... · Una modalità per approfondire tale...

Documents