Tecniche e strumenti per il testing di modelli software Matlab/Simulink

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato Finale in Ingegneria del Software Tecniche e strumenti per il testing di modelli software Matlab/Simulink Anno Accademico 2013/2014 Candidata Mariateresa Guercia matr. N

2 Indice Introduzione i 1 Software Testing Tecniche di Testing Da Model Based a Model Driven Testing Model Based Software Verification & Validation Gli approcci per le attività di verifica e validazione Simulazione Matlab & Simulink Verification and Validation Conclusioni 27 Bibliografia 27 2

3 Introduzione Il testing è un procedimento utilizzato durante il ciclo di vita di un software, per determinare eventuali difetti, testando i singoli componenti del programma. In particolare l obiettivo del testing è quello di confermare che il sistema soddisfi i suoi requisiti funzionali e non funzionali e che non abbia comportamenti imprevisti. Per controllare che un determinato sistema funzioni correttamente bisogna utilizzare un insieme di test case ossia, un insieme di condizioni o variabli che determinano se un applicazione o un sistema software rispondono correttamente, mostrando eventuali difetti, controllando gli output attesi in corrispondenza di un insieme di test di input. Il test non può dimostrare che un sistema è privo di difetti o che si comporterà come specificato in ogni circostanza, è sempre possibile scoprire ulteriori problemi, come disse Edsger Dijkstra: Il testo può solo mostrare la presenza degli errori, non la loro assenza. Un testing esaustivo è impossibile da realizzare quindi ci si affida ad un insieme di test case possibili. Struttura dell elaborato Nell elaborato viene presentato un approccio Model Based per il testing di modelli software tramite l utilizzo di Matlab/Simulink che rappresenta un ambiente grafico per la simulazione multidominio e il Model-Based Design. In particolare viene utilizzato Simulink Verification and Validation che configura i modelli simulink per il testing testandone l accuratezza e la copertura e verificando formalmente il comporamento del modello. Nei capitoli iniziali vengono presentate le tecniche di testing e gli approcci per la verifica e la validazione dei modelli. I capitoli finali riportano una breve panoramica del software utilizzato tramite esempii che illustrano il modo in cui esso agisce sui modelli. i

4 Capitolo 1 Software Testing La fase di testing serve ad accertare che un certo sistema funzioni come specificato dai requisiti iniziali, in particolare si cerca di trovarne eventuali difetti testando ogni singolo componente del programma ed ogni malfunzionamento prima di essere rilasciato all utente finale. Il processo di test del software ha due obiettivi distinti: Test di convalida dimostrare allo sviluppatore e al cliente che il software soddisfi i suoi requisiti, in particolare dovrebbe esserci almeno un test per ogni requisito utente e di sistema, o, per i prodotti software generici, test per tutte le funzionalità del sistema. Per tale test vengono utilizzati un insieme di casi di test ed esso ha esito positivo se tutto funziona come ci si aspetta. Test dei difetti scoprire gli errori o i difetti nel software, dove il comportamento del software è errato, indesiderato o non si conforma alle sue specifiche. Vengono esaminati tutti i tipi di comportamenti indesiderati del sistema come crash, calcoli errati e corruzione dei dati. Un test completato con successo è quello in cui il sistema evidenzia un difetto che porta il sistema a comportarsi in modo errato. Il processo di sofwtare deve quindi convincere i clienti e gli sviluppatori che il software corrisponda a tutti i requisti richiesti e che funzioni in maniera ottimale senza mostrare malfunzionamenti. Un modello generale della fase di testing è mostrato in figura

5 Capitolo 1. Software Testing 2 Figura 1.1: Modello del processo di testing del software I test cases sono specifiche degli input del test e degli output attesi dal sistema, oltre ad una dichiarazione di cosa si sta testando. I dati del test rappresentano gli input creati per testare il sistema e di solito vengono generati automaticamente. Non si deve pensare che eseguendo tutti i test possibili si riesca a testare tutte le possibili sequenze di esecuzioni del programma. Proprio per questo motivo si può affermare che un testing esaustivo non esiste, in quanto nel campo del software vengono testati i sistemi discreti in cui piccole variazioni dei valori di ingresso possono portare a risultati scorretti. Vengono dunque creati un sottoinsieme di test case possibili che comprendono: Dati di input (test-data) per il modulo da testare. Descrizione della funzione interna al modulo. Output atteso della funzione. Un test-case rappresenta quindi, una caratteristica, un requisito conforme alle specifiche ed è utilizzato come unità per costruire un test. Per costruire un test-case bisogna quindi conoscere l output corretto per un certo input della funzione in esame, e questo va ricavato dalle specifiche e dai documenti prodotti in fase di progettazione. Al termine dell esecuzione dell input, l output ottenuto viene memorizzato assieme al test-case e viene confrontato con l output atteso. Quindi un processo di testing affinchè sia di qualità deve essere: Efficace: gestito tramite strategie che consentano la scoperta di quanti più difetti possibili. Efficiente: deve essere in grado di trovare difetti utilizzando il minor numero possibile di casi di test. Ripetibile: se l esecuzione del caso di test influenza l ambiente di esecuzione senza la possibilità di ripristinarlo, ciò potrebbe non essere possibile anche nel caso in cui nel software ci sono degli elementi indeterministici (dipendenti da input non controllabili).

6 Capitolo 1. Software Testing 3 Le attività di testing si articolano su diversi livelli e le relazioni tra modelli e livelli di testing sono esplicitate nel cosiddetto V-Model : Figura 1.2: V-Model in cui ogni fase è implementabile dalla documentazione dettagliata della fase precedente. I diversi livelli di testing vengono riportati qui di seguito: Livello Produttore Testing di Unità viene eseguito da chi sviluppa il componente e riguarda le singole unità di codice (funzioni, oggetti, componenti riusabili). Testing di Integrazione si occupa di trovare i difetti nel sistema tramite l accesso al codice sorgente. Richiede la costruzione di un sistema a partire dai suoi componenti in modo da scoprire problemi che derivano dall integrazione dei singoli componenti che possono essere prefabbricati, riutilizzabili o componenti sviluppati da zero. Quindi questo tipo di testing controlla che questi lavorino effettivamente insieme, vengano chiamati nel modo corretto e trasferiscano i dati in tempo. Il problema che nasce in questo caso è la difficile localizzazione degli errori, quindi si cerca di utilizzare un approccio incrementale in modo da integrare una configurazione minima e testarla aggiungendovi poi ulteriori componenti. Per eseguire il Testing di integrazione vengono utilizzati due approcci: Costruzione di Modelli guida(driver) invocano l unità sotto test, inviandole opportuni valori, relativi al test case. Moduli fittizzi (Stub) vengono invocati dall unità sotto test, vengono utilizzati per simulare il funzionamento della funzione chiamata rispetto al caso di test richiesto. Uno stub è definito come funzione fittizia la cui correttezza è vera per ipotesi. Testing di Sistema vengono integrati gruppi di componenti in modo da formare il sistema o un sotto-sistema, e i test vengono definiti in base alle specifiche del sistema. Livello Cooperativo Produttore-Cliente Privilegiato

7 Capitolo 1. Software Testing 4 Alpha Testing viene fatto utilizzare il sistema ad una parte di utenti reali (nell ambiente di produzione) prima di immetterlo nel mercato. Beta Testing installazione ed uso del sistema in ambiente reale prima dell immissione sul mercato. Livello Utente Testing di Accettazione testing effettuato sull intero sistema sulla base di procedure approvare dal cliente, in modo che esso possa decidere se accettare il prodotto. In realtà nessun processo di testing risulta perfetto,infatti esistono diversi problemi chiave da considerare. Bisogna inanzitutto valutare i risultati del test tramite l Oracolo che rappresenta un meccanismo usato per determinare se un test ha avuto successo o è fallito e viene utilizzato confrontando l output di un sistema sotto analisi, dato in ingresso uno specifico caso di test, con il risultato che il prodotto dovrebbe fornire. Gli oracoli possono essere versioni di test precedenti o sistemi prototipo e vengono eseguiti parallelamente al programma da testare in modo da evidenziarne le differenze. Il modello dell oracolo è mostrato in figura 1.3 : Figura 1.3: Oracolo Un altro problema può essere riscontrato in fase di terminazione del testing e, siccome il testing esaustivo è irrangiungibile, bisogna considerare alcuni criteri per valutare quando il testing possa essere terminato. Può essere considerato un Criterio Temporale indicando un arco di tempo predefinito, oppure possono essere definiti dei criteri di selezione dei casi di test tramite un Criterio di Copertura.

8 Capitolo 1. Software Testing Tecniche di Testing Come è stato già detto in precedenza un test è formato da un insieme di casi di test, quindi il problema sorge nella scelta di essi. I Casi di Test devono essere selezionati in modo da ottimizzare il più possibile efficacia ed efficienza. Le due tipologie fondamentali di criteri di selezione sono : Testing Black Box viene sollecitato il sistema immettendo input e osservando i valori degli output sulla base della sola conoscenza dei requisiti del sistema senza quindi conoscere il codice sorgente, lo stato ed il funzionamento interno dell applicazione. In particolare vengono consultati i documenti relativi alla fase di analisi. Lo scopo principale di questo tipo di testing è la copertura degli scenari e delle funzionalità previste nella specifica dei requisiti. Per semplificare la difficoltà legata alla ricerca dei casi di test vengono suddivisi i possibili input in gruppi i cui elementi si ritiene che saranno trattati similaramente dal processo elaborativo (Classi di equivalenza), in modo che chi esegue il testing eseguirà almeno un test per ogni classe di equivalenza. Testing White Box è un testing di tipo strutturale poichè viene utilizzata la struttura interna del programma per ricavare i casi di test, quindi possono essere formulati criteri di copertura più precisi rispetto al testing black box. In questo caso i criteri di copertura si basano sugli oggetti che compongono la struttura dei programmi come istruzioni e strutture di controllo. Vengono definiti un insieme di casi di test(input data) in modo tale che gli oggetti di una definita classe siano attivati (coperti) almeno una volta nell esecuzione del test. Il flusso di controllo viene eseminato per verificarne la correttezza. Il codice è rappresentato tramite un grafo, il grafo del flusso di controllo (Control Flow Graph-CFG), i cui nodi rappresentano istruzioni e/o predicati del programma e gli archi il passaggio del flusso di controllo. Il grafo viene esaminato per identificare le ramificazioni del flusso di controllo e verificare l esistenza di eventuali anomalie. Il CFG di un programma P viene definito come: dove : CF G(P ) =< N, AC, nl, nf > < N, AC > è un grafo diretto con archi etichettati. Ns, Np sono insiemi disgiunti di nodi istruzione e nodi predicato. nl e nf sono detti rispettivamente nodo iniziale e nodo finale. AC (N {nf }) (N {nl}) ({vero, falso, incond}) rappresenta la relazione del flusso di controllo. Un nodo n Ns {nl} ha un solo successore immediato e il suo arco uscente è etichettato con incond, un nodo n Np ha due successori immediati e i suoi archi uscenti sono etichettati rispettivamente con vero e falso. I Criteri di copertura utilizzati saranno quindi i seguenti:

9 Capitolo 1. Software Testing 6 Copertura dei comandi (statement test) richiede che ogni nodo del CFG venga eseguito almeno una volta durante il testing. Copertura delle decisioni (branch test) richiede che ciascun arco del CFG sia attraversato almeno una volta in modo da garantire che ogni decisione è stata sia vera che falsa in almeno un test case. Copertura delle condizioni (condition test) richiede che ciascuna condizione, nei nodi decisione di un CFG, deve essere valutata sia per valori true che false. Copertura delle condizioni e delle decisioni bisogna combinare la copertura delle condizioni in modo da coprire anche tutte le decisioni. Attraverso il CFG può essere eseguito un Testing dei cammini, infatti dato un modulo ed il suo CFG, un cammino rappresenta un esecuione del modulo dal nodo iniziale del CFG fino al nodo finale. Viene definito quindi il numero dei cammini linearmente indipendenti di un programma come il numero ciclomatico di McCabe: V (G) = E N + 2 dove E = n.ro di archi in G e N = n.ro di nodi in G. dove P = n.ro di predicati in G. V (G) = P + 1 V(G) = n.ro di regioni chiuse in G + 1. questi cammini di base garantiscono l esecuzione di ciascuna istruzione almeno una volta e la copertura di tutti gli archi. Anche per il Testing dei cammini e quindi possibile utilizzare dei Criteri di copertura dei cammini che vengono definiti come segue: Copertura dei cammini(path test) gli errori si verificano con più frequenza quando vengono eseguiti dei cammini che includono particolari sequenze di nodi decisione. Inoltre, non tutti i cammini eseguibili in un CFG possono essere eseguiti durante il test. Copertura dei cammini indipendenti vengono eseguiti un numero di cammini indipendenti di un CFG, ossia un insieme di cammini in cui nessun cammino è completamente contenuto in un altro dell insieme, nè è la combinazione di altri cammini dell insieme. 1.2 Da Model Based a Model Driven Esiste una sostanziale differenza tra lo sviluppo di modelli Model Based rispetto a quelli Model Driven. Nello sviluppo Model Based infatti, i modelli vengono utilizzati durante le fasi di progettazione e implementazione, ciò comporta che le modifiche dei

10 Capitolo 1. Software Testing 7 requisiti e del progetto vengano effettuate direttamente sul codice. Tramite quest approccio i modelli possono diventare inconsistenti in quanto l aggiornamento manuale di essi richiede molto tempo e si rischia, quindi, di non aggiornare più i modelli originali che dopo poco tempo rischiano di diventare inutili. Per quanto riguarda lo sviluppo Model Driven, i modelli diventano parte stessa del progetto e il codice viene generato automaticamente a partire da essi, dando più attenzione alla creazione di modelli più vicini al dominio del problema da risolvere rispetto alla soluzione algoritmica. Questo rappresenta un notevole vantaggio rispetto all approccio Model Based in quanto le modifiche vengono apportate direttamente sui modelli e non sul codice, aumentando l efficienza del sistema e diminuendo i costi e i tempi di sviluppo Testing Model Based Il Testing Model Based è un software testing in cui i casi di test sono generati per intero o in parte da un modello che descrive alcuni aspetti del sistema sotto test. Dopo la loro esecuzione, questi casi di test possono anche essere valutati e documentati automaticamente. Il procedimento con il quale opera il testing Model Based è visualizzato schematicamente nella seguente figura 1.4: Per eseguire il Tesing Model Based abbiamo Figura 1.4: Overview-Model Based Testing bisogno di alcuni elementi fondamentali. Inizialmente vengono considerati i Requisiti/- Specifiche che descrivono il sistema, assolutamente necessari per costruire il modello. Nella fase successiva, viene costruito un modello basato su questi requisiti che richiede un enorme impegno e talvolta risulta abbastanza complesso. Alla fine vengono valutati i test cases e i relativi scripts, generati da una parte del modello. Tramite l utilizzo del test oracle viene stabilito, quindi, il risultato del sistema che viene in seguito confrontato con quello finale.

11 Capitolo 2 Software Verification & Validation Quando viene sviluppato un programma, prima e durante il processo di implementazione, deve essere verificato per accettarsi che sia conforme alle sue specifiche e fornisca le funzionalità attese dal cliente. Questi processi di analisi e convalida vengono denominati Verification & Validation e vengono eseguiti dopo ogni stadio del processo software, dalla revisione dei requisiti fino alla revisione dei progetti e l ispezione del codice fino al test del prodotto. Dunque il problema a questo punto è capire se il sistema risolve effettivamente i problemi per cui è stato concepito e se lo fa correttamente, citando Boehm, 1979 : Are we building the right product? Are we building the product right? che mette in evidenza la differenza concettuale tra Verifica e Convalida: Convalida: Stiamo costruendo il prodotto giusto Verifica: Stiamo costruendo il prodotto nel modo giusto Secondo queste definizioni, il ruolo della Verifica è controllare che il software sia conforme alle sue specifiche e soddisfi i requisiti funzionali e non funzionali. La Convalida è un processo più generale, assicura che il sistema software rispetti le attese del cliente. In qualche modo queste attività intendono rassicurare l utilizzatore che il sistema è adatto al suo scopo, cercando di stabilire, con un buon livello di confidenza, che il sistema è adatto all uso a cui è destinato. Questo livello di confidenza che si vuole fornire non è un concetto assoluto, ma dipende da diversi fattori: Funzioni del software: il livello di confidenza richiesto dipende da quanto il software è critico per una determinata organizzazione. Aspettative dell utente: convalida. vengono dedicati maggiori sforzi alla fase di verifica e Ambiente di mercato: quando un software viene messo sul mercato entra in concorrenza con altri prodotti, quindi una società può decidere di rilasciare un programma prima di aver effettuato il debugging in modo da essere i primi nel mercato. Oppure se i clienti non vogliono pagare prezzi alti per il prodotto devono tollerare più 8

12 Capitolo 2. Software Verification & Validation 9 errori nel sistema. Quindi la fase di verifica e validazione deve tener conto di questi aspetti. In questo modo la fase di Verification & Validation ha due obiettivi fondamentali, scoprire i difetti presenti nel sistema e verificare se il sistema è o meno utilizzabile in condizioni operative. 2.1 Gli approcci per le attività di verifica e validazione All interno del processo di Verifica e Convalida ci sono due approcci complementari al controllo e all analisi del sistema: Approcci statici: in questa fase vengono analizzate le rappresentazioni del sistema come il documento dei requisiti, i diagrammi di progettazione e il codice sorgente del programma, utili a verificare conformità e coerenza nelle fasi di sviluppo. Approcci dinamici: prevedono l esecuzione del software o dei prototipi, con i dati di test, al fine di scoprire eventuali difetti esaminando gli output attesi. Figura 2.1: Verifica e Convalida statica e dinamica La figura 2.1 mostra che le ispezioni e il test giocano ruoli complementari nel processo software. La freccia indica gli stadi del processo in cui le tecniche possono essere utilizzate. Le revisioni dei requisiti e del progetto sono le tecniche principali utilizzate per l individuazione degli errori nelle specifiche e nel progetto.

13 Capitolo 3 Simulazione 3.1 Matlab & Simulink Verification and Validation Simulink è un ambiente grafico utilizzato per la simulazione multidominio e il Model- Based Design. Supporta la progettazione a livello di sistema, la simulazione, la generazione automatica del codice, il testing e la verifica di sistemi. Esso offre un editor grafico, librerie di blocchi personalizzabili e solutori per la modellazione e la simulazione di sistemi dinamici. È integrato con Matlab, e consente di incorporare gli algoritmi Matlab nei modelli e di esportare i risultati delle simulazioni in Matlab per ulteriori analisi. Il tool utilizzato in questa simulazione è Simulink Verification and Validation utile per automatizzare il tracciamento dei requisiti, verificare la conformità dei modelli agli standard, e analizzare la copertura del modello sott esame. Infatti, tramite esso, è possibile creare report dettagliati riguardo alla tracciabilità dei requisiti e sviluppare configurazioni di controllo da condividere con i team addetti alla fase di progettazione. Per garantire che i modelli siano accuratamente testati viene utilizzato il modello di analisi della copertura e, la documentazione dei requisiti, viene fornira mediante modelli, casi di test e generazione del codice. Model Coverage aiuta a convalidare il testing di un modello misurando quanto a fondo gli oggetti del modello sott esame vengono testati. Lavora analizzando l esecuzione degli oggetti che direttamente o indirettamente determinano diversi percorsi di simulazione del modello stesso. Essa è in grado di eseguire diversi tipi di analisi di copertura: Decision Coverage analizza gli elementi che rappresentano i punti di decisione nel modello ( come ad esempio un blocco switch), determinando la percentuale del numero totale di percorsi di simulazione, attraverso l elemento, che la simulazione ha effettivamente attraversato. Condition Coverage analizza i blocchi che in uscita presentano una combinazione logica dei loro ingressi ( come ad esempio il blocco operatore logico) e transizioni stateflow. 10

14 Capitolo 3. Simulazione 11 Modified Condition/Decision Coverage estende la capacità di copertura delle decisioni e delle condizioni. Lookup Table Coverage esamina blocchi i cui dati in uscita vengono dati da ingressi presenti in una tabella di ingressi e uscite. Raggiunge la piena copertura quando si esegue ogni interpolazione ed estrapolazione di ogni intervallo almeno una volta. Signal Range Coverage registra i valori massimi e minimi del segnale di ciascun blocco del modello, misurati durante la simulazioni. Solo i blocchi con segnali di uscita ricevono copertura del campo segnale. Signal Size Coverage registra il minimo, il massimo e la dimensione allocata per tutti i segnali aventi dimensione variabile in un modello. Prima di iniziare l analisi di copertura del modello è necessario specificare diverse opzioni. In particolare in un modello Simulink, selezionando tools -> coverage settings possiamo visualizzare le seguenti opzioni (figura 3.1) Figura 3.1: Coverage Settings Coverage in questa sezione è possibile selezionare il modello per cui si desidera visualizzare la copertura e le metriche che devono essere utilizzate durante l analisi. Results è possibile settare la destinazioni dei risultati. Reporting viene settato nel caso in cui si vuole visualizzare un report in HTML, in praticolare è possibile decidere quali dati includere.

15 Capitolo 3. Simulazione 12 Options vengono selezionate le opzioni per il report di copertura del modello. Filter viene immesso il nome del file che specifica quali oggetti del modello devono essere esclusi dall analisi. É possibile creare ed eseguire un test case anche mediante due funzioni Matlab: >> cvto=cvtest(root) >> cvdo=cvsim(cvto) tramite cvtest viene creato il nuovo caso di test, tramite root viene indicato il nome del modello Simulink. Per eseguire il test case viene utilizzato il comando cvsim. Quando si esegue un modello Simulink è possibile settare il modello in moda da visualizzare, se gli oggetti abbiano o meno copertura 100%. Dopo la simulazione infatti, gli oggetti del modello sono evidenziati con alcuni colori in base a quanto sono coperti: Verde indica che quel determinato oggetto ha ricevuto una copertura completa durante il test. Rosso indica che un oggetto ha ricevuto copertura incompleta. Grigio indice che un oggetto è stato filtrato dalla copertura. Non evidenziati indica che quell oggetto non ha ricevuto copertura. Cliccando su un oggetto evidenziato, viene visualizzata una finestra che fornisce dettagli riguardo alla copertura registrata per tale blocco. Tramite questo software Simulink Verification & Validation è possibile registrare la copertura anche di funzioni Matlab e di Stateflow, registrando, per questi ultimi, l esecuzione del grafico, l esecuzione degli stati, decisioni di transizioni e condizioni individuali che compongono ciascuna decisione. Simulazione-Risposta a un sistema Quest esempio proposto per la simulazione è la rappresentazione tramite i blocchi presenti in Simulink della risposta a un sistema. In particolare viene valutata la risposta al gradino e ad una sinusoide (con frequenza pari a 1), per il seguente sistema: w(s) = s 2 s 2 + s + 1 (3.1) Lo schema costruito è riportato nella figura 3.2.

16 Capitolo 3. Simulazione 13 Figura 3.2: Risposta a un sistema dove è presente un Manual Switch che, tramite un doppio clic, decide quale segnale connettere e, un disturbo di frequenza casuale di ampiezza 0.2. Per visualizzare la Model Coverage è stato fatto agire sul sistema una volta il gradino e una volta la sinusoide. Facendo agire il gradino, sono stati ottenuti i seguenti risultati (figura 3.3): Figura 3.3: Report-Risposta a un gradino

17 Capitolo 3. Simulazione 14 In cui è visibile, tramite un file HTML, il risultato del test di copertura. La metrica utilizzata per la copertura è la Signal Range che registra i valori massimi e minimi del segnale di ciascun blocco del modello, misurati durante la simulazioni. Solo i blocchi con segnali di uscita ricevono copertura del campo segnale. Nel caso duale, facendo agire la sinusoide sono stati ottenuti i seguenti risultati (figura 3.4): Figura 3.4: Report-Risposta a una sinusoide Simulazione-Fault-Tolerant Fuel Control System Per un analisi più dettagliata di tutte le funzioni presenti nel testing tramite Simulink Verification & Validation per la Model Coverage, il modello utilizzato è Fault-Tolerant Fuel Control System che rappresenta un sistema di controllo del combustibile per un motore a benzina. Esso è composto da diversi sottosistemi, ma vengono riportati qui di seguito solamente alcuni blocchi principali per mostrarne l esecuzione. É un modello presente nella libreria di Simulink e viene visualizzato immettendo la seguente funzione nel workspace di Matlab: >> mdl= sldemo_fuelsys ; >> open_system(mdl) ed è raffigurato tramite lo schema a blocchi in figura 3.5:

18 Capitolo 3. Simulazione 15 Figura 3.5: Fault-Tolerant Fuel Control System Il sistema contiene quattro sensori utilizzati per determinare il tasso di carburante (throttle, velocità, ossigeno e pressione assoluta). Sono rappresentati tramite stati paralleli, ed ognuno di essi contiene due sottostati uno normale e uno fail, fatta eccezione per il sensore di ossigeno che contiene anche uno stato di riscaldamento. L utente può selezionare e deselezionare ognuno dei quattro sensori per simulare i guasti. Questo viene realizzato tramite blocchi ad interruttore manuale (facendo doppo clic sul blocco per cambiare la posizione del commutatore). Allo stesso modo, l utente può indurre le condizione di guasto ad un elevata velocità del motore modificando l interruttore presente sulla sinistra. Un Reporting table block fornisce l input per il throttle angle e periodicamente ripete la sequenza di dati specificati nella maschera. Per l esecuzione sono stati impostati i parametri per la coverage, come le metriche utilizzate e i blocchi per cui si desidera visualizzare i risultati. Dopo una prima esecuzione viene visualizzato (figura 3.6):

19 Capitolo 3. Simulazione 16 Figura 3.6: Coverage - Fault-Tolerant Fuel Control System in cui viene mostrata a colpo d occhio la colorazione dei vari blocchi che ricevono la copertura. In particolare i due blocchi evidenziati in rosso indicano che, quegli oggetto, hanno ricevuto una copertura incompleta, come si può anche visualizzare nelle informazioni di quel determinato blocco (figura 3.7, figura 3.8): Figura 3.7: Coverage - Fuel Rate Control

20 Capitolo 3. Simulazione 17 Figura 3.8: Coverage - Engine Gad Dynamics L altro sotto sistema utilizzato è il Fuel Rate Control che utilizza i segnali di ingresso e di retroazione dei sensori per regolare il tasso di carburante. Il modello utilizza tre sottosistemi per attuare questa strategia (logica di controllo, calcolo del flusso d aria, calcolo del carburante). In condizioni di funzionamento normale, il modello stima la portata d aria, e, moltiplica la stima per il reciproco del rapporto desiderato per dare il tasso di carburante. Feedback del sensore di ossigeno fornisce una regolazione ad anello chiuso della stima, al fine di mantenere il rapporto miscela ideale. Dopo l esecuzione la copertura mostrata nel modello di riferimento è la seguente (figura 3.9): Figura 3.9: Coverage - Fuel Rate Control anche in questo caso la copertura dei vari blocchi non è ottimale in quanto gli oggetti del modello hanno anch essi ricevuto una copertura incompleta. Report HTML Il software crea sempre un rapporto di copertura del modello in cui è possibile visualizzare le seguenti informazioni: Coverage Summary contiene informazioni di base riguardo al modello analizzato. In particolare contiene altre due sottosezioni, una si riferisce all inizio e alla fine della simulazione e contiene tutti i comandi di configurazione precedenti alla simulazione (Tests), l altra si riferisce alla sintesti dei risultati dei vari sottosistemi (Summary). Per il modello in figura 3.6 le informazioni visualizzate sono (figura 3.10, figura 3.11):

21 Capitolo 3. Simulazione 18 Figura 3.10: Coverage Summary

22 Capitolo 3. Simulazione 19 Figura 3.11: Coverage Summary Details riporta i risultati dettagliati di copertura del modello. Ogni sezione del report riassume i risultati per parametri, che testano ogni oggetto del modello (in particolare possono essere visualizzati anche cliccando con il tasto destro sull oggetto e selezionando Coverage -> Report). Sono incluse le sezioni Filtered Object, che elenca tutti gli oggetti filtrati dalla registrazione di copertura, Model Details che contiene un sommario dei risultati (cliccando sul nome dell elemento viene visualizzata la scheda dettagliata), e Subsystem Details che contiene una sintesi dei risultati del test di copertura per il sottosistema e un elenco dei sottosistemi in esso contenuti. Nella figura 3.12 vengono visualizzati alcuni dettagli, sempre relativi al modello di figura 3.6 :

23 Capitolo 3. Simulazione 20 Figura 3.12: Coverage Details

24 Capitolo 3. Simulazione 21 Per quanto riguarda i parametri relativi alle metriche di copertura utilizzate, le informazioni riguardano: Cyclomatix Complexity è visibile nel Summary per ogni oggetto presente nella gerarchia del modello. Per un sottosistema o un diagramma Stateflow questo numero include la complessità ciclomatica per ogni suo discendente. Nella sezione Details è presente la complessità ciclomatica per ogni oggetto. Decisions Analyzed elenca i possibili esiti di decisione e il numero di volte che un risultato si è verificato in ogni prova di simulazione. I risultati che non si verificano sono evidenziati in rosso. Conditions Analyzed elenca il numero di occorrenze di condizioni di vero e falso su ogni porta in ingresso al blocco corrispondente. MCDC Analysis elenca le MCDC condizioni di input rappresentati dal blocco corrispondente e la misura in cui i test riportati coprono i casi di condizione. Nella seguente figura 3.13 vi è riportato un esempio: Figura 3.13: Coverage Metric

25 Capitolo 3. Simulazione 22 Coverage - Stateflow L ultimo schema analizzato è il Control Logic, un singolo grafico stateflow costituito da un insieme di sei stati paralleli che implementa la logica di controllo nel suo insieme. I quattro stati paralleli visualizzati nella parte superiore corrispondono ai quattro singoli sensori, i restanti due stati paralleli in fondo considerano lo stato dei quattro sensori contemporaneamente e determinano la funzionalità del sistema complessivo. Per consentire le condizioni di transizione nella modalità corretta, in modo da essere testato in maniera tempestiva, il modello è sincrono e viene eseguito in un normale intervallo di tempo campione di 0, 01s. Dopo l esecuzione, la copertura visualizzata per il modello sott esame è la seguente (figura 3.14): Figura 3.14: Coverage - Control Logic Per i grafici Stateflow il software registra l esecuzione del grafico stesso e l esecuzione di stati, decisioni di transizione e condizioni individuali che compongono ciascuna decisione. Al termine della simulazione, il rapporto HTML, mostra quante volte viene eseguito un sottostato sulla base della storia del superstato e,quante volte ogni decisione di transizione e ogni condizione è valutata come vera o falsa. Il rapporto HTML è riportato qui di seguito (figura 3.15):

26 Capitolo 3. Simulazione 23 Figura 3.15: Summary - Report Control Logic mostra i risultati di copertura per l intero test. Ogni linea nella gerarchia riassume i risultati di copertura di tale livello e dei livelli sottostanti. In particolare quando si registra una copertura per un Chart Stateflow (figura 3.16)

27 Capitolo 3. Simulazione 24 Figura 3.16: Report Chart-Subsystem, Chart il software mostra due tipi di copertura una per il Chart-Subsystem, che riporta i dati di copertura per il diagramma, una volta considerato come oggetto contenitore e, un altra volta considerato come insieme di stati e transizioni, e una per il Chart che, considera i dati di copertura, per il grafico e i suoi ingressi e, per il grafico inteso come insieme di stati e transizioni. NA indica che quella determinata metrica di copertura non è applicabile per un Chart o un Chart-Subsystem ma è applicabile per i sue discendenti. Per ogni stato in un diagramma, il rapporto di copertura comprende una sezione State (figura3.17):

28 Capitolo 3. Simulazione 25 Figura 3.17: Report - State con i dettagli relativi alla copertura registrata in quello stato (in particolare in figura 3.17 sono riportati i dati relativi allo stato Low emission). La copertura di decisione per questo stato di test riporta le decisioni che indicano in quale sottostato eseguire. Le tre decisioni riportate sono: Substate Executed che indica quale sottostato deve essere eseguito quando Low emission esegue. Substate Exited che indica quale sottostato è attivo quando Low emission è in uscita Previously che indica da quale sottostato bisogna ripartire quando Low emission ricomincia la sua esecuzione. Per quanto riguarda invece, il rapporto per le transizioni viene mostrato sotto la sezione Report degli oggetti che le possiedono. Le transizioni non compaiono nella gerarchia del modello nella sezione Summary in quanto la gerarchia si basa su superstati che possiedono altri oggetti Stateflow. La sezione Report è mostrata nella figura 3.18:

29 Capitolo 3. Simulazione 26 Figura 3.18: Report-Report le condizioni analizzate nella tabella, mostrano in ogni riga una condizione insiema al numero registrato di occorrenze per ogni risultato (vero o falso). In particolare siccome entrambi i risultati di decisione sono stati verificati la copertura risultante è del 100%.

30 Capitolo 4 Conclusioni In questo elaborato è stato affrontato il testing di modelli software tramite lo strumento Matlab/Simulink. Dopo una breve introduzione sul procedimento di testing, è stata posta maggiore attenzione sulla fase di testing e sulle varie tecniche utilizzate. In particolare è stato utilizzato un tool di Simulink, Simulink Verification & Valutation allo scopo di mostrare come, tramite questo strumento, è possibile verificare la copertura di particolari oggetti presenti nel modello sott esame. Inizialmente è stato presentata la Model Coverage e come opera sui modelli analizzati, poi è stato eseguito un semplice esempio per mostrarne alcune caratteristiche. Poi, per mostrare al meglio come lavora questo tool di Simulink, è stato utilizzato un modello più complesso presente nella libreria di Simulink, ossia un sistema di controllo del combustibile per un motore a benzina. Esso è composto da diversi sottosistemi, e per alcuni di essi è stata verificata la copertura e mostrato il report HTML con dettagliato approfondimento. 27

31 Bibliografia [1] Sommerville, Ian,Ingegneria del Sofwtare, Pearson Addison-Wesley, [2] MATLAB Documentation Center, 28