银行测试中心建设方案样本.doc

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。

银 行 测 试 中 心
规 划 建 设 方 案

目录
1 概述 3
1.1 背景 3
1.2 任务 3
1.3 目标 4
2 现状分析 4
2.1 测试主体流程现状 4
2.2 当前应用的测试相关技术 6
2.3 综合评估 7
2.4 综合分析 7
3 测试中心简介 8
3.1 测试中心作用 8
3.1.1 测试中心定义 8
3.1.2 测试中心的意义 8
3.2 测试方法论 9
3.2.1 软件测试方法论 9
3.2.2 软件测试和开发生命周期 10
3.3 测试中心的功能 10
3.3.1 测试中心关注的阶段 10
3.3.2 测试中心的职能 12
4 测试中心的规划 12
4.1 内部原则 12
4.1.1 定义软件质量的考核方面 13
4.1.2 软件质量的考核标准 13
4.1.3 测试管理和功能测试 14
4.1.4 性能测试 15
4.1.5 测试结果的发布 15
4.2 测试中心人员角色定义 17
4.3 测试中心流程规划 18
4.4 测试中心技术平台 19
4.5 测试中心发展阶段 19
4.5.1 阶段一: 基于项目的测试 20
4.5.2 阶段二: 产品中心 21
4.5.3 阶段三: 服务中心 23
4.5.4 阶段四: 质量权威中心 24
5 测试体系规划 27
5.1 测试准备 27
5.1.1 测试指标定义 27
5.1.2 测试环境搭建 28
5.1.3 自动化测试工具应用 28
5.1.4 测试管理工具 29
5.1.5 测试团队组织 30
5.1.6 测试数据准备 30
5.2 测试流程 31
5.2.1 开发类项目测试流程 31
5.2.2 维护类项目测试流程 40
5.3 测试管理 42
5.3.1 缺陷管理 43
5.3.2 配置管理 43
5.3.3 需求变更管理 44
5.3.4 换版管理 44
5.3.5 测试用例管理 46
5.3.6 人员培训管理 48
5.3.7 考核管理 48
6 测试中心在质量管理中的应用 49
6.1 确保应用的性能和可用性 49
6.2 降低变更和配置中的风险和对业务的影响 50
7 合康测试服务 50
7.1 合康经验 50
7.2 合康服务模式 51
7.3 合康优势 51
7.4 合康测试的价值体现 51
7.5 合康公司产品线 52
8 继续努力 52

1 概述
1.1 背景
随着银行业务的快速发展, 对银行业务系统的质量控制与质量管理正逐渐成为银行稳定发展的保障。而建设稳健优良的测试体系和与之匹配的测试方法则又是保证软件系统质量行之有效的必经途径。
1.2 任务
测试中心是整个银行业务研发体系建设内容的重要组成部分之一, 为我行自己研发、 外包、 采购软件系统进行完整系统的测试, 提供最佳品质保障, 并为过程改进和管理提供决策支持。建设测试中心的主要目标在于提升我行在银行业务测试环节中的质量控制的能力, 经过测试中心的建设, 形成系统的测试流程, 经过与各个产品研发环节的信息充分连接, 为系统质量分析和评估提供有效的支撑; 基于测试中心构建的IT平台, 有系统性地收集、 积累项目的历史质量管理经验及数据, 提炼共性质量分析和评估模型, 形成结构化、 知识型、 可共享的质量管理资源库, 为长期不断地提高我行业务系统的质量奠定坚实的基础。
1.3 目标
测试中心总体建设目标:
l 建设与整个软件开发体系配套的测试体系
l 建立一流的软件测试流程, 保证测试工作质量
l 逐步建立量化的度量标准, 持续改进软件测试过程
l 建立一支银行业务能力过硬, 测试技能一流的测试团队
l 建立一流的软件测试环境体系( 包含测试硬件环境、 系统软件( 操作系统、 服务器等) 、 自动化测试工具等)

2 现状分析
2.1 测试主体流程现状
现行软件开发操作流程图

当前相关测试人员组织结构

银行科技部有若干科室组成, 当前分为软件一科( 主要负责全行T24核心系统和大前置系统开发及技术支持) 、 软件二科( 主要负责全行电子渠道开发及技术支持) 、 软件三科( 主要负责全行数据仓库和相关系统开发及技术支持) 、 软件四科( 主要负责全行外围业务系统和管理系统开发及技术支持) 等。每个科室由一名科室负责人和若干主管及普通技术人员组成。
每个科室人员除了履行日常科室规定的职责外还负责对已完成开发的项目编制测试案例并进行功能性测试和业务边界类及异常处理流程的测试, 承担了双重职责, 在角色扮演上冲突, 结果使测试没有有效地规划和执行。
测试团队是由监督员组成的虚拟团队, 缺乏实体测试组织, 缺乏明确的软件质量和软件测试的管理和执行人员角色定义。

2.2 当前应用的测试相关技术
业务部门
跨平台多样化技术架构
传统单一的技术架构
系统开发测试环境
软件开发部
运行科
用户测试环境

准生产环境
ITSM管理系统

TD自动化测试管理系统

CA办公自动化系统

当前信息技术部主要经过CA办公自动化系统与银行各相关职能部门进行需求的流转, 无专业需求管理系统, 各类测试阶段的实施仍停留在手工测试方式, 没有统一的测试管理系统来进行有效的问题管理及测试计划的实施, 测试过程中的资产被采用不同的方法和技术记录和管理, 导致测试资产( 指测试过程中生成或编写的各类文档、 脚本、 代码、 配置文件等) 的管理带来困难, 使这些资产的价值被忽视, 变成被保留的历史数据, 而非可促进质量持续提升的基础。
随着银行各类业务系统从单一技术框架结构向多样化技术框架结构的转变, 当前的测试手段和技术已显然无法满足行内多平台、 多语言和多厂商的快速开发上线的模式。

2.3 综合评估

2.4 综合分析
已达到的程度:
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 软件测试方法论
提供质量流程改进的面向目标的关键性能指标, 这些指标是面向业务需求的
实施
实施
设计
应用部署
测试
传统方法论
需求验证
应用部署
优化业务成果
现代方法论
对业务功能进行风险和影响度的评估, 以缩减QA的时间, 并提高有限时间和成本内的质量水平
业务影响分析
验证需求
2
使IT能更好的迎合业务需求, 在应用交付的早期就能够确定可能存在的缺陷
使用业务度量
3
规划
业务需求
设计
测试
1
时间
业务需求
规划

传统的开发方法属于线型或者称之为瀑布型, 每一个阶段的开始都基于上一阶段成果而展开, 因此无法对整个系统质量进行有效的控制, 无法体现测试对于整个系统质量控制的重要性, 一旦在后期测试中发现问题, 很有可能导致软件发布延迟, 整个项目成本的增加。
我们所提倡的测试方法是将测试贯穿于项目规划、 设计、 实施、 部署的整个过程中, 随时对项目质量进行监控。一旦发现问题, 及时提交, 使问题能够尽早、 尽快地得以解决。

3.2.2 软件测试和开发生命周期

经过在软件项目过程中自始至终地贯彻尽早测试、 连续测试、 自动测试经验的实施, 能很大程度上提前了软件系统测试发生的时间, 能连续的及时的发现软件错误, 从而能够在很大程度上降低项目风险和项目开发成本。

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
指标来源
指标计算公式

测试专家

工作量＋质量
项目/版本的缺陷移除率( 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 测试中心技术平台

过程
模板
测试资产
过程
自动化流程
自动化测试执行平台
运作流程
业务专家
项目负责人
测试架构师
测试工程师
测试中心运作人员
负责人

测试管理平台
软件质量门户( Portal)

4.5 测试中心发展阶段
测试中心的建设不是一蹴而就的, 而应该根据自身的特点, 分阶段, 有步骤地进行, 逐步发展和完善。
根据银行信息中心的实际情况出发, 定义了四个发展阶段, 但不是强制性的必然历程, 也能够选择从某个阶段开始, 然后逐步发展进入下一个阶段。
如下图所示:

4.5.1 阶段一: 基于项目的测试
概念:
每个项目独立测试, 组建各自的测试小组, 手工或部分使用自动化工具, 在产品上线前能够发现一定的错误, 从而降低了产品运营时的风险和投产后进行错误修复而需要投入的成本。

阶段目标: 根据项目优先级选择某个科室中的一个或多个项目作为试点项目

工作内容:
l 建立可见的软件质量的度量体系
l 建立软件测试的基本流程和运作规范, 并投入运作
l 建立测试案例库
l 完成测试中心组织架构建设

组织结构:
测试中心负责人
测试经理
测试设计师( BA)
测试工程师
技术架构师
业务分析师
开发工程师

阶段成果:

l 具备对试点项目测试环境的配置能力
l 需求审核和变更管理
l 经过测试案例库的建立, 便于提升日后维护阶段的测试效率
l 测试过程流程化, 每个角色的任务得到充分明确
l 测试人员已具备基本的业务知识
l 经过专业的测试, 降低项目风险

4.5.2 阶段二: 产品中心
概念:
在”项目测试”阶段, 不同部门或LOB的项目小组往往发现她们自己在不断重复工作——浪费时间、 金钱和IT技能——工具不能相互兼容, 方法也前后不一致。为了改变这种状况, 就需要实现集中的、 标准的测试能力。 ”产品中心”这一模型, 它能使集中的测试工具产品变为一种可用的共享服务。在这一模型中, LOB能够巩固硬件、 软件和学习成本, 从而提高技术基础架构的ROI。

阶段目标: 以科室为单位, 逐步建立覆盖科室系统的测试体系
工作内容:
l 建立软件质量的全生命周期的管理
l 建立应用变更生命周期的管理
l 完善软件测试过程和度量体系
l 完善测试中心职能
组织结构:
测试主管
项目测试组A
测试经理
业务分析师
测试架构师
测试工程师
项目测试组B
测试经理
业务分析师
测试架构师
测试工程师
支持团队
测试文档人员
系统管理员

阶段成果:

l 基于缺陷分析的质量管理体系初步成型
l 测试指标得到量化, 便于统计分析, 并就是否上线为决策者提供量化依据
l 自动化测试平台的建立能充分减少测试执行时间, 从而降低项目成本
l 各类测试资产模版化、 规范化、 标准化, 方便阅读及流转
l 项目需求能得到严格的验证、 过滤及整合, 使得在项目的早期就能确定隐含的风险
4.5.3 阶段三: 服务中心
概念:
测试中心发展的下一阶段, 也就是第三阶段, 被称为”服务中心”模型, 在这一模型中, 测试中心集中提供服务和专业知识, 改进质量。一般, 项目测试往往局限于技术人员有限的专业知识, 只限于使用行业的最佳实践和流程。即使她们是这方面的专家, 也无法有效地展开LOB水平的专业测试。经过测试中心, 许多项目小组都能获取专业的经验和建议。

阶段目标: 以产品开发部为单位, 建立覆盖全部系统的测试中心体系

工作内容:
l 建立以技术目标为驱动, 产出以科技为核心的测试中心
l 定义软件质量服务的SLA, 建立软件质量风险和成本的管理模型
l 建立自我完善的可持续提升的质量过程

组织结构:
测试中心经理
服务支持团队
业务专家
系统管理员
项目管理/规范
测试项目经理
服务实施团队
测试架构师
测试设计工程师
技术文档人员
业务分析师
测试执行工程师

阶段成果:

l 对于多元化、 多架构、 跨平台的各类系统都能使用统一的测试指标进行衡量, 便于进行比对分析
l 经过部署无人值守的自动化测试平台, 持续改进测试过程, 降低测试成本
l 使用仿真测试工具替代手工测试, 提高测试效率
l 经过测试环境及应用配置的统一管理, 严控换版步骤, 保证换版质量及成功率
l 对业务功能进行风险和影响度的评估, 以缩减QA的时间, 并提高有限时间和成本内的质量水平
l 使用性能测试工具, 经过对系统的负载测试和压力测试提高这个系统的性能。

4.5.4 阶段四: 质量权威中心
概念:
最后一个阶段---第四阶段是测试中心向”质量权威中心”转化的过程, 在此阶段中, 测试中心将成为日常应用开发、 部署和操作的一部分, 帮助机构关于与应用卓越性。在此模型下, 任何应用只有经过一致的质量和性能测试流程, 而且满足协议质量标准后, 才能投入生产使用。一旦建立完成, ”质量和性能权威( Quality and Performance Authorities) ”( 甚至服务中心) 都能与第三方外包产品相媲美, 因为她们所具有的专业知识和跟踪记录是任何外包商所无法比拟的。”质量和性能权限”也能控制第三方外包商的实施过程, 在这些产品投入银行生产之前, 保证她们的质量和性能。

阶段目标: 建立独立的覆盖全行业务系统的测试中心体系, 并服务于全行机构

工作内容:
l 建立完整系统质量及流程控制体系
l 建设专业的业务专家和技术专家团队
l 建立完善的测试人员培养和职业规划体系
l 建设技术类测试体系及构架
l 建立完善的软硬件监控指标体系
l 完善全行性的业务知识库及基于业务问题的缺陷分析系统

组织结构:
测试中心经理
服务支持团队
业务专家组
技术专家组
项目管理/规范
测试项目经理
服务实施团队
测试架构师
测试设计工程师
技术文档人员
业务分析师
测试执行工程师
流程专家组
运行专家组
测试工程师

阶段成果:

l 对系统开发生命周期内的每个阶段的成果进行测试和验证, 并经过统一的测试指标进行度量
l 经过专业的业务专家和技术专家团队为中心乃至全行提供专业的咨询服务并实现信息共享
l 建立完善的、 阶梯式的人才培养机制, 从而降低人员流动风险
l 可快速高效地对提交测试的业务系统进行全面的、 系统的测试工作, 并提供专业的测试分析报告, 为决策提供依据
l 经过功能、 性能、 安全、 易用等多类型的测试方法对全行业务系统进行全面测试, 保证了测试的完整性和全面性
l 经过和IT战略规划中心和监控中心、 呼叫中心的互联, 从而实现质量体系建设的大战略

5 测试体系规划
5.1 测试准备
在实施测试前, 先要对测试工作进行一些必要的前期准备, 这其中包括:
l 测试指标定义
l 测试环境搭建
l 测试工具应用
l 测试管理工具
l 测试团队组织
l 测试数据准备

5.1.1 测试指标定义
测试过程中定义了四个度量指标: 测试覆盖率、 测试执行率、 测试执行经过率、 测试缺陷解决率。
1. 测试覆盖率
测试覆盖率是指测试用例对需求的覆盖情况。
计算公式: 已设计测试用例的需求数/需求总数。
测试覆盖率从纬度上说包括广度覆盖和深度覆盖; 从内容上说包括用户场景覆盖、 功能覆盖、 功能组合覆盖、 系统场景覆盖。
2. 测试执行率
测试执行率, 就是指实际执行过程中确定已经执行的测试用例比率。
计算公式: 已执行的测试用例数/设计的总测试用例数。
3. 测试执行经过率
测试执行经过率, 指在实际执行的测试用例中, 执行结果为”经过”的测试用例比率。
计算公式: 执行结果为”经过”的测试用例数/实际执行的测试用例总数。
为了得到测试执行经过率数据, 我们在测试执行时, 需要在测试用例副本中记录下每个测试用例的执行结果, 然后在当前版本执行完毕, 或者定期( 如每周) 统计当前测试执行数据。经过原始数据的记录与统计, 我们能够快速的得到当前版本或当前阶段的测试执行经过率。
4. 缺陷解决率
缺陷解决率, 指某个阶段已关闭缺陷占缺陷总数的比率。缺陷关闭操作包括以下两种情况:
正常关闭: 缺陷已修复, 且经过测试人员验证经过;
强制关闭: 重复的缺陷; 由于外部原因造成的缺陷; 暂时不处理的缺陷; 无效的缺陷。这类缺陷经过确认后, 能够强制关闭。
计算公式: 已关闭的缺陷/缺陷总数

5.1.2 测试环境搭建
搭建测试环境是测试实施的一个重要阶段, 测试环境是测试执行的保证。测试环境适合与否会严重影响测试结果的真实性和正确性。
配置测试环境可遵循下列原则:    
  　1．测试环境的正确性:
测试环境不但包括硬件, 还包括软件; 不但包括客户端、 服务器, 还包括网络环境、 测试数据等。测试环境在硬件上可能也有一些特定要求, 例如选用特定的显示卡、 打印机等。但在测试环境上出错的地方往往是在网络设置、 软件环境配置等方面。在Web测试上, 包括DNS、 SSL协议、 防火墙、 Apache/WebLogic等的设置, 还包括虚拟IP、 网络文件系统等。
2．测试环境的可靠性:
测试环境的正确性是最基本的要求, 要提高测试效率, 实施自动化测试, 要给测试环境提供更高的要求。对于一个测试项目, 应将性能测试环境和功能测试环境分开。在进行功能测试时, 最好也有两套同样的环境, 这样能提高测试效率。
3．测试环境的多样性和复杂性:
由于银行系统框架的多样性和跨平台性, 在搭建测试平台的时候, 就应该尽可能的考虑的满足测试要求的各种需要, 搭建一个完善的测试环境, 这样在正式使用的过程中才不至于产生问题。

5.1.3 自动化测试工具应用
自动化测试工具的出现, 极大地减少了测试人员的工作量, 原来繁杂的测试工作, 在自动化测试工具的帮助下, 变的简单而轻松。根据测试内容不同, 所使用的自动化测试工具也不尽相同。
功能测试工具
在测试业务逻辑等功能性应用时, 一般会选择有针对性的功能性测试工具( 比如QTP、 Rational Functional Tester、 Rational Robot等工具) , 当前在测试工具领域中, 技术最成熟而且市场占有率最高的测试工具是HP公司的Quick Test Professional( 简称QTP) ,该工具的功能是能够重现业务交易, 而且还能够进行批量交易, 从一定程度上减少了业务人员的工作量, 也提高了测试效率。测试时间的节约意味着测试人员能够把更多的精力放在业务逻辑和数据校验等重要工作上。
QTP的特点:
无人值守、 自动运行
QTP的案例设计能够由测试人员在工作时间完成, 而测试案例的运行能够在非工作时间进行, 从而减少测试人员在工作时间内花费在运行上的时间, 提高整体的测试效率。晚上运行脚本, 白天进行数据校验, 所节约的时间与QTP数量成正比。
实现数据移植, 降低风险
QTP能够用于数据的移植和导出, 方便地进行大规模测试数据准备。这样做比直接从数据库中导数更安全, 更完备, 不会造成系统内部逻辑错误和漏表情况发生, 风险较低。
测试脚本可重复利用
QTP脚本一次录入完毕后可重复使用, 这正是回归性功能测试的好处, 测试案例的高可重用性极大地减少了测试人员的工作量, 提高了总体测试的效率, 缩短了测试周期。
统一脚本管理、 易用性高
QTP具有统一、 简单的脚本维护功能, 便于日后修改和维护, 当被测系统进行了改动或升级, 能够很方便地进行相应脚本修改, 适应被测系统变化, 提高测试效率。

性能测试工具
性能测试是经过自动化的测试工具模拟多种正常、 峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试, 两者能够结合进行。
经过负载测试, 确定在各种工作负载下系统的性能, 目标是测试当负载逐渐增加时, 系统各项性能指标的变化情况。
压力测试是经过确定一个系统的瓶颈或者不能接收的性能点, 来获得系统能提供的最大服务级别的测试。
当前最常见的性能测试工具是LoadRunner, 经过LoadRunner, 能够生成虚拟用户, 以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程, 然后将其转化为测试脚本。利用虚拟用户, 您能够在Windows, UNIX 或Linux 机器上同时产生成千上万个用户访问。因此LoadRunner能极大的减少负载测试所需的硬件和人力资源。
用LoadRunner建立测试脚本后, 您能够对其进行参数化操作, 这一操作能让您利用几套不同的实际发生数据来测试您的应用程序, 从而反映出本系统的负载能力。以一个业务流程为例, 参数化操作可将记录中的固定数据, 如帐号和客户名称, 由可变值来代替, 在这些变量内随意输入可能的帐号和客户名称, 来匹配多个实际用户的操作行为。
在完成测试后, LoadRunner会将所测试的结果以报表方式呈现出来, 经过报表上的数据, 对系统的性能进行评估, 发现性能瓶颈, 给开发人员对系统的改进提供强有力的帮助。

仿真测试工具
在对一些特殊系统中特别是无界面的系统中进行测试, 需要仿真工具来配合测试。这样测试出来的结果才有实际意义。同时, 使用仿真工具还能降低联调的测试成本。

5.1.4 测试管理工具
QC是HP公司一个测试管理工具, 是业界第一个基于Web的测试管理系统,它能够在公司内部或外部进行全球范围内测试的管理。经过在一个整体的应用系统中集成了测试管理的各个部分, 包括需求管理, 测试计划, 测试执行以及错误跟踪等功能, QC极大地加速了测试过程。
由于所有的项目成员不可能在同一间办