Resumo Técnico: E-Test: Suítes de Testes em Constante Evolução

Declaração do Problema

As suítes de testes são inerentemente imperfeitas e requerem enriquecimento contínuo para manter a confiabilidade do software. Embora os testadores possam, teoricamente, adicionar novos casos de teste para cobrir cenários de execução inexplorados, identificar esses cenários — particularmente aqueles que emergem do uso em produção — é trabalhoso e desafiador, especialmente para sistemas de software grandes e de longa duração. As abordagens existentes, como o teste de regressão (que se concentra na seleção ou priorização de testes existentes) e o teste de campo (que executa o software em produção), não abordam totalmente a lacuna entre o espaço de execução coberto por uma suíte de testes e as execuções reais experimentadas em produção. Simplesmente adicionar todos os cenários de produção observados a uma suíte de testes é impraticável, pois leva a uma explosão incontrolável no tamanho da suíte. O desafio central é filtrar eficientemente vastos conjuntos de cenários de produção para identificar aqueles que são verdadeiramente "necessários para teste" (não cobertos, mas corretos) ou "propensos a erros" (não cobertos e falhos) sem o custo proibitivo de executar todos os casos de teste existentes contra cada novo cenário.

Metodologia: E-Test

Os autores propõem o E-Test, uma abordagem projetada para criar suítes de testes "em constante evolução" (e'er-improving) que crescem automaticamente através da integração de novos casos de teste derivados de dados de produção. O E-Test opera classificando os cenários de execução em três categorias em relação a uma suíte de testes existente:

1. Já testado: O input é equivalente a um caso de teste existente (mesmo particionamento).
2. Necessário para teste (Need-test): O input não é equivalente a nenhum teste existente, a execução é bem-sucedida e ele cobre um novo comportamento de código.
3. Propenso a erro (Error-prone): O input não é equivalente a nenhum teste existente e a execução falha (revela um bug).

O E-Test evita a impraticabilidade de executar todos os testes ao utilizar Modelos de Linguagem de Grande Escala (LLMs) para realizar essa classificação. O sistema consiste em três fases principais:

1. PreProcessor (Pré-processador)

Esta fase constrói um prompt estruturado para o LLM. Ela extrai três componentes fundamentais de um cenário de execução:

• MUT (Método Sob Teste): O código-fonte do método e seus métodos fortemente relacionados (limitado a ~3K tokens).
• MUT Tests: A suíte de testes existente para o método (limitado a ~4K tokens).
• MUT Input: Os parâmetros de entrada específicos e o código de contexto circundante (limitado a ~1K tokens).

O PreProcessor então instancia um template de prompt contendo cinco consultas específicas projetadas para avaliar as características do cenário:

• Q1: O input é semelhante aos testes existentes?
• Q2: O input cobre mais linhas ou ramos (branches) do que os testes existentes?
• Q3: O método se comportará de forma diferente sob este input?
• Q4: O método produzirá resultados corretos?
• Q5: O input revelará um bug?

2. Analyzer (Analisador)

O Analyzer consulta um LLM com o prompt construído. Para aumentar o desempenho, o E-Test emprega três técnicas específicas:

• Ajuste Fino (Fine-tuning): O LLM (especificamente o GPT-3.5 Turbo nos experimentos) é ajustado em um conjunto de dados de cenários rotulados (já testado, necessário para teste, propenso a erro) para melhorar a precisão da classificação.
• Geração Aumentada de Recuperação (RAG): Para superar as limitações da janela de contexto com bases de código grandes, o RAG é usado para recuperar e incorporar trechos de código relevantes relacionados ao prompt, alimentando esse contexto ao LLM.
• Aprendizado de Poucos Disparos (Few-shot Learning): Exemplos fixos de cada tipo de cenário são incluídos no prompt para guiar o modelo.

3. PostProcessor (Pós-processador)

O PostProcessor agrega as respostas do LLM para as cinco consultas. Um mecanismo de "Votante" classifica o cenário com base no padrão de respostas Sim/Não que melhor corresponde à tabela de verdade esperada para cada categoria (por exemplo, um cenário propenso a erro deve responder Não para similaridade, Sim para diferença de cobertura, Sim para comportamento diferente, Não para correção e Sim para revelação de bug). Empates são resolvidos priorizando propenso a erro > necessário para teste > já testado para garantir a robustez. Para cenários classificados como necessário para teste ou propenso a erro, um Gerador de Casos de Teste produz automaticamente casos de teste JUnit continuando a conversa com o LLM.

Principais Contribuições

O artigo apresenta as seguintes contribuições para o estado da arte em testes de software:

• Estrutura Conceitual: Introduz o conceito de "suítes de testes em constante evolução", mudando a perspectiva de manutenção estática para enriquecimento contínuo e automatizado baseado em dados de produção.
• Abordagem E-Test: Define uma abordagem inovadora que combina LLMs, engenharia de prompt, ajuste fino e RAG para classificar cenários de execução sem executar a suíte de testes completa.
• Criação de Dataset: Fornece um conjunto de dados de 1.975 cenários de execução colhidos do Defects4J e de quatro projetos open-source Java altamente conceituados (Spring Boot, Apache ShardingSphere, Apache Dolphinscheduler, Micrometer), categorizados nas três classes alvo.
• Geração de Casos de Teste: Apresenta um mecanismo para gerar automaticamente casos de teste JUnit a partir dos cenários identificados e avalia sua capacidade de revelar falhas.

Resultados Experimentais

A avaliação foi conduzida no dataset de 1.975 cenários, comparando o E-Test com abordagens de estado da arte de teste de regressão (FAST++) e teste de campo (field-ready testing), bem como com LLMs comuns (vanilla).

• Desempenho de Classificação: O E-Test alcançou um F1-score médio de 0,55. Isso supera significativamente:
  • Teste de regressão de estado da arte (FAST++): F1-score de 0,34 (melhoria relativa de 61,8%).
  • Teste pronto para campo (field-ready testing): F1-score de 0,30 (melhoria relativa de 83,3%).
  • LLMs comuns (sem ajuste fino ou RAG): F1-score máximo de 0,39.
  • Classificador aleatório: F1-score de 0,33.
• Impacto do Ajuste Fino: O ajuste fino do GPT-3.5 Turbo foi crítico, melhorando o F1-score médio total em 80% em comparação com o classificador aleatório de base.
• Impacto do RAG: O RAG proporcionou melhorias marginais para casos gerais, mas mostrou um benefício significativo (ganho de 12% no F1-score) especificamente para cenários com suítes de testes muito grandes (>16K tokens), onde os limites de contexto são excedidos.
• Geração de Testes: Para os bugs do Defects4J, o E-Test gerou com sucesso casos de teste que revelaram falhas para 83,2% das falhas documentadas. Dos testes gerados, 99,1% eram sintaticamente corretos, 8-7% compilavam e 83,2% dispararam a falha com cobertura de ramos igual ou superior à verdade fundamental (ground truth).
• Eficiência: Observou-se que consultar LLMs é significativamente mais rápido (0,81–24,97 segundos) do que computar diretamente a cobertura de ramos executando testes (5,12–168,14 segundos), ofereando um compromisso prático entre precisão e custo.

Significância e Alegações

Os autores alegam que o E-Test preenche efetivamente a lacuna entre o espaço de execução explorado por uma suíte de testes e as execuções experimentadas em produção. Ao automatizar a identificação de cenários "necessários para teste" e "propensos a erro", o E-Test reduz o esforço manual necessário para manter as suítes de testes e aumenta a confiabilidade do software.

O artigo enfatiza que, embora os LLMs sozinhos (vanilla) sejam insuficientes para esta tarefa específica, um pipeline cuidadosamente projetado envolvendo ajuste fino, prompts estruturados e recuperação de contexto (RAG) pode alcançar níveis de desempenho que superam as técnicas atuais de estado da arte. Os resultados sugerem que o E-Test pode ser um componente viável para produtos de software de longa duração, permitindo que as suítes de testes evoluam continuamente junto com os dados de produção sem uma explosão combinatória. Os autores observam que a abordagem está atualmente instanciada para testes unitários, mas visa estender-se para testes de integração e de sistema ao abordar desafios de qualidade de contexto e escalabilidade.