释放双眼，带上耳机，听听看~！

本文目录

2.3.1 测试人力资源
2.3.2 测试环境
2.3.3 BUG管理工具

最近入职了新公司，项目组只有我一个测试，自成一家，哈哈，领导让编写测试计划，于是在网上看了很多，最终自己拟了一份，希望能和大家共勉！

1 引言... 4

1.1 产品简介... 4

1.2 编写目的... 4

1.3 参考文档... 4

1.4 限制条件... 5

2 测试概要... 5

2.1 测试目标... 5

2.2 测试范围... 5

2.3 测试资源... 6

2.3.1 测试人力资源... 6

2.3.2 测试环境... 6

2.3.3 BUG管理工具... 6

3 测试规范... 7

3.1 测试接收标准... 7

3.2 BUG规范... 7

4 测试策略... 8

4.1 测试流程及工作量估算... 8

4.2 测试种类... 9

4.3 测试输出文档... 10

5 发布标准... 10

5.1 测试完成标准... 10

5.2 产品发布标准... 10

6 测试风险... 10

1 引言

1.1 产品简介

1.2 编写目的

此文档根据项目需求文档，制定测试策略、评估测试风险，确定所需的资源，并对测试的工作量进行估计，进行人员和进度安排，并且列出测试项目的可交付元素。

本文档预期读者对象主要为项目经理、产品、开发、测试等。

1.3 参考文档

序号	名称	作者	备注
	详细设计文档
	设计原型

1.4 限制条件

本测试计划受限于开发人员提交测试的内容和时间。根据开发人员提交模块的实际情况，本计划会做出相应修改。

2 测试概要

2.1 测试目标

通过测试，达到以下目标：

测试已实现的产品是否达到设计的要求，包括：各个功能点是否以实现，业务流程是否正确。
产品规定的操作和系统运行稳定。
Bug数和缺陷率控制在可接收的范围之内，遗留BUG一般不超过所有BUG的10%。

2.2 测试范围

列出测试最终需要交付的功能模块列表

2.3 测试资源

2.3.1 测试人力资源

角色	人员	职责
测试负责人	XXX	测试环境搭建制定测试计划制定测试规范测试用例审核控制测试进度与相关部门、人员沟通
测试设计人员	XXX	设计测试用例准备测试数据
测试执行人员	XXX	按计划执行测试用例记录执行过程提出纠正建议措施
缺陷管理人员	所有测试执行人员	记录、报告所发现的缺陷跟踪缺陷修改过程回归测试已修复缺陷
测试报告人员	XXX	分析测试结果编写测试报告

2.3.2 测试环境

服务器环境

操作系统：windows IP:

操作系统：linux IP:

终端环境

PC：windows10（ie10、chrome、Firefox）、windows7（ie10、chrome、Firefox）

网络环境

公司办公内网、外网

2.3.3 BUG管理工具

在测试过程中发现的缺陷及可用性问题，使用禅道来进行 bug 管理。

3 测试规范

3.1 测试接收标准

开始/中断测试标准

标准说明

开始测试标准

1、代码编译通过

2、软件可以正确安装运行

3、实现功能与产品设计出入不大

4、冒烟测试通过

中断测试标准

1、安装无法正确完成

2、程序代码编译不通过

3、系统服务异常

4、发现阻塞功能的BUG

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.1 测试流程及工作量估算

任务	时间	执行人员	预期工作量	备注
编写测试计划		XXX	2
测试计划review及修改		XXX	1
测试环境搭建		XXX	4
测试用例编写		XXX	4
冒烟测试		XXX	2	依据开发提测时间变动
第一轮功能测试		XXX	4	执行测试用例，包括边界值测试、兼容性测试、易用性测试、用户界面测试、安全性测试等
第二轮功能测试		XXX	3	BUG复测及功能验证
回归测试		XXX	1	全面回归测试
性能测试	-			待定，需确认具体性能测试方案和工具
发布测试	-			产品发布方案确认后再规划
测试报告总结		XXX	2	时间待定
备注：由于测试时可能会出现多个测试计划并行测试执行的情况，测试预估时间只作参考。

4.2 测试种类

本次测试计划对系统进行以下类型的测试，针对不同的测试类型分别进行规划和设计，包括测试方法和标准等。测试类型罗列如下：

测试类型	是否采用	说明
功能测试	采用	根据系统需求文档和设计文档，检查系统是否正确实现了功能
边界值测试	采用	选择边界数据进行测试，确保系统功能正常，程序无异常
容错性测试	采用	检查系统的容错能力，错误的数据输入不会对功能和系统产生非正常的影响，程序对错误的输入有正确的提示信息
异常测试	采用	检查系统能否处理异常
易用性测试	采用	检查系统是否易用友好
UI（界面）测试	采用	检查界面是否美观合理，便于操作，符合操作习惯
流程测试	采用	按操作流程进行的测试，主要有业务流程、数据流程、逻辑流程，检查软件在按流程操作时是否能够正确处理
接口测试	采用	检查系统接口能否正常工作
配置测试	采用	检查配置是否合理、配置是否正常
系统测试	采用	系统根据集成方案部署安装到软硬件环境后的运行情况
兼容性测试	采用	对于 C/S 架构的系统来说，需要考虑客户端支持的系统平台；对于 B/S 架构的系统来说需要考虑用户端浏览器的版本
稳定性测试	采用	利用工具长时间不断的对系统进行操作
安全性测试	采用	系统级别的安全性扫描；系统应用级别的安全性：检查角色只能访问其所属用户类型已被授权访问的那些功能或数据。
性能测试	采用	提取系统性能数据，检查系统是否满足在需求中所规定达到的性能。
安装卸载测试	采用	检查系统能否正确安装、配置

4.3 测试输出文档

本次测试完成后的提交物：

测试计划
测试用例
测试Bug单
使用手册
测试报告

5 发布标准

5.1 测试完成标准

需求规格说明书中的需求必须全部实现并测试通过。
主流程畅通，系统没有一类和二类Bug（参考3.2 BUG规范），没有影响用户正常使用的BUG。
所有功能和性能测试用例100％执行完成。
剩余三类四类有争议的bug，如果无法达成一致，测试人员需与产品、开发、项目经理开会讨论决定是否遗留有争议的Bug，若最终决定项目上线时有遗留BUG，需将BUG说明附在测试结果报告里，给出原因或最终解决方案。
按照交互文档、需求文档完全的实现需求。
符合交互稿的交互设计规范、符合视觉要求，并已经通过设计评审。
核心代码100％经过代码Review。
允许遗留可能会对用户正常使用造成一定影响的三类、四类缺陷，但应在发布前告知项目组，并经风险评估一致同意发布后方可发布。

5.2 产品发布标准

6 测试风险

本次测试过程中，可能出现的风险如下：

开发提交测试版本比该计划延迟，发生此种情况时，执行测试的时间应该合理顺延；
如果测试计划执行过程中出现需求变更超出预计的情况，可能导致编写测试用例和执行测试相关工作量增加，测试进度延迟；
如果开发提测版本质量较低，bug较多，可能导致比该计划更多轮次的回归测试；
人员调整、人员经验以及对软件的熟悉度可能会影响测试计划；
测试需依赖于服务器环境，如果环境不稳定，如代码编译不通过，tomcat异常、jar包异常、数据库异常等情况，可能会影响测试进度。

{{userData.name}}已认证

测试计划的设计和编写