Software Engineering

14. Verifica e Validazione
 Come assicurarsi che il software corrisponda alle




necessità dell’utente?
Introdurremo i concetti di verifica e validazione
Descriveremo le fasi del processo di testing
Parleremo di pianificazione del testing
Descriveremo diverse strategie di testing
1
Verifica & validazione
 Verifica:
“Stiamo costruendo il prodotto nel modo giusto?”
Il software deve soddisfare la specifica
 Validazione:
"Stiamo costruendo il prodotto giusto?"
Il software deve fare quello che l’utente realmente
richiede
 Sono domande che devono percorrere tutto il ciclo di
vita del software, per correggere errori e per valutare se
il prodotto è usabile dal punto di vista operativo
2
Verifica e Validazione
requisiti
informali
spec. livello 1
validazione
verifica
spec. livello 2
spec. livello n
implementaz.
3
Verifica statica/dinamica
 Verifica e Validazione dinamica
Testare il prodotto facendo prove e osservandone il
comportamento
 Verifica Statica
Analizzare la rappresentazione statica del sistema per
individuare i problemi
4
V&V statica e dinamica
Static
verification
Requirements
specification
Prototype
High-level
design
Formal
specification
Detailed
design
Program
Dynamic
validation
5
Testing
 La verifica di corretto comportamento corretto su un
numero finito di casi non assicura la correttezza del
programma
 Non si può raggiungere una certezza di correttezza
attraverso il testing
 Questo non significa che sia una tecnica di verifica inutile
 Anche le prove matematiche possono contenere errori
6
Terminologia
 ERRORE

la causa di un malfunzionamento, p.es. un errore
umano di editing
 ANOMALIA, GUASTO (fault)
 difetto del programma dovuto a un errore
 MALFUNZIONAMENTO (failure)
 manifestazione visibile della presenza di un’anomalia
7
Esempio
ERRORE di editing
ANOMALIA
--> “*” invece di “+”
MALFUNZIONAMENTO
--> la stampa
program RADDOPPIA ...
....
read (x);
y := x*x;
write (y)
...
ANOMALIA causata da un errore
MALFUNZIONAMENTO causato da un’anomalia
8
Obiettivo per un test
 Individuare tecniche empiriche per aumentare la
probabilità che una anomalia causi un
malfunzionamento
9
Testing
Il test può servire per scoprire la
presenza di possibili malfunzionamenti, ma non a garantirne l’assenza
(Dijkstra)
 Un test ha successo se permette di individuare uno
o più errori
 Per i requisiti non funzionali possono solo essere
utilizzate tecniche di validazione
10
Testing
 Testing statistico
 Il test è progettato in relazione alla frequenza d’uso dei
vari tipi di input da parte degli utenti. Usato per la stima
di affidabilità del sistema e la efficienza del sistema
 Defect testing
 I test sono progettati per scoprire i difetti del sistema
 Debugging
 Individuare dove si trova l’errore e progettarne la
correzione
11
Fasi del testing
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing
Component
testing
Integration testing
User
testing
12
Testing di sistemi OO
 Nei sistemi OO i livelli di integrazione sono meno
distinti rispetto allo schema precedente
 Testare le singole classi corrisponde allo “unit
testing”
 Cluster testing. Corrisponde al module testing.
Testare un gruppo di oggetti che cooperano per
fornire una serie di servizi
13
Il piano di testing
E’ un documento che deve descrivere:
1. Il processo di testing adottato
2. Tracciabilità dei requisiti
3. Elementi testati
4. Schedule del testing: tempo e risorse allocate
5. Procedure di registrazione dei test
6. Requisiti hardware e software utilizzati
7. Vincoli che condizionano il testing
14
Modello a V del processo software
Requir ements
specification
System
specification
System
integration
test plan
Acceptance
test plan
Service
System
design
Acceptance
test
Detailed
design
Sub-system
integration
test plan
System
integration test
Module and
unit code
and tess
Sub-system
integration test
15
Strategie di testing

Strategie diverse possono essere applicate nelle diverse
fasi del processo di testing
1. Incremental testing
2. Top-down testing
3. Bottom-up testing
4. Thread testing
5. Stress testing
6. Back-to-back testing
16
Incremental testing
T1
A
T1
A
T2
T1
A
T2
T2
B
T3
B
T3
B
C
T4
T3
C
T4
T5
D
Test sequence
1
Test sequence
2
Test sequence
3
17
Esperienza
 Sembra che circa il 40% di malfunzionamenti possa
essere attribuito a problemi di integrazione
 essenzialmente errori nell’interpretazione che un
modulo fa delle specifiche dell’altro
18
Test di modulo
 Un modulo fa parte di un sistema


è cliente di altri moduli
è usato da altri moduli
MOD
19
Test di modulo
 Occorre simulare i moduli usati
 STUB
 Occorre simulare i moduli che lo usano
 DRIVER
 Caso di MOD sottoprogramma
 DRIVER



inizializza eventuali variabili globali
chiama MOD
STUB

“completa” i sottoprogrammi mancanti con dei “monconi”
20
Top-down testing
Level 1
Testing
sequence
Level 2
Level 1
Level 2
Le vel 2
. ..
Level 2
Le vel 2
stubs
Le vel 3
stubs
21
Top-down testing
 Inizia con i livelli più alti del sistema e procede all’ingiù: le




sottocomponenti sono rappresentate da “stub” (ceppi,
monconi), che hanno la stessa interfaccia delle
sottocomponenti ma funzionalità limitata
E’ una strategia di testing adatta quando si procede in uno
sviluppo top-down
Individua rapidamente errori architetturali
Può richiedere di aver già completa la struttura del
sistema, prima di poter iniziare qualsiasi test
Può risultare difficile sviluppare gli “stub”
22
Casi possibili di “stub”
 Il chiamato non fa nulla (eventualmente stampa la
traccia)
 Il chiamato colloquia con il programmatore per
calcolare il risultato atteso (stub interattivo)
 Il chiamato è una versione semplificata (un prototipo)
del modulo che verrà chiamato
23
Bottom-up testing
Test
drivers
Level N
Test
drivers
Level N
Level N–1
Le vel N
Level N–1
Level N
Level N
Testing
sequence
Level N–1
24
Bottom-up testing
 I vantaggi del bottom-up sono gli svantaggi del top-down
(e viceversa)
 Si inizia dalle componenti più a basso livello e si lavora
all’insù, realizzando dei “drivers” che simulano l’ambiente
nel quale le componenti saranno inserite
 Non individua errori di progettazione di alto livello se non
molto avanti nel processo
 E’ appropriato per sistemi object-oriented
25
Thread testing
 Adatto a sistemi real-time e ad oggetti
 Si basa sul testare un’operazione che comporta una
sequenza di passi di processo che sono legati da uno
stesso thread (filo) nel sistema
 Inizia con thread legati a un singolo evento e poi viene
reso più complesso testando threads a eventi multipli
 Può essere impossibile un “threading test” completo, a
causa del numero elevato di combinazioni di eventi
26
Esempio: interazione di processi
I1 (P2)
I1 (P1)
I2 (P1)
P1
P2
I3 (P1)
I1 (P3)
P5
O1
(P5)
O1 (P4)
P3
P4
O2 (P4)
27
Thread testing
I1
(P3)
P3
P2
P4
O1
(P4)
I1
(P1)
I2
(P1)
P1
P2
P5
O1
(P5)
I3
(P1)
28
Multiple-thread testing
I1 (P2)
I1 (P1)
I2 (P1)
P1
P2
P5
O1 (P5)
I3 (P1)
P4
O2 (P4)
29
Stress testing
 Ha come obiettivo verificare che il sistema sopporta il
carico massimo previsto in fase di progettazione. Il
sistema viene testato oltre i limiti finché fallisce
 Testa il comportamento del sistema in caso di
fallimento, e verifica le conseguenti perdite di dati o di
servizi
 Particolarmente importante in sistemi distribuiti, che
possono subire degrado quando la rete è troppo carica
30
Back-to-back testing
 Testa diverse versioni del programma con lo stesso input,
e confronta gli output. Se l’output è diverso, ci sono errori
potenziali
 Riduce il costo di esaminare il risultato dei test: il
confronto degli output può essere automatizzato
 Si può usare quando è disponibile un proptotipo, quando il
sistema vine sviluppato in più versioni (su diverse
piattaforme) o un upgrade di sistema
31
Back-to-back testing
Test data
Program
version A
Program
version B
Results
comparator
Difference report
32