【测试沉思录】8. 测试计划应该怎么做？

欢迎订阅我的新专栏《现代命令行工具指南》，精讲目前最流行的开源命令行工具，大大提升你的工作效率。

作者：闫嘉欣编辑：毕小烦

敏捷项目的特点是需求变化快、项目周期短。传统的极致详尽的测试计划已经不符合敏捷的项目了，因此需要简化，需求精准，需要自动，需要更加注重团队沟通，需要拥抱变化。

本文介绍了我们对测试计划的一点思考和实践。

1. 一定要有测试计划

测试计划是指导测试过程的纲领性文件。是为了达成一定时期内的目标，进行的任务规划和行动步骤设计。

说人话就是，你打算做什么？怎么做？谁来做？用多少时间？有什么风险？怎么规避？等等，这就是测试计划。

为什么要做测试计划？

当然是不打无准备之仗。

如果你了解 PDCA，这个 P 对于我们测试来讲就是测试计划。

当我们接手一个项目的测试时，要知道项目要做什么？目标是什么？要理清楚需求的优先级、开发是谁、何时提测、依赖什么、影响什么、有无风险，要盘一盘工作量、资源、分工、节奏、标准、策略等。

这些都是做测试计划。

可能你也遇到过这样的问题：

开发前期提测的功能较少，临近发布，才批量提测，导致来不及测试…
待测功能依赖外部团队的一个新接口，但新接口什么时候给出来没有明确的时间，然后就导致一直等待，阻断进度。
当我们正在「开心」的测试，突然来了个需求变更，打断了工作节奏，不知道怎么调整。
正在努力测试，突然团队中有一个人请假，然后就乱了节奏。
…

这些问题的主要原因就是没有做好计划。有了计划，才能有节奏，才能不乱，即使出现计划外的事情，也能按计划进行合理的调整，逐步找回节奏。

所以一定得做计划。

2. 测试计划应该怎么做？

2.1 原则：一次制定，持续优化。

测试计划不可能面面俱到，项目也不可能一成不变，需求变更、提测延期、依赖延期、有人请假等等情况都会不可避免的发生，因此，计划要先有一个基线，然后根据这个基线，按突发情况导致的时间/风险进行合理调整。

计划的调整可以遵循以下的 4 个原则：

需求宣讲中未能最终确定下来的内容，确定后，需要更新测试计划；
对已有计划会产生明显影响的变更，需要更新测试计划；
对质量目标有明显影响的变更，需要更新测试计划；
小的改动，经评估对原计划无影响时，无需更新测试计划；

2.2 内容：需求、资源和质量。

测试计划主要关注：需求、资源和质量。即在有限的时间内，用有限的资源，完成所提的产品需求，达到一定的质量目标。

要完成哪些产品需求，要达到什么样的质量目标，怎么去分配这有限的时间和资源，就成了计划的关键。

由此可以拆解出更多需要关注的信息：

2.3 注意：评估风险、评审计划

评估风险

提到风险评估，大家会觉得这个词并不陌生，但如果真正要对一个项目做风险评估，很多人会觉得无从下手，因为我们要考虑的是还未发生的事情。

如果不知道从何下手，不妨先试试把各式各样的风险分个类。然后按照时间线，来想一想在项目的不同阶段，我们可能会遇到哪些问题。

如下表所示：
风险类型****举例需求类风险需求描述不够清晰、导致功能越做越多需求变更对原有用户影响较大有没有识别到性能等非功能性需求…设计类风险实现方式是否能使用正确的方法测试改动的影响范围大不大…流程类风险提测时间与测试规划是否冲突外部团队的支持是否及时…资源类风险项目组人员请假测试硬件资源不足…历史类风险曾经踩过了哪些坑，目前是否有类似场景…
风险评估模板
风险来源风险等级影响范围应对策略

评审计划

测试计划评审，是一个公开的，接受每个角色检验的，能够从不视角查漏补缺的机会，一定要抓住这样的机会。

可现在的项目，往往会议比较多，产品需求要评审、视觉/交互/技术设计要评审、测试计划要评审、测试用例要评审…

那测试计划应该怎么评审？

我们比较认同的评审方式可以分为两种：

常规迭代可以不用大范围组织评审的，只要确保信息互通，确保你的测试策略是对应的开发认可的，就足够了。因为人员稳定、测试阶段固定，大部分迭代的测试计划内容都是通用的，只重点分析测试策略和风险即可，只要保障测试人员了解开发的设计和重点难点，能够针对性的产出较为规范的测试策略，就没有什么太大的问题。
而对于较为重大的迭代，有多个团队参与，涉及外部交互的，这种迭代是一定要组织测试计划评审的。不仅要把你的测试计划同步给其他团队，也要能了解其他团队的测试安排，这样更有利于大家达成质量上的共识，也更容易在测试时间和测试阶段上保持一致，以防后期大家进度不一致，互相掣肘。