Tecniche di Testing Black Box

Transcript

1 Tecniche di Testing Black Box 1 Riferimenti Ian Sommerville, Ingegneria del Software, capitoli Pressman, Principi di Ingegneria del Software, 5 edizione, Capitoli Ghezzi, Jazazeri, Mandrioli, Ingegneria del Software, 2 edizione, Capitolo 6 (piùdettagliato sulletecniche) 2 1

2 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 Expected results =? Obtained results Inputs - code inspection - code analysis - model checking - bug fixing - debugging 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? 4 2

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 di recupero da errori. 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. 6 3

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 dimostrino che il requisito è stato soddisfatto. Il testing basato sui requisiti è una tecnica di convalida dove vengono progettati vari test per ogni requisito. 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 8 4

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 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 10 5

6 Esempio Cliente Registrazione Registrazione apparato elettronico Richiesta assistenza System 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). Tecnico Registrazione dati apparato riparato 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 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 12 6

7 Classi di Equivalenza Invalid inputs Valid inputs System Outputs 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. 14 7

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 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 16 8

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 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 18 9

10 Le condizioni sull input giorno Condizioni d ingresso: Il giorno può essere compreso tra 1 e 31 Classi di equivalenza: Valida CE 1 : 1? GIORNO? 31 n valide CE 2 : GIORNO < 1 CE 3 : GIORNO > 31 CE 4 : GIORNO non è un numero intero 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 CE 51 : MESE = gennaio, CE 52 : MESE = febbraio, CE 53 : MESE = marzo,. (Tot. 12 classi di equivalenza) - n valida CE 6 : MESE? M 20 10

11 Le condizioni sull input anno Condizioni di ingresso: Deve essere compreso tra 1900 e 2000 Classi di equivalenza Valida CE 7 : 1900<= ANNO<=2000 n valide CE 8 : ANNO< 1900 CE 9 : ANNO> 2000 CE 10 : ANNO non è un numero intero 21 Scelta dei casi di test... Test case TC1 TC2 TC3 TC4 Giorno Mese gennaio febbraio marzo aprile Anno duemila Classi coperte CE1, CE51, CE7 CE1, CE52, CE8 CE1, CE53, CE9 CE1, CE54, CE10 Test case TC5 TC6 TC7 TC8 Giorno primo Mese brumaio maggio giugno luglio Anno Classi coperte CE1, CE6, CE7 CE2, CE55, CE7 CE3, CE56, CE7 CE4, CE57, CE7 Ogni TC copre al più una CE non valida! 22 11

12 Scelta dei casi di test Test case TC9 TC10 T11 TC12 Giorno Mese agosto settembre ottobre novembre Anno 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 23 Efficacia ed Efficienza del Testing Per valutare la bontà della test suite bisognerebbe valutare contemporaneamente: L efficacia, in termini dimalfunzionamenti trovati L efficienza, in termini di numero di casidi test che riescono a scoprire malfunzionamenti Per migliorare l efficacia servirebbero più test Ad esempio considerando Test suite che coprano non solo le singole classidi equivalenza, ma anche le combinazioni delle classidi equivalenza Per migliorare l efficienza bisognerebbe invece ridurre il numero di test 24 12

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 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 degliinput 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 25 Scelta dei casi di test Una Test Suite più efficiente potrebbe essere la seguente: Test case TC1 TC2 TC3 TC4 Giorno primo Mese gennaio brumaio gennaio gennaio Anno 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! 26 13

14 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 27 Settare ed Osservare lo stato del sistema n 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 28 14

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 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 30 15

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 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. I2 I1 Componente O1 O2 In Az

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. 33 Template della Tabella di Decisione Condizioni Azioni cond1 Cond2 Condn Azione 1 Azione 2 azione n 1 2 Varianti 3 4 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

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 35 La Tabella di decisione Varianti Con dizion i Azioni Numero incidenti Età assicurato Aumento Premio ($) Lettera 0 <= >= <= >=26 50 Tra 2 e 4 <= Tra 2 e 4 >= o più Qualsiasi 0 Polizza Cancellata 36 18

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, 2 n varianti (ma non tutte sono plausibili)- sono dette varianti implicite. Il numero di varianti esplicite (significative) è in genere minore! 37 Generazione dei Test Un possibile Criterio di Copertura della Tabella: Copertura di tutte le varianti esplicite Un Test Case per ogni variante 38 19

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 39 La tabella di decisione Varianti Con dizioni Posizione (1,2,3 ) 4 4 (5,6 ) 7 >7 >7 Coppa Italia Qualsiasi Qualsiasi Qualsiasi Qualsiasi n vinta e Vincitrice? [1,7 ] Vinta n Vinta Spareggio Champions Qualsiasi Vinto Perso Qualsiasi Qualsiasi Qualsiasi Qualsiasi Azioni Champions League Europa League Nessuna coppa 40 20

21 Varianti Esplicite ed Implicite In questo caso abbiamo 12 condizioni sugli input e 7 varianti significative da testare. 41 Esercizio Scrivere la tabella di decisione relativa alla validità di una data del Calendario Gregoriano (anno > 1582) 42 21

22 Esempio: Validità della data del giorno Varianti Con dizioni Giorno? [1,28] (29,30) 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 Qualsiasi Qualsiasi Qualsiasi Qualsiasi Azioni Valida In realtà la tabella presenta una incompletezza: una variante significativa mancante! Quale??? 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)

23 Il Grafo Causa-Effetto per l esempio precedente Età<=25 Età>=26 0 Incidenti 1 Incidenti Tra 2 e 4 Inc.???????? $25 $50 $100 $200 $400 Lettera di avviso >=5 Incidenti Cancellazione polizza? = AND,? =OR, ~= NOT 45 Varianti Con dizion i Numero incidenti Tra 2 e 4 Tra 2 e 4 5 o più Età assicurato <=25 >=26 <=25 >=26 <=25 >=26 Qualsi asi Azion i Aumento Premio ($) Lettera no Polizza Cancellata 46 23

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 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. n 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 48 24

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 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 50 25

26 tazione grafica per stati e transizioni Le azioni possono essere associate sia agli stati che alle transizioni Stato iniziale/ azione Evento [guardia]/ azione Stato finale/ azione 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 52 26

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 53 La Macchina di Mealy corrispondente p1_vincebattuta [ p1_score<20 ] / p1addpoint() p1_vincebattuta() [p1_score()==20 ] / p1addpoint() Giocatore 1 ha vinto p1_èvincitore? () / return TRUE p1_start() / Giocatore1 ha servito Gioco Iniziato p2_start() / p1_vincebattuta / Giocatore2 ha servito p2_vincebattuta() / simulalancio( ) p2_vincebattuta() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore? () / return TRUE p2_vincebattuta [ p2_score<20 ] / p2addpoint( ) 54 27

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 n Deterministico Deterministico: ogni tripla stato/evento/guardia innesca una sola transizione n 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 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 56 28

29 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) 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 58 29

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) 59 Esempio di Difetto: Transizione Mancante p1_vincebattuta [ p1_score<20 ] / p1addpoint() p1_vincebattuta() [p1_score()==20 ] / p1addpoint() Giocatore 1 ha vinto p1_èvincitore? () / return TRUE p1_start() / Giocatore1 ha servito Gioco Iniziato p2_start() / p2_vincebattuta() / simulalancio( ) Giocatore2 ha servito p2_vincebattuta() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore? () / return TRUE p2_vincebattuta [ p2_score<20 ] / p2addpoint( ) Transizione Mancante: p2 perde la battuta ma continua a servire 60 30

31 Esempio di Difetto: Transizione Scorretta p1_vincebattuta [ p1_score<20 ] / p1addpoint() p1_start() / Giocatore1 ha servito p1_vincebattuta() [p1_score()==20 ] / p1addpoint() Giocatore 1 ha vinto p1_èvincitore()? / return TRUE Gioco Iniziato p1_vincebattuta / p2_start() / p2_vincebattuta() / simulalancio( ) Giocatore2 ha servito p2_vincebattuta() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore()? / return TRUE p2_vincebattuta [ p2_score<20 ] / p2addpoint( ) Transizione Scorretta: dopo che il giocatore p2 perde, il gioco ricomincia 61 Esempio di Difetto: Azioni Mancanti p1_vincebattuta [ p1_score<20 ] / p1addpoint() p1_vincebattuta() [p1_score()==20 ] / p1addpoint() Giocatore 1 ha vinto p1_èvincitore()? / return TRUE p1_start() Giocatore1 ha servito Gioco Iniziato p2_start() p1_vincebattuta / p2_vincebattuta() / simulalancio( ) Giocatore2 ha servito p2_vincebattuta() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore()? / return TRUE p2_vincebattuta [ p2_score<20 ] / p2addpoint( ) Azioni Mancanti: non sono generati i Lanci e il sistema attende indefinitamente 62 31

32 Esempio di Difetto: Azione Scorretta p1_vincebattuta [ p1_score<20 ] / p1addpoint() p1_start() / Giocatore1 ha servito p1_vincebattuta() [p1_score()==20 ] / p1addpoint() Giocatore 1 ha vinto p1_èvincitore()? / return TRUE Gioco Iniziato p1_vincebattuta / p2_start() / p2_vincebattuta() / simulalancio( ) Giocatore2 ha servito p2_vincebattuta [ p2_score<20 ] / p1addpoint( ) p2_vincebattuta() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore()? / return TRUE Azione Scorretta: il giocatore 2 non può mai vincere 63 Esempio di Difetto: Sneak Path p1_vincebattuta [ p1_score<20 ] / p1addpoint() Giocatore1 ha servito p1_vincebattuta() [p1_score()==20 ] / p1addpoint() Giocatore 1 ha vinto p1_èvincitore()? / return TRUE p1_start() / Gioco Iniziato p1_vincebattuta / p2_start() / p2_vincebattuta() / simulalancio( ) Giocatore2 ha servito p2_vincebattuta() p2_start() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore()? / return TRUE p2_vincebattuta [ p2_score<20 ] / p2addpoint( ) Sneak Path: il giocatore 2 vince immediatamente premendo il bottone Start quando ha il servizio 64 32

33 Esempio di Difetto: Trap Door p1_vincebattuta [ p1_score<20 ] / p1addpoint() Giocatore1 ha servito p1_vincebattuta() [p1_score()==20 ] / ESC p1addpoint() Giocatore 1 ha vinto p1_èvincitore()? / return TRUE p1_start() / Gioco Iniziato p1_vincebattuta / p2_start() / p2_vincebattuta() / simulalancio( ) Giocatore2 ha servito p2_vincebattuta [ p2_score<20 ] / p2addpoint( ) p2_vincebattuta() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore()? / return TRUE Trap Door: il giocatore 1 può vincere immediatamente premendo ESC quando ha il servizio 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

34 Esempio: All-states Coverage p1_vincebattuta [ p1_score<20 ] / p1addpoint() p1_vincebattuta() [p1_score()==20 ] / p1addpoint() Giocatore 1 ha vinto p1_èvincitore()? / return TRUE p1_start() / Giocatore1 ha servito Gioco Iniziato p1_vincebattuta / p2_start() / p2_vincebattuta() / simulalancio( ) Giocatore2 ha servito p2_vincebattuta() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore()? / return TRUE p2_vincebattuta [ p2_score<20 ] / p2addpoint( ) 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

35 Copertura di tutte le transizioni p1_vincebattuta [ p1_score<20 ] / p1addpoint() p1_vincebattuta() [p1_score()==20 ] / p1addpoint() Giocatore 1 ha vinto p1_èvincitore()? / return TRUE p1_start() / Giocatore1 ha servito Gioco Iniziato p1_vincebattuta / p2_start() / p2_vincebattuta() / simulalancio( ) Giocatore2 ha servito p2_vincebattuta() [p2_score()==20 ] / p2addpoint() Giocatore 2 ha vinto p2_èvincitore()? / return TRUE p2_vincebattuta [ p2_score<20 ] / p2addpoint( ) 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 70 35

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 71 36