7.11 测试理论（6）

测试理论（6）

测试计划

定义及目的

⼀个叙述了预定的测试活动的范围、途径、资源及进度安排的⽂档。它确认了 测试项、被测特征、测试任务、⼈员安排以及任何偶发事件的⻛险。测试计划包含了产品概述、测试区域/测试范围（测试项）、 测试⽬标（被测特征）、测试优先级、测试配置/测试 资源<硬件、软件、人力、技术等>、测试周期、进度安排（测试任务、⼈员安排）、 测试策略、测试⽅法/途径、 测试交流、⻛险分析、测试标准、需交付⽂档等内容。

测试范围

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

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

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

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

以邮箱为例:

 

测试技术手段：

1、自动化测试

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

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

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

测试策略：

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

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

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

资源安排：

两个维度：

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

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

进度安排：

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

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

发布标准：往往是主观的，大家都是认可的

风险控制：

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

依赖方清单

 

 

测试计划注意的事项：

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

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

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

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

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

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

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

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

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

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

测试计划细节

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

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

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

3、管理层再看测试计划过程中会关注是否合理，主要还是资源和时间 需要向管理层强调的点：

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

（2）依赖⽅的管理，和第⼀个⻛险在⼀起进⾏管理

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

测试计划实战

以以下项目为例，三人用时12天，性能测试用时两天。

顺序：兼容性测试/系统测试/性能测试（三者可以并行）

每人每天都有事干

 

eg：