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. N46000548
Indice
Introduzione
i
1
Software Testing
1.1 Tecniche di Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Da Model Based a Model Driven . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Testing Model Based . . . . . . . . . . . . . . . . . . . . . . . . . .
1
5
6
7
2
Software Verification & Validation
2.1 Gli approcci per le attività di verifica e validazione . . . . . . . . . . . . .
8
9
3
Simulazione
10
3.1 Matlab & Simulink Verification and Validation . . . . . . . . . . . . . . . 10
4
Conclusioni
27
Bibliografia
27
2
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
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 1.1.
1
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).
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
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.
Capitolo 1. Software Testing
1.1
5
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:
CF G(P ) =< N, AC, nl, nF >
dove :
– < 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, f also, incond})
rappresenta la relazione del flusso di controllo.
Un nodo n ∈ N s∪{nl} ha un solo successore immediato e il suo arco uscente è etichettato
con incond, un nodo n ∈ N p 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:
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.
•
V (G) = P + 1
dove P = n.ro di predicati in G.
• 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
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.
1.2.1
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.
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: vengono dedicati maggiori sforzi alla fase di verifica e
convalida.
• 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
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.
Capitolo 3
Simulazione
3.1
Matlab & Simulink Verification and Validation
Simulink è un ambiente grafico utilizzato per la simulazione multidominio e il ModelBased 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
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.
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) =
s2
s−2
+s+1
Lo schema costruito è riportato nella figura 3.2.
(3.1)
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
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:
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):
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
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):
Capitolo 3. Simulazione
18
Figura 3.10: Coverage Summary
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 :
Capitolo 3. Simulazione
20
Figura 3.12: Coverage Details
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
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):
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)
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):
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:
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%.
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
Bibliografia
[1] Sommerville, Ian ,Ingegneria del Sofwtare, Pearson Addison-Wesley, 2007.
[2] MATLAB Documentation Center, www.mathworks.it.
28
© Copyright 2025 ExpyDoc
