💻 computer science

LLM-Based Robustness Testing of Microservice Applications: An Empirical Study

Cette étude empirique démontre que la stratégie de prompt influence significativement la diversité et la couverture des tests de robustesse générés par les LLM pour les API de microservices, révélant qu'une approche few-shot guidée par une taxonomie surpasse à la fois les ensembles de modèles plus grands et les prompts fixes pour mettre en évidence des modes de défaillance distincts.

Auteurs originaux : Hrushitha Goud Tigulla, Marco Vieira

Publié 2026-05-15

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Hrushitha Goud Tigulla, Marco Vieira

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 possédiez un restaurant très fréquenté avec une cuisine (l'application principale) et plusieurs postes spécialisés : un comptoir à salades, un gril, un poste de boissons et une caisse. Chaque poste est un « microservice ». Ils communiquent entre eux pour exécuter votre commande.

Maintenant, imaginez que vous vouliez vous assurer que votre restaurant ne plante pas si un client fait quelque chose d'étrange. Peut-être qu'il essaie de commander une salade avec un nombre négatif d'articles, ou qu'il tente de payer sans carte de crédit, ou qu'il envoie un message trop long à lire. Cela s'appelle le Test de Robustesse : essayer intentionnellement de casser le système avec des entrées « mauvaises » pour voir où il échoue.

Le problème est que les humains sont fatigués. Nous ne pouvons pas imaginer chaque chose étrange qu'un client pourrait faire. Alors, les chercheurs de cet article se sont demandé : Pouvons-nous utiliser l'IA (spécifiquement les Grands Modèles de Langage ou LLM) pour générer ces tests étranges pour nous ?

Voici ce qu'ils ont découvert, expliqué simplement :

1. La Configuration : Les Chefs IA

Les chercheurs ont engagé trois « Chefs IA » différents (des modèles d'IA de tailles et de spécialités variées) pour écrire ces tests. Ils leur ont donné le menu du restaurant (les spécifications de l'API) et leur ont demandé de générer des tests.

Ils ont essayé 7 façons différentes de demander (appelées « Stratégies de Prompt ») :

La Table Rase : Dire simplement « Écrivez quelques tests ».
Le Manager Strict : Leur donner une liste de contrôle exacte de ce qu'il faut tester.
Le Professeur : Leur montrer d'abord des exemples de mauvais tests.
Le Penseur : Leur demander de réfléchir étape par étape avant d'écrire.
Le Guide Expert : Leur donner un manuel de règles expliquant comment les choses peuvent casser, ainsi que des exemples de situations spécifiques et piégeuses.

2. La Grande Découverte : La Façon de Demander Compte Plus que l'IA Utilisée

La découverte la plus surprenante a été que la façon dont vous posez la question compte plus que l'IA que vous utilisez.

Le Piège du « Manager Strict » : Lorsqu'ils ont donné une liste de contrôle stricte à l'IA (le prompt « Structuré »), les trois IA ont écrit exactement les mêmes tests. C'était comme donner à trois chefs différents la même carte de recette ; ils ont tous préparé exactement le même plat. C'est mauvais car si la recette a un angle mort, vous le manquez.
Le Succès du « Guide Expert » : Lorsqu'ils ont donné à l'IA un manuel ainsi que des exemples clairs de situations piégeuses (comme la différence entre « une clé manquante » et « une clé vide »), les IA ont commencé à penser différemment. Elles ont trouvé des bugs uniques que les autres avaient manqués.

L'Analogie : Imaginez que vous cherchez des clés perdues dans une maison.

Si vous dites à trois personnes différentes : « Cherchez dans la cuisine », elles regarderont toutes dans la cuisine. Si les clés n'y sont pas, vous ne trouvez rien.
Si vous leur dites : « Cherchez dans la cuisine, mais vérifiez aussi le réfrigérateur, le grille-pain et le lit du chat », elles se disperseront et trouveront plus d'endroits.
L'article a montré que changer la façon dont vous dites à l'IA de chercher (le prompt) était plus efficace que d'embaucher une « meilleure » IA.

3. Le Paradoxe du « Spécialiste en Code »

L'une des IA était un « Spécialiste en Code » (entraîné spécifiquement pour écrire du code). Vous pourriez penser qu'elle serait la meilleure pour trouver des bugs.

Le Problème : Lorsqu'on lui a demandé de simplement « critiquer et améliorer » son propre travail (une stratégie appelée Auto-affinement ou Self-Refine), ce spécialiste a écrit un code parfait qui ne vérifiait pas réellement les erreurs. C'était comme un chef qui a fait un magnifique gâteau mais a oublié de le goûter pour voir s'il était brûlé.
La Solution : Lorsque les chercheurs ont donné à ce spécialiste le « Guide Expert » (le manuel avec des exemples), il est soudainement devenu le meilleur performant, trouvant plus de bugs que n'importe quelle autre combinaison. Le manuel lui a donné l'« intention adverse » — l'état d'esprit pour essayer de casser les choses, ce que sa formation en code ne lui avait pas donné seul.

4. La Surprise du « Zero-Shot »

Il y avait une stratégie où ils ont donné à l'IA aucune instruction du tout, juste le menu.

Le Résultat : Cette IA a trouvé un type spécifique de bug que les autres avaient manqué : les bugs basés sur l'état.
L'Analogie : Les autres IA étaient concentrées sur « L'ingrédient est-il frais ? » (vérification des données). L'IA « Zero-Shot » pensait : « Attendez, est-ce que le client a essayé de commander un dessert avant d'avoir commandé un plat principal ? » (vérification du flux).
Leçon : Même une IA « bête » ou non guidée peut trouver des erreurs logiques étranges qu'une IA hautement guidée manque, car l'IA guidée est trop focalisée sur les règles.

5. La Confusion entre « Clé-Absente » et « Valeur-Vide »

L'article met en évidence une confusion spécifique que les IA avaient.

La Règle : « Si une valeur est manquante, définissez-la sur null. »
L'Erreur de l'IA : Les IA ont interprété cela comme « Définissez la valeur sur une chaîne vide » (comme nom="").
La Réalité : Dans les systèmes informatiques, nom="" (vide) et nom (manquant entièrement) sont deux choses totalement différentes qui cassent le système de manières différentes.
La Solution : Les IA ne pouvaient pas faire la différence jusqu'à ce que les chercheurs leur montrent des exemples concrets des deux. Une fois qu'elles ont vu la différence, elles ont pu tester les deux scénarios.

Résumé des Enseignements

N'engagez pas simplement une IA plus grosse : Une petite IA avec un meilleur prompt peut battre une géante IA avec un mauvais prompt.
Ne soyez pas trop strict : Si vous donnez à l'IA une liste de contrôle rigide, elles feront toutes exactement la même chose. Vous devez leur donner des règles mais leur laisser de la créativité.
Montrez, ne faites pas que dire : Si vous voulez que l'IA comprenne une différence subtile (comme « manquant » vs « vide »), vous devez lui montrer un exemple.
Mélangez vos stratégies : Pour trouver le plus de bugs, vous ne devriez pas exécuter un seul test. Vous devriez exécuter un mélange : certains tests stricts, certains tests guidés, et même certains tests « joker » sans instructions.

En bref, l'article prouve que la façon dont vous parlez à l'IA est la sauce secrète pour trouver des bugs logiciels, et non pas simplement la taille de l'IA elle-même.

Résumé Technique : Tests de Robustesse Basés sur les LLM pour les Applications Microservices

Énoncé du Problème
Les architectures microservices sont vulnérables aux menaces de fiabilité lorsque des entrées malformées, manquantes ou aux valeurs limites se propagent en cascade à travers les services dépendants. Bien que les tests de robustesse exercent systématiquement de telles entrées pour révéler des défaillances côté serveur, la génération de cas de test diversifiés et efficaces reste un défi majeur. Bien que les modèles de langage de grande taille (LLM) puissent générer des tests à partir de spécifications d'API, il est incertain que différentes architectures de modèles et stratégies de prompt produisent des ensembles diversifiés de modes de défaillance ou s'ils convergent vers les mêmes bogues. Les recherches existantes se concentrent sur la correction du code et les taux de compilation, mais manquent de preuves empiriques sur la diversité des modes de défaillance découverts à travers les configurations modèle-prompt dans des systèmes microservices en fonctionnement.

Méthodologie
Les auteurs ont mené une étude empirique contrôlée appliquant la génération de tests basée sur les LLM à deux systèmes microservices open-source architecturalement distincts :

TeaStore : Une application monolingue basée sur Java avec 6 services communiquant via HTTP encodé sous forme.
OTel Astronomy Shop : Une application polyglotte avec 27 services (Go, C++, Rust, JS, .NET, etc.) communiquant via des API JSON et gRPC.

L'étude a utilisé 3 LLM open-source (14B, 32B spécialisé en code et 70B paramètres) et 7 stratégies de prompt regroupées en trois catégories :

Lignes de base : ZeroShot (spécification d'API uniquement) et Structuré (tableau de violations préconstruit mappant les endpoints aux mutations).
Techniques établies : FewShot (exemples de motifs de défaillance), Chain-of-Thought (CoT) et Self-Refine.
Stratégies de connaissance du domaine : Guided (intégrant la taxonomie de mutation de Vieira et al. [1] comme contexte) et GuidedFewShot (ajoutant la classification des défaillances CRASH et des exemples concrets distinguant les mutations absence-clé vs valeur-vide).

Le pipeline expérimental a impliqué la génération de code de test Java/JUnit 5, le nettoyage des sorties, leur exécution contre des déploiements Docker en direct, et la classification des défaillances de robustesse basée sur les codes de statut HTTP $\ge$ 500 (la classe "Abort"). L'étude a défini les Modes de Défaillance (MD) comme des triplets uniques (endpoint, paramètre, type-de-mutation) vérifiés contre le code source, identifiant 9 MD pour TeaStore et 14 pour OTel. La diversité a été mesurée à l'aide de la similarité de Jaccard par paires des ensembles de MD déclenchés.

Contributions Clés

Dominance de la Stratégie de Prompt : Preuve empirique démontrant que la stratégie de prompt explique plus de variation dans la diversité des tests que la taille du modèle. Changer le prompt pour un modèle fixe produit une plus grande variation d'ensembles de modes de défaillance que changer le modèle sous un prompt fixe.
Effondrement Structuré : Identification d'un phénomène où un prompt prescriptif (Structuré) amène tous les modèles à produire des ensembles de modes de défaillance identiques (similarité de Jaccard = 1,00), éliminant efficacement la diversité.
Nouvelles Stratégies de Prompt : Introduction des stratégies Guided et GuidedFewShot intégrant des taxonomies de mutation comme contexte de domaine. GuidedFewShot adresse spécifiquement l'ambiguïté des règles de mutation (par exemple, distinguer la suppression d'une clé de la définition d'une valeur comme vide) grâce à des exemples concrets.
Transformation des Performances : Preuve qu'une connaissance du domaine peut transformer une configuration à couverture zéro en la plus performante. Le modèle spécialisé en code (qwen2.5-coder:32b) a déclenché zéro défaillance sous Self-Refine mais a atteint la couverture la plus élevée en exécution unique (56 % sur TeaStore, 57 % sur OTel) sous GuidedFewShot.
Modèle Unique vs Multi-Modèles : Démonstration que la variation des stratégies de prompt pour un modèle unique surpasse l'utilisation de plusieurs modèles avec un seul prompt. Par exemple, qwen2.5-coder:32b a atteint 100 % de couverture des MD sur OTel en variant les prompts sur trois stratégies, surpassant tout ensemble multi-modèles sous un prompt fixe.

Résultats

Couverture : Aucune exécution unique n'a atteint une couverture complète sur l'un ou l'autre système (la couverture maximale en exécution unique était de 57 %). Cependant, la couverture par union variait considérablement selon la stratégie. FewShot a atteint 89 % de couverture par union sur TeaStore, tandis que GuidedFewShot a atteint 64 % sur OTel.
Diversité : Le prompting Structuré a résulté en une diversité nulle (J=1,00). Self-Refine sur OTel a produit la plus grande diversité (J=0,00) mais avec une faible couverture. GuidedFewShot a maintenu une faible similarité (haute diversité) tout en atteignant une couverture élevée, particulièrement sur OTel (J=0,12).
La Limitation "Absence-de-Clé" : L'étude a constaté que les LLM recevant uniquement des règles de taxonomie (dans Guided) échouaient systématiquement à générer des mutations "absence-de-clé" (omission d'une clé de paramètre), interprétant "remplacer par null" comme la définition d'une valeur à une chaîne vide. GuidedFewShot a résolu cela en fournissant des exemples explicites des deux types de mutations.
Défaillances Basées sur l'État : ZeroShot était la seule stratégie à découvrir des modes de défaillance basés sur l'état (par exemple, supprimer un article du panier sans authentification), que les stratégies axées sur les paramètres ont manqués.

Signification et Revendications
L'article revendique que pour les tests de robustesse dans les microservices, l'ingénierie des prompts est plus critique que la sélection du modèle. Les auteurs soutiennent que les praticiens ne doivent pas se fier à une seule configuration modèle-prompt, car cela fournit une vue incomplète de la surface de défaillance du système. Au lieu de cela, ils recommandent :

D'utiliser GuidedFewShot comme une forte ligne de base pour les scénarios modèle unique-prompt unique en raison de sa haute couverture en exécution unique et de sa diversité maintenue.
D'employer le test multi-configuration (variation des prompts pour un modèle unique) comme une voie plus efficace vers une couverture élevée que l'exécution de plusieurs modèles avec un seul prompt.
D'inclure au moins une exécution ZeroShot pour capturer les défaillances basées sur l'état que les stratégies axées sur les mutations négligent.
De reconnaître que la connaissance du domaine (taxonomies de mutation) doit être accompagnée d'exemples concrets pour désambiguïser les implémentations au niveau du protocole (par exemple, la gestion des paramètres HTTP) que les LLM pourraient interpréter incorrectement en fonction des distributions de leurs données d'entraînement.

L'étude conclut que bien que les LLM puissent générer des tests de robustesse, leur efficacité dépend fortement de la manière dont la connaissance du domaine est formulée dans le prompt, et qu'une combinaison de stratégies est nécessaire pour maximiser la découverte de défaillances.