Tecniche di Testing Black Box - UniNa STiDuEunina.stidue.net/Ingegneria del Software 2/Materiale... · 2012. 1. 4. · Ingegneria del Software 2 Testing Black Box 6 Due principali

1

Testing Black BoxIngegneria del Software 2 1

Tecniche di Testing Black Box


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)

2


Software Testing

• Uno dei metodi pratici più usati per scoprire la presenza didifetti in un programma (osservandone i fallimenti) è ditestarlo con un insieme di valori di input.

Programma

The output is correct?

I1, I2, I3, …, In, … Expected results

= ?Obtained results

“Inputs”- No code inspection - No code analysis- No model checking - No bug fixing- No debugging


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?

3


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 direcupero da errori.


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 suoicomponenti).

– 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.

4


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 dimostrinoche il requisito è stato soddisfatto.

• Il testing basato sui requisiti è una tecnica di convalidadove vengono progettati vari test per ogni requisito.


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

5


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


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

6


EsempioSystem

Cliente

Registrazione

Registrazione apparato elettronico

Richiesta assistenza

Tecnico

Registrazione dati apparato riparato

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


2- Testing delle Partizioni (o delle Classi diEquivalenza)

• I dati di input ed output possono essere in genere suddivisiin 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 membrodella classe.

• I casi di Test dovrebbero essere scelti all’interno diciascuna partizione.

• La tecnica è applicabile sia per il Testing di Unità che diSistema

7


Classi di Equivalenza

System

Outputs

Invalid inputs Valid inputs


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.

8


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


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

9


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


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

10


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 valideCE2 : GIORNO < 1CE3 : GIORNO > 31CE4 : GIORNO non è un numero intero


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 validaCE6: MESE ? M

11


Le condizioni sull’input ‘anno’

•Condizioni di ingresso:– Deve essere compreso tra 1900 e 2000

•Classi di equivalenza• Valida

CE7: 1900<= ANNO<=2000

• Non valideCE8: ANNO< 1900CE9: ANNO> 2000CE10: ANNO non è un numero intero


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


Giorno 1 0 35 primo

Mese brumaio maggio giugno luglio

Anno 1980 1980 1980 1980


Ogni TC copre al più una CE non valida!

12


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


Test case TC13

Giorno 1

Mese dicembre

Anno 1980

Classi coperte CE1, CE512, CE7


Efficacia ed Efficienza del Testing

• Per valutare la bontà della test suite bisognerebbevalutare 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 combinazionidelle classi di equivalenza

• Per migliorare l’efficienza bisognerebbe invece ridurreil numero di test

13


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 possibilicombinazioni … )– 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’efficaciadella 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


… Scelta dei casi di test

• Una Test Suite più efficiente potrebbe essere la seguente:


Giorno 1 0 35 primo

Mese gennaio brumaio gennaio gennaio

Anno 1980 1492 2018 duemila


• 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 ilsistema non controlla la validità nè di mese nè di anno!

14


Problemi di Copertura delle Classi diEquivalenza

• A volte non é possibile coprire le classi di equivalenza senza imporreparticolari pre-condizioni al sistema.

• Esempio: un sistema accetta password di tipo stringa. Classi di equivalenzapossono 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’


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 realedell’applicazione

15


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 boundaryvalues 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


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

16


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


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.

Componente

I1

I2

In

O1

O2

Az1

17


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.


Template della Tabella di Decisione

n

…Condn

…azione n

Azione 2

Azione 1

Azio

ni

Cond2

cond1

Co

nd

izion

i

…4321

Varianti•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

18


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


La Tabella di decisione

SìNoNoNoNoNoNoPolizza Cancellata

NoSìSìNoSìNoNoLettera

0200400501002550AumentoPremio ($)

Azioni

Qualsiasi>=26<=25>=26<=25>=26<=25Età assicurato

5 o piùTra 2 e 4

Tra 2 e 4

1100Numero incidenti

Condizioni

7654321

Varianti

19


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, 2n varianti (ma non tutte sono

plausibili)- sono dette varianti implicite.– Il numero di varianti esplicite (significative) è in

genere minore!


Generazione dei Test

• Un possibile Criterio di Copertura della Tabella:

– Copertura di tutte le varianti esplicite

– Un Test Case per ogni variante

20


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


La tabella di decisione

Sì

No

No

Qualsiasi

Non Vinta

>7°

7

QualsiasiQualsiasiQualsiasiPersoVintoQualsiasiSpareggio Champions

NoNoNoNoNoNoNessuna coppa

SìSìSìSìNoNoEuropa League

NoNoNoNoSìSìChampionsLeague

Azioni

VintaNon vinta eVincitrice? [1°,7°]

QualsiasiQualsiasiQualsiasiQualsiasiCoppa Italia

>7°7°(5°,6°)4°4°(1°,2°,3°)PosizioneCondizioni

654321

Varianti

21


Varianti Esplicite ed Implicite

• In questo caso abbiamo 12 condizioni sugli input e 7 varianti significative da testare.


Esercizio

• Scrivere la tabella di decisione relativa alla validità di una data del Calendario Gregoriano (anno > 1582)

22


Esempio: Validità della data del giorno

?1582>1582>1582>1582>1582>1582>1582Anno

QualsiasiQualsiasiQualsiasiQualsiasiNoSìQualsiasiBisestile

NoNoSìSìNoSìSìValidaAzioni

Qualsiasi(2,4,6,9,11)(1,3,5,7,8,10,12)

?222QualsiasiMese

Qualsiasi3131(29,30)2929? [1,28]GiornoCondizioni

7654321

Varianti

In realtà la tabella presenta una incompletezza: una variante significativa mancante! Quale???


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).

23


Il Grafo Causa-Effetto per l’esempio precedente

Età<=25

Età>=26

0 Incidenti

Tra 2 e 4 Inc.

>=5 Incidenti

1 Incidenti

$25

$50

$100

$200

$400

Lettera di avviso

Cancellazione polizza

??

??

?

?

?

?

? = AND, ? =OR, ~= NOT


SìNoNoNoNoNoNoPolizza Cancellata

NoSìSìnoSìNoNoLettera

0200400501002550AumentoPremio ($)

Azioni

Qualsiasi

>=26<=25>=26<=25>=26<=25Età assicurato

5 o più

Tra 2 e 4Tra 2 e 41100Numero incidenti

Condizioni

7654321

Varianti

24


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


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 soloalcune 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

25


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


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

26


Notazione grafica per stati e transizioni

Le azioni possono essere associate sia agli stati che

alle transizioni

Stato iniziale/azione

Stato finale/azione

Evento [guardia]/azione


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

27


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


La Macchina di Mealy corrispondente

p1_VinceBattuta[ p1_Score<20 ] /p1AddPoint() simulaLancio()

p2_VinceBattuta[ p2_Score<20 ] / p2AddPoint( ) simulaLancio()

p1_VinceBattuta()[p1_Score()==20 ] /p1AddPoint()

p2_VinceBattuta()[p2_Score()==20 ] / p2AddPoint()

Gioco Iniziato

Giocatore1 ha servito


p1_Start() / simulaLancio()


Giocatore1 ha vinto

Giocatore2 ha vinto

p1_èVincitore? () / return TRUE

p2_èVincitore? () /return TRUE

p1_VinceBattuta / simulaLancio()

p2_VinceBattuta() / simulaLancio( )

28


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


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

29


Il ruolo delle Macchine a Stati nel software testing (2/2)

• Consentono di eseguire il testing dell’implementazionedel 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)


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

30


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)


Esempio di Difetto: Transizione Mancante





Gioco Iniziato





Giocatore1 ha vinto

Giocatore2 ha vinto

p1_èVincitore? () / return TRUE

p2_èVincitore? () /return TRUE


Transizione Mancante: p2 perde la battuta ma continua a servire

31


Esempio di Difetto: Transizione Scorretta





Gioco Iniziato





Giocatore1 ha vinto

Giocatore2 ha vinto

p1_èVincitore()? / return TRUE

p2_èVincitore()? /return TRUE



Transizione Scorretta: dopo che il giocatore p2 perde, il gioco ricomincia


Esempio di Difetto: Azioni Mancanti

Azioni Mancanti: non sono generati i Lanci e il sistema attende indefinitamente




Gioco Iniziato



p1_Start() p2_Start()

Giocatore1 ha vinto

Giocatore2 ha vinto






32


Esempio di Difetto: Azione Scorretta




Gioco Iniziato





Giocatore1 ha vinto

Giocatore2 ha vinto





p2_VinceBattuta[ p2_Score<20 ] / p1AddPoint( )simulaLancio()

Azione Scorretta: il giocatore 2 non può mai vincere


Esempio di Difetto: Sneak Path




Gioco Iniziato





Giocatore1 ha vinto

Giocatore2 ha vinto






Sneak Path: il giocatore 2 vince immediatamente premendo il bottone Start quando ha il servizio

p2_Start()

33


Esempio di Difetto: Trap Door




Gioco Iniziato





Giocatore1 ha vinto

Giocatore2 ha vinto






Trap Door: il giocatore 1 può vincere immediatamente premendo ESC quando ha il servizio

ESC


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.

34


Esempio: All-states Coverage




Gioco Iniziato





Giocatore1 ha vinto

Giocatore2 ha vinto







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.

35


Copertura di tutte le transizioni




Gioco Iniziato





Giocatore1 ha vinto

Giocatore2 ha vinto







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

36


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 Object-Oriented

• Usato anche per il testing di GUI e di Sistema

Documents

Tecniche di Testing Black Box - UniNa STiDuEunina.stidue.net/Ingegneria del Software 2/Materiale... · 2012. 1. 4. · Ingegneria del Software 2 Testing Black Box 6 Due principali