Tecniche di Testing Black Box
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Tecniche di Testing Black Box
Ingegneria del Software 2 Testing Black Box 1
Riferimenti
• Ian Sommerville, Ingegneria del Software, capitoli 22-
23-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
1Software 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, Programma
…, In, … Expected results
=?
Obtained results
- No code inspection - No code analysis
“Inputs” - No model checking - No bug fixing
- No debugging
Ingegneria del Software 2 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
2Livelli 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
31- 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
4Esempio
• 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
5Esempio
System
Un cliente registrato può registrare i propri apparati
Registrazione
elettronici in un database di registrazioni, inserendo il
proprio identificativo numerico (di 5 cifre), la tipologia
Cliente
Registrazione apparato elettronico (TV o HI-FI), la marca (una stringa di 10 caratteri
alfabetici), il modello (una stringa alfanumerica di 5
Richiesta assistenza
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,
Registrazione dati apparato riparato
aggiunge automaticamente la data al momento della
Tecnico
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
6Classi 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
7Esempio
• 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 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
8Scelta 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
9Le 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
10Le condizioni sull’input ‘anno’
•Condizioni di ingresso:
– Deve essere compreso tra 1900 e 2000
•Classi di equivalenza
• Valida
CE 7: 1900Scelta 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
12Trade-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 Testing Black Box 25
… 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 é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 pippo ‘Accesso consentito’
‘pluto’ non ha diritto d’accesso pluto ‘Accesso non consentito’‘
Stringa vuota ‘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
14Tecnica 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
15Esempi 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 Testing Black Box 31
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.
I1 O1
Componente
I2 O2
In Az1
Ingegneria del Software 2 Testing Black Box 32
16Costruzione 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 Testing Black Box 33
Template della Tabella di Decisione
Varianti
•Le colonne della
1 2 3 4 … n Tabella rappresentano le
Condizioni
cond1 combinazioni degli input
Cond2 a cui corrispondono le
diverse azioni.
…
Condn •Le righe della tabella
riportano i valori delle
variabili di input (nella
Azioni
Azione Sezione Condizioni) e le
1 azioni eseguibili (nella
Azione Sezione Azioni)
2
•Ogni colonna (distinta
… combinazione degli
azione input) viene chiamata
n
una Variante
Ingegneria del Software 2 Testing Black Box 34
17Un 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à : =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 Testing Black Box 35
La Tabella di decisione
Varianti
1 2 3 4 5 6 7
Con Numero 0 0 1 1 Tra 2 e Tra 2 e 5 o più
dizion incidenti 4 4
i
Età =26 =26 =26 Qualsiasi
assicurato
Azioni Aumento 50 25 100 50 400 200 0
Premio ($)
Lettera No No Sì No Sì Sì No
Polizza No No No No No No Sì
Cancellata
Ingegneria del Software 2 Testing Black Box 36
18Varianti 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
19Un 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 Testing Black Box 39
La tabella di decisione
Varianti
1 2 3 4 5 6 7
Con Posizione (1°,2°,3°) 4° 4° (5°,6°) 7° >7° >7°
dizioni
Coppa Italia Qualsiasi Qualsiasi Qualsiasi Qualsiasi Non vinta e Vinta Non Vinta
Vincitrice? [1
°,7°]
Spareggio Qualsiasi Vinto Perso Qualsiasi Qualsiasi Qualsiasi Qualsiasi
Champions
Azioni Champions Sì Sì No No No No No
League
Europa No No Sì Sì Sì Sì No
League
Nessuna No No No No No No Sì
coppa
Ingegneria del Software 2 Testing Black Box 40
20Varianti 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
21Esempio: Validità della data del giorno
Varianti
1 2 3 4 5 6 7
Con Giorno ? [1,28] 29 29 (29,30) 31 31 Qualsiasi
dizioni
Mese Qualsiasi 2 2 ?2 (1,3,5,7,8,10, (2,4,6,9,11) Qualsiasi
12)
Anno >1582 >1582 >1582 >1582 >1582 >1582 ? 1582
Bisestile Qualsiasi Sì No Qualsiasi Qualsiasi Qualsiasi Qualsiasi
Azioni 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
22Il Grafo Causa-Effetto per l’esempio
precedente
Età=26 ? $50
0 Incidenti ? $100
1 Incidenti ? ? $200
Tra 2 e 4 Inc. ? $400
? Lettera di avviso
>=5 Incidenti Cancellazione polizza
? = AND, ? =OR, ~= NOT
Ingegneria del Software 2 Testing Black Box 45
Varianti
1 2 3 4 5 6 7
Con Numero 0 0 1 1 Tra 2 e 4 Tra 2 e 4 5o
dizion incidenti più
i
Età =26 =26 =26 Qualsi
assicurato asi
Azion Aumento 50 25 100 50 400 200 0
i Premio ($)
Lettera No No Sì no Sì Sì No
Polizza No No No No No No Sì
Cancellata
Ingegneria del Software 2 Testing Black Box 46
23Grafi 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
24Macchine 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
25Notazione grafica per stati e transizioni
Stato iniziale/
azione
Le azioni possono essere
associate sia agli stati che Evento [guardia]/
azione
alle transizioni
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
26Un 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 Testing Black Box 53
La Macchina di Mealy corrispondente
p1_Start() / p2_Start() /
simulaLancio() Gioco simulaLancio()
Iniziato
p1_VinceBattuta p2_VinceBattuta
[ p1_ScoreProprietà 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
28Il 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
29Difetti 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 Testing Black Box 59
Esempio di Difetto: Transizione Mancante
p1_Start() / p2_Start() /
simulaLancio() Gioco simulaLancio()
Iniziato
p1_VinceBattuta p2_VinceBattuta
[ p1_ScoreEsempio di Difetto: Transizione Scorretta
p1_Start() / p2_Start() /
simulaLancio() Gioco simulaLancio()
Iniziato
p1_VinceBattuta p2_VinceBattuta
[ p1_ScoreEsempio di Difetto: Azione Scorretta
p1_Start() / p2_Start() /
simulaLancio() Gioco simulaLancio()
Iniziato
p1_VinceBattuta p2_VinceBattuta
[ p1_ScoreEsempio di Difetto: Trap Door
p1_Start() / p2_Start() /
simulaLancio() Gioco simulaLancio()
Iniziato
p1_VinceBattuta p2_VinceBattuta
[ p1_ScoreEsempio: All-states Coverage
p1_Start() / p2_Start() /
simulaLancio() Gioco simulaLancio()
Iniziato
p1_VinceBattuta p2_VinceBattuta
[ p1_ScoreCopertura di tutte le transizioni
p1_Start() / p2_Start() /
simulaLancio() Gioco simulaLancio()
Iniziato
p1_VinceBattuta p2_VinceBattuta
[ p1_ScoreApplicazioni 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 Object-
Oriented
• Usato anche per il testing di GUI e di Sistema
Ingegneria del Software 2 Testing Black Box 71
36Puoi anche leggere
