💬 NLP

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

本文提出了一种自动化流程，该流程利用释义鲁棒性聚类和 XGBoost 分类器来识别、排序和分类行为驱动开发测试套件中的重构机会，结果表明，该分类器在检测大量 Gherkin 文件语料库中可提取的步骤子序列方面，显著优于基于规则和大型语言模型的基线方法。

原作者： Ali Hassaan Mughal, Noor Fatima, Muhammad Bilal

发布于 2026-05-15

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Ali Hassaan Mughal, Noor Fatima, Muhammad Bilal

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象你是一位图书管理员，试图整理一座庞大而混乱的图书馆，其中每一本书都是用一种名为 Gherkin 的特殊语言编写的软件测试。这些测试讲述着这样的故事：“给定这种情况，当发生那件事，那么就会出现这个结果。”

随着时间的推移，图书管理员（开发人员）已经写下了成千上万个这样的故事。但他们犯了一个巨大的错误：他们反复复制粘贴相同的段落。有时他们只是在这里或那里改了一个词（例如“点击按钮”与“按下按钮”），但含义完全相同。这使得图书馆变得臃肿、难以阅读，且更新起来如同噩梦。如果你需要更改某个按钮的工作方式，你就必须在数百个不同的地方找到并修复它。

本文旨在构建一位智能机器人图书管理员，它能够发现这些重复的段落，判断哪些值得清理，并确切地告诉你如何修复它们。

以下是本文的分解说明，使用了简单的类比：

1. 问题所在：“复制 - 粘贴”的混乱

过去，研究人员只能识别出整个故事（完整的测试场景）是否是重复的。但真正的混乱发生在故事的中间部分。

类比：想象两本小说，它们的前三章完全相同，但其余部分不同。简单的扫描器可能会忽略这一点，因为整本书并不是复制品。
本文的解决方案：他们检查了被称为"切片"的小文本块（连续 2 到 18 个步骤的组）。他们在 339 个不同的软件项目中发现了超过500 万个这样的切片。

2. “改写”挑战

机器人图书管理员不能仅仅寻找完全匹配的文本。开发人员经常重新措辞。

类比：如果一个人写的是“用户登录”，而另一个人写的是“客户签到”，简单的搜索引擎会将其视为两件不同的事。但人类知道它们的含义相同。
本文的解决方案：他们使用了一种特殊的 AI（称为 SBERT），它能理解词语背后的含义，而不仅仅是拼写。它将含义相同但用词不同的切片归为一组。这就像将所有同义词归类在一起，以便图书管理员能清晰地看到模式。

3. 清理混乱的三种方式

一旦机器人发现了一个重复的切片，它必须决定如何修复它。本文根据重复发生的位置，确定了三种特定的“工具”：

工具 A：“背景”（在单个文件内）
- 类比：如果某本书中的每个故事都以相同的三句话开头，你不必在每个章节中重写它们。你只需在书的顶部写一次，作为“背景”说明。
- 何时使用：当相同的步骤在同一个文件内重复时。
工具 B：“可重用章节”（在同一个项目内）
- 类比：如果同一个图书馆中的 50 本不同的书都出现了相同的事件序列，你只需将这一序列写在一本“可重用章节”书中。然后，在其他 50 本书中，你只需写上“参见可重用章节 4"。
- 何时使用：当相同的步骤在同一个软件项目的不同文件中重复时。
工具 C：“通用命令”（跨越不同公司）
- 类比：如果你发现世界上几乎每家图书馆都使用完全相同的短语来表示“登录”，你就可以为此创建一个通用的字典条目。任何图书馆只需说“使用通用登录”即可。
- 何时使用：当相同的步骤在不同的人或公司拥有的完全不同的软件项目中重复时。

4. “智能大脑”（机器学习与大语言模型）

作者必须教导机器人哪些重复切片实际上值得修复。并非所有重复都有用；有些只是无聊、琐碎的事情（例如"200 状态码”，仅仅意味着“成功了”）。

训练：他们聘请了三位人类专家，查看 200 个随机切片，并决定：“这值得修复吗？”以及“我们应该使用哪种工具（A、B 或 C）？”
竞赛：他们训练了一个智能计算机模型（称为 XGBoost）向这些人类学习。然后，他们将其与另外两位"AI 评委”（大语言模型，即 LLMs）进行挑战。
结果：XGBoost 模型是明确的赢家。
- 人类专家（XGBoost）：正确率高达 89%。
- AI 评委（LLMs）：正确率仅为 73% 和 59%。
- 原因：LLMs 过于谨慎。即使是一个好主意，它们也常说“不，不要修复这个”，而专用模型则确切地学会了人类在寻找什么。

5. 主要发现

在将这个机器人应用于包含 110 万个测试步骤的庞大图书馆后，他们发现了以下内容：

重复无处不在：约 75% 的测试文件包含可以通过工具 A（背景）清理的重复块。
跨文件重复很常见：约 60% 的项目包含可以通过工具 B（可重用章节）清理的块。
跨公司重复罕见但真实存在：只有约 12% 的项目包含如此通用的块，以至于可以在不同公司之间共享（工具 C）。
“同一所有者”陷阱：他们注意到，许多“跨公司”重复实际上只是同一家公司（如 DataDog）用不同语言发布了其软件的许多不同版本。机器人学会了忽略这些，因为它们并非真正在不同组织之间“共享”。

6. 结论

本文提供了一份蓝图和工具，用于自动发现软件测试中的“复制 - 粘贴”混乱。

它不仅仅说：“嘿，这里有重复。”
它说：“这是重复项，这是它值得修复的原因，以及你需要进行的确切代码更改以修复它。”

作者发布了他们的所有代码、数据以及他们用于指导人类的“规则手册”，以便其他人可以使用这个机器人来清理他们自己的软件库。他们证明，针对这一特定任务，经过专门训练的模型比当今我们经常听到的通用 AI 聊天机器人更出色。

技术摘要：在行为驱动软件测试套件中挖掘子场景重构机会

问题陈述
行为驱动开发（BDD）测试套件（使用 Gherkin 编写）积累了与单元测试语料库类似的维护隐患，包括复制粘贴式设置、参数变化的近重复项以及静默漂移。虽然 prior work 已识别出单步层面的重复或编目了整场景层面的“代码异味”，但存在一个关键缺口：实际的重构单元很少是孤立的步骤，而是两个或更多连续步骤的连续运行（即“切片”）。现有的序列挖掘算法（如 PrefixSpan、SPADE）基于精确符号序列运行，无法处理 BDD 步骤中常见的表面改写变体。此外，尽管存在三种具体的重构机制（文件内的 Background、仓库内可复用的场景、跨组织的共享高层步骤），但 prior work 尚未自动化识别哪些重复子序列值得提取，也未将其映射到适当的机制。

方法论
作者提出了一种静态的、对改写鲁棒的子序列挖掘器，应用于包含 110 万条 Gherkin 步骤的 339 个 GitHub 仓库语料库（涉及 276 个不同的上游所有者）。该流程分为三个主要阶段：

挖掘与嵌入（阶段 0–4）：
- 切片提取： 系统从场景中提取所有连续的 $L$ 步窗口（ $L \in [2, 18]$ ），生成 5,382,249 个切片。
- 改写鲁棒性： 切片并非基于原始文本匹配，而是基于源自 cukereuse 流程的“混合聚类标识符”进行键控。为了恢复因精确聚类 ID 匹配而遗漏的改写等价切片，作者采用 Sentence-BERT (SBERT) 嵌入过程，经 UMAP 降维后使用 HDBSCAN 进行聚类。这生成了 33,121 个改写等价聚类。
- 范围定义： 重复性在三个嵌套范围内进行测量：
  - 文件内（RQ1）： Background 块的候选项。
  - 仓库内跨文件（RQ2）： 通过 I call feature file 调用的可复用场景的候选项。
  - 跨组织（RQ3）： 自定义高层步骤的候选项，定义为在不同上游所有者（而不仅仅是仓库，以避免因单一所有者拥有多语言 SDK 而虚增计数）之间的重复。
人工标注（阶段 5）：
- 一个包含 200 个切片的分层池由三位作者根据书面评分标准进行标注。
- 评分标准定义了一个四类别的“值得提取”标签（是、否、不确定、标记 - 规范）以及一个机制标签。
- 评分者间一致性（Fleiss' $\kappa$ ）在“值得提取”方面为 0.56，在机制选择方面为 0.79。
建模与基线（阶段 6–8）：
- 分类器： 训练了一个 XGBoost 二分类器，利用切片长度（ $L$ ）、支持计数、异常值比例和范围信号等特征来预测“值得提取性”。
- 机制预测器： 一个次级头用于预测具体的重构机制。
- 基线： 将该分类器与经过调优的基于规则的基线以及两个开放权重大语言模型（LLM）评判器（gpt-oss-120b 和 ling-2.6-1t）进行了比较。

关键结果

语料库规模： 挖掘器识别出 692,020 个不同的重复模式。其中，30,955 个模式在 $\ge 2$ 个不同的上游所有者之间重复。
分类器性能： XGBoost 分类器的折外 F1 分数达到 0.891（95% CI [0.852, 0.927]）。这显著优于基于规则的基线（F1 = 0.836， $p=0.017$ ）以及两个 LLM 评判器（最佳 LLM F1 = 0.728， $p < 10^{-4}$ ）。
普遍性： 应用分类器门控后：
- 75.0% 的场景包含文件内的 Background 候选项。
- 59.5% 包含仓库内可复用场景的候选项。
- 11.7% 包含跨组织共享步骤的候选项。
LLM 局限性： 虽然 LLM 在“是”类别上具有高度精确性，但在召回率上较为保守，低估了值得提取性。它们在机制选择任务（以“是”为条件）上的表现很高（ $\ge 0.95$ 准确率），但在主要的提取决策上未能匹配分类器的性能。
过滤： 一个六条规则的验证过滤链（R1–R6）将候选集从 464,073 个减少到 84,564 个模式，主要通过合并嵌套表示和移除琐碎内容来实现。

意义与贡献
本文声称提供了首个针对 BDD 规范的、在语料库规模上运行的改写鲁棒子序列挖掘器。其主要贡献包括：

切片清单： 一个包含 540 万个连续步骤子序列的排名列表，这些子序列被合并为 692,020 个重复模式，并映射到三种具体的复用机制，同时发布了 Cucumber-Java 实现。
自动化发现： 一个自动化识别哪些切片值得提取的流程，解决了大规模采用 BDD 时手动目标识别的“限制成本”。
实证证据： 证明专用 ML 分类器在确定 BDD 测试套件的重构适用性方面，显著优于基于规则的启发式方法和现成的 LLM 评判器。
可复现性： 所有工件，包括挖掘脚本、标注池、评分标准和训练好的分类器，均在 Apache-2.0 许可下发布。

作者将这项工作定位为三篇论文弧中的“哪个”（which）组件：Mughal (2024) 提供了“如何”（机制），Mughal et al. (2026) 提供了“多少”（步骤级重复规模），而本文提供了“哪个”（每切片提取决策）。论文结论指出，虽然重复结构普遍存在，但跨组织信号主要由基础设施重复（例如 HTTP 请求/响应惯用法）主导，而非复杂的业务逻辑，这表明最直接的价值在于简短且频繁重复的宏。