💻 computer science

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

Deze empirische studie toont aan dat de promptstrategie de diversiteit en dekking van door LLM's gegenereerde robuustheidstests voor microservice-API's aanzienlijk beïnvloedt, en onthult dat een door een taxonomie geleide few-shot-benadering zowel grotere modelensembles als vaste prompts overtreft in het blootleggen van onderscheidende faalmodi.

Oorspronkelijke auteurs: Hrushitha Goud Tigulla, Marco Vieira

Gepubliceerd 2026-05-15

📖 6 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Hrushitha Goud Tigulla, Marco Vieira

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 drukke restaurant bezit met een keuken (de hoofd-app) en verschillende gespecialiseerde stations: een saladebar, een grill, een drankenstation en een kassa. Elk station is een "microservice". Ze praten met elkaar om je bestelling te verwerken.

Stel je nu voor dat je wilt verzekeren dat je restaurant niet crasht als een klant iets raars doet. Misschien proberen ze een salade te bestellen met een negatief aantal items, of proberen ze te betalen zonder creditcard, of sturen ze een bericht dat te lang is om te lezen. Dit heet Robuustheidstesten: het systematisch proberen om het systeem te breken met "slechte" invoer om te zien waar het faalt.

Het probleem is dat mensen moe zijn. We kunnen niet aan elke rare ding bedenken die een klant zou kunnen doen. Daarom vroegen de onderzoekers in dit artikel: Kunnen we AI (specifiek Large Language Models of LLM's) gebruiken om deze rare tests voor ons te bedenken?

Hier is wat ze ontdekten, eenvoudig uitgelegd:

1. De Opzet: De AI-chefs

De onderzoekers huurden drie verschillende "AI-chefs" (AI-modellen van verschillende groottes en specialismen) in om deze tests te schrijven. Ze gaven hen het restaurantmenu (de API-specificaties) en vroegen hen om tests te genereren.

Ze probeerden 7 verschillende manieren om het te vragen (zogenaamde "Prompt-strategieën"):

Het Blankscherm: Gewoon zeggen "Schrijf wat tests."
De Strikte Manager: Ze een checklist geven van precies wat er getest moet worden.
De Leraar: Ze eerst voorbeelden van slechte tests laten zien.
De Denker: Ze vragen om stap voor stap na te denken voordat ze schrijven.
De Expert Gids: Ze een regelboek geven van hoe dingen kunnen breken, plus voorbeelden van specifieke lastige situaties.

2. De Grote Ontdekking: Hoe Je Vraagt Is Belangrijker dan Wie Je Vraagt

De meest verrassende bevinding was dat de manier waarop je de vraag stelt belangrijker is dan welke AI je gebruikt.

De "Strikte Manager"-valstrik: Toen ze de AI een strikte checklist gaven (de "gestructureerde" prompt), schreven alle drie de AI's exact dezelfde tests. Het was alsof je drie verschillende chefs exact hetzelfde receptkaartje gaf; ze maakten allemaal exact hetzelfde gerecht. Dit is slecht, want als het recept een blinde vlek heeft, mis je die.
Het Succes van de "Expert Gids": Toen ze de AI een regelboek gaven plus duidelijke voorbeelden van lastige situaties (zoals het verschil tussen "een sleutel missen" en "een lege sleutel hebben"), begonnen de AI's anders na te denken. Ze vonden unieke bugs die de anderen misten.

De Analogie: Stel je voor dat je zoek naar verloren sleutels in een huis.

Als je drie verschillende mensen zegt: "Kijk in de keuken", zullen ze allemaal in de keuken kijken. Als de sleutels daar niet zijn, vind je niets.
Als je hen zegt: "Kijk in de keuken, maar controleer ook de koelkast, de broodrooster en het bed van de kat", zullen ze zich verspreiden en meer plekken vinden.
Het artikel vond dat het veranderen van hoe je de AI vertelt waar te zoeken (de prompt) effectiever was dan het inhuren van een "beter" AI.

3. De "Code Specialist"-Paradox

Een van de AI's was een "Code Specialist" (specifiek getraind om code te schrijven). Je zou denken dat deze het beste zou zijn in het vinden van bugs.

Het Probleem: Toen ze gevraagd werd om gewoon haar eigen werk te "critiseren en verbeteren" (een strategie genaamd Self-Refine), schreef deze specialist perfecte code die niet daadwerkelijk controleerde op fouten. Het was alsof een chef een prachtige taart maakte maar vergeet te proeven om te zien of hij verbrand was.
De Oplossing: Toen de onderzoekers deze specialist de "Expert Gids" gaven (het regelboek met voorbeelden), werd het plotseling de beste performer, meer bugs vindend dan enige andere combinatie. Het regelboek gaf haar de "adversaire intentie" – de instelling om dingen te proberen te breken, wat haar code-training op zichzelf niet gaf.

4. De "Zero-Shot"-Verrassing

Er was één strategie waarbij ze de AI geen instructies gaven, alleen het menu.

Het Resultaat: Deze AI vond een specifiek type bug dat de anderen misten: Op staat gebaseerde bugs.
De Analogie: De andere AI's waren gefocust op "Is het ingrediënt vers?" (het controleren van de data). De "Zero-Shot"-AI dacht: "Wacht, heeft de klant geprobeerd dessert te bestellen voordat ze een hoofdgerecht bestelden?" (het controleren van de flow).
Les: Zelfs een "domme" of ongestuurde AI kan rare, logische fouten vinden die een sterk gestuurde AI mist, omdat de gestuurde AI te gefocust is op de regels.

5. De Verwarring tussen "Afwezige Sleutel" en "Lege Waarde"

Het artikel benadrukt een specifieke verwarring die de AI's hadden.

De Regel: "Als een waarde ontbreekt, stel deze dan in op null."
De Fout van de AI: De AI's interpreteerden dit als "Stel de waarde in op een lege string" (zoals naam="").
De Realiteit: In computersystemen zijn naam="" (leeg) en naam (helemaal afwezig) twee totaal verschillende dingen die het systeem op verschillende manieren breken.
De Oplossing: De AI's konden het verschil niet zien totdat de onderzoekers hen concrete voorbeelden van beide toonden. Zodra ze het verschil zagen, konden ze beide scenario's testen.

Samenvatting van de Kernpunten

Huur niet zomaar een grotere AI in: Een kleinere AI met een betere prompt kan een gigantische AI met een slechte prompt verslaan.
Wees niet te streng: Als je de AI een rigide checklist geeft, zullen ze allemaal exact hetzelfde doen. Je moet hen regels geven maar hen creatief laten zijn.
Toon, vertel niet alleen: Als je wilt dat de AI een subtiel verschil begrijpt (zoals "ontbreken" versus "leeg"), moet je hen een voorbeeld laten zien.
Meng je strategieën: Om de meeste bugs te vinden, moet je niet slechts één test uitvoeren. Je moet een mix uitvoeren: sommige strenge tests, sommige geleide tests, en zelfs sommige "wildcard"-tests zonder instructies.

Kortom, het artikel bewijst dat hoe je met de AI praat de geheime saus is voor het vinden van softwarebugs, niet alleen de grootte van de AI zelf.

Technische Samenvatting: Robuustheidstesten van Microservice-toepassingen op Basis van LLM's

Probleemstelling
Microservice-architecturen zijn vatbaar voor betrouwbaarheidsbedreigingen wanneer misvormde, ontbrekende of grenswaarde-invoer zich doorheen afhankelijke services voortplant. Hoewel robuustheidstesten dergelijke invoer systematisch toetst om serverkantige fouten aan het licht te brengen, blijft het genereren van diverse en effectieve testgevallen een aanzienlijke uitdaging. Hoewel Large Language Models (LLM's) tests kunnen genereren op basis van API-specificaties, is het onduidelijk of verschillende modelarchitecturen en promptstrategieën diverse sets van foutmodi produceren of of ze convergeren naar dezelfde bugs. Bestaand onderzoek richt zich op codecorrectheid en compilatiepercentages, maar mist empirisch bewijs over de diversiteit van ontdekte foutmodi over model-promptconfiguraties heen in draaiende microservicesystemen.

Methodologie
De auteurs voerden een gecontroleerde empirische studie uit waarbij LLM-gebaseerde testgeneratie werd toegepast op twee architecturaal verschillende open-source microservicesystemen:

TeaStore: Een Java-gebaseerde monolinguale applicatie met 6 services die communiceren via vorm-gecodeerde HTTP.
OTel Astronomy Shop: Een polyglotte applicatie met 27 services (Go, C++, Rust, JS, .NET, enz.) die communiceren via JSON-API's en gRPC.

De studie gebruikte 3 open-source LLM's (14B, 32B code-specialiseerd en 70B parameters) en 7 promptstrategieën gegroepeerd in drie categorieën:

Basislijnen: ZeroShot (alleen API-specificatie) en Gestructureerd (vooraf opgebouwde schendingstabel die eindpunten koppelt aan mutaties).
Gevestigde Technieken: FewShot (voorbeelden van foutpatronen), Chain-of-Thought (CoT) en Self-Refine.
Strategieën op Basis van Domeinkennis: Guided (het inbedden van de mutatietaxonomie van Vieira et al. [1] als context) en GuidedFewShot (het toevoegen van CRASH-foutclassificatie en concrete voorbeelden die onderscheid maken tussen key-absent versus value-empty mutaties).

De experimentele pijplijn omvatte het genereren van Java/JUnit 5-testcode, het opschonen van outputs, het uitvoeren ervan tegen live Docker-implementaties en het classificeren van robuustheidsfouten op basis van HTTP-statuscodes $\ge$ 500 (de "Abort"-klasse). De studie definieerde Foutmodi (FM's) als unieke (eindpunt, parameter, mutatietype)-tripels geverifieerd tegen de broncode, waarbij 9 FM's voor TeaStore en 14 voor OTel werden geïdentificeerd. Diversiteit werd gemeten met behulp van de paarwijze Jaccard-similariteit van geactiveerde FM-sets.

Belangrijkste Bijdragen

Dominantie van Promptstrategie: Empirisch bewijs dat aantoont dat de promptstrategie meer variatie in testdiversiteit verklaart dan de modelgrootte. Het wijzigen van de prompt voor een vast model levert meer variatie in de set van foutmodi op dan het wijzigen van het model onder een vaste prompt.
Gestructureerde Ineenstorting: Identificatie van een fenomeen waarbij een voorschrijvende prompt (Gestructureerd) ertoe leidt dat alle modellen identieke sets van foutmodi produceren (Jaccard-similariteit = 1,00), wat diversiteit effectief elimineert.
Nieuwe Promptstrategieën: Introductie van Guided- en GuidedFewShot-strategieën die mutatietaxonomieën als domeincontext inbedden. GuidedFewShot adresseert specifiek de ambiguïteit van mutatieregels (bijvoorbeeld het onderscheid maken tussen het verwijderen van een sleutel versus het instellen van een waarde op leeg) door middel van concrete voorbeelden.
Prestatietransformatie: Bewijs dat domeinkennis een configuratie met nul dekking kan transformeren naar de best presterende configuratie. Het code-specialiseerde model (qwen2.5-coder:32b) activeerde onder Self-Refine nul fouten, maar behaalde de hoogste dekking in één run (56% op TeaStore, 57% op OTel) onder GuidedFewShot.
Enkel Model versus Meerdere Modellen: Aantonen dat het variëren van promptstrategieën voor een enkel model beter presteert dan het gebruik van meerdere modellen met één prompt. Bijvoorbeeld, qwen2.5-coder:32b behaalde 100% FM-dekking op OTel door prompts te variëren over drie strategieën, wat beter presteerde dan elk ensemble van meerdere modellen onder een vaste prompt.

Resultaten

Dekking: Geen enkele run behaalde volledige dekking op een van de systemen (maximale dekking in één run was 57%). De verenigde dekking varieerde echter aanzienlijk per strategie. FewShot behaalde 89% verenigde dekking op TeaStore, terwijl GuidedFewShot 64% behaalde op OTel.
Diversiteit: Gestructureerde prompting resulteerde in nul diversiteit (J=1,00). Self-Refine op OTel produceerde de hoogste diversiteit (J=0,00) maar met lage dekking. GuidedFewShot behield een lage similariteit (hoge diversiteit) terwijl het hoge dekking behaalde, met name op OTel (J=0,12).
De "Key-Absent"-Beperking: De studie vond dat LLM's die alleen taxonomieregels kregen (in Guided) consequent faalden om "key-absent"-mutaties te genereren (het weglaten van een parametersleutel), waarbij "vervangen door null" werd geïnterpreteerd als het instellen van een waarde op een lege string. GuidedFewShot loste dit op door expliciete voorbeelden van beide mutatietypes te verstrekken.
Op Staat Gebaseerde Fouten: ZeroShot was de enige strategie die op staat gebaseerde foutmodi ontdekte (bijvoorbeeld het verwijderen van een winkelwagenitem zonder authenticatie), wat door op parameters gerichte strategieën werd gemist.

Betekenis en Claims
Het artikel beweert dat voor robuustheidstesten in microservices promptengineering kritischer is dan modelselectie. De auteurs betogen dat practitioners niet moeten vertrouwen op één model-promptconfiguratie, aangezien dit een onvolledig beeld biedt van het foutoppervlak van het systeem. In plaats daarvan adviseren zij:

Het gebruik van GuidedFewShot als een sterke basislijn voor scenario's met één model en één prompt vanwege de hoge dekking in één run en behouden diversiteit.
Het toepassen van testen met meerdere configuraties (variëren van prompts voor één model) als een efficiëntere weg naar hoge dekking dan het draaien van meerdere modellen met één prompt.
Het opnemen van ten minste één ZeroShot-run om op staat gebaseerde fouten te vangen die door op mutaties gerichte strategieën worden over het hoofd gezien.
Het erkennen dat domeinkennis (mutatietaxonomieën) moet worden begeleid door concrete voorbeelden om protocolniveau-implementaties te ontdubbelen (bijvoorbeeld HTTP-parameterbehandeling) die LLM's op basis van trainingsdata-distributies kunnen verkeerd interpreteren.

De studie concludeert dat hoewel LLM's robuustheidstests kunnen genereren, hun effectiviteit sterk afhankelijk is van hoe domeinkennis in de prompt wordt geformuleerd, en dat een combinatie van strategieën noodzakelijk is om de ontdekking van fouten te maximaliseren.