您的当前位置:首页正文

UAT测试计划

2023-01-15 来源:汇智旅游网


UAT测试计划

XXX管理系统

UAT测试计划

1 介绍 .......................................................................... 7 2 用户接受测试准备 .................................................. 7

2.1建立测试环境 7 2.2培训前提 8 2.3用户接受测试数据 8 2.4用户接受测试成员 8 2.5准备工作安排 9

3 执行测试 .................................................................. 9

3.1测试类型和测试种类 9

3.1.1系统安装 10 3.1.2用户接受测试 10

3.1.3非功能性用户接受测试 10 3.1.4测试文档 10 3.1.5其他测试 10

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

10

3.3测试工具 11 3.4测试日期 12

4 接受标准 ................................................................ 12

4.1用户接受测试(通过/失败)标准 12

4.2中止标准和恢复条件 13

5 缺陷跟踪和汇报 .................................................... 13

5.1报告测试事件 13 5.2异常处理 14

5.3测试过程计划和跟踪 14

6 附件 ........................................................................ 16

6.1附录 I 17 6.2附录 II 17

1 介绍

本文档是为实现XXX管理系统上线所计划进行的用户接受测试计划文档,包含以下方面的内容: • 安排撰写用户接受测试用例的日期

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

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

• 安排进行测试,汇报测试结果和重新测试(如果需要的话)的日期

2 用户接受测试准备

2.1 建立测试环境

软件环境:测试环境的软件环境与生产环境具有相同的产品和工具。测试环境于2014年10月10日可用。

测试环境:

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

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

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

▪ 研发团队负责测试环境的功能验证 ▪ 测试团队通过应用程序及专有账户访问测试环境

2.2 培训前提

对参与测试的用户,会提前进行统一的系统培训,包括如何登陆,如何配合测试用例进行相关操作,如何记录发现问题等相关事宜。因为最终用户已经对测试的业务需求及业务功能有一定了解,会特别针对访问应用程序和熟悉了解测试环境进行培训。 测试的培训于10/8/2014开始,为期1天, 参与人员包括参与测试的所有的业务用户。

2.3 用户接受测试数据

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

2.4 用户接受测试成员

参与UAT测试的人员详细信息 (姓名, 电子邮

件, 职务, 角色)如下: 序号 电子邮件 2.5 准备工作安排

职务 角色 下面是参加XXX管理系统用户接受测试的系列动作的概述:

• 建立测试环境,进行测试环境功能验证。 • 确定测试人员名单。

• 为测试人员分配系统测试账户及密码。 • 交付测试脚本(Test Case)给测试人员。 • 客户端环境准备,可联系IT核实客户端环境是否已经符合要求。

3 执行测试

3.1 测试类型和测试种类

测试类型为用户接受测试(UAT),UAT所涵盖的测试案例包括:

分类 序号 测试案例 描述

登录\\1 登出 2 3.1.1 系统安装 登录系统 登出系统 客户端需要预先安装JDK 1.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插件 JDK_1.6.0.22 IE 8.0以上的版Win7_64bit 本 同时客户端环境需要安装如下工具和软件:

Microsoft Word2003、2007、2010 Microsoft Powerpoint2003、2007、2010 Microsoft Excel2003、2007、2010 MS IE7.0以上的版本 3.4 测试日期

测试阶段 用户接受测试 开始日期 结束日期 4 接受标准

4.1 用户接受测试(通过/失败)标准

如果每个测试案例实际结果和预期一致就认为该案例测试结果通过, 如果不一致就认为失败。 测试失败的案例将记录到测试报道中做追踪。

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

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

阶段 严重 错误允许数量 高 中 低 用户接受<=0.5<=0.1% <=1% <=2% % 测试 利益相关人决定根据上述条件,决定在测试阶段是否接受应用。

4.2 中止标准和恢复条件

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

5 缺陷跟踪和汇报

5.1 报告测试事件

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

从测试第一天起, 测试团队发送电子邮件将每日报告给测试经理。报告中包含总结以下内容:

测试周期执行的用例总数 累计所有测试周期测试用例总数 当日要执行的测试用例数目 当日已执行的测试用例数目

高,累计的开放的缺陷数目(严重, 中, 低) 当日生成的缺陷数目(严重, 高, 中, 低) 附录2详细解释了缺陷解决过程

5.2 异常处理

缺陷指定给不同的人员来解决。 开发人员解决缺陷后, 会再测试一遍并更新状态。 缺陷严重性分为:

• 严重

• 高 • 中 • 低

所有严重缺陷立即汇报给相关人员/团队以保证最早暴露问题与解决问题。 请参阅附录1的缺陷分类和附录2的缺陷解决过程。

5.3 测试过程计划和跟踪

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

到测试问题记录文件中。

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

UAT相关的活动安排如下:

序号 任务描述 开始日期 结束日期 负责人员 辅助人员 1 测试计划安2014.07.13 2014.07.16 徐排与文档撰建写 芳 2 测试案例撰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会更正改缺陷。 • 如果开发团队无法重现缺陷, 就将状态改为”Not able to reproduce”。 测试团队会尝试重现缺陷并提供额外信息帮助开发团队。 • 如果测试期间出现任何事件, 测试团队可联络

实施团队。

因篇幅问题不能全部显示,请点此查看更多更全内容