When Generative AI Writes Test Cases: Scenario-Driven Evaluation of Generated Tests
本文引入了一种场景驱动的评估方法，用于将生成式人工智能（GenAI）生成的测试套件与人工编写的测试套件进行对比，结果表明，虽然直接提示策略能恢复更多的预期行为，但“先构思后实现”策略能产生更高效、重复项更少的测试套件，而“仅构思”方法则能有效地发现额外的测试场景。
原始论文采用 CC BY 4.0 许可（https://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下你是一位大厨，正试图教一位非常有天赋但有时过于急躁的 AI 助手如何烹饪一道特定的菜肴。你有一张“金标准”食谱卡（即人工测试集），上面详细列出了这道菜应该是什么味道，以及如何检查是否做得正确。
这篇论文讨论的是让 AI 编写它自己的“味觉测试”来判断菜肴是否美味，并研究如何更好地向它提问。
以下是使用简单类比对这项研究进行的拆解：
问题所在：“黑盒”式的 AI 测试
软件开发人员使用 AI 来编写测试（确保代码正常工作的检查）。但通常，我们只检查 AI 的测试是“通过”还是“失败”，或者它们覆盖了多少行代码。这就像是在检查一个学生是否在数学考试中得到了正确答案，却不去观察他们是如何思考问题的。
研究人员想知道：AI 真的理解了问题的不同“风味”（场景），还是仅仅在瞎猜？
三种提问方式（提示策略）
研究人员尝试了三种不同的方式来与 AI（使用 GPT-4o）交流以生成这些测试。你可以把这些看作是三种不同的向副厨师索要品鉴菜单的方式：
直接实现（“直接做”法）：
- 提示词： “这是代码。现在立刻给我写一份完整的测试列表。”
- 结果： AI 会急于冲向终点。它找到了你想要的大部分正确的“风味”（场景），但过程有点混乱。它会重复编写相同的测试（重复项），有时还会发明一些奇怪且没必要的测试。这就像一位大厨做了 20 份汤样，但其中 10 份竟然是一模一样的。
仅构思（“头脑风暴”法）：
- 提示词： “先不要写代码。先告诉我你应该写哪些类型的测试。给我一个想法清单。”
- 结果： AI 表现得像一个富有创造力的头脑风暴伙伴。它能提出最多关于原食谱中没有提到的、新颖且有趣的创意。然而，它并没有实际“下厨”（编写代码），所以你必须亲自动手将这些想法转化为真正的测试。
先构思后实现（“先计划再行动”法）：
- 提示词： “首先，思考测试的想法。然后，利用这些具体的想法来编写实际的代码。”
- 结果： 这是最有条理的方法。AI 在行动之前会先停下来思考。它生成的测试列表更精简、更干净，重复项非常少。这就像一位大厨先写好购物清单，检查一遍，然后只烹饪真正需要的食材。
关键发现（味觉测试结果）
找回“金标准”：
当被要求“直接做”（直接实现）时，AI 找到了你原有的绝大部分测试场景。但它很混乱。当被强制要求“先计划”（先构思后实现）时，它变得更整洁了，但漏掉了一些原始场景。- 类比： 如果你要求 AI 从一个罐子里找出所有的红弹珠，“直接做”的方法能找到几乎所有的红弹珠，但也顺带抓了一堆蓝弹珠。而“先计划”的方法抓到的红弹珠较少，但没有抓错任何蓝弹珠。
“新”创意：
“仅构思”（头脑风暴）法最擅长发现那些不在你原食谱中的新场景。有时，这些新想法非常有价值——它们捕捉到了原始测试遗漏的漏洞（Bug）。但通常情况下，它们只是对你已知事物的微小变体。“损坏”的测试：
一些 AI 生成的测试无法运行。研究人员仔细观察了失败的原因。- 大多数失败都很简单： AI 猜错了数字（例如，“我认为答案是 5”，但实际上是 4）。这些很容易修复。
- 有些失败很深层： AI 从根本上误解了代码的工作原理（例如，认为门是开着的，但实际上是锁着的）。这些很难修复，因为 AI 的逻辑本身就是错的。
核心结论
并没有一种单一的“完美”方式来要求 AI 编写测试。这取决于你的需求：
- 如果你想捕捉到原团队想到的所有内容，哪怕过程很混乱，请使用直接实现。
- 如果你想要一个精简、高效的列表且没有重复项，请使用先构思后实现。
- 如果你想发现你尚未想到的、具有创造性的新想法，请使用仅构思（然后挑选出最好的部分进行构建）。
研究结论指出，通过观察测试背后的“想法”（场景）而非仅仅看代码本身，开发者可以做出更明智的选择，从而更好地将 AI 应用于工作中。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。