Testing

Transcript

Testing

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
1
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
1
Relazione fra Errore, Difetto e
Malfunzionamento
causa
errore
1..*
causa
Difetto
1..*
Malfunzionamento
1..*
3
Definizioni
• Il Testing (collaudo) è un processo di esecuzione del
software 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ò solo
dimostrare la presenza di difetti
• Il Debugging è il processo di scoperta dei difetti a partire
da malfunzionamenti noti
• L’Ispezione è un processo di analisi del software per
scoprirne i difetti
4
2
Problemi del testing
• Criterio di selezione dei casi di test
• Valutazione dei risultati del test
• Criterio di terminazione del testing
5
Valutazione dei risultati del test
Casi di test
•
Condizione necessaria per
effettuare un test:
– conoscere il comporatmento
atteso per poterlo confrontare con
quello osservato
•
•
L’oracolo conosce il
comportamento atteso per ogni
caso di prova
Oracolo umano
Software
da
testare
Oracolo
– si basa sulle specifiche o sul
giudizio
•
Oracolo automatico
– generato dalle specifiche (formali)
– stesso software ma sviluppato da
altri
– versione precedente (test di
regressione)
Comparatore
Risultati del test
6
3
Terminazione del testing
• Quando il programma si può ritenere analizzato a
sufficienza
– Criterio temporale: periodo di tempo predefinito
– Criterio di costo: sforzo allocato predefinito
– Criterio di copertura:
• percentuale predefinita degli elementi di un modello di
programma
• 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
7
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 test
ideale
8
4
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 successo
anche T2 ha successo e viceversa (ossia ogni insieme di casi di
test 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 test
selezionato che ha successo
Teorema di Goodenough e Gerhart
Il fallimento di un test T per un programma P, selezionato da un
criterio C affidabile e valido, permette di dedurre la correttezza
del programma P
9
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
10
5
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 criterio
affidabile e valido
•
•
Al di là di casi banali, non è possibile costruire un criterio di
selezione generale di test valido e affidabile che non sia il test
esaustivo
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
11
Classi di criteri di selezione
•
Criteri black-box o funzionali
•
– dipendono solo dalle
specifiche del software
•
•
•
Suddivisione in classi di
equivalenza
Analisi dei valori limite
Grafi causa-effetto
Criteri white-box o strutturali
– dipendono dalla struttura
interna del software
•
•
•
Criteri basati sul flusso di
controllo
Criteri basati sul flusso dei
dati
Analisi mutazionale
Sono spesso usati in maniera complementare
12
6
Suddivisione in classi di equivalenza
• Il dominio dei dati di ingresso è suddiviso in classi di
casi di test in modo tale che, se il programma è
corretto per un caso di test, si possa dedurre
ragionevolmente che è corretto per ogni caso di test
in quella classe
• Una classe di equivalenza rappresenta un insieme di
stati validi o non validi per una condizione sulle
variabili d’ingresso
13
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 valida
per valori inferiori al minimo, e una non valida per valori
superiori 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
14
7
Selezione dei casi di test dalle classi di
equivalenza
• Ogni classe di equivalenza deve essere coperta da
almeno un caso di test
– Un caso di test per ogni classe non valida
– Ciascun caso di test per le classi valide deve comprendere il
maggior numero di classi valide ancora scoperte
15
Esercizio
• L’utente può chiamare la banca usando il proprio
computer collegato via modem, digitare una password di
6 cifre, e digitare vari comandi che consentono di
accedere 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 per
telefonata
• Selezionare i casi di test mediante partizione in classi di
equivalenza
16
8
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 valide
CE2 : COD < 000000
CE3 : COD > 999999
17
Le condizioni sull’input ‘comando’
Condizioni di ingresso:
– Il comando può essere di tipo : trasferimento fondi, estratto
conto, saldo, fine sessione
Classi di equivalenza
Valide
CE5: COMANDO = trasferimento fondi
CE6: COMANDO = estratto conto
CE7: COMANDO = saldo
CE8: COMANDO = fine sessione
•
Non valida
CE9: COMANDO = moltiplica
18
9
Le condizioni sull’input ‘importo’
Condizioni di ingresso:
– L’importo non può essere maggiore di 1.000.000 nè minore
di 100.000
Classi di equivalenza
Valida
CE10: 100.000<= IMPORTO<=1.000.000
•
Non valide
CE11: IMPORTO< 100.000
CE12: IMPORTO> 1.000.000
19
Selezione dei casi di test
CONDIZIONI
CLASSI DI EQUIVALENZA
# CE
Valide
# CE
Non valide
Valore della
CE1 000000 ≤ password CE2 password< 000000
password tra 000000
CE3 password > 999999
AND
e 999999
password ≤ 999999
Tipo di comando:
L’importo deve
essere tra 100.000 e
1.000.000
CE4
CE5
CE6
CE7
CE9
Trasferimento
CE8 Moltiplica
Estratto conto
Saldo
Fine sessione
100.000 ≤ importo CE 10 importo< 100000
CE 11 importo > 1000000
AND
importo ≤ 1.000.000
20
10
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
21
… 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
22
11
Analisi dei valori limite
• I casi di test che esplorano condizioni limite spesso
rilevano la presenza di malfunzionamenti
• Le condizioni limite:
– sono direttamente agli estremi
– immediatamente al di sopra
– immediatamente al di sotto
degli 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
23
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
24
12
UN MODELLO DI RAPPRESENTAZIONE DEI
PROGRAMMI: 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 flusso
di 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 sono
etichettati rispettivamente con vero e falso.
25
I
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
1,2
2
true
true
false
3
false
3,4,5
true
4
5
true
6
false
6,7,8
false
7
9
8
F
9
F
26
13
•
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 che
false 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 100
int 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
27
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 eseguiti
durante 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 è completamente
contenuto in un altro dell’insieme, nè è la combinazione di altri cammini
dell’insieme
– ciascun cammino dell’insieme presenterà almeno un arco non presente
in qualche altro cammino
– il numero di cammini indipendenti coincide con la complessità
ciclomatica del programma
28
14
Complessità ciclomatica di un programma
Dato un grafo G di n nodi ed e archi
il numero ciclomatico è dato da:
0
1
true
false
V(G) = e- n+ 2
oppure:
V(G)= d + 1
d= # nodi branch
2
true
false
3
V(G)= 3 =>3 cammini indipendenti
4
5
Compessità ciclomatica
del programma è 3
c1= 0-1-2-4-5
c2= 0-1-2-3-2-4-5
c3= 0-1-5
29
Livelli di testing
Principi
• I test vanno pianificati in
anticipo
• I test devono cominciare
in piccolo e proseguire in
grande
Bisogni
del cliente
Requisiti
Test di
sistema
Progetto
Test di
integrazione
Codice
Modifiche
Test di
accettazione
Test di unità
Test di regressione
30
15
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)
31
Testing di unità (..detta anche di modulo..)
•
il testing é applicato isolatamente ad una unità o
ad un modulo di un sistema software;
•
obiettivo fondamentale é quello di rilevare errori
(logica e dati) nel modulo;
•
prassi diffusa é che esso venga realizzato dal
programmatore che ha prodotto l'unità sotto test.
•
unità: elemento definito nel progetto di un
sistema software e testabile separatamente;
•
nel testing unità e modulo sono spesso usati
come sinonimi.
32
16
Testing d’integrazione
•
il testing é applicato ad un aggregato di due o più unità di
un sistema software;
•
l'obiettivo é quello di rilevare errori nelle interazioni fra le
unità e nelle funzioni che l'aggregato deve assolvere;
•
non é compito dei programmatori che hanno prodotto le
unità componenti
•
le unità da integrare sono selezionabili in base a criteri
funzionali ricavabili dal progetto (architettura del sistema);
•
partendo da una architettura organizzata gerarchicamente,
le integrazioni possono essere realizzate con approccio
top-down o bottom-up
33
Testing di sistema
• il testing é applicato al sistema software completo
ed integrato;
• l'obiettivo è quello di valutare l'adesione del sistema
ai 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 ad
esempio sulla base di un modello di qualità del
prodotto opportunamente istanziato
34
17
Testing di accettazione
•
testing effettuato sull'intero
sistema sulla base di un piano
e di procedure approvate dal
cliente (o utente);
•
l'obiettivo é quello di mettere il
cliente, l'utente o altri a ciò
preposti ( collaudatori o enti ad
hoc) in condizione di decidere
se accettare il prodotto;
•
é a carico del committente;
•
segna il passaggio del
sistema dal produttore
all'ambiente operativo;
•
..é più 'una dimostrazione che
un test'
35
2 livelli di test di accettazione
• alpha testing
uso del sistema da parte di utenti reali ma
nell'ambiente di produzione e prima della immissione
sul mercato
• beta testing:
installazione ed uso del sistema in ambiente reale
prima della immissione sul mercato
tipicamente adottati dai produttori di packages per mercato di massa
36
18
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 (a
causa 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
37
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, intero
sistema
– Caratteristiche da testare: funzionalità, prestazioni, vincoli di
progetto, sicurezza…
– Approccio: criterio di selezione dei test, criterio di
terminazione, strumenti
– Prodotti del test: es. Casi di test, rapporto finale, diario del
test, statistiche di copertura…
– Schedulazione: quando effettuare il testing e lo sforzo per
attività
– Allocazione del personale
38
19
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 il
test di regressione
39
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
40
20
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
41
21

Testing

Transcript

Documenti analoghi

Introduzione al corso

dalla conoscenza all`impresa innovativa per un ingegnere elettrico

14-002950-PR01 PB-A01-02-IT-01.cdr

Testi del Syllabus

Software Testing

brochure - Ita-Stqb

Adeguatezza dei test alla criticità del software

Analysis of extra effort for Change in Scope