系统测试方案VWord下载.doc
《系统测试方案VWord下载.doc》由会员分享，可在线阅读，更多相关《系统测试方案VWord下载.doc（17页珍藏版）》请在冰点文库上搜索。
第九章测试度量管理计划 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-新建
测试人员在测试过程中发现缺陷，提交新的缺陷给开发组长进行审核
2-打开
开发组长进行判定认定为有效缺陷，并将缺陷分配给具体的开发人员进行修改
3-已修正
开发人员已完成修正,等待测试人员进行回归测试
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测试执行准入标准
当达到如下条件时，系统测试可进入正式的测试执行阶段：
测试环境准备就绪
开发方已提交经过内部测试的稳定版本并部署到系统测试环境
开发方已提交相关技术文档（需求文档、设计文档、用户说明书等）及内部测试的相关文档（测试方案、测试案例、测试报告等）
内部测试中测试案例应记录测试执行结果，测试范围应和需求文档、设计文档一致；
如有不一致，开发方应对不一致项进行说明，并经过行方项目经理认可或通过评审
冒烟测试通过
（注：
冒烟测试是对测试对象进行功能快速抽查的一种测试类型。
它主要用于执行测试入口标准的印证，也称绿灯测试、连通性测试。
）
5.2测试中止条件
测试过程中，如发生以下任何一种情况，则中止测试活动，并及时通知开发方：
发现程序不是最新版本
主要模块功能不能正常运行，且影响其它模块的功能测试
业务需求出现较大变更，程序也需要修改
开发方修改时间及新版本发布时间由业务方、开发方、测试方三方商定，修改完成后继续进行测试。
5.3测试准出标准
达到下述条件，可结束本次系统测试：
严重级别以上的所有缺陷均已修复并复测通过，总体缺陷修复率在90%以上，未修复缺陷均有暂缓修复说明
已完成该阶段全部测试案例的运行，提交的系统测试报告经各方评审通过
所有测试工作产品均已提交并通过审核
第六章测试资源
6.1人力资源
通过XX软件在金融应用测试领域的基于功能点测试工作量评估模型（FPA），本次测试投入的总工作量约为XX人月（不包括UAT测试）。
考虑到项目测试实施工期很短，为减少沟通成本，提高执行效率，在测试需求和案例编写阶段，XX公司申请中高端测试人员，其余人员由行方调配，在完成测试需求分析和测试案例设计后继续进行测试执行，本次合作测试公司方测试人员共需X人（其中测试需求和测试案例设计阶段X人，测试执行阶段X人），行方需派出项目经理1人，职责如下：
项目角色
人数需求
职责
项目经理
负责承担项目任务的计划、组织和控制工作，以实现项目目标
负责编写系统测试方案、测试报告
监督、统筹及协调测试实施各项活动和任务安排
负责业务方、开发方、测试方的协调
负责向项目管理机构定期报告项目进展情况
协助进行测试环境准备、测试数据准备、测试版本部署等支持工作
审核系统测试方案、测试案例、测试报告
高级测试工程师
协助项目经理完成项目任务的计划、组织和控制工作
协助项目经理编写系统测试方案、测试报告
测试需求分析
测试案例设计
测试执行，提交缺陷，复测缺陷
系统测试案例审核
中级测试工程师
测试数据需求整理
协助编写系统测试报告
初级测试工程师
简单测试案例设计
测试数据准备
配置管理和测试工具管理工程师
测试管理工具ALM安装、配置和管理
配置管理工具SVN安装、配置和管理
导出测试缺陷日报
在ALM中录入开发组、决策组缺陷处理结果
测试数据需求整理汇总
6.2测试环境
列示本次测试的软、硬件测试环境。
资源名
服务器型号
操作系统
应用软件
网络地址
应用服务器
数据库服务器
6.3测试工具
在本次XX系统测试实施过程中，拟采用的测试工具包括：
用途
工具名称/版本
厂商
说明
测试管理工具
ALM
HP
管理测试需求、测试案例及测试执行、测试缺陷
配置管理工具
SVN
开源
测试文档版本管理
第七章测试进度计划
说明本次测试的详细进度计划，对应的测试人员资源，建议采用Project显示。
第八章沟通管理计划
说明本项目约定的沟通方式的组织者、参与人员、时间频度及产出物等内容。
沟通方式
组织者
参与人员
时间频度
产出物
项目日例会
测试项目经理
测试人员；
每个工作日上午9点
无
项目例会
周例会形式或根据项目情况按需召开；
会议纪要
项目协调会
测试团队负责人；
业务人员、开发人员、开发技术经理、环境管理人员以及各部门领导等（按需可选）
根据项目情况按需召开；
项目评审会
业务人员、开发人员、环境管理人员以及各部门领导等（按需可选）
评审表
会议纪要（可选）
说明本项目约定的各类报告，会议纪要的填写人、提交时间及接收人等内容。
文档名称
填写人
提交时间
接收人
工作日志
测试人员
每个工作日下班之前
项目进度报告
每周五12点之前
测试负责人
测试项目经理指定填写人
每次会议结束后第二个工作日下班前
以上的提交时间如遇国家法定节假日，需要提前提交。
第九章测试度量管理计划
现阶段制定的测试度量TPI的对应基础数据以及数据来源和说明，测试项目经理负责统一收集汇总下表中列出的所有度量基础数据，将收集到的所有基础数据填入《度量数据收集汇总表模板》中，自动计算得出TPI值。
基础数据
数据来源
项目计划总人时
有案例设计的测试需求规则点数量
测试需求
测试案例总数
系统测试案例
全部测试需求规则点数量
系统测试需求
案例设计实际总人时
执行案例实际总人时
执行案例总数
系统测试报告
缺陷总数
已关闭缺陷总数
挂起缺陷总数
11
伪缺陷总数
12
执行通过的案例总数
13
执行过的案例数
14
严重缺陷数量
15
致命缺陷数量
16
项目实际总人时
17
系统测试阶段有效缺陷总数
18
用户验收阶段有效缺陷总数
用户验收测试报告
19
试运行阶段有效缺陷总数
开发人员提供
第十章测试风险管理
测试风险管理是对影响项目测试的各种可能发生的风险进行识别和评估，分析其发生概率及发生后对项目的影响程度，提出规避方法和应对计划，从而有效规避测试风险，在风险发生时采取必要的补救措施使损失减少到最低限度。
风险类型
风险描述
发生概率
风险影响
规避方法
被测系统文档不全面
高
中等
提醒并协调开发方补充重要文档
测试环境
系统测试和用户验收测试同时进行，共用测试环境引起的冲突
和用户验收测试使用不同的机构和用户数据进行测试
测试环境部署不完整，缺乏第三方系统模拟器或模拟器功能有限，交易无返回报文
严重
对所有涉及到第三方的交易进行分析，并根据本次改版影响域分析及现有模拟器情况制定测试方案
测试版本
测试过程中出现版本变更情况，测试版本与最终版本不一致
测试版本按计划统一发布，并启用版本发布通知制度
测试执行
测试中发现系统缺陷，改动的影响域较大，需要较长时间的修改、调优时间
中
加强系统内部测试，及早发现严重问题
测试管理
测试规模、工作量和进度估计不准确
细化测试需求；
多和业务方、开发方沟通讨论；
加强评审的作用
因人员离职、请假突发事件导致的测试进度延迟
低
加强人员储备，及早了解项目组人员状态
第十一章测试交付物
交付物名称
责任人
交付时间
交付方式
电子文档、邮件
测试案例
测试缺陷
升级会员 