💻 computer science

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

Ce papier présente PICKLES, un cadre en langage naturel qui fait le pont entre le développement piloté par les comportements et les tests basés sur les modèles en traduisant des scénarios lisibles par l'homme en modèles formels pour permettre une génération automatique de tests avec une couverture nettement supérieure à celle du BDD standard.

Auteurs originaux : María Belén Rodríguez, Petra van den Bos

Publié 2026-04-30

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : María Belén Rodríguez, Petra van den Bos

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous essayez d'enseigner à un robot comment conduire une voiture. Vous avez deux façons principales de faire cela :

La méthode « Ingénieur Strict » (Tests basés sur le modèle) : Vous rédigez un plan mathématique complexe décrivant chaque route possible, chaque condition météorologique et chaque feu de circulation. C'est incroyablement précis et couvre tous les scénarios, mais seul un mathématicien peut le lire. Si vous voulez montrer au patron ce que le robot fera, vous devez traduire les mathématiques en anglais, ce qui est difficile et sujet aux erreurs.
La méthode « Conteur » (Développement piloté par le comportement) : Vous écrivez une histoire : « Étant donné que la voiture est sur la route, Lorsque le feu passe au rouge, Alors la voiture s'arrête. » Tout le monde comprend cela. C'est facile à écrire et à lire, mais c'est comme écrire une recette pour un jour spécifique seulement. Si vous voulez tester tous les synchronismes possibles des feux de circulation, vous devez écrire des milliers d'histoires séparées, ce qui devient un tas de papier désordonné et ingérable.

Le Problème :
Dans le monde réel, les entreprises souhaitent la précision de l'« Ingénieur Strict » mais la lisibilité du « Conteur ». Habituellement, elles doivent choisir l'un ou l'autre. Si elles choisissent l'histoire, elles manquent des bugs cachés. Si elles choisissent les mathématiques, personne ne comprend les tests.

La Solution : PICKLES
Les auteurs de cet article ont créé un nouveau cadre appelé PICKLES (Precise Input and Control-flow Keyword-based Language for tEst Scenarios). Considérez PICKLES comme un « Traducteur Universel » qui comble le fossé entre les histoires et les mathématiques.

Voici comment cela fonctionne, en utilisant une analogie simple :

1. La « Recette Intelligente » (Le Langage)

Au lieu d'écrire une histoire sur une voiture spécifique s'arrêtant à un feu rouge spécifique, PICKLES vous permet d'écrire une « Recette Intelligente ».

Ancienne méthode : « La voiture s'arrête au feu rouge de la rue Principale. » (Trop spécifique).
Méthode PICKLES : « La voiture s'arrête à n'importe quel feu rouge, à condition que le feu soit rouge et que la voiture soit en mouvement. »
La Magie : Vous pouvez définir des règles comme « Le feu peut être de n'importe quelle couleur, du Rouge au Vert » ou « La voiture peut avoir n'importe quelle vitesse entre 0 et 100 ». Cela s'appelle la paramétrisation. Cela transforme une seule histoire en une règle couvrant des milliers de possibilités à la fois.

2. L'« Architecte Automatique » (La Traduction)

Une fois que vous avez écrit ces « Recettes Intelligentes » en anglais simple (en utilisant un format similaire au langage Gherkin populaire), l'outil PICKLES agit comme un Architecte Automatique.

Il lit vos règles en anglais.
Il construit instantanément un Modèle Formel (une carte mathématique complexe) en arrière-plan.
Cette carte est si détaillée qu'elle connaît chaque chemin possible que le système pourrait emprunter, même les chemins que vous n'avez pas explicitement écrits.

3. La « Carte Maîtresse » (Combinaison des histoires)

Dans les tests traditionnels, vous testez l'Histoire A, puis l'Histoire B, puis l'Histoire C, séparément.

Le Défaut : L'Histoire A peut fonctionner, et l'Histoire B peut fonctionner, mais si vous faites A puis B, le système peut planter. Les histoires traditionnelles manquent souvent de ces erreurs de « poignée de main ».
La Correction PICKLES : L'outil prend toutes vos histoires séparées et les assemble en une seule « Carte Maîtresse » géante. Il détermine comment l'Histoire A se connecte à l'Histoire B, et comment l'Histoire B se connecte à l'Histoire C. Il crée une image complète du comportement du système dans le temps, et non pas seulement dans des moments isolés.

4. La « Retraduction » (Résultats lisibles)

C'est la partie la plus ingénieuse. L'outil utilise la Carte Maîtresse pour générer automatiquement des centaines de cas de test spécifiques.

Habituellement, ces tests ressortiraient sous forme de code mathématique confus.
PICKLES prend ces résultats mathématiques et les traduit à nouveau en histoires en anglais.
Ainsi, le testeur reçoit un rapport indiquant : « Voici un test spécifique où la voiture roulait à 50 mph et le feu est passé au rouge à 2,5 secondes. La voiture s'est arrêtée correctement. »
L'humain peut le lire, le comprendre et le vérifier, même si le travail lourd a été effectué par le moteur mathématique.

Le Test Réel (Le Système de Circulation)

Les auteurs ont testé cela sur un véritable système de gestion du trafic utilisé par une entreprise appelée Technolution.

La Configuration : Ils ont pris des histoires existantes concernant des capteurs de trafic détectant des détecteurs défectueux.
Le Résultat :
- En utilisant l'ancienne méthode du « Conteur » (exécutant les histoires une par une), ils n'ont testé qu'environ 30 % des comportements possibles du système.
- En utilisant PICKLES (en combinant les histoires et en utilisant le moteur mathématique), ils ont atteint 100 % de couverture de la logique du système.
- Ils ont fait cela sans écrire des centaines de nouvelles histoires. Ils ont simplement rendu les histoires originales « plus intelligentes » en ajoutant des variables (comme « n'importe quelle voie » ou « n'importe quelle position ») et ont laissé l'outil faire le reste.

Pourquoi Cela Importe

PICKLES permet aux personnes non techniques (comme les chefs de projet ou les analystes d'affaires) de rédiger des exigences en anglais simple qui sont non ambiguës et mathématiquement rigoureuses. Cela garantit que :

Personne n'est confus : Les exigences sont claires pour tout le monde.
Aucun bug n'est caché : Le moteur mathématique trouve des cas limites que les humains pourraient manquer.
Moins de travail : Vous écrivez moins d'histoires pour tester plus de scénarios.

En bref, PICKLES revient à donner à un robot un livre d'histoires assez intelligent pour comprendre chaque variation possible de l'histoire, résoudre les problèmes mathématiques qui s'y trouvent, puis rédiger un rapport clair pour vous en anglais simple.

1. Énoncé du problème

Le document aborde une tension critique dans les tests logiciels industriels, en particulier pour les systèmes critiques pour la sécurité :

La limitation des tests basés sur des modèles (MBT) : Bien que le MBT offre des tests rigoureux, systématiques et à haute couverture via des modèles formels, son adoption est entravée par la difficulté de définir et de maintenir ces modèles. Ils nécessitent souvent une expertise spécialisée, manquent de lisibilité pour les parties prenantes non techniques et créent des barrières de communication.
La limitation du développement piloté par le comportement (BDD) : Le BDD utilise des scénarios en langage naturel lisibles par l'homme (Étant donné-Quand-Alors) pour faciliter la collaboration. Cependant, le BDD repose sur des exemples concrets, ce qui conduit souvent à :
- Ambiguïté et incomplétude : Le langage naturel peut être vague.
- Faible couverture : Tester des exemples isolés manque souvent les cas limites et les séquences d'interactions complexes.
- Coûts de maintenance : De grandes suites de cas de tests spécifiques sont coûteuses à maintenir et à mettre à jour.

Le défi central : Comment atteindre la précision et la haute couverture du MBT tout en conservant l'accessibilité, la lisibilité et les avantages de collaboration des parties prenantes du BDD, sans obliger les praticiens à choisir entre les deux.

2. Méthodologie : Le cadre PICKLES

Les auteurs proposent PICKLES (Langage basé sur des mots-clés pour les Scénarios de test à Entrée et Flux de Contrôle Précis), un cadre qui fait le pont entre le BDD et le MBT grâce à un pipeline de traduction bidirectionnel.

A. Le langage spécifique au domaine (PicklesDSL)

Pickles étend la syntaxe Gherkin standard (Étant donné-Quand-Alors) avec des constructions formelles pour éliminer l'ambiguïté :

Paramétrage des variables : Un bloc de préambule où les variables sont explicitement typées (par exemple, entier, booléen, tableau, structure) et où des domaines/intervalles sont assignés (par exemple, [1, 3], {AV, PART_AV}).
Paramétrisation : Les étapes peuvent faire référence à des variables et inclure des Blocs de garde (conditions) utilisant des opérateurs logiques (ET, OU) et des quantificateurs (au moins, au plus, exactement).
Structure :
- Étant donné : Définit les préconditions et les gardes d'état initial.
- Quand : Définit les interactions d'entrée avec des paramètres et des gardes.
- Alors : Définit les sorties attendues et les gardes de validation.

B. Sémantique formelle : Systèmes de Transition Symboliques (STS)

Le cadre traduit les spécifications PicklesDSL en Systèmes de Transition Symboliques (STS), un formalisme étendant les Systèmes de Transition Étiquetés avec des constructions de données.

Traduction (Spécification $\to$ STS) :
- Chaque scénario Pickles correspond à un STS partiel.
- Les clauses Étant donné deviennent des gardes initiales.
- Les clauses Quand deviennent des commutateurs d'entrée (transitions).
- Les clauses Alors deviennent des commutateurs de sortie.
- Les variables et les gardes sont mappées sur des paramètres STS, des variables de localisation et des prédicats logiques.
Composition de modèles :
- Les STS de scénarios individuels sont composés en un Modèle Maître.
- Composition par choix ( $\bowtie$ ) : Fusionne les états initiaux de plusieurs scénarios, permettant à n'importe quel scénario de démarrer.
- Composition séquentielle ( $\triangleright$ ) : Connecte les états puits (fin) d'un STS aux états initiaux d'autres, permettant la génération de longues traces d'exécution combinant plusieurs scénarios.

C. Génération de tests et traduction inverse

Génération de tests : Des algorithmes standards de MBT (visant spécifiquement une couverture de commutateur de 100 %) sont appliqués au Modèle Maître pour générer des cas de tests formels (séquences de commutateurs avec des valeurs de paramètres spécifiques).
Traduction inverse (STS $\to$ Pickles) : Les cas de tests formels sont traduits de nouveau en syntaxe PicklesDSL.
- Les valeurs d'entrée sont explicitement définies dans les étapes Quand.
- Les valeurs de sortie sont remplacées par les gardes Alors originales pour valider le comportement du Système Sous Test (SUT).
- Le résultat est un cas de test exécutable et lisible par l'homme, compatible avec les outils BDD standards (par exemple, Cucumber).

3. Contributions clés

PicklesDSL : Un nouveau langage spécifique au domaine qui préserve la structure Gherkin mais ajoute un typage explicite des variables, des définitions de domaines et des contraintes de flux de contrôle, garantissant des spécifications sans ambiguïté.
Traduction bidirectionnelle : Une correspondance formelle entre PicklesDSL et les Systèmes de Transition Symboliques (STS), permettant un passage fluide entre les exigences lisibles par l'homme et les modèles formels.
Composition de Modèle Maître : Une méthode pour composer automatiquement des STS partiels issus de scénarios individuels en un Modèle Maître unifié, permettant la découverte de bugs d'interaction complexes que les scénarios isolés manquent.
Implémentation de prototype : Un outil basé sur Python (utilisant le parseur Lark) qui automatise les processus de traduction, de composition et de traduction inverse.
Validation industrielle : Application du cadre à un composant réel de gestion du trafic de la société Technolution.

4. Résultats

Le cadre a été évalué à l'aide d'une étude de cas impliquant un composant de système de gestion du trafic. Les résultats ont démontré des améliorations significatives par rapport aux approches BDD traditionnelles utilisant le même ensemble de scénarios définis manuellement :

Couverture des transitions :
- BDD traditionnel : L'exécution de scénarios isolés ne couvrait que ~30 % des transitions système possibles.
- Pickles : En composant les scénarios et en générant des tests à partir du Modèle Maître, la couverture a augmenté à 100 %. Cela représente une amélioration de 70 points de pourcentage.
Couverture des entrées :
- Le BDD traditionnel avec des valeurs codées en dur ne teste qu'une infime fraction des entrées possibles.
- Pickles, en utilisant des domaines de variables et une analyse des limites, a représenté 112 possibilités d'entrée distinctes pour un seul scénario (Scénario 02) qui aurait autrement nécessité des centaines de cas de tests manuels. L'étude a noté une amélioration de 98,5 % de la couverture des entrées par rapport aux exemples BDD concrets.
Efficacité : Atteindre une couverture de transitions de 100 % manuellement aurait nécessité au moins sept traces de tests distinctes. Pickles a atteint cet objectif avec seulement quatre scénarios d'entrée, réduisant considérablement l'effort manuel et les coûts de maintenance.

5. Importance

Le cadre PICKLES représente une avancée significative pour rendre les tests basés sur des modèles accessibles aux praticiens industriels :

Combler le fossé : Il élimine avec succès le compromis entre lisibilité et précision. Les parties prenantes peuvent collaborer sur les exigences en langage naturel, tandis que le système assure automatiquement la rigueur formelle.
Tests Shift-Left : En permettant la composition automatique de scénarios, il permet de réaliser des tests d'intégration et au niveau système plus tôt dans le cycle de développement, détectant des bugs d'interaction que les tests unitaires isolés manquent.
Maintenabilité : Les modifications des exigences (par exemple, les plages de variables) se propagent automatiquement à tous les cas de tests générés, réduisant la charge de maintenance associée aux grandes suites BDD.
Explicabilité : Contrairement aux modèles formels boîte noire, les cas de tests générés restent au format Pickles lisible par l'homme, facilitant l'explication des résultats des tests aux managers et aux auditeurs non techniques.

En conclusion, PICKLES démontre qu'en ancrant les spécifications en langage naturel dans une sémantique formelle et en tirant parti de la composition automatisée de modèles, les organisations peuvent atteindre la haute fiabilité du MBT sans sacrifier les avantages collaboratifs du BDD.