标签：测试计划 需要 迭代 day6 被测 任务 测试 软件测试

一.测试计划

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

1.1测试计划内容

包含了产品概述、测试区域/测试范围（测试项）、 测试⽬标（被测 特征）、测试优先级、测试配置/测试资源<硬件、软件、⼈⼒、技术等>、测 试周期、进度安排（测试任务、⼈员安排）、 测试策略、测试⽅法/途径、测试交流、⻛险分析、测试标准、需交付⽂档等内容。

2.测试范围

指的边界，2周一个迭代所需干的事情，

1a.需要明确本次新迭代需要测试的内容，

b.本次新迭代是否需要测试性能测试，

c.本次迭代是否需要测试系统之前的功能，如果需要时间是多久（系统已有功能是需要测试的，但是不会给很多时间）

3.测试技术手段

a.自动化测试

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

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

d.混沌工程（netfix和阿里巴巴

4.测试策略

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

a、职位有无限个，但是职位有类型，并且每个职位的类型有核心的关键字b、针对不同条件的匹配。选择有代表性的数据进行测试

5.资源安排

两个维度：人力资源（已经清晰的知道测试的边界以及测试的范围，思考的是通过几个人，以及多少天来完成这件事），硬件资源（在测试的过程中是否需要服务器，如果没有服务器，那么就需要采购）

6.进度安排

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

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

7.风险预防

最后，我们需要对整个测试过程中可能存在的⻛险，以及当这些⻛险发⽣时的应对措施提前进⾏⼀些考虑和准备，并在测试计划中体现出来（有就写，基于客观事实）

1.2测试计划的具体内容：

测试范围：

1)、测试对象:描述被测对象：如果被测对象的发布特性随版本不同⽽不同，需要明确对象版本。对于不属于测

试范围的对象，也应该在此进⾏描述

2)、测试需要的特性:说明所有需要测试的对象的特性以及特性组合。前端、移动端、后端、⼩程序各个系统功

能

3)、不需要测试的特性，如这地⽅以邮箱测试为案例来进⾏描述不需要的测试，具体为：

 

 1.3测试计划需要注意的事项

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

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

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

4）、风险控制方面如果存在，需要列的非常详细，以及针对每个风险控制的点，需要给出具体的跟踪人，以及负责人 A、没有服务器，运维工程师 B、你负责测试的模块依赖于别人（自己造数据测试） C、关于风险，如果涉及到自己，一定要把风险反馈出来，不能由着开发的意思来，也不能说自己能够解决

5）、你负责的任务由于太大，分配了另外一个测试和你共同来测试这部分 A、你的负责人和对方的负责人，明确任务的边界 B、每天早上反馈的时候，反馈下任务进度，各自反馈各自的

1.4测试计划的编写

兼容性测试1人1天/系统测试全部人参与测/性能测试，可以并行但是按照此顺序

 

 

 

标签：测试计划,需要,迭代,day6,被测,任务,测试,软件测试
来源： https://www.cnblogs.com/zxx4/p/16466984.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。