1.2-测试计划

测试计划的内容

1.测试范围
明确测什么？比如：产品的具体业务需求有哪些？产品是web端的还是移动端的，还是两者都有？

2.测试策略
明确怎么测。对不同业务需求，具体要有哪些测试类型、测试场景、测试方法。

3.资源安排（资源安排：测试：开发=1：4 进度安排：开发时间的50%）
包括测试人员的安排，测试环境是怎样的，测试工具的选择等。

4.进度安排
在明确测试范围、方法和人员之后，我们要考虑什么时候开始测试，预计要测试多久？以便和开发计划、上线计划衔接。

5.发布标准
发布标准是测试完成和产品上线需要满足的条件，以便项目内所有角色都有一致认可的目标。怎样才算是测完了？达到怎样的标准才可以上线？

6.风险预防
最后，我们需要对整个测试过程中可能存在的风险，以及当这些风险发生时的应对措施提前进行一些考虑和准备，并在测试计划中体现出来。

我们一点点来剖析如何编写测试计划：

首先我们的依据是项目的交互稿和需求分析结果
交互稿：功能分析结果：

1.明确测试范围

测试范围的确定来自于需求文档，比如本次需求的目标：要求用户可以成功参加课程。我们功能测试需求分析的结果为用户成功参加课程，涉及到浏览课程、参加课程、学习课程三个模块。

然后考虑兼容性测试、性能测试这些测试类型。我们把我们分析的结果填充到模板中的测试范围这一节中，明确需要测试的也无需求和需要测试的测试类型。
2.测试策略

我们要根据不同的测试类型考虑不同的测试方法。
对于功能测试，我们根据需求分析的思维导图和功能测试的测试用例覆盖浏览课程、参加课程、学习课程三个模块就可以了；
兼容性测试，我们要根据产品的应用场景来考虑，比如IE、Chorme、ios、android、不同机型等等；
性能测试，根据产品架构、预估数据、线上数据来判断需要执行性能测试的功能接口（比如登录接口）；
接口测试，安全性测试等等要根据实际的项目需求来确定。

然后我们将需要用到的测试类型按照测试场景、测试方法等以引用文件的形式填写到测试计划中去，以便让所有项目人员清楚的知道要做哪些测试工作以及怎么做。

3.考虑测试人员的分工和测试资源的分配

比如说，测试人员数量不够或能力不够的时候，就要额外申请测试人员。
测试资源我们一般包括两方面：测试人力资源和测试环境资源。测试人力资源包含两个维度：测试人员数量和测试人员经验、能力。环境资源一般包括：

在我们的测试计划中，测试人员分配、测试环境资源、网络资源、工具使用都要明确写出来。

4.测试进度安排

测试工作的进度安排依赖于开发工作的节点和提交测试进度的时间，并且直接影响预期的上线时间。所以我们需要根据产品业务的复杂度、所需要进行的不同的测试类型的复杂度、产品上线的质量要求的高低、测试人员的数量、能力和经验这些因素，来评估不同阶段、不同类型的测试工作的工作量。比如冒烟测试的工作量、大概有几轮回归测试以及工作量、性能测试的工作量等等。然后对测试人员的分工进行安排，明确职责；那些人进行功能测试、谁来负责性能测试。最终来预估测试工作开始和结束的时间节点，比如预计什么时候可以开始性能测试；预计什么时候完成第二轮回归测试之类。在整个测试过程中，测试团队需要输出的文档也都需要列明，比如测试计划、功能测试用例、性能测试方案、bug数据、性能测试数据、测试报告等

在我们携程XXX项目的例子里，大家可以清晰地看到进度安排的详细情况。

5.发布标准
在测试工作中也需要有标准或一致的目标，来判断测试阶段是否可以结束、产品是否可以上线。这个标准或者目标一般来说包含两个方面：一是测试工作完成的标准，二是产品可以上线发布的标准。这两个目标既相互有关系，但又不完全相同，两者都需要在项目团队内达成一致和共识。

测试完成是产品发布的前提，但产品上线前还有其他一些需要完成的工作，如下：

①首先是测试完成的标准，也就是说做到什么样算是测试工作做完了。
主要包括：
1、测试计划里所有测试类型都已经完成了
2、功能上、兼容性上没有影响用户使用的Bug
3、允许遗留小部分影响不是很大的Bug，但这个数量应该小于一个值
4、性能上符合设计目标和上线要求 这些标准都是针对测试工作本身的要求。

②在满足了测试本身的前提下，产品要发布还需要满足如下要求
1、产品需求都已完成
2、交互视觉走查都已完成
3、一流的小部分Bug项目组完成了风险评估，都认可且问题不大
4、产品使用说明或用户手册或更新log都已完备等。

在我们携程的例子里，测试完成标准和上限标准有如下：

6.风险预防
测试工作很少有计划是完全可以顺顺利利执行完的，计划本身也需要更新维护。所以我们要对测试过程和产品质量可能会发生的一些问题和风险做好应对准备，避免问题真的发生后出现连锁反应，影响整个测试和项目工作。

测试风险一般包含这样几类：
一是测试范围的风险，比如说一开始测试需求分析不准确、不到位漏了测试点，甚至某个测试类型遗漏了，这样问题就比较大了，所以测试需求分析是整个测试工作的基础，还有就是产品需求变更的风险，加需求、减需求、改需求都需要重新进行测试需求分析，需要测得一定要测到，不需要测的就不要浪费人力物力和工作量；
二是测试进度的风险，比如说做计划时工作量估计的不准，测试做着做着发现时间不够导致项目延期，还有测试依赖开发，可能开发工作没有按时完成或改bug不及时导致进度延后，还有可能测试人员因为别的项目更重要抽调走了或者请假、离职等原因造成人员变动；
三是产品质量的风险，比如开发的代码质量比较低或者测试人员是新人对业务不熟悉，能力和经验有所欠缺等等。

在携程某项目的例子中，列举了一些可能遇到的风险：

不做计划可能会有哪些问题：

首先，如果没有计划我们无法预估工作量和需要的测试人员数量。一个项目的工作量和需要的人员数量都没有依据，在公司里怎么来协调和安排呢？

其次，测试人员的分工明确，会导致工作重复和遗漏。出了问题大家可能都觉得不是自己的问题，导致工作混乱效率低下。

再就是测试进度失控。到底什么时候做完没有一个预期，其他的团队怎么安排工作呢？进度有没有失控也没有判断依据，临到预计的上线时间才发现还有很多没有测到、没测完，直接影响整个项目的进行。

还有就是应对需求变更困难，对可能出现的风险没有准备。一旦出现问题，大家一片混乱，很容易导致测试遗漏和项目延期。

最后就是没有统一发布标准，上线意见不一致。测试团队认为Bug太多不能上线，开发团队认为都是小Bug不要紧，先上线再说，导致争执不下的局面。

总而言之，测试计划的作用非常重要：指导测试过程，协调项目安排，提高测试效率，提高测试质量

非原创参考了如下链接有删改：https://www.cnblogs.com/finer/p/9170490.html