💻 computer science

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

Dit artikel introduceert PICKLES, een framework voor natuurlijke taal dat Behaviour-Driven Development en Model-Based Testing met elkaar verbindt door menselijk leesbare scenario's te vertalen naar formele modellen om automatische testgeneratie mogelijk te maken met aanzienlijk hogere dekking dan standaard BDD.

Oorspronkelijke auteurs: María Belén Rodríguez, Petra van den Bos

Gepubliceerd 2026-04-30

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: María Belén Rodríguez, Petra van den Bos

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een robot probeert te leren autorijden. Je hebt twee hoofdmanieren om dit te doen:

De "Strakke Ingenieur"-manier (Modelgebaseerd testen): Je schrijft een complexe wiskundige blauwdruk van elke mogelijke weg, weersomstandigheid en verkeerslicht. Het is ongelooflijk precies en dekt elk scenario, maar alleen een wiskundige kan het lezen. Als je de baas wilt laten zien wat de robot zal doen, moet je de wiskunde terugvertalen naar Engels, wat moeilijk is en gevoelig voor fouten.
De "Verhaler"-manier (Gedragsgestuurd ontwikkelen): Je schrijft een verhaal: "Gegeven dat de auto op de weg is, Wanneer het licht rood wordt, Dan stopt de auto." Iedereen begrijpt dit. Het is makkelijk te schrijven en te lezen, maar het is alsof je een recept schrijft voor slechts één specifieke dag. Als je elke mogelijke verkeerslichttiming wilt testen, moet je duizenden aparte verhalen schrijven, wat een rommelige, onbeheersbare stapel papier wordt.

Het Probleem:
In de echte wereld willen bedrijven de precisie van de "Strakke Ingenieur" maar de leesbaarheid van de "Verhaler". Meestal moeten ze kiezen voor het een of het ander. Als ze kiezen voor het verhaal, missen ze verborgen bugs. Als ze kiezen voor de wiskunde, begrijpt niemand de tests.

De Oplossing: PICKLES
De auteurs van dit paper hebben een nieuw raamwerk ontwikkeld genaamd PICKLES (Precise Input and Control-flow Keyword-based Language for tEst Scenarios). Denk aan PICKLES als een "Universele Vertaler" die de kloof overbrugt tussen verhalen en wiskunde.

Hier is hoe het werkt, met een eenvoudige analogie:

1. Het "Slimme Recept" (De Taal)

In plaats van een verhaal te schrijven over één specifieke auto die stopt bij één specifiek rood licht, laat PICKLES je een "Slim Recept" schrijven.

Oude manier: "De auto stopt bij het rode licht op de Hoofdstraat." (Te specifiek).
PICKLES-methode: "De auto stopt bij elk rood licht, mits het licht rood is en de auto beweegt."
De Magie: Je kunt regels definiëren zoals "Het licht kan elke kleur hebben van Rood tot Groen" of "De auto kan elke snelheid hebben tussen 0 en 100". Dit heet parametrizatie. Het verandert een enkel verhaal in een regel die duizenden mogelijkheden tegelijk dekt.

2. De "Automatische Architect" (De Vertaling)

Zodra je deze "Slimme Recepten" in gewoon Engels schrijft (met een formaat vergelijkbaar met de populaire Gherkin-taal), fungeert het PICKLES-tool als een Automatische Architect.

Het leest je Engelse regels.
Het bouwt direct een Formeel Model (een complexe wiskundige kaart) op op de achtergrond.
Deze kaart is zo gedetailleerd dat het elke mogelijke route kent die het systeem kan nemen, zelfs routes die je niet expliciet hebt opgeschreven.

3. De "Meesterkaart" (Verhalen combineren)

Bij traditioneel testen test je Verhaal A, dan Verhaal B, dan Verhaal C, apart.

De Fout: Verhaal A werkt misschien, en Verhaal B werkt misschien, maar als je A dan B doet, kan het systeem crashen. Traditionele verhalen missen vaak deze "handdruk"-fouten.
De PICKLES-oplossing: Het tool neemt al je aparte verhalen en naait ze samen tot één grote "Meesterkaart". Het berekent hoe Verhaal A verbonden is met Verhaal B, en hoe Verhaal B verbonden is met Verhaal C. Het creëert een compleet beeld van hoe het systeem zich gedraagt in de tijd, niet alleen in geïsoleerde momenten.

4. De "Terugvertaling" (Leesbare resultaten)

Dit is het slimste deel. Het tool gebruikt de Meesterkaart om automatisch honderden specifieke testcases te genereren.

Normaal gesproken zouden deze tests eruitzien als verwarrende wiskundige code.
PICKLES neemt die wiskundige resultaten en vertaalt ze terug naar Engelse verhalen.
Dus, de tester krijgt een rapport dat zegt: "Hier is een specifieke test waarbij de auto 80 km/u reed en het licht na 2,5 seconden rood werd. De auto stopte correct."
De mens kan het lezen, begrijpen en verifiëren, zelfs al is het zware werk gedaan door de wiskundemotor.

De Echte Wereldtest (Het Verkeerssysteem)

De auteurs testten dit op een echt verkeersbeheersysteem dat wordt gebruikt door een bedrijf genaamd Technolution.

De Opstelling: Ze namen bestaande verhalen over verkeerssensoren die defecte detectoren opsporen.
Het Resultaat:
- Met de oude "Verhaler"-methode (verhalen één voor één draaien), testten ze slechts ongeveer 30% van de mogelijke systeemgedragingen.
- Met PICKLES (de verhalen combineren en de wiskundemotor gebruiken), bereikten ze 100% dekking van de systeemlogica.
- Ze deden dit zonder honderden nieuwe verhalen te schrijven. Ze maakten de originele verhalen gewoon "slimmer" door variabelen toe te voegen (zoals "elke rijbaan" of "elke positie") en lieten het tool de rest doen.

Waarom Dit Belangrijk Is

PICKLES stelt niet-technische mensen (zoals projectmanagers of businessanalisten) in staat om eisen in gewoon Engels te schrijven die eenduidig en wiskundig strikt zijn. Het zorgt ervoor dat:

Niemand in de war is: De eisen zijn voor iedereen duidelijk.
Geen bugs verborgen zijn: De wiskundemotor vindt randgevallen die mensen misschien missen.
Minder werk: Je schrijft minder verhalen om meer scenario's te testen.

Kortom, PICKLES is alsof je een robot een verhalenboek geeft dat slim genoeg is om elke mogelijke variatie van het verhaal te begrijpen, de wiskundeproblemen erin op te lossen, en vervolgens een duidelijk rapport terug te schrijven naar jou in gewoon Engels.

1. Probleemstelling

Het paper adresseert een kritieke spanning in industriële softwaretesting, met name voor veiligheidskritieke systemen:

De beperking van Model-Based Testing (MBT): Hoewel MBT rigoureuze, systematische en hoog-coverage testing biedt via formele modellen, wordt de adoptie gehinderd door de moeilijkheid om deze modellen te definiëren en te onderhouden. Ze vereisen vaak gespecialiseerde expertise, ontberen leesbaarheid voor niet-technische stakeholders en creëren communicatiebarrières.
De beperking van Behavior-Driven Development (BDD): BDD gebruikt menselijk leesbare, natuurlijke talige scenario's (Given-When-Then) om samenwerking te faciliteren. BDD vertrouwt echter op concrete voorbeelden, wat vaak leidt tot:
- Ambiguïteit en onvolledigheid: Natuurlijke taal kan vaag zijn.
- Lage coverage: Het testen van geïsoleerde voorbeelden mist vaak randgevallen en complexe interactie-sequenties.
- Onderhoudskosten: Grote suites van specifieke testcases zijn duur om te onderhouden en bij te werken.

De kernuitdaging: Hoe de precisie en hoge coverage van MBT te bereiken terwijl de toegankelijkheid, leesbaarheid en voordelen van stakeholder-samenwerking van BDD behouden blijven, zonder dat practitioners gedwongen worden om te kiezen tussen de twee.

2. Methodologie: Het PICKLES Framework

De auteurs stellen PICKLES (Precise Input and Control-flow Keyword-based Language for tEst Scenarios) voor, een framework dat BDD en MBT overbrugt via een bi-directionele vertaal-pijplijn.

A. De Domain Specific Language (PicklesDSL)

Pickles breidt de standaard Gherkin-syntaxis (Given-When-Then) uit met formele constructies om ambiguïteit te elimineren:

Variabele instellingen: Een prelude-blok waarin variabelen expliciet getypeerd zijn (bijv. integer, boolean, array, structuur) en domeinen/bereiken toegewezen krijgen (bijv. [1, 3], {AV, PART_AV}).
Parametrizatie: Stappen kunnen verwijzen naar variabelen en bevatten Guard Blokken (voorwaarden) met logische operatoren (EN, OF) en kwantoren (minimaal, maximaal, precies).
Structuur:
- Given: Definieert precondities en initiële staat-guards.
- When: Definieert input-interacties met parameters en guards.
- Then: Definieert verwachte outputs en validatie-guards.

B. Formele Semantiek: Symbolische Transitiestelsels (STS)

Het framework vertaalt PicklesDSL-specificaties naar Symbolische Transitiestelsels (STS), een formalisme dat Labelled Transition Systems uitbreidt met data-constructies.

Vertaling (Spec $\to$ STS):
- Elk Pickles-scenario wordt afgebeeld op een gedeeltelijk STS.
- Given-clausules worden initiële guards.
- When-clausules worden input-switches (transities).
- Then-clausules worden output-switches.
- Variabelen en guards worden afgebeeld op STS-parameters, locatie-variabelen en logische predicaten.
Modelcompositie:
- Individuele scenario-STS's worden samengesteld tot een Hoofdmodel.
- Keuze-compositie ( $\bowtie$ ): Voegt initiële staten van meerdere scenario's samen, waardoor elk scenario kan starten.
- Sequentiële compositie ( $\triangleright$ ): Verbindt de sink (eind) staten van één STS met de initiële staten van anderen, waardoor het genereren van lange uitvoeringstraces mogelijk is die meerdere scenario's combineren.

C. Testgeneratie en Reverse Vertaling

Testgeneratie: Standaard MBT-algoritmen (specifiek gericht op 100% switch-coverage) worden toegepast op het Hoofdmodel om formele testcases te genereren (sequenties van switches met specifieke parameterwaarden).
Reverse Vertaling (STS $\to$ Pickles): De formele testcases worden terugvertaald naar PicklesDSL-syntaxis.
- Input-waarden worden expliciet gedefinieerd in de When-stappen.
- Output-waarden worden vervangen door de originele Then-guards om het gedrag van het System Under Test (SUT) te valideren.
- Het resultaat is een uitvoerbare, menselijk leesbare testcase die compatibel is met standaard BDD-tools (bijv. Cucumber).

3. Belangrijkste Bijdragen

PicklesDSL: Een nieuwe Domain Specific Language die de Gherkin-structuur behoudt maar expliciete variabele typering, domeindefinities en controle-flow-beperkingen toevoegt, waardoor eenduidige specificaties gegarandeerd zijn.
Bi-directionele Vertaling: Een formele mapping tussen PicklesDSL en Symbolische Transitiestelsels (STS), wat naadloze beweging mogelijk maakt tussen menselijk leesbare requirements en formele modellen.
Hoofdmodel Compositie: Een methode om automatisch gedeeltelijke STS's uit individuele scenario's samen te stellen tot een unificerend Hoofdmodel, waardoor de ontdekking van complexe interactiefouten mogelijk wordt die geïsoleerde scenario's missen.
Prototype Implementatie: Een Python-gebaseerd hulpmiddel (met gebruik van de Lark-parser) dat de vertaal-, compositie- en reverse-vertaalprocessen automatiseert.
Industriële Validatie: Toepassing van het framework op een real-world verkeersmanagementcomponent van het bedrijf Technolution.

4. Resultaten

Het framework werd geëvalueerd met een case study die een component van een verkeersmanagementsysteem betrof. De resultaten toonden aanzienlijke verbeteringen ten opzichte van traditionele BDD-benaderingen met dezelfde set handmatig gedefinieerde scenario's:

Transitie Coverage:
- Traditionele BDD: Het uitvoeren van scenario's in isolatie dekte slechts ~30% van de mogelijke systeemtransities.
- Pickles: Door scenario's te compositen en tests te genereren vanuit het Hoofdmodel, steeg de coverage naar 100%. Dit vertegenwoordigt een verbetering van 70 procentpunten.
Input Coverage:
- Traditionele BDD met hardcoded waarden oefent een tiny fractie van mogelijke inputs uit.
- Pickles, door gebruik te maken van variabele domeinen en grenswaarde-analyse, vertegenwoordigde 112 distincte input-mogelijkheden voor één scenario (Scenario 02) die anders honderden handmatige testcases zouden vereisen. De studie merkte een verbetering van 98,5% in input coverage op ten opzichte van concrete BDD-voorbeelden.
Efficiëntie: Het handmatig bereiken van 100% transitie coverage zou ten minste zeven distincte testtraces hebben vereist. Pickles bereikte dit met slechts vier input-scenario's, wat de handmatige inspanning en onderhoudskosten aanzienlijk verlaagde.

5. Betekenis

Het PICKLES framework vertegenwoordigt een belangrijke stap voorwaarts in het toegankelijk maken van Model-Based Testing voor industriële practitioners:

Overbruggen van de Kloof: Het elimineert succesvol de trade-off tussen leesbaarheid en precisie. Stakeholders kunnen samenwerken aan requirements in natuurlijke taal, terwijl het systeem automatisch formele rigour waarborgt.
Shift-Left Testing: Door het mogelijk maken van automatische compositie van scenario's, wordt integratie- en systeemniveau-testing eerder in de ontwikkelingscyclus uitgevoerd, waardoor interactiefouten die geïsoleerde unit-tests missen, worden gedetecteerd.
Onderhoudbaarheid: Wijzigingen in requirements (bijv. variabele bereiken) worden automatisch doorgevoerd naar alle gegenereerde testcases, wat de onderhoudslast die gepaard gaat met grote BDD-suites vermindert.
Verklaarbaarheid: In tegenstelling tot black-box formele modellen, blijven de gegenereerde testcases in menselijk leesbaar Pickles-formaat, waardoor het eenvoudiger is om testresultaten uit te leggen aan niet-technische managers en auditors.

Concluderend toont PICKLES aan dat organisaties door natuurlijke talige specificaties te verankeren in formele semantiek en geautomatiseerde modelcompositie te benutten, de hoge betrouwbaarheid van MBT kunnen bereiken zonder de collaboratieve voordelen van BDD op te offeren.