AI 测试报出 23 个问题，人工确认仅 8 个

289 条测试、23 个疑似问题，最后只有 8 个经人工核查成立。这是一个 AI 测试工具团队公开的自家实测结果。作者想讨论的不是 Agent 能跑多快，而是它报出来的问题，有多少值得开发者花时间处理。

这次实验最有用的地方，是把误报也摊开了：AI 擅长发现应用前后矛盾、闯进异常状态，却容易把不了解的业务规则当成缺陷。对准备引入 AI 测试的前端和全栈团队，这比一份漂亮的测试数量报告更有参考价值。

23 个问题，为什么要用两种比例看

测试对象是 Toolshop，一个供测试人员练习 Playwright 和 Cypress 的五金商店演示应用，包含注册、登录、搜索、商品详情、购物车和结账流程。

Agent 只拿到 URL，没有测试账号、需求说明或额外提示。在一次 30 分钟运行中，它梳理出 16 条用户流程、29 条业务规则，生成 289 条测试用例，时间耗尽前执行了 71 条，报告 23 个问题。

人工逐条检查后，结果分成三类：

• 8 个问题在在线站点上得到确认。
• 9 个不成立，包括设计选择、演示系统的简化处理和 Agent 自身判断错误。
• 6 个无法核查，因为需要创建账号，而团队的拆解规则禁止这样做。

按全部报告计算，确认比例是 8/23，约 35%；只看能够核查的报告，则是 8/17，约 47%。作者把后者叫作「存活率」（survival rate），即真实问题数除以已核查问题数。

这个指标回答的是：交到人手里的报告，到底有多少经得起检查。

但 47% 也不能单独看。那 6 个未核查问题仍然悬着，不能算对，也不能算错；289 条用例只有 71 条实际执行，更不能拿生成数量代替执行覆盖。

测试工具节省的时间，要扣掉团队审核误报花掉的时间。

AI 最擅长找矛盾，最容易猜错业务

最有代表性的真实问题，是密码长度规则不一致。

注册页面写着至少 8 个字符，表单和 API 也都执行 8 个字符的限制。但输入 7 个字符，错误信息却是 Password must be minimal 6 characters long.。作者检查源码后发现，旧的数字 6 留在单独的翻译文件里。

这种缺陷适合 Agent：它不必理解复杂业务，只需要发现同一条规则在不同位置说法不同。对前端团队，这也是一个很具体的提醒：页面说明、校验逻辑、接口约束和国际化文案，可能各自正确过，却没有一起更新。

另一类收获来自异常入口。空购物车直接访问 /checkout，步骤条下面没有内容，也没有返回指引，控制台出现 Cannot read properties of null (reading 'cart_items')。输错商品 URL，则只看到「Related products」标题，没有找不到商品的提示。

人工熟悉正常购买路线，容易沿着它反复检查。没有脚本指引的 Agent 会频繁走偏，偶尔恰好走到用户也会遇到的坏状态。

它还发现了保修期显示为 2years 和 2 years 的差异、忘记密码提交后没有任何反馈，以及「Show differences only」仍保留所有商品都相同的行。这些问题不严重，但确实影响使用。

误报则集中在需要业务背景的地方。Agent 用 1111-1111-1111-1111 和虚构礼品卡付款，被接受后标成严重漏洞；但 Toolshop 没有支付处理器，这是演示系统的预期行为。假邮编返回虚构街道，也是类似情况。

环保折扣的误报更典型。真实规则是购物车中超过一半的商品具有 A 或 B 的 CO₂ 评级，才享受 5% 折扣。Agent 的购物车不满足条件，却判断折扣从不生效。网站没有公开这条规则，它就自行补了一条，再据此宣布系统有错。

此外，联系表单提交后消失、订单确认只显示发票号、分类页没有首页的价格筛选，都被作者归为设计选择。还有一条称空注册表单只显示 12 个错误中的 10 个，人工复查时 12 个都在，未能复现。

作者随后让 Agent 把页面、流程和规则存进人可以阅读、修改的知识库。方向合理，但原文没有给出修改后误报下降的数据。

289 条测试，不等于 289 份有效覆盖

Toolshop 有 17 个页面，289 条测试平均每页 17 条，数字看起来很充足。作者读完才发现，不少用例只是用不同路线重复同一段旅程。

原因在于按页面生成测试。为了检查结账页，用例都要先找到商品、加入购物车、打开购物车。有的走搜索，有的点分类，有的直接访问商品 URL。前置路线各不相同，一条失败后，很难判断其他用例是否也受影响。

业务方真正关心的通常是「顾客能不能完成购买」，而不是某个页面单独能否通过检查。

因此，他们正在改成按用户流程组织：围绕同一条完整旅程生成一组测试，共用一致的跨页面路径。原文举的流程示例是选餐厅、添加商品、付款、看到下单成功，并非这次五金商店实验的新增结果。

这个改造仍在进行，作者明确说还没有数字。能直接借用的方法，是先把 AI 生成的测试按用户旅程归组，再检查重复度，而不是看到 289 就默认覆盖充分。

我的判断

我认同把人工核查结果放在前面。作者公开错误报告，也承认目前工具不能把测试导出成代码，这些信息比单纯展示成功案例更方便团队做取舍。

但这仍是一轮演示应用实验，而且文章讨论的是他们第二次拆解。它没有提供与人工测试、已有 Playwright 或 Cypress 测试套件的对照，也没有统计审核耗时、漏掉多少真实缺陷。因此，它能说明这次报告的可信程度，不能证明整体测试效率更高。

「存活率」也只衡量已报告问题的准确程度。一个工具可以少报几个、只报很确定的问题，得到更高比例，同时漏掉更多缺陷。采购或试用时，还要看它发现了哪些已有手段没发现的问题。

按流程组织测试有助于理解业务结果，但也不能因此取消不同入口的检查。搜索、分类、直接访问本来就可能暴露不同缺陷。更稳妥的取舍是统一重复的前置操作，同时保留有明确目的的路径差异。

可编辑知识库同样需要维护。规则由谁确认、更新后怎样影响测试，原文没说清。这部分目前属于合理方案，效果还需要后续实测。

能拿来做什么

• 在自己的 staging 应用上试用一个发布周期，把每条报告分成真实、错误、无法核查三类，同时记录审核耗时。原文明确建议：会提交表单的 Agent 应使用 staging，不要直接指向生产。
• 给注册、购物车、结账等流程补充关键业务规则，尤其是折扣门槛、演示支付行为和提交后的预期反馈；误报出现后，检查它缺的是规则，还是执行出了问题。
• 把生成用例按用户旅程归组，统计真正覆盖的流程，再改一次按钮名称或移动一个字段，记录需要手动修复多少测试，用实际维护量评估工具。
• 要求真实缺陷报告提供复现步骤、截图和录屏，并确认能否导出测试代码。开发者能否仅凭报告复现，测试资产能否带走，都应进入试用判断。