案例网银测试总体过程总结Word文件下载.docx
《案例网银测试总体过程总结Word文件下载.docx》由会员分享，可在线阅读，更多相关《案例网银测试总体过程总结Word文件下载.docx（46页珍藏版）》请在冰点文库上搜索。
数据移行验收结束后
项目的测试人员、职位、工作职责
李娜
编写测试计划缺陷管理测试结果分析
测试案例编写人员
刘百梅、梁俊杰、易楼、罗志强、高宝石、马嘉鑫、骆竞、赖维君、揭文锋
编写测试用例
测试案例执行人员
执行测试报告缺陷回归缺陷
需要配合的部门与人员
开发人员
协助搭建测试环境，测试版本控制
业务人员
协助测试人员理解需求，提供业务帮助
5.测试工具
测试管理工具为Bugfree
6.人员合作模式
测试案例设计及编写：
-XX银行主导负责
-XX银行对外包人员比例：
1比2
-外包人员：
10人
测试案例执行：
-外包商主导负责
-XX银行对外包人员比例：
1比4
-外包人员需求：
20-25人
7.测试时间安排
1
2011.6.1
用例编写人员入场
用例编写人员入场，人数：
行方已准备好场所、相关设备
测试公司提供入场人员名单及人员职责表
1、行方需提供处理环境、设备问题的相关联系人名单及联系方式
2、用例编写阶段及测试运行时间的验收组会议安排；
加强工作组内协作关系及验收问题讨论等
2
2011.6.1-
2011.6.25
测试用例编写
提取测试要点
1、行方已提供相应的测试需求
2、行方已准备好场所、相关设备
以日为单位提交每日需求确认清单
1、请提供相应的联系人名单及联系方式
2、初审及最终评审由行方执行
3、行方需提供：
多语言版本UI规范文文件、错误代码表及对应客户化提示规范文档、页面输入项控制规范、内管的各统计报表中各指针的统计说明及统计方法；
4、开发提供数据移行转换测试方案；
3
提交测试要点给行方进行初审
测试要点
4
2011.6.25-
用例完善
5
提交测试用例给行方进行最终评审
测试用例
6
2011.7.24
测试数据提出
根据所完成的用例进行测试数据提出
用例已评审通过
测试数据要求
7
2011.7.25
测试执行人员入场
测试执行人员入场，人数：
20-25人
行方需提供处理环境、设备问题的相关联系人名单及联系方式
8
2011.7.25-
测试数据准备
包括硬设备及环境（行方准备）
测试用户分配表
测试数据准备完全后测试公司要给执行人员分配测试用户
9
2011.8.12-
2011.8.14
测试执行前准备工作
1、业务人员培训：
BugFree使用及规范（用例管理及BUG处理流程），测试用例分析及测试执行讲解；
10
2011.8.15-
2011.8.25
测试执行
第一轮：
冒烟测试及通过性测试
开发人员提供可测试版本
1、每日测试进度监控表
2、第一轮测试报告（2011.8.26，12:
00AM前提交）
1、每日的测试进度监控表于次日9:
00AM提交
2、开发人员提供可测试模块及功能点
11
2011.8.26-
2011.9.16
第二轮：
通过性、失效性测试及接口：
联动、页面要素测试
第一轮测试已结束
2、第二轮测试报告（2011.9.17，12:
3、兼容性测试包括：
操作系统包括WindowsXP，Vista，Windows7；
4、多语言测试包括：
中文简体、中文繁体、英文
5、分辨率测试：
包括1024*768，800*600,1280*800的测试
6、在第三轮后进行数据移行测试
12
2011.9.17-
2011.9.30
第三轮：
通过性、失效性及兼容性测试
1、第二轮测试已结束
2、兼容性测试需要的系统及浏览器的提供
2、第三轮测试报告（2011.10.1，12:
13
2011.10.6-
2011.10.16
第四轮：
多语言测试、分辨率测试
1、第三轮测试已结束2、多语言测试版本提供
2、第四轮测试报告（2011.10.17，12:
14
2011.10.17-2011.10.18
第五轮：
封版测试
所有用例都已执行，bug修复率达到95%以上，无“中”等级（包含“中”等级）以上bug存在。
2、项目测试报告（2011.10.19，12:
8.测试用例编写预估数
登入/注销
170
现金管理/
CashManagement
查询/Enquiry
3800
付款/Payments
6200
收款/Receivables
40
定期存款/TimeDeposit
330
货币兑换/CurrencyExchange
630
流动资金管理/LiquidityManagement
维护/Maintenance
530
贸易服务/TradeServices
200
信用卡/CreditCard
470
保险/Insurance
250
投资/Investment
500
强积金/MPF
80
托管/Custody
授权中心/AuthorizationCenter
1000
15
下载中心/DownloadCenter
100
16
管理/Management
900
17
工具/Tools
18
内管
450
19
客户迁移
300
20
公共问题（包含版面风格、网页能适应屏幕大小等公共性问题）
9.测试执行计划（初步估算）
1）测试起止时间、程序封版时间：
XX银行网上银行升级项目测试起始时间为2011年8月15日、封版测试时间为2011年10月20日。
2）测试步骤：
预估用例16760条，计划测试5轮，初步估算执行用例总数为67040条。
第一轮：
2011.8.15-2011.8.25，冒烟测试及通过性测试
第二轮：
2011.8.26-2011.9.16，通过性、失效性测试及接口：
第三轮：
2011.9.17-2011.9.30，通过性、失效性及兼容性测试
第四轮：
2011.10.6-2011.10.16，多语言测试
第五轮：
2011.10.17-2011.10.18，封版测试
注：
以上数据指针均要在环境良好的配合及程序版本稳定情况下才能完成；
不包括每日的回归测试及BUG验证工作；
业务人月需求，仅为网银验收不包括核心验收（未提供核心验收的交易量数据，暂无法估算人月需求）；
说明：
详细的测试计划会在测试用例最终评审后进行详细设计，并出相关文档。
10.测试进程说明
1）测试流程表
2）测试过程描述
a.测试计划阶段
编写测试计划
测试经理根据项目计划与项目业务需求说明书创建测试计划，如果此需求发生变化，则将根据变化更新此项目测试计划。
评审测试计划
项目经理浏览并评审《系统项目测试计划》。
测试经理负责更新此文档。
项目经理负责评审和批准经过更新的文档。
《项目测试计划》的版本为1.0,如果该计划被更新，则版本的序号也随之变更。
测试工程师根据测试计划执行测试任务。
b.测试用例阶段
编写测试用例
分析《软件需求说明书》。
测试工程师根据《软件需求说明书》编写测试用例。
冒烟测试用例需要被同时创建。
评审测试用例
测试组负责评审《测试用例》。
在发现错误或问题的情况下，该测试用例将会被更新。
测试经理负责填写《测试用例评审报告》。
我们将《测试用例》的最初版本定义为1.0，如果该档得到更新，其版本也会被同时更新。
c.测试阶段
冒烟测试
测试工程师负责根据《项目测试用例》进行冒烟测试，执行测试用例的实际输出结果是否符合预期结果，我们将此用例标注为通过或者失败，将结果返回给开发部门。
系统测试
根据《项目测试计划》和《项目测试用例》，测试工程师负责执行测试用例：
当执行测试用例时：
1.如果实际输出结果和预期输出结果相同，该用例需要被标注为通过。
2.如果实际输出结果和预期输出结果不同，该用例需要被标注为失败。
3.所有在测试过程发现的缺陷，需要被提交到BugFree。
测试用例在测试过程中将根据需要得到更新。
测试经理负责分析测试结果，对测试人员执行的测试用例进行一定比率的内部QC（质量控制）。
测试完成时，需得到测试经理的批准。
备注：
所有的缺陷必须被提交到缺陷处理系统BugFree。
d.测试总结阶段
分析和总结测试结果
测试经理总结各自的测试工作并在《项目测试总结》中填写相应的部分内容。
包括测试工具，测试技术，测试体会以及工作质量等。
测试经理负责在《项目测试总结》中分析与总结测试资料，填写包括测试人员工作效率，人力资源消耗，测试过程中经验与教训，评价整个项目过程中的测试质量。
测试完成
测试经理负责批准测试完成。
所有测试人员在《项目测试总结》中签名，证明所有任务都已完成。
3）Bug严重程度定义
Bug等级
解释
建议
1-Low
Low——测试建议
建议性的意见或者建议，未来的增强功能
建议性问题，业务与开发确定是否要接纳
2-Medium
Medium——一般错误，包括：
系统满足主要页面要求，对功能有较小影响
辅助说明描述不清楚
显示格式不规范
根据整个Bug数量及等级进行安排修复，最迟不可超过提交后的第二个版本提交测试
3-High
High——高级错误，包括：
次要功能或过程被中断，结果或行为与预期结果不符
界面错误（详细文档）
打印内容、格式错误
Bug提出后最近一次版本提供测试
4-VeryHigh
VeryHigh——较高级错误，包括：
功能不符
数据流错误
程序接口错
文档中定义的步骤不可行，缺少所记录的功能
1日之内，并及时打版本提供测试
5-Urgent
Urgent——严重错误，包括：
由于程序所引起的死机,非法退出
严重的数值计算错误
阻挡构建或下一步功能测试，影响平行测试的功能
11.测试方法
1）功能类测试
功能类测试是银行项目测试工作中的重点，在各个环节都需要有比较全面的考虑。
先考虑测试案例的组织结构，首先按照功能模块（通常对应系统中的一级菜单）归类，然后针对各功能模块下的每一个具体功能（即有独立页面的功能，简称子功能）再分类，分别设计不同方面的测试案例，案例的组织结构如下：
——“XX模块”
——“XX叶子功能1”
——冒烟测试
——页面要素验证
——必输项验证
——输入项检查
——联动项检查
——本功能流程测试
——通过性测试
——失效性测试
——“XX叶子功能2”
……
——总体规则验证
——数据流转测试
——后台线程测试
数据流转测试和后台线程测试，这两类案例可考虑根据情况，放在某一模块下，或者单独自成一部份。
对这几类测试，做一个简要的说明：
冒烟测试
对本功能正常的主线流程进行验证而设计的案例
此案例专门用来做冒烟测试，通常每个子功能只需提供一条该案例，设计时只需保证该功能的正常操作流程（即仅输入必要的有效数据）通过即可
总体规则
根据需求文文件中提供的总体规则来设计的用例。
主要包括各个功能页面风格的一致性、操作习惯的一致、显示格式的统一等。
通常一个项目的总体规则是固定的，既要保证案例的执行覆盖度，又要避免案例的冗余，所以总体规则可由一个人完成设计，在各个模块下直接复用；
测试执行时，可根据需要来进行执行情况的统计。
页面\必输项验证
执行该功能操作，页面中所必须录入/选择的项目，是否在为空的情况下仍然可以通过提交的检查。
各个页面的必输项不同，要考虑必输项的显示方式，以及非必输项是否也被做了必输限制等。
页面\输入项检查
主要指在客户端所进行的各类输入数据项的合法性的检查。
这部分案例主要指在客户端能够验证或限制的内容，如数据输入长度限制、是否含有非法字符等。
页面\联动项检查
主要指页面中多个输入或选择项目之间，根据前一项的结果而对其他项是否产生了约束的检查。
例如，城市的选择，选择了省之后，其下可选择的市，是否进行了列表更新等。
本功能流程测试
当前功能本身的操作及数据流程正确性的测试，包括正常流程和异常流程。
例如，执行转账操作，输入正确和错误密码是否得到了正确的正常和异常返回结果；
以及显示的返回结果是否与实际结果一致等。
数据流转测试
主要指银行端与客户端之间的数据通讯是否准确，以及企业网银授权、审核流程的数据流转是否正确等。
例如，企业网银在银行端设定某种授权模式，在客户端是否正确体现等；
或银行端修改了客户信息、发布了客户通知等在客户端是否正确体现等。
后台线程测试
验证系统设定的在固定时间自动线程是否正确执行。
例如，系统设定每天凌晨1点，某系统自动从主机同步网点数据进行更新等。
“数据流转测试”从名称和范围上难与功能流程测试有明显划分的界限，可根据实际项目情况变更案例类别的名称，或明确规定试用范围；
实际项目中可能仍会有部分案例无法划分在上述的类别中，可根据实际情况进行调整，或单独形成一个补充案例。
例如，主机错误码在网银系统未知的情况，是由于网银数据库基础数据不完整，也应属于缺陷。
“冒烟测试”的案例，仅执行冒烟测试时使用，案例可能会与“本功能流程测试”的案例重复，但此处单独提出，便于测试的执行和统计，不算案例冗余。
2）兼容性测试
兼容性测试主要应针对客户端，并且根据客户的要求并结合实际，来提供不同的测试方案，并非要盲目的兼容一切；
B/S架构项目兼容性测试的重点，在于浏览器兼容的测试
操作系统
证书的导入，证书的识别是否正常
主要针对Vista系统测试，其他非MS操作系统根据需求以及可提供的驱动程序而定
浏览器
页面各功能的可用性，接口显示的美观、一致性
此为兼容性测试的重点。
通常需要兼容IE6、IE7、IE8，此项目还需兼容FireFox3.6，FireFox4.0
Office类文档
网银系统中导出或生成的各类数据，使用不同版本的office（包括非MS的office），是否都能够正常打开并准确显示
通常以office97以上版本作为测试对象
其他主流软件
在网银系统的使用过程中，如果同时打开其他主流软件，是否会造成冲突（如QQ、MSN等）
此测试仅能对已知的可能不兼容软件进行测试，无法达到全面测试，需要总结实际经验来完善
硬设备
网银系统的使用中，对常见的输入设备是否支持良好，尤其在使用特殊控件的位置和独立的客户端系统中（如使用USB键盘等）
此测试仅能对已知的可能不兼容设备进行测试，无法达到全面测试，需要总结实际经验来完善
3）多语言测试
银行系统的接口中，非简体中文的语言应由用户来提供，或至少需要由用户确认语言使用的准确性；
重点测试，使用非简体中文的语言后，页面内容显示的位置、格式等美观性是否发生了变化，是否在可接受范围内；
多语言测试时，要对系统进行完整测试，以达到系统中各个位置（包括弹出的提示信息、异常时的错误信息等），都能够以相应的语言正确显示。
12.测试输入输出标准
测试产品
主要输入：
《项目业务需求分析说明书》
主要输出：
《项目系统测试计划》，《项目系统测试用例》，《项目测试总结》
测试规则
1）冒烟测试
输入：
编码已完成。
输出：
所有版本检查测试用例的执行结果必须为通过。
2）系统测试
版本检查测试已完成。
所有等级为5和4的缺陷必须已经被修复，剩余的未修复的等级为3的缺陷数量必须少于3个，剩余的未修复的等级为2和1的缺陷数量必须少于5个。
测试用例通过标准
如果实际输出结果与期望输出结果相符合，则此用例可以标注为通过，否则就标注为失败。
并将缺陷提交到BugFree。
暂停\恢复测试标准
1）暂停测试标准
如果在测试过程中发现严重的缺陷，导致产品不能正常运行，项目经理和测试经理可以同意暂停测试，其标准如下：
测试环境问题。
源程序中包含一个或多个导致测试不能继续进行的致命缺陷。
架构重新设计，重新开发，需求改变。
2）恢复测试标准
严重缺陷被修复后，测试进程可以继续进行，所需标准如下：
导致测试暂停的致命缺陷已被修复。
必须得到项目经理正式通知。
当测试恢复时，必须重新计划测试流程，更新测试计划和相关联的测试用例。
出现暂停测试情况时，测试经理与相关负责人及时联系，由相关负责人给出具体恢复时间。
测试人员等待恢复测试期间可进行工作总结及用例完善工作。
影响测试时间在半个小时以上的，认为影响到整个测试流程进展，此次影响时间及原因会记录在测试进度监控表中。
13.测试风险分析
项目测试时间不能满足实际时间需求，导致项目开发质量出现问题，测试风险随之提高
高
按照CMMI要求严格评估项目的时间要求，给予测试充分时间，以保证项目质量
软件需求没有经过严格评审，功能点描述不清晰，功能实现没有过程描述，异常流程没有考虑
软件需求必须要经过严格的评审与需求静态测试，变更需要有严密的跟踪过程
项目在测试过程中，需求在不断变更，影响项目测试进度与质量
需求变更必须要经过严格的评审与评估，经过正式的流程提交，然后更新软件需求，在项目末期，必须停止需求变更
软件送交测试版本，缺陷数多，开发人员修改不及时，导致项目测试进度拖沓
送交测试版本，测试人员必须进行冒烟测试，冒烟测试通过后，再进行功能测试
若出现以上测试风险，对整个测试流程的进度影响极大，此时应及时会议商讨解决方案。
企业网银重整UAT测试
时间安排
编号
工作日期
阶段
详细内容
备注
入场之前请行方准备场所、设备及联系人
2011.6.1-2011.6.25
执行者：
行方
2011.6.25-2011.7.22
2011.7.25-2011.8.11
包括硬件设备及环境（行方准备）
2011.8.15-2011.8.25
2011.8.26-2011.9.16
通过性、失效性测试及界面：
2011.9.17-2011.9.30
兼容性测试包括：
2011.10.6-2011.10.16
多语言测试
多语言测试：
序号
姓名
性别
技术类型
角色
刘瑞娜
女
助理
组员
管理
经理
肖振华
男
开发
杨一鸣
刘百梅
测试
组长
李银海
陶丽丽
赵春华
黄学俊
金志刚
李益玲
管理+测试
郭振业
李庆锋
升级会员 