testing - wpage.unina.itwpage.unina.it/fasolino/is/materiale/9-testing.pdf · 3 anna rita fasolino-...
TRANSCRIPT
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