05 - 测试生成¶
在 AI 编程时代，测试的地位不是下降，而是变成了信任底座。因为当代码生成速度显著提升后，真正限制你交付速度的，往往变成“你敢不敢合并这段代码”。
这章解决什么问题¶
很多人用 AI 生成测试，只停留在：
- 让模型补几段单元测试
- 跑通 happy path
- 看覆盖率数字
这不够。真实项目里更关键的是：
- 测试是否覆盖真正的风险点
- 是否能防回归
- 是否能支撑 AI 生成代码快速迭代
- 是否能沉淀成稳定的验证门禁
所以这一章会把“测试生成”写成 可信交付闭环 的核心部分。
学习目标¶
- 把测试理解成 AI4SE 的验证层，而不是附属品
- 学会用 AI 生成单测、集成测试、回归测试和 golden cases
- 学会判断哪些测试值得补、哪些只是堆覆盖率
- 能把测试资产写进项目和面试表达
为什么 AI 时代更需要测试¶
因为 AI 代码常见问题不是“完全不能跑”，而是：
- 边界处理不完整
- 旧行为被悄悄改掉
- 看起来对，其实只覆盖部分场景
- 改动范围超出预期
这些问题最有效的兜底方式，不是继续问模型，而是测试。
测试的 4 层结构¶
建议把测试固定分成这 4 层看。
| 层级 | 作用 |
|---|---|
| 单元测试 | 验证局部逻辑 |
| 集成测试 | 验证模块交互 |
| 回归测试 | 防止已修问题再次出现 |
| 端到端 / Golden | 验证关键主链路结果 |
AI 最容易补的是前两层，但最能体现工程价值的往往是后两层。
先决定“测什么”，再决定“怎么生成”¶
测试生成的第一步不是写 prompt，而是识别风险点。
一个简单框架¶
每次改动后，先问：
- 哪条主路径最可能出问题
- 哪个边界条件最容易漏
- 哪个旧行为不能被破坏
- 哪个错误之前出现过
这些问题决定了测试优先级。
4 类最值得 AI 生成的测试¶
AI 不是所有测试都适合代写，但下面这几类通常既高频又容易建立验证闭环。
1. 单元测试骨架¶
适合：
- 工具函数
- service 逻辑
- parser / formatter
- 简单算法逻辑
AI 很擅长快速补齐基础测试骨架，但你要自己审查是否覆盖边界。
2. 边界与异常测试¶
这一类比正常 case 更值钱。
例如：
- 空值
- null / None
- 超时
- 无效输入
- 兼容旧参数
这也是 AI 代码最容易遗漏的部分。
3. 回归测试¶
当你修了一个 bug，最有价值的测试往往不是通用单测，而是：
- 一个能稳定复现旧问题的失败 case
- 一个修复后的防回归 case
这是面试里非常能讲价值的内容。
4. Golden / Snapshot / Judge 测试¶
对 AI 应用尤其重要。
例如：
- 固定 query 的检索结果顺序
- 固定 prompt 的结构化输出
- 固定任务的 agent trace
- 关键生成结果的 judge 评分
这类测试能显著提高 AI 系统迭代的稳定性。
最推荐的测试生成流程¶
如果顺序反了，就很容易变成“模型写了很多测试，但没测到真正重要的地方”。
一个高价值模板¶
请为以下改动补测试，但先不要修改生产代码。
任务：
修复 query 为空时 rewrite service 报错的问题
请生成测试，覆盖：
- 正常 query
- 空字符串 query
- None query
- 关闭 rewrite 开关时的 fallback
- 原有默认行为不回归
要求：
- 使用现有测试框架
- 优先补防回归测试
- 如果发现生产代码无法通过这些测试，请指出原因
这个模板比“帮我写测试”稳定得多。
生成测试时最常见的 6 个问题¶
这些问题几乎就是 AI 生成测试时最常见的失真来源，最好提前建立识别习惯。
1. 只测正常路径¶
这是最常见的问题，价值最低。
2. 机械复制函数名¶
模型会写一堆看起来完整、实际上没什么判断力的测试。
3. 断言过弱¶
例如只断言“不报错”或“结果不为 null”，但没有验证行为是否正确。
4. 测试依赖过重¶
引入大量 mock、复杂 fixture，反而降低可维护性。
5. 测试和任务目标脱节¶
比如修的是兼容性问题，结果只补了普通成功 case。
6. 覆盖率数字高，但关键风险没覆盖¶
覆盖率是指标，不是目标。
单测、集成、回归，优先级怎么排¶
如果时间有限，建议按下面顺序：
- 防回归测试
- 关键边界单测
- 关键交互的集成测试
- 再考虑补更多覆盖率
对求职项目来说，这个顺序也更容易讲出价值。
AI 应用和 Agent 系统怎么测¶
这部分和传统业务代码不完全一样。
重点对象¶
- 检索结果
- 工具调用顺序
- 结构化输出
- 降级策略
- token 预算和超时行为
可以补的测试类型¶
- judge-based 评测
- golden query 集
- trace 对齐测试
- tool-use 成功率测试
- fallback 命中测试
如果你想投 AI 应用工程或 AI Coding 岗，这些测试意识很重要。
一个适合 AI 系统的测试分层¶
你不一定一次全做，但至少要知道自己缺哪一层。
测试生成时最应该要求模型输出什么¶
除了测试代码本身，建议要求它同时输出：
- 覆盖了哪些风险点
- 还没覆盖哪些风险点
- 哪些测试是防回归测试
- 哪些测试依赖 mock / fixture
这样你更容易 review。
什么时候应该先写测试，再改代码¶
最推荐的场景：
- 修 bug
- 做兼容性改动
- 做重构
- 调整热点逻辑
因为这些场景最需要“先锁行为，再改实现”。
2028 面试里怎么讲测试能力¶
不要只说：
更好的表达是：
我把测试生成作为 AI 代码交付的验证层。对于 bugfix 和重构，我优先补防回归测试，再补边界和异常测试；对 AI 系统则补 golden cases 和 judge-based 评测，确保改动可验证、可追踪。
这会明显比“会写 pytest”更有层次。
简历怎么写¶
差的写法：
好的写法：
或者：
一个简短的测试 checklist¶
- 是否覆盖了主路径
- 是否覆盖了关键边界
- 是否有防回归 case
- 断言是否足够强
- 是否和任务目标一致
- 是否能在 CI 中稳定运行
本章小结¶
- 测试生成的真正价值，不是补代码量，而是建立信任
- AI 时代最值钱的测试，是回归测试、边界测试和 AI 系统评测集
- 你真正要做的，是把测试纳入持续验证门禁
下一步¶
- 继续看 06-文档生成
- 再回到 07-实战项目，把测试资产纳入项目交付
- 配合 03-代码审查 和 08-AI协作开发方法论 形成完整闭环