Testing - wpage.unina.itwpage.unina.it/fasolino/is/materiale/9-testing.pdf · 3 Anna Rita Fasolino-...

21
1 Anna Rita Fasolino- Ingegneria del Software - Testing 1 Testing Definizioni Problemi del testing:Criterio di selezione dei casi di test Test Funzionale: suddivisione in classi di equivalenza e analisi dei valori limite Test Strutturale: basato sul flusso di controllo e dei dati Valutazione dei risultati del testing Criterio di terminazione del testing Livelli di testing Test di programmi OO Pianificazione, Specifica, esecuzione e rapporto del test Anna Rita Fasolino- Ingegneria del Software - Testing 2 Definizioni Errore (umano) incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell’uso di strumenti Difetto (fault o bug) Manifestazione nel software di un errore umano, e causa del fallimento del sistema nell’eseguire la funzione richiesta Malfunzionamento (failure) incapacità del software di comportarsi secondo le aspettative o le specifiche un malfunzionamento ha una natura dinamica: accade in un certo istante di tempo e può essere osservato solo mediante esecuzione

Transcript of Testing - wpage.unina.itwpage.unina.it/fasolino/is/materiale/9-testing.pdf · 3 Anna Rita Fasolino-...

1

Anna Rita Fasolino- Ingegneria del Software -Testing

1

Testing

DefinizioniProblemi del testing:Criterio di selezione dei casi di test

Test Funzionale: suddivisione in classi di equivalenza e analisidei valori limite

Test Strutturale: basato sul flusso di controllo e dei datiValutazione dei risultati del testingCriterio di terminazione del testing

Livelli di testingTest di programmi OO

Pianificazione, Specifica, esecuzione e rapporto del test

Anna Rita Fasolino- Ingegneria del Software -Testing

2

Definizioni

• Errore (umano)– incomprensione umana nel tentativo di comprendere o risolvere un

problema, o nell’uso di strumenti

• Difetto (fault o bug)– Manifestazione nel software di un errore umano, e causa del

fallimento del sistema nell’eseguire la funzione richiesta

• Malfunzionamento (failure)– incapacità del software di comportarsi secondo le aspettative o le

specifiche– un malfunzionamento ha una natura dinamica: accade in un certo

istante di tempo e può essere osservato solo mediante esecuzione

2

Anna Rita Fasolino- Ingegneria del Software -Testing

3

Relazione fra Errore, Difetto eMalfunzionamento

errore Difetto

1..*1..*

Malfunzionamento

1..*1..* 1..* 1..*

causa causa

Anna Rita Fasolino- Ingegneria del Software -Testing

4

Definizioni

• Il Testing (collaudo) è un processo di esecuzione delsoftware allo scopo di scoprirne i malfunzionamenti– osservando i malfunzionamenti possiamo dedurre la

presenza di difetti– Tesi di Dijkstra:

Il testing non può dimostrare l’assenza di difetti, ma può solodimostrare la presenza di difetti

• Il Debugging è il processo di scoperta dei difetti a partireda malfunzionamenti noti

• L’Ispezione è un processo di analisi del software perscoprirne i difetti

3

Anna Rita Fasolino- Ingegneria del Software -Testing

5

Problemi del testing

• Criterio di selezione dei casi di test

• Valutazione dei risultati del test

• Criterio di terminazione del testing

Anna Rita Fasolino- Ingegneria del Software -Testing

6

Valutazione dei risultati del test

• Condizione necessaria pereffettuare un test:– conoscere il comporatmento

atteso per poterlo confrontare conquello osservato

• L’oracolo conosce ilcomportamento atteso per ognicaso di prova

• Oracolo umano– si basa sulle specifiche o sul

giudizio

• Oracolo automatico– generato dalle specifiche (formali)

– stesso software ma sviluppato daaltri

– versione precedente (test diregressione)

Software da

testare Oracolo

Compara-tore

Risultati del test

Casi di test

4

Anna Rita Fasolino- Ingegneria del Software -Testing

7

Terminazione del testing

• Quando il programma si può ritenere analizzato asufficienza– Criterio temporale: periodo di tempo predefinito– Criterio di costo: sforzo allocato predefinito– Criterio di copertura:

• percentuale predefinita degli elementi di un modello diprogramma

• legato ad un criterio di selezione dei casi di test

– Criterio statistico• MTBF (mean time between failures) predefinito e confronto con

un modello di affidabilità esistente

Anna Rita Fasolino- Ingegneria del Software -Testing

8

Problema della selezione dei casi di test

• Un programma è corretto se è corretto per ogni dato d’ingresso• Un programma è esercitato da un caso di test (sottoinsieme dei dai di

input)• Un test è formato da un insieme di casi di test• L’esecuzione del test consiste nell’esecuzione del programma per tutti i

casi di test• Un test ha successo se rileva uno o più malfunzionamenti del programma• Un test è ideale se l’insuccesso del test implica la correttezza del

programma• Un test esaustivo è un test che contiene tutti i dati di ingresso al

programma– un test esaustivo è un test ideale

– un test esaustivo non è pratico e quasi sempre non è fattibile

• Obiettivo realistico: selezionare casi di test che approssimano un testideale

5

Anna Rita Fasolino- Ingegneria del Software -Testing

9

Criterio di selezione di test

• Specifica le condizioni che devono essere soddisfatte da un test• Consente di selezionare più test per uno stesso programma• Un criterio di selezione di test è affidabile per un programma se

per ogni coppia di test selezionati, T1 e T2, se T1 ha successoanche T2 ha successo e viceversa (ossia ogni insieme di casi ditest che sddisfano il criterio rilevano gli stessi errori)

• Un criterio di selezione di test è valido per un programma se,qualora il programma non è corretto, esiste almeno un testselezionato che ha successo

• Teorema di Goodenough e GerhartIl fallimento di un test T per un programma P, selezionato da uncriterio C affidabile e valido, permette di dedurre la correttezzadel programma P

Anna Rita Fasolino- Ingegneria del Software -Testing

10

Esempio

Program raddoppia(input, output);var x, y: integer;begin read(x); y:= x*x; write(y);end

Criterio affidabile ma non valido:• T deve contenere sottoinsiemi

di {0, 2}

Criterio valido ma non affidabile:• T deve contenere sottoinsiemi

di {0,1, 2, 3, 4}

Criterio valido e affidabile:• T deve contenere almeno un

valore maggiore di 3

6

Anna Rita Fasolino- Ingegneria del Software -Testing

11

Selezione dei casi di test

• Teorema di Howden– Non esiste un algoritmo che, dato un programma arbitrario P,

generi un test ideale finito, e cioè un test definito da un criterioaffidabile e valido

• Al di là di casi banali, non è possibile costruire un criterio diselezione generale di test valido e affidabile che non sia il testesaustivo

• Obiettivi pratici– massimizzare il numero di malfunzionamenti scoperti (richiede molti

casi di test)

– minimizzare il numero di casi di test (e quindi il costo del testing)

• E’ preferibile usare più di un criterio di selezione dei test

Anna Rita Fasolino- Ingegneria del Software -Testing

12

Classi di criteri di selezione

• Criteri black-box o funzionali– dipendono solo dalle

specifiche del software

• Suddivisione in classi diequivalenza

• Analisi dei valori limite• Grafi causa-effetto

• Criteri white-box o strutturali– dipendono dalla struttura

interna del software

• Criteri basati sul flusso dicontrollo

• Criteri basati sul flusso deidati

• Analisi mutazionale

Sono spesso usati in maniera complementare

7

Anna Rita Fasolino- Ingegneria del Software -Testing

13

Suddivisione in classi di equivalenza

• Il dominio dei dati di ingresso è suddiviso in classi dicasi di test in modo tale che, se il programma ècorretto per un caso di test, si possa dedurreragionevolmente che è corretto per ogni caso di testin quella classe

• Una classe di equivalenza rappresenta un insieme distati validi o non validi per una condizione sullevariabili d’ingresso

Anna Rita Fasolino- Ingegneria del Software -Testing

14

Definizione delle classi di equivalenza

• Se la condizione sulle variabili d’ingresso specifica:– intervallo di valori

• una classe valida per valori interni all’intervallo, una non validaper valori inferiori al minimo, e una non valida per valorisuperiori al massimo

– valore specifico• una classe valida per il valore specificato, una non valida per

valori inferiori, e una non valida per valori superiori

– elemento di un insieme discreto• una classe valida per ogni elemento dell’insieme, una non

valida per un elemento non appartenente

– valore booleano• una classe valida per il valore TRUE, una classe non valida per

il valore FALSE

8

Anna Rita Fasolino- Ingegneria del Software -Testing

15

Selezione dei casi di test dalle classi diequivalenza

• Ogni classe di equivalenza deve essere coperta daalmeno un caso di test

– Un caso di test per ogni classe non valida

– Ciascun caso di test per le classi valide deve comprendere ilmaggior numero di classi valide ancora scoperte

Anna Rita Fasolino- Ingegneria del Software -Testing

16

Esercizio

• L’utente può chiamare la banca usando il propriocomputer collegato via modem, digitare una password di6 cifre, e digitare vari comandi che consentono diaccedere alle varie funzioni bancarie (trasferimento fondi,estratto conto, saldo, fine sessione). L’utente non puòtrasferire meno di 100.000 lire e più di un milione pertelefonata

• Selezionare i casi di test mediante partizione in classi diequivalenza

9

Anna Rita Fasolino- Ingegneria del Software -Testing

17

Le condizioni sull’input ‘password’

Condizioni d’ingresso:• La password può avere una valore compreso tra

“000000” e “999999”

Classi di equivalenza:• Valida

CE1 : 000000 ≤ PASSWORD ≤ 999999

• Non valideCE2 : COD < 000000CE3 : COD > 999999

Anna Rita Fasolino- Ingegneria del Software -Testing

18

Le condizioni sull’input ‘comando’

Condizioni di ingresso:

– Il comando può essere di tipo: trasferimento fondi, estrattoconto, saldo, fine sessione

Classi di equivalenzaValideCE5: COMANDO = trasferimento fondi

CE6: COMANDO = estratto contoCE7: COMANDO = saldo

CE8: COMANDO = fine sessione

• Non validaCE9: COMANDO = moltiplica

10

Anna Rita Fasolino- Ingegneria del Software -Testing

19

Le condizioni sull’input ‘importo’

Condizioni di ingresso:

– L’importo non può essere maggiore di 1.000.000 nè minoredi 100.000

Classi di equivalenzaValidaCE10: 100.000<= IMPORTO<=1.000.000

• Non valideCE11: IMPORTO< 100.000

CE12: IMPORTO> 1.000.000

Anna Rita Fasolino- Ingegneria del Software -Testing

20

Selezione dei casi di test

CONDIZIONI CLASSI DI EQUIVALENZA##CE Valide ##CE Non valide

Valore dellapassword tra 000000e 999999

CE1 000000≤≤ passwordAND

password ≤≤ 999999

CE2CE3

password< 000000password > 999999

Tipo di comando: CE4

CE5

CE6

CE7

TrasferimentoEstratto contoSaldoFine sessione

CE8 Moltiplica

L’importo deveessere tra 100.000 e1.000.000

CE9 100.000 ≤≤ importoAND

importo ≤≤ 1.000.000

CE10

CE11

importo< 100000importo > 1000000

11

Anna Rita Fasolino- Ingegneria del Software -Testing

21

Scelta dei casi di test ...

Test case TC1 TC2 TC3

password 123456 123456 123456

comando trasferimento estratto conto saldo

importo 800.000 800.000 800.000

Classi coperte CE1, CE4, CE9 CE1, CE5, CE9 CE1, CE6, CE9

Test case TC4 TC5 TC6

password 123456 123 1234567

comando fine sessione estratto conto saldo

importo 800.000 800.000 800.000

Classi coperte CE1, CE7, CE9 CE2, CE5, CE9 CE3, CE6, CE9

Anna Rita Fasolino- Ingegneria del Software -Testing

22

… Scelta dei casi di test

Test case TC7 TC8 TC9

password 123456 123456 123456

comando moltiplica estratto conto saldo

importo 800.000 50.000 10.000.000

Classi coperte CE1, CE8, CE9 CE1, CE5, CE10 CE1, CE6, CE11

12

Anna Rita Fasolino- Ingegneria del Software -Testing

23

Analisi dei valori limite

• I casi di test che esplorano condizioni limite spessorilevano la presenza di malfunzionamenti

• Le condizioni limite:– sono direttamente agli estremi– immediatamente al di sopra– immediatamente al di sottodegli estremi di:– classi di equivalenza di ingresso– classi di equivalenza di uscita

• Le condizioni limite possono essere molto sottili– usare la creatività per cercare altre situazioni estreme

Anna Rita Fasolino- Ingegneria del Software -Testing

24

Criteri basati sul flusso di controllo

Criteri di selezione• Copertura dei comandi

(statement test)• Copertura delle decisioni

(branch test)• Copertura delle condizioni

(condition test)• Copertura delle decisioni e

delle condizioni• Copertura dei cammini (path

test)• Copertura dei cammini

indipendenti

Criteri di adeguatezza• n.ro comandi eseguiti/

n.ro comandi eseguibili

• n.ro archi percorsi/ n.ro archi percorribili

• n.ro cammini percorsi/ n.ro cammini percorribili

• n.ro cammini indip. percorsi/

n.ro ciclomatico

13

Anna Rita Fasolino- Ingegneria del Software -Testing

25

UN MODELLO DI RAPPRESENTAZIONE DEIPROGRAMMI: il Control-Flow Graph

Il grafo del flusso di controllo (Control-Flow Graph) di un programma P:

CFG (P) = <N, AC, nI, nF>

dove:

<N, AC> è un grafo diretto con archi etichettati,

{nI, nF} ⊆⊆ N, N- {nI, nF} = Ns∪∪ Np

Ns e Np sono insiemi disgiunti di nodi istruzione e nodi predicato;

AC ⊆⊆ N-{nF}×× N-{nI } ×× {vero, falso, incond} rappresenta la relazione flussodi controllo; nI ed nF sono detti rispettivamente nodo iniziale e nodo finale.

• Un nodo n∈∈ Ns ∪ ∪ {nI} ha un solo successore immediato e il suo arco uscenteè etichettato con incond.

• Un nodo n∈∈Np ha due successori immediati e i suoi archi uscenti sonoetichettati rispettivamente con vero e falso.

Anna Rita Fasolino- Ingegneria del Software -Testing

26

procedure Quadrato; var x, y, n: integer; begin 1. read(x); 2. if x > 0 then begin 3. n := 1; 4. y := 1; 5. while x > 1 do begin 6. n := n + 2; 7. y := y + n; 8. x := x - 1; end; 9. write(y); end; end;

I

1

2

3

4

5

6

7

8

9

F

true false

false

true

true false

true false

I

1,2

3,4,5

6,7,8

9

F

14

Anna Rita Fasolino- Ingegneria del Software -Testing

27

• Copertura dei comandi (statement test)– ogni nodo del CFG deve essere eseguito almeno una volta durante il testing; è un

criterio di copertura debole, che non assicura la copertura sia del ramo true chefalse di una decisione

• Copertura delle decisioni (branch test)– ciascun arco del CFG deve essere attraversato almeno una volta; ogni decisione è

valutata sia nel caso true che false; un limite è legato alle decisioni in cui piùcondizioni (legate da operatori logici AND ed OR) sono valutate

• Copertura delle condizioni (condition test)– ciascuna condizione nei nodi decisione di un CFG deve essere valutata sia per

valori true che false.int check (x);// controlla se un intero è fra 0 e 100int x;{ if ((x>=0) && (x<= 200))

check= true; else check = false;

}TC={x=5, x=-5 } valuta la decisione sia per valori True che False, ma non le condizioni

• Copertura delle decisioni e delle condizioni– non basta assicurare la copertura delle condizioni, ma anche quella delle decisioni

Anna Rita Fasolino- Ingegneria del Software -Testing

28

Criteri di copertura dei cammini

• Copertura dei cammini (path test)– spesso gli errori si verificano eseguendo cammini che includono

particolari sequenze di nodi decisione

– non tutti i cammini eseguibili in un CFG possono essere eseguitidurante il test (un CFG con loop può avere infiniti cammini eseguibili)

• Copertura dei cammini indipendenti– ci si limita ad eseguire un insieme di cammini indipendenti di un CFG,

ossia un insieme di cammini in cui nessun cammino è completamentecontenuto in un altro dell’insieme, nè è la combinazione di altri camminidell’insieme

– ciascun cammino dell’insieme presenterà almeno un arco non presentein qualche altro cammino

– il numero di cammini indipendenti coincide con la complessitàciclomatica del programma

15

Anna Rita Fasolino- Ingegneria del Software -Testing

29

Complessità ciclomatica di un programma

true false

true false

0

1

2

3

4

5

Dato un grafo G di n nodi ed e archiil numero ciclomatico è dato da:

V(G) = e- n+ 2oppure:V(G)= d + 1d= # nodi branch

V(G)= 3 =>3 cammini indipendenti

c1= 0-1-2-4-5c2= 0-1-2-3-2-4-5c3= 0-1-5

Compessità ciclomatica del programma è 3

Anna Rita Fasolino- Ingegneria del Software -Testing

30

Livelli di testing

Principi• I test vanno pianificati in

anticipo• I test devono cominciare

in piccolo e proseguire ingrande

Bisogni del cliente

Requisiti

Progetto

Codice

Test diaccettazione

Test di sistema

Test di integrazione

Test di unità

Test di regressioneModifiche

16

Anna Rita Fasolino- Ingegneria del Software -Testing

31

LIVELLI DI TESTING

livello produttore

unit testing (Testing di Unità)

integration testing (Testing di Integrazione)

system testing (Testing di Sistema)

livello cooperativo produttore-cliente privilegiato

alpha testing

beta testing

livello cliente o utente

acceptance testing (Testing di accettazione)

Anna Rita Fasolino- Ingegneria del Software -Testing

32

Testing di unità (..detta anche di modulo..)

• il testing é applicato isolatamente ad una unità oad un modulo di un sistema software;

• obiettivo fondamentale é quello di rilevare errori(logica e dati) nel modulo;

• prassi diffusa é che esso venga realizzato dalprogrammatore che ha prodotto l'unità sotto test.

• unità: elemento definito nel progetto di unsistema software e testabile separatamente;

• nel testing unità e modulo sono spesso usaticome sinonimi.

17

Anna Rita Fasolino- Ingegneria del Software -Testing

33

Testing d’integrazione

• il testing é applicato ad un aggregato di due o più unità diun sistema software;

• l'obiettivo é quello di rilevare errori nelle interazioni fra leunità e nelle funzioni che l'aggregato deve assolvere;

• non é compito dei programmatori che hanno prodotto leunità componenti

• le unità da integrare sono selezionabili in base a criterifunzionali ricavabili dal progetto (architettura del sistema);

• partendo da una architettura organizzata gerarchicamente,le integrazioni possono essere realizzate con approcciotop-down o bottom-up

Anna Rita Fasolino- Ingegneria del Software -Testing

34

Testing di sistema

• il testing é applicato al sistema software completoed integrato;

• l'obiettivo è quello di valutare l'adesione del sistemaai requisiti specificati;

• va effettuato dal team addetto al testing

• i requisiti del sistema non sono solo le funzionalitàesterne;

• fondamentali sono i requisiti di qualità, stabiliti adesempio sulla base di un modello di qualità delprodotto opportunamente istanziato

18

Anna Rita Fasolino- Ingegneria del Software -Testing

35

Testing di accettazione

• testing effettuato sull'interosistema sulla base di un pianoe di procedure approvate dalcliente (o utente);

• l'obiettivo é quello di mettere ilcliente, l'utente o altri a ciòpreposti ( collaudatori o enti adhoc) in condizione di deciderese accettare il prodotto;

• é a carico del committente;

• segna il passaggio delsistema dal produttoreall'ambiente operativo;

• ..é più 'una dimostrazione cheun test'

Anna Rita Fasolino- Ingegneria del Software -Testing

36

2 livelli di test di accettazione

• alpha testing uso del sistema da parte di utenti reali manell'ambiente di produzione e prima della immissionesul mercato

• beta testing:installazione ed uso del sistema in ambiente realeprima della immissione sul mercato

tipicamente adottati dai produttori di packages per mercato di massa

19

Anna Rita Fasolino- Ingegneria del Software -Testing

37

Testing di programmi orientati agli oggetti

• I criteri black-box non sono influenzati

• La struttura OO può avere impatto sui criteri white-box

• Test di unità– operazioni di una classe: stessi criteri applicabili– classe di oggetti:sono necessari altri criteri

• è l’oggetto che può essere testato, non la classe

• all’interno di una classe non c’è un unico flusso di controllo (acausa dello scambio di messaggi)

• lo stato di un oggetto influenza il risultato

• problemi dovuti all’uso di ereditarietà

• problemi legati all’uso di binding dinamico

Anna Rita Fasolino- Ingegneria del Software -Testing

38

Piano di test

• Documento relativo all’intero progetto

• Struttura– specifica delle unità di test (per un dato livello di test) Es.

Modulo, gruppi di moduli, programma, sottosistemi, interosistema

– Caratteristiche da testare: funzionalità, prestazioni, vincoli diprogetto, sicurezza…

– Approccio: criterio di selezione dei test, criterio diterminazione, strumenti

– Prodotti del test: es. Casi di test, rapporto finale, diario deltest, statistiche di copertura…

– Schedulazione: quando effettuare il testing e lo sforzo perattività

– Allocazione del personale

20

Anna Rita Fasolino- Ingegneria del Software -Testing

39

Specifica dei casi di test

• Per ogni livello di test– n.ro di caso di test– input– condizione da testare– output atteso

• Effettuato il test, si può completare con– output osservato

• Le specifiche ed i casi di test possono essere riusati per iltest di regressione

Anna Rita Fasolino- Ingegneria del Software -Testing

40

Esecuzione del test

• Costruzione di Moduli guida (invocano l’unità sotto test)

• Moduli fittizi (sono invocati dall’unità sotto test)

Modulo guida

Unità sotto test

Modulo fittizio

21

Anna Rita Fasolino- Ingegneria del Software -Testing

41

Rapporti sul test

• Diario del test– descrive i dettagli del test per come si è svolto effettivamente– la specifica dei casi di test può essere completata e usata

come diario

• Riepilogo del test– Rivolto al management del progetto

• numero totale di casi di test eseguiti• numero e tipo di malfunzionamenti osservati

• numero e tipo di difetti scoperti

• Sommario dei malfunzionamenti– Rivolto a chi deve effettuare il debugging o la correzione