系统测试方案V.doc

系统测试方案V.doc

《系统测试方案V.doc》由会员分享，可在线阅读，更多相关《系统测试方案V.doc（17页珍藏版）》请在冰豆网上搜索。

系统测试方案

XXXXXX

系统测试方案

制作单位：

XXXXXXX

文档编号:

（按照XXXXXX文档资料统一编码规则编制文档编号，由XXXX填写）

版本号:

（按照XXXXXXX关于版本号管理的有关规定填写，由科技部门填写）

负责人（技术）:

编写人员:

（参加需求编写的所有人员,包括业务部门参加人员、软件中心参加人员）

校对人员:

修订记录

日期

版本

修订内容描述

作者

审核人

目录

第一章概述 5

1.1文档目的 5

1.2项目背景 5

1.3参考资料 5

第二章测试目标 5

第三章测试范围 5

3.1功能点正确性测试 5

3.2界面整体性测试 7

3.3业务流程正确性测试 7

3.4基本产品的配置测试 8

第四章测试策略 8

4.1测试实施流程 8

4.2测试需求分析方法 9

4.3测试案例编写策略 10

4.4测试数据申请策略 10

4.5测试执行管理策略 10

4.6测试问题/缺陷管理 10

4.7测试效率保证策略 12

第五章测试约束 12

5.1测试执行准入标准 12

5.2测试中止条件 13

5.3测试准出标准 13

第六章测试资源 13

6.1人力资源 13

6.2测试环境 14

6.3测试工具 14

第七章测试进度计划 15

第八章沟通管理计划 15

第九章测试度量管理计划 16

第十章测试风险管理 17

第十一章测试交付物 17

4

第一章概述

1.1文档目的

描述文档编写的主要目的。

1.2项目背景

描述项目发生的背景。

1.3参考资料

序号

资料名称

版本号

编写单位

1

2

3

第二章测试目标

本测试的目标是保证XX系统所有功能完成的正确性并验证现有的XX产品及流程正确的执行，分析是否符合业务需求说明书指定的功能。

具体包括：

Ø检查XX系统所有功能点的正确性，在系统上线前尽可能多地发现系统缺陷并进行修正。

Ø验证XX系统基本产品及其流程的合理性和一致性，满足产品目前的要求及未来的发展需求。

第三章测试范围

3.1功能点正确性测试

对XX系统的XX个功能点进行全面的测试，设计尽可能详细的测试案例进行测试，功能点如下：

一级需求

二级需求

三级需求

卡管理模块

该功能涉及的交易

生成制卡文件

主卡开卡

卡信息重写

销卡

随机换卡

卡片激活

卡挂失补发

卡收回交易

补开电子现金账户

补换电子现金账户

补销电子现金账户

电子现金销户撤销

卡回收撤销

圈存写卡不明客户申诉

圈存申诉结果查询

电子现金类交易

该功能涉及的交易

电子现金圈存

电子现金圈存当日明细查询

电子现金圈存冲销

电子现金圈提

电子现金圈提确认

单笔预约圈存

卡片参数修改（电子现金限额修改）

主机信息查询

查询客户名下XX卡信息

电子现金交易明细查询

芯片余额及芯片明细信息查询

业务管理类（XX管理平台）

卡产品管理

卡类别管理

卡种管理

卡种渠道交易权限管理

卡种渠道交易限额管理

卡种手续费管理

手续费管理

手续费计算方法维护

手续费收取标准查询维护

批量功能说明

业务批处理功能

对账

银联脱机消费批量处理

银联联机退货批量处理

脱机清算周期后处理

证书到期处理

数据准备制卡处理

银联差错交易批量处理

日终对账后自动调账处理

系统批处理功能

日切处理

机构总分关系同步

报表生成

贷记卡新增柜面需求

贷记卡指定账户圈存

贷记卡圈存撤消

贷记卡圈存冲正

贷记卡圈提

贷记卡圈提撤消

贷记卡圈提确认

金融异常状态处理需求

圈存差错处理

需处理差错情况列表

预约圈存差错处理

需处理差错情况列表

圈提差错处理

需处理差错情况列表

对账处理需求

对账规则

对账机制

差错调账分析

批量调账处理

对账处理需求

对账机制

手续费需求

借记卡手续费标准

银联商户资金清算核算需求

本行商户（我行的单位客户）收款会计核算

他行商户（他行单位账户）收款会计核算

银联脱机消费批量处理需求

银联脱机消费

银联消费退货

脱机退货

联机退货

手工退货

报表需求

电子现金交易统计表

电子现金余额统计表

电子现金交易手续费统计表

发卡统计表

换卡统计表

销卡统计表

工本费手续费统计表

3.2界面整体性测试

界面整体性测试包括如下测试内容：

Ø各功能区界面一致性检查

Ø非功能区页面功能正确性检查（包括登录页面、页面公共区域）

Ø页面输入项校验规则检查

Ø页面公共按钮功能检查

3.3业务流程正确性测试

对被测系统业务中的功能所涉及的基本流程进行全面、正确性测试，由于流程测试涉及到多个岗位及每个岗位的功能、职责，覆盖的业务知识较多，需要进行详尽、全面、合理、仔细的进行案例设计。

3.4基本产品的配置测试

对行里的基本产品进行配置，并通过业务流程进行测试产品功能和实施流程的正确性。

第四章测试策略

4.1测试实施流程

本次XX系统测试采用标准测试流程进行实施，包括5个主要测试阶段和过程：

Ø测试计划：

制订测试方案/测试进度计划

Ø测试需求分析：

根据业务需求及需求说明书整理测试需求，对业务需求或需求说明书进行测试并提交缺陷记录

Ø测试案例设计：

根据测试需求设计测试案例

Ø测试执行：

执行已评审的测试案例并提交软件缺陷、复测缺陷

Ø测试总结：

分析测试执行结果和数据，编写测试报告

测试实施流程图

测试实施过程中的产出物，包括测试需求、测试案例、测试执行结果、测试缺陷，使用HP公司的QualityCenter进行统一管理，并实现各测试资产之间的关联。

4.2测试需求分析方法

根据行方提供的XX系统的需求文档及开发方的XX系统模型，对XX的各个功能点和业务流程进行分析，测试需求分析结果至少应包括如下内容：

Ø功能点分析

Ø业务规则约束

Ø业务流程分析

Ø产品功能分析

测试需求分析结果统一记录在测试管理工具QualityCenter（试用版）中，便于和案例、缺陷的关联以及测试度量指标的统计分析。

在测试需求分析阶段，测试人员需要对业务需求或需求说明书进行测试，并提交缺陷记录。

4.3测试案例编写策略

根据测试需求分析结果有所侧重的原则

在测试需求分析结果的基础上，根据系统功能点和业务流程的特点，在测试案例设计时应有不同侧重：

对系统功能点：

需求功能点尽可能多的测试案例进行验证，包括正案例、反案例、边界值案例等

对业务流程：

应根据产品规则的约束和岗位的职责设计尽可能多的流程测试案例，以验证办理一个产品从开始到结束的所有过程的正确性

冒烟测试案例设计

对重要功能点和基本产品的业务流程，应设计一个基本功能检查案例，用于系统测试进入标准中的冒烟测试检查。

测试案例管理

测试案例统一记录在测试管理工具QualityCenter（试用版）中，便于和需求、缺陷关联以及测试度量指标的统计分析，也利于测试执行管理。

4.4测试数据申请策略

要求测试人员在测试需求分析阶段开始着手准备测试数据。

测试人员根据测试需求分析和测试案例设计时的数据需求，整理出对被测系统及关联的外围系统功能测试账号等方面的类型要求和数量需求，统一汇总后按照测试数据申请流程进行申请。

4.5测试执行管理策略

Ø测试轮次安排策略

本次XX系统测试执行过程共分为4个轮次：

ü第1轮：

冒烟测试执行（执行检查系统基本功能的冒烟测试案例）

ü第2轮：

功能点全面测试执行（执行除冒烟测试案例之外所有功能点案例）

ü第3轮：

业务流程测试执行（执行除冒烟测试案例之外所有业务流程案例）

ü第4轮：

系统全面测试（带生产数据）

Ø测试结果验证策略

对测试结果的正确性验证主要通过XX系统界面显示和流程流转等验证的方式，若因环境因素等各种原因确需其他系统配合通过日志检查报文或通过柜面前端查询等方式进行结果验证时，须提出申请由测试中心进行协调和沟通。

测试结果记录

测试执行计划、测试日志、测试执行结果均在测试管理工具QualityCenter（试用版）中进行记录，实现测试资产的统一管理。

4.6测试问题/缺陷管理

测试人员发现的测试缺陷，测试组与业务、开发需要定期/不定期的进行确认。

Ø缺陷管理工具

本次XX系统测试的问题/缺陷使用测试管理工具QualityCenter的缺陷管理模块进行统一管理。

缺陷管理流程图

注：

仲裁组由开发项目经理、业务人员和测试项目经理组成。

Ø缺陷状态定义

序号

缺陷状态

缺陷状态描述

备注

1

1-新建

测试人员在测试过程中发现缺陷，提交新的缺陷给开发组长进行审核

2

2-打开

开发组长进行判定认定为有效缺陷，并将缺陷分配给具体的开发人员进行修改

3

3-已修正

开发人员已完成修正,等待测试人员进行回归测试

4

4-已关闭

缺陷通过测试人员回归测试，缺陷已被修复

5

A-回归失败

缺陷未通过测试人员回归测试，缺陷未被修复

6

B-拒绝

拒绝修改缺陷，该缺陷可能由于测试人员理解错误或属于重复提交的缺陷，开发组长和开发人员都可以拒绝，拒绝的缺陷需要由仲裁者（一般为项目经理和测试经理）判定后才能认定为伪缺陷。

7

C-挂起

项目经理判定该缺陷不在当前版本进行修复，而在未来版本进行修复

8

D-重新打开

C-挂起的缺陷在条件允许后可重新打开供开发人员进行修复

9

E-伪缺陷

仲裁者（一般为开发项目经理和业务人员）对B-拒绝的缺陷进行判定后，认定该缺陷确实是由于测试人员理解问题或者重复缺陷等原因导致的无效缺陷（伪缺陷）

10

F-内审通过

测试组长判断是缺陷，指派给开发组长

测试组长专用

Ø缺陷严重程度定义及响应时间

1-紧急：

2-3小时（需测试组长跟开发组长做口头提醒/电话）

2-非常高：

1天内（需测试组长跟开发组长做口头提醒/电话,Mail）

3-高：

3天内

4-中：

5天内

5-低：

5天以上

4.7测试效率保证策略

迭代测试的策略

由于本次系统测试时间紧，任务重，留给测试设计的时间不长，在具备测试环境条件的情况下尽早开始测试执行，同时抓紧时间完善测试案例执行完整测试，测试执行分轮次进行。

保证重点的策略

本次XX系统的测试重点是系统提供的所有功能点和业务流程，对测试需求按业务和产品的重要性做优先级分类，在时间或条件有限的情况下，先保证优先级高的功能点和业务流程完成测试，以保障项目进度。

第五章测试约束

5.1测试执行准入标准

当达到如下条件时，系统测试可进入正式的测试执行阶段：

Ø测试环境准备就绪

Ø开发方已提交经过内部测试的稳定版本并部署到系统测试环境

Ø开发方已提交相关技术文档（需求文档、设计文档、用户说明书等）及内部测试的相关文档（测试方案、测试案例、测试报告等）

Ø内部测试中测试案例应记录测试执行结果，测试范围应和需求文档、设计文档一致；如有不一