测试策略与测试金字塔
一、测试策略：测什么、测多少、谁测
测试策略是在项目或产品层面，对测试范围、深度、分工和投入的规划。三个核心问题：测什么——功能、边界、非功能（性能、安全）、回归范围；测多少——关键路径必保、次要功能抽样、风险高的加码；谁测——开发自测与单测、QA 负责场景与回归、自动化由谁写谁维护。策略不必写成长篇大论，但要有明确约定：哪些必须自动化、哪些可以手工、发布前至少要过哪些检查。
二、测试金字塔：单元多、集成适中、E2E 少
测试金字塔（第 17 章已介绍）从策略上强调比例：底层单元测试数量最多——快、稳、便宜，覆盖逻辑细节；中间集成测试适量——测模块/服务协作、真实依赖；顶层E2E数量少——测完整用户场景，慢且脆弱但能验证「端到端通」。这样既能快速反馈（单测秒级）、又能验证连接（集成）、还能保关键路径（E2E），同时控制维护成本和执行时间。反模式是「倒金字塔」：大量 E2E、很少单测，结果慢、脆、难定位问题。
数量多；每次提交跑；覆盖逻辑与边界
数量适中；接口与数据流；可每日或每 PR 跑
数量少；关键用户路径；发布前或关键节点跑
三、自动化与手工测试的划分
自动化测试由脚本执行、可重复、适合回归和 CI。单元、大部分集成、核心 E2E 都应自动化，保证每次提交或每日构建都能跑一遍。手工测试适合探索性测试、一次性验证、UI 或业务快速变化尚未稳定的场景。划分原则：重复执行、稳定场景→ 自动化；探索、一次性的、尚未定型→ 先手工，稳定后再考虑自动化。自动化要有明确负责人（谁写、谁修），否则坏了没人管会逐渐失效。
适合自动化
- 回归：每次发布都要跑的用例
- 稳定接口与逻辑：单测、集成、核心 E2E
- CI 中每次提交或每日跑的检查
- 明确预期、可断言的场景
适合手工（或后补自动化）
- 探索性测试、新功能首次验证
- UI/流程尚未稳定、变更频繁
- 一次性或低频的检查
- 难以自动断言（如「看起来正常」）的场景
四、测试与质量内建
质量内建（Build Quality In）指把质量活动嵌入开发流程，而不是事后「测一轮」。测试策略与金字塔就是内建的一部分：单测随代码写、PR 通过才合并、CI 跑不过不发布、关键 E2E 在发布门禁里。这样「质量」不是 QA 阶段才管，而是每个提交、每次合并都在验证。策略上要约定：哪些测试是门禁（必须过）、哪些是预警（失败要查但不挡发布）、谁负责修、多长时间内修，避免测试沦为摆设。
一句话： 测试策略回答测什么、测多少、谁测；测试金字塔要求单元多、集成适中、E2E 少，兼顾反馈速度与端到端保障。自动化用于重复与稳定场景，手工用于探索与未定型场景；自动化要有明确维护责任。质量内建：测试进 CI、门禁与预警分清、每个提交与合并都在验证质量。
五、小结
测试策略明确测什么、测多少、谁测，并在项目内达成一致。测试金字塔：单元多（快、便宜）、集成适中、E2E 少（关键路径），避免倒金字塔。自动化覆盖回归与稳定场景，手工负责探索与未定型部分；自动化需明确维护人。质量内建：测试进 CI、门禁清晰、质量随每次提交与合并验证。下一章讲集成测试与端到端测试，把集成与 E2E 的写法、环境与稳定性说细。