使用XML维护Selenium自动化测试脚本

使用XML维护Selenium自动化测试脚本2013-11-17 ibm 祝尚元本文适用于需要为测试团队开发自动化回归测试框架的测试设计开发人员。目前业内主流的商业自动化测试工具和开放源代码测试工具，都需要测试人员熟悉开发编程语言。但是过高的编程门槛让很多测试人员只能对自动化测试驻足遥望。为解决该群体的困扰，本文将介绍一种基于 XML 维护自动化测试脚本的自动化测试框架，并详细描述了其中的技术实现细节。XML 具有编写简单，易于在任何程序中读写数据等特性，这使得 XML 成为了数据交换的唯一公共语言。使用基于 XML 的 Selenium 自动化测试框架，可以让不熟悉编程的测试人员快速编写出类似传统功能测试用例的自动化测试用例，从而扫除自动化测试的技术障碍。

本文首先会对比一下业内主流的自动化测试工具，简单分析测试人员使用这些工具时存在的问题。然后以测试人员编写的一份传统测试用例为例子，演示如何使用 Selenium 为其编写自动化测试脚本文件。接着，介绍了如何开发基于 XML 的 Selenium 自动化测试框架。最后，简单介绍了一下如何为基于 XML 的 Selenium 自动化测试框架编写更多的特性。通过比较两种自动化测试实现方式，使用 XML 维护 Selenium 自动化测试脚本的优势一览无余的展示出来。

Web 应用自动化回归测试工具一览

随着软件公司的发展，产品线不断扩大，软件新版本不断推出，支持的平台越来越丰富，如何高效、快速的对软件产品进行测试成为软件测试团队的新挑战。越来越多的项目组在考虑对软件软件产品进行自动化回归测试，考虑选取适合自己项目组的自动化工具。面对数目繁多、各式各样的自动化工具，选择也不是件很容易的事情。测试人员耳熟能详的测试工具如下表：

表格 1. 自动化测试工具

如上表所示，开源的有 Selenium、 Watir 等，商业的测试工具如 Rational Functional Tester、Rational Robot、QTP、SilkTest 等等。开源工具使用成本比较低，但功能不如商业工具丰富。商业工具可以提供强大的录制功能，为初学者所喜爱，但录制脚本并不是自动化测试最优方案。录制脚本中的测试数据和脚本程序混杂在一起，很难进行维护；此外，当测试用例发生较大的变更时，维护用例和重新录制用例所花费的精力不分上下。值得一提的是，RFT 作为 IBM Rational 产品家族的重要组成部分，吸引了大量的测试人员使用该工具。IBM Frame 框架，更是让 RFT 测试脚本开发效率倍增，您们可以再 developerWorks 上面发现很多关于这个框架的文章。以 Selenium 为代表的开源工具，也吸引了大量的测试人员，developerWorks 上也发表了很多文章，如《使用分层的 Selenium 框架进行复杂 Web 应用的自动测试》等等。但是，不管使用什么样的工具，都需要测试人员熟悉开发编程语言。编程门槛让很大一部分的熟悉业务的测试人员只能对自动化测试驻足遥望。那么，如何让不熟悉编程的测试人员也能编写自动化回归测试用例呢？

业务测试人员擅长什么

显然，测试人员十分熟悉业务，擅长编写传统的功能测试用例文档。本文会给出一份简化的测试用例：在搜索引擎谷歌站点查询 IBM 开发者社区，如下表：

表格 2. 测试用例

该测试用例只包括测试步骤，每个测试步骤又分成若干组成部分：步骤编号、测试步骤、期望结果、实际结果、执行状态等。很显然，业务测试人员肯定会写出比这复杂得多的用例。我们用这份简单的测试做演示使用。下面就演示如何对这个用例做自动化测试。