PrimaParte 3 PDF

Ingegneria del Software
(Ing.Informatica Nuovo Ord.)

Canale M-Z / A.A. 2005-06
Marco Cadoli
Universit di Roma La Sapienza
Dipartimento di Informatica e Sistemistica
www.dis.uniroma1.it/~cadoli
PRIMA PARTE
Il processo di produzione del SW

Sezione III: Test del Software
Versione definitiva
Ing. del SW: Prima parte Sez III
Marco Cadoli, Universit La Sapienza, ott 2005
PRIMA PARTE
Il processo di produzione del software
I.
II.
III.
IV.
Introduzione, ciclo di vita del SW

Qualit, standard
Test del SW
Project Management
III. Test del Software

III.1. Concetti fondamentali del test
III.2. Test che non utilizza il calcolatore
III.3. Test a scatola bianca
III.4. Test a scatola nera
III.5. Strategie di test
III.6. Debugging
III.1. Concetti fondamentali del test
Un esempio per iniziare

Definizione di test
Princpi fondamentali del test
Progettare il software pensando al test
Esempio di un programma da testare

Un programma Java:
legge dal file dati.txt tre interi,
corrispondenti ai lati di un triangolo
stampa sullo schermo linformazione se il
triangolo :
scaleno,
isoscele, o
equilatero
SCRIVERE ALCUNI FILE DI INPUT PER TESTARLO
// File Triangolo.java
import java.io.*;
public class Triangolo {
public static void main (String[] args) throws IOException {
String nome_file = "dati.txt";
FileInputStream istream = new FileInputStream(nome_file);
BufferedInputStream bis = new BufferedInputStream(istream);
int primo = InOut.readInt(bis), secondo = InOut.readInt(bis),
terzo = InOut.readInt(bis);
bis.close();
System.out.println("Triangolo di lati: "+primo+' '+secondo+' '+terzo);
if (primo == secondo && secondo == terzo)
System.out.println("Equilatero");
else if (primo == secondo || secondo == terzo || primo == terzo)
System.out.println("Isoscele");
else
System.out.println("Scaleno");
}
}
Avete considerato anche ?

1. un test con un triangolo scaleno valido (2,5,10 non
va bene)
2. un test con un trangolo equilatero valido
3. un test con un triangolo isoscele valido (2,2,4 non
va bene)
4. un test con le tre permutazioni dei lati di un
triangolo isoscele (3,3,4 / 3,4,3 / 4,3,3)
5. un lato di lunghezza pari a 0
6. un lato di lunghezza negativa
7. tre interi maggiori di zero di cui uno uguale alla
somma degli altri due (1,2,3)
8. permutazioni del caso 7 (1,2,3 / 1,3,2 / 3,1,2)
Avete considerato anche ? (2)

9. tre interi di cui uno minore della somma degli
altri 2 (2,5,10)
10. le tre permutazioni del caso 9
11. tre zeri
12. un lato reale
13. due lati come input
14. file non esistente o non leggibile
15. per ogni test avete indicato loutput previsto?
Risultati
Secondo Myers [1979], sulla base dei casi ottenuti
sottoponendo il problema a programmatori
esperti, la media delle risposte affermative alle
domande precedenti inferiore a 8 (su 15).
Il test, anche di un programma banale, non
unattivit banale.
Esercizio 1
Casi di test
Caso
File input Output previsto
1
2
3
4
5
6
7
8
9
10
000
-2 3 3
555
757
10 4 2
-2 2 3
VUOTO
23
5.16 5.26 5.2
A34
errore
numero negativo
equilatero
isoscele
non triangolo
errore su isoscele
errore di formato
solo due interi
reali, non interi
errore di formato
Con riferimento ad ognuna delle 15 domande precedenti, dire se fra i 10

file riportati sopra ce n qualcuno che permette di rispondere
affermativamente
10
Limiti del test

Lattivit di test non pu dimostrare lassenza di
errori nel sw.
Esempio: programma per la classificazione di
triangoli.
Possibili input: file con tre interi (insufficiente: non
copre tutti i casi interessanti!)
Numero dei possibili input: per interi a 32 bit
296 possibili input
Tempo necessario a considerarli tutti:
per 1M test/secondo (sovrastimato!)
276 secondi 251 anni
11
Difetti, errori e malfunzionamenti

Il difetto una caratteristica fisica di una porzione
di codice o di una sezione di un testo di
documentazione
Lerrore l'azione umana che ha generato il difetto
Il malfunzionamento la conseguenza di un difetto
che si manifesta durante lutilizzo del prodotto
software
12
Definizione di test
Le revisioni e le altre attivit di verifica della
qualit tipicamente sono in grado di rilevare errori,
ma non sono sufficienti
Il rilevamento degli errori costa tipicamente il 3040% del totale di un progetto (ma la percentuale
pu essere molto maggiore)
Il test il processo di utilizzo di un programma
con lo specifico intento di trovare errori prima
della consegna allutente finale
13
Obiettivo generale del test

Lobiettivo dellattivit di test la progettazione ed
esecuzione di casi di test capaci di scoprire errori:
z di vario tipo
z sistematicamente
z nel minor tempo possibile
z nella maniera pi efficiente possibile
Il test non ha come obiettivo dimostrare lassenza di
difetti.
14
Aspetti psicologici del test

z
Dal punto di vista psicologico, si tratta di una fase

distruttiva (tutte le altre fasi, ad es., la progettazione,
sono costruttive):
1. Il test consiste nellesecuzione di un programma al fine

di scoprire errori
2. Un caso di test di buona qualit se ha una elevata
probabilit di scoprire un errore ancora non scoperto
3. Un test ha avuto successo se ha scoperto errori prima
ignoti
15
Princpi fondamentali del test
Una componente necessaria di un caso di test la

definizione delloutput (o risultato) atteso prima
dellesecuzione
Locchio vede ci che vuole vedere
Un programmatore non dovrebbe testare i propri
programmi
1. Aspetti psicologici: difficolt nel trovare errori nel
proprio lavoro, processo distruttivo,
2. Incomprensioni del problema
NOTA: non si applica al debugging
16
Princpi fondamentali del test (2)
Unorganizzazione (ad es., un settore di unazienda)

non dovrebbe testare i programmi da lei prodotti
Dal punto di vista psicologico, con il test interno

sembra decrescere la probabilit di rispettare
scadenze, obiettivi, costi,
Le attivit di test andrebbero condotte da terze

parti
I risultati di un test vanno analizzati in maniera

dettagliata
17
I casi di test vanno definiti:

Per condizioni non valide e inattese
Per condizioni valide ed attese
Il test deve verificare se un programma:

Non fa ci che dovrebbe fare
Fa ci che non dovrebbe fare
18
Evitare casi di test usa e getta

Si perde un investimento
Si costretti a reinventare i casi di test
Di conseguenza, spesso i test sulla versione
successiva del codice non sono rigorosi come i
precedenti
Il test non va pianificato con lassunzione tacita che
non verranno trovati errori
I test vanno pianificati con largo anticipo (ad es.,
quando i requisiti sono pronti)
19

La probabilit di esistenza di errori in una parte di
programma cresce col numero di errori gi trovati.
Probabilit di
trovare altri errori
Numero di errori trovati
Gli errori tendono a raggrupparsi in alcune sezioni

del codice (principio di Pareto: l80% degli errori
riconducibile al 20% dei moduli)
20
Ogni caso di test va ricondotto ai requisiti

dellutente
Le attivit di test devono:

partire dallanalisi delle singole funzioni
proseguire coinvolgendo lintera struttura del
progetto
21
Il test esaustivo impossibile il test unattivit

creativa ed intellettualmente stimolante.
Alcune regole empiriche:
Un buon caso di test non ridondante rispetto a
quelli precedenti (si rischia di perdere tempo e
risorse)
importante determinare categorie di casi
Un buon caso di test non n troppo semplice n
troppo complesso
22
Progettare il SW pensando alla fase di test

Collaudabilit (testabilit): facilit con cui il SW pu
essere testato.
Dipende da alcune caratteristiche del SW, fra cui:
Osservabilit: i risultati di ogni test possono essere direttamente
osservati (ad es., si possono ispezionare stati interni e variabili,
il codice sorgente accessibile, )
Controllabilit: grado con cui il test pu essere automatizzato
ed ottimizzato (ad es., i formati di I/O sono coerenti e strutturati,
le variabili possono essere ispezionate durante lesecuzione, )
Scomponibilit: grado di modularizzazione (i moduli sono
indipendenti tra loro e possono essere testati indipendentemente)
23
Progettare il SW pensando al test (2)

Semplicit:
esistono solo le funzioni necessarie
vengono adottati standard di codifica
larchitettura modulare
Stabilit: i cambiamenti
avvengono in numero ridotto
non inficiano test gi svolti
Comprensibilit:
del progetto,
delle relazioni tra moduli,
della documentazione

24
III.2. Test che non utilizza il

calcolatore
Ispezioni e walkthrough
Errori comuni
25
Test umano
Le tecniche di test umano (o di analisi statica)
non fanno uso del calcolatore
Queste tecniche non sono sostitutive del test al
calcolatore, e vanno utilizzate nel lasso di tempo che
intercorre:
fra la fine della codifica e
linizio del test al calcolatore
Lesperienza mostra che le tecniche di test umano

sono molto efficaci nel trovare errori:
Prima vengono trovati gli errori, minore il costo della
loro correzione
Sembra non intervenire laspetto psicologico negativo
(non viene percepita come attivit distruttiva). Vedi
extreme programming
26
Ispezioni e walkthrough
il prodotto oggetto di controllo viene esaminato da un gruppo di

persone (3-5), fra cui lautore
le singole persone hanno (tipicamente) visionato il prodotto

prima di incontrarsi in gruppo
il programmatore commenta, linea per linea, la logica del

programma
vengono individuati alcuni insiemi significativi di valori di input

al prodotto
a fronte di ciascun insieme viene simulata lesecuzione del

prodotto
lobiettivo deve essere trovare gli errori, non correggerli (testing,

not debugging)
27
Errori comuni
Durante il processo di ispezione viene tipicamente
usata una lista di errori pi comuni.
La lista non deve comprendere aspetti dello stile di
programmazione (ad es., ci sono abbastanza
commenti?).
Presentiamo una lista (da [Myers 1979]) che
propone una classificazione di errori indipendente
dal linguaggio di programmazione (alcuni tipi di
errori potrebbero non essere significativi in Java,
ma esserlo in altri linguaggi, ad es., il C).
28
Errori comuni (2)

Errori di riferimento ai dati:
Ci si riferisce ad una variabile non inizializzata?
Nel caso di array o stringhe, ogni indice compreso nei
limiti della dimensione corrispondente?
Ci sono errori di off by one?
Per i riferimenti attraverso puntatore/riferimento, la
corrispondente area di memoria stata allocata (dangling
reference problem)?
Una variabile (eventualmente riferita tramite puntatore) ha
tipo diverso da quello previsto dal programma?
Esistono variabili con nome simile (pratica pericolosa)?
29
Errori comuni (3)

Errori di calcolo:
I calcoli coinvolgono tipi inconsistenti (ad es., stringhe e
interi)?
Esistono delle inconsistenze nei calcoli misti (ad es., interi
e reali)?
Esistono dei calcoli che coinvolgono tipi compatibili ma di
precisione differente?
In unassegnazione, il valore sinistro ha rappresentazione
meno precisa del valore destro?
possibile una condizione di overflow o underflow (ad
esempio nei calcoli intermedi)?
C qualche divisione per zero?
30
Errori comuni (4)

Errori di calcolo (continua):
Nelle espressioni che contengono vari operatori aritmetici,
le assunzioni sullordine di valutazione e di precedenza
degli operatori sono corrette?
Il valore di una variabile esce dallintervallo ragionevole?
(ad es., il peso dovrebbe essere positivo, )
Ci sono usi sbagliati dellaritmetica fra interi, in particolare
delle divisioni?
Stiamo prendendo in considerazione adeguatamente la
precisione finita dei reali?
31
Errori comuni (5)

Errori di confronto:
Ci sono confronti fra variabili di diverso tipo?
Gli operatori di confronto sono usati correttamente?
(ad es., <= al posto di < )
Le espressioni booleane sono corrette (uso appropriato di and, or,
not)?
Nelle espressioni che contengono vari operatori booleani, le
assunzioni sullordine di valutazione e di precedenza degli
operatori sono corrette?
Gli operandi di unespressione booleana sono booleani?
(ad es., 5 < x < 10 scorretta)
La maniera in cui viene valutata lespressione booleana ha impatto
sul significato dellespressione stessa (pratica pericolosa)?
32
Errori comuni (6)

Errori di controllo: (spesso dipendono da errori
nellalgoritmo)
I cicli terminano?
Le funzioni/procedure terminano?
possibile che, a causa delle condizioni di ingresso, un
ciclo non venga mai eseguito?
Le condizioni di uscita dal ciclo sono corrette?
Ci sono errori di off by one (ciclo eseguito una volta in
pi o una volta in meno)?
Esistono delle decisioni non esaustive (ad es., in
unistruzione switch)?
33
Errori comuni (7)

Errori di interfaccia:
Il numero e lordine dei parametri attuali corrisponde a
quello dei parametri formali?
Le assunzioni sulla conversione di tipo fra parametri attuali
e formali sono corrette?
La modalit di passaggio
riferimento) corretta?
dei
parametri
(valore,
Un parametro che si pensa essere di ingresso viene

modificato?
Le unit di misura dei moduli interagenti sono coerenti (ad
es., metri e yard)?
34
Errori comuni (8)

Errori di I/O:
La lettura da file avviene rispettando il formato?
I file vengono aperti con la modalit (lettura/scrittura)
giusta?
Le condizioni di EOF vengono gestite nella maniera
giusta?
Il programma stampa del testo in cui ci sono errori
ortografici o sintattici?
35
Errori comuni (9)

Altri controlli:
Esistono delle variabili dichiarate ma che non vengono
usate, o che vengono usate solamente una volta?
Ci sono errori di battitura?
Se il programma stato compilato con successo, ma il
compilatore ha segnalato dei warning, questi sono stati
presi adeguatamente in considerazione?
Il programma sufficientemente robusto? Controlla la
validit dellinput?
Sono presenti tutte le funzionalit previste per il
programma?
36
III.3. Test a scatola bianca
Progettazione dei casi di test

Test a scatola bianca: caratteristiche generali
Copertura delle istruzioni
Copertura delle decisioni
Copertura delle condizioni
Copertura delle decisioni e delle condizioni
Copertura di una base di cammini indipendenti
37

Quando si progettano i casi di test per lesecuzione da
parte del calcolatore (ad esempio secondo la
metodologia del test a scatola bianca), gli obiettivi
da raggiungere sono (in generale) i seguenti:
Evidenziare un numero prefissato di difetti
minimizzando il costo
Utilizzare al meglio un budget prefissato
Cercare il minimo della funzione globale del costo
38
Articolazione del processo di test

1. Progettazione e pianificazione dei casi di test
a) Progettazione delle condizioni di test: individuare, tra tutte le
possibili situazioni che si possono presentare durante lutilizzo del
prodotto, le sole che si intende riprodurre nel test;
b) Individuazione dei casi di test: individuare, per ogni condizione
di test e per ciascun dato di input, linsieme dei valori di tale dato
(classe di equivalenza) che rendono vera la condizione;
c) Scelta dei valori di input: scegliere per ciascun caso di test (o
classe di casi di test equivalenti) uno specifico valore per ciascun
dato di input.
2. Esecuzione del programma per ciascun caso di test e

registrazione del comportamento del prodotto
3. Confronto tra il comportamento atteso e quello reale
39
Test a scatola bianca:

caratteristiche generali
Viene chiamato anche:
test a scatola trasparente (white box/glass box

testing)
test strutturale (contrapposto a funzionale)
Sfrutta la struttura del controllo (ovvero il grafo di
controllo o di flusso) dei programmi per ricavare i casi
di prova
Viene (tipicamente, ma non sempre) svolto durante la
fase di codifica
40
Test a scatola bianca:

caratteristiche generali (2)
Permette il test di parti del programma (a
differenza del test a scatola nera)
Permette di coprire sistematicamente ogni parte
del programma (spesso gli errori sono presenti nei
casi particolari)
Esistono strumenti automatici (instrumenters), che
consentono di valutare la copertura del codice
durante lesecuzione
41
Tipologie di test a scatola bianca

Copertura delle decisioni e delle condizioni
Copertura tramite cammini nel grafo di controllo
42

il criterio pi semplice (necessario ma non
sufficiente) per un test a scatola bianca ragionevole
Obiettivo: individuare un insieme di casi di test

sufficiente a far eseguire almeno una volta tutte le
istruzioni
43
Copertura delle istruzioni (2)

Esempio Java 1:
A
/*A*/ float x = InOut.readFloat(),

y = InOut.readFloat();
/*B*/ if (x != 0)
/*C*/ y += 10;
/*D*/ y = y/x;
/*E*/ System.out.println(x + + y);
Il caso di test
{x = 7; y = 9}
(in generale,
{x != 0; y = qualsiasi})
copre le istruzioni
x == 0
x != 0
C
Grafo di controllo
per lesempio
44
Copertura delle istruzioni (3)

Potenziale problema:
Anche nel caso di programmi senza cicli, lesecuzione
di ogni istruzione non garantisce che nel programma
vengano eseguiti tutti i cammini possibili
Esempio di una potenziale conseguenza negativa:
Nel programma Java visto in precedenza, non viene
rilevato lerrore di divisione per zero (istruzione D)
45

Include propriamente la copertura delle istruzioni
Non vero il viceversa
Si focalizza sul fatto che necessario prendere in
considerazione tutte le possibili decisioni nellambito
di un programma
Le decisioni sono presenti nelle istruzioni if,
switch, while, for, do
sufficiente a garantire che ciascuna decisione
assuma il valore vero almeno una volta e il valore
falso almeno una volta.
46
Copertura delle decisioni (2)

Esempio Java 1:
/*A*/ float x = InOut.readFloat(),
y = InOut.readFloat();
/*B*/ if (x != 0)
/*C*/ y += 10;
/*D*/ y = y/x;
/*E*/ System.out.println(x + ' ' + y);
A
B
x == 0
I casi di test
1. {x=20; y=30}
2. {x=0; y=30}
coprono le decisioni (e quindi le istruzioni).
Il secondo scopre lerrore di divisione per 0 in D
x != 0
C
47

Potenziale problema:
Se le decisioni sono composte da varie condizioni
(AND, OR), la copertura delle decisioni pu rivelarsi
insufficiente
Esempio Java 2:
/*A*/ float z = InOut.readFloat(),
w = InOut.readFloat();
t = InOut.readFloat();
/*B*/ if (z == 0 || w > 0)
/*C*/ w = w/z;
/*D*/ else w = w + 2/t;
/*E*/ System.out.println(z+' '+w+' '+t);
Come si manifesta
il problema in
questo esempio?
48

I casi di test:
C2: {t = 0; z= 5 ; w= 5} decisione TRUE
C4: {t = 0; z= 5 ; w= -5} decisione FALSE
coprono le decisioni,
il secondo scopre la divisione per 0 in D, ma
non viene scoperto il rischio di divisione per 0 in C
necessario un criterio che prenda in considerazione

la struttura e le componenti delle decisioni
49

Non include propriamente la copertura delle decisioni
Non inclusa propriamente dalla copertura delle decisioni
Si focalizza sul fatto che necessario prendere in
considerazione tutte le possibili condizioni nellambito di ogni
decisione presa dal programma
Le condizioni sono gli operandi delle espressioni booleane
non atomiche

sufficiente a garantire che ciascuna condizione
(espressione booleana atomica) che appare nelle
decisioni assuma il valore vero almeno una volta e il
valore falso almeno una volta
50
Copertura delle condizioni (2)

Esempio Java 2:
/*B*/ if (z == 0 || w > 0)
/*C*/ w = w/z;
/*D*/ else w = w + 2/t;
Questi casi di test

evidenziano un
problema.
Quale?
I casi di test
C3: {t=0;z=0;w=-5} 1a c.=T, 2a c.=F
C2: {t=0;z=5;w= 5} 1a c.=F, 2a c.=T
coprono le condizioni
51
Copertura delle condizioni (3)

I casi di test
C3: {t=0;z=0;w=-5} 1a condizione=T, 2a condizione=F
C2: {t=0;z=5;w= 5} 1a condizione=F, 2a condizione=T
coprono le condizioni,
il primo scopre la divisione per 0 in C, ma
non viene scoperto il rischio di divisione per 0 in D, in
quanto D non viene mai attraversato. Infatti, viene
sempre presa la decisione TRUE
necessario prendere in considerazione
sia le decisioni sia le condizioni
52
Copertura delle decisioni e delle

condizioni
Include propriamente:
sia la copertura delle decisioni
sia la copertura delle condizioni
sufficiente a garantire che:
ciascuna decisione assuma il valore vero almeno una
volta e il valore falso almeno una volta
ciascuna condizione che appare nelle condizioni
assuma il valore vero almeno una volta e il valore
falso almeno una volta
53
Copertura delle decisioni e delle condizioni (2)

Esempio Java 2:
/*B*/ if (z == 0 || w > 0)
/*C*/ w = w/z;
/*D*/ else w = w + 2/t;
I casi di test
C1: {t=0;z=0;w=5} 1a c.=T, 2a c.=T, dec.=T
C4: {t=0;z=5;w=-5} 1a c.=F, 2a c.=F, dec.=F
coprono le decisioni e le condizioni e scoprono le
divisioni per 0 in C e in D
54
Riassunto dei vari casi di test per

lesempio Java 2
Caso
di
test
C1
SI
NO
C2
NO
NO
C3
-5
SI
NO
C4
-5
NO
SI
cond. cond. decis. trova trova

1
2
err. err.
in C in D
55
Casi di test e criteri di copertura

Criterio di
copertura
Trova
errore in C
Trova
errore in D
Decisioni
Casi di test
che lo
soddisfano
C2 + C4
NO
SI
Condizioni
C2 + C3
SI
NO
SI
SI
Decisioni & C1 + C4,

condizioni
oppure
C2 + C3 +
C4
56
Problema metodologico
In generale esistono varie combinazioni di casi di
test che garantiscono la copertura delle decisioni e
delle condizioni, ma non sempre semplice trovarne
una.
Abbiamo bisogno di un metodo semplice ed
efficace per trovare una copertura delle decisioni
e delle condizioni
57
Copertura tramite cammini nel grafo

di controllo
Si basa su:
criterio della copertura delle decisioni e delle
condizioni
grafo di controllo del programma
Obiettivo: fornire un metodo semplice per garantire

la copertura delle decisioni e delle condizioni
58
Grafo di controllo: riassunto

nodi predicato
arco
A
nodo
B
D
C
E
F
regione
while (A) {
if (B) { C }
else { D }
E
}
F;
Esempio:
V(G) = 7 - 6 + 2 = 3
V(G) = 3
Numero ciclomatico (o complessit ciclomatica)

V(G) = E - N + 2 (E = numero di archi, N = numero di nodi)
V(G) = R
(R = numero di regioni connesse, solo per grafi planari)
59
Grafo di controllo: riassunto (2)
until
sequenza
istruzioni
if semplice
while
case
60
Insufficienza del grafo di controllo

senza rappresentazione delle condizioni
Esempio Java 2:
/*B*/ if (z == 0 || w > 0)
/*C*/ w = w/z;
/*D*/ else w = w + 2/t;
False
True
C
D
E
necessaria una rappresentazione

pi dettagliata del grafo di controllo
del programma
61
Grafo di controllo nel caso di decisioni

composte
if (a && b)
x;
else y;
if (a || b)
x;
else y;
a==F
b==F b
...
...
b==T
x
a==T
a==T
...
b==T
a==F
b==F
y
x
...
62
Grafo di controllo per il programma

Esempio Java 2:
/*B*/
/*C*/
/*D*/
/*E*/
if (z == 0 || w > 0)
w = w/z;
else w = w + 2/t;
System.out.println(z+' '+w+' '+t);
False
Grafo senza rappresentazione

delle condizioni
== 0
<= 0 w > 0
True
C
!= 0
Grafo con rappresentazione

delle condizioni
63
Grafo di controllo, condizioni e

decisioni
Con riferimento al grafo di controllo cos
arricchito, i valori booleani (true o false) per le
condizioni e le decisioni corrispondono a
determinati archi.
Possiamo quindi affermare che scegliere un
insieme di casi di test tali che tutti gli archi del
grafo di controllo vengano percorsi implica la
copertura delle condizioni e delle decisioni
64
Cammini nel grafo di controllo
Una maniera per raggiungere il risultato si basa

sulla scelta di un insieme di casi di test che
corrispondano ad un insieme di cammini nel
grafo di controllo tali che tutti gli archi vengano
percorsi almeno una volta.
Il numero di cammini sufficienti a ricoprire tutti

gli archi sempre inferiore o uguale alla
complessit ciclomatica.
65
Lesempio visto in precedenza

Esempio Java 2:
/*B*/ if (z == 0 || w > 0)
/*C*/ w = w/z;
/*D*/ else w = w + 2/t;
I tre casi di test
C2. {t=0; z=5; w= 5}
C3. {t=0; z=0; w= -5}
C4. {t=0; z=5; w=-5}
coprono tutti gli archi
(e quindi le decisioni e condizioni)
A
z
!= 0
== 0
<= 0 w > 0
C
D
E
V=8-7+2=3
I tre cammini ricoprenti
1. A-z-w-C-E (C2)
2. A-z-C-E
(C3)
3. A-z-w-D-E (C4)
66
Scelta dei cammini
Una buona regola empirica prevede di scegliere

un numero di cammini pari alla complessit
ciclomatica
Infatti, in questo modo si ha la proporzionalit

del numero di casi di test alla complessit
strutturale del codice (sperimentalmente, si
notato che il numero di errori cresce con la
complessit ciclomatica)
67
Base di cammini linearmente

indipendenti
Un buon criterio di scelta dei cammini [McCabe]

si basa sul concetto di indipendenza lineare
Un insieme massimale di cammini linearmente
indipendenti si dice base (non unico!)
Una base contiene un numero di cammini pari
alla complessit ciclomatica
Intuitivamente, ogni cammino ingresso-uscita
pu essere ottenuto come una combinazione
lineare dei cammini di una base
Scegliere una base garantisce un certo grado di
robustezza rispetto a coppie di errori che si
annullano a vicenda
68
Esempio di base di cammini

A
B
2
7
D
4
C
5
E
while (A) {
if (B) { C }
else { D }
E
}
F;
Archi/
cammini
Cammini
. A-F
. A-B-D-E-A-F
. A-B-C-E-A-F
La matrice ha
rango 3 (il
massimo)
{ } una
base
69
Esercizio
A
B
2
7
D
4
C
5
E
while (A) {
if (B) { C }
else { D }
E
}
F;
{ 2} una
base?
Cammini
. A-F
. A-B-D-E-A-F
2. A-B-D-E-A-B-D-E-A-F
70
Considerazioni sulla base di cammini
A
B
2
7
D
4
C
5
E
F
Ogni cammino corrisponde ad un vettore

riga binario (di 0/1) nella matrice di
incidenza archi/cammini
Non vero il viceversa
Una matrice che rappresenta cammini ha
al pi 2E righe distinte (E = n archi)
McCabe ha dimostrato che per ogni grafo G:
1. il rango di una matrice di cammini non pu
essere superiore a V(G) (compl. ciclomatica)
2. esiste sempre una matrice di cammini con
rango pari a V(G)
Una base un qualsiasi insieme di righe
(cammini) con rango massimo
71
Esempio di calcolo della base di cammini

Esempio Java 3:
/*1*/ if (x!=0)
/*2*/
y = 5;
else
/*3*/
z -= x;
/*4*/ if (z > 1)
/*5*/
z = z/x;
else
/*6*/
z = 0;
/*7*/ // nop
IN
x!=0
x==0
V(G) = 3
3
4
z>1
z<=1
{C1,C2,C3}
una base di
cammini
linearmente
indipendenti
6
7
OUT
Archi/
cammini
1-2 1-3 2-4 3-4 4-5 4-6 5-7 6-7
C1
C1
C2
C2
C3
C3
72
Limitazioni del metodo

della base di cammini
Il programma dellesempio Java 3 contiene un
errore (divisione per zero nellistruzione 5), che
pu verificarsi solo se il primo if (riga 1) viene
valutato a false, ovvero se stato eseguito il
cammino C4: 1-3-4-5-7, che non fa parte della base
scelta.
Va comunque ricordato che il numero di cammini
pu essere esponenziale nel numero delle
istruzioni.
Il metodo della base dei cammini indipendenti
rappresenta un ragionevole compromesso fra
laccuratezza e lefficienza del test a scatola bianca
73
Esercizio
Con riferimento allesempio Java 3:
Trovare tutte le basi di cammini linearmente
indipendenti
Per ogni base trovata, determinare casi di test
corrispondenti ai cammini relativi, specificando per
ognuno di essi linput e loutput
74
Riassunto della metodologia basata sui

cammini
1. Dato un programma P, costruire il corrispondente
grafo di controllo G, specificando ogni
condizione
2. Scegliere un insieme M di cammini su G tale che
formi una base
3. Per ogni cammino di M, determinare un caso di
test che lo eserciti, specificando anche loutput
atteso
4. Fare eseguire il programma su ogni caso di test,
verificando se loutput quello atteso
NOTA: non sempre il passo 3 fattibile, perch
alcuni cammini potrebbero essere non percorribili
75
Un cammino non percorribile

1
v.length <= 0
2
v.length > 0
i < v.length
i >= v.length
/*1*/ int[] v = ...;

int i = 0;
/*2*/ if (v.length > 0)
/*3*/
while (i < v.length)
/*4*/
i++;
/*5*/ System.out.println(i);
Cammini di una base:

C1:1-2-5:
percorribile con v = {};
C2:1-2-3-4-3-5: percorribile con v = { 2 };
C3:1-2-3-5:
non percorribile
76
Alcune considerazioni sul test a scatola

bianca
Il metodo della copertura dei cammini di una base
non prevede necessariamente molte iterazioni nei
cicli
Se vogliamo iterazioni nei cammini il numero di casi
di test cresce esponenzialmente, ed il problema
diventa intrattabile in pratica
Occorre quindi effettuare delle scelte sul tipo di
iterazione
77
Possibili limitazioni nelliterazione

1. limitare il numero delle iterazioni dei cicli ad n (ncopertura dei cicli)
2. eseguire solo alcuni cicli
3. limitare il numero dei cammini da esplorare tramite pesi
sugli archi e funzioni da massimizzare
probabilit di esecuzione
occupazione di risorse (memoria/tempo)
4. limitare il numero dei cammini individuando i cammini

che definiscono ed usano le variabili del programma (Data
Flow Testing)
definizione del valore di una variabile

uso di tale valore in un test
78
Data Flow Testing

B
...
A
B
C
D
E
F
G
H
I
....
int x,y,a,b;
scanf(%d %d,&x, &y);
a=x;
b=y
while (a!=b)
if(a>b)
a=a-b;
else b=b-a;
printf(%d,a);
C
D
E
a==b
a!=b
a>b
G
a<=b
H
Per x ed y non occorre eseguire il ciclo (0-copertura)

per la definizione di a e b occorre eseguire 1 volta il ciclo (1-copertura)
per la definizione ed uso di a e b occorre eseguire 2 volte il ciclo (2-copertura)
79
III.4. Test a scatola nera

Test a scatola nera: caratteristiche generali
Tecniche basate sulle classi di equivalenza
Copertura delle funzionalit
Tecniche basate su grafi
80
Test a scatola nera:

caratteristiche generali
Viene chiamato anche:
black box testing

test funzionale (contrapposto a strutturale)
Sfrutta la definizione del comportamento ingressouscita dei programmi per ricavare i casi di prova
Principio generale: la progettazione dei casi di test
avviene prescindendo dalla conoscenza della struttura

interna del prodotto e ragionando solo sulle specifiche
81
Test a scatola nera:

caratteristiche generali (2)
Viene (tipicamente, ma non sempre) svolto dopo il
test a scatola bianca (non alternativo, ma
complementare ad esso)
Se ben condotto, riesce a determinare il
manifestarsi di molti malfunzionamenti funzionali
Inoltre, pu evidenziare il mancato rispetto di
qualche requisito non funzionale (ad es., prestazioni
non adeguate)
82
Principali tecniche di test a

scatola nera
Tecnica di copertura delle classi di equivalenza
(definite sullinput)
Tecnica di analisi dei valori estremi (individuati
sullinput)
Tecnica di copertura delle funzionalit (desunte dalle
specifiche)
83
Tecnica di copertura delle classi di

equivalenza
Il testing esaustivo impossibile
dobbiamo individuare il sottoinsieme dei dati di
ingresso con la maggiore probabilit di scoprire
errori.
Un buon caso di test, oltre ad avere una ragionevole
probabilit di trovare un errore, dovrebbe:
ridurre il numero di altri casi di test da sviluppare
rappresentare un intero insieme di casi di test
84

equivalenza (2)
Le due propriet si riferiscono ad obiettivi

diversi:
A. minimizzare il numero totale di casi di test
B. cercare casi di test significativi (rappresentativi)
A questo scopo, il dominio di ingresso va ripartito

in un numero finito di classi di equivalenza
Una classe di equivalenza un sottoinsieme dei
dati di input tale che il test di un suo elemento
sia equivalente al test di ogni altro elemento
della stessa classe (stesso comportamento del
prodotto software)
85

equivalenza (3)
Passi necessari:
1. Identificare, a partire dalle specifiche, un insieme di
condizioni interessanti da sottoporre a test
(conseguimento dellobiettivo B).
In questo modo si individuano le classi di
equivalenza.
2. Definire il minimo insieme di casi di test in grado di
coprire tali condizioni (conseguimento
dellobiettivo A)
86
Esempio di copertura delle classi di

equivalenza
Esempio di specifica
Un programma Java:
legge dal file dati.txt tre interi,
corrispondenti ai lati di un triangolo
stampa sullo schermo linformazione se il triangolo
scaleno, isoscele, o equilatero
PROGETTARE ALCUNE CLASSI DI EQUIVALENZA

87
Esempio di copertura delle classi di

equivalenza (2)
Possibili classi di equivalenza per il programma del
triangolo:
1. tre numeri interi maggiori di zero
2. tre numeri interi tali che la somma di due di essi sia sempre
maggiore del terzo
3. tre numeri uguali
Nota: mescolano input validi e non validi /

Il caso di test a = 2; b = 2; c = 2 copre le tre classi
88
Identificazione delle classi di equivalenza

una buona norma che le classi siano distinte nettamente in:
- valide (quando rappresentano esclusivamente valori di input
validi)
- non valide
Le classi vengono identificate considerando attentamente ogni
condizione di ingresso.
Da un periodo, o da una frase, nelle specifiche (quando le
condizioni di ingresso non sono esse stesse formalizzate) derivano
una o pi classi valide, una o pi classi non valide.
89
Identificazione delle classi

di equivalenza (2)
Le classi vanno elencate e a ciascuna va attribuito un
codice identificativo.
I criteri utili per la ricerca possono essere la
considerazione di:
intervalli di valori
numero di valori
insiemi di valori
condizioni vincolanti
90
Intervallo di valori
Se una condizione di ingresso specifica un intervallo di valori
vanno identificate:
una classe di equivalenza valida (per i valori compresi
nellintervallo)
due classi di equivalenza non valide (una per i valori
inferiori allestremo di variazione minimo, laltra per i
valori superiori allestremo di variazione massimo)
CLASSI DI EQUIVALENZA
CONDIZIONI ESTERNE
VALORE
DEL
CODICE
CLIENTE FRA 1
E 999
VALIDE
1 <= CODICE CLIENTE <= 999

1
NON VALIDE
CODICE CLIENTE < 1

2
CODICE CLIENTE > 999
3
91
Numero di valori
Se una condizione di ingresso specifica il numero di valori
vanno identificate:
una classe di equivalenza valida (per un numero
compreso fra il minimo ed il massimo specificati)
due classi di equivalenza non valide (una per i numeri
inferiori al minimo, laltra per i numeri superiori al
massimo)
CONDIZIONI ESTERNE
NUMERO
DI
PRODOTTI IN UN
SINGOLO
ORDINE
NON PU ESSERE
SUPERIORE A 6
VALIDE
1 <= N.RO PRODOTTI <= 6

1
NON VALIDE
N.RO PRODOTTI < 1

2
N.RO PRODOTTI > 6
3
92
Insieme di valori
Se una condizione di ingresso specifica un insieme di valori vanno
identificate:
tante classi di equivalenza valide quanti sono gli elementi
dellinsieme (se c motivo di ritenere che ciascuno degli
elementi trattato diversamente, altrimenti conviene
raggruppare gli elementi)
una classe di equivalenza non valida (per un elemento non
appartenente allinsieme)
CONDIZIONI ESTERNE
TIPO DI CLIENTE:
PRIVILEGIATO,
NORMALE O
POTENZIALE
VALIDE
TIPO CL. = PRIVILEGIATO
NON VALIDE
TIPO CL. = PRIVILEGIATO 1

TIPO CL. = NORMALE
TIPO CL. = NORMALE
2
TIPO
CL. CL.
= POTENZIALE
TIPO
= POTENZIALE
TIPO CL. = DIFFICILE

4
93
Condizioni vincolanti
Se una condizione di ingresso specifica una situazione del
tipo deve essere, vanno identificate:
una classe di equivalenza valida (per gli elementi che
verificano la condizione)
una classe di equivalenza non valida (per gli elementi che
non verificano la condizione).
CONDIZIONI ESTERNE
IL TIPO DI
PRODOTTO
DEVE ESSERE
FABBRICATO
VALIDE
TIPO PRODOTTO = FABBRICATO

1
NON VALIDE
TIPO PRODOTTO =
ACQUISTATO
94
Classi di equivalenza per il programma

del triangolo
Criterio dellintervallo di valori (ogni lato deve essere
positivo: intervallo illimitato a destra):
Classi valide:
1: a > 0
2: b > 0
3: c > 0
5: b <= 0
6: c <= 0
Classi non valide

4: a <= 0
95

del triangolo (2)
Criterio del numero di valori (il file deve contenere
esattamente tre interi: numero min == numero max):
Classi valide:
7: il file contiene esattamente tre interi
Classi non valide
8: il file contiene pi di tre interi
9: il file contiene meno di tre interi
96

del triangolo (3)
Criterio dellinsieme di valori (ci sono tre tipi di
triangoli):
Classi valide:
10: corrisponde ad un triangolo equilatero
11: corrisponde ad un triangolo isoscele
12: corrisponde ad un triangolo scaleno
Classi non valide
13: non corrisponde ad un triangolo
97

del triangolo (4)
Criterio delle condizioni vincolanti:
Il file deve contenere valori interi (c.v.: 14,
c.n.v.: 15)
Il file deve esistere ed essere leggibile (c.v.: 16,
c.n.v.: 17)
98

Classi valide
Progettare tanti casi di test da coprire tutte le classi di
equivalenza valide, con il vincolo che ciascun caso di
test includa il maggior numero possibile di classi.
Nota: talvolta questo criterio pu contrastare la facilit

di localizzazione degli errori
99
Classi valide: esempio

CONDIZIONI ESTERNE
VALIDE
1. VALORE DEL CODICE

CLIENTE FRA 1 E 999
2.
NUMERO
PRODOTTI
SUPERIORE A 6
NON VALIDE
1 <= CODICE CLIENTE <= 999 (1)
DI
NON
3. IL TIPO PRODOTTO
DEVE ESSERE
FABBRICATO
ESEMPIO:
1<=N. RO PROD. <= 6

TIPO PRODOTTO =
FABBRICATO
(4)
(7)
COD. CL. < 1
(2)
COD. CL. > 999
(3)
N.RO PROD. < 1
(5)
N.RO PROD. > 6
(6)
TIPO PROD. =
ACQUISTATO
(8)
IL CASO DI TEST:
COD. CLIENTE = 5
N.RO DI PROD. = 4
TIPO PROD. = FABBRICATO
COPRE LE CLASSI (1), (4), (7).
100
Progettazione dei casi di test (2)

Classi non valide
progettare tanti casi di test da coprire tutte le classi
di equivalenza non valide, con il vincolo che
ciascun caso di test copra una ed una sola delle
classi non valide.
Le classi non valide vanno coperte individualmente
per evitare mascheramenti fra errori
101
Classi non valide: esempio

CONDIZIONI ESTERNE
VALIDE
1. VALORE DEL CODICE

CLIENTE FRA 1 E 999
2.
NUMERO
PRODOTTI
SUPERIORE A 6
1<=CODICE CLIENTE <= 999
DI
NON
1<=N. RO PROD. <= 6

TIPO PRODOTTO =
FABBRICATO
3. IL TIPO PRODOTTO
DEVE ESSERE
FABBRICATO
NON VALIDE
(1)
(4)
(7)
COD. CL. < 1
(2)
COD. CL. > 999
(3)
N.RO PROD. < 1
(5)
N.RO PROD. > 6
(6)
TIPO PROD. =
ACQUISTATO
(8)
I CASI DI TEST E LE CLASSI COPERTE SONO:

(2)
(3)
(5)
(6)
(8)
COD. CLIENTE =
1000
N.RO DI PROD. =
(F)
(F)
(F)
(F)
(A)
TIPO PROD.
DOVE (F) = FABBRICATO, (A) = ACQUISTATO
102
Casi di test per il programma del

triangolo
C1: 4,4,4:
classi 1,2,3,7,
C7: 2,2,2,2:
classe 8
10, 14, 16
C8: 2,2:
classe 9
C2: 2,2,1:
classe 11
C9: 2,5,10:
classe 13
C3: 5,4,2:
classe 12
C10: 3.0, 3.1, 3.1: classe 15
C4: 1,2,2: classe 4
C11: file illeggibile:
C5: 2,-1,2: classe 5
classe 17
C6: 2,2,-1: classe 6

103
Esercizi
1. Dire se gli 11 casi di test appena riportati per il
programma del triangolo hanno le seguenti
caratteristiche:
Per ogni classe valida esiste almeno un caso di test

che la ricopre
Per ogni classe non valida esiste esattamente un caso
di test che la ricopre
2. Con riferimento ad ognuna delle 15 domande

riportate allinizio di questi lucidi, dire se fra gli
11 casi di test appena riportati sopra ce n
qualcuno che permette di rispondere
affermativamente
104
Tecnica di analisi dei valori estremi

Lesperienza mostra che i casi di test che esplorano
condizioni estreme sono molto produttivi
Le condizioni estreme (o limite) sono quelle situazioni
direttamente sugli estremi
immediatamente al di sopra
immediatamente al di sotto
degli estremi di classi di equivalenza dingresso e di

uscita
105
Tecnica di analisi dei valori estremi (2)

Lanalisi dei valori estremi differisce dalla partizione in
classi di equivalenza per due aspetti:
1. vengono scelti come rappresentativi della classe di
equivalenza uno o pi valori in un intorno di ciascun
estremo
2. i casi di test sono derivati considerando anche lo
spazio dei risultati (classi di equivalenza di uscita)
La tecnica richiede una buona conoscenza del tema
applicativo ed una buona dose di creativit
106

Linee guida:
1.intervallo di valori specificato da una condizione dingresso:
scrivere casi di test
validi, per i valori sugli estremi dellintervallo
non validi, per valori immediatamente sotto il minimo o
sopra il massimo
2.numero di valori specificato da una condizione dingresso:
scrivere casi di test:
validi, per il numero minimo e per il massimo
non validi, per i numeri immediatamente sotto il minimo o
sopra il massimo
107

3. ripetere il processo di cui al punto 1 per ciascuna condizione
analoga in uscita
4. ripetere il processo di cui al punto 2 per ciascuna condizione
analoga in uscita
5. se in ingresso o in uscita al prodotto software c un insieme
ordinato di elementi occorre prevedere casi di test per il primo
e lultimo elemento dellinsieme
6. usare la propria abilit per ricercare altre condizioni estreme
108

Lo spazio dei risultati
occorre effettuare unanalisi accurata dello spazio dei risultati,
considerando che:
non sempre gli estremi del dominio di ingresso
corrispondono agli estremi del dominio di uscita in
quanto non sono determinati dallo stesso insieme di
circostanze
non sempre possibile generare un risultato al di fuori
degli estremi del dominio valido di uscita
109
Lo spazio dei risultati: esempio

per lintervallo di valori
output
estremo superiore
del dominio di output
input
estremo inferiore
della classe valida
estremo superiore
del dominio di output
estremo superiore
della classe valida
110
Esempio
UN ESEMPIO
CONDIZIONI ESTERNE
VALIDE
LA SOMMA DI DUE LATI

MAGGIORE DEL TERZO
A+B>C
NON VALIDE
A + B <=C
DUE POSSIBILI CASI DI TEST

A = 3
B=4
C=5
A =1
B=2
C=4
111
Esempio (2)
Se nel programma fosse erroneamente presente la condizione
A + B >= C allora i casi di test precedenti non rileverebbero
lerrore.
Lanalisi dei valori estremi esplora le situazioni sugli estremi

ed intorno agli estremi delle classi di equivalenza.
Secondo la tecnica dei valori estremi, dobbiamo produrre un

caso di test come A = 1, B = 2, C = 3
112

Conclusioni
i casi di test ottenuti con lanalisi dei valori estremi rappresentano
errori molto comuni.
una generazione casuale dei casi di test non individua questi errori.
lanalisi dei valori estremi una delle tecniche pi utili nel disegno
dei casi di test.
malgrado lapparente semplicit la tecnica non banale, in quanto
le condizioni estreme possono essere molto sottili
113
Esercizio
Progettare classi di equivalenza per ununit di programma Java per
la ricerca di un valore in un vettore non vuoto
INPUT = vettore vett di N interi (N>0); intero k
OUTPUT=
true, se k presente in vett;

false, altrimenti.
public static boolean cerca (int[] vett, int k) {

// restituisce true sse k presente
// in vett, false altrimenti
114
Soluzione
Passi da seguire:
1. Identificare alcuni criteri per caratterizzare classi di
equivalenza, senza prendere in considerazione i valori estremi
2.
Raffinare/espandere i precedenti criteri prendendo in

considerazione:
a)
Uno o pi valori nellintorno di ciascun estremo per le condizioni di

ingresso
b) Uno o pi valori nellintorno di ciascun estremo per le condizioni di

uscita
c)
3.
Eventuali ordinamenti negli insiemi
Sintetizzare le classi
115
Soluzione: passo 1
1. Identificare alcune classi di equivalenza, senza
prendere in considerazione i valori estremi. Per
semplicit, prendiamo in considerazione solo il criterio
dellintervallo di valori.
Classe non valida: vettore di zero elementi
(N == 0)
Classe valida: vettore con almeno un elemento
(N > 0)
116
Soluzione: passo 2
2. Raffinare/espandere le precedenti classi (solo
la valida):
a) Estremi per le condizioni di ingresso:
N == 0 (lunghezza minima del vettore)
Uno o pi valori nellintorno: 1, 2
Non esiste lunghezza massima del vettore
Va scelta una lunghezza arbitraria (ad es., 10)
117
Soluzione: passo 2 (2)

b) Estremo per le condizioni di uscita:
false/true (risultati possibili)
c) Eventuali ordinamenti:
k il primo in vett
k lultimo in vett
k presente in vett, ma non il primo n
lultimo
118
Soluzione: passo 3
PARTIZIONE IN DIECI CLASSI DI EQUIVALENZA
========================================================
| N=0 | N=1 |
N=2
|
N>2
|
========================================================
K |
/ |CL. 1 | k il primo | k il primo |CL. 4
|
/ |
|CL. 2
|---------------|
presente | /
|
|---------------| k l'ultimo |CL. 5
| /
|
| k l'ultimo |---------------|
|/
|
|CL. 3
| k in mezzo |CL. 6
--------------------------------------------------------|
K non |CL. 7 |CL. 8 |CL. 9
| CL. 10
|
presente |
|
|
|
|
--------------------------------------------------------
Nota: tutte le classi sono valide tranne la 7.

Sono necessari dieci casi di test (le classi valide sono disgiunte).
119
Esempio di programma driver

int[] classe1 =
int[] classe2 =
int[] classe3 =
int[] classe4 =
int[] classe5 =
int[] classe6 =
int[] classe7 =
int[] classe8 =
int[] classe9 =
int[] classe10=
int[][] tutti =
{ 47 };
{ 47, 9 };
{ 9, 47 };
{ 47, 9, 2, 4, -1, 22, 55, 28, 12, 0 };
{ 9, 2, 4, -1, 22, 55, 28, 12, 0, 47 };
{ 9, 2, 4, -1, 47, 22, 55, 28, 12, 0 };
{ };
{ 2 };
{ 2, -4 };
{ 9, 2, 4, -1, 46, 22, 55, 28, 12, 0 };
{classe1, classe2, classe3, classe4, classe5,
classe6, classe7, classe8, classe9, classe10 };
for (int i = 0; i <= 9; i++)
System.out.println("Caso di test: " + (i+1) +
", risultato: " +
DaTestare.cerca(tutti[i],47));
120
Esercizi
Progettare classi di equivalenza per le seguenti unit di
programma Java:
1. INPUT =
OUTPUT =
vettore vett di N interi; intero k

true, se k presente almeno due
volte in vett; false, altrimenti.
2. INPUT =
OUTPUT =
lista di interi l
massimo valore in l
121
Esercizi (2)
3. INPUT =
OUTPUT =
sequenza di 0 e 1, letta da tastiera

lunghezza massima della sottosequenza
di 0 pi lunga
4. INPUT =
OUTPUT =
vettore di N interi
lo stesso vettore, ordinato
122
Tecnica di copertura delle funzionalit

Per sapere quello che un prodotto SW deve (o non
deve fare) occorre riferirsi alle sue specifiche, che
possono essere pi o meno formali
Occorre analizzare e dividere le specifiche in
modo da definire con esattezza:
quali sono le funzioni elementari che il prodotto deve
svolgere, e
per ciascuna di esse, stabilire
se la funzionalit testabile oppure no;
se non lo qual la causa.
123
Tecnica di copertura delle funzionalit (2)

Le funzionalit individuate devono avere le seguenti
caratteristiche:
Indipendenza: non esiste nessun altra funzionalit che sia
sempre esercitata o non esercitata contemporaneamente
alla funzionalit in questione
Elementarit: non divisibile in sottofunzionalit
esercitabili indipendentemente
124
Tecnica di copertura delle funzionalit (3)

Passi da seguire:
1. Identificare ogni funzionalit nelle specifiche
2. Identificare le combinazioni di funzionalit presenti nelle
specifiche
3. Rendere ciascuna funzionalit (o combinazione) accessibile
ad un test indipendente
4. Collegare ciascuna funzionalit ad un caso di test finale
5. Identificare i requisiti non funzionali da verificare con il test
6. Procedere rispetto a tali requisiti in modo analogo a quanto
definito per le funzionalit
125
Tecniche basate sullutilizzo di grafi

Un limite intrinseco delle tecniche precedenti la loro
inefficacia nel caso di combinazioni di circostanze
(classi di input)
Ad esempio, in un ipotetico programma per la
valutazione di questionari a scelta multipla potrebbe:
non verificarsi errore quando il numero di moduli sotto un
certo limite prestabilito
non verificarsi errore quando il numero di domande per
modulo sotto un certo limite prestabilito
verificarsi errore quando il prodotto del numero di domande
per modulo eccede un certo limite
Il numero di combinazioni cresce esponenzialmente

con il numero di classi
126
Tecniche basate sullutilizzo di grafi (2)
I grafi causa-effetto aiutano a selezionare le

combinazioni in maniera significativa
Procedimento per sintetizzare i casi di test utilizzando
i grafi causa-effetto:
1. le specifiche di ingresso vengono ridotte a:
a) condizioni booleane, rappresentanti fatti (dati) di
ingresso e uscita
Esempi: il cliente di riguardo (dato di ingresso)
il cliente pu pagare con assegno (dato di uscita)
b) asserzioni su tali condizioni booleane
Esempio: se il cliente di riguardo, allora pu
pagare con assegno
127

2. si rappresenta linsieme di asserzioni mediante un grafo, in
cui si possono utilizzare i connettivi logici AND, OR, NOT
possibile rappresentare tali grafi in forma matriciale, utile
per generare le opportune sequenze di ingresso
Esempio: se i fatti A, B, C verificandosi congiuntamente
causano leffetto D il grafo corrispondente sar del tipo:
A
B
AND
A=conto <X
B=in possesso di un documento
C=lassegno non risulta rubato
D=pu pagare con assegno
A B
128

3. Per ciascun effetto, trovare le combinazioni di
cause che:
a) lo determinano (ovvero la corrispondente condizione
booleana diventa true) e che
b) non lo determinano (false)
4. Cercare una rappresentazione semplice delle

combinazioni di cui ai punti precedenti (in
particolare, determinare le condizioni irrilevanti)
5. Tali rappresentazioni determinano i casi di test
129
III.5. Strategie di test
Tipologie di test
Test di integrazione
Test di sistema, di accettazione e di regressione
Test di moduli particolari
130
Tipologie di test
Test di unit
Test di sistema
Test di accettazione
Test di regressione
Scatola bianca e/o nera

Solo scatola nera
131
Una volta testati i singoli moduli (ispezione, black e white)
occorre integrarli tra di loro
Il 75% degli errori nel progetto Apollo furono errori di interfaccia
Il problema dellintegrazione va preso in considerazione fin

dalle fasi iniziali del progetto
Questo implica, tra laltro, la pianificazione di opportuni
livelli di test.
Ad esempio: ispezione umana white black
integrazione
132
Tecniche di integrazione
A
B
Albero delle
chiamate
DRIVER
B
Driver: sostituisce un modulo
chiamante trasmettendo i
parametri (corretti!)
STUB 1
STUB 2
STUB 3
Stub: sostituisce un modulo chiamato

restituendo i valori di ritorno (corretti!)
133
Strategie di integrazione
STRATEGIA NON INCREMENTALE
BIG-BANG
Integrazione simultanea di tutte le parti
STRATEGIA INCREMENTALE
TOP-DOWN
BOTTOM-UP
Integrazione effettuata partendo

dallalto, procedendo verso le procedure
pi annidate
Integrazione effettuata dal basso, partendo
dalle foglie
134
Il test incrementale
Vantaggi
Non un metodo caotico
Gli errori vengono individuati prima e pi facilmente
Svantaggi
Pu richiedere la scrittura di un numero considerevole di
driver o stub
Riduce il parallelismo
135
Approcci incrementali
APPROCCIO TOP-DOWN
APPROCCIO BOTTOM-UP
A
B
C
STUB E
DRIVER A
D
STUB F
DRIVER B
DRIVER D
STUB H
Regola: integrare prima possibile i componenti pi critici e di I/O

136
Approccio top-down
Vantaggi
Utile quando i difetti o la complessit sono nella parte alta della struttura
Si ottiene rapidamente uno scheletro del prodotto semifunzionante
Approccio pi naturale
Svantaggi
Gli stub da produrre sono tipicamente complessi
Pu ritardare il completamento del test di alcuni componenti
Pi difficile osservare i risultati
137
Approccio bottom-up
Vantaggi
Utile quando i difetti o la complessit sono nella parte
bassa della struttura
Pi facile da realizzarsi
Pi facile osservare i risultati del test
Svantaggi
La produzione di driver meno naturale (ma esistono
tool per la generazione automatica)
Il prodotto non completo sino a quando non vengono
aggiunti i componenti alti
138
Test di sistema
Avviene dopo il test di integrazione (esiste un sistema
minimo integrato)
Si esegue individuando:
casi di test basati sui requisiti che sono sufficienti a coprire il
sistema da una prospettiva black box (funzionale)
ulteriori casi di test che sono richiesti per misurare ed esplorare
le prestazioni del sistema e la misura di attributi di qualit
Esempi: tempo di risposta, spazio occupato, robustezza
139
Test di sistema (2)

Altri tipi di test di prestazione possono includere:
test della documentazione di sistema (correttezza e usabilit),
test dellaffidabilit del sistema (analisi dei fallimenti, test di
stress, test operazionali),
test della manutenzione del sistema (tempo per eseguire
cambiamenti standard).
, in generale, un compito complesso

Si utilizzano tecniche di copertura
140
Test di accettazione
Si esegue a valle del test di sistema.
Serve a confermare che il sistema pronto per un uso
operazionale.
In genere il test di accettazione eseguito dallutente che
deve dimostrare leffettiva funzionalit del sistema e della
relativa documentazione.
La selezione dei casi di test eseguita dagli utenti, con laiuto
di un esperto pianificatore (presso lo sviluppatore: test alfa,
presso il cliente: test beta)
La differenza con il test di sistema, risiede nel fatto che ora i
test vengono eseguiti in un contesto quasi operazionale (il
sistema viene testato utilizzando lhardware, il software e
lambiente utente per cui stato sviluppato).
141
Test di regressione
Effettuato a valle di una modifica del programma:
Controllare che il bug sia stato individuato e corretto:
vanno rieseguiti esattamente gli stessi test che erano stati
eseguiti quando era stato trovato il problema, descritto nei
report.
Cercare di trovare bug correlati: una volta scovato il bug
che causava i problemi, e avendo scoperto le cause allinterno
del codice che lo generavano, opportuno chiedersi se
possono esistere altre parti di codice a cui apportare le
medesime modifiche (o perlomeno simili).
142
Test di regressione (2)

Controllare il resto del programma: dopo aver apportato le
opportune modifiche al codice, si deve considerare
leventualit che esse possano aver causato altri problemi.
Quindi si devono controllare le parti di programma che
potrebbero essere state compromesse da tali cambiamenti.
Controllare la correttezza di una nuova versione tramite la
ripetizione di un opportuno (ampio) insieme di test (ad es., i
test di sistema).
Sono necessari strumenti automatici.
143
Test per confronto

Software ridondante (situazioni estremamante
critiche)
Produzione di differenti versioni sulla base delle
stesse specifiche
Confronto (facilmente automatizzabile) delle varie
versioni sugli stessi casi di test
Nota: ovviamente se le specifiche sono errate...

144
Test di interfacce grafiche

Notevole sovrapposizione di funzionalit (ambienti a
finestra/menu/mouse)
Possibilit di sviluppare delle checklist esaustive del tipo:
le funzionalit di movimento scrolling e ridimensionamento
funzionano?
il mouse permette di raggiungere tutti gli elementi presenti nella
finestra?
lo stato della barra dei men consistente?
sono previsti dei comanti da tastiera per le funzionalit pi
frequentemente usate?
il formato dei dati di ingresso (date, numeri, ecc.) corretto?
i meccanismi grafici per linput dei dati funzionano correttamente?
145
III.6. Debugging
Princpi di debugging e riparazione
Debugging per forza bruta
Debugging per abduzione
146
Princpi di debugging
Pensare
Se in impasse, dormirci sopra
Se in impasse, parlarne a qualcun altro
Evitare la sperimentazione (ultima scelta)
147
Princpi di riparazione
Se c un errore, forse ce ne sono altri
Riparare lerrore, non il suo sintomo
La probabilit di avere corretto lerrore non il
100%, e diminuisce al crescere del programma
Potremmo avere introdotto altri errori
148
Soluzione esercizio 1
Do
ma
nda
Ri
spo
sta
No Si Si No Si Si No No Si No Si Si Si No Si
Fil e
2,
6
10 11 12 13 14
15
149

PrimaParte 3 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PrimaParte 3 PDF

Caricato da

Copyright:

Formati disponibili

Ingegneria del Software

(Ing.Informatica Nuovo Ord.)

Il processo di produzione del SW

Marco Cadoli, Universit La Sapienza, ott 2005

Introduzione, ciclo di vita del SW

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

III. Test del Software

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

III.1. Concetti fondamentali del test

Un esempio per iniziare

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

Esempio di un programma da testare

Marco Cadoli, Universit La Sapienza, ott 2005

Marco Cadoli, Universit La Sapienza, ott 2005

Avete considerato anche ?

Marco Cadoli, Universit La Sapienza, ott 2005

Avete considerato anche ? (2)

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

File input Output previsto

Con riferimento ad ognuna delle 15 domande precedenti, dire se fra i 10

Marco Cadoli, Universit La Sapienza, ott 2005

Limiti del test

Marco Cadoli, Universit La Sapienza, ott 2005

Difetti, errori e malfunzionamenti

Marco Cadoli, Universit La Sapienza, ott 2005

Marco Cadoli, Universit La Sapienza, ott 2005

Obiettivo generale del test

Marco Cadoli, Universit La Sapienza, ott 2005

Aspetti psicologici del test

Dal punto di vista psicologico, si tratta di una fase

1. Il test consiste nellesecuzione di un programma al fine

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

Princpi fondamentali del test

Una componente necessaria di un caso di test la

Marco Cadoli, Universit La Sapienza, ott 2005

Princpi fondamentali del test (2)

Unorganizzazione (ad es., un settore di unazienda)

Dal punto di vista psicologico, con il test interno

Le attivit di test andrebbero condotte da terze

I risultati di un test vanno analizzati in maniera

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

Princpi fondamentali del test (3)

I casi di test vanno definiti:

Il test deve verificare se un programma:

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

Princpi fondamentali del test (4)

Evitare casi di test usa e getta

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

Princpi fondamentali del test (5)

Numero di errori trovati

Gli errori tendono a raggrupparsi in alcune sezioni

Ing. del SW: Prima parte Sez III

Marco Cadoli, Universit La Sapienza, ott 2005

/A/ float x = InOut.readFloat(),