MASTOR: A Multi-Agent Approach to Semantic Test Oracle Generation for RESTful APIs

Resumo Técnico: MASTOR

Declaração do Problema

As abordagens de teste automatizado existentes para APIs RESTful concentram-se predominantemente na geração de casos de teste (ex: fuzzing, busca ou geração de entradas baseada em LLM), mas dependem de mecanismos de verificação simplistas. Esses mecanismos tipicamente verificam códigos de status HTTP, falhas de tempo de execução e conformidade de esquema. Embora leves, essas verificações falham em detectar falhas semânticas, violações de lógica de negócio e inconsistências comportamentais dependentes de estado incorporadas nas implementações das APIs.

Muitos defeitos de API não se manifestam como crashes ou esquemas inválidos, mas sim como:

• Códigos de status de resposta incorretos em diferentes caminhos de execução.
• Campos de corpo de resposta malformados ou ausentes.
• Inconsistências de dados entre operações de endpoints relacionados.

A construção de oráculos semânticos é desafiadora porque a correção abrange tanto o comportamento por endpoint (ex: restrições de nível de campo) quanto as relações entre endpoints (ex: propagação de identificadores). Essas restrições estão distribuídas em múltiplos componentes de código-fonte (controladores, serviços, repositórios), tornando difícil para uma única consulta de LLM monolítica extrair todas as evidências relevantes sem alucinação devido à sobrecarga de contexto.

Metodologia: MASTOR

MASTOR (Multi-Agent approach for Semantic Test Oracle generation for RESTful APIs) é um framework que gera oráculos de teste semânticos diretamente do código-fonte da implementação. Ele emprega uma arquitetka multi-agente baseada em um padrão de quadro negro (blackboard pattern), decompondo a tarefa em subtarefas especializadas para garantir o isolamento preciso de contexto e o refinamento iterativo.

Visão Geral da Arquitetura

O MASTOR opera em duas fases principais, coordenadas por um orquestrador (MastorAgent) e utilizando um OutputStore compartilhado (quadro negro) para comunicação:

1. Fase de Análise de Fonte:

   • SourceExtractionAgent: Analisa um fechamento de importação transitiva de arquivos de origem relevantes para cada endpoint. Ele constrói um Contexto de Fonte estruturado contendo restrições de parâmetros de entrada e esquemas de resposta. Ele distingue entre campos verificados pela fonte (derivados de código concreto) e campos pendentes (declarados no OAS, mas não substanciados no código), priorizando a precisão.
   • SemanticExtractAgent: Processa os Contextos de Fonte para identificar associações semânticas entre operações (ex: Ciclo de Vida de Recurso, Fluxo de Identificador, Propagação de Estado) e produz grupos de operações ordenados.

2. Fase de Geração de Oráculo:
   Esta fase executa dois caminhos paralelos, ambos sujeitos a um loop de "revisão e regeneração":

   • Caminho de Operação Única: O SingleOpOracleAgent gera oráculos para endpoints individuais usando quatro estratégias complementares: Forward-Valid, Forward-Invalid, Backward-Valid e Backward-Invalid. Estas cobrem raciocínios de entrada válidos/inválidos e direções de raciocínio direto/inverso.
   • Caminho de Múltiplas Operações: O MultiOpOracleAgent gera oráculos de consistência comportamental para sequências de operações identificadas na fase de Análise de Fonte, modelando explicitamente o fluxo de dados via capturas (extração de campos de resposta) e vínculos (conexão desses campos a entradas subsequentes).
   • Revisão do Desafiador (Challenger Review): Ambos os caminhos empregam um agente revisor dedicado (SingleOpChallengerAgent ou MultiOpChallengerAgent). O revisor identifica fraquezas (ex: valores de limite ausentes, identificadores alucinados) e emite dicas de melhoria. O agente especialista então realiza uma passagem de regeneração direcionada apenas para os oráculos sinalizados.
   • Normalização: Um filtro determinístico remove oráculos estruturalmente inválidos (ex: aqueles que carecem de asserções de status ou contêm parâmetros alucinados) antes de fundi-los na Suíte de Oráculos final.

Detalhes de Implementação

• LLM vs. Baseado em Regras: O sistema divide o trabalho entre componentes baseados em regras (ex: construção de fechamento de importação, filtros de normalização) e LLMs (ex: extração semântica, síntese de oráculo, revisão).
• Fundamentação (Grounding): Cada asserção gerada é fundamentada em um elemento específico do código-fonte identificado durante a extração, garantindo rastreabilidade.
• Conversores: O sistema inclui ferramentas (ToJUnit, ToPostmanAssertify, ToReadable) para traduzir a suíte de oráculos em código de teste executável e descrições legíveis por humanos.

Principais Contribuições

1. Framework MASTOR: Uma abordagem multi-agente para gerar oráculos de teste semânticos para APIs RESTful diretamente do código-fonte da implementação, indo além das especificações de interface.
2. Arquitetura de Duas Fases: Um design que separa a Análise de Fonte (extração de Contextos de Fonte estruturados) da Geração de Oráculo (caminhos paralelos de operação única e múltipla com revisão de desafiador).
3. Representação Intermediária Estruturada: A introdução do Contexto de Fonte, que separa fatos verificados pelo código de reivindicações pendentes do OAS para garantir que as asserções sejam fundamentadas em código concreto.
4. Ferramental: Implementação de conversores para JUnit, Postman e formatos legíveis por humanos, facilitando a integração em CI/CD e inspeção manual.
5. Avaliação Empírica: Uma avaliação abrangente em 13 projetos de API RESTful de código aberto (296 endpoints, 251k linhas de código) demonstrando eficácia, eficiência e a contribuição dos componentes arquitetônicos.
6. Lançamento Aberto: A liberação da implementação completa, conjuntos de dados de benchmark e a suíte de oráculos gerada como um artefato de código aberto.

Resultados Experimentais

Os autores avaliaram o MASTOR em 13 APIs sujeitas usando a Pontuação de Mutação (MS - Mutation Score) como métrica primária.

• Eficácia (RQ1): O MASTOR gerou 10.022 oráculos e alcançou uma pontuação de mutação média de 75,4% (variando de 69,0% a 95,9%). APIs com respostas estáticas ou puramente computadas pontuaram mais alto, enquanto aquelas com autenticação complexa ou aninhamento profundo pontuaram mais baixo.
• Comparação (RQ2): Em 50 endpoints selecionados (restritos a oráculos de status e campo para comparação justa):
  • O MASTOR alcançou 69,9% de MS.
  • Superou o Prompt Direto (39,8%) em 30,1 pontos percentuais.
  • Superou o SATORI (uma abordagem de LLM baseada apenas em especificação) em 49,4 pontos percentuais (20,5%).
  • Os resultados destacam a vantagem da fundamentação em código-fonte sobre a análise baseada apenas em especificação e o valor da orquestração multi-agente estruturada sobre o prompting não estruturado.
• Estudo de Ablação (RQ3):
  • Remover a Geração de Oráculo de Múltiplas Operações reduziu o MS em 3,7 pp, confirmando seu valor na detecção de falhas entre operações, apesar de cobrir apenas 2,6% do total de oráculos.
  • Remover o ChallengerAgent reduziu o MS em 7,2 pp, demonstrando que a etapa de revisão melhora significativamente a precisão dos oráculos ao filtrar asserções semanticamente fracas.
• Custo (RQ4): O custo médio de inferência foi de $0,56 por API. Embora o MASTOR seja mais caro que o Prompt Direto (devido às múltiplas chamadas de LLM para extração, geração e revisão), o custo escala previsivelmente com a contagem de endpoints. A Geração de Operação Única e a revisão do Challenger representaram ~75% do custo total.

Significância e Alegações

O artigo afirma que o MASTOR aborda uma lacuna crítica no teste de APIs RESTful: a falta de ferramentas automatizadas capazes de detectar falhas semânticas que são invisíveis para verificações de nível de interface. Ao fundamentar a geração de oráculos no código-fonte da implementação e utilizar uma estratégia de decomposição multi-agente, o MASTOR alcança:

• Maior Detecção de Falhas: Superando significativamente tanto o prompting não estruturado quanto as abordagens baseadas apenas em especificação em testes de mutação.
• Rastreabilidade: Cada asserção está vinculada a uma evidência específica do código-fonte, reduzendo alucinações e melhorando a interpretabilidade.
• Escalabilidade: O custo é prático para integração em pipelines de CI/CD, com custos escalando linearmente com o número de endpoints.

Os autores posicionam o MASTOR não como um substituto para ferramentas de geração de entrada, mas como uma camada complementar que fornece a verificação semântica necessária para validar a correção das respostas da API além da mera conformidade de esquema. O trabalho é apresentado como um passo em direção a testes automatizados mais robustos e conscientes da implementação para sistemas complexos orientados a serviços.