1

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

2

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

Verifica & validazione

3

spec. livello 1

spec. livello nimplementaz.

verificavalidazione

requisitiinformali

spec. livello 2

Verifica e Validazione

4

Verifica e Validazione dinamicaTestare il prodotto facendo prove e osservandone il comportamento

Verifica StaticaAnalizzare la rappresentazione statica del sistema per individuare i problemi

Verifica statica/dinamica

5

V&V statica e dinamica

Formalspecification

High-leveldesign

Requirementsspecification

Detaileddesign

Program

PrototypeDynamicvalidation

Staticverification

6

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

7

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

8

Esempio

ERRORE di editing

ANOMALIA

--> “*” invece di “+”

MALFUNZIONAMENTO

--> la stampa

ANOMALIA causata da un errore

MALFUNZIONAMENTO causato da un’anomalia

program RADDOPPIA .......read (x);y := x*x;write (y)...

9

Obiettivo per un test

Individuare tecniche empiriche per aumentare la probabilità che una anomalia causi un malfunzionamento

10

Un test ha successo se permette di individuare uno o più errori

Per i requisiti non funzionali possono solo essere utilizzate tecniche di validazione

Testing

Il test può servire per scoprire lapresenza di possibili malfunziona-

menti, ma non a garantirne l’assenza(Dijkstra)

11

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

12

Fasi del testing

Sub-systemtesting

Moduletesting

Unittesting

Systemtesting

Acceptancetesting

Componenttesting

Integration testing Usertesting

13

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

14

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

15

Modello a V del processo software

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

16

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

17

Incremental testing

T3

T2

T1

T4

T5

A

B

C

D

T2

T1

T3

T4

A

B

C

T1

T2

T3

A

B

Test sequence1

Test sequence2

Test sequence3

18

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

19

Test di modulo

Un modulo fa parte di un sistema è cliente di altri moduli è usato da altri moduli

MOD

20

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”

21

Top-down testing

Level 2Level 2Level 2Level 2

Level 1 Level 1Testing

sequence

Level 2stubs

Level 3stubs

. . .

22

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”

23

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

24

Bottom-up testing

Level NLevel NLevel NLevel NLevel N

Level N–1 Level N–1Level N–1

Testingsequence

Testdrivers

Testdrivers

25

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

26

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

27

Esempio: interazione di processi

P2

P1

P5

P4

I1 (P2)

O2 (P4)

O1(P5)

I2 (P1)

I1 (P1)

I3 (P1)

P3I1 (P3) O1 (P4)

28

Thread testing

P2P3 P4 O1(P4)

I1(P3)

P2P1 P5 O1(P5)

I2(P1)

I1(P1)

I3(P1)

29

Multiple-thread testing

P2P1 P5

P4

I1 (P2)

O2 (P4)

O1 (P5)I2 (P1)

I1 (P1)

I3 (P1)

30

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

Stress testing

31

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

32

Back-to-back testing

Test data

Programversion A

Programversion B

Resultscomparator

Difference report