想象一下，你是一位试图根据一本旧食谱重现名菜的大厨。这本食谱（即数据集）准确地告诉了你要使用哪些食材以及遵循哪些步骤。然而，随着时间的推移，杂货店的布局发生了变化，产品的名称被更改了，甚至有些商品已经不再销售。如果你今天尝试按照旧的指令来烹饪这道菜，你可能会发现食材缺失了、名字错了，或者烹饪方法不再奏效。
这正是这篇论文中的研究人员所做的事情，只不过他们看的不是食谱，而是一本关于**量子软件漏洞（bugs）**的“食谱”，名为 Bugs4Q。
以下是他们研究内容的简单拆解：
1. 问题所在：“腐烂”的食谱
研究人员使用像 Bugs4Q 这样的数据集来测试用于寻找和修复量子计算机程序漏洞的新工具。这些数据集包含了带有“漏洞”的代码以及该代码的“修复后”版本。
研究人员想知道：如果我们今天尝试运行这些旧的漏洞示例，它们还能运行吗？
他们发现，就像一份旧食谱一样，这个数据集正在随着时间而“腐烂”。
- 结果： 当他们尝试在最新版本的量子软件框架（Qiskit）上运行这些漏洞时，只有 16.2% 的漏洞仍然可以运行。
- 对比： 在该数据集最初创建时，约有 62.2% 的漏洞是可以运行的。
- 类比： 这就像是用 2026 年的烤箱和已经改名或停产的食材，去尝试烘焙一个 2022 年的蛋糕。大多数情况下，蛋糕根本无法发起来。
2. 为什么失败了？（根本原因）
团队研究了这些“食谱”失败的原因。他们发现了两个主要问题：
- 主要是关于“杂货店”（依赖项）： 93.6% 的失败是因为软件依赖于已经发生变化的外部库（就像食材一样）。
- 转折： 在常规（经典）软件的世界里，你通常可以通过告诉计算机“使用这个食材的旧版本”来解决这个问题。
- 量子差异： 在量子软件中，仅仅固定旧版本是不起作用的。这些“食谱”本身已经损坏了，因为其中的指令所引用的工具已经不存在了，或者被移动到了不同的货架上。
- “量子”因素： 出人意料的是，只有 5.1% 的失败实际上是由量子物理学那种奇特、不可预测的特性（例如硬币落地时不是正面就是反面，而是侧立起来）导致的。绝大多数失败都是标准的软件维护问题。
3. 解决方案：“Bugs4Q-Robust”
由于旧的食谱坏掉了，研究人员决定修复它们。他们创建了一个新版本，称为 Bugs4Q-Robust。
- 他们做了什么： 他们手动检查了损坏的食谱并重写了指令。他们更新了“导入路径”（告诉代码在哪里找到食材）并更改了“API 调用”（如何向烤箱发出烘焙请求）。
- 结果： 在这些手动修复之后，成功率从 16.2% 跳回到了 78.4%。
- 代价： 他们无法修复所有问题。大约 10% 的漏洞是无法复现的，因为量子软件的变化如此之大，以至于原始的“漏洞”已经不存在了。这就像是你试图重现一个因为忘了加盐而导致的漏洞，但新的烤箱会自动帮你加盐。你已经无法重新制造那个错误了。
4. 核心教训
论文得出结论：维护一个软件漏洞数据集不仅仅是保存代码那么简单，它要困难得多。
- 对于经典软件： 你通常可以只是冻结环境（比如把食材放入时光胶囊中）来让它再次运行。
- 对于量子软件： 你必须主动重写代码以适应新世界。由于框架演进得如此之快，“冻结”环境是不够的；你必须将食谱迁移到新的厨房中。
简而言之： 研究人员表明，量子软件漏洞数据集是非常脆弱的。随着技术的演进，它们会迅速失效，并且修复它们不仅需要更新设置，更需要重写代码本身，才能让研究得以延续。
技术摘要：关于量子软件缺陷数据集的可复现性：以 Bugs4Q 为例的研究
问题陈述
软件缺陷数据集是软件测试、故障定位和自动化程序修复领域的基础资源。然而，由于执行环境和系统依赖性的变化，这些数据集的可复现性往往会随时间而退化。虽然前人的工作（Zhu 等人）已经证实了经典缺陷数据集（如 Defects4J）存在复现失败的问题，但目前尚不清楚这些发现是否可以推广到量子软件领域。量子程序具有独特的特性，例如概率性输出以及对特定量子门操作的依赖，这可能会引入截然不同的可复现性挑战。本研究旨在填补关于量子软件缺陷数据集时间维度可复现性知识的空白，特别关注 Bugs4Q——一个广泛使用的、基于 Qiskit 的真实世界量子程序缺陷基准数据集。
研究方法
作者对 Zhu 等人的研究进行了操作性复制，并针对量子领域调整了实验设计。
- 数据集： 本研究使用了 Bugs4Q 数据集，该数据集包含从 GitHub、Stack Overflow 和 Stack Exchange 收集的 42 个真实的 Buggy Qiskit 程序。在剔除五个缺乏测试代码的制品后，共分析了 37 个制品。这些制品被分为三类缺陷类型：错误输出（Wrong Output, WO）、抛出异常（Throw Exception, TE）和模拟失败（Simulation Failure, SF）。
- 纵向分析： 作者评估了 Qiskit 核心库在 21 个快照下的可复现性，涵盖了三个主要版本系列（0.x、1.x 和 2.x），跨度为三年（2022 年 5 月至 2026 年 4 月）。
- 实验设置：
- 执行： 总共执行了 77,700 次量子程序运行。为了应对量子测量的非确定性特征，每个制品在每个快照下均执行了 30 次。
- 配置： 测试了两种依赖配置：
- 仅核心（Core-only）： 仅更新 Qiskit 核心库。
- 钉选堆栈（Pinned-stack）： 在更新核心库的同时，根据官方发布说明手动钉选兼容的周边包版本。
- 可复现性标准： 借鉴前人工作，采用了三个严苛程度递增的标准：
- 存在性（Existence）： 有缺陷的版本失败，而修复后的版本成功。
- 类型匹配（Type Match）： 失败类型（例如特定的异常类或断言错误）与原始报告一致。
- 原因匹配（Cause Match）： 运行时证据（例如错误消息或输出偏差）与原始根因一致。
- 根因分析： 对于未能通过最严格标准（原因匹配）的制品，作者使用开放式编码对 543 个复现失败实例进行了人工分类，以识别根因并提出补丁策略。
关键发现与结果
1. 可复现性随时间退化
随着 Qiskit 生态系统的演进，Bugs4Q 的可复现性急剧下降。
- 在初始快照（Qiskit v0.20.1）下，存在性标准的复现率为 62.2%。
- 到最新快照（Qiskit v2.3.1）时，复现率降至 16.2%。
- 复现性的下降在主要版本升级（0.x → 1.x 以及 1.x → 2.x）后最为严重。
- 失效持续性： 与经典数据集（制品有时会重新变得可复现）不同，一旦 Bugs4Q 中的制品变得不可复现，它在随后的所有快照中都保持不可复现状态。在三年的时间里，83.8% 的制品（37 个中的 31 个）经历了至少一次复现失败。
2. 复现失败的根因
对 543 个失败实例的分析显示，93.6% 的失败与依赖项相关，这与经典软件的研究结果一致。然而，这些依赖项的性质存在显著差异：
- 源码相关失败（82.0%）： 这是主要原因。发生原因是制品源代码引用的 Qiskit 接口（导入路径或 API 调用）在较新版本中被移除或重构。
- 导入不兼容（48.1%）： 模块被移动或移除（例如
qiskit.extensions）。
- API 调用不兼容（33.9%）： 旧有的函数（例如
execute）被新的模式（例如 transpile + backend.run）所取代。
- 库相关失败（11.6%）： 核心库与周边包之间的不兼容。
- 量子特有失败（5.1%）： 由于量子测量的概率性特征导致的失败（例如 shot counts 的统计波动）。
- 原始测试问题（1.3%）： 原始测试逻辑本身的缺陷。
3. 可修补性与源代码修改
在关于可修复性的研究中，观察到了与经典软件研究结果的关键分歧：
- 在经典数据集中，约 94% 的失败仅通过更新依赖即可解决。
- 在 Bugs4Q 中，仅有 4.6% 的失败可以通过环境层面的补丁（依赖钉选）来解决。
- 其余 95.4% 需要进行 源代码修改，例如迁移导入语句以及更新 API 调用以适配新的 Qiskit 接口。
贡献
- 实证研究： 这是首个调查量子软件缺陷数据集随时间变化的可复现性的实证研究。
- 根因分类： 本研究对复现失败进行了分类，指出虽然依赖项问题占主导地位，但它们主要表现为源代码接口不匹配，而非简单的版本冲突。
- Bugs4Q-Robust： 作者构建了 Bugs4Q-Robust，这是一个针对 Qiskit v2.3.1 设计的经过修复的增强版数据集。
- 结果： 应用补丁后，在最新版本上的复现率（存在性标准）从 16.2% 提升至 78.4%。
- 局限性： 部分失败仍无法修复，原因是存在“库内部行为变化”，即新 API 会隐式处理原本会触发 Bug 的情况，导致无论如何打补丁都无法复现原始 Bug。
- 对维护工作的启示： 研究强调，维护量子缺陷数据集需要持续进行源代码迁移，而不仅仅是环境管理。
重要性与主张
本文主张，虽然量子软件与经典软件在“可复现性退化”这一现象上是一致的，但其机制与解决方案却不同。
- 依赖管理是必要但不充分的： 不同于通过钉选依赖通常就能解决问题的经典数据集，量子数据集需要通过主动的源代码维护来迁移过时的 API 引用。
- 需要持续维护： 像 Qiskit 这样以重大破坏性变更（breaking changes）为特征的快速演进框架，要求数据集维护者必须定期将制品手动迁移至新 API。
- 未来研究方向： 作者建议，在框架演进（例如参考 Qiskit 迁移指南）的指导下，开发自动化的代码迁移技术，是维护量子缺陷数据集的一个极具前景的方向，因为手动打补丁无法实现规模化。
研究结论指出，对于使用 Bugs4Q 的研究人员而言，报告特定的数据集快照和执行环境，并记录为恢复可复现性而进行的任何修改是非常必要的。作者发布了 Bugs4Q-Robust 及其复现包，以支持这一不断发展的生态系统中的未来研究。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。