LLM-Guided Issue Generation from Uncovered Code Segments
本文介绍了 IssueSpecter，这是一种自动化工具，它利用覆盖率分析和大型语言模型来识别未覆盖代码段中的缺陷，并生成包含复现步骤和修复建议的、经过优先级排序的可操作问题报告，其有效性和排序性能均优于现有的最先进工具。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你是一家庞大而繁忙的餐厅（一个软件项目）的主厨。你有一支检查员团队（自动化测试），他们在厨房里巡视，检查每一个炉灶、烤箱和台面，确保一切干净且运转正常。他们非常彻底，但有一个盲点：他们只检查被告知要检查的区域。
厨房里有一些阴暗的角落、积满灰尘的架子和被遗忘的抽屉，检查员从未查看过这些地方。这些就是“未覆盖的代码段”。问题在于，最危险的漏洞（比如腐烂的食材或断裂的刀具）往往就藏匿在这些阴暗角落，因为从来没有人去查看过那里。
问题：“预言机”陷阱
传统上，当软件工程师试图在这些阴暗角落中发现漏洞时，他们会尝试编写新的“检查脚本”（测试）来照亮这些地方。但这里有个陷阱：要编写一个能指出“这里出错了”的脚本，你首先必须知道它应该如何工作。如果脚本猜错了，即使刀具实际上已经断裂，它也可能报告“一切正常！”。这被称为“预言机问题”。
解决方案：IssueSpecter（“幽灵猎人”）
本文的作者开发了一种名为IssueSpecter的工具。它不尝试编写新的检查脚本，而是像一个幽灵猎人或侦探那样行动。
以下是其逐步工作原理：
- 地图（覆盖率分析）：首先，IssueSpecter 查看厨房地图，并精确指出检查员从未打开过哪些抽屉和架子。这些就是“未覆盖的段”。
- 侦探（人工智能）：它将这些黑暗、未经测试的代码片段交给一位超级聪明的 AI 侦探（大型语言模型）。AI 的任务不是编写测试，而是阅读代码并想象可能发生什么错误。
- 提示词：AI 被告知：“这是一段无人测试过的代码。请假装你是一位专家主厨。找出此处可能发生的三件坏事。告诉我后果有多严重、如何重现事故以及如何修复。”
- 报告（问题生成）：AI 为它发现的每一个潜在漏洞撰写一份正式的“事故报告”。这些报告包括：
- 严重性：这是轻微的划痕还是火灾隐患？
- 复现步骤：“如果你执行 X，然后执行 Y，厨房就会起火。”
- 修复方案：“这是阻止火灾的新食谱。”
- 编辑（排序）：AI 可能会发现数百个潜在问题，其中许多是微不足道的或虚构的。IssueSpecter 拥有一个两步编辑流程：
- 基于规则的过滤器：一个简单的检查清单，优先处理影响范围广或极其危险的问题。
- AI 重新排序：第二个更智能的 AI 审查会查看前 10 个候选项，并指出：“实际上，这个安全漏洞比那个拼写错误更紧迫。”它会重新排列列表，使最关键的漏洞排在最前面。
他们的发现
该团队在 13 个不同的开源“餐厅”（Python 项目）上测试了这种方法。
- 数量：他们生成了超过 10,000 份潜在漏洞报告。
- 准确性：当人类专家查看前 130 份报告时，84.6% 是真实存在的问题或值得调查。只有约 15% 是误报（AI“幻觉”出不存在的漏洞）。
- 多样性：他们发现了各种类型的问题：逻辑错误（食谱毫无意义）、边界错误（如果盐放太多会发生什么？）甚至安全漏洞（有人可能从后门潜入）。
排序的“魔力”
最重要的发现之一是关于排序。
- 如果你仅仅使用简单的规则（例如“按严重性排序”），你可能会错过最危险的漏洞，因为它看起来与不太危险的漏洞相似。
- 在一个例子（HTTPie 项目）中，简单的规则将一个关键的“路径遍历”安全漏洞（黑客借此可以穿墙而过）排在列表的第 7 位。
- AI 重新排序器意识到了其危险性，并将其移至第 1 位。如果没有 AI，忙碌的开发人员可能在阅读完前 3 项后就停止，从而完全错过了这个关键威胁。
与竞争对手的比较
作者将 IssueSpecter 与CoverUp进行了比较，CoverUp 是一种最先进的工具，试图为这些未覆盖区域生成新测试。
- CoverUp 试图编写脚本来破坏代码。
- IssueSpecter 阅读代码并撰写关于为何它出错的报告。
- 结果：IssueSpecter 发现了稍多有效的漏洞（81% 对 76%），并且至关重要的是，它为开发人员提供了一份现成的报告，其中包含修复方案。使用 CoverUp 时，开发人员仍必须阅读生成的测试，弄清楚它试图表达什么，然后编写修复方案。IssueSpecter 则一次性将“事故报告”和“维修手册”打包交给他们。
现实世界示例（案例研究）
论文重点介绍了 IssueSpecter 捕获的三个具体“幽灵”：
- 内存吞噬者：在一个 HTTP 客户端库中，代码在处理大文件时耗尽了计算机的所有内存，因为它没有“停止”按钮。IssueSpecter 发现了它，并建议添加限制。
- 沉默的数据丢失者：在一个 gzip 解压器中，如果你发送两个压缩文件在一起，该工具会在没有警告的情况下静默丢弃第二个文件。IssueSpecter 发现了这一点，并建议添加一个循环来检查残留数据。
- 类型陷阱：在一个提示处理器中，如果用户尝试将字典用作键，代码就会崩溃。IssueSpecter 发现了这个“不可哈希类型”错误，并建议添加一个修复方案以优雅地处理它。
结论
IssueSpecter 是一个工具，它宣称：“不要只测试你所知道的；要查看你所忽略的。” 通过将未覆盖代码的地图与能够阅读并推理该代码的 AI 侦探相结合，它帮助开发人员发现传统测试所遗漏的隐藏且危险的漏洞，并提供一份优先列表，明确指出首先应该修复什么。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。