在Robot测试技术框架中，相应的处理为：

'打开文件 Dim sData() as string InFileName = getExcelFileName ReadExcelData InFileName, sData() =============================== ‘对文件中每一行 Select Case (sObjType) Case "Button" ProcessButton(sObjAction, sObjData, sData) Case “EditBox” ProcessEditBox(sObjAction, sObjData, sData) Case “ComboBox” ProcessComboBox(sObjAction, sObjData, sData) Case “RadioButton” ProcessRadioButton(sObjAction, sObjData, sData) =============================== ‘对按钮执行的动作 Select Case(sObjAction) Case “Click” Window SetContext, "currentwindow", "" PushButton Click, "Text=" & sObjData, "" =============================== ‘对文本框执行的动作 Select Case(sObjAction) Case “Click” EditBox Click, "Name=" & sObjData, "" InputKeys "^+{HOME}{DELETE}" InputKeys sData =============================== ‘对组合框执行的动作 Select Case(sObjAction) Case “Click” ComboBox Click, "Name=" & sObjData, "" ComboListBox Click, "Name=" & sObjData, "Text=" & sData =============================== ‘对单选按钮执行的动作 Select Case(sObjAction) Case “Click” RadioButton Click, "Name=" & sObjData

要强调的是，以按钮为例，虽然在表中需要为界面上每一个具体的按钮定义一行，但是在测试技术框架中，所有按钮处理的代码都是一样的。

3.2.3 验证点

没有验证点的自动化测试就不能称之为测试。从这句话中就可以看到验证点在自动化测试中的重要性。对于验证点来讲，因为不同的测试、不同的应用验证点都不相同，所以Robot测试技术框架仅仅提供了扩展的机制，不同的验证点可以通过扩展机制加入到测试技术框架中。

加入验证点之后，表的定义如下：

　最后一行是加入的验证点。所有的验证点其对象类型均为VP，不同的验证点有不同的对象标志，上表中的验证点是VP_SUM，验证点的基线数据为24。

在Robot测试技术框架中，处理如下：

‘对文件中每一行 Select Case (sObjType) Case …… Process…… Case “VP” ProcessVP(sObjAction, sData) =============================== ‘对验证点执行的动作 g_VP_SUM_Baseline = sData CallScript sObjAction =============================== ‘验证点脚本的处理 sData = g_VP_SUM_Baseline SQAGetProperty “”, “”, sActual if sData = sActual then …… else …… end if

将验证点的基线数据放入全局变量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测试技术框架中，取数据的处理如下：

‘对文件中每一行 Select Case (sObjType) Case …… Process…… Case “DC” ProcessDC(sData) =============================== ‘对数据关联执行的动作 CallScript sData =============================== ‘数据关联中，获取数据脚本的处理 SQAGetProperty “”, “”, g_DC_ID

对每一个数据关联，取数据单独的创建一个脚本文件，脚本文件的名字和数据关联的名字相同，都比如说都叫DC_GETID。虽然数据关联取数据脚本的内容各不相同，但是一般的步骤是使用SQAGetProperty函数从界面上取得数据，放入全局变量g_DC_ID中。

在Robot测试技术框架中，赋值回去的处理如下：

‘对文件中每一行 Select Case (sObjType) Case …… Process…… Case “EditBox” ProcessEditBox(sObjAction, sObjData, sData) =============================== ‘对文本框执行的动作 Select Case(sObjAction) Case “Click” EditBox Click, "Name=" & sObjData, "" InputKeys "^+{HOME}{DELETE}" InputKeys g_DC_ID

即从全局变量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测试技术框架，又测试技术框架解释并执行。

4. 结论

可以看到，使用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年软件开发经验。