测试计划（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名词解释
本测试计划中涉及以下名词，解释如下：
| 缩写词或术语 | 英文解释 | 中文解释 |
|---|---|---|
| 验收测试 | 系统开发生命周期方法论的一个阶段，这时相关的用户和／或独立测试人员根据测试计划和结果对系统进行测试和接收 | |
| α测试 | 是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成 | |
| 黑盒测试 | 测试人员不关心程序具体如何实现的一种测试方法 | |
| BUG | 有时称作defect（缺陷）或error（错误），软件程序中存在的编程错误，可能会带来不必要的副作用，软件的功能和特性与设计规格说明书或用户需求不一致的方面 | |
| β测试 | 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成 | |
| .... | .... | .... |
1.4测试摘要
管理后台V3期主要涉及的是管理后台的会员卡的绑定、会员导入、会员卡导入等操作，需要重点关注，APP学员的会员信息和管理后台同步；目前的支付方式中只使用次卡、储值卡、期限卡支付；而微信和银行卡支付目前暂不支持，所以此流程暂时不通。
1.4.1 重点事项
- 会员信息导入
- 会员卡信息导入
- 会员卡绑定
- 后台控制用户的课提前预约私教和特色课课程数
- ....
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 和电话。
| 职务 | 姓名 | 电话 | |
|---|---|---|---|
| IOS/Android开发工程师 | 张三 | zhangsan@qq.com | 156*** |
| 后台开发工程师 | ... | ... | ... |
| 开发经理 | ... | ... | ... |
| 测试负责人 | ... | ... | ... |
| 测试人员 | ... | ... | ... |
2.4风险及约束
风险和制约因素：
- 需求变更更新延迟，导致开发延期
- dev和beta环境经常崩溃，导致开发和测试浪费工作时间
- 测试人员不足，可能导致测试不充分，需要增加人员等
2.5测试文档
测试过程中可能用到的参考文档、概要设计设计文档、详细设计文档以及保存位置，测试应产生测试用例、测试报告等文档。
2.5.1测试参考文档
| 文档说明 | 作者 | 文档位置（CVS） |
|---|---|---|
| 需求规格说明书 | 张** | ... |
| 概要设计 | ... | ... |
| 详细设计 | ... | ... |
| 管理后台使用手册 | ... | ... |
| 管理手册 | ... | ... |
| 测试用例 | ... | ... |
| API文档 | ... | |
| ... | ... | ... |
2.5.2测试提交文档
| 文档说明 | 作者 | 文档位置（CVS） |
|---|---|---|
| 《项目测试计划》 | ||
| 《项目测试方案》（可根据项目情况进行裁剪） | ||
| 测试用例 | ||
| 《性能测试方案（报告）》 | ||
| 《产品操作手册(后台)》 | ||
| 《产品操作手册(前台)》 | ||
| 《产品接口说明》 | ||
| 《产品安装维护手册》 | ||
| 《产品错误代码说明文档》 | ||
| 《产品培训操作文档》 | ||
| ... | ... | ... |
第3章质量目标
本次需要完成三期后台的开发，该期结束之后，用户可以正式切换进入系统进行试用，APP和后台以及小程序是一个完整的闭环。 需求中提出的功能已完成且测试通过，在线上系统可以正常稳定运行。
3.1产品质量目标
用户正式试用，环境稳定运行无异常。
| 测试质量目标 | 确认者（如需说明） |
|---|---|
| 测试已实现的产品UI是否达到设计的要求 | |
| 已实现的功能是否符合产品PO的预期，包括：各个功能点是否以实现，业务流程是否正确 | |
| 所有的测试案例已经执行过 | |
| 每一部分的测试已经被Test Lead确认完成 | |
| 所有的重要等级为的Bug已经解决并由测试验证 | |
| 产品规定的操作和运行稳定 |
第4章 资源需求
4.1培训资料
| 培训需求 | 培训内容 | 培训人员 | 开始时间 | 完成时间 |
|---|---|---|---|---|
| 业务流程 | 管理后台的使用流程 | 张** | ||
| 用户操作说明 | 用户操作手册培训 | |||
4.2测试环境
4.2.1硬件测试环境
服务器配置
| 机型（配置） | IP地址 | 操作系统 | 用途及特殊说明 | 软件及版本 | 预计空间 |
|---|---|---|---|---|---|
| ubuntu01 | *** | ubuntu16 | 服务器 | *** | |
| ubuntu02 | K8S服务 | ||||
| ubuntu03 | docker服务.. | ||||
客户端配置
| 机型（配置） | IP地址 | 操作系统 | 用途及特殊说明 | 软件及版本 | 预计空间 |
|---|---|---|---|---|---|
| ThinkVision、16G内存 | *** | win10企业版 | 客户机 | Chrome74-32位 | |
| 锤子手机 | Android7.0 | ||||
| iPhone7p | IOS10.0 | ||||
4.2.2软件测试环境
| 软件需求 | 用途 |
|---|---|
| mysql数据库 | |
| rabbit | |
| ... | ... |
4.3测试工具
此项目将列出测试使用的工具以及用途：
| 测试工具 | 用途 |
|---|---|
| 自动测试工具：selenium+python | 自动化回归测试 |
| JIRA | bug管理 |
| confluence | 项目管理工具 |
| postman | 接口自动化测试 |
| JMeter | 性能/接口自动化测试 |
| ... | ... |
第5章 测试策略
5.1 整体测试策略
使用里程碑技术在测试过程中验证每个模块，测试人员在需求评审阶段参与测试工作，进行需求review、设计review、测试案例设计和测试开发。在系统开发完成之后，开发自测完成，正式进入执行测试阶段。产品达到软件产品质量要求和测试要求后发布，并提交相关测试文档。
5.2开始/中断/完成标准
说明中断/开始/完成测试的标准。
| 开始/中断/完成测试 | 标准说明 |
|---|---|
| 开始测试标准 | 硬件环境可用且软件正确安装完成 |
| 中断测试标准 | 安装无法正确完成或程序的文档有相当多的失误或系统服务异常或发现Block Bug |
| 完成测试标准 | 完成测试计划中的测试规划并达到程序和测试质量目标,并由Test Lead/R&D Manager确认 |
5.3测试类型
| 测试类型 | 是否采用 | 说明 |
|---|---|---|
| 功能测试 | 采用 | 根据系统需求规格说明书、原型和设计文档，检查产品是否正确实现了功能。 |
| 流程测试 | 采用 | 按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否能够正确处理 |
| 边界值测试 | 采用 | 选择边界数据进行测试，确保系统功能正常，程序无异常。 |
| 容错性测试 | 采用 | 检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息 |
| 异常测试 | 采用 | 检查系统能否处理异常 |
| 启动停止测试 | 采用 | 检查每个模块能否正常启动停止、异常停止后能否正常启动 |
| 安装测试 | 采用 | 检查系统能否正确安装、配置 |
| 易用性测试 | 采用 | 检查系统是否易用友好 |
| 界面测试 | 采用 | 检查界面是否美观合理 |
| 接口测试 | 采用 | 检查系统能否与外部接口正常工作 |
| 配置测试 | 采用 | 检查配置是否合理、配置是否正常 |
| 安全性和访问控制测试 | 采用 | 应用程序级别的安全性：检查Actor只能访问其所属用户类型已被授权访问的那些功能或数据。系统级别的安全性：检查只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。 |
| 兼容性测试 | 需要考虑浏览器的兼容性以及不同手机类型的兼容性(FireFoxchromeQQ浏览器等；华为手机iPhone手机小米vivo等手机) | |
| 回归测试 | 采用 | 检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求 |
| ... | ... | ... |
5.4 测试技术
| 测试技术 | 是否采用 | 说明 |
|---|---|---|
| 里程碑技术 | 采用 | 里程碑的达成标准及验收方法在测试完后制订 |
| 审评测试 | 采用 | 对软件产品功能说明文档和设计说明文档进行检查，在需求与设计阶段进行 |
| 编写测试用例 | 采用 | 在产品编码阶段编写测试用例 |
| 集成测试 | 采用 | 检测模块集成后的系统是否达到需求对业务流程及数据流的处理是否符合标准、系统对业务流处理是否存在逻辑不严谨及错误以及是否存在不合理的标准及要求。 |
| 确认测试 | 采用 | 在产品发布前，对照feature list 进行基本需求的确认，确认产品是否正确实现了功能。 |
| 系统测试 | 采用 | 包括回归测试 |
| 验收测试 | 不采用 | 由工程实施人员进行 |
| ... | ... | ... |
我们要根据不同的测试类型考虑不同的测试方法，对于功能测试，我们根据需求分析的思维导图和功能测试的测试用例覆盖需求列表；兼容性测试，我们要根据产品的应用场景来考虑，比如IE、Chorme、ios、android、不同机型等等；性能测试，根据产品架构、预估数据、线上数据来判断需要执行性能测试的功能接口（比如登录接口）；接口测试，安全性测试等等要根据实际的项目需求来确定。
第6章 测试计划
6.1进度计划
主要包括里程碑计划，包括阶段、里程碑、资源等。
6.1.1测试时间进度
| 测试阶段 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
|---|---|---|---|---|
| 制定测试计划 | 2019-05-01 | 2019-05-14 | 张** | 输出测试计划说明书 |
| 需求Review | 输出需求说明书或原型 | |||
| 设计Review | 输出设计说明和原型 | |||
| 设计测试用例 | 输出测试用例 | |||
| 测试实施 | ||||
| 功能测试 | 功能模块级别中以上bugs被修复，测试通过 | |||
| 集成测试 | 各个模块间接口及功能bugs级别中以上bugs被修复，测试通过 | |||
| 系统测试 | 需求说明书中的功能全部实现且测试通过 | |||
| 验收测试 | 产品和UI验收通过 | |||
| 文档编写 | 输出测试报告 | |||
6.1.2测试里程碑
| 里程碑 | 完成时间 | 完成标准 |
|---|---|---|
| 测试正式开始 | 完成可接受性测试和冒烟测试 | |
| 测试执行 | 执行测试 | 完成所有里程碑测试和标准测试,测试种类包括确认测试和系统测试,且所有以发现的Bug等级为非常严重/严重/中的Bug已修复,近期内无发现新的Bug等级为非常严重/严重/中的Bug，等级低的bug根据实际项目时间安排择优处理。 |
| 产品Release | 重复进行主路径测试和进行Bug检查测试,产品处于可交付状态并由测试经理和高级经理确认 |
6.2测试准备
6.2.1 测试环境准备
| 准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
|---|---|---|---|---|
| 测试环境准备 |
6.2.2 安装测试
| 准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
|---|---|---|---|---|
| 安装测试 |
6.2.3 冒烟测试
| 准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
|---|---|---|---|---|
| 冒烟测试 |
6.3 具体测试实施任务和时间人员安排
| 测试功能点 | 开始时间 | 完成时间 | 测试人员 | 说明 |
|---|---|---|---|---|
以上是测试计划实际情况中的一个文档输出，那么我们如何才能输出这样文档呢？
根据文档内容要求，我们需要确定测试目标、测试范围和测试策略，以及根据测试范围和测试策略进行测试时间、人力等资源的安排等这几个重点。
那么如何确定测试目标呢？
测试目标是有质量目标来确定的，而质量目标则从以下三个维度来说明
- 产品的商业价值：是质量第一还是快速上线
- 根据项目铁三角原则：确定是快速上线还是0bug上线
- 根据线上项目事故率：这个也是测试绩效考核的一个点，线上无P0和P1的事故
根据以上3点确定测试计划的测试目标。
如何确立测试范围呢？
一般情况下，测试范围是根据需求文档和原型综合评判得出测试计划的测试范围，这里一般情况下建议使用思维导图进行需求分析，这里主要有需求优先级、、需求的关联功能、识别测试重点等确定测试范围，得出测试的关键功能、主要功能、强关联功能 、次要功能、弱关联功能等。
确定测试策略
整体测试策略
- 业务和技术深度掌握：深挖业务场景，掌握业务相关的接口
- 多样化的测试策略：主要有业务场景、交互，UI，兼容性，数据逻辑，业务逻辑，性能测试等多角度进行分析测试
- 组内组外的充分沟通：在敏捷开发中显得更加重要
版本测试策略
- 针对不同功能和优先级采用不同的测试策略：P1优先级的功能则需要用例的详细设计，充分考虑用户的实际使用场景，覆盖功能的各种细节和异常情况，在第一轮测试完成之后，P1的第二轮则一般是进行探索性测试，确定所涉及的场景基本都被覆盖。针对P2优先级的功能则需要用例的详细设计，覆盖用户的各种实际使用场景，一般在第一轮测试完成之后，不需要第二轮的探索测试。而对于P3功能一般是直接进行测试要点的编写，进行探索性测试即可。P4的功能一般是直接根据需求文档进行测试。当然如果产品的商业价值可能不同的需求的优先级则有所不同，需要实际项目实际操作。
- 交叉抽测和回归测试
如何制定工期、人员安排、进度安排
工期的评定
- 出卡牌的方式
- 头脑风暴
人员安排
- 需要考虑任务的关联度和重要程度
- 人员工作量分布
进度安排
- 提测时间安排
- 一般使用甘特图进行进度安排
- 根据功能的优先级和重点以及人员的工作量情况，排定进度表
里程碑进度安排
根据上面的进度安排制定的甘特图，可能会出现颗粒度太细，无法一目了然了解项目进度情况，所以这个时候就需要里程碑，通过里程碑，划分里程碑的进度。可以根据不同的模块相对大小划分里程碑，这里需要注意要加入测试前期的测试用例编写的时间安排以及测试回归时所消耗的时间。
其他影响
- 研发计划
- 风险处理：需要根据风险的历史库和预先识别的风险制定风险策略
- 研发流程：如果说项目质量要求比较高，我们可能还需要制定冒烟测试计划、单元测试、集成测试等
通过上面的测试计划内容以及如何制定测试计划的详细说明，相信你可以根据项目情况制定一份确实可行的测试计划啦，马上行动起来吧......