6.1 测试策略，而不只是测试类型

测试不是“把单元测试、集成测试、系统测试这些名词背下来”。真正的测试策略要回答一个更工程化的问题：

这个系统最可能以什么方式伤害用户、业务或团队？我们应该用什么证据，在什么层级，尽早发现它？

从风险开始

一个支付功能和一个头像预览功能都可以写单元测试、集成测试和端到端测试，但它们的风险完全不同。支付功能最怕重复扣款、金额单位错误、超时后状态不一致；头像预览可能更关注体验、兼容性和上传失败提示。

因此测试策略应先列出风险：

• 业务规则是否可能算错？
• 模块之间的接口是否可能理解不一致？
• 用户关键路径是否可能中断？
• 数据是否可能丢失、泄露或无法恢复？
• 变更是否可能破坏已有行为？

测试层级是工具箱

单元测试反馈最快，适合检查纯逻辑、边界值和异常分支。集成测试检查模块、数据库、消息队列、第三方 API 之间的契约。系统测试检查关键路径是否能串起来。验收测试和探索测试帮助确认系统是否真的满足人的工作方式。

成熟策略不是“越高层越真实，所以全做端到端”。高层测试更接近真实使用，但通常更慢、更脆弱，也更难定位失败原因。低层测试更快，但不能证明整个流程能跑通。

好的组合通常像金字塔：大量低层快速反馈，适量集成契约测试，少量关键端到端路径，再加上针对体验和未知风险的探索。

回归测试是团队记忆

回归测试不是为了证明代码完美，而是为了防止团队重复踩同一个坑。当线上缺陷被修复后，应该留下一个能再次抓住它的测试。这样 bug 不只是被修掉，还被转化成系统记忆。

测试策略最终应该能说清楚：

• 哪些风险由自动化测试覆盖？
• 哪些风险必须通过评审、演练或人工验收覆盖？
• 哪些测试必须在每次提交运行？
• 哪些测试可以在合并前、夜间或发布前运行？
• 测试失败时，团队能多快定位原因？

测试的价值不是数量，而是让重要坏消息更早、更便宜、更准确地出现。