|
金融信息系统测试解决方案
金融信息系统测试方案的目的:一是从方法论的角度对整个金融信息系统测试进行介绍,包括它的概念、流程和部分关键环节(测试案例编写)的说明;二是制定了测试策略、计划、实施、控制和管理准则,对部分内容提供模板,作为以后真正制定测试计划的基础。 Callicloud靓云金融信息科技服务平台.
测试分成很多种,从最终目的看,可以分成:一类是在信息系统开发过程中进行的测试,如单元测试、系统集成测试、性能和压力测试等,它们都是由系统开发商为主体进行的测试,目的是为了发现信息系统测试中:内部逻辑、功能模块、与其他系统之间的交互以及是否符合业务需求等方面存在的问题;另一类是金融机构自身用户对系统进行的验收测试,也叫用户验收测试(User Acceptance Test,UAT),通常是以客户为主体进行的验收测试,目的是检验系统是否可以满足各项业务需求,是否可以投入生产运行。
Callicloud靓云金融信息科技服务平台.金融信息系统测试解决方案1 测试方案说明1.1 方案背景1.2 方案目的1.3 组织结构1.4 测试流程金融信息系统测试解决方案2 金融信息系统概述2.1 整体描述2.2 物理架构2.3 技术架构2.4 关联系统2.5功能需求概述金融信息系统测试解决方案3 风险和应对机制3.1 资源短缺3.2 时间压缩3.3 需求变更 3.4 测试技术金融信息系统测试解决方案4 测试目标和范围4.1 测试目标4.2 测试范围5 测试方法与策略5.1 测试方法5.2 开始和结束定义5.3 测试视角与侧重点5.4 假设与限制条件6 测试准备6.1 编写测试案例6.1.1 案例开发原则6.1.2 案例开发方法6.1.3 测试案例估算方法6.2 主要测试步骤6.3 测试文档模板6.4 测试案例样板6.5 测试环境准备金融信息系统测试解决方案7 实施测试7.1 测试通过、停止、未通过定义7.2 缺陷分类与统计分析7.2.1 缺陷记录信息7.2.3 缺陷修复优先级7.2.4 缺陷类别7.2.5 修复成功率7.3 软件配置审核7.4 集成验证测试7.5 单元和功能测试7.6 结构测试7.7 Ad Hoc 测试7.8 Smoke 测试7.9 国际化测试7.10 测试过程7.10.1 案例执行7.10.2 测试结果分析7.10.3 汇报测试结果7.11 测试进度安排7.12 测试工具金融信息系统测试解决方案8 测试管理8.1 计划/人员安排8.2 培训计划8.3 缺陷管理8.4 过程管理8.5 质量管理8.5.1 设立质量控制组8.5.2 问题/差异管理8.5.3 需求变更管理8.5.4 执行效率8.5.5 管理机制8.6 合作管理8.7 会议管理8.8 报告和文档管理8.9 责任分配9 参考资料靓云金融信息科技服务平台是一个汇集金融信息系统解决方案、金融IT供应商、金融IT产品、金融机构信息化需求、信息中心信息系统测试验收测试金融信息系统测试解决方案。
靓云金融信息科技服务平台是一个汇集金融信息系统解决方案、金融IT供应商、金融IT产品、金融机构信息化需求
3.1 定义
系统测试是为了确定开发的新系统是否满足用户的验收标准而进行的正式测试,通常是基于业务需求,采用真实的测试数据,在真实环境下进行。
3.2 目标
测试的主要目标是:核实开发出来的系统, 在项目计划允许的时间内,按照既定的质量标准完成各阶段测试,保证新系统满足客户需求。
需要避免的误区是:测试不是在验证设计与需求的合理性,也不是验证设计和需求的完整性,测试的主要任务是测试系统是否按业务需求进行了开发,并满足各项预定指标。
3.3 测试范围
3.3.1 范围内
进行测试计划时,一项重要任务是明确测试的范围,即哪些需求和/或功能是本次测试要完成的。测试范围应与需求文档相一致。如果有与外部接口的解决方案,也应列出所有需要测试的接口。
在测试范围内的测试领域
功能/需求 相关文档 系统设计文档 备注
测试的具体内容包括:
1. 软件配置审核
2. 系统集成测试
3. 性能/压力/负载测试
4. 回归测试
5. 兼容和稳定性测试
6. 发布/安装/实施性测试
7. 安全性测试
8. 系统维护和备份测试
9. 其它
3.3.2 范围外 (具体项目具体分析)
举例:列出不在本测试阶段测试的需求或功能。
表格:不在测试范围内的领域
功能/需求 相关文档 系统设计文档 备注
测试不包括的内容有:
1. 不在测试范围内的新功能的测试
2. 单元测试 (开发组完成)
3. 功能测试 (开发组完成)
4. 系统集合测试 (开发组完成)
5. 国际化测试
4 功能需求概述
本项目分为业务需求梳理、系统需求分析、系统设计三个阶段进行。业务需求梳理是系统需求分析的基础,而系统需求分析则是系统设计的前提。
图表 系统需求分析阶段描述
本项目中对系统功能性需求的分析采用了以用例为主的方法,辅以业务规则、数据项、界面等来描述需求。依据分析的结果,对特定金融信息几需求分为6个大类,n个一层用例,m个2层用例进行描述。
依据业务的框架方案,功能需求分为#@##关于系统功能需求的详细内容可参见相关功能需求规格说明书(将作为系统开发和测试的标准)。
楼主按最终目的进行的分类内容,非常的不妥
UAT更多的是一个上线前的形式的,走流程的测试,所以,这不是按最终目的进行的分类,更像是按执行测试者、或是测试环节/流程进行的分类
金融信息系统测试方法及策略1.1 测试方式 金融系统测试通常是采取手工和自动化测试相结合,借助测试工具的支持来提高测试效率和进度。测试方式阶段
技术
工具
人员
备注
1 软件配置审核
代码,文档
审核
测试工程师
2单元测试
白盒测试
JUnit, TestNG, Rational Purifyplus
开发工程师
3组件测试
灰盒测试
组件测试框架
开发工程师
4集成测试
黑盒测试
手动功能
测试工程师
回归测试
自动化工具-QTP
自动化测试工程师
黑盒测试
自动化工具-BPT
业务流程测试工程师
5 系统测试
性能/压力/负荷测试
Loadrunner
性能测试工程师
备份/恢复测试
手动测试
测试工程师
安装盘及最终包测试
手动测试
测试工程师
与其它业务系统集成
接口测试
测试开发工程师
1.2 测试视角和着重点 测试各类金融应用系统,通常可以从两个视角进行考虑:一是单个用户视角,即从系统的单个用户的角度去考虑系统的各个功能;二是业务流程视角,即业务从发起到结束的全流程的角度去考虑系统的功能。对于系统测试,通常是以业务流程的视角进行考虑。从业务流程角度进行考虑时,鉴于多个单点环节连接构成,而每个单点可能有多种不同的情况,如果对其各种情况的组合进行测试,不仅有许多重复劳动,而且系统的规模和复杂性也使这种思路不具备可操作性。因此,在设计测试案例和决定案例数量时应充分考虑本系统的特点,有选择性地进行业务流程测试。1.3 限制条件和假设 系统测试的过程中,可能会存在人为的因素,数据准备、资源的可获得性、计划安排等方面的限制。例如,· 对业务系统和技术实现提供的信息不够详细,测试方案中的有些方面会产生偏差。· 系统开发组所实施的测试在方式方法上,需求理解,开发/测试时间限制,和操作上会有不同,导致偏差。· 由于流程系统中的测试要素排列组合数目很大,需要从中抽取有效的测试用例,并尽可能地覆盖功能区域。· 测试用例覆盖面不足。· 测试时间相对于测试任务很紧张。· 测试人员需要学习和熟悉测试管理工具和自动化工具。· 测试方案在细化的过程中会遇到新的问题。· 测试组中有用户方面的人员参与,需要协调管理。
6.1 金融信息系统测试_编写测试案例6.1.1 金融信息系统测试案例开发原则
测试案例的编写是系统验收测试过程中的一项重要工作,在编写案例时,应遵循以下原则:· 开发测试用例的输入是需求分析说明书、概要设计说明书、详细设计说明书· 以业务为主线,覆盖完整、连贯的业务流程· 以系统为基础,体现业务流程在系统内的操作,覆盖所有的业务和操作特征· 尽量避免相似功能的重复测试· 使用银行现有具有真实的业务背景的数据· 业务需求为辅保证业务系统的可用性· 功能和自动化相结合· 案例的量满足应测试时间的进度要求,可适当排列优先级6.1.2金融信息系统测试案例开发方法 · 矩阵分析法: 按照矩阵分析表格从业务流程要素的排列组合中抽取出符合业务逻辑的组合。· 排列组合优化法:根据有效的排列组合采用优选工具计算出最优组合,并保证所有功能点都能够覆盖。· 渐进测试法:按照由简单到复杂,测试要素可抽取的观点对系统进行逐步递进的测试。· 典型测试法:挑选实际使用频度高,复杂程度高的流程重点测试。1.1.3金融系统测试估算方法 · 参考业务需求中的一些量化指标,· 根据对本系统测试提出的测试种类· 结合本系统的业务和技术特点和以往的项目经验。· 按照系统的开发测试周期即月数完成编码实现和相应的测试,以及测试的不同阶段划分。1.1.4 金融系统测试注意事项 · 测试数据的准备· 组织架构的准备· 测试案例选择的覆盖· 测试人员的安排· 其他UAT需要关注的问题1.2 金融系统测试主要步骤 根据系统的特点,编写测试案例和相关说明,使测试人员能够据此测试需要测试的各种情形。具体步骤包括:· 分析:分析系统功能特征和业务特征,列出需要测试的关键点,保证完整性· 勾勒:将需要测试的关键点组合成多个案例框架,保证组合后的完整性,同时避免相似功能的反复重复测试· 案例编写:由业务人员确定每个业务案例的详细步骤,保证每个案例自身逻辑的完整性· 数据填充:将银行的业务数据填入案例步骤中· IT转换:将业务语言转换为IT语言,形成可以用于测试的测试脚本1.3 金融系统测试文档模板 在设计测试案例时,需要确保需要测试的功能需求都被测试到。下面的测试覆盖矩阵表可以帮助我们观察测试案例对需求的覆盖情况。测试覆盖矩阵表(略)对于每一个测试案例,通常需要撰写相关的案例文档。测试案例没有标准的文档格式,它通常包含的主要要素有:· 标题和编号、版本号、修改记录、测试案例编写人、审阅人等· 针对目标和假设前提· 测试执行人扮演的角色· 输入和数据/代码· 测试案例执行的流程· 预期输出· 测试结果记录· 测试执行人· 缺陷的严重性· 缺陷修复的优先级· 修复执行人· 修复日期下面是一个可供参考的金融系统测试案例文档模板:1.4 金融系统测试环境准备 测试开始之前还有一项重要工作是测试环境的准备。在此过程中,需要明确并建立测试所需的设施支持,包括文件、程序和数据库等测试所需要的资源。本阶段的主要任务是:· 确定并记录测试环境的以下方面:· 比如:- 服务器和工作站的操作系统,包括fix packs, patches 等- 通信协议和网络要求- 硬件要求(CPU、内存、硬件存储等)- 与外部接口(包括原有系统)的连接- 系统安全相关的要求- 数据库的安装和配置- 测试环境的备份、恢复和建设程序等· 明确测试工具· 确保测试环境的安装和配置· 测试环境要尽可能地和实际生产环境相符· 比如:测试使用的性能测试工具是Mercury公司的Loadrunner,它能够在一台机器上模拟多个并发用户对服务器发出请求,同时能够收集系统吞吐量和响应时间等信息。为了更真实地模拟实际应用环境,测试设备选用实际业务环境中的硬件配置:· 应用服务器使用了WebLogic; · 数据库选择了Oracle 9.20X;· 操作系统是HP UNIX 11.11· 多台计算机构成了1000/100M的局域网。实际测试之前,这些内容都必须非常明确,并在相关测试文档中进行详细说明。另外,还需要说明负责协调可能会数量众多的测试环境所需资源的人员、稀缺资源的使用时间、保证对测试环境的有效控制的方法等。 |
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
|