银行测试中心建设方案.docx
- 文档编号:29313738
- 上传时间:2023-07-22
- 格式:DOCX
- 页数:53
- 大小:2.16MB
银行测试中心建设方案.docx
《银行测试中心建设方案.docx》由会员分享,可在线阅读,更多相关《银行测试中心建设方案.docx(53页珍藏版)》请在冰豆网上搜索。
银行测试中心建设方案
银行测试中心
规划建设方案
1概述
1.1背景
随着银行业务的快速发展,对银行业务系统的质量控制与质量管理正逐渐成为银行稳定发展的保障。
而建设稳健优良的测试体系和与之匹配的测试方法则又是保证软件系统质量行之有效的必经途径。
1.2任务
测试中心是整个银行业务研发体系建设内容的重要组成部分之一,为我行自己研发、外包、采购软件系统进行完整系统的测试,提供最佳品质保障,并为过程改进和管理提供决策支持。
建设测试中心的主要目标在于提升我行在银行业务测试环节中的质量控制的能力,通过测试中心的建设,形成系统的测试流程,通过与各个产品研发环节的信息充分连接,为系统质量分析和评估提供有效的支撑;基于测试中心构建的IT平台,有系统性地收集、积累项目的历史质量管理经验及数据,提炼共性质量分析和评估模型,形成结构化、知识型、可共享的质量管理资源库,为长期不断地提高我行业务系统的质量奠定坚实的基础。
1.3目标
测试中心总体建设目标:
●建设与整个软件开发体系配套的测试体系
●建立一流的软件测试流程,保证测试工作质量
●逐步建立量化的度量标准,持续改进软件测试过程
●建立一支银行业务能力过硬,测试技能一流的测试团队
●建立一流的软件测试环境体系(包含测试硬件环境、系统软件(操作系统、服务器等)、自动化测试工具等)
2现状分析
2.1测试主体流程现状
现行软件开发操作流程图
目前相关测试人员组织结构
银行科技部有若干科室组成,目前分为软件一科(主要负责全行T24核心系统和大前置系统开发及技术支持)、软件二科(主要负责全行电子渠道开发及技术支持)、软件三科(主要负责全行数据仓库和相关系统开发及技术支持)、软件四科(主要负责全行外围业务系统和管理系统开发及技术支持)等。
每个科室由一名科室负责人和若干主管及普通技术人员组成。
每个科室人员除了履行日常科室规定的职责外还负责对已完成开发的项目编制测试案例并进行功能性测试和业务边界类及异常处理流程的测试,承担了双重职责,在角色扮演上冲突,结果使测试没有有效地规划和执行。
测试团队是由监督员组成的虚拟团队,缺乏实体测试组织,缺乏明确的软件质量和软件测试的管理和执行人员角色定义。
2.2目前应用的测试相关技术
目前信息技术部主要通过CA办公自动化系统与银行各相关职能部门进行需求的流转,无专业需求管理系统,各类测试阶段的实施仍停留在手工测试方式,没有统一的测试管理系统来进行有效的问题管理及测试计划的实施,测试过程中的资产被采用不同的方法和技术记录和管理,导致测试资产(指测试过程中生成或编写的各类文档、脚本、代码、配置文件等)的管理带来困难,使这些资产的价值被忽视,变成被保留的历史数据,而非可促进质量持续提升的基础。
随着银行各类业务系统从单一技术框架结构向多样化技术框架结构的转变,目前的测试手段和技术已显然无法满足行内多平台、多语言和多厂商的快速开发上线的模式。
2.3
综合评估
2.4综合分析
已达到的程度:
●业务需求管理过程已经建立
●已产生需求过滤及整合机制
●对软件质量有改进意识
●部分系统已尝试使用自动化测试工具
●使用ITSM进行服务管理
尚存问题:
●测试知识无法传承,容易产生盲区
●业务人员角色冲突,测试无法有效规划和实施
●缺乏统一的需求管理、测试管理流程和系统
●手工测试效率低下,无法覆盖全部测试需求
●配置管理缺乏,案例完整性难以保证,存在潜在风险
●测试资产难以有效保存,价值易被忽视
●测试环境管理缺乏,容易造成版本错换、漏换
●缺乏对外包项目的质量管理,无法对外包厂商的软件质量进行量化评估
3测试中心简介
3.1测试中心作用
3.1.1测试中心定义
●软件质量:
软件质量是软件特性的总和,软件满足规定或者潜在用户需求的能力
●软件测试:
软件测试的经典定义是在规定条件下对程序进行操作,以发现错误,对软件质量进行评估。
由于软件是由文档,数据以及程序组成的,因此目前软件测试涵盖的已经不仅仅是对程序进行测试,还应该包括对软件行程过程的文档和数据进行的测试。
●测试中心:
测试中心是区别于开发团队的相对独立的,统一的团体或者组织,其人员具有先进的测试理论和经验,能够遵循测试管理流程,通过手工或者自动化测试工具,对系统或软件开展有组织的,有效的测试活动,从而对系统或软件提供整体的质量评估。
●测试中心的特点在于:
◆具有相对独立性,统一性
◆可以作用于不同的系统或应用
◆具有一致的管理流程和软件质量可见性
◆提供集中的基础架构
◆具有专业的团队,实现了技能和测试资产共享
3.1.2测试中心的意义
相比单纯的某个项目内部的测试工具采购和使用而言,建设统一的测试中心的意义在于:
有效性:
应用开发/实施产品、最佳实践方法和人员都实现了集成,可以从一个点上就能便捷地获取所有项目小组的权限,因此不需要增加昂贵的资源投入。
(事实上可能会减少职员总人数。
)
改进性:
可以从整个银行中收集测试流程、组织和产品方面的最佳实践,并且标准化及改进这些实践,然后重新把这些改进过的实践发送到整个银行中。
这样,就缩短了新的测试项目的学习曲线,提高了所有测试小组的成功可能性。
统一性:
测试中心模式能帮助银行统一业务目标和项目优先级,提供更好的最终用户服务。
实用性:
建立一个测试中心模型,这是一个可以达到的目标。
您可以利用现存的各种资源从小范围开始实施,然后,在证实其价值后,再进一步扩展其能力。
许多公司往往会发现测试中心模型是自给自足的。
职业提升:
测试中心模型为专业人士提供了一个具有吸引力的新职业机会,帮助银行重新招募并保留顶级人才。
3.2测试方法论
3.2.1软件测试方法论
3.2.2
传统的开发方法属于线型或者称之为瀑布型,每一个阶段的开始都基于上一阶段成果而展开,因此无法对整个系统质量进行有效的控制,无法体现测试对于整个系统质量控制的重要性,一旦在后期测试中发现问题,很有可能导致软件发布延迟,整个项目成本的增加。
我们所提倡的测试方法是将测试贯穿于项目规划、设计、实施、部署的整个过程中,随时对项目质量进行监控。
一旦发现问题,及时提交,使问题能够尽早、尽快地得以解决。
3.2.3
软件测试和开发生命周期
通过在软件项目过程中自始至终地贯彻尽早测试、连续测试、自动测试经验的实施,能很大程度上提前了软件系统测试发生的时间,能连续的及时的发现软件错误,从而可以在很大程度上降低项目风险和项目开发成本。
3.3测试中心的功能
3.3.1测试中心关注的阶段
以下是软件测试V&V模型图:
如图所示,测试过程主要分为四个阶段:
单元测试,集成测试,系统测试,验收测试。
在模型中,单元测试是基于代码的测试,最初由开发人员执行,以验证其可执行程序代码的各个部分是否已达到了预期的功能要求;
集成测试验证了2个或多个单元之间的集成是否正确,并有针对性地对详细设计中所定义的各单元之间的接口进行检查;
在所有单元测试和集成测试完成后,系统测试开始以客户环境模拟系统的运行,以验证系统是否达到了在概要设计中所定义的功能和性能;
最后,当技术部门完成了所有测试工作后,由业务专家或用户进行验收测试,以确保产品能真正符合用户业务上的需要。
单元测试和集成测试主要由开发团队完成,因此测试中心主要关注的是系统测试和验收测试,当系统上线以后,在版本更新和缺陷修复过程中,测试中心也会承担回归测试的任务。
V&V模型中,两个V分别代表验证(Verification)和确认(Validation)。
软件验证技术是“评估系统或部件在特定的开发阶段是否满足该阶段开始时人们对它提出的要求”。
软件验证是在软件开发的各个阶段,从软件技术人员的角度,测试当前的开发成果(文档,代码等)符合设计的规范,保证按照设计流程和要求进行开发,即“正确地做了事”。
软件确认技术是“评估系统或软件部件在开发过程中或开发结束时是否满足特定要求”。
软件确认是从用户的角度,测试当前的开发成果符合用户的真正需求,即“做了正确的事”。
所以V&V模型更能体现测试在整个软件系统的建设过程中,对质量控制所起到的至关重要的作用。
V&V模型是目前主流测试过程模型,但其并不是万能的,因此在测试过程模型的引用中除了该模型外我们还将把随机测试和配置测试理念贯穿其中。
3.3.2测试中心的职能
测试中心涵盖的功能应该包括:
●业务需求:
分析业务需求,保证测试与业务需求统一
●标准规范:
通过实际和理论相结合,建立适合自己的规范,并且进行验证,同时遵循相应的标准和规范
●系统模型:
具有内部统一的测试模型和被测系统搭建能力,可以进行模型验证
●应用功能:
提供功能测试管理和执行
●应用性能:
提供性能测试管理和执行
●系统维护:
提供内部基础架构,被测系统和测试工具的日常管理和维护
●应用管理:
通过与上线后的应用管理和监控集成,获得错误反馈,对测试工具进行评估和改进。
4测试中心的规划
4.1内部原则
测试中心应该和业务部门,研发部门等一起讨论,建立起软件质量的考核方面和标准
4.1.1定义软件质量的考核方面
-功能性:
应用的各个业务场景的功能完备
-可用性:
应用的用户操作界面的易用和可接受性
-可靠性:
应用在长时间运行下的稳定和安全
-性能:
多用户并发和尖峰压力下的功能性和响应时间
-可维护性:
应用在生产环境下的维护难度
4.1.2软件质量的考核标准
根据国家标准和行业标注,根据业务需求,制定合适本测试中心的,结合不同类型系统的质量考核标准。
软件项目质量考核有一个完整的指标体系,从可行易操作的角度出发,评价一个软件项目质量情况,可以从以下几个方面出发,获取比较客观的评价指标。
指标内容说明如下:
1.小组考核内容:
小组工作量负荷情况分析、小组工作量完成情况分析
2.项目考核:
项目进度完成情况分析、项目工作内容组成情况分析
3.个人考核:
个人进度完成情况、个人工作表现情况
4.缺陷率考核
4.1.3测试管理和功能测试
通过业务需求转换为测试需求,以定义软件项目质量管理的目标。
从需求到案例设计,建立案例,测试执行和缺陷跟踪都必须纳入管理之中,实现测试资产集中管理。
通过统一的测试管理平台将单元测试,集成测试,系统测试和用户接收测试连接起来,将开发人员和测试中心连接起来,形成有效的合作工作流程。
制定测试管理流程,并且通过统一的测试管理平台进行流程的规范。
在有效的测试管理下,通过手工或者自动化功能测试工具完成功能测试,保证系统的功能满足业务需求,同时逐步完善自动化功能测试,建立自动化功能测试框架,以解放人力,提高功能测试的效率。
4.1.4性能测试
为了保证系统上线后可以达到系统的性能要求,测试中心需要对系统进行严格的性能测试过程,测试中心将使用自动化的性能测试工具对交付软件进行性能测试,并使用测试管理与分析工具对测试结果进行分析,以保证交付软件可以达到系统性能要求。
在测试过程中可以使用性能测试工具帮助分析性能瓶颈,进而解决性能问题。
性能测试过程中不仅仅需要进行压力加载模拟,更主要的还需要能够提供监控功能,监控被测系统各个环节在压力情况下的指标表现,同时需要提供比较强大的结果分析功能,为了更好的解决应用开发中可能存在的性能瓶颈,需要具有有效的手段,能够发现应用开发中代码和SQL级别存在的性能问题,从而帮助开发人员优化代码,提高系统性能。
4.1.5测试结果的发布
在功能测试和性能测试阶段,测试中心需要针对各个项目提供有效而全面的功能测试报告和性能测试报告。
功能测试报告应该包括自动化功能测试执行各个步骤的信息和正确与否,性能测试报告应该包含丰富的应用性能分析信息。
测试中心同时还需要生成软件测试评估报告和测试过程报告,例如测试需求覆盖率,缺陷趋势,测试过程中问题汇总等。
能够针对定义的考核方面和考核标准,提供监控质量报告。
通过统一的测试管理平台,测试中心需要针对所有项目,通过定义的关键性能指标(KPI),提供全面的信息视图。
同时能够提供视图的个性化功能,满足不同角色的人员查看的需要,提高工作效率。
测试管理和质量评估KPI一般包括:
考核对象
考核KPI维度
考核指标KPI
指标来源
指标计算公式
测试专家
工作量+质量
项目/版本的缺陷移除率(DRE)
QC
(ST+UAT/ST+UAT+PIR)*100
业务需求的覆盖率(被测项目需求覆盖率)
QC
测试需求覆盖业务需求的比例
关联的需求覆盖率(测试需求的案例覆盖率)
QC
测试案例覆盖测试测试需求的比例
项目/版本的测试工作总量
项目经理
(案例+执行+缺陷+需求)
时间
项目/版本的测试时间的误差率(测试项目进度的偏差率)
项目经理
客户服务
项目经理对测试团队的满意度
项目经理
同评估或调查的统一公式
客户对测试团队的满意度
项目经理
同评估或调查的统一公式
技能和培训支持
工作量+质量
团队培训和技能提高类工作的工作总量,或课程数×学员等
部门经理
同评估或调查的统一公式
协助测试团队解决技术问题数量
部门经理
同评估或调查的统一公式
客户服务
培训的客户满意度
部门经理
同评估或调查的统一公式
测试组长
工作量+质量
项目/版本的缺陷移除率(DRE)
QC
(ST+UAT/ST+UAT+PIR)*100
业务需求的覆盖率(被测项目需求覆盖率)
QC
测试需求覆盖业务需求的比例
关联的需求覆盖率(测试需求的案例覆盖率)
QC
测试案例覆盖测试测试需求的比例
项目/版本的测试工作总量
QC
(案例+执行+缺陷+需求)
时间
项目/版本的测试时间的误差率(测试项目进度的偏差率)
部门经理
客户服务
部门经理对测试团队的满意度
部门经理
同评估或调查的统一公式
客户对测试团队的满意度
部门经理
同评估或调查的统一公式
测试执行人员
质量
缺陷发现时间
QC
无
缺陷发现率(测试周期)
QC
第一个测试周期发现的缺陷数量/总缺陷数量
案例执行效率(案例执行平均时间)
QC
数量/时间
工作量
案例数量×案例复杂度
QC
案例数量×案例复杂度
客户服务
客户满意度(测试组长)的满意度
测试组长\经理
同评估或调查的统一公式
注:
1.ST:
指系统测试阶段发现的缺陷
UAT:
指用户验收测试阶段发现的缺陷
PIR:
指从ITSM导入的缺陷(即生产环境发现的缺陷)
2.对于ST,UAT,PIR种类的缺陷都根据严重程度定义了权重
L1*5
L2*3
L3*2
L4*1
4.2测试中心人员角色定义
测试中心人员结构因不同的发展阶段而不同,详细请看第四点《测试中心发展阶段》,在此仅列出所涉及的常用角色及职责说明。
人员角色
工作职责
测试中心经理
管理测试中心的日常工作,负责所有工作的指派和人员调整,监督测试项目的流程进度和质量
业务专家
作为资深业务分析人员的主要职能是提供对业务人员或团队进行业务支持、分析和培训
运作专家
运作专家将负责测试团队的知识技能的管理,QA流程建设等工作,提供中心的共享服务
测试项目经理
负责具体的一个或多个测试项,管理项目内部的工作流程,项目人员的工作任务分配,直接对测试中心经理负责,对所提出的评测结果和报告负责,评估测试项目质量
测试架构师
测试中心的专业测试顾问,针对项目制定测试策略,总体设计测试计划,考核测试结果,控制流程更改,评估和总结被测试应用的质量
测试设计工程师
设计测试计划和案例,设计自动化测试脚本,熟悉各种测试工具和技术,定义测试实施计划
测试执行工程师
执行测试案例,记录案例运行结果,分析测试结果,提交缺陷报告
业务人员
提供和确认被测试系统业务需求,检验被测试系统测试结果,提供业务测试数据
系统管理员
管理和维护测试管理系统,搭建和维护被测试系统
测试工程师
具有相对比较丰富测试案例开发和执行经验人员.可以指导或负责具体的测试执行工作
4.3测试中心流程规划
上图流程包括:
--需求审核和变更管理--缺陷管理
--测试策略和计划模型--度量和KPI报告
--测试流程管理--测试资源和工作管理
--测试案例和脚本--人员时间和技能
--系统测试--测试环境
--性能测试
--回归测试
4.4测试中心技术平台
4.5测试中心发展阶段
测试中心的建设不是一蹴而就的,而应该根据自身的特点,分阶段,有步骤地进行,逐步发展和完善。
根据银行信息中心的实际情况出发,定义了四个发展阶段,但不是强制性的必然历程,也可以选择从某个阶段开始,然后逐步发展进入下一个阶段。
如下图所示:
4.5.1阶段一:
基于项目的测试
概念:
每个项目独立测试,组建各自的测试小组,手工或部分使用自动化工具,在产品上线前能够发现一定的错误,从而降低了产品运营时的风险和投产后进行错误修复而需要投入的成本。
阶段目标:
根据项目优先级选择某个科室中的一个或多个项目作为试点项目
工作内容:
●建立可见的软件质量的度量体系
●建立软件测试的基本流程和运作规范,并投入运作
●建立测试案例库
●完成测试中心组织架构建设
组织结构:
阶段成果:
●具备对试点项目测试环境的配置能力
●需求审核和变更管理
●通过测试案例库的建立,便于提升日后维护阶段的测试效率
●测试过程流程化,每个角色的任务得到充分明确
●测试人员已具备基本的业务知识
●通过专业的测试,降低项目风险
4.5.2阶段二:
产品中心
概念:
在“项目测试”阶段,不同部门或LOB的项目小组往往发现他们自己在不断重复工作——浪费时间、金钱和IT技能——工具不能相互兼容,方法也前后不一致。
为了改变这种状况,就需要实现集中的、标准的测试能力。
“产品中心”这一模型,它能使集中的测试工具产品变为一种可用的共享服务。
在这一模型中,LOB可以巩固硬件、软件和学习成本,从而提高技术基础架构的ROI。
阶段目标:
以科室为单位,逐步建立覆盖科室系统的测试体系
工作内容:
●建立软件质量的全生命周期的管理
●建立应用变更生命周期的管理
●完善软件测试过程和度量体系
●完善测试中心职能
组织结构:
阶段成果:
●基于缺陷分析的质量管理体系初步成型
●测试指标得到量化,便于统计分析,并就是否上线为决策者提供量化依据
●自动化测试平台的建立能充分减少测试执行时间,从而降低项目成本
●各类测试资产模版化、规范化、标准化,方便阅读及流转
●项目需求能得到严格的验证、过滤及整合,使得在项目的早期就能确定隐含的风险
4.5.3阶段三:
服务中心
概念:
测试中心发展的下一阶段,也就是第三阶段,被称为“服务中心”模型,在这一模型中,测试中心集中提供服务和专业知识,改进质量。
通常,项目测试往往局限于技术人员有限的专业知识,只限于使用行业的最佳实践和流程。
即使他们是这方面的专家,也无法有效地展开LOB水平的专业测试。
通过测试中心,许多项目小组都能获取专业的经验和建议。
阶段目标:
以产品开发部为单位,建立覆盖全部系统的测试中心体系
工作内容:
●建立以技术目标为驱动,产出以科技为核心的测试中心
●定义软件质量服务的SLA,建立软件质量风险和成本的管理模型
●建立自我完善的可持续提升的质量过程
组织结构:
阶段成果:
●对于多元化、多架构、跨平台的各类系统都能使用统一的测试指标进行衡量,便于进行比对分析
●通过部署无人值守的自动化测试平台,持续改进测试过程,降低测试成本
●使用仿真测试工具替代手工测试,提高测试效率
●通过测试环境及应用配置的统一管理,严控换版步骤,保证换版质量及成功率
●对业务功能进行风险和影响度的评估,以缩减QA的时间,并提高有限时间和成本内的质量水平
●使用性能测试工具,通过对系统的负载测试和压力测试提高这个系统的性能。
4.5.4阶段四:
质量权威中心
概念:
最后一个阶段---第四阶段是测试中心向“质量权威中心”转化的过程,在此阶段中,测试中心将成为日常应用开发、部署和操作的一部分,帮助机构关于与应用卓越性。
在此模型下,任何应用只有通过一致的质量和性能测试流程,并且满足协议质量标准后,才能投入生产使用。
一旦建立完成,“质量和性能权威(QualityandPerformanceAuthorities)”(甚至服务中心)都能与第三方外包产品相媲美,因为他们所具有的专业知识和跟踪记录是任何外包商所无法比拟的。
“质量和性能权限”也能控制第三方外包商的实施过程,在这些产品投入银行生产之前,保证他们的质量和性能。
阶段目标:
建立独立的覆盖全行业务系统的测试中心体系,并服务于全行机构
工作内容:
●建立完整系统质量及流程控制体系
●建设专业的业务专家和技术专家团队
●建立完善的测试人员培养和职业规划体系
●建设技术类测试体系及构架
●建立完善的软硬件监控指标体系
●完善全行性的业务知识库及基于业务问题的缺陷分析系统
组织结构:
阶段成果:
●对系统开发生命周期内的每个阶段的成果进行测试和验证,并通过统一的测试指标进行度量
●通过专业的业务专家和技术专家团队为中心乃至全行提供专业的咨询服务并实现信息共享
●建立完善的、阶梯式的人才培养机制,从而降低人员流动风险
●可快速高效地对提交测试的业务系统进行全面的、系统的测试工作,并提供专业的测试分析报告,为决策提供依据
●通过功能、性能、安全、易用等多类型的测试方法对全行业务系统进行全面测试,保证了测试的完整性和全面性
●通过和IT战略规划中心和监控中心、呼叫中心的互联,从而实现质量体系建设的大战略
5测试体系规划
5.1测试准备
在实施测试前,先要对测试工作进行一些必要的前期准备,这其中包括:
●测试指标定义
●测试环境搭建
●测试工具应用
●测试管理工具
●测试团队组织
●测试数据准备
5.1.1测试指标定义
测试过程中定义了四个度量指标:
测试覆盖率、测试执行率、测试执行通过率、测试缺陷解决率。
1.测试覆盖率
测试覆盖率是指测试用例对需求的覆盖情况。
计算公式:
已设计测试用例的需求数/需求总数。
测试覆盖率从纬度上说包括广度覆盖和深度覆盖;从内容上说包括用户场景覆盖、功能覆盖、功能组合覆盖、系统场景覆盖。
2.测试执行率
测试执行率,就是指实际执行过程中确定已经执行的测试用例比率。
计算公式:
已执行的测试用例数/设计的总测试用例数。
3.测试执行通过率
测试执行通过率,指在实际执行的测试用例中,执行结果为“通过”的测试用例比率。
计算公式:
执行结果为“通过”的测试用例数/实际执行的测试用例总数。
为了得到测试执行通过率数据,我们在测试执行时,需要在测试用例副本中记录下每个测试用例的执行结果,然后在当前版本执行完毕,或者定期(如每周)统计当前测试执行数据。
通过原始数据的记录与统计,我们可以快速的得到当前版本或当前阶段的测试执行通过率。
4.缺陷解决率
缺陷解决率,指某个阶段已关闭缺陷占缺陷总数的比率。
缺陷关闭操作包括以下两种情况:
正常关闭:
缺陷已修复,且经过测试人员验证通过;
强制关闭:
重复的缺陷;由于外部原因造成的缺陷;暂时不处理
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 银行 测试中心 建设 方案