💻 computer science

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

Este estudio empírico demuestra que la estrategia de prompt influye significativamente en la diversidad y cobertura de las pruebas de robustez generadas por LLM para APIs de microservicios, revelando que un enfoque de pocos ejemplos guiado por una taxonomía supera tanto a los conjuntos de modelos más grandes como a los prompts fijos en la exposición de modos de fallo distintos.

Autores originales: Hrushitha Goud Tigulla, Marco Vieira

Publicado 2026-05-15

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Hrushitha Goud Tigulla, Marco Vieira

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres dueño de un restaurante concurrido con una cocina (la aplicación principal) y varias estaciones especializadas: una barra de ensaladas, una parrilla, una estación de bebidas y una caja registradora. Cada estación es un "microservicio". Se comunican entre sí para completar tu pedido.

Ahora, imagina que quieres asegurarte de que tu restaurante no colapse si un cliente hace algo extraño. Quizás intenten pedir una ensalada con una cantidad negativa de artículos, o intenten pagar sin tarjeta de crédito, o envíen un mensaje demasiado largo para leer. Esto se llama Pruebas de Robustez: intentar intencionalmente romper el sistema con entradas "malas" para ver dónde falla.

El problema es que los humanos estamos cansados. No podemos pensar en cada cosa extraña que un cliente podría hacer. Así que los investigadores de este artículo preguntaron: ¿Podemos usar IA (específicamente Modelos de Lenguaje Grandes o LLM) para generar estas pruebas extrañas por nosotros?

Esto es lo que encontraron, explicado de forma sencilla:

1. La Configuración: Los Chefs de IA

Los investigadores contrataron a tres "Chefs de IA" diferentes (modelos de IA de distintos tamaños y especialidades) para escribir estas pruebas. Les dieron el menú del restaurante (las especificaciones de la API) y les pidieron que generaran pruebas.

Probaron 7 formas diferentes de preguntar (llamadas "Estrategias de Prompt"):

El Lienzo en Blanco: Solo decir "Escribe algunas pruebas".
El Gerente Estricto: Darles una lista de verificación exacta de qué probar.
El Profesor: Mostrarles ejemplos de malas pruebas primero.
El Pensador: Pedirles que piensen paso a paso antes de escribir.
La Guía Experta: Darles un manual de reglas sobre cómo las cosas pueden romperse, más ejemplos de situaciones específicas y truculentas.

2. El Gran Descubrimiento: Cómo Pides Importa Más que a Quién Pides

El hallazgo más sorprendente fue que la forma en que haces la pregunta importa más que qué IA uses.

La Trampa del "Gerente Estricto": Cuando dieron a la IA una lista de verificación estricta (el prompt "Estructurado"), las tres IAs escribieron exactamente las mismas pruebas. Era como dar a tres chefs diferentes la misma tarjeta de receta exacta; todos hicieron el mismo plato exacto. Esto es malo porque si la receta tiene un punto ciego, lo pierdes.
El Éxito de la "Guía Experta": Cuando dieron a la IA un manual más ejemplos claros de situaciones truculentas (como la diferencia entre "falta una clave" y "tener una clave vacía"), las IAs comenzaron a pensar de manera diferente. Encontraron errores únicos que los demás pasaron por alto.

La Analogía: Imagina que estás buscando llaves perdidas en una casa.

Si le dices a tres personas diferentes: "Busquen en la cocina", todas buscarán en la cocina. Si las llaves no están allí, no encontrarán nada.
Si les dices: "Busquen en la cocina, pero también revisen el refrigerador, la tostadora y la cama del gato", se dispersarán y encontrarán más lugares.
El artículo encontró que cambiar cómo le dices a la IA que busque (el prompt) fue más efectivo que contratar una IA "mejor".

3. La Paradoja del "Especialista en Código"

Una de las IAs era un "Especialista en Código" (entrenado específicamente para escribir código). Podrías pensar que este sería el mejor para encontrar errores.

El Problema: Cuando se le pidió simplemente "criticar y mejorar" su propio trabajo (una estrategia llamada Auto-Refinamiento), este especialista escribió código perfecto que en realidad no verificaba errores. Era como un chef que hizo una hermosa tarta pero olvidó probarla para ver si estaba quemada.
La Solución: Cuando los investigadores le dieron a este especialista la "Guía Experta" (el manual con ejemplos), de repente se convirtió en el mejor rendimiento, encontrando más errores que cualquier otra combinación. El manual le dio la "intención adversaria": la mentalidad de intentar romper cosas, lo cual su entrenamiento en código no le dio por sí solo.

4. La Sorpresa del "Zero-Shot"

Hubo una estrategia donde dieron a la IA ninguna instrucción en absoluto, solo el menú.

El Resultado: Esta IA encontró un tipo específico de error que los demás pasaron por alto: Errores basados en estado.
La Analogía: Las otras IAs se centraban en "¿Está el ingrediente fresco?" (verificando los datos). La IA "Zero-Shot" estaba pensando: "Espera, ¿intentó el cliente pedir postre antes de pedir el plato principal?" (verificando el flujo).
Lección: Incluso una IA "tonta" o no guiada puede encontrar errores lógicos extraños que una IA altamente guiada pasa por alto porque la IA guiada está demasiado enfocada en las reglas.

5. La Confusión entre "Clave-Ausente" vs. "Valor-Vacío"

El artículo destaca una confusión específica que tuvieron las IAs.

La Regla: "Si falta un valor, establécelo en nulo".
El Error de la IA: Las IAs interpretaron esto como "Establece el valor en una cadena vacía" (como nombre="").
La Realidad: En los sistemas informáticos, nombre="" (vacío) y nombre (ausente por completo) son dos cosas totalmente diferentes que rompen el sistema de maneras distintas.
La Solución: Las IAs no podían distinguir la diferencia hasta que los investigadores les mostraron ejemplos concretos de ambos. Una vez que vieron la diferencia, pudieron probar ambos escenarios.

Resumen de las Conclusiones

No contrates solo una IA más grande: Una IA más pequeña con un mejor prompt puede vencer a una IA gigante con un mal prompt.
No seas demasiado estricto: Si le das a la IA una lista de verificación rígida, todos harán exactamente lo mismo. Necesitas darles reglas pero permitirles ser creativos.
Muestra, no solo digas: Si quieres que la IA entienda una diferencia sutil (como "ausente" vs. "vacío"), tienes que mostrarles un ejemplo.
Mezcla tus estrategias: Para encontrar la mayoría de los errores, no deberías ejecutar solo una prueba. Deberías ejecutar una mezcla: algunas pruebas estrictas, algunas guiadas e incluso algunas pruebas "comodín" sin instrucciones.

En resumen, el artículo demuestra que cómo hablas con la IA es el secreto para encontrar errores de software, no solo el tamaño de la IA en sí.

Resumen Técnico: Pruebas de Robustez Basadas en LLM para Aplicaciones de Microservicios

Enunciado del Problema
Las arquitecturas de microservicios son susceptibles a amenazas de fiabilidad cuando entradas malformadas, ausentes o de valores límite se propagan en cascada a través de servicios dependientes. Aunque las pruebas de robustez ejercitan sistemáticamente dichas entradas para exponer fallos del lado del servidor, generar casos de prueba diversos y efectivos sigue siendo un desafío significativo. Aunque los Modelos de Lenguaje Grandes (LLM) pueden generar pruebas a partir de especificaciones de API, no está claro si diferentes arquitecturas de modelos y estrategias de prompt producen conjuntos diversos de modos de fallo o si convergen hacia los mismos errores. La investigación existente se centra en la corrección del código y las tasas de compilación, pero carece de evidencia empírica sobre la diversidad de modos de fallo descubiertos en diferentes configuraciones de modelo-prompt en sistemas de microservicios en ejecución.

Metodología
Los autores realizaron un estudio empírico controlado aplicando la generación de pruebas basada en LLM a dos sistemas de microservicios de código abierto arquitectónicamente distintos:

TeaStore: Una aplicación monolingüe basada en Java con 6 servicios que se comunican mediante HTTP codificado en formularios.
OTel Astronomy Shop: Una aplicación políglota con 27 servicios (Go, C++, Rust, JS, .NET, etc.) que se comunican mediante APIs JSON y gRPC.

El estudio utilizó 3 LLM de código abierto (14B, 32B especializados en código y 70B parámetros) y 7 estrategias de prompt agrupadas en tres categorías:

Líneas base: ZeroShot (solo especificación de API) y Structured (tabla de violaciones predefinida que mapea puntos finales a mutaciones).
Técnicas establecidas: FewShot (ejemplos de patrones de fallo), Chain-of-Thought (CoT) y Self-Refine.
Estrategias de conocimiento del dominio: Guided (incrustando la taxonomía de mutaciones de Vieira et al. [1] como contexto) y GuidedFewShot (añadiendo la clasificación de fallos CRASH y ejemplos concretos que distinguen entre mutaciones de clave ausente frente a valor vacío).

El flujo de trabajo experimental implicó generar código de prueba Java/JUnit 5, limpiar las salidas, ejecutarlas frente a implementaciones Docker en vivo y clasificar los fallos de robustez basándose en códigos de estado HTTP $\ge$ 500 (la clase "Abort"). El estudio definió Modos de Fallo (FMs) como tripletes únicos (punto final, parámetro, tipo de mutación) verificados contra el código fuente, identificando 9 FMs para TeaStore y 14 para OTel. La diversidad se midió utilizando la similitud de Jaccard por pares de los conjuntos de FMs activados.

Contribuciones Clave

Dominio de la Estrategia de Prompt: Evidencia empírica que demuestra que la estrategia de prompt explica más variación en la diversidad de pruebas que el tamaño del modelo. Cambiar el prompt para un modelo fijo produce una mayor variación en el conjunto de modos de fallo que cambiar el modelo bajo un prompt fijo.
Colapso Estructurado: Identificación de un fenómeno donde un prompt prescriptivo (Structured) hace que todos los modelos produzcan conjuntos idénticos de modos de fallo (similitud de Jaccard = 1.00), eliminando efectivamente la diversidad.
Nuevas Estrategias de Prompt: Introducción de las estrategias Guided y GuidedFewShot que incrustan taxonomías de mutaciones como contexto de dominio. GuidedFewShot aborda específicamente la ambigüedad de las reglas de mutación (por ejemplo, distinguir entre eliminar una clave frente a establecer un valor como vacío) mediante ejemplos concretos.
Transformación del Rendimiento: Evidencia de que el conocimiento del dominio puede transformar una configuración de cobertura cero en la de mejor rendimiento. El modelo especializado en código (qwen2.5-coder:32b) activó cero fallos bajo Self-Refine, pero logró la mayor cobertura de ejecución única (56% en TeaStore, 57% en OTel) bajo GuidedFewShot.
Modelo Único vs. Múltiples Modelos: Demostración de que variar las estrategias de prompt para un solo modelo supera el uso de múltiples modelos con un único prompt. Por ejemplo, qwen2.5-coder:32b logró una cobertura del 100% de FMs en OTel variando los prompts a través de tres estrategias, superando a cualquier ensamble de múltiples modelos bajo un prompt fijo.

Resultados

Cobertura: Ninguna ejecución única logró cobertura completa en ninguno de los sistemas (la cobertura máxima de ejecución única fue del 57%). Sin embargo, la cobertura de unión varió significativamente según la estrategia. FewShot logró una cobertura de unión del 89% en TeaStore, mientras que GuidedFewShot logró un 64% en OTel.
Diversidad: El prompt Structured resultó en cero diversidad (J=1.00). Self-Refine en OTel produjo la mayor diversidad (J=0.00) pero con baja cobertura. GuidedFewShot mantuvo una baja similitud (alta diversidad) mientras lograba una alta cobertura, particularmente en OTel (J=0.12).
La Limitación de "Clave-Ausente": El estudio encontró que los LLM con solo reglas de taxonomía (en Guided) fallaron consistentemente en generar mutaciones de "clave ausente" (omitiendo una clave de parámetro), interpretando "reemplazar por nulo" como establecer un valor a una cadena vacía. GuidedFewShot resolvió esto proporcionando ejemplos explícitos de ambos tipos de mutación.
Fallos Basados en Estado: ZeroShot fue la única estrategia que descubrió modos de fallo basados en estado (por ejemplo, eliminar un artículo del carrito sin autenticación), los cuales las estrategias centradas en parámetros pasaron por alto.

Significado y Afirmaciones
El artículo afirma que, para las pruebas de robustez en microservicios, la ingeniería de prompts es más crítica que la selección del modelo. Los autores argumentan que los practicantes no deben depender de una única configuración de modelo-prompt, ya que esto proporciona una visión incompleta de la superficie de fallos del sistema. En su lugar, recomiendan:

Utilizar GuidedFewShot como una línea base sólida para escenarios de modelo único y prompt único debido a su alta cobertura de ejecución única y diversidad mantenida.
Emplear pruebas de múltiples configuraciones (variando prompts para un solo modelo) como un camino más eficiente hacia una alta cobertura que ejecutar múltiples modelos con un único prompt.
Incluir al menos una ejecución ZeroShot para capturar fallos basados en estado que las estrategias centradas en mutaciones pasan por alto.
Reconocer que el conocimiento del dominio (taxonomías de mutaciones) debe ir acompañado de ejemplos concretos para desambiguar implementaciones a nivel de protocolo (por ejemplo, manejo de parámetros HTTP) que los LLM pueden malinterpretar basándose en distribuciones de datos de entrenamiento.

El estudio concluye que, aunque los LLM pueden generar pruebas de robustez, su efectividad depende en gran medida de cómo se enmarca el conocimiento del dominio en el prompt, y que es necesaria una combinación de estrategias para maximizar el descubrimiento de fallos.