第2章测试计划制定

2、测试计划制定：需求分析、测试范围界定、测试策略选择、测试资源评估、测试进度安排

大家好，我是老张。今天咱们聊聊测试计划怎么定。

很多人觉得测试计划就是写个文档，走个过场。我告诉你，真不是这样。一份好的测试计划，是整个测试工作的“作战地图”。没有它，你就是在黑夜里瞎摸。

我见过太多项目，测试做到一半才发现漏了关键功能，或者资源不够用。说白了，都是计划没做好。今天我就把压箱底的经验掏出来，跟你聊聊这五个核心步骤。

需求分析是第一步，也是最容易被忽视的一步。我个人的习惯是，拿到需求文档后，先不急着写用例。我会先问自己三个问题：

举个例子。我之前做过一个电商后台系统。需求文档上写的是“支持商品批量导入”。看起来很简单对吧？但我仔细一分析，发现事情没那么简单。

“批量导入”背后，其实藏着好几个子需求：

你看，如果不做需求分析，直接上手测“导入”，你很可能只测了最顺利的那条路径。一旦用户上传了格式错误的文件，系统直接崩溃了，那可就麻烦了。

我的小技巧： 需求分析时，我习惯用思维导图把功能点拆开。一个功能拆成3-5个子功能，再往下拆。拆到不能再拆为止。这样测试范围就清晰了。

测试范围界定，说白了就是划边界。你想想看，一个系统功能那么多，你不可能全都测一遍。时间、人力、预算都有限。

我遇到过最头疼的情况，就是项目经理说“所有功能都要测”。这其实是不负责任的说法。真正专业的做法是：

我曾经在一个项目中，客户坚持要测所有历史版本的功能。我直接告诉他：“测可以，但工期要延长一倍，预算要翻番。” 最后客户自己放弃了。为什么？因为那些功能已经稳定运行了三年，从来没出过问题。

注意： 界定范围不是偷懒。而是把有限的资源用在刀刃上。一定要和项目经理、产品经理达成共识，并签字确认。否则后期扯皮，吃亏的是测试。

测试策略，就是决定你怎么测。是手工测还是自动化测？是黑盒测还是白盒测？是冒烟测试还是回归测试？

我个人习惯，会根据项目特点来选：

举个例子。我之前测过一个支付接口。我选择了自动化测试 + 压力测试。为什么？因为支付接口逻辑固定，但并发量巨大。手工测一次要5分钟，自动化5秒钟就跑完了。而且压力测试能发现系统在1000人同时支付时会不会挂掉。

    核心原则： 测试策略没有银弹。适合的才是最好的。别盲目追求自动化，也别死守手工测试。

资源评估，就是算账。你需要多少人？多少台机器？多少时间？

我一般会从三个维度来评估：

嗯，这里要注意。资源评估时，千万别拍脑袋。我见过有人直接说“这个项目需要5个人测2周”。问他为什么，他说“感觉”。这哪行？

我自己的方法是：先估算用例数。比如一个功能有100个用例，一个测试人员一天能执行30个，那一个人就需要3.3天。再考虑写用例、环境搭建、报告编写的时间，最后乘以一个1.2的系数。这样算出来的结果，才靠谱。

避坑指南： 我曾经因为低估了环境搭建的时间，导致测试延期了3天。后来我学乖了，每次评估资源时，都会单独列一项“环境准备时间”，至少占整个周期的10%。

进度安排，就是把测试工作拆成一个个可执行的任务。我习惯用甘特图来管理。

一个典型的测试进度安排，大概长这样：

你可能会问：“老张，进度安排这么细，万一有变动怎么办？”

问得好。我的做法是：每周一早上开个15分钟的站会，看看进度有没有偏差。如果有，及时调整。比如某个模块bug太多，测试时间不够了，那就从其他模块调人支援。或者跟项目经理商量，砍掉一些非核心的测试项。

    记住： 进度安排不是死的。它是活的。你要像开车一样，随时微调方向盘，但大方向不能偏。

好了，关于测试计划制定的五个步骤，我就聊这么多。总结一下：

下一章，我会聊聊测试用例设计。那可是个技术活，咱们到时候见。