模板
教程
环境
性能
功能
管理
基于 IBM Rational Robot 的自动化功能测试框架
本文介绍了构建在 IBM Rational Robot 基础之上的自动化功能测试框架，来帮助组织更好的进行自动化的功能测试。
1. 前言
测试本身就是一项异常艰苦的工作，而成功的进行自动化的功能测试，对很多软件开发组织来讲，更是困难重重。本文介绍了构建在IBM Rational Robot基础之上的自动化功能测试框架，来帮助组织更好的进行自动化的功能测试。
随着业务的变化，软件产品的种类越来越多，软件产品的升级越来越快，在很多的软件开发组织中，测试部门承受着巨大的压力，他们一方面要测试越来越多的软件产品，一方面要应对越来越短的测试时间，同时，还要面对捉襟见肘的测试资源。
每个版本发布都包括新增加的功能和已有的功能，已有的功能已经在以前的版本中进行过测试，但是还需要在此版本中执行回归测试。在这种情况下，测试部门往往会考虑到，既然回归测试的测试用例都已经存在并且已经在上一个版本中执行过，那么在新版本中能否自动的执行这些测试？如果能这样的话，将极大的节省时间和资源，将有限的资源投入到新功能的测试上，缓解测试的压力。
通常情况下，软件开发组织会使用自动化测试工具，使用录制回放方式来进行功能测试的自动化。但是录制回放方式并不能解决全部问题。
2.2 录制回放中存在的问题
业界的经验表明，虽然录制回放方式能够快速的生成测试，但是仅仅单纯的使用录制回放是不够的。
首先，也是最主要的原因，就是使用录制回放方式，往往需要耗费时间和资源来调试、维护脚本。这些工作量随着脚本数量的增加，可能会增大到几乎不可能再对脚本进行有效维护的地步；其次，使用录制回放方式，要求应用已经开发完成并且在录制中不出现错误，但是往往当应用达到此条件时已经没有足够的时间进行测试；最后，使用录制回放方式，要求每个测试人员均会使用测试脚本语言“编程”，而当前大多数软件开发组织测试人员专注于业务，往往没有兴趣和精力来“编程”。
所以，录制回放方式并不能解决所有的问题，在自动化的功能测试上，需要有测试框架的支持。
3.1 概述
IBM Rational Robot是一款优秀的自动化测试工具，自动化功能测试框架是基于Robot之上构建的。如下图：
图 1. 基于Robot的自动化功能测试框架
业务测试人员类似于当前软件开发组织中使用手工执行测试的测试人员。可以看到，在解决方案中，除传统的业务测试人员外，增加了技术测试人员角色。技术测试人员偏重于自动化测试相关技术，实际上并不直接执行测试。
解决方案的核心是使用Robot的SQABasic脚本开发的Robot测试技术框架。此Robot测试技术框架以表驱动为指导思想，读入动态结构，解释并执行动态结构中的每一项，是自动化测试的引擎。同时，为了提高Robot测试技术框架的易用性，在解决方案中还包括测试设计工具，它是使用其它编程语言，比如JAVA、Dephi等开发的应用程序。在测试设计工具中，测试技术人员首先建立和待测试应用一一对应的静态结构，此静态结构以页面为单位，随后业务测试人员从静态结构中选择不同的页面，组成测试动态结构，即测试用例，随后，此动态结构被Robot测试技术框架读入并解释执行。
3.2 Robot测试技术框架
3.2.1 表驱动介绍
Robot测试技术框架是基于表驱动测试思想。表驱动测试就是预先在表中定义清楚代表每一步执行操作的关键字，然后由脚本读入表中的每一行，根据关键字来执行对应的动作。以CQ Web登录界面为例：
图 2. ClearQuest Web登录界面
当要自动执行“登录”按钮时，可以如下图来定义此表：
登录
然后在Robot的脚本中，打开表，读入此行并执行。这样的话，Robot便去点击界面上的“登录”按钮了。
| clearcase/" target="_blank" >cccccc>
'打开文件 =============================== ‘解释并执行 |
以上是表驱动的简单示例。在自动化测试中，基于表驱动，还需要解决以下问题：对象识别、验证点、数据池、分支执行、数据关联、日志记录、调用其它脚本、脚本结束。本节将分别展示其在Robot测试技术框架中的实现方式。
3.2.2 对象识别
根据IBM Rational Robot识别对象并执行操作的要求，如果要让Robot找到界面上的对象并执行相关动作，需要给Robot指定每个对象的对象类型、对象标志、执行动作和数据，如下图所示。
图 3. 为Robot指定每个对象的对象类型、对象标志、执行动作和数据
以按钮举例来讲，如果要让Robot自动点击某个按钮，那么首先要告诉Robot需要在“Button”这种类型的对象上进行操作；其次要告诉Robot，在此类型的对象上要执行什么操作，比如click；第三要告诉Robot要click那个具体的按钮上，比如要click“登录”按钮。
在Robot测试技术框架中，相应的处理为：
|
'打开文件 =============================== ‘对文件中每一行 ‘对按钮执行的动作 ‘对文本框执行的动作 ‘对组合框执行的动作 =============================== ‘对单选按钮执行的动作 |
要强调的是，以按钮为例，虽然在表中需要为界面上每一个具体的按钮定义一行，但是在测试技术框架中，所有按钮处理的代码都是一样的。
3.2.3 验证点
没有验证点的自动化测试就不能称之为测试。从这句话中就可以看到验证点在自动化测试中的重要性。对于验证点来讲，因为不同的测试、不同的应用验证点都不相同，所以Robot测试技术框架仅仅提供了扩展的机制，不同的验证点可以通过扩展机制加入到测试技术框架中。
加入验证点之后，表的定义如下：
最后一行是加入的验证点。所有的验证点其对象类型均为VP，不同的验证点有不同的对象标志，上表中的验证点是VP_SUM，验证点的基线数据为24。
在Robot测试技术框架中，处理如下：
|
‘对文件中每一行 ‘对验证点执行的动作 =============================== ‘验证点脚本的处理 |
将验证点的基线数据放入全局变量g_VP_SUM_Baseline中，然后使用CallScript函数来调用验证点的脚本。对每一个验证点单独的创建一个脚本文件，脚本文件的名字和验证点的标志相同，都是VP_SUM。虽然各个验证点脚本的内容都不相同，但是一般的步骤是首先从全局变量g_VP_SUM_Baseline中取出基线数据，然后使用SQAGetProperty函数从界面上取实际的数据，再比较实际数据和基线数据。
3.2.4 数据池
往往需要使用不同的数据来运行同一个测试，在自动化测试中是使用数据池来实现的。数据池的增加比较简单，就是往表中增加表示数据的列，每一列代表一次测试执行所需要的数据。如下表：
从上表中看到，“数据1”这一列代表一次测试的执行所需要的数据，“数据2”代表另外一次测试的执行所需要的数据。
在Robot测试技术框架中，加入循环，按照数据列的数量来进行循环，每一个循环均从第一行执行到最后一行。
3.2.5 执行分支
在测试中，往往是同一个业务或者功能，但是因为输入的数据、选择的条件不同，而具有不同的执行流程。执行分支的处理比较简单，就是在相应的数据列的位置上，填写代表忽略的特殊标志，比如“IGNORE”，当测试执行到此动作时，判断其数据是否是“IGNORE”，如果是，就不执行此动作而到下一个动作。对应的表如下：
从上表中看到，第一次执行会执行VP_SUM验证点，但是第二次执行，因为验证点相应的数据是“IGNORE”，所以就不会执行VP_SUM验证点。
在Robot测试技术框架中，在每次执行动作时，先判断其数据是否是“IGNORE”即可。
3.2.6 数据关联
在测试中，需要处理数据关联这种情况。数据关联是指前一个动作执行完成后，应用产生新的数据，此数据在随后的动作中需要用到。因为这些数据是在执行的过程中由程序产生的，所以没有办法预先在表中准备。在这种情况下对应的表如下：
从上表可以看到，首先使用DC_GETID来将要关联的数据取出来，然后在需要使用此数据的地方，再使用DC_SETID赋值回去。
在Robot测试技术框架中，取数据的处理如下：
|
‘对文件中每一行 =============================== ‘对数据关联执行的动作 =============================== ‘数据关联中，获取数据脚本的处理 |
对每一个数据关联，取数据单独的创建一个脚本文件，脚本文件的名字和数据关联的名字相同，都比如说都叫DC_GETID。虽然数据关联取数据脚本的内容各不相同，但是一般的步骤是使用SQAGetProperty函数从界面上取得数据，放入全局变量g_DC_ID中。
在Robot测试技术框架中，赋值回去的处理如下：
|
‘对文件中每一行 ‘对文本框执行的动作 |
即从全局变量g_DC_ID中取出数据，再输入到文本框中。
3.2.7 其它处理
其它处理包括日志记录、调用其它脚本以及脚本结束，相应的表如下：
可以看到，在动作类型这一列，使用使用“L”代表记录日志，日志的内容存放在这一行的数据列中，比如上表中的“输入交易号”；使用标志“S”代码调用其它脚本，要调用的脚本名称存放在这一行的数据列中，比如上表中的“Order”；使用标志“X”代表脚本结束。
在Robot测试技术框架中，相应的处理如下：
| ‘对文件中每一行 Select Case (sActType) Case “G” Process…… Case “L” Log(sData) Case “S” CallScript sData Case “X” Exit |
3.3 测试设计工具
测试设计工具的最主要的目的就是为了提高Robot测试技术框架的易用性，帮助测试人员生成表驱动所需要的表。另外，测试设计工具通过使用数据库，能够在工具级别为测试重用提供支持。测试设计工具主要包括两方面的功能：供技术测试人员创建测试的静态结构；供业务测试人员创建测试的动态结构。
测试的静态结构要求和应用保持一致，以页面为单位。即应用中各个功能的层次结构是如何来安排的，就相应的在测试设计工具中按照这种安排来建立静态结构，直到每个页面为止。这样来设计的好处是：首先，静态结构和应用保持一致，将来应用发生变化，比较容易定位到静态结构中需要修改的地方；其次，建立静态结构，应用是什么样子，就建立成什么样子，照搬即可，不需要很多的业务知识，比较适合于技术测试人员；最后，静态结构和应用保持一致，将来业务测试人员设计测试的动态结构时，能够方便的根据应用在静态结构中找到相应的页面。
以下是已经建好的静态结构的示例：
图 4. 静态结构示例
可以看到，左边是和应用功能组织保持一致的树形结构。点开“集团理财”节点，可以在右边的上半部分看到此页面中的元素，页面上每一个元素都按照Robot技术框架的要求输入必要的信息，比如对象类型、对象标志、执行动作等。这些内容是由技术测试人员根据页面来输入的。如果不希望人工输入的话，那么也可以开发相应的工具去解析页面，来自动的生成每个页面的元素，或者是使用IBM Rational Functional Tester（简称RFT）的对象映射功能，由RFT去页面上抓取对象来生成。
测试的动态结构和测试的要求有关。在创建测试用例的过程中，测试用例的每一个步骤，均是选自静态结构中的一个页面，将页面加入到测试用例中之后，还可以指定此次测试用例要测试页面上那些元素。另外，在测试的动态结构中，还可以指定测试数据、验证点、数据关联等操作。当设计完成后就直接生成真正可以被Robot测试技术框架所执行的表。
以下是已经建好的动态结构的示例：
图 5. 动态结构示例
可以看到，左边是和按照测试的要求组织起来的测试用例。点开“票据托管”这个测试用例，可以在右边的上半部分看到此测试用例的执行步骤，比如第一步是“登录”，第二步是“票据托管导航”，依次下来是“票据托管”和“退出”，这些步骤都是从静态结构中选出来的。当点击测试步骤中“票据托管”这个页面，在下方将此页面的元素显示出来，业务测试人员可以为每一个测试元素输入数据、指定数据关联、添加验证点等。
当业务测试人员设计好测试用例后，就可以将测试用例传递给Robot测试技术框架，又测试技术框架解释并执行。
可以看到，使用IBM Rational Robot提供的强大功能所搭建起来的自动化功能测试框架，能够帮助软件开发组织成功的实施自动化的功能测试。
1. 通过重用已有的静态结构和动态结构，能够有效的促进测试的重用，并且在IBM Rational Robot的支持下，可以自动的执行这些测试
2. 通过使用测试设计工具来生成动态配置，可以看到除测试技术框架的SQABasic脚本外，不需要再维护任何其它的脚本，降低了脚本调试、维护的工作量。并且将来的维护是基于测试设计工具来进行，也降低了自动化测试整体的维护工作量
3. 通过使用测试设计工具来生成静态配置，能够做到根据界面的设计来进行配置，而不需要等到待测试应用完全可用，就使得及早测试成为可能
4. 通过支持业务、技术测试人员的分工，在测试技术框架中封装自动化测试技术细节，使得业务测试人员不需要自动化测试技术的相关知识，只需要通过测试设计工具，就能够简单、直观的进行测试的设计和执行，降低了自动化测试的实施难度
另外，在实施自动化功能测试框架中，还发现两个有趣的现象。第一，因为可以去自动化的执行测试，所以业务测试人员更多的在使用测试设计工具，从而导致测试设计在整个测试中所占的比重有显著的提高，有效的提升测试的质量；第二，因为统一、一致的界面操作方式、提示方式和表达方式有利于自动化测试的进行，所以也间接的促使开发团队在设计、开发过程中更加注重界面的规范性以及界面控件的可测试性。
参考资料
在 developerWorks 上可以找到 Rational Robot专题
关于自动化测试框架的相关概念Choosing a test automation framework
关于作者
陈国伟，IBM中国软件开发中心实验室服务高级软件工程师，专注于Rational软件。目前主要致力于为客户提供软件工程的方法、技术和工具的服务与支持，关注的领域有JAVA开发、RUP实施、用例建模、OOAD、测试以及配置和变更管理。在加入IBM之前，参与ERP、保险、电信等大型软件项目的管理和开发，拥有6年软件开发经验。
