💻 computer science

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

Este estudo empírico demonstra que a estratégia de prompt influencia significativamente a diversidade e a cobertura dos testes de robustez gerados por LLMs para APIs de microsserviços, revelando que uma abordagem de few-shot guiada por taxonomia supera tanto ensembles de modelos maiores quanto prompts fixos na exposição de modos de falha distintos.

Autores originais: Hrushitha Goud Tigulla, Marco Vieira

Publicado 2026-05-15

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Hrushitha Goud Tigulla, Marco Vieira

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é dono de um restaurante movimentado com uma cozinha (o aplicativo principal) e várias estações especializadas: uma barra de saladas, um grill, uma estação de bebidas e um caixa. Cada estação é um "microserviço". Elas se comunicam entre si para realizar seu pedido.

Agora, imagine que você quer garantir que seu restaurante não trave se um cliente fizer algo estranho. Talvez ele tente pedir uma salada com um número negativo de itens, ou tente pagar sem um cartão de crédito, ou envie uma mensagem longa demais para ser lida. Isso é chamado de Teste de Robustez: tentar intencionalmente quebrar o sistema com entradas "ruins" para ver onde ele falha.

O problema é que os humanos estão cansados. Não conseguimos pensar em todas as coisas estranhas que um cliente pode fazer. Então, os pesquisadores deste artigo perguntaram: Podemos usar IA (especificamente Modelos de Linguagem Grandes ou LLMs) para criar esses testes estranhos para nós?

Aqui está o que eles descobriram, explicado de forma simples:

1. A Configuração: Os Cozinheiros de IA

Os pesquisadores contrataram três "Cozinheiros de IA" diferentes (modelos de IA de tamanhos e especialidades distintas) para escrever esses testes. Eles deram a eles o cardápio do restaurante (as especificações da API) e pediram que gerassem testes.

Eles tentaram 7 maneiras diferentes de pedir (chamadas de "Estratégias de Prompt"):

A Tábua em Branco: Apenas dizer "Escreva alguns testes".
O Gerente Rigoroso: Dar-lhes uma lista de verificação do que exatamente testar.
O Professor: Mostrar-lhes exemplos de testes ruins primeiro.
O Pensador: Pedir-lhes para pensar passo a passo antes de escrever.
O Guia Especialista: Dar-lhes um livro de regras de como as coisas podem quebrar, além de exemplos de situações específicas e complicadas.

2. A Grande Descoberta: Como Você Pergunta Importa Mais do que Quem Você Pergunta

A descoberta mais surpreendente foi que a maneira como você faz a pergunta importa mais do que qual IA você usa.

A Armadilha do "Gerente Rigoroso": Quando deram à IA uma lista de verificação rígida (o prompt "Estruturado"), as três IAs escreveram os mesmos testes exatos. Foi como dar a três cozinheiros diferentes o mesmo cartão de receita; todos fizeram o prato exato. Isso é ruim porque, se a receita tiver um ponto cego, você o perderá.
O Sucesso do "Guia Especialista": Quando deram à IA um livro de regras mais exemplos claros de situações complicadas (como a diferença entre "faltar uma chave" e "ter uma chave vazia"), as IAs começaram a pensar de forma diferente. Elas encontraram bugs únicos que as outras perderam.

A Analogia: Imagine que você está procurando chaves perdidas em uma casa.

Se você disser a três pessoas diferentes: "Procure na cozinha", todas procurarão na cozinha. Se as chaves não estiverem lá, você não encontrará nada.
Se você disser a elas: "Procure na cozinha, mas também verifique a geladeira, a torradeira e a cama do gato", elas se espalharão e encontrarão mais lugares.
O artigo descobriu que mudar como você diz à IA para procurar (o prompt) foi mais eficaz do que contratar uma IA "melhor".

3. O Paradoxo do "Especialista em Código"

Uma das IAs era um "Especialista em Código" (treinado especificamente para escrever código). Você poderia pensar que este seria o melhor em encontrar bugs.

O Problema: Quando solicitado apenas a "criticar e melhorar" seu próprio trabalho (uma estratégia chamada Auto-Refinamento), este especialista escreveu código perfeito que na verdade não verificava erros. Foi como um cozinheiro que fez um bolo lindo, mas esqueceu de prová-lo para ver se estava queimado.
A Solução: Quando os pesquisadores deram a este especialista o "Guia Especialista" (o livro de regras com exemplos), ele de repente se tornou o melhor desempenho, encontrando mais bugs do que qualquer outra combinação. O livro de regras deu a ele a "intenção adversária" — a mentalidade de tentar quebrar coisas —, algo que seu treinamento em código não lhe proporcionou por conta própria.

4. A Surpresa do "Zero-Shot"

Houve uma estratégia em que deram à IA nenhuma instrução, apenas o cardápio.

O Resultado: Esta IA encontrou um tipo específico de bug que as outras perderam: bugs baseados em estado.
A Analogia: As outras IAs estavam focadas em "O ingrediente está fresco?" (verificando os dados). A IA "Zero-Shot" estava pensando: "Espere, o cliente tentou pedir sobremesa antes de pedir o prato principal?" (verificando o fluxo).
Lição: Mesmo uma IA "boba" ou não orientada pode encontrar erros lógicos estranhos que uma IA altamente orientada perde, porque a IA orientada está muito focada nas regras.

5. A Confusão entre "Chave-Ausente" vs. "Valor-Vazio"

O artigo destaca uma confusão específica que as IAs tiveram.

A Regra: "Se um valor estiver ausente, defina-o como nulo."
O Erro da IA: As IAs interpretaram isso como "Defina o valor como uma string vazia" (como nome="").
A Realidade: Em sistemas de computador, nome="" (vazio) e nome (ausente completamente) são duas coisas totalmente diferentes que quebram o sistema de maneiras diferentes.
A Solução: As IAs não conseguiam distinguir a diferença até que os pesquisadores mostrassem exemplos concretos de ambos. Assim que viram a diferença, puderam testar ambos os cenários.

Resumo das Conclusões

Não contrate apenas uma IA maior: Uma IA menor com um prompt melhor pode vencer uma IA gigante com um prompt ruim.
Não seja muito rígido: Se você der à IA uma lista de verificação rígida, todos farão exatamente a mesma coisa. Você precisa dar a eles regras, mas deixá-los ser criativos.
Mostre, não apenas conte: Se você quer que a IA entenda uma diferença sutil (como "ausente" vs. "vazio"), você tem que mostrar um exemplo.
Misture suas estratégias: Para encontrar a maioria dos bugs, você não deve executar apenas um teste. Você deve executar uma mistura: alguns testes rígidos, alguns testes orientados e até alguns testes "coringa" sem instruções.

Em resumo, o artigo prova que como você fala com a IA é o segredo para encontrar bugs de software, não apenas o tamanho da IA em si.

Resumo Técnico: Teste de Robustez Baseado em LLM para Aplicações de Microsserviços

Declaração do Problema
As arquiteturas de microsserviços são suscetíveis a ameaças de confiabilidade quando entradas malformadas, ausentes ou de valores limite se propagam em cascata através de serviços dependentes. Embora o teste de robustez exercite sistematicamente tais entradas para expor falhas no lado do servidor, a geração de casos de teste diversos e eficazes permanece um desafio significativo. Embora os Modelos de Linguagem de Grande Escala (LLMs) possam gerar testes a partir de especificações de API, não está claro se diferentes arquiteturas de modelos e estratégias de prompt produzem conjuntos diversos de modos de falha ou se convergem para os mesmos bugs. A pesquisa existente foca na correção do código e nas taxas de compilação, mas carece de evidências empíricas sobre a diversidade de modos de falha descobertos em diferentes configurações de modelo-prompt em sistemas de microsserviços em execução.

Metodologia
Os autores conduziram um estudo empírico controlado aplicando a geração de testes baseada em LLM a dois sistemas de microsserviços de código aberto arquiteturalmente distintos:

TeaStore: Um aplicativo monolíngue baseado em Java com 6 serviços comunicando-se via HTTP codificado em formulário.
OTel Astronomy Shop: Um aplicativo poliglota com 27 serviços (Go, C++, Rust, JS, .NET, etc.) comunicando-se via APIs JSON e gRPC.

O estudo utilizou 3 LLMs de código aberto (14B, 32B especializados em código e 70B parâmetros) e 7 estratégias de prompt agrupadas em três categorias:

Linhas de Base: ZeroShot (apenas especificação de API) e Structured (tabela de violação pré-construída mapeando endpoints para mutações).
Técnicas Estabelecidas: FewShot (exemplos de padrões de falha), Chain-of-Thought (CoT) e Self-Refine.
Estratégias de Conhecimento de Domínio: Guided (incorporando a taxonomia de mutação de Vieira et al. [1] como contexto) e GuidedFewShot (adicionando classificação de falha CRASH e exemplos concretos que distinguem mutações de chave ausente vs. valor vazio).

O pipeline experimental envolveu a geração de código de teste Java/JUnit 5, limpeza das saídas, execução contra implantações Docker ao vivo e classificação de falhas de robustez com base em códigos de status HTTP $\ge$ 500 (classe "Abort"). O estudo definiu Modos de Falha (FMs) como triplas únicas (endpoint, parâmetro, tipo-de-mutação) verificadas contra o código-fonte, identificando 9 FMs para o TeaStore e 14 para o OTel. A diversidade foi medida usando a similaridade Jaccard par a par dos conjuntos de FMs acionados.

Principais Contribuições

Dominância da Estratégia de Prompt: Evidência empírica demonstrando que a estratégia de prompt explica mais variação na diversidade de testes do que o tamanho do modelo. Alterar o prompt para um modelo fixo produz maior variação no conjunto de modos de falha do que alterar o modelo sob um prompt fixo.
Colapso Estruturado: Identificação de um fenômeno onde um prompt prescritivo (Structured) faz com que todos os modelos produzam conjuntos idênticos de modos de falha (similaridade Jaccard = 1,00), eliminando efetivamente a diversidade.
Novas Estratégias de Prompt: Introdução das estratégias Guided e GuidedFewShot que incorporam taxonomias de mutação como contexto de domínio. GuidedFewShot aborda especificamente a ambiguidade das regras de mutação (por exemplo, distinguir entre remover uma chave vs. definir um valor como vazio) através de exemplos concretos.
Transformação de Desempenho: Evidência de que o conhecimento de domínio pode transformar uma configuração de cobertura zero na de melhor desempenho. O modelo especializado em código (qwen2.5-coder:32b) acionou zero falhas sob Self-Refine, mas alcançou a maior cobertura de execução única (56% no TeaStore, 57% no OTel) sob GuidedFewShot.
Modelo Único vs. Múltiplos Modelos: Demonstração de que variar estratégias de prompt para um único modelo supera o uso de múltiplos modelos com um único prompt. Por exemplo, qwen2.5-coder:32b alcançou 100% de cobertura de FMs no OTel variando prompts em três estratégias, superando qualquer ensemble de múltiplos modelos sob um prompt fixo.

Resultados

Cobertura: Nenhuma execução única alcançou cobertura completa em nenhum dos sistemas (a cobertura máxima de execução única foi de 57%). No entanto, a cobertura de união variou significativamente por estratégia. FewShot alcançou 89% de cobertura de união no TeaStore, enquanto GuidedFewShot alcançou 64% no OTel.
Diversidade: O prompt Structured resultou em zero diversidade (J=1,00). Self-Refine no OTel produziu a maior diversidade (J=0,00), mas com baixa cobertura. GuidedFewShot manteve baixa similaridade (alta diversidade) enquanto alcançava alta cobertura, particularmente no OTel (J=0,12).
A Limitação "Chave-Ausente": O estudo encontrou que LLMs recebendo apenas regras de taxonomia (em Guided) consistentemente falharam em gerar mutações de "chave ausente" (omissão de uma chave de parâmetro), interpretando "substituir por null" como definir um valor para uma string vazia. GuidedFewShot resolveu isso fornecendo exemplos explícitos de ambos os tipos de mutação.
Falhas Baseadas em Estado: ZeroShot foi a única estratégia a descobrir modos de falha baseados em estado (por exemplo, remover um item do carrinho sem autenticação), que estratégias focadas em parâmetros perderam.

Significado e Alegações
O artigo afirma que, para teste de robustez em microsserviços, a engenharia de prompt é mais crítica do que a seleção do modelo. Os autores argumentam que os praticantes não devem confiar em uma única configuração de modelo-prompt, pois isso fornece uma visão incompleta da superfície de falha do sistema. Em vez disso, eles recomendam:

Usar GuidedFewShot como uma forte linha de base para cenários de modelo único e prompt único devido à sua alta cobertura de execução única e diversidade mantida.
Empregar teste de múltiplas configurações (variando prompts para um único modelo) como um caminho mais eficiente para alta cobertura do que executar múltiplos modelos com um único prompt.
Incluir pelo menos uma execução ZeroShot para capturar falhas baseadas em estado que estratégias focadas em mutação ignoram.
Reconhecer que o conhecimento de domínio (taxonomias de mutação) deve ser acompanhado por exemplos concretos para desambiguar implementações em nível de protocolo (por exemplo, manipulação de parâmetros HTTP) que os LLMs podem interpretar erroneamente com base nas distribuições de dados de treinamento.

O estudo conclui que, embora os LLMs possam gerar testes de robustez, sua eficácia depende fortemente de como o conhecimento de domínio é enquadrado no prompt, e que uma combinação de estratégias é necessária para maximizar a descoberta de falhas.