AI 辅助写测试：从用例生成到覆盖率补齐的实战流程

写测试是大多数开发者最想外包、又最不敢外包的工作：用例写少了等于没写，写多了维护成本直线上升。大模型出现之后，写测试第一次有了“先生成、再校验、最后补齐”的可行流程。本文分享一套我在实际项目里跑通的 AI 辅助写测试流程，覆盖单元测试生成、边界用例补齐和覆盖率收尾三个环节。

一、先定规矩：让 AI 在约束里生成

直接把函数贴给 AI 让它“写个测试”，大概率得到一堆能跑但没营养的用例。我的做法是先给 AI 三条硬约束：

1. 只测公开行为，不测内部实现细节，避免重构一改实现测试全挂；
2. 每个用例必须有明确的断言意图，禁止“assertTrue(true)”式的占位断言；
3. 命名按“场景_输入_预期结果”的格式，例如 下单_库存不足_返回错误码。

把这三条写进提示词，再贴上待测函数的签名和业务说明，生成质量会立刻上一个台阶。约束越具体，返工越少。

二、第一步：生成 happy path，再人工过一遍

以一个订单金额计算函数为例，我先让 AI 生成主流程用例：正常下单、满减叠加、优惠券抵扣三类。生成后我只做两件事：

• 跑一遍，删掉重复用例——AI 经常把“满减 100 减 10”和“满减 200 减 20”写成两个用例，其实是一个等价类；
• 核对断言里的数字是否和业务规则一致，金额、税率这类数字 AI 容易“编造”，必须逐个核对。

这一步的目标不是追求数量，而是拿到一套可信的基线用例。基线可信，后面的补齐才有意义。

三、第二步：让 AI 专门找边界和异常

主流程用例稳了之后，换一套提示词，专门让 AI 扮演“找茬的人”：

• 输入边界：空字符串、0、负数、最大值、超长字符串；
• 状态边界：库存刚好为 0、优惠券刚过期、并发下单；
• 异常路径：下游服务超时、数据库写入失败、参数缺失。

我的经验是，把“边界”单独作为一轮对话来做，效果比混在第一轮里好得多。AI 在同一轮里既要覆盖主流程又要想边界，往往两头都做不好。分开之后，边界用例的命中率明显提高，经常能挖出两三个开发时没想到的分支。

四、第三步：用覆盖率报告指挥补齐

跑完测试后看覆盖率报告，重点不是那个百分比数字，而是未覆盖的分支清单。把未覆盖分支的行号和代码贴给 AI，让它只针对这些分支生成用例，一次补一个分支，补完就跑一遍验证。

这里有两个坑要注意：

1. 不要为了数字而补用例。有些防御性代码（比如理论上到不了的 else 分支）硬补用例只会增加维护负担，该接受低覆盖就接受；
2. 每次补完立即运行全量测试，防止新用例破坏已有用例的共享状态，比如共用的数据库夹具。

五、一个可直接套用的提示词模板

待测函数：[函数签名 + 业务说明]
约束：
1. 只测公开行为，不测内部实现；
2. 每个用例有明确断言，禁止占位断言；
3. 命名格式：场景_输入_预期结果。
任务：先生成 5 个主流程用例，覆盖[列出核心场景]；
再单独生成边界与异常用例，覆盖[列出边界点]。
输出：可直接运行的测试代码 + 每个用例一句话说明。

六、效果与注意事项

按这套流程，我在一个中等规模模块上把测试编写时间从约 3 天压到 1 天左右，行覆盖率从 62% 提到 87%。但有三点必须守住：AI 生成的数字断言要人工核对；测试数据里的敏感信息（真实手机号、密钥）绝不能贴进对话；生成代码进仓库前一定要跑一次完整流水线，别只信聊天窗口里的“看起来能跑”。

AI 不会替你对测试质量负责，它只是把“先生成、再校验、最后补齐”的体力活变快了。判断哪些该测、哪些不该测，仍然是开发者的工作。把判断留给人，把体力活交给 AI，这才是 AI 辅助写测试的正确分工。