Contenuti
- Testing basato su Tabelle di Decisione
- Testing basato su Grafi Causa-Effetto
- Testing basato sugli stati (State Based Testing)
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 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.
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.
Un esempio: la tabella di decisione per la procedura di rinnovo annuale delle polizze automobilistiche di una compagnia di assicurazioni.
Un esempio di Tabella di decisione
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.
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).
Il Grafo Causa-Effetto per l’esempio precedente
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 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.
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.
Notazione grafica per stati e transizioni
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.
Un esempio di Macchina di Mealy
Per rappresentare la dinamica di un video-gioco (es. ping-pong, squash, etc.) fra due giocatori.
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 che non ha il servizio sbaglia il colpo, il punteggio del giocatore col servizio viene incrementato e questi continua a servire;
- se il giocatore che non ha il servizio perde la palla ed il punteggio di chi ha il servizio è a -1 punto dalla vittoria, questi diventa il vincitore (es. si vince a 21 punti).
La Macchina di Mealy corrispondente
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
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.
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:
- è 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 usare delle Checklist per 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.
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 (un evento è accettato quando non dovrebbe);
- una trap door (l’implementazione accetta eventi non previsti);
Esempio di Difetto: Transizione Mancante
Transizione Mancante: p2 perde la battuta ma continua a servire.
Esempio di Difetto: Transizione Scorretta
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.
Esempio di Difetto: Azione Scorretta
Azione Scorretta: il giocatore 2 non può mai vincere.
Esempio di Difetto: Sneak Path
Sneak Path: il giocatore 2 vince immediatamente premendo il bottone Start quando ha il servizio .
Esempio di Difetto: Trap Door
Trap Door: il giocatore 1 può vincere immediatamente premendo ESC quando ha il servizio.
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.
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.
- 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.
Esempio: All-states Coverage
Copertura di tutte le transizioni
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.