第二章：测试策略制定
说实话，很多团队做测试，上来就闷头写用例。结果呢？测了一堆无关紧要的功能，核心风险点反而漏了。我见过太多次这种悲剧了。
测试策略，说白了就是回答三个问题：测什么？怎么测？测多少？ 今天我就把这几年的实战经验掰开揉碎了讲给你听。
2.1 基于产品规格与用户场景的测试策略
我个人习惯，拿到一个产品，先不看代码。先看什么？看产品规格书和用户场景文档。
产品规格告诉你「这东西应该能做什么」，用户场景告诉你「用户实际会怎么用」。这两者往往有差距。我在项目中遇到过，规格书写着「支持1000并发」，但用户场景分析下来，实际峰值只有200并发。那测试重点就应该放在200并发下的稳定性，而不是死磕1000并发。
具体怎么做？我一般分三步：
- 拆解规格：把每个功能点列出来，标注优先级（P0/P1/P2）
- 还原场景：用户的操作路径是什么？异常情况有哪些？
- 交叉映射：把场景和规格对应起来，找出覆盖盲区
核心原则：测试策略不是功能的罗列，而是用户行为的模拟。你想想看，用户不会按着你的功能列表去操作，他们只会按自己的习惯来。
2.2 风险导向的测试优先级划分
资源永远是有限的。你不可能把所有测试都做一遍。那怎么办？用风险来排优先级。
我常用的方法叫「风险矩阵法」。很简单，两个维度：发生概率和影响程度。
| 影响程度 | 高概率 | 中概率 | 低概率 |
|---|---|---|---|
| 严重 | P0（必须测） | P0（必须测） | P1（重点测） |
| 中等 | P1（重点测） | P1（重点测） | P2（可选测） |
| 轻微 | P2（可选测） | P2（可选测） | P3（不测） |
举个例子。支付模块的金额计算错误，影响程度是「严重」，发生概率是「中」。那它就是P0，必须优先测。而某个设置页面的文案错误，影响程度是「轻微」，概率再高也只是P2。
注意：我曾经犯过一个错——把所有功能都标成P0。结果团队累死累活，核心问题还是漏了。后来我学乖了：P0的用例数，不要超过总用例的20%。
优先级定下来之后，测试顺序也就清楚了：
- 第一轮：P0用例，冒烟测试+核心功能验证
- 第二轮：P1用例，边界条件+异常场景
- 第三轮：P2用例，兼容性+性能摸底
2.3 测试覆盖率的定义与度量
覆盖率这东西，很多人理解偏了。以为覆盖率越高越好。其实不是。覆盖率是工具，不是目标。
我见过一个团队，代码覆盖率做到了95%，但线上还是出了大问题。为什么？因为他们只测了「快乐路径」，异常分支根本没走到。覆盖率数字好看，但质量一塌糊涂。
常用的覆盖率指标，我列一下：
| 类型 | 定义 | 我的建议 |
|---|---|---|
| 行覆盖率 | 代码行被执行的比例 | 目标80%以上，但别盲目追求100% |
| 分支覆盖率 | if/else等分支被覆盖的比例 | 这个更重要，建议85%以上 |
| 函数覆盖率 | 函数被调用的比例 | 100%是基本要求 |
| 需求覆盖率 | 需求点被测试覆盖的比例 | 这个才是核心，必须100% |
嗯，这里要注意：不要只看代码覆盖率，更要看需求覆盖率。代码覆盖率再高，需求没覆盖到，等于白测。
我的习惯：每次测试结束后，我会生成两份报告。一份是代码覆盖率报告，给开发看。一份是需求覆盖率报告，给产品看。两边都对得上，我才敢说「测试完成了」。
2.4 知识体系总览
说了这么多，我画了一张图，帮你把整个测试策略的知识体系串起来。你一看就明白了。
这张图把整个测试策略的核心逻辑串起来了。你从中心出发，沿着三个方向展开，每个方向都有具体的落地方法。做测试策略的时候，对着这张图过一遍，基本不会漏。
最后说一句：测试策略不是写出来就完事的文档。它需要动态调整。项目进行中，风险变了，优先级就得跟着变。我见过太多团队，策略写完了就束之高阁，结果测到一半发现方向错了。记住：策略是活的，不是死的。
公众号:蓝海资料掘金营，微信deep3321