第三章 测试计划制定：测试计划的核心要素、测试范围与风险评估、测试资源与时间估算、编写测试计划文档
说实话，很多刚入行的测试同学觉得写测试计划是浪费时间。
「直接上手测不就完了？」——我以前也这么想。
直到有一次，我负责一个电商大促项目。没写计划，直接开测。结果呢？第三天发现测试环境跟生产环境差了三个版本，第五天发现核心支付流程没人覆盖，第七天老板问「什么时候能测完」——我答不上来。
嗯，那次之后，我再也不敢跳过测试计划了。
3.1 测试计划的核心要素
一份合格的测试计划，说白了就是回答五个问题：
- 测什么 —— 测试范围
- 不测什么 —— 排除项
- 怎么测 —— 测试策略
- 谁来做 —— 资源分配
- 什么时候做完 —— 时间线
我个人的习惯是，先列一个「测试计划五要素清单」，贴在项目文档最前面：
| 要素 | 说明 | 常见坑点 |
|---|---|---|
| 测试目标 | 本次测试要达成什么 | 目标写得太虚，比如「保证质量」 |
| 测试范围 | 哪些功能/模块要测 | 漏掉边界场景 |
| 测试策略 | 用什么方法、什么工具 | 策略跟项目脱节 |
| 资源计划 | 人、环境、数据 | 低估了环境搭建时间 |
| 进度安排 | 各阶段时间节点 | 没有预留缓冲期 |
我的小技巧： 每次写计划前，先找开发负责人聊15分钟。问问他们「你觉得最可能出问题的地方在哪？」——往往能提前发现很多盲区。
3.2 测试范围与风险评估
测试范围这块，我见过最典型的错误就是「什么都想测」。
你想想看，一个项目几十个模块，几百个接口，几千条用例——人力有限，时间有限。全测？不现实。
所以，核心思路是：先划范围，再排优先级。
3.2.1 怎么划范围？
我一般用「三圈法」：
- 内圈：本次迭代新增/修改的功能 —— 必须测
- 中圈：受影响的老功能 —— 回归测
- 外圈：完全没改动的模块 —— 冒烟测或不测
举个例子。有一次我们改了一个支付网关的接口参数。内圈是支付接口本身，中圈是订单流程、退款流程，外圈是商品展示、用户登录——这些基本不受影响，跑个冒烟就行。
3.2.2 风险评估怎么做？
风险评估，说白了就是回答三个问题：
- 哪里容易出问题？ —— 比如新写的代码、复杂的业务逻辑
- 出了问题影响多大？ —— 比如支付失败 vs 页面颜色不对
- 我们能承受多大风险？ —— 这得跟产品经理对齐
我习惯用「风险矩阵」来量化：
| 风险等级 | 发生概率 | 影响程度 | 应对策略 |
|---|---|---|---|
| 高 | 高 | 严重 | 必须测，且要深度测 |
| 中 | 中 | 一般 | 安排常规测试 |
| 低 | 低 | 轻微 | 冒烟测试或延期 |
我曾经踩过的坑： 有一次我觉得某个模块「应该没问题」，就只安排了冒烟测试。结果上线后出了严重bug，回滚花了两个小时。从那以后，我对「应该没问题」这四个字特别警惕。
3.3 测试资源与时间估算
资源估算，很多新手容易犯一个错：只算了「执行测试」的时间。
其实，测试的完整流程包括：
- 环境搭建（1-2天）
- 用例设计（2-3天）
- 用例评审（0.5天）
- 测试执行（看用例量）
- 缺陷回归（预留30%时间）
- 测试报告（0.5天）
我个人习惯用「三点估算法」：
乐观时间：一切顺利，3天
悲观时间：各种问题，7天
最可能时间：正常情况，5天
估算结果 = (乐观 + 4×最可能 + 悲观) / 6
= (3 + 4×5 + 7) / 6
= 5 天然后，我会在这个基础上再加20%的缓冲。为什么？因为总会有意外——环境挂了、需求变了、开发延期了……你想想看，是不是这个理？
3.4 编写测试计划文档
文档怎么写？我见过几十页的测试计划，也见过一页纸的。说实话，不是越长越好。
我的建议是：够用就行。
一份标准的测试计划文档，包含以下章节：
- 概述 —— 项目背景、测试目标（200字以内）
- 测试范围 —— 内圈/中圈/外圈，明确排除项
- 测试策略 —— 功能测试、接口测试、性能测试的安排
- 资源计划 —— 人员、环境、工具、数据
- 进度安排 —— 各阶段时间节点，标注里程碑
- 风险与应对 —— 风险矩阵 + 应急预案
- 交付物 —— 测试用例、测试报告、缺陷清单
嗯，这里要注意： 文档写完后，一定要拉上开发、产品、项目经理一起评审。别自己闷头写完了就发邮件——我吃过这个亏，评审会上被怼得体无完肤。
3.5 本章知识体系
下面这张图，是我自己总结的测试计划制定流程。每次写计划前，我都会看一眼，确保没漏掉什么。
好了，以上就是测试计划制定的核心内容。说白了，就是「想清楚再动手」。别急着开测，先把计划写好——你会发现，后面能省下不少返工的功夫。
公众号:蓝海资料掘金营，微信deep3321