AI Agent执行测试用例的完整方法：从计划到证据链闭环

引言：写出测试文字 ≠ 完成测试

B站UP主奇遇AI在一期实战演示中，抛出了一个直击AI测试痛点的观点：AI能写出测试文字，并不等于它完成了测试。

真正有价值的，不是屏幕上最终出现一个绿色的"通过"，而是每一个结论都能回溯到具体的请求、数据库变化和清理记录。换句话说——结论必须落到证据上。

这套方法并非纸上谈兵。作者在公司真实项目里从零搭建、反复校准，并将其重新设计成一个可以独立运行的"语聊房"公开演示项目，完整走了一遍从资料准备、计划制定到执行验证的全过程。本文将梳理这条完整链路，看AI Agent如何从"自由发挥"转变为"按清单执行、用证据说话"。

搭建工作目录：锁定AI Agent的上下文边界

很多人复刻AI测试时，第一反应是准备一大段精心设计的提示语（Prompt）。但作者强调，最先要准备的不是提示语，而是一个清晰的工作目录。

这个目录需要把需求文档、接口说明、后端代码、表结构、测试账号、准备数据和结果保存规则，全部放在同一个上下文里。目录就是这次执行的边界——脚本是执行入口，结果也会回到这个目录。当所有依据都在一个上下文中，后续的动作才容易"浮现"出来。

一个关键的安全设计是：测试账号只给只读权限。 数据库观察器（Observer）只能通过预设的只读查询来观察数据，避免执行过程中产生任何无关改动。这样既能验证结果，又不会污染环境。

作者也给出了两种使用建议：短期试用只需准备一个压缩包，解压后让Codex打开项目目录即可；长期迭代则更适合固定工作目录，让上下文持续沉淀。

拆分18条可验证Case：覆盖五大风险场景

执行级别被明确锁定为18条Case，而不是让AI Agent自由发挥。这18条覆盖了五大类风险场景：

• 正常与边界：验证合法兑换业务能否成立
• 非法输入：验证错误输入是否被正确拦截
• 鉴权与权限：验证身份边界是否清晰
• 余额校验：验证余额检查是否生效
• 重放（幂等性）：验证同一请求重复提交是否会重复扣减
• 数据隔离：验证不同用户之间数据是否串号

每一条Case都对应一个具体风险。Runner只按这份清单执行，不临时加Case，也不凭印象修改预期结果。

这种分组的好处在于，每一类失败都有对应的观察重点：正常场景看业务闭环，异常场景看副作用，权限场景看身份边界，重放场景看幂等性，隔离场景看数据是否串到别人。先固定问题，结果才有明确的边界。

作者特别提醒，文件之间不是平行堆在一起的，而是各有职责分工：接口文档给出对外契约，路由把请求接进来，参数模型负责拒绝非法输入，Service决定业务变化，SQL说明数据落在哪些表，Observer只负责受控读取。职责分开后，出现不一致时才能判断问题到底属于输入层还是数据层。

每条Case当作一次有记录的实验

作者提出了一个精妙的比喻：一条Case可以看成一次有记录的实验。 完整的执行链路固定为五个步骤：

1. 保存 db_before（发请求前的数据库状态）
2. 发出真实请求
3. 保存 db_after（发请求后的数据库状态）
4. 做断言，写evidence（证据）
5. 执行cleanup（清理）

这样一来，接口响应、数据库变化和清理结果就被放在了同一条链路上。每个Case都能回答同一组问题：请求发了什么？服务返回什么？数据库前后变了什么？清理之后是否回到起点？只看其中一层，结论都不完整。

执行前的基线也被明确固定：贡献值1650，积分1000，订单和两类流水都是0。后面每条Case都从这个可复现的基线开始。

Dry Run与Approval：AI Agent不能自己开跑

正式执行前，必须先经过Dry Run（空跑）。Dry Run只检查计划，不调用真实业务接口，作用是先把执行范围和风险暴露出来。

这里体现了一个重要的控制原则：AI不能自己开跑。 作者先核对范围、权限和清理要求，确认没问题后才生成一个有时效的Approval（批准），锁住本轮允许做什么。消息发出后，Runner才按批准范围进入这18条Case。

这种设计把"批准范围"和"实际动作"分开核对，Runner启动前页面不会提前显示任何"通过"结果。计划文件不能代替执行证据——这是贯穿全程的铁律。

用三条代表性Case验证证据链

执行完成后，先看整轮结果：总数、通过/失败分类、evidence数量、cleanup状态。但总结果只说明这轮是否完整结束，不能代替具体证据。 作者挑出三条代表性Case逐一验证。

正常兑换：三层证据缺一不可

输入条件、接口响应和数据库前后状态必须互相对应。即使接口返回200，如果没有对应的数据库变化，也不能证明业务完整成功。贡献值减少多少、积分增加多少、订单和流水各出现几条，都应该能从业务规则推出，并与实际查询结果逐项对上。只要有一项不一致，就不能归类为成功。

非法输入：拒绝必须发生在写入之前

作者故意传入小数10.5来测试。这里遵循同一原则：先确认服务拒绝了什么，再确认拒绝发生在业务写入之前，最后用数据库前后状态证明没有留下"半条记录"。

错误提示和无副作用要同时成立，失败才算"干净"。 数据库前后完全不变，没有扣余额、加积分、建订单或写流水。

重放测试：验证幂等性

同一个requestId连续提交两次。第一次replay标记为false，第二次应被识别为重复请求，replay标记为true，且两次返回同一个订单号（订单号不预先写死）。重放验证的核心是：同一个requestId只产生一次业务变化，第二次请求可以返回已处理标记，但绝不能再次扣减余额，数据库变化也只能出现一次。

Cleanup Verify：最后一道门禁

测试跑完还不能结束。Cleanup Verify要确认贡献值、积分回到基线，订单和两类流水归零。 关键在于，清理不是把页面上的数字改回去，而是重新读取真实基线，确认账户、订单和流水都回到可复用状态。

作者一针见血地指出：能执行只是第一步，能复原才让下一轮测试有可信的起点。 下一轮测试能否成立，完全取决于这里是否干净。

总结：可追溯的证据链才是AI测试的核心价值

这一期跑通了完整闭环，从资料准备到最终环境复原。所有的机器记录都保留事实，摘要只负责快速定位——如果需要追查某个结论从何而来，就沿着索引回到具体文件，而不是指着页面上的一句总结。

作者透露，项目里的testing skills已经开源免费，TM和QA都能复用并会持续更新。后续还将推出更复杂的群聊链路测试，以及无文档的JS逆向探索skill——配合抓包和前端JS还原真实接口、参数和调用顺序，最终让AI完成接口编排。

对于正在探索AI Agent测试的团队来说，这套"结论必须落到证据上"的方法论，或许比任何华丽的自动化Demo都更值得借鉴。