💬 NLP

Mining Subscenario Refactoring Opportunities in Behaviour-Driven Software Test Suites: ML Classifiers and LLM-Judge Baselines

Este artigo apresenta um pipeline automatizado que utiliza agrupamento robusto a paráfrases e um classificador XGBoost para identificar, classificar e categorizar oportunidades de refatoração em suites de testes de Desenvolvimento Orientado a Comportamento, demonstrando que o classificador supera significativamente tanto as abordagens baseadas em regras quanto as linhas de base de Modelos de Linguagem Grandes na detecção de subsequências de passos extraíveis em um grande corpus de arquivos Gherkin.

Autores originais: Ali Hassaan Mughal, Noor Fatima, Muhammad Bilal

Publicado 2026-05-15

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Ali Hassaan Mughal, Noor Fatima, Muhammad Bilal

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ê é um bibliotecário tentando organizar uma biblioteca massiva e caótica, onde cada livro é um teste de software escrito em uma linguagem especial chamada Gherkin. Esses testes contam uma história: "Dado isto, Quando aquilo, Então isto."

Com o tempo, os bibliotecários (desenvolvedores) escreveram milhares dessas histórias. Mas eles cometeram um grande erro: continuam copiando e colando os mesmos parágrafos repetidamente. Às vezes, mudam uma palavra aqui ou ali ("clique no botão" vs. "pressione o botão"), mas o significado é exatamente o mesmo. Isso deixa a biblioteca inchada, difícil de ler e um pesadelo para atualizar. Se você precisar alterar como um botão funciona, terá que encontrar e corrigi-lo em centenas de lugares diferentes.

Este artigo trata de construir um bibliotecário robô inteligente que possa encontrar esses parágrafos repetitivos, identificar quais valem a pena ser limpos e dizer exatamente como corrigi-los.

Veja como o artigo se estrutura, usando analogias simples:

1. O Problema: A Bagunça do "Copiar e Colar"

No passado, os pesquisadores só conseguiam detectar se uma história inteira (um cenário completo de teste) era uma duplicata. Mas a verdadeira bagunça acontece no meio das histórias.

A Analogia: Imagine dois romances onde os primeiros três capítulos são idênticos, mas o restante é diferente. Um scanner simples poderia perder isso porque o livro inteiro não é uma cópia.
A Solução do Artigo: Eles analisaram pequenos pedaços de texto chamados "fatias" (grupos de 2 a 18 passos consecutivos). Encontraram mais de 5 milhões dessas fatias em 339 projetos de software diferentes.

2. O Desafio da "Paráfrase"

O bibliotecário robô não pode apenas procurar correspondências exatas de texto. Os desenvolvedores frequentemente reformulam as coisas.

A Analogia: Se uma pessoa escreve "O usuário faz login" e outra escreve "O cliente entra na conta", um mecanismo de busca simples vê duas coisas diferentes. Mas um humano sabe que significam a mesma coisa.
A Solução do Artigo: Eles usaram uma IA especial (chamada SBERT) que entende o significado por trás das palavras, e não apenas a ortografia. Ela agrupa fatias que significam a mesma coisa, mesmo que as palavras sejam diferentes. É como agrupar todos os sinônimos juntos para que o bibliotecário veja o padrão claramente.

3. As Três Maneiras de Corrigir a Bagunça

Uma vez que o robô encontra uma fatia repetitiva, ele precisa decidir como corrigi-la. O artigo identifica três "ferramentas" específicas para o trabalho, dependendo de onde a repetição ocorre:

Ferramenta A: O "Fundo" (Dentro de um único arquivo)
- Analogia: Se toda história em um livro específico começa com as mesmas três frases, você não as reescreve em cada capítulo. Você as escreve uma vez no topo do livro como uma nota de "Fundo".
- Quando usar: Quando os mesmos passos se repetem dentro de um único arquivo.
Ferramenta B: O "Capítulo Reutilizável" (Dentro de um projeto)
- Analogia: Se uma sequência específica de eventos acontece em 50 livros diferentes na mesma biblioteca, você escreve essa sequência uma vez em um livro de "Capítulo Reutilizável". Então, nos outros 50 livros, você apenas escreve "Ver Capítulo Reutilizável 4".
- Quando usar: Quando os mesmos passos se repetem em arquivos diferentes dentro do mesmo projeto de software.
Ferramenta C: O "Comando Universal" (Entre diferentes empresas)
- Analogia: Se você descobre que quase todas as bibliotecas do mundo usam exatamente a mesma frase para "Fazer login", você cria uma entrada universal no dicionário para isso. Qualquer biblioteca pode apenas dizer "Use Login Universal".
- Quando usar: Quando os mesmos passos se repetem em projetos de software totalmente diferentes, pertencentes a pessoas ou empresas distintas.

4. O "Cérebro Inteligente" (Aprendizado de Máquina vs. LLMs)

Os autores precisaram ensinar ao robô quais fatias repetitivas valem a pena ser corrigidas. Nem toda repetição é útil; algumas são apenas coisas chatas e triviais (como "status 200", que apenas significa "funcionou").

O Treinamento: Eles contrataram três especialistas humanos para analisar 200 fatias aleatórias e decidir: "Isso vale a pena corrigir?" e "Qual ferramenta (A, B ou C) devemos usar?"
O Concurso: Eles treinaram um modelo de computador inteligente (chamado XGBoost) para aprender com esses humanos. Em seguida, desafiaram-no contra dois outros "juízes de IA" (Modelos de Linguagem Grandes, ou LLMs).
O Resultado: O modelo XGBoost foi o vencedor claro.
- O Especialista Humano (XGBoost): Acertou 89% das vezes.
- Os Juízes de IA (LLMs): Acertaram apenas 73% e 59% das vezes.
- Por quê? Os LLMs foram muito cautelosos. Frequentemente diziam "Não, não corrija isso", mesmo quando era uma boa ideia, enquanto o modelo especializado aprendeu exatamente o que os humanos estavam procurando.

5. As Grandes Descobertas

Após executar esse robô na biblioteca massiva de 1,1 milhão de etapas de teste, eis o que descobriram:

A repetição está em todo lugar: Cerca de 75% dos arquivos de teste têm pedaços repetitivos que poderiam ser limpos usando a Ferramenta A (Fundo).
A repetição entre arquivos é comum: Cerca de 60% dos projetos têm pedaços que poderiam ser limpos usando a Ferramenta B (Capítulo Reutilizável).
A repetição entre empresas é rara, mas real: Apenas cerca de 12% dos projetos têm pedaços tão universais que poderiam ser compartilhados entre diferentes empresas (Ferramenta C).
A Armadilha do "Mesmo Proprietário": Eles notaram que muitas repetições "entre empresas" eram, na verdade, apenas uma empresa (como a DataDog) publicando muitas versões diferentes de seu software em idiomas diferentes. O robô aprendeu a ignorar essas, pois elas não são verdadeiramente "compartilhadas" entre organizações distintas.

6. A Conclusão

Este artigo fornece um projeto e uma ferramenta para encontrar automaticamente a bagunça de "copiar e colar" em testes de software.

Não diz apenas "Ei, há uma duplicata."
Diz: "Aqui está a duplicata, aqui está o motivo pelo qual vale a pena corrigi-la e aqui está a alteração exata de código que você precisa fazer para corrigi-la."

Os autores liberaram todo o seu código, dados e o "manual de regras" que usaram para os humanos, para que qualquer outra pessoa possa usar esse robô para limpar suas próprias bibliotecas de software. Eles provaram que um modelo especializado e treinado é melhor para esta tarefa específica do que os chatbots de IA de propósito geral dos quais frequentemente ouvimos falar hoje.

Resumo Técnico: Mineração de Oportunidades de Refatoração de Subcenários em Suítes de Testes de Software Orientadas a Comportamento

Declaração do Problema
Suítes de testes de Desenvolvimento Orientado a Comportamento (BDD), escritas em Gherkin, acumulam riscos de manutenção semelhantes a corpora de testes unitários, incluindo configuração de copiar-e-colar, quase-duplicatas com variação de parâmetros e deriva silenciosa. Embora trabalhos anteriores tenham identificado duplicação no nível de etapa única ou catalogado "maus cheiros" no nível de cenário completo, uma lacuna crítica permanece: a unidade prática de refatoração raramente é uma etapa isolada, mas sim uma sequência contígua de duas ou mais etapas (uma "fatia"). Algoritmos existentes de mineração de sequências (por exemplo, PrefixSpan, SPADE) operam em sequências exatas de símbolos e falham ao lidar com as variações de paráfrase superficiais comuns nas etapas do BDD. Além disso, embora existam três mecanismos de refatoração concretos (Background dentro do arquivo, cenários reutilizáveis dentro do repositório e etapas superiores compartilhadas entre organizações), nenhum trabalho anterior automatiza a identificação de quais subsequências recorrentes valem a pena extrair ou mapeá-las para o mecanismo apropriado.

Metodologia
Os autores apresentam um minerador de subsequências estático e robusto a paráfrases aplicado a um corpus de 339 repositórios do GitHub (276 proprietários upstream distintos) contendo 1,1 milhão de etapas Gherkin. O pipeline é organizado em três etapas principais:

Mineração e Incorporação (Fases 0–4):
- Extração de Fatias: O sistema extrai todas as janelas contíguas de $L$ etapas ( $L \in [2, 18]$ ) dos cenários, gerando 5.382.249 fatias.
- Robustez a Paráfrases: Em vez de correspondência de texto bruto, as fatias são indexadas por "identificadores de cluster híbrido" derivados do pipeline cukereuse. Para recuperar fatias equivalentes em paráfrase perdidas pela correspondência exata de ID de cluster, os autores empregam uma passagem de incorporação Sentence-BERT (SBERT), reduzida via UMAP e agrupada usando HDBSCAN. Isso resulta em 33.121 clusters de equivalência de paráfrase.
- Definição de Escopo: A recorrência é medida em três escopos aninhados:
  - Dentro do arquivo (RQ1): Candidatos para um bloco Background.
  - Entre arquivos dentro do repositório (RQ2): Candidatos para um cenário reutilizável invocado via I call feature file.
  - Entre organizações (RQ3): Candidatos para uma etapa superior personalizada, definida pela recorrência entre proprietários upstream distintos (não apenas repositórios, para evitar inflar contagens de proprietários únicos com SDKs multilíngues).
Rotulagem Humana (Fase 5):
- Um pool estratificado de 200 fatias foi rotulado por três autores contra uma rubrica escrita.
- A rubrica define um rótulo de quatro categorias "merecedor de extração" (sim, não, incerto, especificação sinalizada) e um rótulo de mecanismo.
- A concordância entre avaliadores (Fleiss' $\kappa$ ) foi de 0,56 para merecimento de extração e 0,79 para seleção de mecanismo.
Modelagem e Linhas de Base (Fases 6–8):
- Classificador: Um classificador binário XGBoost foi treinado para prever "merecimento de extração" usando características como comprimento da fatia ( $L$ ), contagens de suporte, frações de outliers e sinais de escopo.
- Preditor de Mecanismo: Uma segunda cabeça prediz o mecanismo de refatoração específico.
- Linhas de Base: O classificador foi comparado a uma linha de base baseada em regras ajustada e dois juízes de Grandes Modelos de Linguagem (LLM) de pesos abertos (gpt-oss-120b e ling-2.6-1t).

Resultados Principais

Escala do Corpus: O minerador identificou 692.020 padrões recorrentes distintos. Desses, 30.955 ocorrem em $\ge 2$ proprietários upstream distintos.
Desempenho do Classificador: O classificador XGBoost alcançou um escore F1 fora da dobra de 0,891 (IC 95% [0,852, 0,927]). Isso superou significativamente a linha de base baseada em regras (F1 = 0,836, $p=0,017$ ) e ambos os juízes LLM (melhor F1 de LLM = 0,728, $p < 10^{-4}$ ).
Prevalência: Após aplicar o filtro do classificador:
- 75,0% dos cenários contêm um candidato de Background dentro do arquivo.
- 59,5% contêm um candidato de cenário reutilizável dentro do repositório.
- 11,7% contêm um candidato de etapa compartilhada entre organizações.
Limitações dos LLMs: Embora os LLMs fossem altamente precisos na classe "sim", foram conservadores na recuperação, subestimando o merecimento de extração. Seu desempenho na tarefa de seleção de mecanismo (condicional a "sim") foi alto ( $\ge 0,95$ de precisão), mas não conseguiram igualar o classificador na decisão primária de extração.
Filtragem: Uma cadeia de filtro de verificação de seis regras (R1–R6) reduziu o conjunto de candidatos de 464.073 para 84.564 padrões, principalmente ao colapsar representações aninhadas e remover conteúdo trivial.

Significado e Contribuições
O artigo afirma fornecer o primeiro minerador de subsequências robusto a paráfrases para especificações BDD que opera em escala de corpus. Suas principais contribuições são:

Um Inventário de Fatias: Uma lista classificada de 5,4 milhões de subsequências contíguas de etapas colapsadas em 692.020 padrões recorrentes, mapeados para três mecanismos de reutilização específicos com implementações publicadas em Cucumber-Java.
Descoberta Automatizada: Um pipeline que automatiza a identificação de quais fatias valem a pena extrair, abordando o "custo limitante" da identificação manual de alvos na adoção de BDD em larga escala.
Evidência Empírica: Uma demonstração de que um classificador ML especializado supera significativamente tanto heurísticas baseadas em regras quanto juízes LLM prontos para uso na determinação da adequação de refatoração para suítes de testes BDD.
Reprodutibilidade: Todos os artefatos, incluindo os scripts de mineração, o pool rotulado, a rubrica e os classificadores treinados, são lançados sob a licença Apache-2.0.

Os autores posicionam este trabalho como o componente "qual" em um arco de três artigos: Mughal (2024) forneceu o "como" (mecanismos), Mughal et al. (2026) forneceu o "quanto" (escala de duplicação no nível de etapa) e este artigo fornece o "qual" (decisões de extração por fatia). O artigo conclui que, embora a estrutura recorrente seja pervasiva, o sinal entre organizações é dominado por duplicação infraestrutural (por exemplo, idiomáticas de requisição/resposta HTTP) em vez de lógica de negócios complexa, sugerindo que o valor mais imediato reside em macros curtas e frequentemente repetidas.