功能测试成功案例（民生银行自动化测试）
一、项目背景
国内的银行系统的核心业务（Corebanking）作为银行的基本业务支撑软件，具有以下几个特点：
功能复杂
复杂的corebanking有多达两三千个功能，并且允许多个功能之间进行组合，实现更复杂的功能。
频繁的系统升级与更新
由于WTO要求，金融行业的开发速度很快，各个银行都在从经营国内的传统银行业务（存款、贷款、票据等），向更多的业务品种、产品化经营模式、混业经营等方向飞速发展。在这个前提下，就要求银行的核心业务系统不断的改造和增加功能，以满足告诉发展的业务需求。
对功能可靠性的要求非常高
银行软件的最大特点是高可靠性，不循序出现错误和保持系统运行的稳定性。
相对应，会导致对系统测试提出了更高的要求：
高覆盖率的测试用例
银行核心业务系统的功能复杂，更要求具有非常全面的测试用例，能够覆盖整个核心业务系统的功能。
测试用例的高复用性
核心业务软件具有很长的生命周期，随着软件版本号的增加，功能不断的增强，就需要对应版本的测试用例来对不同的版本进行测试。
软件功能的提升是建立在上一个版本基础上的，因此测试用例也是建立在上一个版本的测试用例基础上的。因此，对测试用例进行复用，可以有效地降低测试成本。
软件版本发布过程中，会有大的版本发布和小版本发布，也就对应了需要进行不同规模的测试。每次测试，如果都重新设计测试用例，会带来巨大的成本开销；因此通过测试用例的高复用性，可以在测试的时候只需要重构发生变化的测试用例，就可以方便的实现回归测试。
大量的回归测试
核心业务软件具有很长的生命周期，随着软件版本号的增加，每次发布版本都需要对原有的功能进行回归测试。
按照软件工程的统计学规律，每修改3个缺陷会引入一个新的缺陷，这就是说，当我们修改或者增加功能的时候，会导致新的缺陷产生。
需要通过对每个发布版本的测试来发现引入的缺陷。这种测试对于安全生产具有重要的意义。
通过回归测试，可以很好的发现新引入的缺陷。
测试质量控制点和质量标准
传统的功能测试，基本上由测试人员自己来设计测试用例、执行测试用例、汇报测试结果。在整个测试过程中，缺乏有效的质量控制点和质量标准：
1）没有某个阶段点进行Review和评审；
2）缺乏测试需求、测试用例的质量标准。测试的质量得不到保证。
二、测试解决方案
a) 测试平台 测试需要软件进行支撑，我们把这个软件称为测试平台
测试平台包括：
测试工具：用来录制和执行测试脚本；
测试框架：管理测试需求、测试用例设计、业务组件管理、测试计划管理、测试执行的框架；
测试报表：查看测试结果、统计分析测试需求覆盖率、业务组件分支覆盖率；
缺陷管理：对缺陷进行跟踪和处理；
测试管理平台：管理测试数据、管理辅助信息、协同工作；
配置管理：对测试需求、测试用例、业务组件进行配置管理； 本项目使用AutoRunner作为工具；TestCenter作为测试框架、测试管理平台、测试报表和缺陷管理。
b) 测试用例开发流程
把测试用例的开发过程划分为三个阶段：需求、设计、实现。
需求阶段：
根据核心业务系统的需求来编写测试需求的标准，创建测试需求。使用TestCenter的需求部分来完成测试需求的编写和管理。
测试需求在TestCenter中表现为;需求树;，各个节点作为具体的需求。
需求具有很多的状态和属性信息，包括：
1）名称；
2）测试主题；
3）类型；
4）详细信息描述；
5）附件；
对应的测试用例；
设计阶段：
根据测试需求来设计测试用例。使用TestCenter的测试用例管理部分来创建测试用例；
然后再使用TestCenter，把测试需求和测试用例关联。
在后面需要进行一次测试的时候，就可以根据由测试需求的范围来确定需要的测试用例集了。执行测试用例集，就可以进行对一定范围内的测试需求进行测试。
TestCenter的测试用例具有很多属性和配置：
1）名称；唯一表示此测试用例的名字；
2）包含的业务组件和测试数据；根据TestCenter实现的业务组件，用户可以通过配置的方式来给测试用例增加业务组件，下图为测试用例中包含的业务组件：
在给测试用例设定业务组件完成之后，还需要给每个业务组件设定当它被执行的时候的数值，也就是测试数据。TestCenter支持用户给每个业务组件来设置测试数据：
当测试用例被执行的时候，就会使用测试用例的数据来执行。业务组件被添加到测试用例中的时候，使用业务组件本身的缺省数据。
3） 测试用例所包含的各个业务组件之间的依赖关系； 在TestCenter中，可以通过属性的方式来设定一个业务组件执行的时候所需要依赖的其他测试用例。 当设定一个业务组件依赖于另外一个业务组件的时候，在执行的时候TestCenter会决定哪些业务组件首先被执行，那些在后面执行，就不再需要测试工程师再指定执行的次序。
4） 输入参数列表； TestCenter支持管理每个测试用例的参数表。每个参数都包括：1）参数名；2）参数赋值信息。 TestCenter的输入参数如果定义了赋值信息，在测试用例执行的时候，会自动从测试数据场景中获取这个动态的参数信息。 这个参数信息可以来自于测试计划的数据场景文件，也可以是前面的某个测试用例的输出参数数据。如果使用前面的测试用例的输出参数作为输入参数，那么就可以动态的修改输入参数，对数据场景的依赖可以大大降低，减少了进行一次测试的准备工作。
5） 输出参数列表； 输出参数列表用来把测试用例过程中创建的数据输出出来。 输出的数据一般情况下再作为输入参数传递到其他的测试用例中。 例如：测试用例A作为对私开户的一个测试用例，它的输出参数列表中包括用例中开出的账户；测试用例B作为对私存如的一个测试用例，输入参数中包括一个账户作为输入参数，用来支取。 可以看出，上面的例子中测试用例是不依赖场景：已经开出的帐户。
6）数值传递，包括从参数传递到各个业务组件中的数据、业务组件之间的数值传递。 TestCenter支持在一个测试用例内部，输入/输出参数、业务组件之间传递数据；TestCenter支持在一个测试集中，测试用例之间传递数据。 所有的参数传递都是采用配置的方式来实现，不采用编程的方式。
实现阶段： 根据测试用例所需的业务组件要求，来创建业务组件。创建业务组件的过程主要是通过测试工具录制和编写测试脚本来完成。
TestCenter的业务组件，包括：
1）测试脚本和对象库/资源；
2）参数数据表。参数数据表，实际上是这个业务组件的数据格式信息。 在整个测试体系中，业务组件是通过测试工具来创建的（也可以手工创建）。
c) 测试执行流程
根据测试要求确定测试需求的范围； TestCenter支持测试计划，在创建测试计划的时候，首先需要确定测试范围。
据测试范围创建测试用例集合； TestCenter允许用户从某个测试需求的节点来创建测试集。TestCenter提供了测试集创建向导，通过对与测试需求对应的测试用例进行筛选（主要是通过测试主题），就获得覆盖此测试需求的测试用例集合。
设定测试用例的数据场景； TestCenter根据所定义的测试集合，把其中所有测试用例的输入参数合并，就成为此测试集合的数据场景。 TestCenter支持导出一个测试集合场景文件，在这个文件中，用户可以看到各个参数试用的缺省值。 编辑此测试场景文件，并且把此文件倒入测试集合，就可以实现一个测试计划可以执行在不同的数据场景下执行。 TestCenter支持灵活的数据场景管理，可以避免用户需要编写的大量的用来维护测试数据场景的小程序和维护大量的数据。 数据场景是建立在测试计划和测试场景之间的一个标准接口。
执行测试用例； TestCenter支持可伸缩的执行模式： 第一， 在用户定义业务流的时候，除了需要定义一些特殊的依赖关系（先决条件依赖），其他的先后顺序关系是不需要定义的； 第二， 用户不需要预先定义、也不需要预先知道有多少设备可以参与测试；而是在执行测试的时候，自动;发现设备;，并且动态给设备分配需要执行的脚本和数据； 第三， 在测试过程中，如果有新的测试设备加入，TestCenter会动态把它们加入到资源中来，给他们分配需要执行的脚本和数据； TestCenter的错误处理： 第一， TestCenter和测试工具连接的模块，叫做TestAgent； 第二， TestAgent可以同时连接多个不同的测试工具，但是每个测试工具只能够连接一个； 第三， 用户可以编辑TestAgent的配置文件来增加新的测试工具支持； 第四， TestAgent支持一个错误处理脚本：当出现同步错误的时候，会被自动来执行，这个脚本用户可以自己编写，完成重新初始化Workline（运行资源），保证失败之后的测试资源可以被回收和重新使用；
评估测试结果； TestCenter提供了Web的界面来显示测试日志、统计分析、测试报告。 测试日志包括各个测试用例执行信息，以及相关的屏幕截取图； 统计分析包括：
1）测试用例比例分析；
2）测试需求覆盖分析；
3）业务组件覆盖分析，三个部分。
测试报告：支持标准的测试报告文件生成，可以生成一个pdf格式的测试报告。
d) 质量标准 核心的质量标准： 测试需求标准； 测试用例标准；
e) 测试活动 测试活动包括：
导入测试需求；
创建测试需求；
创建测试主题；
创建测试用例；
创建业务组件；
创建测试集；
编写测试计划；
创建测试计划的数据场景；
维护测试计划的数据场景；
执行测试；
评估测试和编写测试报告；
三、实施过程
本项目初始情况在项目没有开始以前，银行核心业务系统采用手工测试方法进行测试，没有明确的测试用例、测试需求、测试脚本。只有一定的测试人员进行手工测试，工作量大，测试效果不明显，缺乏测试质量管理。
实施过程 由于需求范围太大，一次创建所有的测试需求和测试用例是不现实的，也不能很快的看到效果，因此我们采用了分子系统实施的方式：
第一阶段：对核心业务系统的清算子系统进行测试，包括：
a) 完成测试需求；
b) 根据完成的清算模块的测试需求，完成测试用例设计与实现；
c) 执行测试，评估测试的结果。
第二阶段：逐步增加其他子系统的测试需求和测试用例。
四、项目后期情况
a) 情况 使用情况： 经过一年的项目实施，已经建立了完整的测试需求和测试用例； 建立了日常运行的测试计划； 可以通过测试计划来执行自动测试。一般都把测试安排在夜间完成，提高了测试效率。 每次测试都自动生成测试报告，作为测试完成的分析报告。 投入人员情况： 投入测试人员6名，已经完全使用自动化测试来实现测试工作。
b) 分析
五、总结
a) TestCenter提供了强大的测试框架，包括面向Business Process Testing模型和数据管理模型、运行模型、角色管理模型，基本上取消了原来自动化测试需要自己来开发测试框架的工作。而良好的框架模型，能够方便的支持自动化测试，提高了测试用例设计和实现生产率，也保证了自动化测试项目的成功。
b) 高度的测试自动化。 传统的方法，总是认为自动化测试的比例难以很高，实际上这个理解是错误的。分析无法获得高度自动化的原因，主要在于：
第一，用户需要开发测试框架，难度过高，而且由于本身对自动化测试的理解不足，导致了框架缺陷太多，容易失败；
第二，管理测试数据的开销过大；
第三，设计测试用例依赖编码来完成，造成了测试用例的可维护性比较差，从而导致自动化测试的维护难度很高；
第四，测试用例的规范化。
不规范的测试用例阻碍了测试自动化的实现，特别是测试用例的验证规则，在不使用自动化测试的项目中，验证方法是比较混乱的，导致无法通过自动执行来完成。
TestCenter提供了强大的测试业务模型，通过高度组件化、可配置，解决了这几个问题：
第一，测试框架已经被包括在TestCenter中，用户已经不需要开发复杂的测试框架，把精力都投入到测试本身。在本案例中非常明显，没有人去关心测试用例组织和管理、数据场景管理等复杂的问题TestCenter已经解决了这些问题；
第二，测试数据管理成为TestCenter的基本功能，用户不需要管理此繁琐的内容；
第三，测试用例采用配置的方法来实现，并且提供了各种丰富的功能，从而导致维护测试用例的成本非常小；
第四，测试用例被高度规范、标准化，使得测试工程师及时不够理解测试活动，也能够编写规范的测试用例，从另外一个方面降低了人员成本，降低了知识传递成本。
c) 测试执行分配。 TestCenter支持灵活的可伸缩的执行模式，在执行时刻自动分配测试脚本执行，从而使得一次执行成千的测试用例成为可能。 在一个测试集合规划图中去设计几千个测试用例依赖关系图，这是不可想象和难以完成的工作。TestCenter通过表的方式来简化这种方式，并且允许用户定义简单的依赖关系来处理特殊情况，对于一般的没有顺序关系的测试用例，基本上不需要考虑，这种方式便于创建的测试计划可以执行在不同的测试环境之下。 TestCenter通过支持测试集合的嵌套：一个测试集合可以包含另外一个测试集合，并且设定测试集合内部的依赖关系。这种方式提供了一个多层次的解决方案，用来解决大规模系统测试中，各个子系统之间的依赖关系问题。
d) 测试过程分解和质量控制点。 TestCenter支持各个对象之间的依赖关系，可以自动依赖。 TestCenter的各个对象可以作为质量控制点的评审对象，便于进行测试活动中的质量控制。