《AI Coding 工程化：从个人提效到组织升级》第 14 期
这个系列主要聊 AI Coding 怎样从个人工具进入团队研发流程。本期承接上一期的测试场景设计，继续往下讲：用例确定以后，Coding Agent 怎样把测试真正跑完。
上一期聊的是另一个问题：Harness 和 CI 都跑完了，为什么联调时仍然会漏场景？解决的是测试题目有没有出全。
题目确定以后，事情还没结束。
代码写完，开发人员要找符合条件的账号、准备数据、执行测试。报错了，再去日志平台翻记录，查数据库状态，对着代码找原因，修改以后重新跑一遍。
如果这些工作还全部靠人，AI Coding 只是把编码这一段提速了。后面的验证链条没有接起来，开发人员照样要在几个系统之间来回切换。
这也是我们后来继续补的一段流程：造数、测试执行、问题定位和 Bugfix，都由 Coding Agent 顺着同一个任务往下做。代码写出来还不算结束，它至少要先拿出一份可以检查的测试结果。
测试报错以后，Agent 怎么自己查下去
拿一个接口改动里经常碰到的场景来说。
Coding Agent 完成了一个新的业务分支，也生成了对应测试。执行时，接口没有返回预期结果，或者调用下游直接报错。
以前开发人员会先看测试输出，再打开日志平台搜索调用链，必要时查一下数据库，最后回到代码里判断是分支条件、接口字段还是数据状态有问题。
现在这些动作可以沿着同一个测试任务继续执行：
- Coding Agent 读取失败用例、请求参数和预期结果；
- 调用日志查询 Skill，找到本次请求对应的错误和上下游返回；
- 查询测试库，确认本地数据有没有落下、当前状态是否正确；
- 结合接口定义和代码链路定位问题，修改以后重新执行原用例。
比如日志里出现字段类型转换错误，数据库中的本地记录又是正常的，问题通常就要继续往接口契约和映射代码里找。字段名、类型或返回结构对不上，Agent 修改对应代码，再用同一组数据回归。
还有一种更直接：表结构已经改了，测试环境却没有执行变更 SQL。日志报“字段不存在”时，Agent 应该先核对数据库结构和迁移记录，而不是继续修改业务代码。确认以后，在测试环境补执行变更，再重新验证。
闭环的重点不在于多调用几个工具。Agent 必须拿着同一个测试目标往下走，知道刚才验证了什么、看到了什么证据、为什么要改这段代码，以及修改后该重跑哪个 Case。
先把测试数据准备好，后面才有资格谈自动化
测试闭环最先卡住的，往往不是测试脚本，而是数据。
有些 Case 需要特定状态的账号，有些需要一笔走到中间节点的业务单据。数据不满足条件，分支永远跑不进去，AI 很容易把“数据没准备好”误判成“代码写错了”。
在实际测试里，我们常用的造数方式主要有两种：一种是直接在本系统的隔离测试库里插入或修改数据；另一种是调用现有测试工具，模拟业务请求，让数据沿着业务链路生成。
具体选哪一种，不做一刀切，主要看哪种更方便，也更不容易造错。
如果改动只在一个系统内，数据涉及两三张熟悉的表，关系也简单，Coding Agent 可以直接在隔离的测试库里插入或修改数据。
一旦涉及上下游，就更适合调用测试工具，通过模拟业务请求来造数。开发人员未必有上下游数据库权限，即使有权限，也不一定理解对方的表结构和业务关系。直接改表，很可能造出一条数据库里存在、业务上却根本不成立的数据。
还有一些场景会关联十几张表，带着状态、时间和前后依赖。此时直接插库看起来快，实际上最容易把测试卡在错误数据上。成熟的造数工具已经知道业务链路应该怎么走，让 Agent 调用它，比重新理解十几张表更可靠。
这里讨论的直接插库，只限隔离测试环境。生产数据、敏感数据和高风险写操作，仍然要由现有权限、审计和审批机制控制，不能因为执行者换成 AI 就放开边界。
测试闭环里，至少要接住四类能力
从前面的过程往回看，一套能真正跑起来的测试闭环，需要四类能力配合。
第一类是测试执行能力。Coding Agent 能按已经评审的用例调用接口、脚本或现有自动化测试，并拿到结构化结果。
第二类是测试数据能力。简单数据可以操作本系统测试库，复杂数据调用企业已有的造数工具，避免每次临时拼 SQL。
第三类是问题证据能力。日志、数据库、接口返回和代码版本要能关联到同一次执行。Agent 按需查询，而不是让人把几万行日志复制回对话。
第四类是修复与回归能力。定位到代码或项目配置问题后，Agent 修改代码，重新完成自检，并只重跑受影响的 Case 和必要回归。
Claude Code、OpenAI Codex、Cursor 等 Coding Agent 都可以通过 Skills、脚本或工具接口接入这些能力。真正需要企业自己建设的，是内部日志、数据库、测试平台和业务造数工具怎样以安全、稳定的方式被调用。
AI 接走测试执行，人仍然要判断测得对不对
测试闭环自动化以后，测试人员并没有从流程里消失。我们目前把两件事分得比较开：AI 负责执行和取证，人负责审核用例与结果。
测试用例要人工审核。预期结果是否正确，主流程、异常分支和回归范围有没有覆盖，不能只由写代码的 Agent 自己决定。
测试结果也要有人看。尤其主流程，我们目前仍会人工跑一遍，确认真实业务行为和页面表现符合预期。
人工暂时不能完全退出，在涉及页面和客户端交互的 E2E 测试里体现得最明显。复杂页面交互让 AI 执行，常常耗时长、Token 消耗高，而且容易受页面状态、等待时间和环境波动影响。以现阶段的效果看，很多场景人工测试反而更快、更稳定。
所以这套闭环不是为了证明“以后不需要测试人员”。它先接走那些重复、可执行、可以用证据判断结果的工作。人把精力放在用例设计、结果审核、主流程体验和自动化暂时覆盖不了的场景上。
以后端上测试能力继续改善，人机分工还会变化。但流程不能建立在未来可能出现的能力上，先按当前最可靠的方式交付。
写在最后
在我们的实践里，造数、测试、查问题和 Bugfix 每个环节都减少了人工操作。端上 E2E 还没有完全自动化，测试用例、测试结果和主流程也仍然由人把关，但开发人员不必再为每一次失败重复搬日志、查数据、改代码和回归。
这才是测试闭环对 AI Coding 的意义：代码生成以后，Coding Agent 还能继续往下走，直到给出一份可以被人检查的测试结果。
