1/3
Sardegna FESR 2014/2020 - ASSE PRIORITARIO I
RICERCA SCIENTIFICA SVILUPPO TECNOLOGICO E INNOVA IONE
Azione 1.1.4 Sostegno alle attività collaborative di R&S per lo sviluppo di nuove tecnologie sostenibili, di nuovi prodotti e servizi
RAPPORTO TECNICO Generazione automatica di test
(aggiornamento)
P oge o cl e Top Do n PROSSIMO
Sardegna FESR 2014/2020 - ASSE PRIORITARIO I
RICERCA SCIENTIFICA SVILUPPO TECNOLOGICO E INNOVA IONE
Azione 1.1.4 Sostegno alle attività collaborative di R&S per lo sviluppo di nuove tecnologie sostenibili, di nuovi prodotti e servizi
RAPPORTO TECNICO
Generazione automatica di test (aggiornamento)
Organismo di Ricerca: Università degli Studi di Sassari Progetto Cluster Top Down: PROSSIMO
CUP: J85F17000030002
Il sottoscritto Luca Pulina in qualità di Responsabile scientifico del progetto Cluster Top Down PROSSIMO
Timbro e Firma_________________________________ Data _____12/11/2020____________
Sommario
In questo documento presentiamo un nuovo approccio ai test di conformità dei sistemi reattivi black box. Consideriamo le specifiche del sistema scritte come formule di logica temporale lineare per generare test come sequenze di coppie input / output: gli input vengono estratti dagli automi Buchi corrispondenti alle specifiche e gli output sono ottenuti alimentando gli input ai sistemi. La conformità viene verificata confrontando le sequenze di input / output con le tracce degli automi per rilevare le violazioni delle specifiche. Consideriamo diversi criteri per l'estrazione dei test e per l'interruzione della generazione e li confrontiamo sperimentalmente utilizzando sia gli indicatori di copertura che il rilevamento degli errori. I risultati mostrano che la nostra metodologia può generare suite di test con una buona copertura del sistema e capacità di rilevamento degli errori.
Contents
1 Introduzione
2 Generazione automatica di test da specifica LTL
2.1 Generatore degli input . . . . 3 Analisi sperimentale
3.1 Syntcomp Benchmarks . . . . 3.2 Adaptive Cruise Control . . . . 3.3 Manipulatore robotico . . . . 4 Conclusioni
1 Introduzione
Nel lavoro presentato in questo documento, ci occupiamo del problema di testare se un sistema reattivo — vale a dire, un sistema che possiamo eseguire, ma per il quale non abbiamo alcuna rappresentazione interna — `e conforme a una serie di requisiti forniti come formule di logica temporale. Questo problema si presenta in una variet`a di contesti, ad esempio, quando un sistema viene sviluppato integrando componenti commerciali o↵-the-shelf (COTS) [1].
In questi scenari, tecniche come il model checking [2] o il (white-box) test basato su modello [3] sono chiaramente inapplicabili.
Also, classical black-box techniques like random testing, equivalence partition- ing or boundary analysis [4] either do not take into account the specification or require manual e↵ort to assemble meaningful test suites. Techniques aimed at au- tomated test generation for black-box reactive systems relying on formal models of the specifications have been explored — see, e.g., [5, 6, 7, 8, 9] — and they seem more promising than classical techniques when both efficiency of test generation and e↵ectiveness in covering the specification are considered.
Inoltre, tecniche classiche black-box come random testing, equivalence partition- ing oboundary analysis [4] non tengono conto delle specifiche oppure richiedono un intervento manuale per assemblare suite di test significative. Tecniche mirate alla generazione di test automatizzati per sistemi reattivi black-box basate su modelli formali delle specifiche — vedi, ad es. [5, 6, 7, 8, 9] — sembrano pi`u promettenti delle tecniche classiche, sia per efficienza nella generazione di test, sia per l’efficacia in termini di copertura.
Le tecniche di verifica runtime [10] possono essere viste come una forma di test basato su oracolo [11]: ogni test viene eseguito sull’implementazione del sistema e l’oracolo del test, ovvero il monitor, nel gergo della verifica runtime, osserva il sistema e controlla se le sue esecuzioni sono comportamenti consentiti dalla specifica o no.
Seguendo questa linea di ricerca, una tecnica basata sull’uso di monitor come oracolo
`e proposta in [12]. Il loro approccio pu`o testare le propriet`a di safety (”qualcosa di male non accadr`a mai”), ma non si occupa di propriet`a di liveness (”qualcosa di buono accadr`a infinitamente spesso”). Mentre le propriet`a di liveness non sono suscettibili di monitoraggio su esecuzioni finite, la loro sottoclasse appropriata di propriet`a di co-safety (”qualcosa di buono accadr`a”) consiste in formule che possono essere monitorate su tracce finite tracce e che `e bene considerare quando si testa la conformit`a di un sistema.
Il nostro approccio `e ispirato a quello presentato in [12], ma mira a trattare con una classe pi`u generale di propriet`a. La nostra metodologia si basa su una visita di un automa di Buchi corrispondente ai requisiti. La visita parte dallo stato iniziale dell’automa e genera una sequenza di valori di input con cui viene alimentato il sistema black-box, ottenendo una sequenza corrispondente di valori di output.
Tale sequenza di input/output `e controllata rispetto all’automa, cio`e si controlla se esiste almeno uno stato nell’automa che pu`o essere raggiunto lungo la sequenza. Se non esiste tale stato, il sistema non `e conforme ai requisiti e la sequenza fornisce un controesempio. Altrimenti, si continua la generazione della sequenza iterando i
Figure 1: Workflow dell’approccio proposto.
passaggi precedenti fino a quando (i) uno stato di accettazione dell’automa viene raggiunto con una sequenza di lunghezza almeno kmin oppure (ii) uno stato di accettazione non pu`o essere raggiunto con una sequenza di lunghezza kmax, dove kmin e kmax sono due parametri tali che kmin < kmax. `E possibile ottenere pi`u test ripetendo questa procedura fino a quando tutte le transizioni raggiungibili sono state visitate almeno una volta.
Abbiamo valutato il nostro approccio su tre diversi setting sperimentali.
Nel primo abbiamo considerato i benchmark presi dalla LTL Track dell’edizione 2018 della Reactive Synthesis Competition (SYNTCOMP 2018)1 e abbiamo com- parato il nostro approccio con quello descritto in [12].
Nel secondo setting abbiamo utilizzato il protitipo di Adaptive Cruise Con- trol (ACC) implementato [13] e abbiamo confrontato i test generati col nostro ap- proccio con quelli generati utilizzando una strategia model-based.
Nell’ultimo, abbiamo testato un modello di controllore di braccio robotico in modo da valutare in nostro approccio con un insieme di requisiti di scala industriale.
Nei primi due setting abbiamo utilizzato un mix di fault-injection [14] e mutation analysis [15] per il confronto dei test generati. Nel terzo, i ”difetti” da testare sono stati inseriti in modo manuale.
I risultati che abbiamo ottenuto con i nostri esperimenti dimostrano che il nostro approccio `e pi`u efficace di quello mostrato in [12] in termini di difetti scoperti.
Inoltre, generazione di test basati sulla specifica pu`o essere efficace quanto quella basata sul modello di sistema. Infine, il nostro approccio risulta essere efficace nella ricerca di errori in sistemi di livello industriale di piccole e medie dimensioni.
Il resto del documento `e strutturato come segue. In Section 2 `e descritto il framework per la generazione automatica di test, mentre in sezione 3 `e presentata l’analisi sperimentale. Infine, il documento si conclude con sezione 4.
2 Generazione automatica di test da specifica LTL
Per testare i sistemi black-box, il nostro approccio adotta il workflow presentato in figura 1. Si assume che la specifica sia composta da un elenco di formule LTL la definizione di un insieme I di proposizioni di input e di un insieme O di proposizioni di output tali che I\ O = ;. La pipeline ”Test Generator ” in figura 1 ha l’obiettivo di produrre una serie di test validi da eseguire sul System Under Test (SUT).
La pipeline `e composta da quattro elementi:
• Parser legge la specifica di input, crea le strutture dati intermedie e costruisce la congiunzione di requisiti.
• Automata Builder crea una rappresentazione con automa di Buchi della speci- fica di input.
• Input Generator sceglie quali input eseguire nel SUT.
• Test Oracle valuta l’output prodotto dal SUT e controlla che soddisfi la speci- fica.
Testing Environment `e responsabile dell’interazione tra i componenti. Interroga In- put Generator per nuovi input da testare e li esegue sul SUT. Testing Environment raccoglie l’output e lo passa a Test Oracle per la valutazione. Se il test `e completo, Testing Environment memorizza il verdetto finale e ripristina l’ambiente per iniziare un nuovo test. Inoltre, Test Oracle fornisce a Input Generator l’insieme dei possibili stati in cui pu`o trovarsi l’automa data la traccia eseguita. Di seguito, presentiamo ogni fase della nostra implementazione in modo pi`u dettagliato.
Requisiti ed elaborazione dell’automa L’input dell’algoritmo per la genera- tozione dei test `e un insieme R ={ 1, . . . , n} di formule LTL in aggiunta all’elenco di variabili di input e output. Il parser legge le formule di input come congiunzione
= 1^ · · · ^ nper creare l’automa corrispondente. Per la costruzione dell’automa di Buchi, rappresentato come grafico diretto, `e utilizzato spot[16].
Oracolo dei test Lo scopo dell’oracolo del test `e decidere se una traccia ⌧ , com- posta da variabili di input e output, `e corretta rispetto alla data la specifica LTL
.
Nel nostro approccio, l’oracolo `e implementato su un automa FLTL e le tracce vengono controllate direttamente sull’automa di Buchi non deterministico generato.
Supponiamo infatti che ogni traccia ⌧ che termina con uno stato di accettazione q⇤ dell’automa A , soddisfa anche la formula su cui l’automa `e costruito.
1http://www.syntcomp.org/
2.1 Generatore degli input
L’idea principale alla base della generazione di sequenze di input per testare il SUT consiste nell’esplorare diversi percorsi dell’automa A che rappresenta la specifica.
Data una scelta di (i) una strategia di esplorazione per dare priorit`a ai percorsi e (ii) una condizione di terminazione terminare la ricerca, otteniamo il nostro algoritmo Guided Depth First Search (GDFS). Come suggerisce il nome, `e una variante del classico algoritmo di ricerca in profondit`a sui grafi diretti.
Algorithm 1 Guided Depth First Search
1: function GDFS(A , kmin, kmax, oracle, env)
2: visitCounter emptyMap( )
3: for e2 A .outgoingEdges(A .initState) do
4: visitCounter[e] 0
5: end for
6: while 9e 2 visitCounter.(visitCounter[e] == 0) do
7: ⌧ {}
8: sc A .initState
9: env.reset( )
10: while oracle.validPrefix(⌧ )^ |⌧| < kmax do
11: for e2 A .outgoingEdges(sc) ^ e /2 visitCounter do
12: visitCounter[e] 0
13: end for
14: e selectNextEdge(A , sc, visitCounter)
15: i getInput(e)
16: for e2 A .outgoingEdges(sc) ^ getInput(e) == i do
17: visitCounter[e] visitCounter[e] + 1
18: end for
19: o env.performAction(i)
20: sc getSuccessor(A , sc, i[ o)
21: ⌧.append(i[ o)
22: if |⌧| kmin ^ sc 2 A .acceptanceStates then
23: break
24: end if
25: end while
26: res oracle.evaluate(⌧)
27: env.addTest(⌧, res)
28: end while
29: end function
L’algoritmo prende come input l’automa A , l’intervallo kmin e kmax, ovvero la lunghezza minima e massima di ciascuna traccia, l’oggetto oracle e l’oggetto ”am- biente” env. L’algoritmo inizia con l’inizializzazione della mappa visitCounter, che conta quante volte `e stato esplorato un arco (righe 2-5). Si noti che solo gli archi uscenti dallo stato iniziale vengono inizializzati, mentre gli altri vengono aggiunti
in modo incrementale durante l’esplorazione (righe 11 - 13). L’algoritmo termina quando tutti gli archi in visitCounter sono stati visitati almeno una volta. All’inizio di ogni test, la traccia ⌧ viene inizializzata con valore nullo (vuota) e lo stato corrente sc `e inizializzato allo stato iniziale dell’automa (righe 7-8). Quindi l’ambiente `e ”re- settato” lo stato iniziale (riga 9). Il test viene calcolato in modo iterativo scegliendo un arco (riga 14), estraendo l’input sulla sua etichetta (riga 15), eseguendolo sul SUT tramite l’oggetto env (riga 19) e utilizzando l’output per scegliere lo stato successivo, se presente, e a costruire la traccia ⌧ (righe 20 - 21). La funzione selectNextEdge sceglie lo stato successivo. In caso di pi`u archi con lo stesso peso, la scelta `e e↵et- tuata con un’euristica che tiene conto della distanza dallo stato di accettazione pi`u vicino e del grado dello stato di destinazione. Inoltre, il visitCounter viene aggior- nato dopo ogni scelta (righe 16 - 18) aumentando il contatore di tutti gli archi che lasciano sc che presentano l’input i. La fine di un test avviene esattamente quando uno dei seguenti tre casi `e vero: (i) ⌧ non `e pi`u un prefisso valido di mathcalL(A ) e quindi il test `e fallito; (ii) la lunghezza ⌧ ha raggiunto la lunghezza massima kmax; (iii) la lunghezza di ⌧ `e maggiore di kmin e l’esplorazione ha raggiunto uno stato di accettazione. Alla fine di ogni prova, l’oracolo emette il suo verdetto finale e il il risultato `e memorizzato nell’oggetto env (righe 26 - 27).
3 Analisi sperimentale
In questa sezione sono presentati i risultati di tre esperimenti 2 che coinvolgono il framework introdotto in precedenza. Nel primo ci proponiamo di valutare la qualit`a della suite di test generata che coinvolge una serie di benchmark presi in prestito dalla LTL Track della Reactive Synthesis Competition 20183 (SYNTCOMP 2018). Il il secondo esperimento mira a confrontare l’efficacia del nostro approccio rispetto alle strategie basate su modelli; per fare ci`o, consideriamo il caso d’uso di un Adaptive Cruise Control reso disponibile in [13] e confrontiamo il nostro algoritmo con approcci allo stato dell’arte basati su modelli. Infine, il nostro ultimo esperimento mira a valutare la scalabilit`a del nostro approccio in un utilizzo nel mondo reale. Consideriamo quindi un insieme di requisiti dalla progettazione di un controller integrato per un robot manipolatore utilizzato nel contesto di PROSSIMO (scenario d’uso 1). Gli esperimenti descritti di seguito sono stati eseguiti su una workstation dotata di una CPU Intel Xeon E31245 da 3,30 GHz e 32 GB di RAM con Lubuntu 18.10 64 bits. Per tutti gli esperimenti, abbiamo concesso un limite di tempo di 600 secondi (10 minuti) e un limite di memoria di 30 GB.
3.1 Syntcomp Benchmarks
A valle di una fase di pre-elaborazione e adattamento al problema della generazione di test, abbiamo ottenuto una serie di 128 benchmarck, ciascuno con 100 mutanti per poter aplicare valutazioni tipiche dei test di mutazione mutation testing. Tale
2Tutti i benchmark sono disponibili su https://gitlab.sagelab.it/sage/benchmarks-tests
3http://www.syntcomp.org/
tecnica `e utilizzata, in generale, per progettare nuovi test e valutare la qualit`a dei test. Il test di mutazione implica la modifica di un SUT in piccoli modi. Ogni versione mutata `e chiamata mutante e i test rilevano e rifiutano i mutanti facendo s`ı che il comportamento della versione originale di↵erisca dal mutante. Questo si chiama ”uccidere il mutante”. Le suite di test sono misurate dalla percentuale di mutanti che uccidono.
Nell’esperimento, confrontiamo i risultati ottenuti con 5 diversi algoritmi. GDFS- 1, GDFS-3 e GDFS-5 sono relativi all’algoritmo proposto con kminimpostato rispet- tivamente su 1, 3 e 5. A scopo di confronto, abbiamo re-implementato, e generaliz- zato per adattarsi al nostro framework, l’algoritmo presentato in [12]. In [12] vengono proposte due strategie, vale a dire Random Walk (RW) e Guided Walk (GW) e ab- biamo implementato e testato entrambi. Per quanto riguarda i criteri di copertura, abbiamo implementato il cosiddetto Atomic Proposition Coverage (APC). Per ogni algoritmo poniamo kmax uguale a 100 e fermiamo l’esecuzione non appena un test fallisce e il mutante viene ucciso.
La figura 2 (a sinistra) mostra il numero di mutanti uccisi per benchmark da ogni algoritmo. La figura 2 (a destra) mostra il numero medio di passi eseguito, ovvero la somma della lunghezza di ogni test, mediata sul numero mutanti. In entrambi i grafici, l’ascissa rappresenta il numero di benchmark, mentre l’ordinata mostra il numero di mutanti uccisi (a sinistra) e il numero di passaggi eseguiti (a destra). Si noti che, poich´e il i risultati di RW e GW possono variare a causa di comportamenti non deterministici, abbiamo eseguito il test 3 volte e riportato il valore mediano come riferimento per questi due algoritmi. I risultati rivelano chiaramente che GDFS-5 supera tutti gli altri algoritmi in termini di quantit`a totale di mutanti uccisi e che il numero di passaggi eseguiti `e solo leggermente superiore a GDFS-1 e GDFS-3.
Tuttavia, solo per due benchmark tutti i 100 mutanti sono stati uccisi. Inoltre, in 25 casi non sono stati uccisi, 15 dei quali a causa di timeout. Per quanto riguarda RW e GW, entrambi si sono rivelati totalmente inefficaci per 73 dei 129 benchmark, sebbene si siano verificati solo 2 timeout. Tuttavia, guardando Figura 2 (a destra) notiamo che in 59 di questi benchmark, i due algoritmi non hanno eseguito alcun test.
3.2 Adaptive Cruise Control
Nel secondo esperimento abbiamo considerato il prototipo di Adaptive Cruise Con- trol (ACC) implementato in [13].
Il sistema ACC regola la velocit`a attuale del veicolo verso una velocit`a di crociera target definita dal conducente. Se il veicolo si avvicina troppo al veicolo che precede, il sistema ACC deve regolare la distanza corrente tra i due e mantenere una certa distanza di sicurezza. Inoltre, il conducente pu`o intervenire per: (1) attivare il sis- tema tramite un pulsante ACC; (2) disattivare il sistema tramite il pulsante ACC;
e (3) disattivare il sistema frenando o accelerando la macchina. Anche gli autori di [13] hanno e↵ettuato la generazione dei test partendo da specifiche LTL e lo hanno fatto utilizzando tre di↵erenti criteri di copertura dei requisiti: requirements cover- age (RC), antecedent coverage (AC), e unique first cause coverage (UFC). I test sono
Figure 2: Numero di mutanti uccisi (sinistra) and numero medio di passi elaborati (destra) considerando l’esperimento in cui sono coinvoli i benchmark della SYNT- COMP 2018.
Table 1: Risultati sperimentali su ACC
RC AC UFC GDFS-1 GDFS-3 GDFS-5
Number of Test Cases 6 7 18 26 4912 2597
Branch Coverage (%) 78.3 78.3 86.7 45.0 70.0 71.7
Number of Killed Mutants 488 488 488 414 480 480
Killed Mutants (%) 93.1 93.1 93.1 79.0 91.6 91.6
generati con una strategia basata su modelli: le propriet`a da testare sono costru- ite dalle specifiche e un controesempio viene prodotto con un model checker. Gli algoritmi sono valutati con 524 mutazioni derivanti dalla corretta implementazione.
L’obiettivo dell’esperimento qui descritto `e confrontare le prestazioni del nostro algoritmo rispetto alle tecniche basate su modelli, che fanno quindi uso esplicito di un modello per generare casi di test. La specifica `e composta da 12 requisiti, 6 variabili di input e 10 variabili di output. I risultati sono illustrati nella tabella 1.
Per facilitare il confronto riportiamo anche i risultati di [13].
I risultati presentati mostrano che le prestazioni dell’algoritmo GDFS sono parag- onabili agli algoritmi basati sul modello, con una di↵erenza di soli 8 mutanti (1.5%
del totale) per kmin uguale 3 o 5. Si noti per`o che, nonostante la maggiore dimen- sione della suite di test generata, GDFS raggiunge una copertura di filiale inferiore rispetto a quella basata su modello fermandosi a 71.7%.
Questi risultati mostrano che il test black-box con il framework presentato pu`o essere efficace quasi quanto le tecniche basate sul modello, in cui `e richiesto pi`u lavoro manuale per modellare il sistema.
3.3 Manipulatore robotico
Nel nostro ultimo esperimento consideriamo una serie di specifiche derivanti dalla progettazione di un controller integrato per un manipolatore robotico. Il controller dovrebbe dirigere un braccio robotico correttamente inizializzato — e relativo sis- tema di visione — per cercare un oggetto posto in una data posizione e spostarsi in tale posizione per a↵errare l’oggetto; una volta a↵errato, l’oggetto deve essere
Table 2: Risultati relativi all’esperimento col manipolatore robotico.
# Injection # Tests # Steps Time(s)
1 1 2 7.64
2 2 14 8.61
3 2 14 8.74
4 1 2 7.75
5 1 7 8.15
6 4 25 8.61
7 56 502 25.23
8 1 3 8.15
9 1 6 7.84
10 2 10 8.17
spostato e rilasciato in una posizione di↵erente (all’interno di un secchio nello sce- nario d’uso 1 di PROSSIMO). Il robot deve fermarsi anche in caso di urto accidentale con altri oggetti o con il robot stesso. Infine, se viene rilevato un allarme generale, ad es. dall’interazione con un supervisore umano, il robot deve arrestarsi non ap- pena possibile. Il manipolatore `e un Trossen Robotics a 4 gradi di libert`a, modello WidowX footnotehttp://www.trossenrobotics.com/widowxrobotarm. dotato di pinza. La specifica `e composta da 31 requisiti, 3 ingressi e 11 uscite. Il SUT `e im- plementato come modello SMV. E ad ogni passaggio, NuSMV [17] viene chiamato per determinare l’evoluzione del sistema.
Utilizzando GDFS-5 (kmin = 5 e kmax = 30), siamo in grado di ottenere 1441 test per un totale di 12867 passi eseguiti in 1171 secondi.
Successivamente, i ”guasti” sono stati inseriti manualmente rimuovendo alcuni vincoli nelle guardie (costringendo il sistema a evolversi da uno stato all’altro) o mod- ificando i valori di alcune variabili. Alla fine, otteniamo 10 diversi modelli NuSMV difettosi. I risultati di questa analisi sono presentati in tabella 2. Innanzitutto, seg- naliamo che almeno un test non riuscito `e stato rilevato in tutti i casi considerati.
Guardando la tabella, si pu`o osservare che, per ogni sistema con bug, un piccolo numero di test `e stato necessario per scoprire il fallimento. Pertanto, nella maggior parte dei casi, non `e necessario eseguire un’esplorazione completa dell’automa e una la strategia di arresto anticipato pu`o far risparmiare tempo durante la fase di debug.
4 Conclusioni
In questo documento `e stato descritto un nuovo approccio per la generazione di test per sistemi reattivi black-box. Abbiamo valutato il nostro approccio su tre diversi setting sperimentali. Nella primo abbiamo sintetizzato una serie di benchmark presi da SYNTCOMP 2018 e abbiamo dimostrato che il nostro approccio `e migliore nel trovare mutanti rispetto a due diversi algoritmi presentati in [12]. Nel secondo ab- biamo dimostrato che il nostro approccio si confronta favorevolmente con tecniche all’avanguardia basate su modelli. Infine, nella terzo setting abbiamo testato un
controller per un robot manipolatore modellato in smv e abbiamo mostrato che il nostro approccio `e in grado di trovare alcuni guasti (inseriti artificialmente). Come lavoro futuro, prevediamo di (i) estendere il framework con ulteriori strategie di gen- erazione e (ii) aumentare l’espressivit`a del linguaggio di input. L’implementazione del nostro approccio `e disponibile all’interno della libreria Java4.
References
[1] Jingyue Li, Reidar Conradi, Christian Bunse, Marco Torchiano, Odd Petter N Slyngstad, and Maurizio Morisio. Development with o↵-the-shelf components:
10 facts. IEEE software, 26(2):80–87, 2009.
[2] Christel Baier and Joost-Pieter Katoen. Principles of model checking. MIT press, 2008.
[3] Mark Utting and Bruno Legeard. Practical Model-Based Testing: A Tools Ap- proach. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2007.
[4] Ilene Burnstein. Practical software testing: a process-oriented approach.
Springer Science & Business Media, 2006.
[5] Moez Krichen and Stavros Tripakis. Black-box conformance testing for real- time systems. In International SPIN Workshop on Model Checking of Software, pages 109–126. Springer, 2004.
[6] Benoˆıt Barbot, Nicolas Basset, and Thao Dang. Generation of signals under temporal constraints for CPS testing. In Julia M. Badger and Kristin Yvonne Rozier, editors, NASA Formal Methods - 11th International Symposium, NFM 2019, Houston, TX, USA, May 7-9, 2019, Proceedings, volume 11460 of Lecture Notes in Computer Science, pages 54–70. Springer, 2019.
[7] Beat Koch, Jens Grabowski, Dieter Hogrefe, and Michael Schmitt. Autolink-a tool for automatic test generation from sdl specifications. In Proceedings. 2nd IEEE Workshop on Industrial Strength Formal Specification Techniques, pages 114–125. IEEE, 1998.
[8] Michael Schmitt, Michael Ebner, and Jens Grabowski. Test generation with autolink and testcomposer. In Proc. 2nd Workshop of the SDL Forum Society on SDL and MSC-SAM, volume 2000, 2000.
[9] Claude Jard and Thierry J´eron. Tgv: theory, principles and algorithms. In- ternational Journal on Software Tools for Technology Transfer, 7(4):297–315, 2005.
[10] Andreas Bauer, Martin Leucker, and Christian Schallhart. Runtime verification for ltl and tltl. ACM Transactions on Software Engineering and Methodology (TOSEM), 20(4):14, 2011.
4https://gitlab.sagelab.it/sage/SpecPro
[11] Gilles Bernot, Marie Claude Gaudel, and Bruno Marre. Software testing based on formal specifications: a theory and a tool. Software Engineering Journal, 6(6):387–405, 1991.
[12] Paolo Arcaini, Angelo Gargantini, and Elvinia Riccobene. Online testing of ltl properties for java code. In Haifa Verification Conference, pages 95–111.
Springer, 2013.
[13] Adina Aniculaesei, Falk Howar, Peer Denecke, and Andreas Rausch. Auto- mated generation of requirements-based test cases for an adaptive cruise con- trol system. In 2018 IEEE Workshop on Validation, Analysis and Evolution of Software Tests (VST), pages 11–15. IEEE, 2018.
[14] Mei-Chen Hsueh, Timothy K Tsai, and Ravishankar K Iyer. Fault injection techniques and tools. Computer, 30(4):75–82, 1997.
[15] James H Andrews, Lionel C Briand, Yvan Labiche, and Akbar Siami Namin.
Using mutation analysis for assessing and comparing testing coverage criteria.
IEEE Transactions on Software Engineering, 32(8):608–624, 2006.
[16] Alexandre Duret-Lutz, Alexandre Lewkowicz, Amaury Fauchille, Thibaud Michaud, Etienne Renault, and Laurent Xu. Spot 2.0 — a framework for LTL and !-automata manipulation. In Proceedings of the 14th International Symposium on Automated Technology for Verification and Analysis (ATVA’16), volume 9938 of Lecture Notes in Computer Science, pages 122–129. Springer, October 2016.
[17] Alessandro Cimatti, Edmund Clarke, Enrico Giunchiglia, Fausto Giunchiglia, Marco Pistore, Marco Roveri, Roberto Sebastiani, and Armando Tacchella.
NuSMV 2: An OpenSource Tool for Symbolic Model Checking. In 14th Interna- tional Conference on Computer Aided Verification (CAV 2002), pages 359–364, 2002.
