UAT测试计划Word文件下载.docx

UAT测试计划Word文件下载.docx

《UAT测试计划Word文件下载.docx》由会员分享，可在线阅读，更多相关《UAT测试计划Word文件下载.docx（9页珍藏版）》请在冰点文库上搜索。

备注

⏹相关文档及参考资料

序号

相关文档

文档位置

版本

日期

1

需求规格说明书

2014-1-30

介绍

本文档是为实现XXX管理系统上线所计划进行的用户接受测试计划文档，包含以下方面的内容：

∙安排撰写用户接受测试用例的日期

∙安排人员培训并建立测试环境，在测试环境中进行测试

∙安排准备测试环境的日期

∙安排进行测试，汇报测试结果和重新测试（如果需要的话）的日期

2用户接受测试准备

2.1建立测试环境

软件环境：

测试环境的软件环境与生产环境具有相同的产品和工具。

测试环境于2014年10月10日可用。

测试环境：

▪用户接受测试在此环境下进行

▪该环境于2014年10月10日就绪

▪研发团队负责把部署代码及程序部署到测试环境

▪研发团队负责测试环境的功能验证

▪测试团队通过应用程序及专有账户访问测试环境

2.2培训前提

对参与测试的用户，会提前进行统一的系统培训，包括如何登陆，如何配合测试用例进行相关操作，如何记录发现问题等相关事宜。

因为最终用户已经对测试的业务需求及业务功能有一定了解，会特别针对访问应用程序和熟悉了解测试环境进行培训。

测试的培训于10/8/2014开始,为期1天，参与人员包括参与测试的所有的业务用户。

2.3用户接受测试数据

用户接受测试的数据由各自业务部门提供。

2.4用户接受测试成员

参与UAT测试的人员详细信息（姓名，电子邮件，职务，角色）如下：

电子邮件

职务

角色

2.5准备工作安排

下面是参加XXX管理系统用户接受测试的系列动作的概述：

∙建立测试环境，进行测试环境功能验证。

∙确定测试人员名单。

∙为测试人员分配系统测试账户及密码。

∙交付测试脚本（TestCase）给测试人员。

∙客户端环境准备，可联系IT核实客户端环境是否已经符合要求。

3执行测试

3.1测试类型和测试种类

测试类型为用户接受测试（UAT），UAT所涵盖的测试案例包括：

分类

测试案例

描述

登录\登出

登录系统

2

登出系统

3.1.1系统安装

客户端需要预先安装JDK1.6.0.22_32bit以上版本。

3.1.2用户接受测试

测试人员需要在Excle提出，并提供必要的截屏和信息，以便开发人员能够分析解决问题。

本次测试范围不包括：

其他非功能性类型的测试，例如存储测试，配置测试，兼容性测试，可靠性测试，恢复测试等等。

3.1.3非功能性用户接受测试

本次测试范围未包括非功能性用户接受测试。

3.1.4测试文档

请参考《XXX管理系统UAT测试用例》文档。

3.1.5其他测试

无。

3.2用户接受测试任务和里程碑

下列是XXX管理系统应用程序相关的具体任务：

1.发布测试计划，明确测试时间及测试人员

2.准备符合所有需求的测试用例

3.执行测试用例/脚本

4.记录测试结果

5.记录上报的问题

6.汇报和记录测试结果

7.测试问题解决，更新测试记录

前提与假设：

（1）测试环境服务器环境为测试系统，客户端及测试工具IT部门负责部署。

（2）测试团队通过公司内部网路访问测试环境。

（3）测试人员在Excle测试报道中进行测试错误和异常情况记录。

3.3测试工具

测试人员使用的操作环境：

浏览器

操作系统

Java插件

IE8.0以上的版本

Win7_64bit

JDK_1.6.0.22

同时客户端环境需要安装如下工具和软件：

MicrosoftWord2003、2007、2010

MicrosoftPowerpoint2003、2007、2010

MicrosoftExcel2003、2007、2010

MSIE7.0以上的版本

3.4测试日期

测试阶段

开始日期

结束日期

用户接受测试

4接受标准

4.1用户接受测试（通过/失败）标准

如果每个测试案例实际结果和预期一致就认为该案例测试结果通过，如果不一致就认为失败。

测试失败的案例将记录到测试报道中做追踪。

在测试完成后，其结果如满足用户需求文档的接受条件将被部署生产应用。

该列表是测试阶段的接受条件：

阶段

错误允许数量

严重

高

中

低

<

=0.1%

=0.5%

=1%

=2%

利益相关人决定根据上述条件，决定在测试阶段是否接受应用。

4.2中止标准和恢复条件

如果应用或相关数据库有重大缺陷，则所有的测试活动被中止，在缺陷改正后测试恢复。

5缺陷跟踪和汇报

5.1报告测试事件

现场测试经理把测试结果定期汇报给项目经理。

从测试第一天起，测试团队发送电子邮件将每日报告给测试经理。

报告中包含总结以下内容：

测试周期执行的用例总数

累计所有测试周期测试用例总数

当日要执行的测试用例数目

当日已执行的测试用例数目

累计的开放的缺陷数目（严重，高，中，低）

当日生成的缺陷数目（严重，高，中，低）

附录2详细解释了缺陷解决过程

5.2异常处理

缺陷指定给不同的人员来解决。

开发人员解决缺陷后，会再测试一遍并更新状态。

缺陷严重性分为：

∙严重

∙高

∙中

∙低

所有严重缺陷立即汇报给相关人员/团队以保证最早暴露问题与解决问题。

请参阅附录1的缺陷分类和附录2的缺陷解决过程。

5.3测试过程计划和跟踪

测试人员按照测试案例指定的操作顺序进行测试，测试过程中如出现意外，即出现与预期的不同结果，请与支持人员联系并将问题重现，由支持人员判别是否是错误，如果判断是错误，统一记录到测试问题记录文件中。

技术人员对测试问题记录文件中的每个问题进行分析，并制定相应的解决方案，指定问题解决人，最后解决日期。

UAT相关的活动安排如下：

任务描述

负责人员

辅助人员

测试计划安排与文档撰写

2014.07.13

2014.07.16

测试案例撰写

2014.07.18

2014.09.30

3

测试系统准备就绪

4

安排测试人员

6

进行第一轮测试

7

第一轮测试结果分析与报告问题

8

修复Bug

9

进行第二轮测试

10

第二轮测试结果分析与报告问题

11

UAT汇总报告

6附件

6.1附录I

严重性

严重缺陷是那些使软件无法达到与需求中描述的功能一致的缺陷，使系统不可用

高严重性缺陷定义为那些使软件无法达到与需求和设计标准中描述的功能一致的，与定义阶段需求严重不同。

中严重性缺陷定义为那些使软件无法达到与需求和设计标准中描述的功能一致的，可能影响应用功能的缺陷。

低严重性缺陷定义为那些使软件无法达到与需求和设计标准中描述的功能一致的，但不严重影响应用的缺陷。

微小性能影响

6.2附录II

缺陷解决

∙测试发现缺陷后就会记录到测试报告中,其初始状态改为”开放”。

∙实施团队每天分析缺陷。

一旦缺陷被认为正常了，就会将缺陷状态改为”Close”

∙一旦缺陷被更正，则开发人员会将缺陷状态改为”已更正”。

所有”已更正”的缺陷信息会在下次测试时进行测试验证。

∙测试团队会再次测试开发团队更正的缺陷。

如果缺陷依然存在，则状态会改为”重新开放”并重新认为是一个缺陷。

如果再次测试成功，测试团队会将状态改为”Close”

∙如果技术负责人认为缺陷不存在，就会改状态为”不是缺陷”并让测试团队再次测试。

如果测试团队认为缺陷存在则PNT会更正改缺陷。

∙如果开发团队无法重现缺陷，就将状态改为”Notabletoreproduce”。

测试团队会尝试重现缺陷并提供额外信息帮助开发团队。

∙如果测试期间出现任何事件，测试团队可联络实施团队。