...Functional Tester(RFT) 开发 Web 应用自动化测试框架 ...

基于 Rational Functional Tester 开发 Web 应用自动化测试框架简介：Rational Functional Tester（RFT）是 IBM 提供的一款自动化测试工具，适用于各种测试工作，特别擅长于 GUI 方面的自动化测试，可以方便的查找控件，提供了丰富的方法供软件测试人员用于脚本开发使用。本文以一款针对数据输入进行预测分析决策的 Web 产品的自动化测试为例，借助 Rational Functional Tester（RFT）设计和开发 DM Automation 这个自动化测试框架，详细介绍了自动化测试框架的设计原理，以及如何组织测试用例。同时本文还分享了一些自动化测试框架设计的经验与遵循的原则。背景知识IBM Rational Functional Tester（简称 RFT）是一款先进的、自动化的功能和回归测试工具，它适用于测试人员和 GUI 开发人员。使用它，测试新手可以简化复杂的测试任务，很快上手；测试专家能够通过选择工业标准化的脚本语言，实现各种高级定制功能。通过 IBM 的最新专利技术，例如基于 Wizard 的智能数据驱动的软件测试技术、提高测试脚本重用的 ScriptAssurance 技术等等，大大提高了脚本的易用性和可维护能力。同时，它第一次为 Java 和 Web 测试人员，提供了和开发人员同样的操作平台（Eclipse），并通过提供与 IBM Rational 整个测试生命周期软件的完美集成，真正实现了一个平台统一整个软件开发团队的能力。RFT 提供的自动化测试方式一般分为两种，一是采用录制器录制生成测试脚本，二是由 QA 人员编写测试脚本。由于录制生成脚本的方式存在一些弊端，比如脚本复用性不高，不易维护，脚本可移植性不高等等，我们选择了第二种方式作为了自动化测试框架的脚本生成方式。本文实现的测试框架能够从数据文件中读取测试数据，然后传入自动化脚本，不同的数据文件对应不同的测试用例。这种模式实现了数据和脚本分离。提高了脚本的利用率，并使脚本的可维护性大大提高。本文实现的框架另一个特点是脚本编写人员无需掌握编程语言，只需要用 xml 文件来编写一个个基础的测试单元，再通过通过统一的 xml 文件来组织这些小的测试单元，从而形成真正的测试用例，这种方式可以灵活组织测试用例，测试单元可以得到很大程度的复用，编写效率很高。通过以往的尝试，发现真正实现自动化测试，并不是掌握了某个自动化测试工具，掌握了脚本的编写技术就能够达成，面对复杂的 ERP 系统，简单的录制 / 回放并不能达到自动化测试的要求，虽然花费巨大代价但起到的效果甚微。基于以上因素并结合行业发展思路，在正式实施自动化之前，必须搭建一套适合的自动化测试框架，将脚本能够有效的组织、连贯应用起来，提高测试脚本的可维护性和可读性。在进行自动化框架的开发工作时，我们需要从以下几点进行考虑： 高复用性 高可维护性 稳定性 快速编写脚本 自动执行 正确输出结果 能够不断提升自动化测试比例 本文实现的自动化测试框架，也正是基于以上方面的考虑，分析设计的。示例背景DM (Decision Management) 是一个基于 Web 开发的决策管理产品，DM 自动化框架是以 DM 产品为测试目标开发的一套自动化测试框架，当然它同时适用于大多数的 Web 产品的测试。如图所示：DM 产品是一个标准的富客户端应用，以 GWT 来编写 Ajax 前端。需要进行自动化测试的部分主要是 view 层用户和应用的交互，前端在调用服务器端服务后，返回数据的效验以及异步调用后数据的效验等等。图 1. DM Web 端架构设计自动化测试框架的设计原理ITCL 框架是 IBM 公司内部被广泛使用的自动化设计框架，也叫做 IBM 框架。主要的设计宗旨就是将代码划分成三层结构，即对象层（AppObjects layer）、任务层（Task layer）、测试用例层（TestCases layer）。将代码划分成三层结构使得“做什么“和”如何做“分离开来，有利于代码的组织，结构清晰。同时提高了代码的可复用性和扩展性。当使用 ITCL 框架开发自动化测试脚本时，其核心的任务就是合理的设计和组织对象层和任务层。在自动化测试框架中合理的设计对象层和任务层常常会使整个自动化项目的开发和后期维护达到事半功倍的效果，DM 测试框架的分层结构在基于 ITCL 框架的基础上进行了一系列的改变，简化了对象层，将 object 层与 task 合并为 task 层，每一个 task 由一个 xml 文件来定义，task 是由多个 step 标签组成的，每一个 step 可以看成是以往的 object。同时增加了 Utile 工具包，主要存放通用的方法，例如：测试单元中使用的所有的标签类、xml 解析类、文件读取类、日志类、效验类等等。对于这些基础的类是框架最为固定的部分，因为无论将自动化框架在哪一个 Web 应用中使用，这部分内容都是可以完全重用并可以持续扩展的。图 2. 自动测试框架示意对于 Web 应用来说，主要是靠浏览器来解释页面中的 html 元素来运行程序。对于每一个 Web 页面来说都是由不同的 html 标签组成的，虽然页面元素是多种多样的，不同的应用所使用的控件也不尽相同，但是对于一个应用来说，使用的控件是相对固定的。而用户对于页面上的操作无非只有一下几种事件：1 鼠标点击，2 键盘操作，3 等待。对于自动化测试来说只要能够按顺序表示出某个页面中对于指定控件的一组操作（例如：输入，输入，点击，等待）就可以实现对于这个页面的业务逻辑操作。我们将用户在 Web 应用中的操作都定义相对应的标签，比如输入定义为 、点击事件定义为 、等待定义为 等等。 标签则是用来找到指定的控件，find 标签有三个属性 findType、property、value，只要在 xml 文件中将这三个值设置上，xml 解析器就可以通过获取 xml 中指定的值，调用 RFT 的查找方法来实现控件的查找， 标签和用户的操作组合起来使用。具体的标签的实现方式则是封装了 RFT 提供的方法来完成的。同时我们定义了效验标签 ，当用户操作到某一步骤时候需要加一个验证点时可以直接使用 validate 标签，在该处插入验证点即可。将操作定义为标签可以极大的降低测试人员开发脚本的难度，更容易复用，和灵活的调用。同时，我们可以自己在增加一些自定义的标签，在一个应用中非常公用的组件可以定义成一个通用标签，从而减少整个测试脚本代码量，减少错误。 标签的实现写法如下：public class ClickTagParser extends TagParser public ClickTagParser(Element rootTagElement) super(rootTagElement);Overridepublic void takeAction(TestObject component) if (component != null) try (GuiTestObject) component).click(); catch (Exception e) e.printStackTrace(); 例如一个点击动作在 xml 文件中的的写法是回页首实例一个登陆的业务操作由两次输入（输入用户名，输入密码）和一次点击动作（点击登陆按钮）完成那么测试人员仅仅需要编写如下的 xml 内容即可，而这一个功能就可以当作一个测试单元，我们为它命名为“LogingSucess”，并可以在最终的测试用例脚本中去调用，由多个小的测试单元最终会组合成一个完整的测试用例。图 3. 一个登陆的业务操作使用自动化测试框架后，测试人员不必关心框架的实现细节，只需要根据业务逻辑组织 xml 文件。然后再将写好的 xml 文件通过统一调用的方式在一个总的 xml 文件中里进行灵活组装和调用，从而组成一个完整的测试用例。通过配置 xml 来定义出一个真实的测试用例，如下为总的测试入口 xml 的部分配置信息：testscript scriptName=commontasks.DataStep图 4. DM Automation 框架示意图如同所示，框架首先通过 RFT 启动脚本调用 Test Suite 这个 xml 文件（Test Suite 由测试工程师来组织需要运行的 TestCases）然后通过 XML 解析器逐层来解析 TestCases 里有哪些 Task，并找到这些 Task 对应 xml 文件，然后继续去解析 Task 中的标签，而标签的相应动作则定义在标签库中，通过 RFT 提供的方法，而最终完成整个自动化测试的过程。整个过程中每一个步骤都是可以通过 XML 文件灵活的装配，从而使测试工程师的精力都集中在如何去组织，调用 Task 而成为实际的测试用例。DM 自动化测试框架的输入分为两部分，一部分来自外部数据文件，是以 property 文件来存放数据。另一部分输入则是直接在实际的测试用例中传入指定的参数，小的测试单元根据名字接收这些参数来实现数据输入。效验和最终的日志对于自动化测试来说是非常重要的部分，在 DM 自动化测试框架中，将这两部分功能进行了重新的开发。日志分为两个部分，一是总体的测试结果，二是具体每一个测试单元的详细信息，同时具有错误用例，正确用例的过滤功能。测试不会因为一个页面错误，比如控件不存在而中断。测试的过程会跳转到下一个测试用例，继续进行。图 5. 日志示意 1所有运行结果通过时候，日志的抓图。图 6. 日志示意 2图 7. 日志示意 3图中红色表示运行状态失败的效验点，框架会自动为效验结果失败的用例抓取错误时的图像。图 7. 日志示意 3发布：通过批处理命令，设置 RFT 启动的计划。这样自动化测试可以随时运行。一般较长的测试用例，可以安排在周末进行运行。在周一工作日时直接查看测试用例日志。总结优点1. 简化测试人员脚本开发难度，测试人员仅需要根据页面的操作逻辑顺序编写 xml 文件，不需要掌握 java 等开发语言 2. 复用方便，一些公用的组件可以写成统一的标签，在 xml 里直接调用 3. 脚本是解释性的，因此框架 DLL 不需要重新编译。 4. 脚本由于成为配置，那么其管理也就变得更加容易和简单。 5. 可以让测试人员，完全只是关心业务上的脚本。 6. 配置中，可以方便地记录每一步的执行内容。原先的编译方式，失