Tecniche di Testing Black Box Riferimenti

Tecniche di Testing Black Box
Ingegneria del Software 2
Testing Black Box
1
Riferimenti
• Ian Sommerville, Ingegneria del Software, capitoli 2223-24
• Pressman, Principi di Ingegneria del Software, 5°
edizione, Capitoli 15-16
• Ghezzi, Jazazeri, Mandrioli, Ingegneria del Software, 2°
edizione, Capitolo 6 (più dettagliato sulle tecniche)
Ingegneria del Software 2
Testing Black Box
2
1
Software Testing
•
Uno dei metodi pratici più usati per scoprire la presenza di
difetti in un programma (osservandone i fallimenti) è di
testarlo con un insieme di valori di input.
The output
is correct?
I1, I2, I3,
…, In, …
Programma
- No code inspection
- No model checking
- No debugging
“Inputs”
Ingegneria del Software 2
Expected results
=?
Obtained results
- No code analysis
- No bug fixing
Testing Black Box
3
Testing: i problemi da affrontare
•
A quale livello eseguire il Testing?
– Unit Testing
– Integration Testing
– System Testing
•
Come scegliere gli input?
– Usando le specifiche/ i casi d’uso/ i requisiti (Black-box)
– Usando il codice (White-box)
•
Come definire gli output attesi?
– Definizione di Oracoli di test (Oracoli umani o automatici)
•
Quando terminare l’attività di testing?
– Come decidere se i nostri test sono validi?
Ingegneria del Software 2
Testing Black Box
4
2
Livelli di Testing
• Unit Testing:
– Si testano singole funzioni/ procedure/ metodi/ classi
• Integration Testing
– Si controlla che le unità, già testate isolatamente, funzionino
correttamente una volta integrate fra loro
• System Testing
– Si controlla che l’intero sistema sia in grado di funzionare
con dati reali, in un ambiente reale, e se ne valutano le
prestazioni, la capacità di gestire le situazioni di errore e di
recupero da errori.
Ingegneria del Software 2
Testing Black Box
5
Due principali Tecniche di Testing
•
Testing funzionale (o Black Box):
–
–
–
–
–
•
Richiede l’analisi degli output generati dal sistema (o da suoi
componenti) in risposta ad input (test cases) definiti sulla base
della sola conoscenza dei requisiti del sistema (o di suoi
componenti).
Testing basato sui requisiti;
Testing delle partizioni;
Test basato su Tabelle di Decisione;
Test basato su Grafi Causa-Effetto.
Testing strutturale (o White Box).
–
fondato sulla conoscenza della struttura del software, ed in
particolare del codice, degli input associati e dell’oracolo, per la
definizione dei casi di prova.
Ingegneria del Software 2
Testing Black Box
6
3
1- Testing basato sui requisiti
•
Il principio della verificabilità dei requisiti afferma che i
requisiti dovrebbero essere testabili, cioè scritti in
modo da consentire di progettare test che dimostrino
che il requisito è stato soddisfatto.
•
Il testing basato sui requisiti è una tecnica di convalida
dove vengono progettati vari test per ogni requisito.
Ingegneria del Software 2
Testing Black Box
7
Esempio di tecnica di derivazione dei Test a partire
dai requisiti
• Alcuni requisiti di un Sistema per la consultazione di
Articoli da più database (v. Sommerville):
– RF1: L’utente deve poter scegliere se eseguire ricerche in tutti i
database o in un sotto-insieme di essi.
– RF2: Il sistema deve fornire appropriati visualizzatori per
leggere i vari documenti reperiti.
– RF3: L’utente può ordinare una copia di articolo da scaricare in
locale
– RF4: Ad ogni ordine dovrebbe essere associato un
identificatore (ORDER_ID) che l’utente deve poter copiare
nella sua area di memoria buffer.
• Per ciascun requisito si progetteranno una o più prove
Ingegneria del Software 2
Testing Black Box
8
4
Esempio
• RF1: L’utente deve poter scegliere se eseguire ricerche
in tutti i database o in un sotto-insieme di essi
• 1: Scegliere di eseguire ricerche sia di elementi presenti che non
presenti nel database, considerando un solo database.
• 2: Scegliere di eseguire ricerche sia di elementi presenti che non
presenti nel database, considerando due database.
• 3: Scegliere di eseguire ricerche sia di elementi presenti che non
presenti nel database, considerando più di due database.
• In genere saranno necessari più test per ciascun requisito
Ingegneria del Software 2
Testing Black Box
9
Derivazione di Casi di Test a partire dai Casi d’uso
• Avendo a disposizione un Diagramma dei Casi d’uso e
le descrizioni degli scenari dei Casi d’uso (attraverso
pre-post condizioni e flussi di eventi)…
• Si dovrà definire almeno un caso di test per ogni
scenario
– Gli input saranno scelti in modo da esercitare lo specifico
scenario
• Si potranno aggiungere anche casi di test per
esercitare combinazioni di più casi d’uso
Ingegneria del Software 2
Testing Black Box
10
5
Esempio
System
Registrazione
Cliente
Registrazione apparato elettronico
Richiesta assistenza
Registrazione dati apparato riparato
Tecnico
Un cliente registrato può registrare i propri apparati
elettronici in un database di registrazioni, inserendo il
proprio identificativo numerico (di 5 cifre), la tipologia
(TV o HI-FI), la marca (una stringa di 10 caratteri
alfabetici), il modello (una stringa alfanumerica di 5
caratteri) e il numero di serie dell’apparato (numero
intero di 6 cifre).
Il sistema, dopo aver verificato la validità
dell’identificativo del cliente e degli altri input inseriti,
aggiunge automaticamente la data al momento della
registrazione.
Es.: UC-Registrazione Apparecchio Elettronico:
• Uno scenario normale in cui sono forniti dal cliente dati validi per il
suo ID-cliente e per l’apparecchio (ossia marca, modello, numero di serie)
• Uno scenario alternativo in cui il cliente inserisce un ID-cliente non valido
• Uno scenario alternativo in cui il cliente inserisce almeno un dato apparecchio
non valido
Si sceglieranno gli input necessari a coprire i tre scenari almeno una volta
Ingegneria del Software 2
Testing Black Box
11
2- Testing delle Partizioni (o delle Classi di
Equivalenza)
•
I dati di input ed output possono essere in genere suddivisi
in classi dove tutti i membri di una stessa classe sono in
qualche modo correlati.
•
Ognuna delle classi costituisce una classe di equivalenza
(una partizione) ed il programma si comporterà
(verosimilmente) nello stesso modo per ciascun membro
della classe.
•
I casi di Test dovrebbero essere scelti all’interno di
ciascuna partizione .
•
La tecnica è applicabile sia per il Testing di Unità che di
Sistema
Ingegneria del Software 2
Testing Black Box
12
6
Classi di Equivalenza
Invalid inputs
Valid inputs
System
Outputs
Ingegneria del Software 2
Testing Black Box
13
Suddivisione in classi di equivalenza
• Le partizioni sono identificate usando le specifiche del
programma o altra documentazione.
• Una possibile suddivisione è quella in cui la classe di
equivalenza rappresenta un insieme di stati validi o non
validi per una condizione sulle variabili d’ingresso.
Ingegneria del Software 2
Testing Black Box
14
7
Esempio
•
•
Dato di Input: password
Condizione di validità per password:
–
•
la password deve essere una stringa alfanumerica di
lunghezza compresa fra 6 e 10 caratteri.
Classi di Equivalenza:
–
–
Una classe valida CV1 è quella composta dalle stringhe di
lunghezza fra 6 e 10 caratteri.
Due classi non valide :
• CNV2 che include le stringhe di lunghezza <6
• CNV3 che include le stringhe di lunghezza >10
Ingegneria del Software 2
Testing Black Box
15
Generalizzando…
• 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 per il valore FALSE
Ingegneria del Software 2
Testing Black Box
16
8
Scelta dei Casi di Test a partire dalle Classi di
Equivalenza
• Regole pratiche per la Scelta:
• 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
• Cercare di coprire anche i confini delle partizioni
Ingegneria del Software 2
Testing Black Box
17
Esercizio
• In un modulo Web bisogna inserire la propria data di nascita,
composta di giorno (numerico), mese (stringa che può valere
gennaio … dicembre), anno (numerico, compreso tra 1900 e
2000).
• Selezionare i casi di test mediante partizionamento in classi di
equivalenza
Ingegneria del Software 2
Testing Black Box
18
9
Le condizioni sull’input ‘giorno’
•Condizioni d’ingresso:
• Il giorno può essere compreso tra 1 e 31
•Classi di equivalenza:
• Valida
CE1 : 1 ? GIORNO ? 31
• Non valide
CE2 : GIORNO < 1
CE3 : GIORNO > 31
CE4 : GIORNO non è un numero intero
Ingegneria del Software 2
Testing Black Box
19
Le condizioni sull’input ‘mese’
•Condizioni di ingresso:
– Il mese deve essere nell’insieme M=(gennaio, febbraio, marzo, aprile,
maggio, giugno, luglio, agosto, settembre, ottobre, novembre,
dicembre)
•Classi di equivalenza
– Valide
CE51: MESE = gennaio, CE52: MESE = febbraio, CE53: MESE = marzo, ….
(Tot. 12 classi di equivalenza)
- Non valida
CE6: MESE ? M
Ingegneria del Software 2
Testing Black Box
20
10
Le condizioni sull’input ‘anno’
•Condizioni di ingresso:
– Deve essere compreso tra 1900 e 2000
•Classi di equivalenza
•
Valida
CE 7: 1900<= ANNO<=2000
•
Non valide
CE 8: ANNO< 1900
CE 9: ANNO> 2000
CE 10: ANNO non è un numero intero
Ingegneria del Software 2
21
Testing Black Box
Scelta dei casi di test ...
Test case
TC1
TC2
TC3
TC4
Giorno
1
1
1
1
Mese
gennaio
febbraio
marzo
aprile
Anno
1980
1492
2018
duemila
Classi coperte
CE1, CE51, CE7
CE1, CE52, CE8
CE1, CE53, CE9
CE1, CE54, CE10
Test case
TC5
TC6
TC7
TC8
Giorno
1
0
35
primo
Mese
brumaio
maggio
giugno
luglio
Anno
1980
1980
1980
1980
Classi coperte
CE1, CE6, CE7
CE2, CE55, CE7
CE3, CE56, CE7
CE4, CE57, CE7
Ogni TC copre al più una CE non valida!
Ingegneria del Software 2
Testing Black Box
22
11
Scelta dei casi di test
Test case
TC9
TC10
T11
TC12
Giorno
1
1
1
1
Mese
agosto
settembre
ottobre
novembre
Anno
1980
1980
1980
1980
Classi coperte
CE1, CE58, CE7
CE1, CE59, CE7
CE1, CE510, CE7
CE1, CE511, CE7
Test case
TC13
Giorno
1
Mese
dicembre
Anno
1980
Classi coperte
CE1, CE512, CE7
Ingegneria del Software 2
Testing Black Box
23
Efficacia ed Efficienza del Testing
• Per valutare la bontà della test suite bisognerebbe
valutare contemporaneamente:
– L’efficacia, in termini di malfunzionamenti trovati
– L’efficienza, in termini di numero di casi di test che riescono
a scoprire malfunzionamenti
• Per migliorare l’efficacia servirebbero più test
– Ad esempio considerando Test suite che coprano non solo
le singole classi di equivalenza, ma anche le combinazioni
delle classi di equivalenza
• Per migliorare l’efficienza bisognerebbe invece ridurre
il numero di test
Ingegneria del Software 2
Testing Black Box
24
12
Trade-off tra Efficacia ed Efficienza
• Nell’esempio precedente, la Test Suite comprendente TC1…TC13
copre tutte le classi di equivalenza (ma non tutte le possibili
combinazioni … )
– Ad esempio, non abbiamo testato la combinazione associata alla data
di nascita del 30 febbraio !
• Nel nostro caso, proporre casi di test in grado di sollecitare tutte le
combinazioni ammissibili degli input farebbe aumentare l’efficacia
della test suite riducendo l’efficienza
– L’efficacia va privilegiata quando si vuole un software affidabile
– L’efficienza va privilegiata se si vuole un testing meno costoso (in
particolare se non può essere eseguito automaticamente
Ingegneria del Software 2
25
Testing Black Box
… Scelta dei casi di test
• Una Test Suite più efficiente potrebbe essere la seguente:
Test case
TC1
TC2
TC3
TC4
Giorno
1
0
35
primo
Mese
gennaio
brumaio
gennaio
gennaio
Anno
1980
1492
2018
duemila
Classi coperte
CE1, CE5, CE7
CE2, CE6, CE8
CE3, CE5, CE9
CE4, CE5, CE10
Riduco il numero di TC coprendo più classi non valide con
un solo TC ma …
•
• E’ molto più difficile individuare errori
• Ad esempio in TC2 il sistema potrebbe rispondere con
un’eccezione perchè il giorno é <1, ma potrei non accorgermi che il
sistema non controlla la validità nè di mese nè di anno!
Ingegneria del Software 2
Testing Black Box
26
13
Problemi di Copertura delle Classi di
Equivalenza
• A volte non é possibile coprire le classi di equivalenza senza imporre
particolari pre-condizioni al sistema.
•
Esempio: un sistema accetta password di tipo stringa. Classi di equivalenza
possono essere:
–
–
•
Classi valide:
• CE1: PASSWORD corrispondente ad un utente che ha diritto d’accesso
Classi non valide:
• CE2: PASSWORD corrispondente ad un utente che non ha diritto d’accesso
• CE3: PASSWORD vuota
Nella descrizione dei casi di test bisogna quindi tener conto di precondizioni:
Precondizione
Input
Output Atteso
‘pippo’ ha diritto d’accesso
‘pluto’ non ha diritto d’accesso
pippo
pluto
Stringa vuota
‘Accesso consentito’
‘Accesso non consentito’‘
‘Errore’
Ingegneria del Software 2
Testing Black Box
27
Settare ed Osservare lo stato del sistema
– Non sempre è possibile osservare lo stato di un sistema, nè
poter settare precondizioni e postcondizioni
– In questi casi non è possibile nemmeno valutare l’efficacia del
criterio, per cui l’affidabilità del test è incognita
• In questi casi si può solo cercare di fare quanti più test possibili,
oppure ricavare i test dall’osservazione dell’utilizzo reale
dell’applicazione
Ingegneria del Software 2
Testing Black Box
28
14
Tecnica dei valori limite (boundaries)
• Una variante alla tecnica delle classi di equivalenza consiste nel
considerare anche i valori limite (boundaries)
• In pratica, vengono specializzate delle ulteriori classi di
equivalenza valide e non valide corrispondenti ai valori limite degli
insiemi di validità dei dati
• Si applica efficacemente a sottoinsiemi di insiemi continui (interi,
reali), in particolare ad intervalli
• Sono boundary values anche quei valori per i quali si suppone
possa esserci un comportamento particolare rispetto a qualche
operazione
– Ad esempio il valore zero per un intero che potrebbe rientrare
in una divisione o per un puntatore
Ingegneria del Software 2
Testing Black Box
29
Casi tipici di boundaries
• Se la condizione sulle variabili d’ingresso specifica:
• intervallo (chiuso) di valori
• Boundary classes: minimo dell’intervallo, massimo dell’intervallo
(classi valide), valore leggermente inferiore al minimo,
leggermente superiore al massimo (classi non valide)
• Unione di intervalli
• Ci sono boundary classes per ogni estremo di ogni
sottointervallo
• Valori interi
• Una boundary class, indipendentemente dalle specifiche, è
l’insieme {0}; un’altra, se non altrimenti considerata, è la classe
dei numeri negativi, e così via
Ingegneria del Software 2
Testing Black Box
30
15
Esempi di boundary classes
• Per l’input giorno:
– {0}: valore leggermente inferiore dell’estremo inferiore dell’intervallo e
anche valore nullo
– {1}: estremo inferiore
– {28}: estremo superiore in alcuni casi
– {29}: caso critico noto
– {30}: caso critico noto
– {31}: caso critico noto
– {32}: valore leggermente maggiore dell’estremo superiore
• Per l’input anno (le specifiche del problema imponevano anno
compreso tra 1900 e 2000)
–
–
–
–
{1899}: valore leggermente inferiore dell’estremo inferiore dell’intervallo
{1900}: estremo inferiore
{2000}: estremo superiore
{2001}: valore leggermente maggiore dell’estremo superiore
Ingegneria del Software 2
31
Testing Black Box
3-Testing basato su Tabelle di Decisione
• Le tabelle di Decisione sono uno strumento per la specifica
black-box di componenti in cui:
– A diverse combinazioni degli ingressi corrispondono
uscite/azioni diverse;
– Le varie combinazioni degli ingressi possono essere
rappresentate come espressioni booleane mutuamente
esclusive;
– Il risultato non deve dipendere da precedenti input o output, né
dall’ordine con cui vengono forniti gli input.
O1
I1
Componente
Ingegneria del Software 2
I2
O2
In
Az1
Testing Black Box
32
16
Costruzione della Tabella di Decisione
• Le colonne della Tabella rappresentano le
combinazioni degli input a cui corrispondono le
diverse azioni.
• Le righe della tabella riportano i valori delle variabili di
input (nella Sezione Condizioni) e le azioni eseguibili
(nella Sezione Azioni)
• Ogni distinta combinazione degli input viene chiamata
una Variante.
Ingegneria del Software 2
33
Testing Black Box
Template della Tabella di Decisione
Varianti
1
Condizioni
cond1
Azioni
Azione
1
2
3
4
…
Cond2
…
Condn
Azione
2
…
azione
n
Ingegneria del Software 2
Testing Black Box
n
•Le colonne della
Tabella rappresentano le
combinazioni degli input
a cui corrispondono le
diverse azioni.
•Le righe della tabella
riportano i valori delle
variabili di input (nella
Sezione Condizioni) e le
azioni eseguibili (nella
Sezione Azioni)
•Ogni colonna (distinta
combinazione degli
input) viene chiamata
una Variante
34
17
Un esempio
• Calcolo Polizza di assicurazione :
• la procedura di rinnovo annuale delle polizze
automobilistiche di una compagnia di assicurazioni
considera il Numero di Incidenti fatti e l’Età
dell’assicurato
• Numero incidenti : 0, 1, fra 2 e 4, più di 5
• Età : <=25, >=26
• In base a tali input stabilisce se:
• Aumentare il premio da pagare
• Inviare una Lettera di avvertimento
• Annullare la polizza
Ingegneria del Software 2
35
Testing Black Box
La Tabella di decisione
Varianti
Con
dizion
i
1
2
3
4
5
6
7
Numero
incidenti
0
0
1
1
Tra 2 e
4
Tra 2 e
4
5 o più
Età
assicurato
<=25
>=26
<=25
>=26
<=25
>=26
Qualsiasi
50
25
100
50
400
200
0
Lettera
No
No
Sì
No
Sì
Sì
No
Polizza
Cancellata
No
No
No
No
No
No
Sì
Azioni Aumento
Premio ($)
Ingegneria del Software 2
Testing Black Box
36
18
Varianti Esplicite ed Implicite
• Nella tabella, l’operatore logico fra le condizioni è
di And;
• Nell’esempio precedente abbiamo 6 condizioni
sugli input e 7 varianti significative, ma in generale
esistono più combinazioni possibili.
• Quante combinazioni di condizioni sono in
generale possibili?
– Per n condizioni, 2 n varianti (ma non tutte sono
plausibili)- sono dette varianti implicite.
– Il numero di varianti esplicite (significative) è in
genere minore!
Ingegneria del Software 2
Testing Black Box
37
Generazione dei Test
• Un possibile Criterio di Copertura della Tabella:
– Copertura di tutte le varianti esplicite
– Un Test Case per ogni variante
Ingegneria del Software 2
Testing Black Box
38
19
Un altro esempio
• Al termine del campionato di calcio di serie A del 2011,
le prime tre squadre si qualificano direttamente alla
Champions League, mentre la quarta classificata deve
sottoporsi ad uno spareggio: se lo vince si qualifica per
la Champions League, altrimenti per l’Europa League
• La 5° e la 6° classificata si qualificano automaticamente
per l’Europa League, insieme con la squadra vincitrice
della Coppa Italia, qualora essa sia arrivata 7° o peggio,
altrimenti si qualifica in Europa League la 7° classificata
del campionato
Ingegneria del Software 2
39
Testing Black Box
La tabella di decisione
Varianti
Con
dizioni
Azioni
1
2
3
4
5
6
7
Posizione
(1°,2°,3°)
4°
4°
(5°,6°)
7°
>7°
>7°
Coppa Italia
Qualsiasi
Qualsiasi
Qualsiasi
Qualsiasi
Non vinta e
Vincitrice? [1
°,7°]
Vinta
Non Vinta
Spareggio
Champions
Qualsiasi
Vinto
Perso
Qualsiasi
Qualsiasi
Qualsiasi
Qualsiasi
Champions
League
Sì
Sì
No
No
No
No
No
Europa
League
No
No
Sì
Sì
Sì
Sì
No
Nessuna
coppa
No
No
No
No
No
No
Sì
Ingegneria del Software 2
Testing Black Box
40
20
Varianti Esplicite ed Implicite
• In questo caso abbiamo 12 condizioni sugli input
e 7 varianti significative da testare.
Ingegneria del Software 2
Testing Black Box
41
Esercizio
• Scrivere la tabella di decisione relativa alla validità di
una data del Calendario Gregoriano (anno > 1582)
Ingegneria del Software 2
Testing Black Box
42
21
Esempio: Validità della data del giorno
Varianti
Con
dizioni
Azioni
1
2
3
4
5
6
7
Giorno
? [1,28]
29
29
(29,30)
31
31
Qualsiasi
Mese
Qualsiasi
2
2
?2
(1,3,5,7,8,10,
12)
(2,4,6,9,11)
Qualsiasi
Anno
>1582
>1582
>1582
>1582
>1582
>1582
? 1582
Bisestile
Qualsiasi
Sì
No
Qualsiasi
Qualsiasi
Qualsiasi
Qualsiasi
Valida
Sì
Sì
No
Sì
Sì
No
No
In realtà la tabella presenta una incompletezza: una variante significativa
mancante! Quale???
Ingegneria del Software 2
Testing Black Box
43
Testing basato su Grafi Causa-Effetto
• I Grafi Causa-Effetto sono un modo alternativo per
rappresentare le relazioni fra condizioni ed azioni di una
Tabella di Decisione.
• Il grafo prevede un nodo per ogni causa (variabile di
decisione) e uno per ogni effetto (azione di output). Cause
ed Effetti si dispongono su linee verticali opposte.
• Alcuni effetti derivano da una singola causa (e sono
direttamente collegati alla relativa causa).
• Altri effetti derivano da combinazioni fra cause esprimibili
mediante espressioni booleane (con operatori AND, OR e
NOT).
Ingegneria del Software 2
Testing Black Box
44
22
Il Grafo Causa-Effetto per l’esempio
precedente
Età<=25
?
?
?
?
Età>=26
0 Incidenti
1 Incidenti
$25
?
$50
$100
?
?
Tra 2 e 4 Inc.
$200
$400
?
Lettera di avviso
>=5 Incidenti
?
Cancellazione polizza
= AND, ?
=OR, ~= NOT
Ingegneria del Software 2
45
Testing Black Box
Varianti
Con
dizion
i
Azion
i
1
2
3
4
5
6
7
Numero
incidenti
0
0
1
1
Tra 2 e 4
Tra 2 e 4
5o
più
Età
assicurato
<=25
>=26
<=25
>=26
<=25
>=26
Qualsi
asi
Aumento
Premio ($)
50
25
100
50
400
200
0
Lettera
No
No
Sì
no
Sì
Sì
No
Polizza
Cancellata
No
No
No
No
No
No
Sì
Ingegneria del Software 2
Testing Black Box
46
23
Grafi Causa- Effetto
• Vantaggi:
– rappresentazione grafica ed intuitiva,
– È conveniente sviluppare tale grafo se non si ha già a disposizione
una tabella di decisione
– È possibile derivare una funzione booleana dal grafo causa-effetto
(che consente di esprimere in maniera compatta tutte le possibili
combinazioni di cause)
– Può essere usata facilmente per la verifica del comportamento del
software
• Svantaggi
– al crescere della complessità della specifica, il grafo può divenire
ingestibile
Ingegneria del Software 2
Testing Black Box
47
Generazione dei Test
• Copertura di tutte le possibili combinazioni d’ingresso
– Può diventare impraticabile, al crescere delle combinazioni
– Una semplificazione: si può partire dagli effetti e percorrere il grafo
all’indietro cercando alcune combinazioni degli ingressi che rendono
vero l’effetto considerato.
– Non tutte le combinazioni possibili saranno considerate, ma solo
alcune che soddisfano alcune specifiche euristiche.
• Es. combinazione di OR di cause che deve essere vera -> si considera
una sola causa vera per volta
• AND di cause che deve essere falsa-> si considerano combinazioni con
una sola causa falsa
Ingegneria del Software 2
Testing Black Box
48
24
Macchine a Stati e State-Base Testing
– ref. R. Binder “Testing Object-Oriented Systems- Models,
Patterns and Tools”, Addison Wesley
– È una tecnica di testing Black-Box basata sull’uso di Macchine
a Stati
– Le Macchine sono usate per specificare il comportamento di un
componente, sottosistema, o sistema software
– La Macchina è usata per derivare anche i casi di test
Ingegneria del Software 2
Testing Black Box
49
Macchina a Stati (State Machine)
• Macchina a Stati: è un modello (o specifica) del
comportamento dinamico di un sistema, indipendente
dalla sua implementazione.
• Si basa sui seguenti elementi fondamentali:
•
•
•
•
•
stato: situazione astratta nel ciclo di vita di una entità (ad esempio, lo
stato del contenuto di un oggetto)
evento: un particolare input (es. un messaggio, o chiamata di un
metodo)
azione: il risultato, l’output o l’operazione che segue un evento
transizione: una sequenza ammessa fra due stati, ossia un
cambiamento di stato causato da un evento.
guardia: una espressione predicativa associata ad un evento, che
stabilisce una condizione Booleana che deve essere verificata
affinchè la transizioni scatti
Ingegneria del Software 2
Testing Black Box
50
25
Notazione grafica per stati e transizioni
Stato iniziale/
azione
Le azioni possono essere
associate sia agli stati che
alle transizioni
Evento [guardia]/
azione
Stato finale/
azione
Ingegneria del Software 2
Testing Black Box
51
Diversi Tipi di Macchine a Stati
• Automa a Stati Finiti (FSM)
– senza guardie, né azioni associate a stati né a transizioni
• Macchina di Mealy
– le azioni sono associate solo alle transizioni, e non agli stati, che sono
stati passivi
• Macchina di Moore
– azioni associate solo agli stati, non alle transizioni
• Statechart
– Sono possibili Stati gerarchici, o super-stati (ossia aggregati di altri
stati)
•
•
State transition diagram: è una rappresentazione in forma di grafo di
una Macchina a Stati
State transition table: rappresentazione tabellare della Macchina a
Stati
Ingegneria del Software 2
Testing Black Box
52
26
Un esempio di Macchina di Mealy
• Per rappresentare la dinamica di un video-gioco (es.
ping-pong, squash, etc.) fra due giocatori (es. si vince
a 21 punti).
• Ciascun giocatore ha un bottone di start e uno di reset
• Il giocatore che preme lo start per primo, comincia a servire
• Il giocatore corrente serve e viene eseguito un lancio:
– Se chi ha servito sbaglia il colpo, l’avversario guadagna il servizio
– Se il giocatore senza servizio sbaglia il colpo, il punteggio del
giocatore col servizio viene incrementato e questi continua a
servire;
– Se il giocatore senza servizio sbaglia ed il punteggio di chi ha il
servizio è pari a 20 (-1 punto dalla vittoria), questi diventa il vincitore
Ingegneria del Software 2
53
Testing Black Box
La Macchina di Mealy corrispondente
p1_Start() /
simulaLancio()
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
Gioco
Iniziato
p2_Start() /
simulaLancio()
p1_VinceBattuta / simulaLancio()
Giocatore2
Giocatore1
ha servito
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p2AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
Giocatore
1 ha vinto
p2_èVincitore? () /
return TRUE
p1_èVincitore? () /
return TRUE
Ingegneria del Software 2
Testing Black Box
54
27
Proprietà Generali delle Macchine a Stati
•
Sono tipicamente modelli incompleti (per problemi di scalabilità):
– Solo stati, eventi e transizioni più importanti vengono rappresentate
– In genere solo gli eventi leciti sono associati a transizioni; eventi illeciti
(quali p1_Start dallo stato Player 1 served) non sono specificati
•
Può essere Deterministico o Non Deterministico
– Deterministico: ogni tripla stato/evento/guardia innesca una sola transizione
– Non Deterministico: la stessa tripla stato/evento/guardia può innescare
varie transizioni, a seconda dei casi
•
•
•
Può avere vari stati finali (o nessuno: computazione infinita)
Può avere eventi vuoti (transizioni di default)
Può essere concorrente: la macchina (statechart) può essere in vari stati
contemporaneamente
Ingegneria del Software 2
Testing Black Box
55
Il ruolo delle Macchine a Stati nel software
testing (1/2)
• Supportano l’esecuzione di attività di model testing, dove
un modello eseguibile (la state machine) del sistema
viene eseguito o simulato con sequenze di eventi che
costituiscono i casi di test, ancor prima
dell’implementazione.
• Un test è una sequenza di eventi della macchina a stati:
– TC1: e1-e2- e4-…
– TC2: e1-e3- e
• Simulando la sequenza di eventi si controlla che il
corrispondente comportamento specificato per il sistema
sia corretto
Ingegneria del Software 2
Testing Black Box
56
28
Il ruolo delle Macchine a Stati nel software
testing (2/2)
• Consentono di eseguire il testing dell’implementazione
del sistema rispetto ad una sua specifica (la state
machine)
• Supportano la generazione automatica di test cases a
livello del codice:
• Anche in questo caso i test sono dati da sequenze di
eventi
– È richiesto un mapping esplicito fra gli elementi della macchina
(states, events, actions, transitions, guards) ed i corrispondenti
elementi dell’implementazione (e.g., classes, objects, attributes,
messages, methods, expressions)
– Lo stato corrente della macchina deve essere verificabile o
dall’ambiente di runtime o dall’implementazione stessa (built-in
tests con asserzioni e invarianti di classe)
Ingegneria del Software 2
Testing Black Box
57
Il problema della Validazione delle Macchine a
Stati
• Per eseguire sia il Model Testing o il Testing dell’implementazione
occorre preventivamente verificare che la macchina a stati sia
completa e consistente :
•
•
•
•
•
•
•
deve esserci uno stato iniziale con sole transizioni uscenti;
deve esserci almeno uno stato finale con sole transizioni entranti;
non deve presentare stati equivalenti (cioè stati per i quali
qualunque sequenza di eventi produce identiche sequenze di azioni
risultanti)
Ogni stato deve essere raggiungibile dallo stato iniziale
Deve esserci almeno uno stato finale raggiungibile da ogni stato
Ogni evento ed azione devono apparire in almeno una transizione (o
stato)
Tranne che per gli stati iniziale e finale, ogni stato ha almeno una
transizione entrante ed una uscente
• Si usano delle Checklist per il controllo
Ingegneria del Software 2
Testing Black Box
58
29
Difetti sul Controllo rispetto alle State Machine
• Un difetto sul controllo consente a sequenze scorrette di eventi di
essere accettate, o produce sequenze scorrette di azioni di
output.
• Nell’eseguire il testing basato su macchine a stati, occorre
cercare di verificare la presenza dei seguenti tipi di difetto sul
controllo:
•
•
•
•
•
•
•
Transizioni mancanti (non accade nulla a seguito di un evento)
Transizioni scorrette (ossia verso stati scorretti)
Eventi mancanti o scorretti
Azioni mancanti o scorrette (cose scorrette accadono a seguito di una
transizione)
Uno stato extra, mancante, o corrotto (comportamento impredicibile)
Uno sneak path (scorciatoia: un evento è accettato quando non
dovrebbe)
Una trap door (l’implementazione accetta eventi non previsti)
Ingegneria del Software 2
59
Testing Black Box
Esempio di Difetto: Transizione Mancante
p1_Start() /
simulaLancio()
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
Gioco
Iniziato
p2_Start() /
simulaLancio()
Giocatore2
ha servito
Giocatore1
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p2AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
Giocatore
1 ha vinto
p2_èVincitore? () /
return TRUE
p1_èVincitore? () /
return TRUE
Transizione Mancante: p2 perde la battuta ma continua a servire
Ingegneria del Software 2
Testing Black Box
60
30
Esempio di Difetto: Transizione Scorretta
p1_Start() /
simulaLancio()
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
Gioco
Iniziato
p2_Start() /
simulaLancio()
p1_VinceBattuta /
simulaLancio()
Giocatore2
ha servito
Giocatore1
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p2AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
Giocatore
1 ha vinto
p2_èVincitore()? /
return TRUE
p1_èVincitore()? /
return TRUE
Transizione Scorretta: dopo che il giocatore p2 perde, il gioco ricomincia
Ingegneria del Software 2
61
Testing Black Box
Esempio di Difetto: Azioni Mancanti
p2_Start()
p1_Start()
Gioco
Iniziato
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
p1_VinceBattuta / simulaLancio()
Giocatore2
Giocatore1
ha servito
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p2AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
Giocatore
1 ha vinto
p2_èVincitore()? /
return TRUE
p1_èVincitore()? /
return TRUE
Azioni Mancanti: non sono generati i Lanci e il sistema attende indefinitamente
Ingegneria del Software 2
Testing Black Box
62
31
Esempio di Difetto: Azione Scorretta
p1_Start() /
simulaLancio()
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
Gioco
Iniziato
p2_Start() /
simulaLancio()
p1_VinceBattuta / simulaLancio()
Giocatore2
Giocatore1
ha servito
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p1AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
Giocatore
1 ha vinto
p2_èVincitore()? /
return TRUE
p1_èVincitore()? /
return TRUE
Azione Scorretta: il giocatore 2 non può mai vincere
Ingegneria del Software 2
63
Testing Black Box
Esempio di Difetto: Sneak Path
p1_Start() /
simulaLancio()
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
Gioco
Iniziato
p2_Start() /
simulaLancio()
p1_VinceBattuta / simulaLancio()
Giocatore2
Giocatore1
ha servito
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p2AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
p2_Start()
Giocatore
1 ha vinto
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
p2_èVincitore()? /
return TRUE
p1_èVincitore()? /
return TRUE
Sneak Path: il giocatore 2 vince immediatamente premendo il bottone Start
quando ha il servizio
Ingegneria del Software 2
Testing Black Box
64
32
Esempio di Difetto: Trap Door
p1_Start() /
simulaLancio()
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
Gioco
Iniziato
p2_Start() /
simulaLancio()
p1_VinceBattuta / simulaLancio()
Giocatore2
Giocatore1
ha servito
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p2AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
ESC
Giocatore
1 ha vinto
p2_èVincitore()? /
return TRUE
p1_èVincitore()? /
return TRUE
Trap Door: il giocatore 1 può vincere immediatamente premendo ESC
quando ha il servizio
Ingegneria del Software 2
Testing Black Box
65
Strategie per il Progetto dei Test
nello State-based testing
• Si usano gli stessi concetti di Copertura visti nel testing white-box:
• Test Case = sequenza di eventi di input
– all-events coverage: ogni evento della macchina a stati viene incluso nella
test suite (fa parte di almeno un test case)
– all-states coverage: ogni stato della macchina è esercitato almeno una volta
da qualche test della test suite
– all-actions coverage: ogni azione è eseguita almeno una volta
• Questi criteri non definiscono una adeguata copertura in
quanto:
– posso riuscire ad esercitare tutti gli eventi, ma non visitare tutti gli stati
o produrre tutte le azioni; posso visitare tutti gli stati, ma perdere
eventi od azioni; posso mancare coppie evento/azione scorrette.
Ingegneria del Software 2
Testing Black Box
66
33
Esempio: All-states Coverage
p1_Start() /
simulaLancio()
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
Gioco
Iniziato
p2_Start() /
simulaLancio()
p1_VinceBattuta / simulaLancio()
Giocatore2
Giocatore1
ha servito
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p2AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
Giocatore
1 ha vinto
p2_èVincitore()? /
return TRUE
p1_èVincitore()? /
return TRUE
Ingegneria del Software 2
Testing Black Box
67
Altri Criteri di Copertura
• all-transitions: ogni transizione è esercitata
almeno una volta
• implica le coperture all-events, all-states, e all-actions
• Posso rilevare transizioni mancanti, coppie
evento/azione scorrette o mancanti (mi accorgo che
l’azione associata ad un evento è scorretta), che lo stato
risultante raggiunto è scorretto (se lo stato è
osservabile), o che viene raggiunto un extra stato
• Se lo stato non è osservabile, non si può provare che
viene raggiunto uno stato scorretto; inoltre, non si rileva
la presenza di extra-transizioni.
Ingegneria del Software 2
Testing Black Box
68
34
Copertura di tutte le transizioni
p1_Start() /
simulaLancio()
p1_VinceBattuta
[ p1_Score<20 ] /
p1AddPoint()
simulaLancio()
Gioco
Iniziato
p2_Start() /
simulaLancio()
p1_VinceBattuta / simulaLancio()
Giocatore2
Giocatore1
ha servito
ha servito
p2_VinceBattuta
[ p2_Score<20 ] /
p2AddPoint( )
simulaLancio()
p2_VinceBattuta() / simulaLancio( )
p2_VinceBattuta()
[p2_Score()==20 ] /
p2AddPoint()
Giocatore
2 ha vinto
p1_VinceBattuta()
[p1_Score()==20 ] /
p1AddPoint()
Giocatore
1 ha vinto
p2_èVincitore()? /
return TRUE
p1_èVincitore()? /
return TRUE
Ingegneria del Software 2
Testing Black Box
69
Altri criteri di copertura…
• all n-transition sequences: ogni sequenza di transizioni di
n eventi deve essere esercitata almeno una volta
– all transitions = all 1-transition sequences
– all n-transition sequences implica all (n-1)-transition sequences
– Si possono scoprire alcuni stati scorretti o corrotti
• all round-trip paths: ogni sequenza di transizioni che parte
e termina nello stato stato viene esercitata almeno una volta
– Può rilevare tutte le coppie evento/azione scorrette o mancanti
• exhaustive: ogni cammino sulla macchina a stati è
esercitato almeno una volta
– In genere impossibile e quasi sempre impraticabile
Ingegneria del Software 2
Testing Black Box
70
35
Applicazioni dello State Based Testing
• Nasce per il testing di Circuiti (Hardware)
• È stato adottato per il testing software fin dagli anni ’70
• Tipicamente usato per il testing di unità per software ObjectOriented
• Usato anche per il testing di GUI e di Sistema
Ingegneria del Software 2
Testing Black Box
71
36