Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Anna Rita Fasolino » 14.Tecniche di Testing Dinamico


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.

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 .

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.

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.

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 .

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.

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.

I materiali di supporto della lezione

Ref. R. Binder “Testing Object-Oriented Systems- Models, Patterns and Tools”, Addison Wesley

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93