功能自动化测试方案-V1.1

建设银行质量管理体系

中国建设银行

功能自动化测试实施方案建议书

（讨论稿）

中国建设银行信息技术管理部

2006年12月

目录

1前言 (3)

1.1文档目的 (3)

1.2名词术语 (3)

2功能自动化测试实施原则 (5)

2.1实施原则 (5)

2.2实施功能自动化测试的优缺点 (5)

3实施范围和目标 (7)

3.1实施范围 (7)

3.2实施目标 (7)

4技术方案实施内容 (8)

4.1使用QTP测试的阶段 (8)

4.1.1创建测试或组件 (8)

4.1.2运行测试或组件 (8)

4.1.3分析结果 (8)

4.2使用QTP测试的具体步骤 (9)

4.2.1测试分析准备 (9)

4.2.2录制测试脚本 (9)

4.2.3加强测试脚本 (9)

4.2.4调试脚本 (10)

4.2.5执行测试脚本 (10)

4.2.6分析测试结果 (10)

4.2.7汇报测试缺陷 (10)

4.3准入检查 (10)

4.4测试数据环境与脚本管理 (11)

4.5功能自动化测试复用规范 (11)

4.6功能自动化测试系统部署 (13)

4.7组织管理要求 (14)

5功能自动化测试方法比较 (16)

5.1录制回放技术 (16)

5.2脚本技术 (17)

5.3数据驱动技术 (18)

5.4各种自动测试技术比较 (20)

6实施管理建议 (21)

6.1实施策略建议 (21)

6.2人员组织结构 (21)

6.3实施计划 (22)

6.4交付物 (23)

1前言

1.1文档目的

功能自动化测试方案是为中国建设银行北京开发中心功能测试使用自动化工具，实现以自动化测试为主的目标而编写的技术和实施方案。

文档的主要目的是提供自动化测试的技术方案、实施内容、实施步骤，以及关键的技术实现手段等。本文的预期读者为建行测试中心相关人员。

1.2名词术语

?QTP：Mercury公司的功能自动测试工具，是一种企业级的用于检验应用程序是否

如期运行的功能性测试工具。通过自动捕获，检测，和重复用户交互的操作，QTP

能够辨认缺陷并且确保那些跨越多个应用程序和数据库的业务流程在初次发布就

能避免出现故障，并且保持长期可靠运行。

?MQC：Mercury公司的测试管理工具，用于在广泛的IT系统和应用环境下执行质

量保证。它包含一套基于角色的集成应用程序和最佳实践，以及开放式、可伸缩、

可扩展的基础架构。Quality Center设计用于对关键质量活动进行优化和自动化，

包括要求、测试和故障管理、功能测试以及业务流程测试。

?功能测试：功能测试又称正确性测试，它检查软件的功能是否符合规格说明。由于

正确性是软件最重要的质量因素，所以其测试也最重要。

?自动化测试：使用商业提供的自动化测试工具或者自己开发的工具对目标系统进行

测试。机器自动执行的测试，替代人完成重复性劳动，但不能完全取代人。自动化

测试需要用到测试工具，测试工程师的参与，自动化测试技术可应用于所有的测试

阶段

?业务组件：表示应用程序中单任务的步骤集合。业务组件（也称为组件）在Mercury

Quality Center 中由业务流程测试组合为特定的场景以建立业务流程测试。

?Action：在QTP中Action是一个可以被重复使用的最小单位，当建立一个全新的

测试脚本时，测试脚本中只有一个Action名为Action1，可以将整个测试脚本切

割成多个Actions，让测试脚本更为模块化且更容易被重复使用。

?CheckPoint检查点：用来验证脚本执行结果是否达到预期。可以在录制的过程中建

立检查点，也可以在录制完成之后再建立检查点。

?测试对象模型：是一大组对象类型或类，QTP用这些对象类型或类来表示应用程

序中的对象。每个测试对象类都有一个可以唯一标识属于该类的对象的属性列表，以及一组QTP 可以对其进行录制的方法。

?测试对象：是QTP 在测试或组件中创建的用于表示应用程序中的实际对象的对

象。QTP 存储有关该对象的信息，这些信息有助于它在运行会话期间标识和检查该对象。

?运行时对象：是网站或应用程序中的实际对象，在运行会话期间执行针对该对象的

方法。

2功能自动化测试实施原则

2.1实施原则

功能自动化测试过程中工具不可能完成所有的工作，工具仍然是测试过程中的辅助手段。对于工具主要是解决测试过程中的重复性的工作任务。另外实施自动化的测试，对被测系统也有更高的要求，总结功能自动化测试的实施原则如下：

1)使用自动化工具测试，要求被测系统开发比较稳定，较少发生功能的变更；

2)在自动化测试脚本录制前，被测系统的界面相对稳定；

3)功能测试自动化要求测试数据环境中的测试数据相对充裕，满足多次重复回归

测试的要求；

4)要求被测系统的版本运行比较稳定，较少发生测试中止的情况；

5)分期分步骤实施，优先选择产品功能比较稳定的系统进行；

6)完善的、可复用的数据参数、脚本库是一个长期的积累过程。

2.2实施功能自动化测试的优缺点

功能的自动化测试与手工测试虽然有很多局限，但是同样有其优势，随着自动化测试技术和工具的发展，对于比较稳定的产品的功能测试中，自动化测试占有越来越重要的地位。使用QTP可以加快整个测试的过程，在产品的版本发布之后，可以重复使用测试脚本进行测试，具体来说：

自动化测试的优点：

?提高测试效率，降低测试成本；

?重复性强的手工劳动独立用自动化实现；

?快速的回归测试，提高新版本发布的速度和质量；

?避免人工测试容易犯的错误，如：错误测试，漏测试，多测试等；

?很容易就实现并发性测试；

?测试可重用，采用脚本和数据可以很容易实现重用。

自动化测试的缺点：

?规范的测试管理，测试需求，测试用例；

?不能创造性发现测试脚本没有设计的缺陷；

?高质量的测试用例；

?高素质的自动化测试工程师；

?对测试环境要求比较严格；

?测试需求变化可能引起大量的测试用例，自动测试脚本的修改、维护。

3实施范围和目标

3.1实施范围

1)工具范围：目前考虑QTP、MQC、TAR、配置管理工具、Excel等工具的使用和集

成；持续集成工具暂时先不考虑；

2)系统范围：定位在建行测试中心基础测试环境中的交易类系统；

3)测试阶段的范围：局限在SIT后期、以及上线后的功能回归测试，目前暂不包括LT、

内部测试中的功能测试部分。

3.2实施目标

1.功能自动化测试系统应该能完成SIT、以及上线后功能的回归测试；

2.方案目标对有界面和无界面的交易测试都能完成，有界面的交易支持如下方式：

a)支持字符终端界面；

b)支持B/S的Web界面；

c)支持C/S的Windows应用程序界面；

3.功能自动化测试方案对目前建行存在的大部分应用系统都可以进行测试；

4.实现自动化脚本录制、自动化脚本执行、自动化缺陷报告和管理。

3.3总体实施策略

1.首先从目前建行的系统中选择适合自动化测试的项目和系统；

2.其次确定实施功能自动化测试的阶段和时机；

3.第三从适合的项目中选择适合自动化测试实施的功能和交易。

具体实施策略参见第6节的实施管理建议。

4技术方案实施内容

4.1使用QTP测试的阶段

使用QTP 测试包括三个主要阶段：

4.1.1创建测试或组件

创建阶段可以通过在应用程序或网站上录制会话，或者建立对象库并使用关键字驱动功能向关键字视图中手动添加步骤来创建测试或组件。然后，可以使用特殊的测试选项和/或编程语句来修改这些测试或组件。

4.1.2运行测试或组件

创建测试或组件后，测试工程师可以运行这些测试或组件。

?运行测试或组件检查被测系统。

?运行测试或者组件对录制和编写的脚本进行调试。

4.1.3分析结果

运行测试或组件之后，就可以查看测试执行的结果。

?在“结果”窗口中查看结果。

?报告在运行会话过程中检测到的缺陷。

4.2使用QTP测试的具体步骤

4.2.1测试分析准备

在测试前需要先确认被测应用程序是否符合自动化测试的需要，是否满足自动化测试工具的要求。

确认测试的范围和测试目标，比如要测试哪些功能、以及测试的时机等。

在准备阶段要根据被测系统的业务需要分析被测系统的功能，整理出测试需求和测试数据需求。熟悉被测系统为后期指定测试集做准备。

配置QTP工具的设置，为脚本录制做准备。

4.2.2录制测试脚本

启动QTP工具的录制功能，手工操作被测系统的应用程序，QTP将自动录制人工的操作过程，并将操作的步骤显示在QTP工具中。对于工具不能录制或者不能识别的界面对象需要手工识别和添加。

4.2.3加强测试脚本

在测试脚本中加入检查点，检查点可以是标准检查点、对象检查点、文本检查点、数据库检查点等，以验证应用程序的功能是否正确；

将录制的脚本中的固定值（Hard Code）以参数取代，使得测试脚本跟测试数据结合；

使用逻辑或者条件判断，增加脚本的逻辑以实现对复杂的功能的测试。

4.2.4调试脚本

对修改增强完成的脚本进行调试，修改脚本中的逻辑错误，确保测试脚本能够正常顺利执行。

对于由于被测系统的功能需求发生变化后，测试脚本需要维护和修改，然后重新进行调试，以保证测试脚本的有效性。

4.2.5执行测试脚本

调试完成的测试脚本，将在被测系统的版本上执行测试，检查被测系统的功能是否满足需求。执行脚本一般将脚本导入MQC中管理和定义测试案例执行集，由MQC来调度执行测试脚本。

4.2.6分析测试结果

分析测试执行的结果，找出问题所在。如果是刚开始实施自动化测试，分析结果还可以帮助分析和定位测试脚本的正确性。以便提高测试脚本的可靠性。

4.2.7汇报测试缺陷

通常QTP工具与MQC工具结合使用，这样QTP发现的缺陷可以自动提交到MQC中对缺陷进行管理和跟踪。

4.3准入检查

准入检查机制是测试管理中的重要的环节，同时对于实现自动化测试方案中，更是一个重要的机制。准入检查对被测系统的版本、系统功能开发的稳定性等都能够有效验证，保证了自动化测试的顺利执行，同时也减少了自动化测试脚本的维护工作量。

准入检查的内容和方式：

?被测版本静态检查：通过静态检查被测版本的《版本发布单》、版本的文件、版本

的部署安装是否正确。

?被测系统版本验证：通过MQC运行覆盖主要业务功能的脚本案例执行的成功率判

断被测系统能否进入自动化测试。

4.4测试数据环境与脚本管理

QTP可以将测试数据参数化，数据参数与测试脚本相对应，在测试脚本中可以调用这些数据参数，实现同一个脚本可以针对不同的数据执行多遍。可以根据参数的设置实现测试业务流程的多个分支。

测试数据的参数化有四种基本方法：

1)使用QTP的DataTable，直接在QTP中将测试数据录入参数表中；

2)使用QTP的正则表达式，根据测试数据的需求，使用正则表达式可以简化

DataTable中的重复、序列以及匹配数据；

3)使用外部文件：通过Excel导入QTP中，或者脚本直接访问外部文件的方式得

到数据，可以方便实现脚本之间的数据共享；

4)使用外部关系数据库，QTP脚本可以直接访问其他的数据库，从数据库中取测

试数据。

测试数据与脚本的关系：

?把自动测试脚本运行所用到的数据以参数取代，脚本运行时从参数表取数据；

?将数据与脚本分离，便于对数据和脚本的维护管理，便于更新数据以适应新的测试；

?QTP脚本中的取值参数化，增强脚本的复用程度；

?环境变量参数化，测试、操作参数的值，应用程序随机值。

测试脚本参数化的实现步骤：

1)定义数据表参数；

2)在数据表中建立数据参数值；

3)修改受参数化影响的测试步骤的脚本；

4)运行脚本，调试建立的参数和修改的脚本。

4.5功能自动化测试复用规范

使用自动化测试工具进行系统功能的自动化测试的一个重要的目的之一就是减少成本，提高效率。因此对测试过程中的成果的复用就是一个重要的需要考虑的内容，幸运的是，目前的很多自动化测试工具都提供了类似复用的功能。针对QTP来说，工具本身提供了对脚本Action的复用、检查点的复用、参数数据的复用以及脚本模板的定制功能。

?Action的复用：

对于需要重复执行的步骤、一些常用的操作，以及一些通用性的操作，比如登录、退出等。一般都录制为单独的Action，存为单独的脚本文件。在需要的地方调用该Action。或者对于已经录制好的脚本，可以使用脚本分拆功能将复用的脚本分拆出来。

Action的复用是先录制用于复用的Action脚本，然后对该脚本设置为Reuseable Action，这样该Action可以为其他脚本调用。

QTP对Action的调用方式为：复制Action和调用已有的Action两种方式，可以根据实际情况选择。

脚本的复用可以减少脚本库中脚本的数量，增强案例库的可维护性。

?参数数据的复用：

QTP的参数化主要有两种方式，一是Global：控制整个Action的运行次数；另一种是Current Action的方式，对于一个脚本中有多个Action的情况下，用于控制单一的Action的循环次数。

对于参数数据是执行自动化测试的前提，参数数据一般是可以在不同的系统版本的测试或者回归测试中复用率比较高。

?检查点的复用：

每个脚本都需要设定检查点，但有些脚本的检查点可能相同，这时重复设定检查点就会使工作没有实际意义，这时可以设立可重用检查点来解决这个问题。具体设置步骤为：

1)录制脚本，不设立检查点；

2)录制可重用检查点，将QTP 录制和运行设置设为录制当前页，开始录制，不

录制步骤，直接在录制过程中添加检查点，将这个只有检查点的Action设为可

重用Action（Reusable Action）；

3)调用可重用检查点，在第一步录制好的脚本中调用这个可重用检查点，首先选

中需要添加检查点的步骤，然后选择调用已有的Action。

?Action模板定制：

对于需要在每个Action脚本中包含的信息，比如脚本文件的头注释信息等，可以应用Action模板的方式来规范脚本开发的规范化，也为脚本维护和修改提供了方便。具体操作步骤为：

1)新建一个文本，输入一些新建Action时经常包含的信息，然后保存为

ActionTemplate.MST文件；

2)复制该文件到QTP/dat目录下。这样每次新建action都会包含固定的信息。

4.6环境部署

功能自动化测试环境包括：自动化工具、缺陷管理工具、测试案例管理工具、持续集成工具的协同环境。在该方案中建议的自动化测试工具及其主要功能有：

4.7组织管理要求

在自动化测试实施过程中，需要相关的角色和人员，不同的角色负责相应的职责，具体需要的人员角色如下：

?测试经理：

制定测试计划；

协调各个小组工作、协调行方资源；

跟踪测试进度；

协商解决测试中的遇到的问题。

?业务测试工程师：

为自动化测试提供业务指导，数据准备。

?测试分析工程师：

搭建测试环境，数据准备；

定义脚本的框架，调试脚本框架；

分析测试结果，优化测试脚本，配合系统优化。

?测试脚本开发工程师：

根据框架生成测试脚本，数据参数化，添加检查点，执行测试，记录测试结果。

开发人员：

系统优化，测试过程中问题定位。

5功能自动化测试方法比较

自动化测试技术的发展经历了简单的录制回放、脚本测试和数据测试的阶段，同时也代表了自动化测试技术方法。下面对比这三种自动化测试的技术方法，比较其优缺点。

5.1录制回放技术

建行测试过程分为测试计划、测试需求分析、测试设计和案例编写、测试执行、测试分析等几个阶段，测试执行和测试问题报告是属于机械的、多次重复的活动，大概要占测试总工作量的80％左右，最适合被自动化，也是首先应该被自动化的。测试案例编写活动也有部分工作可以被自动化，如自动产生脚本框架等。测试执行活动又分为输入数据、执行测试、验证测试数据三个部分，其中工作量最大、实现起来最容易的就是输入数据和执行测试过程的自动化，最初采取的方法就是由计算机记录手工操作的过程和数据，再次执行测试时，根据上次记录内容回放即可，就不需要手工输入了，这就是录制/回放技术，后来，为了实现验证测试数据的自动化，在录制过程后，进行了增强工作，可在脚本中加入同步、检查点，并对部分数据进行参数化，实现初步的数据驱动。

使用这种技术，其优点如下：

1.使用简单，不需要深入的工作或计划，可很快启动手工录制工作，可以快速开

始自动化，在短时间开发出大量简单的测试，启动成本低

2.使用者不需要了解编程技术（假设不需要修改脚本）

3.对实际执行的操作可以跟踪审计

但是，绝大部分采用这种技术进行自动化回归测试的组织都失败了，失败的一个共性的原因是因为这种技术虽然初期启动成本低，但是随着测试过程的进行，后期维护成本非常高，使得不可能使用这种技术构建长期的自动测试系统，具体来说，这种技术存在以下问题：

1.产生自动测试的过程繁琐，效率低：产生可行的自动测试的时间比手工测试长

2～10倍

2.一切依赖于录制过程中捕获的内容，故只能测试已经能够正常执行的功能

3.存在录制噪声，产生的脚本是非结构化的，维护工作量巨大

4.脚本、数据和验证条件是捆绑在一起的，任何一个修改，就必须重新录制或者

修改脚本

5.易受软件改变的影响，软件改变后必须重新录制脚本和验证条件

6.如果回放时发生了录制脚本时没有发生的事情，将引起整个测试失败

正因为以上原因，录制－增强－回放技术只使用于少量特殊情况，如培训演示、只使用一次的测试脚本，界面和操作不变的测试等，对于长期、大量的自动回归测试来说，这种方法是不可行的。

5.2脚本技术

既然录制回放技术维护工作量巨大，无法使用这种技术构建长期的、大量测试的测试系统，那么如何改进自动回归测试系统的可维护性呢？人们发现，自动回归测试系统本身也是一个软件系统，其基本工作元素就是测试脚本，测试脚本也是一种软件程序代码，也存在各种程序错误，改进自动回归测试系统的可维护性，就是要改善自动测试脚本的可维护性，既然自动回归测试脚本是软件程序，那么就可以使用软件开发的技术来改进自动回归测试脚本的可维护性，这就是结构化的编程方法（当时还没有出现面向对象的技术）。

这种结构化的脚本技术又叫功能分解技术，是一种基于任务的技术，其工作原理是根据被测系统需要完成的任务和功能，对这些功能和任务进行分解，采用结构化编程技术完成实现这些功能的脚本，不同测试中执行重复的任务时，使用同一个脚本，当重复任务发生改变时，也只需要修改一个脚本，对该脚本来说，数据与脚本是分离的，可以把数据作为脚本的参数，也可以把需要的输入数据和验证数据放到指定的文件中，由脚本读取。

这种技术的特点是发展了“结构良好的、有文档的、健壮的、可维护的”测试能力，测试项目成为工程项目，其关键特征是部分测试脚本已经开始具有可复用性。另外，由于测试脚

本包括错误捕获和恢复逻辑，比录制回放技术具有更高的可靠性，可以预知可能发生的错误和意外事件，通过编程进行处理，使自动回归测试能顺利进行。

总结起来，这种技术优缺点如下：

优点：

1.可维护性较强

?采用模块化设计，如果业务功能改变，只需要改变1、2个脚本，维护开销低

于录制回放技术

?复杂的测试用例可以通过在一个主脚本中调用业务功能脚本实现

?对于需要重复执行的测试任务，只需要使用一个脚本，删除了明显的重复，通

过把不同的输入/验证数据作为参数，或者放到文件中，使数据与脚本分开，脚

本可以被不同用例使用

2.可靠性

?不存在录制噪声，脚本经过测试后，可靠性比较高

?意外事件（如弹出菜单、对话框等）可以预先考虑并通过编程解决

这种技术虽然维护成本比录制回放技术低，但是还存在一些问题，主要缺点如下：

?每个功能都需要一个特定的测试脚本，而且大量脚本需要手工编写

?重复使用的脚本（共享脚本）通常只占被测软件很小的一部分

?脚本数量增多，增加了更多的文档，管理难度加大

5.3数据驱动技术

使用脚本技术后，还存在一些的问题，其一，由于脚本技术是一种基于任务的技术，与应用系统的功能是紧密相关的，通常不同的应用系统之间的差异比较大，如一个银行的应用系统和一个税务的应用系统，他们之间可复用的脚本很少。二是由于采用这种技术，大量脚本还是与数据捆绑在一起的，如果数据发生变化，也需要具有编程经验的人员修改脚本，并调试脚本，成本比较高。

如何解决这些问题呢？很显然，需要进一步提高共享脚本的数量。通过进一步思考，人们发现任何自动测试的终极目标都是自动完成一套与测试需求相对应的有计划的测试，可以由测试计划驱动测试过程，测试工作的中心是测试数据，而不是测试脚本，测试脚本只是为了传递测试数据，应把测试脚本和测试数据分开，由测试数据来驱动自动回归测试过程，这就是所谓的数据驱动测试或关键字驱动测试，也叫基于动作（Action）的测试或Action Word

方法，与前面说到的数据驱动不同，这里说的数据驱动测试不只是简单把外部数据输入到AUT（Application Under Test，被测系统）中，数据驱动测试是一种数据被包含在输入数据文件中，并且数据控制自动化测试脚本执行的流程和动作的测试，只有这样，才能实现在不同应用间的复用。

这种测试方法要求我们分开测试数据和测试脚本，测试脚本是可以复用的，因此也要求测试脚本是参数化的。具体来说，采用这种技术就是在测试数据中指定测试执行的步骤，以及每个步骤执行时操作的对象、动作和数据，测试脚本的作用就是读入数据，并根据数据的要求执行相应的动作，而面向对象技术的出现，也促进了该技术的发展。

另外，由于自动测试脚本本身也是一种软件，也存在逻辑错误和其他各种缺陷，也需要维护，因此，在自动回归测试过程中，除了要维护被测系统相关的代码、数据、文档外，还需要维护自动测试系统本身的脚本、数据和文档，维护成本非常高，因此可以说，创建结构化的、基于组件的测试脚本并使测试脚本与其执行的数据相分离是自动化测试成功的唯一途径。

这种技术有多种实现方法，通常都会需要一个框架或引擎，用它来解析输入数据中的动作指令，执行指令要求的动作，而此框架和引擎的好坏，会直接影响自动回归测试系统能否成功。

这种方法优缺点分析如下：

优点：

1.可维护性

?使用输入文件的数据控制自动化测试的执行流程和动作

?在特定框架下，可以非常容易地产生“健壮的”脚本，甚至自动产生

?数据与脚本分开，数据维护非常简便，输入数据文件格式简单，维护方便，调

整数据不需要修改脚本

?可以借助占位符（变量）允许动态数据输入

2.可靠性

?不存在录制噪声，基于框架的脚本开发更容易，更健壮

?意外事件（如弹出菜单、对话框等）可以预先考虑并通过编程解决

3.可复用性：不是为一个应用开发脚本，脚本是封装的，可以在不同应用间复用

4.降低人员要求：只需要一个工具专家，业务人员不需要了解测试工具

缺点：