银行测试体系规划建设可行性研究方案

1、 1 银行测试体系规划建设可行性研究方案 2 目 录 1 概述 . 5 1.1 背景 . 5 1.2 任务 . 5 1.3 目标 . 5 2 现状分析 . 6 2.1 测试主体流程现状 . 6 2.2 目前应用的测试相关技术. 9 2.3 综合评估 . 9 2.4 综合分析 . 11 3 测试中心简介 . 12 3.1 测试中心作用 . 12 3.1.1 测试中心定义 . 12 3.1.2 测试中心的意义 . 13 3.2 测试方法论. 14 3.2.1 软件测试方法论 . 14 3.2.2 软件测试和开发生命周期 . 15 3.3 测试中心的功能 . 16 3.3.1 测试中心关注的阶段 .

2、 16 3.3.2 测试中心的职能 . 18 4 测试中心的规划 . 19 4.1 内部原则 . 19 3 4.1.1 定义软件质量的考核方面 . 19 4.1.2 软件质量的考核标准 . 20 4.1.3 测试管理和功能测试 . 20 4.1.4 性能测试 . 21 4.1.5 测试结果的发布 . 22 4.2 测试中心人员角色定义 . 26 4.3 测试中心流程规划 . 28 4.4 测试中心技术平台 . 29 4.5 测试中心发展阶段 . 29 4.5.1 阶段一：基于项目的测试 . 30 4.5.2 阶段二：产品中心 . 32 4.5.3 阶段三：服务中心 . 34 4.5.4 阶段四

3、：质量权威中心 . 37 5 测试体系规划 . 40 5.1 测试准备 . 40 5.1.1 测试指标定义 . 41 5.1.2 测试环境搭建 . 42 5.1.3 自动化测试工具应用 . 43 5.1.4 测试管理工具 . 46 5.1.5 测试团队组织 . 47 5.1.6 测试数据准备 . 47 5.2 测试流程 . 49 5.2.1 开发类项目测试流程 . 49 4 5.2.2 维护类项目测试流程 . 64 5.3 测试管理 . 69 5.3.1 缺陷管理 . 70 5.3.2 配置管理 . 71 5.3.3 需求变更管理 . 71 5.3.4 换版管理 . 72 5.3.5 测试用例

4、管理 . 错误！未定义书签。 5.3.6 人员培训管理 . 错误！未定义书签。 5.3.7 考核管理 . 错误！未定义书签。 6 测试中心在质量管理中的应用 . 错误！未定义书签。 6.1 确保应用的性能和可用性. 错误！未定义书签。 6.2 降低变更和配置中的风险和对业务的影响 . 错误！未定义书签。 7 合康测试服务 . 错误！未定义书签。 7.1 合康经验 . 错误！未定义书签。 7.2 合康服务模式 . 错误！未定义书签。 7.3 合康优势 . 错误！未定义书签。 7.4 合康测试的价值体现 . 错误！未定义书签。 7.5 合康公司产品线 . 错误！未定义书签。 8 继续努力 . 错误

5、！未定义书签。 5 1 概述 1.1 背景 随着银行业务的快速发展，对银行业务系统的质量控制与质量管理正逐渐成为银行稳定发展的保障。而建设稳健优良的测试体系和与之匹配的测试方法则又是保证软件系统质量行之有效的必经途径。 1.2 任务 测试中心是整个银行业务研发体系建设内容的重要组成部分之一，为我行自己研发、外包、采购软件系统进行完整系统的测试，提供最佳品质保障，并为过程改进和管理提供决策支持。建设测试中心的主要目标在于提升我行在银行业务测试环节中的质量控制的能力，通过测试中心的建设，形成系统的测试流程，通过与各个产品研发环节的信息充分连接，为系统质量分析和评估提供有效的支撑；基于测试中心构建的

6、IT平台，有系统性地收集、积累项目的历史质量管理经验及数据，提炼共性质量分析和评估模型，形成结构化、知识型、可共享的质量管理资源库，为长期不断地提高我行业务系统的质量奠定坚实的基础。 1.3 目标 测试中心总体建设目标： ? 建设与整个软件开发体系配套的测试体系 6 ? 建立一流的软件测试流程，保证测试工作质量 ? 逐步建立量化的度量标准，持续改进软件测试过程 ? 建立一支银行业务能力过硬，测试技能一流的测试团队 ? 建立一流的软件测试环境体系（包含测试硬件环境、系统软件（操作系统、服务器等）、自动化测试工具等） 2 现状分析 2.1 测试主体流程现状 现行软件开发操作流程图 7 项目开发流程

7、需求确认阶段业务部门（客户）信息技术部项目组信息技术部相关科室开始业务部门提出业务需求功能测试用户验收测试日常操作，提出优化需求反馈情况技术论证基本需求方案需求分析设计开发技术及性能测试系统试运行，跟踪系统运行情况反馈情况情况良好需求评审，若有必要，申请技术评审费用、人力计划预估实施方案评审上线评审上线换版系统运行支持，验收评审(移交)开发测试阶段跟踪反馈阶段 8 目前相关测试人员组织结构 信息技术部软件一科 （兼职测试案例设计）科室负责人监督员（兼职测试实施）监督员A B软件二科科室负责人监督员 （兼职测试案例设计）监督员（兼职测试实施） 软件三科 A B （兼职测试案例设计）（兼职测试实施

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

9、效地规划和执行。 测试团队是由监督员组成的虚拟团队，缺乏实体测试组织，缺乏明确的软件质量和软件测试的管理和执行人员角色定义。 9 2.2 目前应用的测试相关技术 目前信息技术部主要通过CA办公自动化系统与银行各相关职能部门进行需求的流转，无专业需求管理系统，各类测试阶段的实施仍停留在手工测试方式，没有统一的测试管理系统来进行有效的问题管理及测试计划的实施，测试过程中的资产被采用不同的方法和技术记录和管理，导致测试资产（指测试过程中生成或编写的各类文档、脚本、代码、配置文件等）的管理带来困难，使这些资产的价值被忽视，变成被保留的历史数据，而非可促进质量持续提升的基础。 随着银行各类业务系统从单一

10、技术框架结构向多样化技术框架结构的转变，目前的测试手段和技术已显然无法满足行内多平台、多语言和多厂商的快速开发上线的模式。 2.3 综合评估 业务部跨平台多样化技术架传统单一的技术架系统开发测试环 软件开发部 运行科用户测试环准生产环ITS管理系T自动化测试管理系C办公自动化系 Quality ExpertQuality SavvyQuality ConsciousQuality Initializing1234资源共享服务和工作请求需求缺陷管理报告和度量 10 11 2.4 综合分析 已达到的程度： ? 业务需求管理过程已经建立 ? 已产生需求过滤及整合机制 ? 对软件质量有改进意识 ? 部

11、分系统已尝试使用自动化测试工具 ? 使用ITSM进行服务管理 尚存问题： ? 测试知识无法传承，容易产生盲区 ? 业务人员角色冲突，测试无法有效规划和实施 ? 缺乏统一的需求管理、测试管理流程和系统 ? 手工测试效率低下，无法覆盖全部测试需求 ? 配置管理缺乏，案例完整性难以保证，存在潜在风险 ? 测试资产难以有效保存，价值易被忽视 ? 测试环境管理缺乏，容易造成版本错换、漏换 ? 缺乏对外包项目的质量管理，无法对外包厂商的软件质量进行量化评估 12 3 测试中心简介 3.1 测试中心作用 3.1.1 测试中心定义 ? 软件质量：软件质量是软件特性的总和，软件满足规定或者潜在用户需求的能力 ?

12、 软件测试：软件测试的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。由于软件是由文档，数据以及程序组成的，因此目前软件测试涵盖的已经不仅仅是对程序进行测试，还应该包括对软件行程过程的文档和数据进行的测试。 ? 测试中心： 测试中心是区别于开发团队的相对独立的，统一的团体或者组织，其人员具有先进的测试理论和经验，能够遵循测试管理流程，通过手工或者自动化测试工具，对系统或软件开展有组织的，有效的测试活动，从而对系统或软件提供整体的质量评估。 ? 测试中心的特点在于： ? 具有相对独立性，统一性 ? 可以作用于不同的系统或应用 ? 具有一致的管理流程和软件质量可见性 ? 提供

13、集中的基础架构 ? 具有专业的团队，实现了技能和测试资产共享 13 3.1.2 测试中心的意义 相比单纯的某个项目内部的测试工具采购和使用而言，建设统一的测试中心的意义在于： 有效性：应用开发/实施产品、最佳实践方法和人员都实现了集成，可以从一个点上就能便捷地获取所有项目小组的权限，因此不需要增加昂贵的资源投入。（事实上可能会减少职员总人数。） 改进性：可以从整个银行中收集测试流程、组织和产品方面的最佳实践，并且标准化及改进这些实践，然后重新把这些改进过的实践发送到整个银行中。这样，就缩短了新的测试项目的学习曲线，提高了所有测试小组的成功可能性。 统一性：测试中心模式能帮助银行统一业务目标和项

14、目优先级，提供更好的最终用户服务。 实用性： 建立一个测试中心模型，这是一个可以达到的目标。您可以利用现存的各种资源从小范围开始实施，然后，在证实其价值后，再进一步扩展其能力。许多公司往往会发现测试中心模型是自给自足的。 职业提升：测试中心模型为专业人士提供了一个具有吸引力的新职业机会，帮助银行重新招募并保留顶级人才。 14 3.2 测试方法论 3.2.1 软件测试方法论 实施 实施 设计 应用部署 测试 传统方法论 需求验证 应用部署 优化业务成果 现代方法论 对业务功能进行风险和影响度的评估，以缩减QA的时间，并提高有限时间和成本内的质量水平 业务影响分析 验证需求 2 使IT能更好的迎合

15、业务需求，在应用交付的早期就能够确定可能存在的缺陷 使用业务度量 3 规划 业务需求 设计 测试 1 时间 业务需求 规划 提供质量流程改进的面向目标的关键性能指标，这些指标是面向业务需求的 传统的开发方法属于线型或者称之为瀑布型，每一个阶段的开始都基于上一阶段成果而展开，因此无法对整个系统质量进行有效的控制，无法体现测试对于整个系统质量控制的重要性，一旦在后期测试中发现问题，很有可能导致软件发布延迟，整个项目成本的增加。 我们所提倡的测试方法是将测试贯穿于项目规划、设计、实施、部署的整个过程中，随时对项目质量进行监控。一旦发现问题，及时提交，使问题能够尽早、尽快地得以解决。 15 3.2.2

16、 软件测试和开发生命周期 RequirementsVerificationTest Strategy &Test PlanTest caseSystemTestTestUATReadinessTestProblemDiagnosticPerformance 通过在软件项目过程中自始至终地贯彻尽早测试、连续测试、自动测试经验的实施，能很大程度上提前了软件系统测试发生的时间，能连续的及时的发现软件错误，从而可以在很大程度上降低项目风险和项目开发成本。 RequirementsFunctional & Technical SpecsBuildTest ExecutionDeployMercury Q

17、uality ProcessesOperation 16 3.3 测试中心的功能 3.3.1 测试中心关注的阶段 以下是软件测试V&V模型图： 如图所示，测试过程主要分为四个阶段：单元测试，集成测试，系统测试，验收测试。 在模型中，单元测试是基于代码的测试，最初由开发人员执行，以验证其可执行程序代码的各个部分是否已达到了预期的功能要求； 集成测试验证了2个或多个单元之间的集成是否正确，并有针对性地对详细设计中所定义的各单元之间的接口进行检查； 17 在所有单元测试和集成测试完成后，系统测试开始以客户环境模拟系统的运行，以验证系统是否达到了在概要设计中所定义的功能和性能； 最后，当技术部门完成了

18、所有测试工作后，由业务专家或用户进行验收测试，以确保产品能真正符合用户业务上的需要。 单元测试和集成测试主要由开发团队完成，因此测试中心主要关注的是系统测试和验收测试，当系统上线以后，在版本更新和缺陷修复过程中，测试中心也会承担回归测试的任务。 V&V模型中，两个V分别代表验证（Verification）和确认（Validation）。 软件验证技术是“评估系统或部件在特定的开发阶段是否满足该阶段开始时人们对它提出的要求”。软件验证是在软件开发的各个阶段，从软件技术人员的角度，测试当前的开发成果（文档，代码等）符合设计的规范，保证按照设计流程和要求进行开发，即“正确地做了事”。 软件确认技术是

19、“评估系统或软件部件在开发过程中或开发结束时是否满足特定要求”。软件确认是从用户的角度，测试当前的开发成果符合用户的真正需求，即“做了正确的事”。 所以V&V模型更能体现测试在整个软件系统的建设过程中，对质量控制所起到的至关重要的作用。 V&V模型是目前主流测试过程模型,但其并不是万能的，因此在测试过程模型的引用中除了该模型外我们还将把随机测试和配置测试理念贯穿其中。 18 3.3.2 测试中心的职能 测试中心涵盖的功能应该包括： ? 业务需求: 分析业务需求，保证测试与业务需求统一 ? 标准规范：通过实际和理论相结合，建立适合自己的规范，并且进行验证，同 时遵循相应的标准和规范 ? 系统模型

20、：具有内部统一的测试模型和被测系统搭建能力，可以进行模型验证 ? 应用功能：提供功能测试管理和执行 ? 应用性能：提供性能测试管理和执行 ? 系统维护：提供内部基础架构，被测系统和测试工具的日常管理和维护 ? 应用管理：通过与上线后的应用管理和监控集成，获得错误反馈，对测试工具 进行评估和改进。 19 4 测试中心的规划 4.1 内部原则 测试中心应该和业务部门，研发部门等一起讨论，建立起软件质量的考核方面和标准 4.1.1 定义软件质量的考核方面 -功能性：应用的各个业务场景的功能完备 -可用性：应用的用户操作界面的易用和可接受性 -可靠性：应用在长时间运行下的稳定和安全 -性 能：多用户并

21、发和尖峰压力下的功能性和响应时间 -可维护性：应用在生产环境下的维护难度 20 4.1.2 软件质量的考核标准 根据国家标准和行业标注，根据业务需求，制定合适本测试中心的，结合不同类型系统的质量考核标准。 软件项目质量考核有一个完整的指标体系，从可行易操作的角度出发，评价一个软件项目质量情况，可以从以下几个方面出发，获取比较客观的评价指标。指标内容说明如下： 1. 小组考核内容: 小组工作量负荷情况分析、小组工作量完成情况分析 2. 项目考核：项目进度完成情况分析、项目工作内容组成情况分析 3. 个人考核：个人进度完成情况、个人工作表现情况 4. 缺陷率考核 4.1.3 测试管理和功能测试 2

22、1 通过业务需求转换为测试需求，以定义软件项目质量管理的目标。 从需求到案例设计，建立案例，测试执行和缺陷跟踪都必须纳入管理之中，实现测试资产集中管理。 通过统一的测试管理平台将单元测试，集成测试，系统测试和用户接收测试连接起来，将开发人员和测试中心连接起来，形成有效的合作工作流程。 制定测试管理流程，并且通过统一的测试管理平台进行流程的规范。 在有效的测试管理下，通过手工或者自动化功能测试工具完成功能测试，保证系统的功能满足业务需求，同时逐步完善自动化功能测试，建立自动化功能测试框架，以解放人力，提高功能测试的效率。 4.1.4 性能测试 为了保证系统上线后可以达到系统的性能要求，测试中心需

23、要对系统进行严格的 22 性能测试过程，测试中心将使用自动化的性能测试工具对交付软件进行性能测试，并使用测试管理与分析工具对测试结果进行分析，以保证交付软件可以达到系统性能要求。在测试过程中可以使用性能测试工具帮助分析性能瓶颈，进而解决性能问题。 性能测试过程中不仅仅需要进行压力加载模拟，更主要的还需要能够提供监控功能，监控被测系统各个环节在压力情况下的指标表现，同时需要提供比较强大的结果分析功能，为了更好的解决应用开发中可能存在的性能瓶颈，需要具有有效的手段，能够发现应用开发中代码和SQL级别存在的性能问题，从而帮助开发人员优化代码，提高系统性能。 4.1.5 测试结果的发布 在功能测试和性

24、能测试阶段，测试中心需要针对各个项目提供有效而全面的功能测试报告和性能测试报告。功能测试报告应该包括自动化功能测试执行各个步骤的信息和正确与否，性能测试报告应该包含丰富的应用性能分析信息。 测试中心同时还需要生成软件测试评估报告和测试过程报告，例如测试需求覆盖率，缺陷趋势，测试过程中问题汇总等。 能够针对定义的考核方面和考核标准，提供监控质量报告。 通过统一的测试管理平台，测试中心需要针对所有项目，通过定义的关键性能指标（KPI），提供全面的信息视图。同时能够提供视图的个性化功能，满足不同角色的人员查看的需要，提高工作效率。 23 测试管理和质量评估KPI一般包括： 考核对象 考核KPI维度

25、考核指标KPI 指标来源 指标计算公式 测试专家 工作量质量 项目/版本的缺陷移除率（DRE） QC (STUAT/ST+UAT+PIR)*100 业务需求的覆盖率（被测项目需求覆盖率） QC 测试需求覆盖业务需求的比例 关联的需求覆盖率（测试需求的案例覆盖率） QC 测试案例覆盖测试测试需求的比例 项目/版本的测试工作总量 项目经理 （案例执行缺陷需求） 时间 项目/版本的测试时间的误差率(测试项目进度的偏差率) 项目经理 项目经理对测试团项目经理 同评估或调查的统 24 客户服务 队的满意度 一公式 客户对测试团队的满意度 项目经理 同评估或调查的统一公式 技能和培训支持 工作量质量 团队

26、培训和技能提高类工作的工作总量，或课程数学员等 部门经理 同评估或调查的统一公式 协助测试团队解决技术问题数量 部门经理 同评估或调查的统一公式 客户服务 培训的客户满意度 部门经理 同评估或调查的统一公式 工作量质量 项目/版本的缺陷移除率（DRE） QC (STUAT/ST+UAT+PIR)*100 业务需求的覆盖率（被测项目需求覆盖率） QC 测试需求覆盖业务需求的比例 关联的需求覆盖率（测试需求的案例覆盖率） QC 测试案例覆盖测试测试需求的比例 25 测试组长 项目/版本的测试工作总量 QC （案例执行缺陷需求） 时间 项目/版本的测试时间的误差率(测试项目进度的偏差率) 部门经理

27、客户服务 部门经理对测试团队的满意度 部门经理 同评估或调查的统一公式 客户对测试团队的满意度 部门经理 同评估或调查的统一公式 测试执行人员 质量 缺陷发现时间 QC 无 缺陷发现率（测试周期） QC 第一个测试周期发现的缺陷数量/总缺陷数量 案例执行效率(案例执行平均时间) QC 数量/时间 工作量 案例数量案例复杂度 QC 案例数量案例复杂度 客户服务 客户满意度（测试组长）的满意度 测试组长经理 同评估或调查的统一公式 注：1. ST：指系统测试阶段发现的缺陷 26 UAT：指用户验收测试阶段发现的缺陷 PIR：指从ITSM导入的缺陷（即生产环境发现的缺陷） 2. 对于ST，UAT，P

28、IR种类的缺陷都根据严重程度定义了权重 L1*5 L2*3 L3*2 L4*1 4.2 测试中心人员角色定义 测试中心人员结构因不同的发展阶段而不同，详细请看第四点测试中心发展阶段，在此仅列出所涉及的常用角色及职责说明。 人员角色 工作职责 测试中心经理 管理测试中心的日常工作，负责所有工作的指派和人员调整，监督测试项目的流程进度和质量 业务专家 作为资深业务分析人员的主要职能是提供对业务人员或团队进行业务支持、分析和培训 运作专家 运作专家将负责测试团队的知识技能的管理，QA流程建设等工作，提供中心的共享服务 27 测试项目经理 负责具体的一个或多个测试项，管理项目内部的工作流程，项目人员的

29、工作任务分配，直接对测试中心经理负责，对所提出的评测结果和报告负责，评估测试项目质量 测试架构师 测试中心的专业测试顾问，针对项目制定测试策略，总体设计测试计划，考核测试结果，控制流程更改，评估和总结被测试应用的质量 测试设计工程师 设计测试计划和案例，设计自动化测试脚本，熟悉各种测试工具和技术，定义测试实施计划 测试执行工程师 执行测试案例，记录案例运行结果，分析测试结果，提交缺陷报告 业务人员 提供和确认被测试系统业务需求，检验被测试系统测试结果，提供业务测试数据 系统管理员 管理和维护测试管理系统，搭建和维护被测试系统 测试工程师 具有相对比较丰富测试案例开发和执行经验人员.可以指导或负责具体的测试执行工作 28 4.3 测试中心流程规划 上图流程包括： -需求审核和变更管理 -缺陷管理 -测试策略和计划模型 -度量和KPI报告 -测试流程管理 -测试资源和工作管理 -测试案例和脚本 -人员时间和技能 -系统测试 -测试环境 -性能测试 -回归测试 29 过程 模板 测试资产