测试计划

标签：关注   方式   实现   切换   同步   时间比较   无法   停止   fir   

测试计划（Testing plan）的定义：

描述了要进行的测试活动的范围、方法、资源和进度的文档；
是对整个信息系统应用软件组装测试和确认测试。
它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。
测试计划可以有效预防计划的风险，保障计划的顺利实施。

测试计划的目的

（1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。
（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。
（3）开发有效的测试模型，能正确地验证正在开发的软件系统。
（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。
（5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。
（6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。

编写测试计划，就是为了达到这些目的。

通过测试计划可以宏观的指导测试的后续工作

测试计划由谁编写

测试计划属于管理型文档，是由测试经理、测试主管或测试组长进行编写。

测试计划编写的6个要素

1）why——为什么要进行这些测试；
2) what—测试哪些方面，不同阶段的工作内容；
3) when—测试不同阶段的起止时间；
4) where—相应文档，缺陷的存放位置，测试环境等；
5) who—项目有关人员组成，安排哪些测试人员进行测试
6) how—如何去做，使用哪些测试工具以及测试方法进行测试。

上图主要说明了制定测试计划的相关步骤，下面就着重说明测试计划的主要内容。

测试计划主要内容

第1章 引言

1.1项目背景和目的

本次是关于健身房管理后台三期项目的测试计划，主要功能包括登录、会员卡信息导入、会员信息导入、私教课和特色课的预约课程限制、潜客管理、签到等管理后台以及APP端的功能测试计划。根据项目情况，安排测试阶段周期2周完成3轮测试工作、人员目前配备的是两个测试人员，在两周内结束测试，达到上线测试标准。三期结束之后可以比较完整的交付用户正式试用管理系统。

1.2参考资料

1.3名词解释

本测试计划中涉及以下名词，解释如下：

1.4测试摘要

管理后台V3期主要涉及的是管理后台的会员卡的绑定、会员导入、会员卡导入等操作，需要重点关注，APP学员的会员信息和管理后台同步；目前的支付方式中只使用次卡、储值卡、期限卡支付；而微信和银行卡支付目前暂不支持，所以此流程暂时不通。

1.4.1 重点事项

1. 会员信息导入
2. 会员卡信息导入
3. 会员卡绑定
4. 后台控制用户的课提前预约私教和特色课课程数
5. ....

1.4.2 争议事项

简要说明争议事项。

1.4.3 风险评估

目前开发排期时间比较赶，导致测试时间不充分；因项目原因无法延期，所以需要侧重点进行管理后台的测试，APP的测试可根据实际情况适当延期。其二：目前后台管理系统没有进行性能和压力测试，在后期用户数据量猛增可能会导致系统瘫痪的风险；其三：目前测试机型不充分，基本没有进行兼容性测试；在用户试用阶段，建议试用目前已经验证的常规机型和常用浏览器FirFox或chrome浏览器等。

1.4.4 时间进度

简要说明测试开始时间与发布时间。

1.4.5 测试目标

测试发布的质量目标：

测试计划中所有测试方法和模块已经执行通过

所有的测试案例已经执行过

所有的重要等级为中、严重、非常严重的Bug已经解决并由测试验证

第2章 项目背景

2.1测试范围

目前三期项目的主要功能参考如下：

本次测试计划主要涵盖的测试范围：管理后台V3期和APP以及微信小程序，其中管理端的优先级最高，需要优先上线、其后是APP和小程序。目前涉及的测试方法主要包括接口测试、功能测试、集成测试、系统测试和验收测试；其中接口和整体功能测试、验收测试是目前测试的重点，具体参考原型和需求说明书。

2.2测试目标

2.3联系方式

列出项目参与人员的职务、姓名、E-mail 和电话。

2.4风险及约束

风险和制约因素：

1. 需求变更更新延迟，导致开发延期
2. dev和beta环境经常崩溃，导致开发和测试浪费工作时间
3. 测试人员不足，可能导致测试不充分，需要增加人员等

2.5测试文档

测试过程中可能用到的参考文档、概要设计设计文档、详细设计文档以及保存位置，测试应产生测试用例、测试报告等文档。

2.5.1测试参考文档

2.5.2测试提交文档

第3章质量目标

本次需要完成三期后台的开发，该期结束之后，用户可以正式切换进入系统进行试用，APP和后台以及小程序是一个完整的闭环。 需求中提出的功能已完成且测试通过，在线上系统可以正常稳定运行。

3.1产品质量目标

用户正式试用，环境稳定运行无异常。

第4章 资源需求

4.1培训资料

4.2测试环境

4.2.1硬件测试环境

服务器配置

客户端配置

4.2.2软件测试环境

4.3测试工具

此项目将列出测试使用的工具以及用途：

第5章 测试策略

5.1 整体测试策略

使用里程碑技术在测试过程中验证每个模块，测试人员在需求评审阶段参与测试工作，进行需求review、设计review、测试案例设计和测试开发。在系统开发完成之后，开发自测完成，正式进入执行测试阶段。产品达到软件产品质量要求和测试要求后发布，并提交相关测试文档。

5.2开始/中断/完成标准

说明中断/开始/完成测试的标准。

5.3测试类型

5.4 测试技术

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

第6章 测试计划

6.1进度计划

主要包括里程碑计划，包括阶段、里程碑、资源等。

6.1.1测试时间进度

6.1.2测试里程碑

6.2测试准备

6.2.1 测试环境准备

6.2.2 安装测试

6.2.3 冒烟测试

6.3 具体测试实施任务和时间人员安排

以上是测试计划实际情况中的一个文档输出，那么我们如何才能输出这样文档呢？

根据文档内容要求，我们需要确定测试目标、测试范围和测试策略，以及根据测试范围和测试策略进行测试时间、人力等资源的安排等这几个重点。

那么如何确定测试目标呢？

测试目标是有质量目标来确定的，而质量目标则从以下三个维度来说明

1. 产品的商业价值：是质量第一还是快速上线
2. 根据项目铁三角原则：确定是快速上线还是0bug上线
3. 根据线上项目事故率：这个也是测试绩效考核的一个点，线上无P0和P1的事故

根据以上3点确定测试计划的测试目标。

如何确立测试范围呢？

一般情况下，测试范围是根据需求文档和原型综合评判得出测试计划的测试范围，这里一般情况下建议使用思维导图进行需求分析，这里主要有需求优先级、、需求的关联功能、识别测试重点等确定测试范围，得出测试的关键功能、主要功能、强关联功能 、次要功能、弱关联功能等。

确定测试策略

整体测试策略

1. 业务和技术深度掌握：深挖业务场景，掌握业务相关的接口
2. 多样化的测试策略：主要有业务场景、交互，UI，兼容性，数据逻辑，业务逻辑，性能测试等多角度进行分析测试
3. 组内组外的充分沟通：在敏捷开发中显得更加重要

版本测试策略

1. 针对不同功能和优先级采用不同的测试策略：P1优先级的功能则需要用例的详细设计，充分考虑用户的实际使用场景，覆盖功能的各种细节和异常情况，在第一轮测试完成之后，P1的第二轮则一般是进行探索性测试，确定所涉及的场景基本都被覆盖。针对P2优先级的功能则需要用例的详细设计，覆盖用户的各种实际使用场景，一般在第一轮测试完成之后，不需要第二轮的探索测试。而对于P3功能一般是直接进行测试要点的编写，进行探索性测试即可。P4的功能一般是直接根据需求文档进行测试。当然如果产品的商业价值可能不同的需求的优先级则有所不同，需要实际项目实际操作。
2. 交叉抽测和回归测试

如何制定工期、人员安排、进度安排

工期的评定

1. 出卡牌的方式
2. 头脑风暴

人员安排

1. 需要考虑任务的关联度和重要程度
2. 人员工作量分布

进度安排

1. 提测时间安排
2. 一般使用甘特图进行进度安排
3. 根据功能的优先级和重点以及人员的工作量情况，排定进度表

里程碑进度安排

根据上面的进度安排制定的甘特图，可能会出现颗粒度太细，无法一目了然了解项目进度情况，所以这个时候就需要里程碑，通过里程碑，划分里程碑的进度。可以根据不同的模块相对大小划分里程碑，这里需要注意要加入测试前期的测试用例编写的时间安排以及测试回归时所消耗的时间。

其他影响

1. 研发计划
2. 风险处理：需要根据风险的历史库和预先识别的风险制定风险策略
3. 研发流程：如果说项目质量要求比较高，我们可能还需要制定冒烟测试计划、单元测试、集成测试等

通过上面的测试计划内容以及如何制定测试计划的详细说明，相信你可以根据项目情况制定一份确实可行的测试计划啦，马上行动起来吧......

测试计划

标签：关注   方式   实现   切换   同步   时间比较   无法   停止   fir   

原文地址：https://www.cnblogs.com/LOVEYU/p/10976776.html