文思海辉刘爱华：测试体系建设

ZDNET至顶网CIO与应用频道 11月04日 北京消息（文/王聪彬）：文思海辉金融测试事业部的售前部总经理刘爱华在中国金融行业IT解决方案研讨峰会上首先指出测试只是以一个手段，目的是保证业务系统上线运行之后的质量有保障。

刘爱华认为，测试体系是融会测试遵从的为标准、规范和流程，贯通测试采用的策略、技术和方法，业务知识，（人员+方法+技术）×测试环境，过程质量标准，在项目过程当中按照过程质量标准进行累计进行提升。

文思海辉金融测试事业部的售前部总经理 刘爱华

以下为演讲实录：

现在面临两重挑战，这个时间对大家压力很大，希望大家坚持一下，菲利普说第二个发言压力很大，上午不管从领导从客户，从专家讲了很多，我听了一下，把测试体系的这些东西都已经涵盖在内了，我下面讲什么呢，占用大家时间不太好意思，我跟大会主持商量要不跳舞就算了，漂亮主持冲我一乐，问我一句话，中午吃的怎么样，看来不讲不行了。我记住了菲利普的第二句话，现在讲什么不要紧，现在高科技，我们可以上网查。什么是体系？人人都在讲体系，我之前对体系真是没有太多的理解，我上午查了一下，往大里说，总宇宙是一个体系，各个星系是一个体系，往效力说，社会是一个体系，众多的小体系构成大体系，是总体系，总则为一，化则无穷，反之亦然，这就是体系。有点玄，但是有道理，第二个解释就是指若干有关事物或某些意识相互联系的系统而构成的一个有特定功能的有机整体。按理说就应该知道什么是测试体系了，可以举一反三，但是年纪稍微有点大，还是搞不懂什么是测试体系，我们先不说这个事情。本人在IT里混二十多年了，半路出家，今天上午中行的张处很亲切，我跟他很长时间共事，跟很多行业客户也聊过，他们有很多问题。我想他们那些问题肯定跟测试体系有点相关，我们反过来看看这些问题都有什么，把这些问题归纳了一下，实际是三大类问题。

一个是为什么要测试，这个问题是不是有点小儿科，谁都知道要测试，可是细分起来不一定那么简单。第二个就是要做什么测试，再一个就是怎样做好测试，如果能回答这三个问题，对今天讨论的话题就有一个脉络了。为什么要测试呢？今天赵主任开始讲的最好，我们测试只是一个手段，我们目的是什么呢？是要保证我们这个业务系统上线运行之后，它的质量有保障。测试本身作为应用软件生命周期质量保证体系的基础和支撑，我跟客户沟通，我们整个质量体系比较完备，可是到了落实具体质量的时候，感觉到有点阻力了，到了项目组以后，到了各个环节以后，跟他们讲好像是有些负担。测试这个东西一定是说能够把整个质量贯彻到底的落地的一个支撑，采用系统化的方法，通过严格缜密的过程，全面检验应用系统的交付质量，以达到规定的投产标准。

为什么测试？说一千道一万，就是要保障我们投产的质量标准。投产质量标准，其实我们这个标准非常多，因为我本人不是搞QA，QA我也不太懂，但是我认为从一个银行业务系统它最终的质量就是生产以后，交付数据，不外乎两个方面，一个是功能性标准，这个系统所提供的业务功能是不是能全面覆盖功能规格，所做的业务能不能支持，在执行这些业务的时候是不是能正确。刚才上午大家讲的很好，对一个软件来讲，无论如何缺陷没法穷尽，但是我们怎么样能够通过达成一个共同认可的缺陷容忍度，达到上线，因为测试要考虑成本、质量、时间、市场效益，我们不能无穷无尽的去测试，这样就没有意义了。我们要规定一个大家能够认可的对缺陷的容忍度。非功能质量标准，我们知道在生产运行当中，某一个功能有了缺陷的话，其实影响并不是最致命的，最致命的往往是非功能的出了问题，在非功能质量标准方面考核的更多，制定更加严格。系统性能方面的要求就不用说了，我们提供了服务，达到什么服务水平，我们的设备日处理量，还有我们处理窗口够不够，如果不够，第二天开不了门了，承载量不够，系统上去以后就垮掉了。刚一开门卖国债，系统就死掉了，秒杀，强买，非功能性的指标我们应该定义非常清楚。还有系统安全方面，不用说了，另外还有RAS，可靠性、可用性、可维护性，可靠性不用说，我的系统不要遇到故障就死机。可用性，跟前面领导讲的那个理解稍微有点角度上的不一样，它这个系统对用户提供服务的水平，现在银行达到99.99%，一定要限制在最小范围之内，为用户提供服务。还有就是可维护性，我们系统总在变更，新的系统投产上线，对原有系统版本升级等等，不要造成过多的中断。不要这个系统设计的时候没法更新换代。

刚才讲到有关为什么要测试，下面跟着讲要做什么测试呢？大家知道这是一个老掉牙的东西了，从设计、开发、测试、投产，系统设计、功能设计、程序设计、程序开发，软件设计有SIT，为什么还要讲这些东西呢？一方面来讲，它对测试有一些规定的要求，在什么时间一定要做什么样的测试，否则你的质量在后期就会反映出来，达不到标准。另外这个明显有它的局限性，如果有些我们只在后续测试的话，有些本质性的问题，结构性的问题，我们发现以后，再去修复，再去纠正，成本就太大了。我们应该在前面在做延伸，在做系统设计架构原型设计，当然不只是结构承载能力，还有很多方面的东西。另外在系统投产以后，我们并没有终结，我们系统还在不断更新换代，我们这个系统还需要维护，不管是从应用系统版本升级，不管是运行环境的版本升级，这些都对整个系统的表现有影响，所以我们在投产以后，还是系统维护性的测试。系统维护性测试还有很重要的一环，前段时间跟客户交流的时候谈到一个可恢复性测试的问题，投产以后出现故障以后，虽然我们数据都有备份设计，可是他总是担心数据不对，因为搞系统的人都知道，我们在运行过程当中，有些动态参数调整完了以后，有些并没有存在系统里面，重新切换以后就死机了，要做可恢复性测试。作为测试来讲，如果有条件，有机会的话，在投产以后这个阶段需要考虑。

领域从开发环境来讲，在测试过程当中不断进行修复，模型本身没什么意义，这体现两个方面的意思，第一个方面的意思，就是我个人认为测试虽然讲端到端，尽早进入，全覆盖，可是从真正实施的角度讲，任何事情都要有边界，有范围，这样我的目标才明确，才可控。如果什么事情没有一个边界范围界定的话，从头到尾总是想把所有的事情做好，往往做不好。我们可以重点看在每个阶段的某些测试，有一个基本的划分以后，每个阶段都把事情做好了，自然全过程就做好了。在往后的讨论当中有关测试体系方面，我想有些内容是分类SIT以后的这些，为什么这么讲呢？在SIT相关测试方面的一些方法一些标准，一些规范等等，我们希望在开发过程，项目组他们进行管理。我们重点针对投产最关键的这些指标进行重点衡量，这种划分并不影响我们提前介入。反之，从头到尾一体化的考虑，也并不排斥说还是应该去考虑每个阶段有比较明确的边界范围。这里面体现一点，软件质量控制是无穷无尽的，是循环往复的过程。从设计到测试到投产以后，随着新的版本变化，有变更的部分，新增的部分，有新的需求，经过这个周期，需要进行各方面的设计，编码再测试，又有新的需求。对于有影响部分的地方，用回归的测试，这样就形成生命周期有机的一个循环。
怎样做好测试？我是做系统出身的，测试之前我一窃不通，有机会我去听听测试方面的论坛，他们告诉我，测试三要素，三个P，人员、方法、技术，有了这三个就能做好测试了。可是我后来一琢磨，也是，也不是，如果只是在我开发周期循环里面，我也许可以的，可是我们现在讲，赵主任说的特别好，我们不是仅仅测试软件，软件只是棋盘当中一个棋子而已，我们要考虑整个系统，要测试系统，要做系统方面的测试还需要什么呢？一定需要一个合适的测试环境和业务知识。不同业务怎么测？没法测，没有环境随便测，肯定会死的，毫无疑问，而且现在银行系统环境那么复杂，业务测试环境我认为还需要加强。刚才提到了，我们不能无头苍蝇，我们要知道我们测试什么东西，测试标准，另外我们有了人员，有了方法，有了技术，还需要规矩，做事没有规矩不成方圆。什么叫规范？就是规定的，你照这个样子去做，它规定了你要做什么，怎么做，达到什么标准，什么要求，一种指南性的东西。我认为我们要做好测试，尤其是要做好保证应用系统上线以后投产这种测试，这几个要素必不可少。
业务知识我就不说了，我绝对是外行，在座的都是专家，给我们文思海辉做一个广告，文思海辉可以不太谦虚的说，我们在国内金融测试方面是走在前面的，之所以走在前面是我们真正懂业务，我们文思海辉有一系列银行运用的东西，核心系统、渠道系统、客户管理、业务管理、集成应用，很全面，我们有这方面的知识，能支撑测试过程当中的一些规范也好，一些标准也好，这是很重要的一个因素。

标准回过头来再多说两句，前面说要想做好全过程从头到尾的测试，还是应该有所界定呢？原因是便于对各个阶段的质量进行控制。各个阶段的测试有自己的目标和任务，我主要讲三个方面的主要标准，准入标准、准出标准、验收标准。准入，我们测试过程的准入标准非常重要，今天张处也提到，往往筹备过程需要考虑很多东西，准备阶段至关重要。如果不了解前面的交付情况怎么样，时间耽误了，结果不会好，准入标准非常重要，准入标准也分很多层次，测试过程有它的标准，测试任务有它的准入标准，还有系统投产有它的标准。另外准是准出的标准，准出标准分两个方面，一个是开发交付准出，一个是测试交付准出。我个人认为开发之前，项目内部之间一些测试，包括它的文档，包括它的交付，包括所有的东西，它要满足这个标准。

规范，规范有很多，我简单归纳为三个方面，测试规范、管理规范、文档规范，测试规范今天上午专家都讲到了，我们测试过程、执行过程应该怎么做，做哪些事情，我们测试过程需要什么人员，需要什么环境，什么数据，什么工具，知识库怎么去积累和使用，过程怎么控制。管理规范，测试任务需要一个管理的过程，今天有一位同行讲的好，三分技术，七分管理，管理非常重要。管理有哪些规范呢？测试任务与项目优先级，并发的任务权重不一样，轻重缓急不一样。还有整个项目生命周期与实施过程的管理，对整个测试团队，对测试资源来进行管理，还有测试问题与测试资源、测试问题与软件缺陷。文档规范非常重要，有的同志告诉我，他在设计一款好的工具，这款工具可以参照功能设计规格说明书，能够自动识别它的功能点，自动设计它的场景，自动设计它的案例，我说这很好。可是如果它的文档没有写出来，你怎么介绍，这就是对文档规范方面，对以后推进标准化、自动化、规范化非常重要，可是我们往往忽略这个环节。有人告诉我，他需求说明书就几页纸，连个框图都没有，这个文档规范虽然这都是老生常谈，我个人觉得转了一圈回来看，其实还是这些内容。

测试的环境，可以这么讲，测试环境对我们规模化或者对整个投产项目最终质量控制这种测试来讲，非常重要。原因就是说如果我们测试环境不能够代表生产环境的特征，我们测试的结果就是不真实的，上线一定会有问题的。所以你可以达不到它的容量，但不能跟它的结构有差异，这个我就不用多讲了，张处已经讲的非常清楚，而且中行在这方面在业界是做的比较好的，有常态化的测试环境，也有动态化的测试环境，这方面非常之好。这里我想讲另外一个层面，被测系统它所包含的这些东西，除了它配置以外，它所需要的测试数据，它所应用的部署，还有它监控的这套工具一定要完备，一定要完善，否则的话，你的数据来源就不全，就不准确。对测试环境来讲，我们整个测试工具的部署，案例库、脚本库、知识库这些运用也是非常重要的。所以我们对测试环境管理，一定要从被测系统和测试系统这两个方面，把它这几个要素都要考虑进去，这样我们测试的结果才有代表性。

人员和职责，我们有了人，但是如果不告诉这些人他该做什么事情，这帮人只是等着不知道该干什么。首先是一个项目经理，第二从业务层面和系统层面有这样的架构师帮他们做分析，最后我们有一个测试方面的专家，再配一组人作为测试工程师进行测试，还有技术支持人员，这是一个简化的模型。大家的职责和相互之间的关系非常紧密，非常逻辑化，比如任务来了以后，我的业务分析师能够提出他的测试需求，从业务角度应该测哪些东西。技术架构师从非功能特性方面提出技术方面的需求，应该测哪些东西，应该从哪个角度去考虑。项目经理根据这些测试需求，根据他对整个项目的理解和评估，制定一个总体的测试方案，测试方案交给经理以后，经理提出需求，进行这方面的场景设计，来设计一个可执行的方案计划，这样落实到项目团队具体来执行。功能方面常常有人问到，如果出了问题，谁说了算，专家说了算，谁是专家？业务分析师既然提出业务分析的测试需求，提供了业务测试场景，它一定对功能达到什么要求非常了解，所以就是他说了算。非功能性方面谁了算？一定是技术架构师说了算，形成封闭的循环，它的设计一定知道我要什么样的结果，结果出来以后，我来评判，没有太多可扯皮和打架的，扯皮打架的是职责分配的不合理。我画出这样一张图，虽然有些乱，但能说明一些问题。同一个人员可以在项目当中扮演多个角色，同一个角色也可以多人扮演。

刚才讲到了人员，方法，有很多的方法，我这里归纳为三个方面，组织方法、管理方法、实施方法。组织方法什么意思呢？就是我们通常说，我们用什么方式去组织生产，对于测试来讲，我可以把它这么去认为，它就是测试中心和测试职能部门的一种生产活动。测试中心的生产就是测试，这是一种现代社会职能化的划分，我认为是这样的。对于这种测试作为一种生产活动来讲，可以把测试按照订单式的方法来做，你的任务对我来说就是一个订单，我前期跟踪你这个订单有什么需求，有了这个订单，我可以了解你需要什么资源，需要什么样的质量交付东西，按照这种方式来组织，这个事物就比较清晰了。然后这个订单可以分解成很多不同的单元，像中行一个批次有几十个项目混在一起，一个批次是一个大的任务。为什么按照项目的形式来组织测试呢？我认为项目管理是迄今为止比较完善的一种管理方式，有很好的项目管理经验。如果以订单方式，我们可以充分利用集约型的资源计划概念，因为我们测试需要资源，资源有很多，有实效性，有成本方面的考虑，从粗犷型到集约型。

下面简单列举几个测试项目组织模型，项目决策委员会，这个名字叫什么不要紧，总之他是一个总裁判。这个项目是以项目经理为核心，项目经理一定是这个测试项目任务总的担当者，不管出现什么情况，项目经理职责非常明确，就是落实到人，他来组织，不管是通过矩阵式的方式还是什么方式，因地制宜，来进行组织。这个是一个测试项目的工作流流程，如果简单的讲，把它当做从这个项目前期分析、风险评估、资源需求评估，我们可以干这些事情，作为一个立项的话，后面紧跟着下来就是计划、设计、执行、总结。这里面我想强调的意思是说，各个层次的职能和职责非常分明，从执行层面应该怎么做工作，从测试中心要怎么工作，要做到所谓的工作流、信息流和数据流和谐的流动，项目管理就做好了。如果任何地方工作流流不动了，项目做不下去，信息流不畅通，要不到管理数据，没有用了，数据流走不下去，衔接不上，也没有什么用，一定这三个方面要和谐流动才行。当然现在已经不是手工操作的时代了，我们有现代的工具，有很多好的平台可以利用，通过系统平台，可以把我们整个管理数据库，测试的资产，测试的知识，这些统统能够把它按照逻辑、按照架构，把它管理起来。这样在以后所有的工作当中，都可以参照。针对前期提出的概念，按订单生产的资源计划方式，我的项目来了以后，究竟需要什么样的能力，究竟需要什么样的环境，究竟需要哪些资源，这些都要统筹来考虑。

方法之二就是管理方法，管理方法对整个项目管理有很多内容，我把它归纳成这几类，一是项目管理，第二是整个流程的管理，第三是资源管理，测试管理，还有就是很中的测试资产的管理，文档管理，刚才已经讲过了。项目管理不多说，核心的问题就是进度、质量还有成本，刚才已经讲过了。流程管理，我们做任何事情要有流程，我们怎么去定义符合我们实际情况的流程，我们怎么去把这个纸面上的流程能够付诸实施，怎么能够根据情况的变化对流程进行优化，这个是流程管理方面核心的内容。资源管理，人力、环境、技术，我们技术相当发达了，不管是系统方面的测试，还是什么方面的测试，都有相应的工具。测试管理不用多说，资产管理，资产是非常重要的环节，不管我们是专家知识的积累还是针对某些应用系统它的场景、案例和脚本的积累，这些都是测试过程当中所积累起来的，可以互用的资产，这些都是钱。如果没有这些东西，每一个项目来从头做一遍，有多少钱要投入做这个事情。文档管理这个不用多说了。

从管理这个角度，我也简单画了一个图，我把它叫测试管理信息流模型。从执行层面，每个阶段它要注意收集报告哪些信息，具体来讲，你的执行经理对底下这层，应该是每个阶段把握哪些信息，责任层面，项目经理你需要把握哪些信息。刚才讲到了，进度、质量、成本，还有项目计划，从决策方面需要哪些信息？总的资源统筹，总的项目任务管控，以及整个运行的绩效考核，这些从何而来？都是在整个过程当中，通过我们技术平台这种方式，能够在我们数据库里面，就能够提取，就能够查看，就能够分析。否则的话，如果我们说现在拿着一个QA质量体系，派一个质量检查员，一定行不通的，他会有一万个理由说，对不起，不就完了，我现在特别忙。知道这个信息流的模型，付诸于技术方法手段，这样不但没有什么阻力，而且能让整个运转变得更加顺畅。

刚才看比较虚的东西，我们来看从一个项目来讲有哪些实施的方法，我们总结为ATIS，高级测试实施方法。什么意思呢？就是我们结合业界的最佳实践，结合我们金融业务的特点，参照业界的标准、方法，形成我们测试规范库。规范就是用我们一些要求，一些约定，一些标准方法，有了这个以后，我们就知道怎么去划分测试阶段，怎么去定义我们的测试活动，怎么去定义我们的决策职责，怎么去规范我们的文档，怎么去实施我们技术的方法。上午IBM同志介绍灰盒，这些都是技术方法，有了这些以后，我们就可以把整个测试分解成一个清晰的路线图。就是每个人都知道他担任的角色是什么，他在什么时间什么点应该做什么事情，我们常常说一句话，要知道在用正确的人员，在正确的时间，用正确的方法，去做正确的事情。当然还要加上，把事情要做正确，试想我们这个管理方法那么复杂，但是你不能每个人都是专家，如果我们给他一个路线图，告诉你，你现在这个工作应该做什么，应该完成什么交付，你应该参照什么样的方式去做，按照什么标准来完成这个事情，那就很清晰了。每个人都知道怎么做的话，每个阶段就能做的很好，这就是我们定义了一个所谓高级测试实施方法，就是把每个步骤都把它定义成一个可遵循的路线图。

整个过程，一个项目下来，从前期的沟通和交流，根据交流的结果能够制定计划到培训测试人员团队，整个是一个简单的项目过程。我们通过这个过程，怎么去完善，怎么去监督，怎么去提升我们的质量，提出一个所谓的计划、执行、检查还有措施，PDCA，也是比较老的比较传统的方法，但是这个方法我认为到迄今为止还是行之有效的方法。高一个层面来讲，就是整个测试的过程改进，这里面有几个循环，测试标准、业务特点，工具方法库，形成一个规范库，根据这个规范库，制定测试的方案，付诸执行，对测试项目进行监控，反过来更新，这样一个循环往复的过程。年纪稍微大一点的知道，当年学过毛泽东主席的实践论，它是一种螺旋式上升这么一个过程。看起来它是在循环的，回到原点，但每一个循环它都达到新的高度，这样才有发展，才有进步。而且这种发展进步是有规律可寻的，整个过程感应体系它应该是遵从这么一个体系。有依据的标准和规范，有执行的方案，再去实施。

讲了那么多方法，回到技术层面，技术特别发达，有很多技术，但是对测试来讲，不外乎这三个方面，一个是测试技术，一个是应用技术还有系统技术。测试技术自不待言，方法、技巧、专业工具如何运用，如果我们要讲自动化，如果没有应用方面的技术进行分析是很难做到的。系统技术就更多了，测试环境运维，测试数据管理，从需求到萃取到漂白到部署到更新换代，非常完善的一套东西，还有性能监控分析。

技术支撑平台，有很多实实在在的东西，比如文思海辉在测试领域里面，整个过程不管订单方式，项目流程，我们用工作流来驱动这个路线图，这个测试路线图，我们用工作流的方式来驱动这个路线图，每个人只要一上系统，就知道今天干什么。不管测试整个质量，对功能测试、性能测试、测试数据、测试环境，这些方面都有相应的专业工具能够集成在一起，同时还能够集成我们业界主流的测试工具。不管是惠普的也好，还是IBM也好，形成一个完整的支撑平台。

我们再来看什么是测试体系？我的理解，融会贯通，融会测试遵从的为标准、规范和流程，贯通测试采用的策略、技术和方法，业务知识，（人员+方法+技术）×测试环境，过程质量标准，在项目过程当中，按照过程质量标准进行累计，进行提升。这个我认为就是一个基本表达，大家看还有什么缺的？规范，为什么把规范放在乘方的位置，有人员有方法，做对了，事半功倍，不按照规范，帮倒忙。有了这个以后，你就可以达到你的目标，就是你的项目交付，这就是我所理解的测试体系。

项目级的测试体系是一个基本的颗粒，在一个项目里面，我们能把整个项目实施体系流程，相关的标准规范以及文档这些组织搞清楚了，就很容易扩展到中心这一级的，横向拓展以项目群为特征的测试任务管理体系和实施体系，上升到中心级，以保障测试任务为目标的项目资源计划，专业团队建设和自动化测试平台。最后上升到企业级，我把这些做好以后，非常容易覆盖到前期一直到后期，覆盖到整个企业全生命周期。我这个想法跟有些客户沟通，大家有不同意见，这没有关系，有的从质量控制角度讲，他希望有一个从头到尾的质量体系先存在，这个也可以。但是实施起来是有难度的，我个人认为，以这种方法来实施，它是可控的，它是可以见到明显效果的，而且也是容易树立口碑和威信的，做起来困难是很小的。通过项目落地可以实现一举多得，包括体系的完善建立，包括测试任务最重要的任务完成，包括整个团队的建设。既然是浅谈，我把测试体系建设谈到这么一个地方。