📚 课程目录第3章测试计划制定

3. 测试计划制定：范围界定、资源分配、时间规划

测试计划这东西，说白了就是一张作战地图。我刚做验证那会儿，拿到需求文档就急着写测试用例，结果呢？测到一半发现漏了关键功能，又得回头补环境、加设备，项目差点延期。嗯，从那以后我才明白——计划没做好，后面全是坑。

这一章，我会拿实际项目踩过的坑，跟你聊聊怎么把“范围”“资源”“时间”这三件事定稳。你想想看，要是这三个角都没站住，整个验证流程能靠谱吗？

很多团队一上来就“全量测试”，结果资源根本扛不住。我个人习惯是先画一个测试范围矩阵，把“测什么”“不测什么”“边界在哪”写死。怎么画？三步走：

功能边界：对照需求文档，列出所有功能点，标注P0/P1/P2优先级。P0是死线，漏了就是验收不通过。
数据边界：参数取值范围、等价类、边界值。我记得有一次测一个温度传感器接口，数值范围是-40℃到125℃，我们只测了常温段，结果低温下数据全飘了……后来我在计划里加上“极端值必测”。
环境边界：哪些操作系统、浏览器、硬件版本需要覆盖？哪些明确排除？比如客户只用Chrome 90+，那IE就不测，但不能省略“不测项”的说明。

小技巧： 用一张“范围剪裁表”把需求、版本、排除项列成清单，评审时大家现场签字确认。这招能挡住80%的后期扯皮。

资源不是“有多少用多少”，而是算出来怎么配最划算。我建议按这四个维度打表：

举个例子。我之前带过一个车载项目，资源表里“人”这一列只写了3个人名，结果2个要支援另一个紧急项目。我赶紧把测试范围砍掉低优先级30%的功能，换成环境自动化回归覆盖。虽然有点痛，但核心功能守住了。资源不是越多越好，而是要对齐优先级。

注意： 千万别把“人天”当唯一计量单位。同一个人写脚本和手动执行，效率差3倍以上。资源分配里要体现技能差异，否则算出来全是假账。

时间规划最忌“倒排工期拍脑袋”。我习惯用阶段门禁制：把整个验证周期切成几个大阶段，每个阶段末尾设一个“门禁检查点”。通过才能往下走，不通过就回头补。这样做的好处是——问题早发现，成本少一半。

常见的阶段划分：

准备期（T0~T1）：环境搭建、数据准备、脚本框架搭建。这个阶段我一般留20%的余量，因为环境问题总是比想象多。
执行期（T1~T2）：按优先级分批执行用例。建议第一周只跑P0，验证核心流程是否通。
回归期（T2~T3）：修Bug后全量回归。这里最容易爆时间——我曾经因为一个低频Bug修了3天，回归跑了2天，差点赶不上交付。后来我规定：回归期最多占用整体计划的15%，超了就上浮范围例外。
验收期（T3~T4）：客户/第三方验收。只做冒烟和关键场景，不做新用例。

说到余量，我们一般是在每个阶段后面加上10%~15%的缓冲。有人觉得这是“浪费”，其实它是最后的救命稻草。你想想看，要是遇到测试环境挂了、关键人员请假、需求临时变更，没余量你只能跪。

我见过不少团队，计划书做得跟砖头一样厚，结果从来不看。有意义吗？没有。计划是用来指导执行和应对变化的。我自己的做法是：每两天花10分钟，对照计划表看一看进度偏差，小于10%就正常过，超过15%就要启动纠偏措施——加资源、减范围、调顺序，总要选一个。

  我的经验： 测试计划最好用可追踪的电子表格或看板，不要用Word定死。需求一变更，直接在计划表里删改，同时留下变更记录。这样到复盘时，每一刀都能说清楚为什么砍。

说一千道一万，计划的价值不是那张纸，而是你思考过所有可能出问题的地方，并且提前留好了路。嗯，这一章就到这儿，你自己动手理一理手上的项目，试试能不能用这三个维度拆开看看。