软件测试基础（三）--测试计划

一、测试计划定义

定义：⼀个叙述了预定的测试活动的范围、途径、资源以及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排以及任何偶发事件的风险。

二、测试计划内容

1、测试范围

明确测什么？测试的边界，也就是说本次迭代（2周）测试需要干的具体的事，测试范围里面需要明确的指出这么几点：

A、本次新迭代需要测试的内容 

B、本次迭代是否需要测试性能测试 

C、本次迭代是否需要系统之前的功能，如果测试，时间是多少？(系统已有功能是每个迭代必须要进行测试的，但是不会给太多的测试时间)。

2、测试策略

明确怎么测？在测试范围清晰的定义测试的边界之后，那么测试团队需要考虑的是使用什么样的测试策略来进行测试，也就是说通过什么样的解决思路以及测试技术，能够在有限的资源上完成产品的交付。

测试技术手段：

a、自动化测试

b、精准测试（开发修改了哪些代码，测试这边很准确的知道修改了哪些代码，以及自动化的验证这些被修改的代码）

c、流量回放（把线上所有的请求在线下执行）

d、混沌工程（Netfix和阿里巴巴）(通过科学试验的手段技术来模拟生产环境中出现故障后的技术解决方案)

测试类型：

以拉钩网为例，如何在有限的时间里将拉勾网里的内容测试完：

a、职位有无限个，但是职位有类型，并且每个职位的类型有核心的关键字

b、针对不同条件的匹配。选择有代表性的数据进行测试

标签系统： 西安 未央区 女性 18-25 未结婚

3、资源安排

两个维度：

a、人力资源（已经清晰的知道测试的边界以及测试的范围，思考的是通过几个人，以及多少天来完成这件事）

b、硬件资源（在测试的过程中是否需要服务器，如果没有服务器，那么就需要采购）

4、进度安排

a、针对测试的边界（范围），会把任务拆分成很多的story。

b、给每个story完成任务的具体时间范围，需要精确到小时（每个任务具体开始的时间和结束的时间）。

5、发布标准

往往是主观的，大家都是认可的。

6、风险控制

在测试计划里面，关于风险控制，不是非必要的，但是是必须考虑的，所以说的测试风险，指的是事实上大家可见的风险，不能主观意愿强加的风险以及凭自己的猜想强加的风险

以新浪邮箱为例：

三、测试计划注意的事项

1、针对本次迭代需要测试的对象，任务必须要拆分，而且拆分后的任务都是可独立的测试

2、针对分配给你的story（任务），测试时间由自己规划

3、一般测试计划是每个人去梳理，最后将测试计划进行整合

4、风险控制方面如果存在，需要列的非常详细，以及针对每个风险控制的点，需要给出具体的跟踪人，以及负责人

A、没有服务器，运维工程师

B、你负责测试的模块依赖于别人（自己造数据测试）

C、关于风险，如果涉及到自己，一定要把风险反馈出来，不能由着开发的意思来，也不能说自己能够解决

5、你负责的任务由于太大，分配了另外一个测试和你共同来测试这部分，对于任务的分配你会怎么处理：

A、让你的负责人和对方的负责人，明确任务的边界

B、每天早上反馈的时候，反馈下任务进度，各自反馈各自的任务进度

四、编写测试计划

以“车主小程序一期”项目为例：

编写测试计划如下：

1、测试概述

2、测试任务

3、风险控制

依赖方清单：

五、编写测试计划注意的细节

测试计划编写完成后，其实管理层更多关心的主要有如下几点，具体为：

1、是否可以在计划的时间内测试完成，达到可以上线的目标；

2、测试资源是否不需要增加，如果增加，解决方案是什么？（特别注意，如果需要增加，需要反馈给项目经理和测试经理，进行测试资源的协调）

3、管理层再看测试计划过程中会关注是否合理，主要还有资源和时间。

需要向管理层强调的点：

1、测试风险，这个存在⼀定得强调出来，以及针对测试风险解决的方案是什么？如果不能解决，会带来什么样的影响，需要协调什么资源？

2、依赖方的管理，和第⼀个风险在⼀起进行管理；

3、测试质量标准，以及上线的标准和测试的要求。