最近入职了新公司，项目组只有我一个测试，自成一家，哈哈，领导让编写测试计划，于是在网上看了很多，最终自己拟了一份，希望能和大家共勉！
目录
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 测试策略... 9
4.1 测试流程及工作量估算... 9
4.2 测试种类... 10
4.2.1 功能测试... 11
4.2.2 容错性测试... 12
4.2.3 易用性测试... 13
4.2.4 UI（界面）测试... 13
4.2.5 接口测试... 14
4.2.6 系统测试... 14
4.2.7 兼容性测试... 15
4.2.8 性能测试... 15
4.2.9 安装卸载测试... 17
5 发布标准... 17
5.1 测试输出文档... 17
5.2 测试完成标准... 18
5.3 产品发布标准... 18
6 测试风险... 18
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. 某一项功能的冗余操作太多。如：对话框嵌套层次太多，影响用户操作。 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.2.1 功能测试
功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接收、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。
| 测试目标 |
覆盖本次测试范围的所有功能测试 |
| 测试范围 |
测试内容 |
| 技术 |
1.设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略等 2.利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容： （1）在使用有效数据时得到预期的结果。 （2）在使用无效数据时显示相应的错误消息或警告消息。 （3）各业务规则都得到了正确的应用。 |
| 开始标准 |
通过冒烟测试 |
| 完成标准 |
不能遗留一，二级缺陷,三级普通缺陷90%得到修改并且通过复测，四级改进缺陷80%得到修改并且通过复测 |
| 测试重点和优先级 |
重点测试的功能和优先级安排 |
| 需考虑的特殊事项 |
考虑数据库数据存储的正确性； 考虑业务边界值的测试（边界值测试）； 考虑业务异常情况的测试（异常测试）； 考虑业务流程、数据流程、逻辑流程的测试（流程测试） |
4.2.2 容错性测试
容错性测试主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复手段。
| 测试目标 |
检查软件容错能力 |
| 测试范围 |
|
| 技术 |
1.输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。 2.灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复。 |
| 开始标准 |
功能测试阶段 |
| 完成标准 |
不能遗留一，二级缺陷,三级普通缺陷90%得到修改并且通过复测，四级改进缺陷80%得到修改并且通过复测 |
| 测试重点和优先级 |
重点考虑各种异常情况，灾难恢复性测试需建立在系统有较好的容灾机制。 |
| 需考虑的特殊事项 |
考虑不按正常流程操作系统； 考虑使用非正常手段访问（例如直接使用内部链接地址访问，直接使用访问协议访问） 考虑数据不符合实际规则（例如数据填写不完整、输入不存在的日期、数字或文本超出设定值、输入空格、上传不符合类型的文件等） 考虑多系统登录、超时登录等 以下几点为环境容错测试，即容灾机制需考虑的问题：
|
4.2.3 易用性测试
易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。易用性测试应当集中体现在界面美观、功能实用、处理有效几个方面。
| 测试目标 |
检查系统是否易用友好 |
| 测试范围 |
|
| 技术 |
一般从导航，图形，内容，整体界面等几个方面入手，主要考虑如下几个方面: (1)易理解性;(2)易学习性;(3)易操作性(4)吸引性;(5)依从性。 具体测试点如下： 1.查询、添加、删除、修改操作相关提示信息的一致性，可理解性 2.输入限制的正确性 3.系统各种提示信息的正确性，可理解性，一致性 |
| 开始标准 |
功能测试阶段 |
| 完成标准 |
不能遗留一，二级缺陷,三级普通缺陷90%得到修改并且通过复测，四级改进缺陷80%得到修改并且通过复测 |
| 测试重点和优先级 |
|
| 需考虑的特殊事项 |
考虑系统被频繁使用的功能支持快捷方式或默认值方式； 考虑2秒钟法则——用户在使用某类系统时的等待反应不应该超过2秒； 考虑3次点击法则——用户在3次点击之内如果还没有找到他们想要的信息或了解产品/网站的特色，他们就会离开； 考虑所有提示信息应该可以帮助用户完成功能使用，并且尽可能通俗易懂，言简意赅 |
4.2.4 UI（界面）测试
用户界面（UI）测试主要用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。
| 测试目标 |
测试UI界面的浏览是否可以正确反映业务的功能和需求，是否能与原型图保持一致 |
| 测试范围 |
|
| 技术 |
UI界面测试包括窗口与窗口之间、字段与字段之间的浏览，以及各种访问方法（Tab键、鼠标移动、和快捷键）的使用，窗口的对象和特征（例如，菜单、图标、文字、大小、位置、状态和中心）等 |
| 开始标准 |
功能测试阶段 |
| 完成标准 |
成功地核实出各个窗口都与原型图保持一致，或符合可接受标准 |
| 测试重点和优先级 |
|
| 需考虑的特殊事项 |
考虑直观性、一致性、灵活性、舒适性等 |
4.2.5 接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试也属于功能测试，测试流程是首先根据接口文档编写测试用例（用例编写可以按照功能测试的规则来编写，例如等价类划分，边界值等设计方法），然后执行测试，查看不同的参数请求，判断接口的返回数据是否达到预期，可能需要转换接口数据格式，常见为json格式，并且需根据需求支持一种或多种接口请求方式（例如GET请求、POST请求等），请求协议为http或https等。
| 测试目标 |
保证接口调用的正确性 |
| 测试范围 |
|
| 技术 |
1.使用接口测试工具postman进行接口调用测试， 2.使用jmeter维护自动化接口测试， 3.使用fiddler进行接口请求抓取 |
| 开始标准 |
功能测试阶段 |
| 完成标准 |
不能遗留一，二级缺陷,三级普通缺陷90%得到修改并且通过复测，四级改进缺陷80%得到修改并且通过复测 |
| 测试重点和优先级 |
|
| 需考虑的特殊事项 |
考虑接口参数必填、非必填 考虑业务异常情况 考虑接口参数异常（如参数为null，参数为特殊字符） 考虑接口参数边界值测试 考虑接口返回数据的正确性 考虑接口请求超时的情况 考虑接口请求失败的情况，业务是否可逆，数据是否存储或取消 |
4.2.6 系统测试
系统测试主要目的为检测系统是否达到需求对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此阶段测试是基于功能测试完成的情况下。
| 测试目标 |
检测整个系统业务流程，数据流的正确性 |
| 测试范围 |
|
| 技术 |
利用有效的和无效的数据来执行各个用例、用例流或功能，以核实以下内容： 1.在使用有效数据时得到预期的结果。 2.在使用无效数据时显示相应的错误消息或警告消息。 3.各业务规则都得到了正确的应用。 |
| 开始标准 |
功能测试完成后 |
| 完成标准 |
所计划的测试已全部执行。 所发现的等级高的缺陷已全部解决。 |
| 测试重点和优先级 |
重点测试系统之间交互，数据传送等 |
| 需考虑的特殊事项 |
考虑不同系统的交互流程是否存在冗余步骤，及可优化点 |
4.2.7 兼容性测试
兼容性测试主要检验被测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行测试。
| 测试目标 |
检测程序兼容性 |
| 测试范围 |
|
| 技术 |
1.测试软件是否能在不同的操作系统平台上兼容，或测试软件是否能在同一操作平台的不同版本上兼容； 2.软件本身能否向前或向后兼容（考虑版本迭代的情况）； 3.测试软件能否与其他相关的软件兼容； 4.测试软件能否支持不同浏览器的兼容； 5.测试软件能否支持不同分辨率的兼容； 6.数据兼容性测试，主要是指数据能否共享等。 |
| 开始标准 |
功能测试阶段 |
| 完成标准 |
不能遗留一，二级缺陷,三级普通缺陷90%得到修改并且通过复测，四级改进缺陷80%得到修改并且通过复测 |
| 测试重点和优先级 |
|
| 需考虑的特殊事项 |
需考虑后期版本迭代，不同系统不同版本之间的兼容性 |
4.2.8 性能测试
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。性能测试是为了验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。性能测试一般包括以下几种类型：
1.基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数据做为基础参考。
2.负载测试：是指对系统不断地增加压力或持续一段时间增加一定压力，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。
3.压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注系统在峰值负载时或超出最大负载情况下的处理能力。
4.稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
5.并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时，是否存在死锁或者其他性能问题。
| 测试目标 |
检测系统性能，发现性能瓶颈，进行性能调优 |
| 测试范围 |
|
| 技术 |
待确定详细的性能测试方案 |
| 开始标准 |
测试工作完成后，系统稳定后 |
| 完成标准 |
达到需求要求的性能标准 |
| 测试重点和优先级 |
|
| 需考虑的特殊事项 |
性能测试一般参考指标有响应时间、吞吐量、并发数、资源利用率、事务处理能力（TPS）等。 性能测试一般关注点如下： 1.响应时间快慢，服务器端的处理速度 2.服务器端的使用情况 3.数据库端的资源使用情况 4.最大用户访问数量 5.同时处理最大业务数量 6.考察系统能否支撑7x24小时运转 7.内存资源、线程资源能否正常回收 8.代码，算法，sql语句设计是否合理 9.整个系统的稳定性，可恢复性 |
4.2.9 安装卸载测试
安装卸载测试是为了确保该软件在正常情况和异常情况的不同条件下（例如，进行首次安装、升级、完整的或自定义的安装，卸载重安装等）都能成功进行安装，异常情况包括磁盘空间不足、缺少目录创建权限等，核实软件在安装后可立即正常运行，核实软件可以正常进行卸载。
| 测试目标 |
检查程序包是否可以正常进行安装部署和卸载 |
| 测试范围 |
- |
| 技术 |
1.软件在不同操作系统下安装的过程。 2.软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到了指定的目录里。 3. 软件安装过程是否可以取消 4.测试使用系统自带的添加删除（以WIDOWSXP为例）程序卸载的情况 5.测试软件自带的卸载程序 6.测试卸载以后重新安装 7.测试安装和卸载时的提示信息是否合理 |
| 开始标准 |
测试阶段完成，有安装包打包方案后 |
| 完成标准 |
安装成功能够运行系统，卸载成功无残留 |
| 测试重点和优先级 |
|
| 需考虑的特殊事项 |
考虑安装和卸载过程中出现的意外情况的测试（如死机、断电、重启） 考虑旧版本升级操作 |
5 发布标准
5.1 测试输出文档
本次测试完成后的提交物：
- 测试计划
- 测试用例
- 测试Bug单
- 使用手册
- 测试报告
5.2 测试完成标准
本次测试过程中，计划测试完成的标准如下：
- 需求规格说明书中的需求必须全部实现并测试通过。
- 主流程畅通，系统没有一类和二类Bug（参考3.2 BUG规范），没有影响用户正常使用的BUG。
- 所有功能和性能测试用例100％执行完成。
- 剩余三类四类有争议的bug，如果无法达成一致，测试人员需与产品、开发、项目经理开会讨论决定是否遗留有争议的Bug，若最终决定项目上线时有遗留BUG，需将BUG说明附在测试结果报告里，给出原因或最终解决方案。
- 测试报告编写完成，测试收尾工作结束。
- 项目处于试运行或上线阶段。
5.3 产品发布标准
本次测试过程中，计划产品发布上线的标准如下：
- 按照交互文档、需求文档完全的实现需求。
- 符合交互稿的交互设计规范、符合视觉要求，并已经通过设计评审。
- 核心代码100％经过代码Review。
- 允许遗留可能会对用户正常使用造成一定影响的三类、四类缺陷，但应在发布前告知项目组，并经风险评估一致同意发布后方可发布。
6 测试风险
本次测试过程中，可能出现的风险如下：
- 开发提交测试版本比该计划延迟，发生此种情况时，执行测试的时间应该合理顺延；
- 如果测试计划执行过程中出现需求变更超出预计的情况，可能导致编写测试用例和执行测试相关工作量增加，测试进度延迟；
- 如果开发提测版本质量较低，bug较多，可能导致比该计划更多轮次的回归测试；
- 人员调整、人员经验以及对软件的熟悉度可能会影响测试计划；
- 测试需依赖于服务器环境，如果环境不稳定，如代码编译不通过，tomcat异常、jar包异常、数据库异常等情况，可能会影响测试进度。