Similar Pattern Annotation via Retrieval Knowledge for LLM-Based Test Code Fault Localization

Resumo Técnico: SPARK para Localização de Falhas em Código de Teste

Definição do Problema
Falhas de software no desenvolvimento moderno são frequentemente causadas não por defeitos no Sistema Sob Teste (SUT), mas por falhas no próprio código de teste. Este problema, conhecido como Localização de Falhas em Código de Teste (TCFL), é crítico em ambientes de Integração Contínua (CI) onde grandes suites de teste são executadas frequentemente. No entanto, a TCFL apresenta desafios únicos distintos da localização de falhas tradicional em SUT:

1. Restrições de caixa-preta: O código-fonte do SUT é frequentemente indisponível, impedindo análises de caixa-branca.
2. Sinais diagnósticos limitados: Falhas tipicamente fornecem apenas mensagens de erro e logs parciais, carecendo de rastros de execução detalhados.
3. Grandes espaços de busca: Scripts de teste de nível de sistema modernos são complexos e interagem com múltiplos componentes, expandindo os locais potenciais de falha.
4. Falta de soluções existentes: Embora abordagens baseadas em Localização de Falhas Espectro-Basada (SBFL) e Aprendizado de Máquina existam para SUTs, elas são frequentemente inaplicáveis ao código de teste. A única abordagem existente baseada em LLM (Saboor et al. [59]) depende de prompts padrão com contexto limitado, o que luta com cenários complexos e de múltiplas falhas.

Além disso, embora pipelines de CI acumulem uma vasta história de falhas de teste diagnosticadas e resolvidas, aproveitar efetivamente esse "conhecimento de depuração" para guiar Modelos de Linguagem Grandes (LLMs) permanece um desafio aberto. Abordagens ingênuas de Geração Aumentada por Recuperação (RAG) que injetam casos de teste recuperados inteiros em prompts sofrem de consumo excessivo de tokens, limites de janela de contexto e baixa escalabilidade.

Metodologia: O Framework SPARK
Os autores propõem o SPARK (Anotação de Padrões Similares via Conhecimento de Recuperação), um framework ponta a ponta que integra conhecimento de depuração acumulado em TCFL baseada em LLM sem exigir re-treinamento do modelo. O SPARK opera sob a suposição de que falhas de teste frequentemente se repetem em padrões similares e que um corpus de casos de teste rotulados com falhas está disponível.

O framework consiste em quatro componentes principais:

1. Módulo de Filtragem: Seleciona um subconjunto do corpus rotulado com falhas (base de conhecimento) com base em políticas específicas (por exemplo, todos os casos disponíveis, apenas casos precedentes ou casos temporalmente mais próximos) para gerenciar a disponibilidade de dados e reduzir ruído.
2. Motor de Busca por Similaridade: Computa a similaridade entre um caso de teste "consulta" falho e a base de conhecimento usando embeddings vetoriais de mensagens de erro concatenadas e código de teste. Ele recupera o(s) caso(s) de teste rotulado(s) com falha mais similar(es).
3. Módulo de Recuperação de Contexto: Extrai apenas as linhas defeituosas específicas dos casos de teste similares recuperados, em vez de todo o código de teste.
4. Módulo de Anotação: Esta é a inovação central. Em vez de anexar exemplos recuperados ao prompt, o SPARK anota seletivamente linhas no caso de teste consulta que são textualmente similares (com base na distância de Levenshtein normalizada) às linhas defeituosas recuperadas. Essas anotações são adicionadas como comentários inline (por exemplo, # !!! alta probabilidade de estar defeituosa !!!).

O caso de teste consulta anotado, juntamente com a mensagem de erro e instruções padrão de localização de falhas, é então alimentado em um LLM pronto para uso (Qwen2.5-72B nos experimentos). O LLM é guiado a focar seu raciocínio nas linhas anotadas, efetivamente estreitando o espaço de busca enquanto mantém a capacidade de analisar o contexto completo.

Principais Contribuições

1. Formulação do Problema: O artigo caracteriza o cenário prático da TCFL em ambientes de CI e identifica a oportunidade subutilizada de aproveitar o conhecimento de depuração acumulado.
2. Framework SPARK: Introduz a primeira abordagem para usar sistematicamente conhecimento de depuração aumentado por recuperação para guiar o raciocínio de LLMs para TCFL, abordando especificamente os problemas de escalabilidade do RAG ingênuo.
3. Integração Baseada em Anotação: Os autores propõem um mecanismo leve que destaca seletivamente linhas suspeitas via anotações. Isso evita a "explosão de tamanho do prompt" associada à injeção de exemplos completos, preservando a escalabilidade e a eficiência de inferência.
4. Avaliação Abrangente: O framework é avaliado em três conjuntos de dados industriais contendo casos de teste Python defeituosos do mundo real de diferentes produtos de software.
5. Disponibilidade de Ferramenta e Dados: Os autores fornecem a implementação da ferramenta e embeddings de conjuntos de dados processados (devido a restrições de privacidade) para apoiar a reprodutibilidade.

Resultados Experimentais
A avaliação compara o SPARK contra a abordagem de base de TCFL baseada em LLM (Saboor et al. [59]) em três conjuntos de dados (DS1, DS2, DS3) nas granularidades de linha e unidade (função/bloco).

• Eficácia: O SPARK supera consistentemente a linha de base. No nível de linha, ele melhora a Precisão Top-1 em 10,1–19,1 pontos percentuais (pp) e o Hit@1 por uma margem similar. As melhorias de Recall variam de 6,8 a 11,9 pp. Notavelmente, o SPARK mostra ganhos significativos na identificação de locais corretos em casos de teste complexos contendo múltiplas falhas. Por exemplo, no conjunto de dados de melhor desempenho, o Hit@3 atinge 85,7%, comparado a 60,7% para a linha de base.
• Escalabilidade e Eficiência: Apesar das etapas de recuperação e anotação, o SPARK mantém custos de inferência comparáveis à linha de base. Requer apenas 10–60 tokens de entrada adicionais por caso de teste em média. Os tempos de inferência permanecem quase idênticos à linha de base, com aumentos negligenciáveis (no máximo ~4 segundos por caso de teste em configurações específicas).
• Robustez:
  • Sensibilidade ao Limiar: A abordagem é robusta a variações no limiar de distância de anotação ($\epsilon$). O desempenho permanece estável em uma faixa de 0,00 a 0,15, sugerindo que similaridade estrita não é necessária para que as anotações sejam eficazes.
  • Políticas de Filtragem: Embora o uso de todos os dados disponíveis ($p_{all}$) produza os melhores resultados, políticas que filtram com base na proximidade temporal ($p_{closest-by-time}$) alcançam desempenho quase idêntico enquanto reduzem o tamanho da base de conhecimento em ~90%. Isso indica que o método é adaptável a diferentes cenários de disponibilidade de dados.
  • Estudos de Ablação: Remover a busca por similaridade (Recuperação Aleatória) ou o módulo de anotação (Livre de Anotação) degrada significativamente o desempenho, confirmando que tanto a relevância dos exemplos recuperados quanto o método de integração (anotação) são críticos.

Significado e Alegações
O artigo alega que o SPARK avança o estado da arte ao demonstrar que conhecimento de depuração aumentado por recuperação pode ser integrado efetivamente na localização de falhas baseada em LLM sem comprometer a eficiência. Ao afastar-se da injeção de contexto ingênua em direção a uma estratégia de anotação direcionada, o SPARK permite uma localização de falhas mais precisa em ambientes de CI de caixa-preta e grande escala. Os autores enfatizam que essa abordagem é particularmente valiosa para casos de teste complexos e de múltiplas falhas, onde prompts tradicionais de LLM frequentemente falham em distinguir a causa raiz do sintoma de falha. O trabalho estabelece um caminho prático para aproveitar dados históricos de depuração para melhorar a confiabilidade de software em ambientes industriais.