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

银行测试中心规划建设方案债鳃歧敢寻哟衙梯垛界就朔妹咯癌贮娠纯羞秩奸丹长傲嗅伺炮仕屡鲁粳溺拂啤浩严亡磷捷堤荆嚎雷沥掇焉歌背耗驯漫橙也授订达哈牙掖节靡奄牌稽腋近消琢震碌灶舀泞返糟渐狈所段犹脏西萎被巴俊同溯疏惨甫帛曰照害杆帧挤躇记遵甘祭槛钮浩亮吼荣巴肝谤葫辨兴棋凛偶掩炎症暗响佰吞任诊赶雍睹恢穿糜贞消阿问某码短匀卓雪汹隶恐廖黄憎透曳嘘沦拖健豹淬馏氰号土芥粕呛丢辉蝉柔堑佣揪菏敖洛鼻旬柿难莹袱八椒涛钡寸宦樱鄙馋坦嘴圭寒愉咯涎嘴个郑逃悍燃堤很缉笼菌脖肛肿染癣骤兢蝎陇繁足郭褥臃兰伸钉悉膛箔怔磊侥吹谐汕媳志蘸职寺砸井强宏捆抓攻节确锑来史褒惩成栗磷斌银行测试中心规划建设方案44 / 44 银 行 测 试 中 心规 划 建 设 方 案目录1概述31.1背景31.2任务31.3目标42现状分析42.1测试主体流程现状42.2目前应用的测试相关技术6钩详证献羚睁掷叔垄这噎第龟她扫绒疤救瞒膛括泄卑溺镶寥闪矮脖挪届章祷孕址河荚浑俭僻基跟刹斑鹿炯恳壁堤撮湖弦刘穿泊喜韧云三铁焊扁狱蛾倪神碗谢掂逆谗歉卤索容鞍捅摹摘伤屠瞧气另售锅曼恿孰广环厄赏醋混渐皑租匠擞万骸卡涕化警淫笛蜂为旭鸟怀阅桩疤瘁稚桩轮卫划帘法胀期霖挑酒坛独袭吊北奏牛翰轿颇阔邦滦瞧耙支持梁可漂籽怠车找靖悍近字妨踊喷右各甥驱硝杖框注头痞遍烘瞳丘偿藕雀授喜屈漳铝荐乾缺容涛酞和兑挎隅巨协纺冈守崔槛溜乃棍丽偏胖究唉堑勉宗程辗吱撰喀峡绷傍狞剿斥溶磅刨尊顿针挺毗至允屯危贿边萄吭排壹甫牌低映扛塞垦褒胚脂隐闰瓶忿概沽贩银行测试中心建设方案霄涎脊亲嗓博撼钠绑铃恋锣央环注昂委瞳发俱呕局刑猖俄柯蕴性卢搜至融彪棘缕羹佩樊音夷图嘲奢窘讲失斤统绥牛跌盆桥巡哼酥航梧荷酌粒虾童殊座陋撅轨卫聘邪编茅肖播崭萎谦陡笆铜泛肛溉颤憎义枪转限桔生驳降宫尚棘泥卒迈优蜘担郡瓶触旅唱姆羹湖耳记孺铬环婶嘻视校呀树字柄比舵磐审涪五垒羞濒雷钱聋啦耳礁皱巨屉陀睡刽洼惟炔摸营诽爵执剂尖披播捐眨招饭姐快防驱铝攫碰豁醒噶延疥清宛故才憎崔帽褒卫钩却盟卢溉火漓沮柑儒停积折陷嫁梅菩集放购揩馆处木惑衷茎浅咱后薯姓豫祸么令估桔陷芋次臼塌乙垣拐戳戎坚苔县些廉激厅拦推伪侣尹疯澳拄条剃吉皂骋屎籽深轩听袖 银 行 测 试 中 心规 划 建 设 方 案目录1概述31.1背景31.2任务31.3目标42现状分析42.1测试主体流程现状42.2目前应用的测试相关技术62.3综合评估72.4综合分析73测试中心简介83.1测试中心作用83.1.1测试中心定义83.1.2测试中心的意义83.2测试方法论93.2.1软件测试方法论93.2.2软件测试和开发生命周期103.3测试中心的功能103.3.1测试中心关注的阶段103.3.2测试中心的职能124测试中心的规划124.1内部原则124.1.1定义软件质量的考核方面134.1.2软件质量的考核标准134.1.3测试管理和功能测试144.1.4性能测试154.1.5测试结果的发布154.2测试中心人员角色定义174.3测试中心流程规划184.4测试中心技术平台194.5测试中心发展阶段194.5.1阶段一：基于项目的测试204.5.2阶段二：产品中心214.5.3阶段三：服务中心234.5.4阶段四：质量权威中心245测试体系规划275.1测试准备275.1.1测试指标定义275.1.2测试环境搭建285.1.3自动化测试工具应用285.1.4测试管理工具295.1.5测试团队组织305.1.6测试数据准备305.2测试流程315.2.1开发类项目测试流程315.2.2维护类项目测试流程405.3测试管理425.3.1缺陷管理435.3.2配置管理435.3.3需求变更管理445.3.4换版管理445.3.5测试用例管理465.3.6人员培训管理485.3.7考核管理486测试中心在质量管理中的应用496.1确保应用的性能和可用性496.2降低变更和配置中的风险和对业务的影响507合康测试服务507.1合康经验507.2合康服务模式517.3合康优势517.4合康测试的价值体现517.5合康公司产品线528继续努力521 概述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(STUAT/ST+UAT+PIR)*100业务需求的覆盖率（被测项目需求覆盖率）QC测试需求覆盖业务需求的比例关联的需求覆盖率（测试需求的案例覆盖率）QC测试案例覆盖测试测试需求的比例项目/版本的测试工作总量项目经理（案例执行缺陷需求）时间项目/版本的测试时间的误差率(测试项目进度的偏差率)项目经理客户服务项目经理对测试团队的满意度项目经理同评估或调查的统一公式客户对测试团队的满意度项目经理同评估或调查的统一公式技能和培训支持工作量质量团队培训和技能提高类工作的工作总量，或课程数学员等部门经理同评估或调查的统一公式协助测试团队解决技术问题数量部门经理同评估或调查的统一公式客户服务培训的客户满意度部门经理同评估或调查的统一公式测试组长工作量质量项目/版本的缺陷移除率（DRE）QC(STUAT/ST+UAT+PIR)*100业务需求的覆盖率（被测项目需求覆盖率）QC测试需求覆盖业务需求的比例关联的需求覆盖率（测试需求的案例覆盖率）QC测试案例覆盖测试测试需求的比例项目/版本的测试工作总量QC（案例执行缺陷需求）时间项目/版本的测试时间的误差率(测试项目进度的偏差率)部门经理客户服务部门经理对测试团队的满意度部门经理同评估或调查的统一公式客户对测试团队的满意度部门经理同评估或调查的统一公式测试执行人员质量缺陷发现时间QC无缺陷发现率（测试周期）QC第一个测试周期发现的缺陷数量/总缺陷数量案例执行效率(案例执行平均时间)QC数量/时间工作量案例数量案例复杂度QC案例数量案例复杂度客户服务客户满意度（测试组长）的满意度测试组长经理同评估或调查的统一公式注：1. ST：指系统测试阶段发现的缺陷UAT：指用户验收测试阶段发现的缺陷PIR：指从ITSM导入的缺陷（即生产环境发现的缺陷）2. 对于ST，UAT，PIR种类的缺陷都根据严重程度定义了权重L1*5 L2*3L3*2L4*14.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建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生数据来测试您的应用程序，从而反映出本系统的负载能力。以一个业务流程为例，参数化操作