1.测试计划的定义
描述了要进行的测试活动的范围、方法、资源和进度的文档；
是对整个信息系统应用软件组装测试和确认测试。
它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。
测试计划可以有效预防计划的风险，保障计划的顺利实施。
2.测试计划的目的
（1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。
（2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。
（3）开发有效的测试模型，能正确地验证正在开发的软件系统。
（4）确定测试所需要的时间和资源，以保证其可获得性、有效性。
（5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。
（6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。
3. 测试计划编写的6个要素
1）why—为什么要进行这些测试；
2) what—测试哪些方面，不同阶段的工作内容；
3) when—测试不同阶段的起止时间；
4) where—相应文档，缺陷的存放位置，测试环境等；
5) who—项目有关人员组成，安排哪些测试人员进行测试
6) how—如何去做，使用哪些测试工具以及测试方法进行测试。
4. 测试计划模板
以下为我结合两个博客，做出的一个适合自己的测试计划模板：
4.1 引言
4.1.1 项目背景和目的
本次是关于健身房管理后台三期项目的测试计划，主要功能包括登录、会员卡信息导入、会员信息导入、私教课和特色课的预约课程限制、潜客管理、签到等管理后台以及APP端的功能测试计划。根据项目情况，安排测试阶段周期2周完成3轮测试工作、人员目前配备的是两个测试人员，在两周内结束测试，达到上线测试标准。三期结束之后可以比较完整的交付用户正式试用管理系统。
本文档根据项目需求文档，制定测试策略、评估测试风险，确定所需的资源，并对测试的工作量进行估计，进行人员和进度安排，并且列出测试项目的可交付元素。
预期读者对象主要为项目经理、产品、开发、测试等。
4.1.2 参考资料
| 文档资料 | 文档说明 | 位置信息 |
|---|---|---|
| 项目可行性分析报告 | 项目可行性分析说明书 | 项目计划\项目可行性分析报告 |
| 软件需求规格说明书 | 软件需求定义 | … |
| 软件概要设计 | 软件采用的框架、软件的数据库结构设计 | … |
| 软件详细设计 | 软件数据库每个表的详细设计等 | … |
| 用户使用说明书 | 用户使用说明文档 | … |
| … | … | … |
4.1.3 [ 名词解释 ]
本测试计划中涉及以下名词，解释如下：
| 缩写词或术语 | 英文解释 | 中文解释 |
|---|---|---|
| 验收测试 | 系统开发生命周期方法论的一个阶段，这时相关的用户和／或独立测试人员根据测试计划和结果对系统进行测试和接收 | |
| α测试 | 是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成 | |
| 黑盒测试 | 测试人员不关心程序具体如何实现的一种测试方法 | |
| BUG | 有时称作defect（缺陷）或error（错误），软件程序中存在的编程错误，可能会带来不必要的副作用，软件的功能和特性与设计规格说明书或用户需求不一致的方面 | |
| β测试 | 测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成 | |
| … | … | … |
4.1.4 风险评估
目前开发排期时间比较赶，导致测试时间不充分；因项目原因无法延期，所以需要侧重点进行管理后台的测试，APP的测试可根据实际情况适当延期。其二：目前后台管理系统没有进行性能和压力测试，在后期用户数据量猛增可能会导致系统瘫痪的风险；其三：目前测试机型不充分，基本没有进行兼容性测试；在用户试用阶段，建议试用目前已经验证的常规机型和常用浏览器FirFox或chrome浏览器等。
4.2 测试概要
4.2.1 测试目标
通过测试，达到以下目标：
- 测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。
- 产品规定的操作和系统运行稳定。
- Bug数和缺陷率控制在可接收的范围之内，遗留BUG一般不超过所有BUG的10%。
4.2.2 测试范围
目前三期项目的主要功能参考如下：
本次测试计划主要涵盖的测试范围：管理后台V3期和APP以及微信小程序，其中管理端的优先级最高，需要优先上线、其后是APP和小程序。目前涉及的测试方法主要包括接口测试、功能测试、集成测试、系统测试和验收测试；其中接口和整体功能测试、验收测试是目前测试的重点，具体参考原型和需求说明书。
4.2.3 时间进度
| 时间/事项 | 起始时间 | 结束时间 |
|---|---|---|
| 转测时间 | … | … |
| 测试开始时间 | … | … |
| 测试结束时间 | … | … |
| … | … |
4.2.4 测试资源
4.2.4.1 测试人力资源
| 角色 | 人员 | 职责 |
|---|---|---|
| 测试负责人 | XXX | 测试环境搭建 制定测试计划 制定测试规范 测试用例审核 控制测试进度 与相关部门、人员沟通 |
| 测试设计人员 | XXX | 设计测试用例 准备测试数据 |
| 测试执行人员 | XXX | 按计划执行测试用例 记录执行过程 提出纠正建议措施 |
| 缺陷管理人员 | 所有测试执行人员 | 记录、报告所发现的缺陷 跟踪缺陷修改过程 回归测试已修复缺陷 |
| 测试报告人员 | XXX | 分析测试结果 编写测试报告 |
4.2.4.2 测试环境
1.服务器环境
| 机型（配置） | IP地址 | 操作系统 | 用途及特殊说明 | 软件及版本 | 预计空间 |
|---|---|---|---|---|---|
| ubuntu01 | *** | ubuntu16 | 服务器 | *** | |
| ubuntu02 | K8S服务 | ||||
| ubuntu03 | docker服务… |
2.客户端配置
| 机型（配置） | IP地址 | 操作系统 | 用途及特殊说明 | 软件及版本 | 预计空间 |
|---|---|---|---|---|---|
| ThinkVision、16G内存 | *** | win10企业版 | 客户机 | Chrome74-32位 | |
| 锤子手机 | Android7.0 | ||||
| iPhone7p | IOS10.0 |
-
终端环境
PC：windows10（ie10、chrome、Firefox）、windows7（ie10、chrome、Firefox） -
网络环境
公司办公内网、外网
4.2.4.2 测试工具
| 测试工具 | 用途 |
|---|---|
| 自动测试工具 | selenium+python 自动化回归测试 |
| JIRA | bug管理 |
| confluence | 项目管理工具 |
| postman | 接口自动化测试 |
| JMeter | 性能/接口自动化测试 |
| … | … |
4.3 测试规范
4.3.1 测试接收标准
| 开始/中断测试标准 | 标准说明 |
|---|---|
| 开始测试标准 | 1、代码编译通过 2、软件可以正确安装运行 3、实现功能与产品设计出入不大 4、冒烟测试通过 |
| 中断测试标准 | 1、安装无法正确完成 2、程序代码编译不通过 3、系统服务异常 4、发现阻塞功能的BUG |
4.3.2 BUG规范
测试人员提交缺陷记录时，应清晰、准确地描述缺陷发生的条件和步骤，并设置缺陷的严重等级如下：
| 缺陷级别 | 描述 |
|---|---|
| 一级 （致命问题） |
1. 程序运行过程中不断申请，但没有完全释放资源，造成系统性能越来越低，并出现无规律的死机现象。 2. 程序运行导致系统崩溃。 3. 由程序引起的资源严重不足、非法退出等。 4. 严重的关键计算错误（如计费等）。 5. 数据库发生死锁，且无法自动恢复。 6. 与需求要求差距较大。 7. 系统无响应。 |
| 二级 （严重问题） |
1. 因错误操作导致的程序中断。 2. 功能没有实现。 3. 正确操作导致的错误结果。 4. 与数据库连接错误,无法自动恢复。 5. 数据通讯错误，无法自动恢复。 6. 数据库的表、业务规则、缺省值未加完整性等约束条件。 7. 界面中的信息不能及时刷新，不能正确反映当前数据状态，可能误导用户。（数据库中剩余记录个数和参数设置对话框中的预设值常常显示为历史值而不是当前值） 8. 对输入数据没有进行充分并且有效的有效性检查，造成不合要求的数据进入数据库。 |
| 三级 （普通问题） |
1. 操作界面错误。（包括数据窗口内列名定义、含义是否一致，界面中英文混杂，界面元素参差不齐，文字显示不全） 2. 打印内容、格式错误。 3. 删除操作未给出提示。 4. 数据库表中有过多的空字段。 5. 提示信息意文不明或为原始的英文提示。 6. 要求用户输入多余的、本来系统可以自动获取的数据。（服务是否启动，安装后用户需要手动修改某些配置文件）。 7. 辅助说明描述不清楚，有歧义。 8. 长操作未给用户提示。 |
| 四级 （改进问题） |
1. 辅助说明描述不清楚。 2. 输入输出不规范。 3. 可输入区域和只读区域没有明显的区分标志。 4. 某一项功能的冗余操作太多。如：对话框嵌套层次太多，影响用户操作。 5. 不能记忆用户的设置或操作习惯，用户每次进入系统都需要重新操作初始环境。 6. 不符合用户操作习惯。（快捷键定义不科学、不实用，键位分布不合理、按键太多，甚至没有快捷键）。 7. 界面不规范。 8. 提示窗口文字未采用行业术语。 |
4.4 测试策略
4.4.1 测试流程及工作量估算
| 任务 | 时间 | 执行人员 | 预期工作量 | 备注 |
|---|---|---|---|---|
| 编写测试计划 | XXX | 2 | ||
| 测试计划review及修改 | XXX | 1 | ||
| 测试环境搭建 | XXX | 4 | ||
| 测试用例编写 | XXX | 4 | ||
| 冒烟测试 | XXX | 2 | 依据开发提测时间变动 | |
| 第一轮功能测试 | XXX | 4 | 执行测试用例，包括边界值测试、兼容性测试、易用性测试、用户界面测试、安全性测试等 | |
| 第二轮功能测试 | XXX | 3 | BUG复测及功能验证 | |
| 回归测试 | XXX | 1 | 全面回归测试 | |
| 性能测试 | - | 待定，需确认具体性能测试方案和工具 | ||
| 发布测试 | - | 产品发布方案确认后再规划 | ||
| 测试报告总结 | XXX | 2 | 时间待定 |
备注：由于测试时可能会出现多个测试计划并行测试执行的情况，测试预估时间只作参考。
4.4.2 测试类型
| 测试类型 | 是否采用 | 说明 |
|---|---|---|
| 功能测试 | 采用 | 根据系统需求规格说明书、原型和设计文档，检查产品是否正确实现了功能。 |
| 流程测试 | 采用 | 按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程、正反流程，检查软件在按流程操作时是否能够正确处理 |
| 边界值测试 | 采用 | 选择边界数据进行测试，确保系统功能正常，程序无异常。 |
| 容错性测试 | 采用 | 检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，且程序对错误的输入有正确的提示信息 |
| 异常测试 | 采用 | 检查系统能否处理异常 |
| 启动停止测试 | 采用 | 检查每个模块能否正常启动停止、异常停止后能否正常启动 |
| 安装卸载测试 | 采用 | 检查系统能否正确安装、配置 |
| 易用性测试 | 采用 | 检查系统是否易用友好 |
| 界面测试 | 采用 | 检查界面是否美观合理 |
| 接口测试 | 采用 | 检查系统能否与外部接口正常工作 |
| 配置测试 | 采用 | 检查配置是否合理、配置是否正常 |
| 安全性和访问控制测试 | 采用 | 应用程序级别的安全性：检查Actor只能访问其所属用户类型已被授权访问的那些功能或数据。系统级别的安全性：检查只有具备系统和应用程序访问权限的Actor才能访问系统和应用程序。 |
| 兼容性测试 | 采用 | 需要考虑浏览器的兼容性以及不同手机类型的兼容性(FireFox\chrome\QQ浏览器等；华为手机\iPhone手机\小米\vivo等手机) |
| 回归测试 | 采用 | 检查程序修改后有没有引起新的错误、是否能够正常工作以及能否满足系统的需求 |
其中每个测试类型的详解见博客 4.2章节下。
4.5 测试计划
4.5.1 进度计划
主要包括里程碑计划，包括阶段、里程碑、资源等。
4.5.2 测试时间进度
| 测试阶段 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
|---|---|---|---|---|
| 制定测试计划 | 2019-05-01 | 2019-05-14 | 唐** | 输出测试计划说明书 |
| 需求Review | 输出需求说明书或原型 | |||
| 设计Review | 输出设计说明和原型 | |||
| 设计测试用例 | 输出测试用例 | |||
| 测试实施 | ||||
| 功能测试 | 功能模块级别中以上bugs被修复，测试通过 | |||
| 集成测试 | 各个模块间接口及功能bugs级别中以上bugs被修复，测试通过 | |||
| 系统测试 | 需求说明书中的功能全部实现且测试通过 | |||
| 验收测试 | 产品和UI验收通过 | |||
| 文档编写 | 输出测试报告 |
4.5.3 测试里程碑
| 里程碑 | 完成时间 | 完成标准 |
|---|---|---|
| 测试正式开始 | 完成可接受性测试和冒烟测试 | |
| 测试执行 | 执行测试 | 完成所有里程碑测试和标准测试,测试种类包括确认测试和系统测试,且所有以发现的Bug等级为非常严重/严重/中的Bug已修复,近期内无发现新的Bug等级为非常严重/严重/中的Bug，等级低的bug根据实际项目时间安排择优处理。 |
| 产品Release | 重复进行主路径测试和进行Bug检查测试,产品处于可交付状态并由测试经理和高级经理确认 |
4.5.4 测试准备
4.5.4.1 测试环境准备
| 准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
|---|---|---|---|---|
| 测试环境准备 |
4.5.4.2 安装测试
| 准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
|---|---|---|---|---|
| 安装测试 |
4.5.4.3 冒烟测试
| 准备事项 | 开始时间 | 完成时间 | 测试人员 | 阶段完成标志 |
|---|---|---|---|---|
| 冒烟测试 |
4.5.5 具体测试实施任务和时间人员安排
| 测试功能点 | 开始时间 | 完成时间 | 测试人员 | 说明 |
|---|---|---|---|---|
| … | … | … | … | … |
4.6 发布标准
4.6.1 测试输出文档
本次测试完成后的提交物：
- 测试计划
- 测试用例
- 测试Bug单
- 使用手册
- 测试报告
4.6.2 测试完成标准
本次测试过程中，计划测试完成的标准如下：
- 需求规格说明书中的需求必须全部实现并测试通过。
- 主流程畅通，系统没有一类和二类Bug（参考3.2 BUG规范），没有影响用户正常使用的BUG。
- 所有功能和性能测试用例100％执行完成。
- 剩余三类四类有争议的bug，如果无法达成一致，测试人员需与产品、开发、项目经理开会讨论决定是否遗留有争议的Bug，若最终决定项目上线时有遗留BUG，需将BUG说明附在测试结果报告里，给出原因或最终解决方案。
- 测试报告编写完成，测试收尾工作结束。
- 项目处于试运行或上线阶段。
4.6.3 产品发布标准
本次测试过程中，计划产品发布上线的标准如下：
- 按照交互文档、需求文档完全的实现需求。
- 符合交互稿的交互设计规范、符合视觉要求，并已经通过设计评审。
- 核心代码100％经过代码Review。
- 允许遗留可能会对用户正常使用造成一定影响的三类、四类缺陷，但应在发布前告知项目组，并经风险评估一致同意发布后方可发布。
来源：CSDN
作者：暗潮汹涌
链接：https://blog.csdn.net/qq_34659777/article/details/103971817