Resumo Técnico: Geração Contínua de Casos de Teste para Grandes Modelos de Linguagem com Memória de Projeto

1. Definição do Problema

Em sistemas de software de grande escala que passam por iterações ágeis e entrega contínua, manter uma cobertura de testes eficaz é um desafio devido à evolução de requisitos, atualizações de interfaces e defeitos recorrentes. Scripts de testes automáticos convencionais e abordagens padrão de Grandes Modelos de Linguagem (LLMs) frequentemente falham em reutilizar efetivamente dados históricos de falhas ou cobrir riscos emergentes. A literatura existente destaca limitações específicas:

• Déficits de Contexto: LLMs padrão lutam contra asserções instáveis e falta de contexto [1].
• Estagnação de Cobertura: Modelos pré-treinados podem melhorar testes baseados em busca, mas ainda enfrentam platôs de cobertura [2].
• Negligência Histórica: Abordagens que melhoram a cobertura muitas vezes falham em reutilizar suficientemente defeitos históricos do nível do projeto [3].
• Desequilíbrio de Estratégia: Estratégias de geração única têm dificuldade em equilibrar cobertura com capacidades de gatilho de defeitos [4].
• Lacunas de Memória: Aplicações de Desenvolvimento Orientado a Testes (TDD) de LLMs frequentemente carecem de mecanismos para memória de evolução de versão de longo prazo [5].

O problema central é definido como uma Tarefa de Otimização de Cobertura de Risco Restrita em Evolução de Versão, onde o objetivo é selecionar um conjunto de casos de teste ideal que maximize a cobertura ponderada de caminhos de negócio alterados e gatilhos de defeitos históricos, minimizando casos inválidos e duplicidade semântica.

2. Metodologia

A solução proposta introduz um framework de Memória de Projeto, tratando a memória não como um apêndice simples de Recuperação Aumentada por Geração (RAG), mas como uma camada de controle que evolui conforme o release. A metodologia consiste em três estágios principais:

2.1 Construção da Base de Conhecimento de Memória do Projeto

O sistema agrega ativos de teste de múltiplas fontes em granularidade de evento, integrando:

• Fontes de Dados: Documentos de requisitos, descrições de interface (OpenAPI), commits de código, relatórios de problemas/defeitos e scripts de teste existentes.
• Limpeza de Dados: Remoção de texto de template e logs inválidos; conversão de dados sensíveis (ex: números de pedido, SKUs) em tokens irreversíveis ou placeholders genéricos.
• Segmentação Semântica: Os dados são etiquetados por release_id, business_path_id, api_chain, state_pair, risk_tag e trigger_condition.
• Representação Vetorializada: Um vetor de estado de memória heterogêneo é construído usando um índice HNSW. O vetor $\mathbf{m}_i$ para uma unidade de memória é uma fusão ponderada de:
  • Embedding semântico ($\mathbf{e}_{sem}$)
  • Embedding de tipo (requisitos, interface, defeito, script)
  • Embedding de versão
  • Embedding de rótulo de risco
  • Pesos: $\alpha=0.45$ (semântico), $\beta=0.15$ (tipo), $\gamma=0.15$ (versão), $\delta=0.25$ (risco).

2.2 Mecanismo de Atualização Incremental de Memória

A memória evolui com base em commits, mudanças de interface ou transições de defeitos. Um Analisador de Diff extrai mudanças e, se um limite (0.35) for excedido, a memória é versionada; caso contrário, os pesos são atualizados. A fórmula de atualização de peso incorpora:

• Coeficiente de retenção histórica ($\eta = 0.72$)
• Frequência de recorrência de defeitos
• Nível de risco de negócio
• Similaridade semântica com as mudanças atuais
• Decaimento de distância de versão

2.3 Pipeline Generativo

O processo de geração utiliza o Llama3.1-70B-Instruct guiado pelos seguintes passos:

1. Recuperação de Memória Relacionada ao Risco: Um vetor de consulta é construído a partir das mudanças de requisição e diffs de API. O HNSW recupera as 50 unidades de memória superiores, que são então reclassificadas por um controlador de feedback de risco baseado em recorrência de defeitos, importância do caminho e distância de versão.
2. Construção de Prompt: As 12 memórias de risco superiores, os diffs de interface atuais e as asserções de falha histórica são formatados em fragmentos JSON. O prompt inclui campos para Cenário, Cadeia de API, Precondições, Limites de Entrada, Memória de Risco, Asserções Esperadas e Casos Negativos.
3. Geração e Validação: O modelo gera candidatos com parâmetros restritos (Temperatura=0.2, Top-p=0.85).
4. Deduplicação e Verificação de Consistência: Os casos gerados passam por:
   • Deduplicação Semântica: Usando Sentence-BERT com um limiar de similaridade de cosseno de 0.86.
   • Verificação de Asserção e Estado: Verificação de novos valores de borda ou ramos de exceção.
   • Validação de Schema e Máquina de Estados: Garantindo conformidade com OpenAPI e transições de estado válidas (ex: prevenir Pago $\to$ Criado).

3. Principais Contribuições

• Modelagem de Memória Heterogênea Versionada: Indo além do RAG estático para um sistema de memória dinâmico que rastreia a evolução da versão e o risco.
• Feedback de Gatilho de Defeito: Um mecanismo que pondera a recuperação de memória com base na recorrência de defeitos históricos e risco de negócio.
• Seleção de Contexto Consciente de Risco: Uma estratégia de reclassificação que prioriza caminhos densos em defeitos sobre fluxos normais.
• Deduplicação Semântica com Preservação de Bordas: Um processo de filtragem que remove casos redundantes enquanto retém variações críticas de borda e ramos de exceção.
• Verificação de Consistência de Estado: Módulos de validação que garantem que os casos de teste gerados adiram às transições de estado válidas e restrições de schema.

4. Resultados Experimentais

O método foi avaliado em um Sistema de Pedidos de E-commerce real contendo 214 APIs de backend, mais de 9.600 scripts históricos e 3.180 defeitos históricos ao longo de um ciclo de 14 meses.

Métricas de Desempenho (vs. Prompting sem Memória):

• Taxa de Caso de Teste Eficaz: Alcançou 88,7% (±1,1%), comparado a 28,1% para prompting sem memória.
• Redução de Duplicação: Reduziu a duplicação em 8,9% (±0,7%).
• Cobertura de Caminho de Alto Risco: Atingiu 91,3%.
• Descoberta de Defeitos: Identificou 61 defeitos, uma melhoria de 19,6% sobre a linha de base sem memória (51 defeitos).

Análise Comparativa:

• O método proposto superou as linhas de base, incluindo RAG puro, CODAMOSA, CAT-LM, templates de regras e testes suplementares humanos.
• Estudos de Ablação: Remover a memória do projeto reduziu a eficiência para 66,1% e a cobertura de alto risco para 73,4%. Remover a reclassificação de risco baixou a cobertura para 82,1%. Remover a deduplicação aumentou a duplicação para 21,4%.
• Tamanho do Modelo: Embora o modelo 70B tenha mostrado desempenho superior em raciocínio de cadeia de chamada longa e reparo de asserção, modelos menores (Llama3.1-8B, Qwen2.5-14B) permaneceram competitivos (80,4% e 83,6% respectivamente), sugerindo que o framework não é inteiramente dependente de contagens massivas de parâmetros.

5. Significância e Alegações

O artigo afirma que a Memória de Projeto melhora significativamente a capacidade de um LLM de entender regras de negócio de longo prazo, dependências entre interfaces e padrões de falha históricos. Ao tratar a memória como uma camada de controle que evolui com o release, em vez de um apêndice estático, a abordagem aborda com sucesso a "estagnação" da cobertura de testes em ambientes de entrega contínua.

Os autores observam que o método é particularmente eficaz na detecção de falhas sensíveis a regressão, como rollbacks entre interfaces, problemas de recuperação de cupom, violações de idempotência e incompatibilidades de renomeação de campos.

Limitações Reconhecidas:
A abordagem depende da disponibilidade de registros de bugs abrangentes, padrões de interface claros e uma arquitetura de backend específica (sistema de pedidos de e-commerce). Os autores alertam que documentação pobre ou arquiteturas complexas podem reduzir a recuperação de memória e a portabilidade. O framework é apresentado como uma solução específica para a geração contínua de casos de teste em sistemas de software em evolução, com dados e scripts anonimizados fornecidos para validação subsequente.