💻 computer science

PICKLES: a Natural Language Framework for Requirement Specification and Model-Based Testing

Questo documento introduce PICKLES, un framework in linguaggio naturale che colma il divario tra Behaviour-Driven Development e Model-Based Testing traducendo scenari leggibili dall'uomo in modelli formali per abilitare la generazione automatica di test con una copertura significativamente superiore rispetto al BDD standard.

Autori originali: María Belén Rodríguez, Petra van den Bos

Pubblicato 2026-04-30

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: María Belén Rodríguez, Petra van den Bos

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di dover insegnare a un robot come guidare un'auto. Hai due modi principali per farlo:

Il metodo "Ingegnere Rigido" (Test basati su modelli): Scrivi una complessa bozza matematica di ogni possibile strada, condizione meteorologica e semaforo. È incredibilmente preciso e copre ogni scenario, ma solo un matematico può leggerlo. Se vuoi mostrare al capo cosa farà il robot, devi tradurre la matematica nuovamente in inglese, il che è difficile e soggetto a errori.
Il metodo "Raccontastorie" (Sviluppo guidato dal comportamento): Scrivi una storia: "Dato che l'auto è sulla strada, Quando il semaforo diventa rosso, Allora l'auto si ferma." Tutti lo capiscono. È facile da scrivere e leggere, ma è come scrivere una ricetta per un solo giorno specifico. Se vuoi testare ogni possibile tempistica del semaforo, devi scrivere migliaia di storie separate, che diventano un mucchio disordinato e ingestibile di carta.

Il Problema:
Nel mondo reale, le aziende vogliono la precisione dell'"Ingegnere Rigido" ma la leggibilità del "Raccontastorie". Di solito, devono scegliere l'uno o l'altro. Se scelgono la storia, perdono i bug nascosti. Se scelgono la matematica, nessuno capisce i test.

La Soluzione: PICKLES
Gli autori di questo documento hanno creato un nuovo framework chiamato PICKLES (Precise Input and Control-flow Keyword-based Language for tEst Scenarios). Pensa a PICKLES come a un "Traduttore Universale" che colma il divario tra storie e matematica.

Ecco come funziona, usando una semplice analogia:

1. La "Ricetta Intelligente" (Il Linguaggio)

Invece di scrivere una storia su un'auto specifica che si ferma a un semaforo rosso specifico, PICKLES ti permette di scrivere una "Ricetta Intelligente".

Vecchio metodo: "L'auto si ferma al semaforo rosso su Main Street." (Troppo specifico).
Metodo PICKLES: "L'auto si ferma a qualsiasi semaforo rosso, purché il semaforo sia rosso e l'auto sia in movimento."
La Magia: Puoi definire regole come "Il semaforo può essere di qualsiasi colore dal Rosso al Verde" o "L'auto può avere qualsiasi velocità tra 0 e 100". Questo si chiama parametrizzazione. Trasforma una singola storia in una regola che copre migliaia di possibilità contemporaneamente.

2. L'"Architetto Automatico" (La Traduzione)

Una volta scritte queste "Ricette Intelligenti" in inglese semplice (usando un formato simile al popolare linguaggio Gherkin), lo strumento PICKLES agisce come un Architetto Automatico.

Legge le tue regole in inglese.
Costruisce istantaneamente un Modello Formale (una complessa mappa matematica) dietro le quinte.
Questa mappa è così dettagliata da conoscere ogni possibile percorso che il sistema potrebbe intraprendere, anche percorsi che non hai esplicitamente scritto.

3. La "Mappa Maestra" (Combinazione delle Storie)

Nei test tradizionali, testi la Storia A, poi la Storia B, poi la Storia C, separatamente.

Il Difetto: La Storia A potrebbe funzionare e la Storia B potrebbe funzionare, ma se fai A poi B, il sistema potrebbe bloccarsi. Le storie tradizionali spesso mancano di questi errori di "stretta di mano".
La Correzione PICKLES: Lo strumento prende tutte le tue storie separate e le cuce insieme in un'unica gigantesca "Mappa Maestra". Capisce come la Storia A si collega alla Storia B e come la Storia B si collega alla Storia C. Crea un quadro completo di come il sistema si comporta nel tempo, non solo in momenti isolati.

4. La "Ritraduzione" (Risultati Leggibili)

Questa è la parte più intelligente. Lo strumento utilizza la Mappa Maestra per generare automaticamente centinaia di casi di test specifici.

Di solito, questi test uscirebbero come codice matematico confuso.
PICKLES prende quei risultati matematici e li traduce nuovamente in storie in inglese.
Quindi, il tester riceve un rapporto che dice: "Ecco un test specifico in cui l'auto viaggiava a 50 mph e il semaforo è diventato rosso a 2,5 secondi. L'auto si è fermata correttamente."
L'umano può leggerlo, capirlo e verificarlo, anche se il lavoro pesante è stato svolto dal motore matematico.

Il Test Reale (Il Sistema di Traffico)

Gli autori hanno testato questo su un vero sistema di gestione del traffico utilizzato da un'azienda chiamata Technolution.

La Configurazione: Hanno preso storie esistenti sui sensori di traffico che rilevano rivelatori guasti.
Il Risultato:
- Usando il vecchio metodo "Raccontastorie" (eseguendo le storie una per una), hanno testato solo circa il 30% dei possibili comportamenti del sistema.
- Usando PICKLES (combinando le storie e utilizzando il motore matematico), hanno raggiunto il 100% di copertura della logica del sistema.
- Lo hanno fatto senza scrivere centinaia di nuove storie. Hanno semplicemente reso le storie originali "più intelligenti" aggiungendo variabili (come "qualsiasi corsia" o "qualsiasi posizione") e lasciando che lo strumento facesse il resto.

Perché Questo È Importante

PICKLES permette a persone non tecniche (come project manager o analisti aziendali) di scrivere requisiti in inglese semplice che sono non ambigui e matematicamente rigorosi. Garantisce che:

Nessuno sia confuso: I requisiti sono chiari per tutti.
Nessun bug sia nascosto: Il motore matematico trova casi limite che gli umani potrebbero perdere.
Meno lavoro: Scrivi meno storie per testare più scenari.

In breve, PICKLES è come dare a un robot un libro di storie abbastanza intelligente da comprendere ogni possibile variazione della storia, risolvere i problemi matematici al suo interno e poi scrivere un rapporto chiaro per te in inglese semplice.

1. Enunciazione del Problema

Il documento affronta una tensione critica nei test di software industriali, in particolare per i sistemi safety-critical:

Il Limite del Testing Basato su Modelli (MBT): Sebbene il MBT offra test rigorosi, sistematici e ad alta copertura tramite modelli formali, la sua adozione è ostacolata dalla difficoltà di definire e mantenere tali modelli. Spesso richiedono competenze specializzate, mancano di leggibilità per gli stakeholder non tecnici e creano barriere comunicative.
Il Limite dello Sviluppo Guidato dal Comportamento (BDD): Il BDD utilizza scenari in linguaggio naturale leggibili dall'uomo (Given-When-Then) per facilitare la collaborazione. Tuttavia, il BDD si basa su esempi concreti, il che spesso porta a:
- Ambiguità e Incompletezza: Il linguaggio naturale può essere vago.
- Bassa Copertura: Testare esempi isolati spesso trascura i casi limite e le sequenze complesse di interazione.
- Costi di Manutenzione: Grandi suite di casi di test specifici sono costose da mantenere e aggiornare.

La Sfida Principale: Come ottenere la precisione e l'alta copertura del MBT mantenendo al contempo i benefici di accessibilità, leggibilità e collaborazione tra gli stakeholder del BDD, senza costringere i praticanti a scegliere tra i due.

2. Metodologia: Il Framework PICKLES

Gli autori propongono PICKLES (Precise Input and Control-flow Keyword-based Language for tEst Scenarios), un framework che colma il divario tra BDD e MBT attraverso una pipeline di traduzione bidirezionale.

A. Il Linguaggio Specifico di Dominio (PicklesDSL)

Pickles estende la sintassi Gherkin standard (Given-When-Then) con costrutti formali per eliminare l'ambiguità:

Impostazioni delle Variabili: Un blocco preliminare in cui le variabili sono tipizzate esplicitamente (es. intero, booleano, array, struttura) e assegnate a domini/intervali (es. [1, 3], {AV, PART_AV}).
Parametrizzazione: I passaggi possono fare riferimento a variabili e includere Blocchi di Guardia (condizioni) utilizzando operatori logici (AND, OR) e quantificatori (almeno, al massimo, esattamente).
Struttura:
- Given: Definisce le precondizioni e le guardie dello stato iniziale.
- When: Definisce le interazioni di input con parametri e guardie.
- Then: Definisce le uscite attese e le guardie di validazione.

B. Semantica Formale: Sistemi di Transizione Simbolici (STS)

Il framework traduce le specifiche PicklesDSL in Sistemi di Transizione Simbolici (STS), un formalismo che estende i Sistemi di Transizione Etichettati con costrutti di dati.

Traduzione (Spec $\to$ STS):
- Ogni scenario Pickles mappato su un STS parziale.
- Le clausole Given diventano guardie iniziali.
- Le clausole When diventano interruttori di input (transizioni).
- Le clausole Then diventano interruttori di output.
- Variabili e guardie sono mappate su parametri STS, variabili di posizione e predicati logici.
Composizione del Modello:
- Gli STS degli scenari individuali sono composti in un Modello Maestro.
- Composizione di Scelta ( $\bowtie$ ): Unisce gli stati iniziali di più scenari, permettendo a qualsiasi scenario di iniziare.
- Composizione Sequenziale ( $\triangleright$ ): Collega gli stati di sink (fine) di uno STS agli stati iniziali di altri, consentendo la generazione di lunghe tracce di esecuzione che combinano più scenari.

C. Generazione dei Test e Traduzione Inversa

Generazione dei Test: Algoritmi MBT standard (specificamente mirati a una copertura del 100% degli interruttori) sono applicati al Modello Maestro per generare casi di test formali (sequenze di interruttori con specifici valori di parametro).
Traduzione Inversa (STS $\to$ Pickles): I casi di test formali sono tradotti nuovamente nella sintassi PicklesDSL.
- I valori di input sono definiti esplicitamente nei passaggi When.
- I valori di output sono sostituiti dalle originali guardie Then per validare il comportamento del Sistema in Test (SUT).
- Il risultato è un caso di test eseguibile e leggibile dall'uomo, compatibile con gli strumenti BDD standard (es. Cucumber).

3. Contributi Chiave

PicklesDSL: Un nuovo Linguaggio Specifico di Dominio che preserva la struttura Gherkin ma aggiunge tipizzazione esplicita delle variabili, definizioni di dominio e vincoli di flusso di controllo, garantendo specifiche non ambigue.
Traduzione Bidirezionale: Una mappatura formale tra PicklesDSL e Sistemi di Transizione Simbolici (STS), che permette un passaggio fluido tra requisiti leggibili dall'uomo e modelli formali.
Composizione del Modello Maestro: Un metodo per comporre automaticamente STS parziali da scenari individuali in un Modello Maestro unificato, consentendo la scoperta di bug di interazione complessi che gli scenari isolati non rilevano.
Implementazione Prototipale: Uno strumento basato su Python (utilizzando il parser Lark) che automatizza i processi di traduzione, composizione e traduzione inversa.
Validazione Industriale: Applicazione del framework a un componente reale di gestione del traffico della società Technolution.

4. Risultati

Il framework è stato valutato utilizzando un caso studio che coinvolgeva un componente di un sistema di gestione del traffico. I risultati hanno dimostrato miglioramenti significativi rispetto agli approcci BDD tradizionali utilizzando lo stesso set di scenari definiti manualmente:

Copertura delle Transizioni:
- BDD Tradizionale: L'esecuzione degli scenari in isolamento copriva solo circa il 30% delle possibili transizioni di sistema.
- Pickles: Componendo gli scenari e generando test dal Modello Maestro, la copertura è aumentata al 100%. Questo rappresenta un miglioramento di 70 punti percentuali.
Copertura degli Input:
- Il BDD tradizionale con valori hardcoded esercita una minuscola frazione degli input possibili.
- Pickles, sfruttando i domini delle variabili e l'analisi dei confini, ha rappresentato 112 possibilità di input distinte per un singolo scenario (Scenario 02) che altrimenti richiederebbe centinaia di casi di test manuali. Lo studio ha notato un miglioramento del 98,5% nella copertura degli input rispetto agli esempi BDD concreti.
Efficienza: Raggiungere una copertura del 100% delle transizioni manualmente avrebbe richiesto almeno sette tracce di test distinte. Pickles ha raggiunto questo obiettivo con soli quattro scenari di input, riducendo significativamente lo sforzo manuale e i costi di manutenzione.

5. Significato

Il framework PICKLES rappresenta un passo significativo avanti nel rendere il Testing Basato su Modelli accessibile ai praticanti industriali:

Colmare il Divario: Elimina con successo il compromesso tra leggibilità e precisione. Gli stakeholder possono collaborare sui requisiti in linguaggio naturale, mentre il sistema garantisce automaticamente il rigore formale.
Shift-Left Testing: Abilitando la composizione automatica degli scenari, permette di eseguire test di integrazione e a livello di sistema più precocemente nel ciclo di vita dello sviluppo, rilevando bug di interazione che i test unitari isolati non colgono.
Manutenibilità: Le modifiche ai requisiti (es. intervalli di variabili) si propagano automaticamente a tutti i casi di test generati, riducendo il carico di manutenzione associato alle grandi suite BDD.
Spiegabilità: A differenza dei modelli formali a scatola nera, i casi di test generati rimangono nel formato leggibile Pickles, rendendo più facile spiegare i risultati dei test a manager e auditor non tecnici.

In conclusione, PICKLES dimostra che, fondando le specifiche in linguaggio naturale su semantica formale e sfruttando la composizione automatica dei modelli, le organizzazioni possono raggiungere l'affidabilità elevata del MBT senza sacrificare i benefici collaborativi del BDD.