系统测试方案V.doc

1、 系统测试方案XXXXXX系统测试方案制作单位：XXXXXXX文档编号:(按照XXXXXX文档资料统一编码规则编制文档编号，由XXXX填写)版本号:（按照XXXXXXX关于版本号管理的有关规定填写，由科技部门填写）负责人（技术）:编写人员: (参加需求编写的所有人员,包括业务部门参加人员、软件中心参加人员)校对人员:修 订 记 录日期版本修订内容描述作者审核人目 录第一章 概述51.1文档目的51.2项目背景51.3参考资料5第二章 测试目标5第三章 测试范围53.1功能点正确性测试53.2界面整体性测试73.3业务流程正确性测试73.4基本产品的配置测试8第四章 测试策略84.1测试实施流程

2、84.2测试需求分析方法94.3测试案例编写策略104.4测试数据申请策略104.5测试执行管理策略104.6测试问题/缺陷管理104.7测试效率保证策略12第五章 测试约束125.1测试执行准入标准125.2测试中止条件135.3测试准出标准13第六章 测试资源136.1人力资源136.2测试环境146.3测试工具14第七章 测试进度计划15第八章 沟通管理计划15第九章 测试度量管理计划16第十章 测试风险管理17第十一章 测试交付物174第一章 概述1.1文档目的描述文档编写的主要目的。1.2项目背景描述项目发生的背景。1.3参考资料序号资料名称版本号编写单位123第二章 测试目标本测试

3、的目标是保证XX系统所有功能完成的正确性并验证现有的XX产品及流程正确的执行，分析是否符合业务需求说明书指定的功能。具体包括： 检查XX系统所有功能点的正确性，在系统上线前尽可能多地发现系统缺陷并进行修正。 验证XX系统基本产品及其流程的合理性和一致性，满足产品目前的要求及未来的发展需求。第三章 测试范围3.1功能点正确性测试对XX系统的XX个功能点进行全面的测试，设计尽可能详细的测试案例进行测试，功能点如下： 一级需求二级需求三级需求卡管理模块该功能涉及的交易生成制卡文件主卡开卡卡信息重写销卡随机换卡卡片激活卡挂失补发卡收回交易补开电子现金账户补换电子现金账户补销电子现金账户电子现金销户撤销

4、卡回收撤销圈存写卡不明客户申诉圈存申诉结果查询电子现金类交易该功能涉及的交易电子现金圈存电子现金圈存当日明细查询电子现金圈存冲销电子现金圈提电子现金圈提确认单笔预约圈存卡片参数修改（电子现金限额修改）主机信息查询查询客户名下XX卡信息电子现金交易明细查询芯片余额及芯片明细信息查询业务管理类（XX管理平台）卡产品管理卡类别管理卡种管理卡种渠道交易权限管理卡种渠道交易限额管理卡种手续费管理手续费管理手续费计算方法维护手续费收取标准查询维护批量功能说明业务批处理功能对账银联脱机消费批量处理银联联机退货批量处理脱机清算周期后处理证书到期处理数据准备制卡处理银联差错交易批量处理日终对账后自动调账处理系统

5、批处理功能日切处理机构总分关系同步报表生成贷记卡新增柜面需求贷记卡指定账户圈存贷记卡圈存撤消贷记卡圈存冲正贷记卡圈提贷记卡圈提撤消贷记卡圈提确认金融异常状态处理需求圈存差错处理需处理差错情况列表预约圈存差错处理需处理差错情况列表圈提差错处理需处理差错情况列表对账处理需求对账规则对账机制差错调账分析批量调账处理对账处理需求对账机制手续费需求借记卡手续费标准银联商户资金清算核算需求本行商户（我行的单位客户）收款会计核算他行商户（他行单位账户）收款会计核算银联脱机消费批量处理需求银联脱机消费银联消费退货脱机退货联机退货手工退货报表需求电子现金交易统计表电子现金余额统计表电子现金交易手续费统计表发卡统

6、计表换卡统计表销卡统计表工本费手续费统计表3.2界面整体性测试界面整体性测试包括如下测试内容： 各功能区界面一致性检查 非功能区页面功能正确性检查(包括登录页面、页面公共区域) 页面输入项校验规则检查 页面公共按钮功能检查3.3业务流程正确性测试对被测系统业务中的功能所涉及的基本流程进行全面、正确性测试，由于流程测试涉及到多个岗位及每个岗位的功能、职责，覆盖的业务知识较多，需要进行详尽、全面、合理、仔细的进行案例设计。3.4基本产品的配置测试对行里的基本产品进行配置，并通过业务流程进行测试产品功能和实施流程的正确性。第四章 测试策略4.1测试实施流程本次XX系统测试采用标准测试流程进行实施，包

7、括5个主要测试阶段和过程： 测试计划：制订测试方案/测试进度计划 测试需求分析：根据业务需求及需求说明书整理测试需求，对业务需求或需求说明书进行测试并提交缺陷记录 测试案例设计：根据测试需求设计测试案例 测试执行：执行已评审的测试案例并提交软件缺陷、复测缺陷 测试总结：分析测试执行结果和数据，编写测试报告测试实施流程图测试实施过程中的产出物，包括测试需求、测试案例、测试执行结果、测试缺陷，使用HP公司的Quality Center进行统一管理，并实现各测试资产之间的关联。4.2测试需求分析方法根据行方提供的XX系统的需求文档及开发方的XX系统模型，对XX的各个功能点和业务流程进行分析，测试需求

8、分析结果至少应包括如下内容： 功能点分析 业务规则约束 业务流程分析 产品功能分析测试需求分析结果统一记录在测试管理工具Quality Center(试用版)中，便于和案例、缺陷的关联以及测试度量指标的统计分析。在测试需求分析阶段，测试人员需要对业务需求或需求说明书进行测试，并提交缺陷记录。4.3测试案例编写策略根据测试需求分析结果有所侧重的原则在测试需求分析结果的基础上，根据系统功能点和业务流程的特点，在测试案例设计时应有不同侧重：对系统功能点：需求功能点尽可能多的测试案例进行验证，包括正案例、反案例、边界值案例等对业务流程：应根据产品规则的约束和岗位的职责设计尽可能多的流程测试案例，以验证

9、办理一个产品从开始到结束的所有过程的正确性冒烟测试案例设计对重要功能点和基本产品的业务流程，应设计一个基本功能检查案例，用于系统测试进入标准中的冒烟测试检查。测试案例管理测试案例统一记录在测试管理工具Quality Center(试用版)中，便于和需求、缺陷关联以及测试度量指标的统计分析，也利于测试执行管理。4.4测试数据申请策略要求测试人员在测试需求分析阶段开始着手准备测试数据。测试人员根据测试需求分析和测试案例设计时的数据需求，整理出对被测系统及关联的外围系统功能测试账号等方面的类型要求和数量需求，统一汇总后按照测试数据申请流程进行申请。4.5测试执行管理策略 测试轮次安排策略本次XX系统

10、测试执行过程共分为4个轮次： 第1轮：冒烟测试执行(执行检查系统基本功能的冒烟测试案例) 第2轮：功能点全面测试执行(执行除冒烟测试案例之外所有功能点案例) 第3轮：业务流程测试执行(执行除冒烟测试案例之外所有业务流程案例) 第4轮：系统全面测试(带生产数据) 测试结果验证策略对测试结果的正确性验证主要通过XX系统界面显示和流程流转等验证的方式，若因环境因素等各种原因确需其他系统配合通过日志检查报文或通过柜面前端查询等方式进行结果验证时，须提出申请由测试中心进行协调和沟通。 测试结果记录测试执行计划、测试日志、测试执行结果均在测试管理工具Quality Center(试用版)中进行记录，实现测

11、试资产的统一管理。4.6测试问题/缺陷管理测试人员发现的测试缺陷，测试组与业务、开发需要定期/不定期的进行确认。 缺陷管理工具本次XX系统测试的问题/缺陷使用测试管理工具Quality Center的缺陷管理模块进行统一管理。缺陷管理流程图注：仲裁组由开发项目经理、业务人员和测试项目经理组成。 缺陷状态定义序号缺陷状态缺陷状态描述备注11-新建测试人员在测试过程中发现缺陷，提交新的缺陷给开发组长进行审核22-打开开发组长进行判定认定为有效缺陷，并将缺陷分配给具体的开发人员进行修改33-已修正开发人员已完成修正,等待测试人员进行回归测试44-已关闭缺陷通过测试人员回归测试，缺陷已被修复5A-回归

12、失败缺陷未通过测试人员回归测试，缺陷未被修复6B-拒绝拒绝修改缺陷，该缺陷可能由于测试人员理解错误或属于重复提交的缺陷，开发组长和开发人员都可以拒绝，拒绝的缺陷需要由仲裁者（一般为项目经理和测试经理）判定后才能认定为伪缺陷。 7C-挂起项目经理判定该缺陷不在当前版本进行修复，而在未来版本进行修复8D-重新打开C-挂起的缺陷在条件允许后可重新打开供开发人员进行修复9E-伪缺陷仲裁者（一般为开发项目经理和业务人员）对B-拒绝的缺陷进行判定后，认定该缺陷确实是由于测试人员理解问题或者重复缺陷等原因导致的无效缺陷（伪缺陷）10F-内审通过测试组长判断是缺陷，指派给开发组长测试组长专用 缺陷严重程度定义

13、及响应时间1- 紧急：2-3小时（需测试组长跟开发组长做口头提醒/电话）2- 非常高：1天内（需测试组长跟开发组长做口头提醒/电话,Mail）3- 高：3天内4- 中：5天内5- 低：5天以上4.7测试效率保证策略迭代测试的策略由于本次系统测试时间紧，任务重，留给测试设计的时间不长，在具备测试环境条件的情况下尽早开始测试执行，同时抓紧时间完善测试案例执行完整测试，测试执行分轮次进行。保证重点的策略本次XX系统的测试重点是系统提供的所有功能点和业务流程，对测试需求按业务和产品的重要性做优先级分类，在时间或条件有限的情况下，先保证优先级高的功能点和业务流程完成测试，以保障项目进度。第五章 测试约束5.1测试执行准入标准当达到如下条件时，系统测试可进入正式的测试执行阶段： 测试环境准备就绪 开发方已提交经过内部测试的稳定版本并部署到系统测试环境 开发方已提交相关技术文档（需求文档、设计文档、用户说明书等）及内部测试的相关文档（测试方案、测试案例、测试报告等） 内部测试中测试案例应记录测试执行结果，测试范围应和需求文档、设计文档一致；如有不一