基于 IBM Rational Robot 的自动化功能测试框架

发布: 2009-4-22 10:04 | 作者: 陈国伟 | 来源: 测试时代采编 | 查看: 219次 | 进入软件测试论坛讨论

从上表可以看到，首先使用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 其它处理

其它处理包括日志记录、调用其它脚本以及脚本结束，相应的表如下：

表 7：数据池表d 动作类型对象类型对象标志执行动作数据1 G Button 确定 Click G HTMLLink 链接 Click G ComboBox 角色列表 Click 系统管理员普通管理员 G RadioButton 区域 Click V VP VP_SUM VP_SUM　 24 IGNORE G DC DC_GETID DC_GETID G EditBox 交易号 Click DC_GETID DC_GETID L 输入交易号输入交易号 S Order Order X

可以看到，在动作类型这一列，使用使用“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. 通过支持业务、技术测试人员的分工，在测试技术框架中封装自动化测试技术细节，使得业务测试人员不需要自动化测试技术的相关知识，只需要通过测试设计工具，就能够简单、直观的进行测试的设计和执行，降低了自动化测试的实施难度

另外，在实施自动化功能测试框架中，还发现两个有趣的现象。第一，因为可以去自动化的执行测试，所以业务测试人员更多的在使用测试设计工具，从而导致测试设计在整个测试中所占的比重有显著的提高，有效的提升测试的质量；第二，因为统一、一致的界面操作方式、提示方式和表达方式有利于自动化测试的进行，所以也间接的促使开发团队在设计、开发过程中更加注重界面的规范性以及界面控件的可测试性。