银行测试中心建设方案样本.docx
《银行测试中心建设方案样本.docx》由会员分享，可在线阅读，更多相关《银行测试中心建设方案样本.docx（79页珍藏版）》请在冰点文库上搜索。
资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。
银行测试中心规划建设方案
目录
1概述 错误!
未定义书签。
1.1背景 错误!
未定义书签。
1.2任务 错误!
未定义书签。
1.3目标 错误!
未定义书签。
2现状分析 错误!
未定义书签。
2.1测试主体流程现状 错误!
未定义书签。
2.2当前应用的测试相关技术 错误!
未定义书签。
2.3综合评估 错误!
未定义书签。
2.4综合分析 错误!
未定义书签。
3测试中心简介 错误!
未定义书签。
3.1测试中心作用 错误!
未定义书签。
3.1.1测试中心定义 错误!
未定义书签。
3.1.2测试中心的意义 错误!
未定义书签。
3.2测试方法论 错误!
未定义书签。
3.2.1软件测试方法论 错误!
未定义书签。
3.2.2软件测试和开发生命周期 错误!
未定义书签。
3.3测试中心的功能 错误!
未定义书签。
3.3.1测试中心关注的阶段 错误!
未定义书签。
3.3.2测试中心的职能 错误!
未定义书签。
4测试中心的规划 错误!
未定义书签。
4.1内部原则 错误!
未定义书签。
4.1.1定义软件质量的考核方面 错误!
未定义书签。
4.1.2软件质量的考核标准 错误!
未定义书签。
4.1.3测试管理和功能测试 错误!
未定义书签。
4.1.4性能测试 错误!
未定义书签。
4.1.5测试结果的发布 错误!
未定义书签。
4.2测试中心人员角色定义 错误!
未定义书签。
4.3测试中心流程规划 错误!
未定义书签。
4.4测试中心技术平台 错误!
未定义书签。
4.5测试中心发展阶段 错误!
未定义书签。
4.5.1阶段一:
基于项目的测试 错误!
未定义书签。
4.5.2阶段二:
产品中心 错误!
未定义书签。
4.5.3阶段三:
服务中心 错误!
未定义书签。
4.5.4阶段四:
质量权威中心 错误!
未定义书签。
5测试体系规划 错误!
未定义书签。
5.1测试准备 错误!
未定义书签。
5.1.1测试指标定义 错误!
未定义书签。
5.1.2测试环境搭建 错误!
未定义书签。
5.1.3自动化测试工具应用 错误!
未定义书签。
5.1.4测试管理工具 错误!
未定义书签。
5.1.5测试团队组织 错误!
未定义书签。
5.1.6测试数据准备 错误!
未定义书签。
5.2测试流程 错误!
未定义书签。
5.2.1开发类项目测试流程 错误!
未定义书签。
5.2.2维护类项目测试流程 错误!
未定义书签。
5.3测试管理 错误!
未定义书签。
5.3.1缺陷管理 错误!
未定义书签。
5.3.2配置管理 错误!
未定义书签。
5.3.3需求变更管理 错误!
未定义书签。
5.3.4换版管理 错误!
未定义书签。
5.3.5测试用例管理 错误!
未定义书签。
5.3.6人员培训管理 错误!
未定义书签。
5.3.7考核管理 错误!
未定义书签。
6测试中心在质量管理中的应用 错误!
未定义书签。
6.1确保应用的性能和可用性 错误!
未定义书签。
6.2降低变更和配置中的风险和对业务的影响 错误!
未定义书签。
7合康测试服务 错误!
未定义书签。
7.1合康经验 错误!
未定义书签。
7.2合康服务模式 错误!
未定义书签。
7.3合康优势 错误!
未定义书签。
7.4合康测试的价值体现 错误!
未定义书签。
7.5合康公司产品线 错误!
未定义书签。
8继续努力 错误!
未定义书签。
1概述
1.1背景
随着银行业务的快速发展,对银行业务系统的质量控制与质量管理正逐渐成为银行稳定发展的保障。
而建设稳健优良的测试体系和与之匹配的测试方法则又是保证软件系统质量行之有效的必经途径。
1.2任务
测试中心是整个银行业务研发体系建设内容的重要组成部分之一,为我行自己研发、外包、采购软件系统进行完整系统的测试,提供最佳品质保障,并为过程改进和管理提供决策支持。
建设测试中心的主要目标在于提升我行在银行业务测试环节中的质量控制的能力,经过测试中心的建设,形成系统的测试流程,经过与各个产品研发环节的信息充分连接,为系统质量分析和评估提供有效的支撑;基于测试中心构建的IT平台,有系统性地收集、积累项目的历史质量管理经验及数据,提炼共性质量分析和评估模型,形成结构化、知识型、可共享的质量管理资源库,为长期不断地提高我行业务系统的质量奠定坚实的基础。
1.3目标
测试中心总体建设目标:
l建设与整个软件开发体系配套的测试体系
l建立一流的软件测试流程,保证测试工作质量
l逐步建立量化的度量标准,持续改进软件测试过程
l建立一支银行业务能力过硬,测试技能一流的测试团队
l建立一流的软件测试环境体系（包含测试硬件环境、系统软件（操作系统、服务器等）、自动化测试工具等）
2现状分析
2.1测试主体流程现状
现行软件开发操作流程图
项目开发流程
业务部门（客户）
信息技术部项目组
信息技术部相关科室
开始
业务部门提出业
务需求
技术论证
基本需求方案
需求评审，若有必要，
申请技术评审
费用、人力计划预估
实施方案评审
段阶认确求需
需求分析
设计开发
功能测试
技术及性能测
试
段阶馈反踪跟
日常操作，提
出优化需求
反馈情况
系统试运行，跟踪系统运行
情况
反馈情况
系统运行支
持，验收评审
情况良好（移交）
用户验收测试
上线评审
段
阶
试
测
上线换版
发
开
当前相关测试人员组织结构
科室负责人
科室负责人
科室负责人
科室负责人
监督员A
监督员A
监督员A
监督A
（兼职测试案例设
（兼职测试案例设计）
（兼职测试案例设计）
（兼职测试案例设计）
计）
信息技术部
软件一科
软件二科
软件三科
软件四科
监督员B
（兼职测试实施）
监督员B
（兼职测试实施）
监督员B
（兼职测试实施）
监督员B
（兼职测试实施）
虚拟团队 虚拟团队
银行科技部有若干科室组成,当前分为软件一科（主要负责全行T24核心系统和大前置系统开发及技术支持）、软件二科（主要负责全行电子渠道开发及技术支持）、软件三科（主要负责全行数据仓库和相关系统开发及技术支持）、软件四科（主要负责全行外围业务系统和管理系统开发及技术支持）等。
每个科室由一名科室负责人和若干主管及普通技术人员组成。
每个科室人员除了履行日常科室规定的职责外还负责对已完成开发的项目编制测试案例并进行功能性测试和业务边界类及异常处理流程的测试,承担了双重职责,在角色扮演上冲突,结果使测试没有有效地规划和执行。
测试团队是由监督员组成的虚拟团队,缺乏实体测试组织,缺乏明确的软件质量和软件测试的管理和执行人员角色定义。
2.2当前应用的测试相关技术
软件开发部
系统开发测试环境
用户测试环境
TD自动化测试管理系统
CA办公自动化系统
业务部门
运行科
ITSM管理系统准生产环境
传统单一的技术架构
跨平台多样化技术架构
当前信息技术部主要经过CA办公自动化系统与银行各相关职能部门进行需求的流转,无专业需求管理系统,各类测试阶段的实施仍停留在手工测试方式,没有统一的测试管理系统来进行有效的问题管理及测试计划的实施,测试过程中的资产被采用不同的方法和技术记录和管理,导致测试资产（指测试过程中生成或编写的各类文档、脚本、代码、配置文件等）的管理带来困难,使这些资产的价值被忽视,变成被保留的历史数据,而非可促进质量持续提升的基础。
随着银行各类业务系统从单一技术框架结构向多样化技术框架结构的转变,当前的测试手段和技术已显然无法满足行内多平台、多语言和多厂商的快速开发上线的模式。
资源
4
QualityExpert
报告和度量
共享服务和工作请求
3
QualitySavvy
2
QualityConscious
缺陷管理
需求
1
QualityInitializing
0
性能测试
测试计划和案例
用户验收测试
单元测试
2.4综合分析
系统和集成测试
2.3综合评估
已达到的程度:
l业务需求管理过程已经建立
l已产生需求过滤及整合机制
l对软件质量有改进意识
l部分系统已尝试使用自动化测试工具
l使用ITSM进行服务管理
尚存问题:
l测试知识无法传承,容易产生盲区
l业务人员角色冲突,测试无法有效规划和实施
l缺乏统一的需求管理、测试管理流程和系统
l手工测试效率低下,无法覆盖全部测试需求
l配置管理缺乏,案例完整性难以保证,存在潜在风险
l测试资产难以有效保存,价值易被忽视
l测试环境管理缺乏,容易造成版本错换、漏换
l缺乏对外包项目的质量管理,无法对外包厂商的软件质量进行量化评估
3测试中心简介
3.1测试中心作用
3.1.1测试中心定义
l软件质量:
软件质量是软件特性的总和,软件满足规定或者潜在用户需求的能力
l软件测试:
软件测试的经典定义是在规定条件下对程序进行操作,以发现错误,对软件质量进行评估。
由于软件是由文档,数据以及程序组成的,因此当前软件测试涵盖的已经不但仅是对程序进行测试,还应该包括对软件行程过程的文档和
数据进行的测试。
l测试中心:
测试中心是区别于开发团队的相对独立的,统一的团体或者组织,其人员具有先进的测试理论和经验,能够遵循测试管理流程,经过手工或者自动化测试工具,对系统或软件开展有组织的,有效的测试活动,从而对系统或软件提供整体的质量评估。
l测试中心的特点在于:
u具有相对独立性,统一性
u能够作用于不同的系统或应用
u具有一致的管理流程和软件质量可见性
u提供集中的基础架构
u具有专业的团队,实现了技能和测试资产共享
3.1.2测试中心的意义
相比单纯的某个项目内部的测试工具采购和使用而言,
建设统一的测试中心的意义在于:
有效性:
应用开发/实施产品、最佳实践方法和人员都实现了集成,能够从一个点上就能便捷地获取所有项目小组的权限,因此不需要增加昂贵的资源投入。
（事实上可能会减
少职员总人数。
）
改进性:
能够从整个银行中收集测试流程、组织和产品方面的最佳实践,而且标准化及改进这些实践,然后重新把这些改进过的实践发送到整个银行中。
这样,就缩短了新的测试项目的学习曲线,提高了所有测试小组的成功可能性。
统一性:
测试中心模式能帮助银行统一业务目标和项目优先级,提供更好的最终用户服务。
实用性:
建立一个测试中心模型,这是一个能够达到的目标。
您能够利用现存的各种资源从小范围开始实施,然后,在证实其价值后,再进一步扩展其能力。
许多公司往往会发现测试中心模型是自给自足的。
职业提升:
测试中心模型为专业人士提供了一个具有吸引力的新职业机会,帮助银行重新招募并保留顶级人才。
3.2测试方法论
3.2.1软件测试方法论
传统方法论
规 业务
设
实施
测试
应
现代方法论
优化业务成果
规
业
设
实施
应
需求
测试
时间
1
验证需求
使IT能更好的迎合
2
业务影响分析
对业务功能进行风
3
使用业务度量
提供质量流程改进
业务需求,在应用 险和影响度的评估, 的面向目标的关键
传统的开发方法属于线型或者称之为瀑布型,每一个阶段的开始都基于上一阶段成果而展开,因此无法对整个系统质量进行有效的控制,无法体现测试对于整个系统质量控制的重要性,一旦在后期测试中发现问题,很有可能导致软件发布延迟,整个项目成本的增加。
我们所提倡的测试方法是将测试贯穿于项目规划、设计、实施、部署的整个过程中,随时对项目质量进行监控。
一旦发现问题,及时提交,使问题能够尽早、尽快地得以解决。
3.2.2软件测试和开发生命周期
RequirementsVerification
TestStrategy&TestPlan
TestcaseSystemPerformanceUAT ReadinessTest Test Test
ProblemDiagnostic
RequirementsFunctional&TechnicalSpecs Build TestExecution Deploy Operation
MercuryQualityProcesses
经过在软件项目过程中自始至终地贯彻尽早测试、连续测试、自动测试经验的实施,能很大程度上提前了软件系统测试发生的时间,能连续的及时的发现软件错误,从而能够在很大程度上降低项目风险和项目开发成本。
3.3测试中心的功能
3.3.1测试中心关注的阶段
以下是软件测试V&V模型图:
如图所示,测试过程主要分为四个阶段:
单元测试,集成测试,系统测试,验收测试。
在模型中,单元测试是基于代码的测试,最初由开发人员执行,以验证其可执行程序代码的各个部分是否已达到了预期的功能要求;
集成测试验证了2个或多个单元之间的集成是否正确,并有针对性地对详细设计中所定义的各单元之间的接口进行检查;
在所有单元测试和集成测试完成后,系统测试开始以客户环境模拟系统的运行,以验证系统是否达到了在概要设计中所定义的功能和性能;
最后,当技术部门完成了所有测试工作后,由业务专家或用户进行验收测试,以确保产品能真正符合用户业务上的需要。
单元测试和集成测试主要由开发团队完成,因此测试中心主要关注的是系统测试和验收测试,当系统上线以后,在版本更新和缺陷修复过程中,测试中心也会承担回归测试的任务。
V&V模型中,两个V分别代表验证（Verification）和确认（Validation）。
软件验证技术是”评估系统或部件在特定的开发阶段是否满足该阶段开始时人们对它提出的要求”。
软件验证是在软件开发的各个阶段,从软件技术人员的角度,测试当前的开发成果（文档,代码等）符合设计的规范,保证按照设计流程和要求进行开发,即”正确地做了事”。
软件确认技术是”评估系统或软件部件在开发过程中或开发结束时是否满足特定要求”。
软件确认是从用户的角度,测试当前的开发成果符合用户的真正需求,即”做了正确的事”。
因此V&V模型更能体现测试在整个软件系统的建设过程中,
对质量控制所起到的至关重要的作用。
V&V模型是当前主流测试过程模型,但其并不是万能的,因此在测试过程模型的引用中除了该模型外我们还将把随机测试和配置测试理念贯穿其中。
3.3.2测试中心的职能
测试中心涵盖的功能应该包括:
l业务需求:
分析业务需求,保证测试与业务需求统一
l标准规范:
经过实际和理论相结合,建立适合自己的规范,
而且进行验证,同时遵循相应的标准和规范
l系统模型:
具有内部统一的测试模型和被测系统搭建能力,
能够进行模型验证
l应用功能:
提供功能测试管理和执行
l应用性能:
提供性能测试管理和执行
l系统维护:
提供内部基础架构,被测系统和测试工具的日常管理和维护
l应用管理:
经过与上线后的应用管理和监控集成,获得错
误反馈,对测试工具进行评估和改进。
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
指标来源
指标计算公式
维度
项目/版本的缺陷
QC
（ST＋
移除率（DRE）
UAT/ST+UAT+PIR）
*100
业务需求的覆盖率
QC
测试需求覆盖业
（被测项目需求覆
务需求的比例
工作量＋质量
盖率）
关联的需求覆盖率
QC
测试案例覆盖测
测试专家
（测试需求的案例
覆盖率）
试测试需求的比
例
项目/版本的测试
项目经理
（案例＋执行＋
工作总量
缺陷＋需求）
时间
项目/版本的测试
项目经理
时间的误差率（测
试项目进度的偏差
率）
项目经理对测试团
项目经理
同评估或调查的
客户服务
队的满意度
统一公式
客户对测试团队的
项目经理
同评估或调查的
满意度
统一公式
团队培训和技能提
部门经理
同评估或调查的
高类工作的工作总
统一公式
工作量＋
量,或课程数×学
技能和培
质量
员等
训支持
协助测试团队解决
部门经理
同评估或调查的
技术问题数量
统一公式
客户服务
培训的客户满意度
部门经理
同评估或调查的
统一公式
项目/版本的缺陷
QC
（ST＋
移除率（DRE）
UAT/ST+UAT+PIR）
*100
业务需求的覆盖率
QC
测试需求覆盖业
（被测项目需求覆
务需求的比例
工作量＋质量
盖率）
关联的需求覆盖率
QC
测试案例覆盖测
（测试需求的案例
试测试需求的比
测试组长
覆盖率）
项目/版本的测试
QC
例
（案例＋执行＋
工作总量
缺陷＋需求）
时间
项目/版本的测试
部门经理
时间的误差率（测
试项目进度的偏差
率）
部门经理对测试团
部门经理
同评估或调查的
客户服务
队的满意度
统一公式
客户对测试团队的
部门经理
同评估或调查的
满意度
统一公式
缺陷发现时间
QC
无
缺陷发现率（测试
QC
第一个测试周期
质量
周期）
发现的缺陷数量/
测试执行
案例执行效率（案
QC
总缺陷数量
数量/时间
人员
例执行平均时间）
工作量
案例数量×案例复
QC
案例数量×案例复
杂度
杂度
客户服务
客户满意度（测试
测试组长\
同评估或调查的
组长）的满意度
经理
统一公式
注:
1.ST:
指系统测试阶段发现的缺陷
UAT:
指用户验收测试阶段发现的缺陷
PIR:
指从ITSM导入的缺陷（即生产环境发现的缺陷）
2.对于ST,UAT,PIR种类的缺陷都根据严重程度定义了权
重
L1*5L2*3L3*2L4*
升级会员 