标签：评估   性问题   结果   发布   上线   要求   列表   不同   控制   

导航目录

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 测试目标

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

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

2.2 测试范围

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

2.3 测试资源

2.3.1 测试人力资源

2.3.2 测试环境

2.3.3 BUG管理工具

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

3 测试规范

3.1 测试接收标准

3.2 BUG规范

测试人员提交缺陷记录时，应清晰、准确地描述缺陷发生的条件和步骤，并
设置缺陷的严重等级如下：

4 测试策略

4.1 测试流程及工作量估算

4.2 测试种类

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

4.2.1 功能测试

功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接收、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。

4.2.2 容错性测试

容错性测试主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复手段。

4.2.3 易用性测试

易用性测试是指用户使用软件时是否感觉方便，比如是否最多点击鼠标三次就可以达到用户的目的。易用性测试应当集中体现在界面美观、功能实用、处理有效几个方面。

4.2.4 UI（界面）测试

用户界面（UI）测试主要用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。

4.2.5 接口测试

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

接口测试也属于功能测试，测试流程是首先根据接口文档编写测试用例（用例编写可以按照功能测试的规则来编写，例如等价类划分，边界值等设计方法），然后执行测试，查看不同的参数请求，判断接口的返回数据是否达到预期，可能需要转换接口数据格式，常见为json格式，并且需根据需求支持一种或多种接口请求方式（例如GET请求、POST请求等），请求协议为http或https等。

4.2.6 系统测试

系统测试主要目的为检测系统是否达到需求对业务流程及数据流的处理是否符合标准，检测系统对业务流处理是否存在逻辑不严谨及错误，检测需求是否存在不合理的标准及要求。此阶段测试是基于功能测试完成的情况下。

4.2.7 兼容性测试

兼容性测试主要检验被测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行测试。

4.2.8 性能测试

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。性能测试是为了验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。性能测试一般包括以下几种类型：

1. 基准测试：在给系统施加较低压力时，查看系统的运行状况并记录相关数据做为基础参考。
2. 负载测试：是指对系统不断地增加压力或持续一段时间增加一定压力，直到系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。
3. 压力测试：压力测试是评估系统处于或超过预期负载时系统的运行情况，关注系统在峰值负载时或超出最大负载情况下的处理能力。
4. 稳定性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
5. 并发测试：测试多个用户同时访问同一个应用、同一个模块或者数据记录时，是否存在死锁或者其他性能问题。

4.2.9 安装卸载测试

安装卸载测试是为了确保该软件在正常情况和异常情况的不同条件下（例如，进行首次安装、升级、完整的或自定义的安装，卸载重安装等）都能成功进行安装，异常情况包括磁盘空间不足、缺少目录创建权限等，核实软件在安装后可立即正常运行，核实软件可以正常进行卸载。

5 发布标准

5.1 测试输出文档

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

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

5.2 测试完成标准

本次测试过程中，计划测试完成的标准如下：

1. 需求规格说明书中的需求必须全部实现并测试通过。
2. 主流程畅通，系统没有一类和二类Bug（参考3.2 BUG规范），没有影响用户正常使用的BUG。
3. 所有功能和性能测试用例100％执行完成。
4. 剩余三类四类有争议的bug，如果无法达成一致，测试人员需与产品、开发、项目经理开会讨论决定是否遗留有争议的Bug，若最终决定项目上线时有遗留BUG，需将BUG说明附在测试结果报告里，给出原因或最终解决方案。
5. 测试报告编写完成，测试收尾工作结束。
6. 项目处于试运行或上线阶段。

5.3 产品发布标准

本次测试过程中，计划产品发布上线的标准如下：

1. 按照交互文档、需求文档完全的实现需求。
2. 符合交互稿的交互设计规范、符合视觉要求，并已经通过设计评审。
3. 核心代码100％经过代码Review。
4. 允许遗留可能会对用户正常使用造成一定影响的三类、四类缺陷，但应在发布前告知项目组，并经风险评估一致同意发布后方可发布。

6 测试风险

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

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

测试计划的设计和编写

标签：评估   性问题   结果   发布   上线   要求   列表   不同   控制   

原文地址：https://www.cnblogs.com/taozhen/p/14781057.html