Resumen Técnico: MASTOR

Planteamiento del Problema

Los enfoques actuales de pruebas automatizadas para APIs RESTful se centran predominantemente en la generación de casos de prueba (por ejemplo, fuzzing, búsqueda o generación de entradas impulsada por LLM), pero dependen de mecanismos de verificación simplistas. Estos mecanismos típicamente verifican códigos de estado HTTP, fallos en tiempo de ejecución y conformidad con el esquema. Aunque son ligeros, estos controles no logran detectar fallos semánticos, violaciones de la lógica de negocio e inconsistencias de comportamiento dependientes del estado incrustadas en las implementaciones de las API.

Muchos defectos de las API no se manifiestan como bloqueos o esquemas inválidos, sino como:

• Códigos de estado de respuesta incorrectos a través de diferentes rutas de ejecución.
• Campos de cuerpo de respuesta malformados o faltantes.
• Inconsistencias de datos entre operaciones de endpoints relacionados.

La construcción de oráculos semánticos es un desafío porque la corrección abarca tanto el comportamiento por endpoint (por ejemplo, restricciones a nivel de campo) como las relaciones entre endpoints (por ejemplo, la propagación de identificadores). Estas restricciones están distribuidas a través de múltiples componentes del código fuente (controladores, servicios, repositorios), lo que dificulta que una única consulta de LLM monolítica extraiga toda la evidencia relevante sin alucinaciones debido a la sobrecarga de contexto.

Metodología: MASTOR

MASTOR (Enfoque multi-agente para la generación de oráculos de prueba semánticos para APIs RESTful) es un marco de trabajo que genera oráculos de prueba semánticos directamente desde el código fuente de la implementación. Emplea una arquitectura multi-agente basada en un patrón de pizarra (blackboard pattern), descomponiendo la tarea en subtareas especializadas para asegurar un acotamiento de contexto preciso y un refinamiento iterativo.

Descripción General de la Arquitectura

MASTOR opera en dos fases principales, coordinadas por un orquestador (MastorAgent) y utilizando un OutputStore compartido (pizarra) para la comunicación:

1. Fase de Análisis de Fuente:

   • SourceExtractionAgent: Analiza un cierre de importación transitiva de los archivos de fuente relevantes para cada endpoint. Construye un Contexto de Fuente estructurado que contiene las restricciones de parámetros de entrada y los esquemas de respuesta. Distingue entre campos verificados por la fuente (derivados de código concreto) y campos pendientes (declarados en OAS pero no corroborados en el código), priorizando la precisión.
   • SemanticExtractAgent: Procesa los Contextos de Fuente para identificar asociaciones semánticas entre operaciones (por ejemplo, Ciclo de Vida de Recursos, Flujo de Identificadores, Propagación de Estado) y produce grupos de operaciones ordenados.

2. Fase de Generación de Oráculos:
   Esta fase ejecuta dos rutas paralelas, ambas sujetas a un bucle de "revisión y regeneración":

   • Ruta de Operación Única: El SingleOpOracleAgent genera oráculos para endpoints individuales utilizando cuatro estrategias complementarias: Forward-Valid, Forward-Invalid, Backward-Valid y Backward-Invalid. Estas cubren razonamientos de entrada válida/inválida y direcciones de razonamiento hacia adelante/atrás.
   • Ruta de Multi-Operación: El MultiOpOracleAgent genera oráculos de consistencia de comportamiento para secuencias de operaciones identificadas en la fase de Análisis de Fuente, modelando explícitamente el flujo de datos mediante capturas (extracción de campos de respuesta) y vinculaciones (conexión de estos con entradas subsecuentes).
   • Revisión del Desafiante (Challenger Review): Ambos caminos emplean un agente revisor dedicado (SingleOpChallengerAgent o MultiOpChallengerAgent). El revisor identifica debilidades (por ejemplo, valores límite faltantes, identificadores alucinados) y emite sugerencias de mejora. El agente especialista realiza entonces una pasada de regeneración dirigida solo para los oráculos señalados.
   • Normalización: Un filtro determinista elimina los oráculos estructuralmente inválidos (por ejemplo, aquellos que carecen de aserciones de estado o contienen parámetros alucinados) antes de fusionarlos en la Suite de Oráculos final.

Detalles de Implementación

• LLM vs. Basado en Reglas: El sistema divide el trabajo entre componentes basados en reglas (por ejemplo, construcción del cierre de importación, filtros de normalización) y LLMs (por ejemplo, extracción semántica, síntesis de oráculos, revisión).
• Fundamentación (Grounding): Cada aserción generada está fundamentada en un elemento específico del código fuente identificado durante la extracción, asegurando la trazabilidad.
• Convertidores: El sistema incluye herramientas (ToJUnit, ToPostmanAssertify, ToReadable) para traducir la suite de oráculos en código de prueba ejecutable y descripciones legibles por humanos.

Contribuciones Clave

1. Marco MASTOR: Un enfoque multi-agente para generar oráculos de prueba semánticos para APIs RESTful directamente desde el código fuente de la implementación, yendo más allá de las especificaciones a nivel de interfaz.
2. Arquitectura de Dos Fases: Un diseño que separa el Análisis de Fuente (extracción de Contextos de Fuente estructurados) de la Generación de Oráculos (rutas paralelas de operación única y multi-operación con revisión del desafiante).
3. Representación Intermedia Estructurada: La introducción del Contexto de Fuente, que separa los hechos verificados por la fuente de las afirmaciones pendientes de OAS para asegurar que las aserciones estén fundamentadas en código concreto.
4. Herramientas: Implementación de convertidores para JUnit, Postman y formatos legibles por humanos, facilitando la integración en CI/CD e inspección manual.
5. Evaluación Empírica: Una evaluación exhaustiva en 13 proyectos de API RESTful de código abierto (296 endpoints, 251k líneas de código) que demuestra efectividad, eficiencia y la contribución de los componentes arquitectónicos.
6. Lanzamiento Abierto: La liberación de la implementación completa, los conjuntos de datos de referencia y la suite de oráculos generada como un artefacto de código abierto.

Resultados Experimentales

Los autores evaluaron MASTOR en 13 APIs de estudio utilizando la Puntuación de Mutación (MS) como métrica principal.

• Efectividad (RQ1): MASTOR generó 10,022 oráculos y logró una puntuación de mutación promedio del 75.4% (con un rango de 69.0% a 95.9%). Las APIs con respuestas estáticas o puramente computadas obtuvieron las puntuaciones más altas, mientras que aquellas con autenticación compleja o anidamiento profundo obtuvieron puntuaciones más bajas.
• Comparación (RQ2): En 50 endpoints seleccionados (restringidos a oráculos de estado y de campo para una comparación justa):
  • MASTOR logró un 69.9% de MS.
  • Superó al Prompting Directo (39.8%) por 30.1 puntos porcentuales.
  • Superó a SATORI (un enfoque de LLM basado solo en especificaciones) por 49.4 puntos porcentuales (20.5%).
  • Los resultados resaltan la ventaja de la fundamentación en el código fuente sobre el análisis basado solo en la especificación, y el valor de la orquestación multi-agente estructurada sobre el prompting no estructurado.
• Estudio de Ablación (RQ3):
  • Eliminar la Generación de Oráculos Multi-Op redujo la MS en 3.7 pp, confirmando su valor en la detección de fallos entre operaciones a pesar de cubrir solo el 2.6% del total de oráculos.
  • Eliminar el ChallengerAgent redujo la MS en 7.2 pp, demostando que el paso de revisión mejora significamente la precisión de los oráculos al filtrar aserciones semánticamente débiles.
• Costo (RQ4): El costo de inferencia mediana fue de $0.56 por API. Aunque MASTOR es más costoso que el Prompting Directo (debido a las múltiples llamadas a LLM para extracción, generación y revisión), el costo escala de forma predecible con el número de endpoints. La Generación de Operación Única y la revisión del Desafiante representaron aproximadamente el 75% del costo total.

Significado y Reivindicaciones

El artículo afirma que MASTOR aborda una brecha crítica en las pruebas de API RESTful: la falta de herramientas automatizadas capaces de detectar fallos semánticos que son invisibles para los controles a nivel de interfaz. Al fundamentar la generación de oráculos en el código fuente de la implementación y utilizar una estrategia de descomposición multi-agente, MASTOR logra:

• Mayor Detección de Fallos: Superando significativamente tanto al prompting no estructurado como a los enfoques basados solo en especificaciones en las pruebas de mutación.
• Trazabilidad: Cada aserción está vinculada a evidencia específica del código fuente, reduciendo las alucinaciones y mejorando la interpretabilidad.
• Escalabilidad: El costo es práctico para la integración en flujos de CI/CD, con costos que escalan linealmente con el número de endpoints.

Los autores posicionan a MASTOR no como un reemplazo para las herramientas de generación de entradas, sino como una capa complementaria que proporciona la verificación semántica necesaria para validar la corrección de las respuestas de la API más allá de la mera conformidad con el esquema. El trabajo se presenta como un paso hacia un testing automatizado más robusto y consciente de la implementación para sistemas complejos de servicios.