这是《落叶》文集里第 114 片落叶，希望你能喜欢，不为别的，只为这份坚持。
测试计划，描述了要进行的测试活动的范围、方法、资源和进度的文档；是对整个信息系统应用软件组装测试和确认测试。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。
很多人在开始制定计划时，都不清楚为什么要做计划，只知道这是流程中的要求，于是拿到模板就开始逐条逐项地去填充。
而且，在不知道为什么要写测试计划的前提下去写，很多东西其实就是为了写而写，写完之后，怎么看都会觉得可读性很差，更别说是否有很高的可行性了。
长此以往，很多人就会把制定测试计划看做一个填充模板的行为，测试计划这个东西就会变成一种固化的流程形式了，反而失去了它本身应起的作用。
所以，我们在写测试计划前，首先应该先明确一件事情，就是我们为什么要制定计划？
制定计划就是为了让项目管理者和项目团队对接下来的前进路线达成一致的认知。
我理解的项目计划制定，其实也不需要模板化，更不需要多么“完美”。甚至于我们可以把制定计划当成通关游戏那样去玩：
1、识别项目范围，再如上图一样，画一条可以从起点抵达终点的路线；
2、站在起点的地理位置和时间位置上，根据已知的信息，在能看的比较清晰的距离点上标注一个里程碑（蓝色圆圈）；
3、再假设自己已经站在第一个里程碑的地理位置和时间位置上，往前标注出下一个里程碑，但这个时候，你因为所掌握的信息不足，很多东西都是基于假设的条件，没关系，标注一个大概的距离即可，以此类推，标注出剩余的所有里程碑点；
4、识别风险，并把可能会遇到风险的位置标识出来（问号）；
5、为第一段路线制定详细的计划，因为行走这段路线所需的信息比较充足和真实可靠；
6、行走路上的每一天，都可以根据实时掌握的信息动态而调整前进的方向和步伐；
7、当走到第一个里程碑的时候，这时候看下一个里程碑会比站在起点的时候要清晰很多，根据最新掌握到的信息和相关环境因素的变化，再适时地制定前往下一个里程碑的详细计划；
8、以此类推，边走边调整计划，遇到风险就去应对，直到通关；
从上述“游戏通关”式的步骤上来看，这种制定计划和执行计划的方式比较易于制定和实际执行。从我个人经验角度来看，可以解决几个传统项目计划中的弊端：
1、需要花费大量的时间和精力去制定一套近乎“完美”的项目计划；
2、项目经理在执行时常常会为了遵循既定的计划，而牺牲一部分灵活应变的优势；
3、可能会基于不够充分和不够实时的信息，制定出部分无用的计划，甚至于错误的计划，当项目进行到某一个里程碑时，因为项目环境因素的变化，而导致既定的后续计划需要大幅修改甚至推翻重来，造成前期工作的浪费；
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
