相信大多数的软件测试工程师都听说过或者简单了解过测试计划，但是你真的知道什么是测试计划么？你真的知道如何编写测试计划么？大多数人应该是一脸茫然。百度的结果五花八门，有没有相对规范的标准呢？答案是没有，至少我没有找到。那么今天我就结合经验和对一些国内技术前沿的公司跟大家聊一聊什么是测试计划以及如何编写测试计划。
计划的必要性：
在我们日常的工作和生活中，经常需要做计划。古人云：凡事预则立，不预则废（《礼记.中庸》），也就是强调预先计划的重要性和必要性。
我们做项目，项目需要定项目计划；测试作为项目中的一部分，当然也需要制定测试计划。
一个测试计划制定者的素养：
有多年从事测试工作的经验，能够条例清晰的罗列出测试中的流程和应当留心的步骤，以及不可缺少的风险规避的意识对于部门的员工能力要有一定程度的了解，才能合理的安排工作内容高压下的冷静处理能力，一旦项目出现突发的严重问题，能够冷静找出出错环节。人际沟通的能力，一个测试计划也是有与其他部门之间的合作关系，需要与其保持及时有效的沟通，了解到他们的需求 那么我们什么时候来做测试计划呢？
一般来说，在产品需求确认，做过测试需求分析之后我们就要开始编写测试计划。当然测试计划编写的工作要根据工作实际来决定，也就是具体情况具体分析（政治课学的哈~）
其实，要想做好测试计划必须有一定的测试经验。那么下面我就结合工作实际，跟大家聊一聊测试计划的内容。
测试计划的内容：
测试范围 明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？
测试策略 明确怎么测？对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。
资源安排 包括测试人员的安排，测试环境是怎样的，测试工具的选择等。
进度安排 在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。
发布标准 发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？
风险预防 最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。
我们把这些内容模板化，形成测试计划的模板。无论是在实际的工作中还是大家学习编写测试计划，都可以用这样的模板来使用。
在此模板的基础上，我们一点点来剖析如何编写测试计划。
这里的参考资料可以有：（可行性分析报告、软件需求定义、软件系统分析、软件概要设计、软件详细设计、软件测试需求、硬件可行性分析报告、硬件需求分析、硬件概要设计、硬件原理图设计、硬件结构设计、硬件测试需求、模块开发手册、测试时间表及人员安排、测试计划、测试方案、测试报告、测试分析报告、用户操作手册、安装指南等）
2 测试范围
测试范围的确定来自于需求文档，依据是项目的交互稿和需求分析结果
2.1功能测试范围的分析
功能点的拆分、接口测试、UI测试
2.2系统测试范围的分析
（1）容错处理
（2）兼容性要求
（3）配置要求
（4）性能要求
（5）安全性要求
（6）可靠性、日志文件
3.测试策略
为了更好确定软件测试策略，可以问如下一些问题：
(1).回归测试的范围如何确定？
(2).如何利用可重复性的测试？
(3).测试缺乏可预见性，如何收集衡量测试结果的指标？
(4).如何建立稳定的、模拟系统实际运行的测试环境？
(5).如何从无穷的输入数据中选择合理的、有效的测试数据集？
(6).如何衡量这份测试策略的有效性？
1、基于测试技术的测试策略
(1).任何情况下都要使用边界值分析方法
(2).等价类划分法是对边界值分析方法的有效补充
(3).如果功能的输入数据/条件存在多种组合情况，则使用因果图
(4).错误推测法
(5).对照程序逻辑来审查已有测试用例的逻辑覆盖程度
(6).白盒测试
2、分阶段的测试策略
(1).严格执行代码审查
(2).单元测试和集成测试，准备自动化测试
(3).系统测试中，以每次发布用户基线为结束标志
(4).不能忽略安全性测试、可用性测试、配置测试和数据完整性测试
(5).在功能测试、安全性测试、配置测试中进行探索性测试
3、基于测试方案的综合测试策略
(1).测试优先级，优先级越高，越早测试，测试力度越大
(2).使用尽可能少的测试用例，发现尽可能多的程序错误
(3).测试策略尽量简单、清晰
(4).基于缺陷分析的测试策略
4、测试资源
测试人力资源包含两个维度：
1、测试人员数量
2、测试人员经验、能力。
环境资源一般包括：
1、测试服务器环境（尽量与线上环境保持一致）
2、终端环境（PC配置，手机型号）
3、测试工具（bug管理工具，用例管理工具，性能测试工具等）
在我们的测试计划中，测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来。
5、进度安排
测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期的上线时间。所以我们需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。
可以用工作分解结构表方法评估工作量：
1、列出本项目需要完成的各项任务
2、细化每个任务，尤其是测试阶段，需要对模块进行拆分，拆分到可衡量和细化的维度
3、预先设计测试点，按照测试点来估算
4、给每个维度估算时间，需要优化和重复操作的部分
5、在已估算结果上浮动10%-15%
6、发布标准
测试完成的标准，也就是说做到什么样算是测试工作做完了。主要包括：
1、测试计划里所有测试类型都已经完成了
2、功能上、兼容性上没有影响用户使用的Bug
3、允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值
4、性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。
在满足了测试本身的前提下，产品要发布还需要满足要求：
1、产品需求都已完成
2、交互视觉走查都已完成
3、一流的小部分Bug项目组完成了风险评估，都认可且问题不大
4、产品使用说明或用户手册或更新log都已完备等等。
7、风险说明
测试风险分类：
1、测试范围的风险，测试遗漏、需求变更；比如说一开始测试需求分析不准确、不到位漏了测试点，甚至某个测试类型遗漏了，这样问题就比较大了，所以测试需求分析是整个测试工作的基础，还有就是产品需求变更的风险，加需求、减需求、改需求都需要重新进行测试需求分析，需要测得一定要测到，不需要测的就不要浪费人力物力和工作量；
2、测试进度的风险，工作量预估不准确、耦合任务延迟、测试人员变动；比如说做计划时工作量估计的不准，测试做着做着发现时间不够导致项目延期，还有测试依赖开发，可能开发工作没有按时完成或改bug不及时导致进度延后，还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动；
3、产品质量的风险，代码质量、测试人员能力；比如开发的代码质量比较低或者测试人员是新人对业务不熟悉，能力和经验有所欠缺等等。
测试风险的控制方法：
1、根据风险发生的概率和带来的影响确定风险的优先级，然后才去措施避免那些可以避免的风险；
2、风险转移，比如去掉新功能，转移风险；
3、不可避免的风险，就设法降低风险，如提高测试用例的覆盖率；
4、事先做好风险管理计划，喜欢里程碑和验收管理；
5、有一套应急、有效的处理方法，比如全员了解，注意日常观察，及时发现风险出现的征兆；
6、做计划时，要留有余地
7、制定文档标准。
到这里我们就完成了一份测试计划。有的人可能依旧存在疑问：做计划真的有那么重要么？我们实际工作中有很多项目根本就没有计划依旧可以完成的啊！我们来看一下不做计划可能会有哪些问题~
首先，如果没有计划我们无法预估工作量和需要的测试人员数量。一个项目的工作量和需要的人员数量都没有依据，在公司里怎么来协调和安排呢？
其次，测试人员的分工明确，会导致工作重复和遗漏。出了问题大家可能都觉得不是自己的问题，导致工作混乱效率低下。
再就是测试进度失控。到底什么时候做完没有一个预期，其他的团队怎么安排工作呢？进度有没有失控也没有判断依据，临到预计的上线时间才发现还有很多没有测到、没测完，直接影响整个项目的进行。
还有就是应对需求变更困难，对可能出现的风险没有准备。一旦出现问题，大家一片混乱，很容易导致测试遗漏和项目延期。
最后就是没有统一发布标准，上线意见不一致。测试团队认为Bug太多不能上线，开发团队认为都是小Bug不要紧，先上线再说，导致争执不下的局面。、
当然根据项目不同还可能存在其他一些列问题…
总而言之，测试计划的作用非常重要。
做测试计划对测试人员的能力和要求是非常高的，从另一个角度来说，测试计划可以体现一个测试人员的自我修养。一个测试人员需要很好的经验沉淀、有很多好的全局意识才能做好一个项目的测试计划。
希望大家都能够很好的胜任编写测试计划这项工作。