Automating Detection and Root-Cause Analysis of Flaky Tests in Quantum Software

本文提出了一种自动化管道，利用大语言模型（LLM）和余弦相似度技术，成功将量子软件中的易失性测试数据集扩展了 54%（新增 25 个案例），并验证了 Google Gemini 等模型在检测易失性测试及分析其根本原因方面的高精度表现。

要点

这篇论文就像是在讲一个关于**“捉鬼”的故事，只不过这里的“鬼”不是真的幽灵，而是量子软件里一种让人头疼的“捣乱测试”**（Flaky Tests）。

为了让你更容易理解，我们可以把整个研究过程想象成**“量子软件医院的诊断与治愈计划”**。

1. 背景：什么是“捣乱测试”？

想象一下，你开了一家量子软件工厂。这里的机器（量子计算机）非常神奇，但也非常**“情绪化”和“随性”**。

• 经典软件（普通软件）： 就像做面包。如果你按同样的配方（代码）做，每次烤出来的面包应该是一样的。如果面包烤糊了，那就是配方错了，改好配方下次就能成功。
• 量子软件： 就像在狂风中抛硬币。即使你完全按同样的配方（代码）做，因为量子世界本质上是概率性的（就像风的方向在变），有时候硬币正面朝上，有时候反面朝上。

“捣乱测试”（Flaky Tests） 就是那些**“看心情”的测试员**。

• 今天你运行测试，它说：“通过！没问题！”
• 明天你运行完全一样的测试，它却说：“失败！出大问题了！”
• 后天你又运行，它又说：“哦，刚才那是手滑，其实通过了。”

这种测试最讨厌的地方在于：代码根本没变，但它就是忽好忽坏。 这会让工程师抓狂，因为他们不知道到底是软件真的坏了，还是测试员在“闹脾气”。

2. 问题：以前的医生太累了

以前，要找出这些“捣乱测试”，工程师得像侦探一样，手动去翻几千个工单（Issue Reports）和代码修改记录（Pull Requests）。

• 效率低： 就像在茫茫大海里捞针，靠人眼一个个看关键词（比如搜"flaky"这个词）。
• 漏网之鱼多： 很多捣乱测试因为描述得不够清楚，或者用了不同的词，就被漏掉了。
• 成本极高： 在真实的量子计算机上重跑测试，就像租用昂贵的私人飞机，跑一次就要花很多钱和时间。如果为了确认一个测试是不是“捣乱”而反复跑几十次，成本简直无法承受。

3. 解决方案：给医生装上“超级 AI 大脑”

这篇论文的作者们（来自多伦多和巴尔的摩的研究团队）决定：别让人肉搜了，我们用人工智能（大语言模型，LLM）来帮忙！

他们做了一套**“自动化诊断流水线”**，主要做了三件事：

第一步：扩充“病例库”（数据增强）

他们先有一个包含 46 个已知“捣乱测试”的小数据库。然后，他们利用一种叫**“向量相似度”的技术（可以想象成“找亲戚”**）：

• 把新发现的工单和代码，变成一种“数字指纹”。
• 把这些指纹和已知的“捣乱测试”指纹做对比。
• 如果两个指纹很像，哪怕它们没写过"flaky"这个词，系统也会怀疑：“嘿，这个可能也是个捣乱测试！”
• 成果： 他们成功挖出了25 个以前没人发现的捣乱测试，把数据库扩大了54%。

第二步：训练"AI 医生”（模型评估）

他们找来了市面上最厉害的几位"AI 医生”（比如 Google 的 Gemini, OpenAI 的 GPT, Meta 的 Llama 等），让它们学习如何判断：

1. RQ3（诊断）： 这个工单是不是“捣乱测试”？
2. RQ4（结合案情）： 如果不仅看工单，还看具体的代码片段，能不能更准？
3. RQ5（找病因）： 如果确认是捣乱测试，根本原因是什么？（是随机性？是网络问题？还是多线程打架？）

第三步：实战演练（结果）

经过测试，Google 的 Gemini 2.5 Flash 表现最棒，就像一位经验丰富的老专家：

• 准确率极高： 在识别捣乱测试时，准确率达到了 94% 以上。
• 找病因准： 在分析原因时，准确率更是高达 96%。
• 结论： AI 不仅能帮你快速把“捣乱测试”从几千个工单里挑出来，还能告诉你：“这个测试之所以捣乱，是因为它用的随机数种子没固定住，就像抛硬币没定好规则一样。”

4. 核心发现：量子世界的“捣乱”很特别

通过研究，他们发现量子软件的“捣乱”和经典软件很不一样：

• 经典软件： 捣乱通常是因为**“多线程打架”（几个人同时抢一个资源）或者“网络延迟”**。
• 量子软件： 捣乱主要是因为**“随机性”**（Randomness）。
  • 比喻： 就像你让一个量子程序去生成一个随机数，如果每次生成的随机数种子不一样，测试结果就会变来变去。
  • 药方： 最常见的解决办法就是**“固定随机种子”**（Fix Seed），就像规定抛硬币必须用同一枚硬币、同一个力度，这样结果就稳定了。

5. 总结：这对我们意味着什么？

这篇论文就像是为量子软件行业开发了一套**“智能体检仪”**：

1. 省钱省力： 不需要在昂贵的量子硬件上反复跑测试来确认问题，AI 看一眼代码和工单就能判断。
2. 提高质量： 以前那些被忽略的“捣乱测试”现在能被自动抓出来，防止它们伪装成真正的 Bug，或者掩盖真正的缺陷。
3. 未来可期： 虽然现在的 AI 还不能直接“修好”代码，但它已经能精准地告诉工程师：“这里有问题，原因是 X，建议修改 Y。”

一句话总结：
研究人员利用最先进的人工智能，教会了机器如何识别量子软件中那些“喜怒无常”的测试，不仅扩大了已知问题的数据库，还证明了 AI 能成为量子软件工程师最得力的**“捉鬼助手”**，让量子软件变得更可靠、更稳定。

技术摘要

论文技术总结：量子软件中不稳定测试的自动化检测与根因分析

1. 研究背景与问题定义 (Problem)

背景：
随着量子计算技术的发展，量子软件系统（如 Qiskit, NetKet 等）日益复杂，其开发和维护同样依赖自动化测试。然而，与经典软件不同，量子软件具有固有的概率性输出，这使得它们极易受到“量子不稳定测试”（Quantum Flaky Tests）的影响。

核心问题：

• 定义： 不稳定测试是指在不修改代码的情况下，测试结果在“通过”与“失败”之间不一致地波动。
• 危害： 这类测试会掩盖真实的缺陷，误导开发人员，增加技术债务，并降低开发效率。
• 量子特有挑战：
  1. 根因不同： 经典软件的不稳定多源于并发和异步行为，而量子软件的主要根因是随机性（Randomness）。
  2. 噪声干扰： 量子噪声（如退相干、门错误）引入了额外的变异性，难以区分是真实回归还是硬件波动。
  3. 复现成本高昂： 在真实量子硬件上复现不稳定行为需要多次运行，成本极高（例如 IBM 量子平台按分钟计费且队列有限）。
• 现有局限： 目前缺乏系统性的工具来检测和诊断量子软件中的不稳定测试。现有的基于关键词搜索和人工分析的方法效率低下，且难以扩展。

2. 方法论 (Methodology)

本文提出了一套自动化管道（Automated Pipeline），旨在从代码仓库中检测与不稳定测试相关的 Issue 报告（IRs）和拉取请求（PRs），并识别其根因。

2.1 数据集扩展与构建

• 基础数据： 基于作者先前的研究（包含 46 个手动标记的量子不稳定测试案例）。
• 扩展方法： 利用嵌入模型（Embedding Transformers）和余弦相似度自动发现新的不稳定测试案例。
  • 使用 mixedbread-ai/mxbai-embed-large-v1 模型对 GitHub IRs 和 PRs 进行向量化。
  • 计算新报告与已知不稳定案例的相似度，筛选高分报告进行人工交叉验证。
• 结果： 成功识别了 25 个新的不稳定测试，将数据集规模扩大了 54%（总数达 71 个案例），并补充了导致问题的代码片段及修复方案。

2.2 自动化检测与根因分析流程

利用基础模型（Foundation Models, FMs），特别是大语言模型（LLMs），构建检测与诊断系统：

1. 输入构建： 结合文本证据（IR/PR 描述、评论）和代码上下文（受影响的文件、方法级代码变更）。
2. 任务定义：
   • RQ3 (检测)： 判断给定的 IR/PR 是否与不稳定测试相关（二分类）。
   • RQ4 (上下文增强)： 在加入代码上下文后，判断是否相关。
   • RQ5 (根因识别)： 自动识别不稳定测试的具体根因（如随机性、浮点运算、多线程等 9 类）。
3. 实验设计：
   • 上下文策略： 对比了不同上下文组合：仅描述（Rp/Rf）、方法级代码（Cp）、完整代码（Cf）。
   • 少样本学习（Few-shot）： 引入基于余弦相似度排序的示例（Ep/Ef）作为提示（Prompting）的一部分。
   • 模型评估： 测试了多种 LLM，包括 OpenAI (GPT-4o 系列), Meta (Llama-3.1), Google (Gemini-2.5-flash), 和 Anthropic (Claude-4-haiku)。

3. 关键贡献 (Key Contributions)

1. 数据集扩充： 将现有的量子不稳定测试数据集从 46 个扩展到 71 个（增加 54%），并首次包含了导致问题的** buggy 代码和对应的修复方案**，填补了该领域数据稀缺的空白。
2. 自动化检测管道： 开发了一套基于嵌入相似度和 LLM 的半自动化流程，能够高效挖掘软件仓库中的不稳定测试报告，显著降低了人工筛选成本。
3. LLM 在量子软件工程中的应用验证： 系统评估了多种 LLM 在量子软件不稳定测试分类和根因诊断上的能力，证明了 LLM 在处理此类任务上的潜力。
4. 根因分类体系细化： 基于扩展数据集，详细分析了 8 种根因类别（如随机性、软件环境、多线程等）及其对应的修复模式（如固定随机种子、调整容差等）。

4. 实验结果 (Results)

4.1 数据集统计

• 从 12 个开源量子软件仓库（主要是 Python 和 Q#）中收集了 71 个不稳定测试案例。
• 观察到的不稳定率约为 0.82%（71/8628），虽低于经典工业软件，但考虑到量子项目的年轻性和规模，实际影响巨大。
• 主要根因： 随机性（Randomness） 占比最高（19.2%），最常见的修复方式是固定随机种子（Fix Seed）（占所有修复的 16.4%）。

4.2 模型性能表现

• 最佳模型： Google Gemini 2.5 Flash 表现最优。
  • 不稳定检测 (RQ3)： F1-score 达到 0.9420。
  • 根因识别 (RQ5)： F1-score 达到 0.9643。
• 上下文影响：
  • 包含完整描述和评论（Rf）通常比仅包含初始描述（Rp）效果更好。
  • 方法级代码（Cp） 往往比完整代码列表（Cf）表现更好，这符合人类工程师聚焦关键代码的逻辑，但也受限于数据提取的完整性。
• 其他模型： GPT-4o 在仅文本输入（Rp）下表现良好，但在结合代码上下文时，Gemini 2.5 Flash 展现出更强的推理和泛化能力。

5. 研究意义与未来展望 (Significance & Future Work)

意义：

• 提升软件质量： 为量子软件工程师提供了自动化的工具，用于快速筛选和诊断不稳定测试，减少误报和漏报。
• 降低成本： 通过自动化分析减少了对昂贵量子硬件重复运行测试的需求。
• 社区资源： 公开了扩展后的数据集和自动化管道，为后续研究提供了基准（Benchmark）和可复用的工件。

未来工作：

1. 动态证据集成： 引入动态测试（如模拟器上的选择性重跑）来进一步验证不稳定行为。
2. 自动修复： 开发自动化修复建议，不仅识别根因，还能推荐具体的代码修复模式（如自动添加随机种子）。
3. 数据集扩展： 继续扩展至更多量子平台和仓库，并建立更全面的基准测试。

结论：
该研究表明，利用大语言模型（LLMs）结合文本和代码上下文，可以有效解决量子软件中不稳定测试检测难、诊断难的问题，为量子软件工程（QSE）的自动化维护提供了重要的技术路径。