Génération de Cas de Test par IA à Partir des Exigences : le Prompt qui Produit des Tests Exécutables

Vous avez quarante user stories dans le backlog du sprint et un ingénieur QA avec trois jours. Quelqu’un a déjà suggéré de coller les critères d’acceptation dans ChatGPT, et quelqu’un d’autre l’a essayé et a récupéré trente cas de test qui se lisent bien et ne peuvent pas être exécutés.

Les deux ont raison. La génération de cas de test par IA produit un premier brouillon utilisable en quelques minutes, et elle s’effondre avec un prompt d’une ligne, car un modèle sans contrat de sortie optimise pour paraître utile plutôt que pour être exécutable. La solution réside dans la structure du prompt plutôt que dans le choix du modèle : quatre parties fixes dans l’entrée, puis une passe de critique qui note le brouillon selon six angles de risque et ne régénère que les lacunes.

Ce qui revient, c’est du Gherkin, un scénario par cas, étiqueté de P0 à P2, chaque ligne tracée jusqu’au critère qu’elle couvre, prêt pour l’importateur Xray, TestRail, ou Jira. Ci-dessous se trouvent le modèle, la boucle, la grille de revue, et le point de bascule honnête.

Pourquoi la Génération de Cas de Test par IA Renvoie n'Importe Quoi avec un Prompt d'une Ligne

Le prompt avec lequel la plupart des équipes commencent est une version de « génère des cas de test pour cette exigence », et il renvoie une liste qu’un manager accepte et qu’un testeur ne peut pas utiliser. Stack Overflow a constaté que la frustration la plus courante avec les outils IA était « des solutions IA presque justes, mais pas tout à fait », rapportée par 66 % des répondants.

Les Quatre Choses qui Manquent à un Prompt d'une Ligne

• Structure d’entrée. Avec seulement du texte libre, le modèle invente les limites de la fonctionnalité et devine ce que signifie « locataire » dans votre produit.
• Format de sortie. Le texte libre renvoie « Vérifier que l’utilisateur peut se connecter », là où Gherkin renvoie un Given, When, et Then qu’un testeur peut exécuter.
• Étiquetage. Les cas non étiquetés arrivent comme une liste plate, tandis qu’une colonne de risque la transforme en un sous-ensemble P0 que vous exécutez à chaque build.
• Portée des cas limites. Laissé ouvert, le modèle produit des chemins heureux et une vérification nulle au lieu de l’expiration de session et de l’isolation des locataires.

Pourquoi le Résultat Semble « Raisonnable » mais n'Est pas Exécutable

Les cas se dupliquent entre les stories, car le modèle ne porte aucune mémoire de la story qu’il a traitée une minute plus tôt, et rien ne remonte à un critère, donc la couverture ne peut pas être rapportée. Les étapes arrivent sous forme de phrases narratives que deux testeurs lisent de deux façons, et chaque cas porte la même priorité implicite, donc la suite ne peut pas être réduite quand la date bouge.

Le Niveau d'Exigence de cet Article

Ce guide s’astreint à trois artefacts : un modèle de prompt, une boucle de critique, une grille de revue. Collez les trois dans Claude, ChatGPT, ou Gemini et vous devriez générer des cas de test à partir d’exigences qui reviennent dédupliqués, étiquetés par risque, et tracés.

Le Modèle de Prompt en Quatre Parties

Chaque partie ci-dessous élimine un échec spécifique nommé plus haut. L’ordre compte, car le modèle lit d’abord le contrat d’entrée et les garde-fous en dernier, et les garde-fous sont là où un plafond sur le nombre de cas prend effet.

Structure d'Entrée

Quatre entrées, dans cet ordre : le texte de l’exigence, les critères d’acceptation sous forme de liste à puces plutôt qu’un paragraphe, le contexte de la pile technique, et les six classes de cas limites ci-dessous. Le contexte de stack est la partie que les équipes sautent et celle qui change le plus la sortie.

Un modèle à qui l’on dit « Next.js app router, JWT avec tokens d’accès de 15 minutes, sécurité au niveau ligne Postgres, neuf locales incluant l’arabe » générera des cas de test à partir de user stories nommant la fenêtre de renouvellement du token et la mise en page de droite à gauche. Retirez-le et vous obtenez des cas qui conviennent à n’importe quel produit et n’en testent aucun.

La Demande

Demandez un tableau où chaque ligne est un scénario au format Given/When/Then, plus deux colonnes que le modèle n’ajoute jamais sans y être invité : une colonne de risque contenant P0, P1, ou P2, et une colonne de traçabilité nommant le critère couvert. Cette seconde colonne rend la couverture rapportable et la déduplication possible, car le modèle voit quels critères portent déjà trois cas.

Gherkin, spécifié par le projet Cucumber, mérite sa place pour une seconde raison. C’est le format que l’importateur de Xray lit nativement.

Contrainte de Rôle et de Voix

La ligne de rôle fait un vrai travail sur la verbosité et le jugement de triage. La nôtre dit : « Agis comme un ingénieur QA avec 8 ans d’expérience en SaaS d’entreprise. Écris des cas de test qu’un ingénieur humain exécutera aujourd’hui, et saute la couverture de fumée que le pipeline CI gère déjà. »

Garde-Fous de Sortie

Dédupliquez par rapport aux critères avant de renvoyer quoi que ce soit, et écartez tout cas de chemin heureux dont la clause Then ne fait que reformuler un critère mot pour mot, car cela teste la phrase plutôt que le logiciel. Le troisième garde-fou plafonne la sortie à trois cas par critère, sauf si un angle de risque se déclenche.

# PART 1 - INPUT
REQUIREMENT:


ACCEPTANCE CRITERIA:
- AC1: 
- AC2: 
- AC3: 

TECH-STACK CONTEXT:
- Framework:  
- Auth model: 
- Data store: 
- i18n scope: 

EDGE-CASE CLASSES TO COVER:
auth | permissions | concurrency | network | i18n | data-integrity

# PART 2 - THE ASK
Return a table. One row per test case. Columns:
  | ID | Title | Given | When | Then | Risk | Traces to |
- Given/When/Then: one line each, no supporting narrative.
- Risk: P0 (release blocker), P1 (this sprint), P2 (backlog).
- Traces to: the exact AC id this case covers.

# PART 3 - ROLE
Act as a QA engineer with 8 years of enterprise SaaS experience.
Write test cases a human engineer will run today.
Skip smoke coverage the CI pipeline already handles.

# PART 4 - GUARDRAILS
- Deduplicate against the acceptance criteria before returning.
- Drop any happy-path case whose Then only restates an AC verbatim.
- Cap at 3 cases per AC, unless an edge-case class above fires,
  then lift the cap for that AC only.
- Output the table and nothing else. No preamble, no summary.

La Boucle de Couverture à Six Angles

La plupart des guides sur comment écrire des cas de test avec l’IA s’arrêtent au premier prompt, qui est là où commence le travail intéressant. Un premier brouillon couvre ce que les critères ont dit à voix haute, et la boucle ci-dessous trouve ce qu’ils ont silencieusement supposé.

Les Six Angles

• Authentification. Expiration de session en pleine action, renouvellement de token sur une requête en cours, escalade de rôle après un changement de permission.
• Permissions. Cas limites RBAC, isolation des locataires, un utilisateur qui perd l’accès en gardant une page ouverte.
• Concurrence. Double soumission, deux onglets modifiant un enregistrement, conflits de verrouillage optimiste, courses sur un compteur partagé.
• Réseau. Délais d’attente, tempêtes de réessai, mode hors ligne, une réponse partielle renvoyant 200 avec la moitié du payload.
• i18n. Mise en page de droite à gauche, formats de date et de nombre selon la locale, chaînes qui cassent un contrôle à largeur fixe.
• Intégrité des données. Champs nullables, valeurs limites, emoji dans les noms, saisie de texte libre proche de l’injection.

Le Prompt de Critique

Recollez le tableau du premier brouillon dans la même conversation et demandez au modèle d’auditer sa propre sortie par rapport à chaque angle nommément. Les instructions numérotées battent un paragraphe ici, car le modèle répond à chaque point à son tour tandis qu’une demande en prose ne gagne qu’une seule phrase résumante.

Here is the suite you just generated: 

For each of the six edge-case classes (auth, permissions, concurrency,
network, i18n, data-integrity):
  1. List which of my cases cover that class. Cite case IDs.
  2. Score coverage of that class: none | partial | adequate.
  3. Name what a senior tester would expect to see that I am missing.

Then return ONLY the missing cases, in the same table format.
Do not restate cases I already have.

La dernière ligne est ce qui fait gagner du temps. Sans « ne renvoie que les cas manquants », le modèle renumérote tout et vous perdez la revue que vous aviez déjà faite.

Quand Arrêter la Boucle

Arrêtez-vous après deux passes, ou plus tôt si le modèle rapporte une couverture adéquate sur quatre des six angles. Une troisième passe produit de manière fiable des cas techniquement valides et commercialement inutiles.

Ce que la Boucle Détecte sur une Vraie User Story

Prenez une story simple : en tant qu’utilisateur récurrent, je peux me connecter avec e-mail et mot de passe et atterrir sur mon tableau de bord. Le premier brouillon a renvoyé des identifiants valides, un mot de passe invalide, un compte verrouillé, et une vérification de champ vide, puis la passe de critique a noté l’authentification partielle, l’i18n nulle, la concurrence nulle.

Scenario : La session expire pendant que le tableau de bord est ouvert        [P0, AC3]
  Given je suis connecté et inactif au-delà du TTL de 15 minutes du token d'accès
  When je déclenche une action du tableau de bord qui appelle l'API
  Then le token de rafraîchissement renouvelle la session silencieusement et l'action se termine

Scenario : Connexion simultanée depuis un second appareil            [P1, AC1]
  Given je suis connecté sur l'appareil A
  When je me connecte avec les mêmes identifiants sur l'appareil B
  Then les deux sessions restent valides et aucun tableau de bord n'affiche de données obsolètes

Scenario : Formulaire de connexion dans une locale de droite à gauche             [P1, AC2]
  Given ma locale est ar-SA
  When j'ouvre le formulaire de connexion
  Then les libellés, le contrôle d'affichage du mot de passe, et le texte de validation se reflètent correctement

Aucun des trois n’est exotique. Les trois atteignent la production précisément parce que les critères d’acceptation ne les ont jamais mentionnés.

Extraits de Prompt pour Claude, GPT-4o, et Gemini

Le modèle tourne inchangé sur les trois grands modèles de chat, et chacun a besoin d’une ligne corrective. Ces lignes ne coûtent rien et changent la sortie plus qu’un changement de modèle.

Claude Sonnet, Ajustements et Coût par Suite

Claude exécute la boucle de critique avec le moins d’incitations et respecte le plus fidèlement « ne renvoie que les cas manquants ». Son habitude est le remplissage narratif, ajoutez donc « une ligne par Given/When/Then, sans récit à l’appui » à la partie deux. Anthropic liste Claude Sonnet 5 à 2 $ par million de tokens en entrée et 10 $ par million en sortie.

GPT-4o, Ajustements et Coût par Suite

GPT-4o produit le brouillon initial le plus rapide et la critique d’angles la plus faible quand les angles arrivent en paragraphe. Collez-les plutôt sous forme d’énumération à puces, la correction la plus utile pour la génération de cas de test avec ChatGPT. OpenAI liste GPT-4o à 2,50 $ par million de tokens en entrée et 10 $ par million en sortie.

Gemini 2.5 Pro, Ajustements et Coût par Suite

Gemini utilise le mieux le contexte de la stack technique, produisant des cas d’intégrité de données spécifiques à l’ORM que les autres manquent. Sa faiblesse est la discipline Gherkin, ajoutez donc « Given/When/Then strict, pas de préambule en texte libre » à la partie deux. Google liste Gemini 2.5 Pro à 1,25 $ par million de tokens en entrée jusqu’à 200 000 tokens et 10 $ par million en sortie.

Les trois facturent les mêmes 10 $ par million de tokens en sortie, et une exécution en deux passes est dominée par la sortie, donc la qualité de sortie devrait décider du choix plutôt que le prix. Lisez les comptages réels de tokens dans la réponse d’usage de chaque API, et notez qu’Anthropic signale un tokenizer produisant environ 30 % de tokens en plus pour un texte identique sur les modèles plus récents.

L'Étape de Revue Humaine

La question sous-jacente à cette section, formulée comme on la taperait dans une barre de recherche, est de savoir si l’IA peut remplacer les testeurs manuels, et la réponse honnête est non. Le modèle rédige plus vite que n’importe quel humain, et un testeur décide de ce qui est livré et ajoute les cas limites du domaine que le modèle ne peut pas connaître.

Les données d’enquête soutiennent cette prudence. Stack Overflow rapporte que 46 % des développeurs se méfient activement de la précision des sorties IA contre 33 % qui leur font confiance.

La Grille de Notation à Trois Dimensions (Exécutabilité, Unicité, Valeur)

Notez chaque cas généré de 1 à 3 sur trois dimensions, puis supprimez tout ce qui est en dessous de 6 sur 9. Un 6 conserve des cas forts sur deux dimensions et faibles sur une, et nettoie le milieu qui fait paraître les suites rédigées par IA gonflées.

• Exécutabilité. Un testeur peut-il exécuter cela aujourd’hui avec les données qui existent déjà ? Une fixture que personne n’a construite obtient 1.
• Unicité. Couvre-t-il quelque chose qu’aucun autre cas ne couvre ? Les quasi-doublons sont attrapés ici.
• Valeur. Un échec ici compte-t-il ? Une limite de locataire cassée obtient 3, une infobulle mal alignée dans une petite locale obtient 1.

Les Cas Limites du Domaine que Seul un Humain Détecte

Trois catégories réapparaissent à chaque revue, et aucune n’est déductible d’un ticket. Des règles métier qui vivent dans des tickets de support, des régressions de sprints récents dont le modèle n’a aucune mémoire, et des cas limites spécifiques à une intégration d’entreprise, comme une API partenaire renvoyant 200 avec un corps d’erreur.

C’est là qu’une passe externalisée ressemble à une fonction QA plutôt qu’à un service de transcription. Elle applique la même discipline de notation que notre processus de tests manuels.

Ce que la Revue Prend Réellement

Budgétisez la revue explicitement, car c’est l’étape qui est coupée en premier. Sur un lot de 40 stories, la boucle renvoie une couple de centaines de cas bruts, et la notation avance à environ un cas toutes les quinze secondes, prévoyez donc qu’environ la moitié survit et près de quatre-vingt-dix livrés en une heure. Traitez cela comme une estimation de cadrage plutôt qu’un benchmark mesuré, et pour avoir une idée de ce que devient la suite maintenue, notre étude de cas Granola documente plus de 1 100 cas de test et 76 % de la suite de régression automatisée sur un produit de bloc-notes IA.

Faire Passer les Cas dans Jira, TestRail, ou Xray sans Passe de Réécriture

Le format de sortie a été choisi spécifiquement pour cette section. Un tableau Gherkin se trouve à une transformation de l’importateur intégré de chaque tracker majeur, et les trois voies ci-dessous utilisent des outils propriétaires que la plupart des équipes possèdent déjà sous licence.

Xray sur Jira (Importateur Cucumber)

Enregistrez les scénarios sous forme de fichiers .feature et postez-les vers le point de terminaison d’import de Xray à /api/v2/import/feature, qui accepte aussi un zip. Les tags de scénario deviennent des labels sur le ticket Test créé, donc la colonne de risque arrive comme @P0, et un tag avant la ligne Feature relie le Test à une exigence Jira existante. Xray note que la description de la Feature est ignorée à l’import.

TestRail (Importateur CSV + Mappage de Colonnes)

Exportez le même tableau en CSV et ouvrez la boîte de dialogue Import CSV depuis la barre d’outils du dépôt de cas de test. TestRail mappe les colonnes aux champs de cas à la deuxième étape et prend en charge le mappage de valeurs pour les listes déroulantes, transformant les chaînes P0/P1/P2 en vraies valeurs de priorité. Gardez un cas par ligne pour que la mise en page à ligne unique s’applique.

Le mappage qui fonctionne : Title vers Title, Given vers Preconditions, When vers Steps, Then vers Expected Result, Risk vers Priority, traçabilité vers References. Mappez chaque champ requis ou l’assistant ne se terminera pas.

Jira Natif (ScriptRunner / Forge)

Sans Xray, créez chaque cas comme son propre ticket lié à la story. Un script ScriptRunner parcourt le CSV et crée les tickets, et une app Forge fait de même via l’API de liaison de tickets Jira Cloud, qu’Atlassian documente comme nécessitant le scope write :issue-link :jira.

Quoi Ignorer

Sautez les plateformes d’intégration IA-vers-tracker commercialisées pour ce transfert. La sortie du prompt est déjà proche du CSV par conception et chaque importateur ci-dessus est propriétaire et documenté, donc cette couche résout un problème que le format de sortie a déjà supprimé.

Quand un LLM Simple ne Suffit Plus

Quatre signaux marquent le point où la boucle cesse de passer à l’échelle, et ils ont tendance à arriver ensemble. Surveillez ceux-ci plutôt qu’un nombre de mots dans votre document d’exigences.

• Le corpus dépasse le contexte. Au-delà d’environ 500 stories, la traçabilité inter-sprint devient le goulot d’étranglement et une fenêtre de chat ne peut pas voir ce qui est déjà couvert.
• La maintenance des prompts devient un travail. Quatre heures ou plus par semaine passées à ajuster des prompts relève de la comparaison face à une licence de plateforme.
• La conformité a besoin d’une piste d’audit. Les périmètres SOC 2, HIPAA, et ISO 27001 veulent le modèle et la version du prompt estampillés sur chaque cas.
• Les régressions récentes continuent de passer inaperçues. La génération de cas de test par prompts LLM ne porte aucune mémoire des incidents du dernier sprint, donc les mêmes lacunes réapparaissent.

À partir de là, le choix se réduit à deux voies : exécuter les passes vous-même sur une plateforme conçue à cet effet, où notre revue des meilleurs outils de test IA couvre l’inventaire agentique, ou confier la passe à une équipe QA qui l’exécute déjà, ce que couvrent nos services de tests IA, incluant le support d’ingénierie de prompts et la revue de la sortie LLM. Cette seconde voie se facture en Temps et Matériel contre un périmètre fixe, donc un premier lot est une dépense bornée.

Quand la Boucle se Termine et que le Sprint Commence

Le prompt en quatre parties et la boucle à six angles amènent le premier brouillon à l’exécutabilité, et la passe de notation et l’import dans le tracker le font entrer dans le sprint. Ces deux dernières étapes décident si la suite est utilisée ou silencieusement abandonnée.

Exécutez-le sur une story cet après-midi et comptez combien de cas survivent à la notation. Ce chiffre en dit plus sur vos exigences que sur le modèle, car les critères qui produisent du remplissage étaient généralement vagues au départ.

Une équipe QA peut aussi exécuter la boucle et faire entrer les cas dans votre tracker à chaque sprint. Si c’est un meilleur usage de la semaine de vos ingénieurs, contactez-nous et nous cadrerons le premier lot par rapport à votre backlog.

Questions Fréquentes

Découvrez comment nous avons construit et maintenu plus de 1 100 cas de test pour Granola, un bloc-notes IA, et automatisé 76 % de sa suite de régression

Veuillez saisir votre adresse courriel professionnelle n'est pas un courriel professionnel

Obtenir l’étude de cas