AI生成测试的七步审查法：如何避免假阳性测试混入代码库

用七个检查项审核 AI 生成的测试。命名用户风险。打破产品本身。检查最终结果。更换数据。读懂失败信息。重复运行。然后判断这条测试能否拦截一次不良发布。

AI 可以在几秒内写出一条干净的测试。文件看起来可能已经完成。名字可能听起来正确。测试甚至可能通过。

但这些事实都不能证明价值。一条有用的测试，应该能捕获对用户真正重要的失败。在测试加入测试套件之前，你的评审必须找到那个证明。

我为此用七个检查项来做判断。

1. 命名用户风险

从可能受到伤害的人开始。用一句话写出这个风险。

例如："客户看到错误的总额，多付了钱。"

避免"结账可能失败"这类风险。那句话没有指明损害在哪里。它也没有给测试一个明确的目标。

金钱、时间、访问权、信任，都是清晰的答案。"功能坏了"不是。

测试应该在它所保护的行为出问题时失败。在保留之前先证明这一点。

AI 经常写出一条步骤正确的测试。测试可能从来不检查重要的结果。

test('customer can pay', async ({ page }) => {
  await page.goto('/checkout')
  await page.getByRole('button', { name: 'Pay' }).click()
  await expect(page.getByText('Success')).toBeVisible()
})

这条测试检查了一条消息。它没有检查扣款金额。

移除付款操作或返回错误的总额。测试必须失败。通过的结果意味着测试什么有用的保护都没有。

3. 检查最终结果

点击是步骤。结果才是证明。

上面的测试点击了正确的按钮。更强的测试应该检查金额和付款记录。

await expect(page.getByTestId('order-total')).toHaveText('$120.00')
await expect(page.getByTestId('payment-status')).toHaveText('Paid')

一个断言意味着结果检查。Playwright 提供了等待结果的断言。工具可以等待。你仍然要选择正确的结果。

审查每一个断言。问自己它证明了什么用户结果。只确认页面活动的断言应该重写。

AI 倾向于生成一个干净的示例。真实用户带来的是缺失值、错误值和极端值。

测试不止一个金额。包含零、一个很大的值，以及无效文本。

for (const amount of ['0', '999999', 'wrong']) {
  await page.getByLabel('Amount').fill(amount)
  await page.getByRole('button', { name: 'Pay' }).click()
  await expect(page.getByRole('alert')).toBeVisible()
}

具体数值取决于你的产品。审查问题保持简单。一个漂亮的示例能掩盖严重的失败吗？

用错误的结果运行测试。然后读它的消息。

另一个工程师应该能在不打开整个文件的情况下理解问题。对比这两条消息：

Expected: "$20.00"
Received: "$120.00"

Timeout after 30000ms

第一条消息指向产品错误。第二条让人去日志里搜索。

使用清晰的结果检查和有意义的测试名称。失败应该缩短调查时间。

用同样的输入跑两遍。应该得到相同的结果。

重复运行能捕获共享数据和时序问题。也能暴露依赖其他测试的测试。

不要把第二次运行通过当作证明。对比两次运行。在保留测试之前调查任何差异。

7. 做出发布决策

用一个简单的问题收尾：这条测试能拦截一次不良发布吗？

说出它能拦截的发布。例如："当总额错误时，这条测试阻止结账。"

当答案清晰时保留测试。当答案仍然模糊时重写或删除它。

这一步保护评审队列。团队不需要每一条生成的测试。他们需要能证明重要行为的那一小部分。

五分钟评审示例

想象 AI 写了一条结账测试。测试添加了一个产品并完成付款。它检查了成功消息。

首先，命名风险。客户可能支付了错误的总额。

接下来，改变价格计算。测试仍然通过，因为消息出现了。你发现了缺失的证明。

添加一个订单总额的检查。然后尝试过期的优惠券和空购物车。测试应该解释每一次失败的结果。

用同样的数据跑两遍测试。两次运行应该一致。

以发布问题收尾。这条测试应该在扣款总额错误时拦截结账。答案现在命名了一个清晰的发布失败。

这次评审改进了测试本身，而没有添加超出需要的代码。团队获得了有用的证明，而不是另一个通过的文件。

评审时使用这张卡

你可以在几分钟内完成这次评审：

打破受保护的行为。

检查最终结果。

更换输入数据。

读懂失败消息。

说出它拦截的不良发布。

AI 可以处理测试数量。你仍然决定什么值得信任。保留那些正确失败且能解释发布为何应该停止的测试。

Anton Gulin 构建 AI 系统和测量工具。他以测试软件为生，并将那套方法论应用于 AI。他运行独立的 LLM 基准测试并构建生产级测试系统。在 anton.qa 或 LinkedIn 找到他。