《精通自动化测试框架设计》—第2章 2.4节使用XML文件

本节书摘来自异步社区《精通自动化测试框架设计》一书中的第2章，第2.4节使用xml文件，作者陈冬严 , 邵杰明 , 王东刚 , 蒋涛，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.4　使用xml文件

xml，可扩展的标识语言（extensible markup language），其先驱是sgml和html。1996年万维网协会（w3c）开始设计一种可扩展的标记语言，使其能够将sgml的灵活性和强大功能与已经被广泛采用的html结合起来。1998年2月，xml 1.0 成为了w3c 的推荐标准（顺便说一下webdriver现在也是w3c推荐标准）。xml最大的优势在于对各种数据的跨平台管理，任何操作系统，包括windows 、macos 、linux 以及其他平台都可以通过xml的解析器来读取xml数据，并且以xml格式输出结果。虽然早在2004年就有人喊出了“xml在互联网上已经失败”（xml on the web has failed[1]）的口号，但目前xml仍是目前事实上的系统间数据交换的标准。

2.4.1　webdriver中的定位方法

俗话说女大十八变。用这句话来形容b/s架构的软件产品的用户界面也是非常贴切的。ui自动化的一大挑战就是如何应对经常变化的界面，将界面定位的维护成本控制在一个较为合理的范围内。这其中一个比较好的实践就是将界面元素的定位信息保存在外部文件中，如xml，作为运行时框架类的输入数据，动态地导入到其对应的页面类中供定位使用。

webdriver中通过实现了by这一接口的各个driver类的实例来进行元素定位。典型的用法如下例所示：

第一个方法返回一个webelement实例或者抛出异常。后者返回所有找到的webelement的实例列表或者空列表。

其中，by这个接口中定义的元素定位的方法有如下8种。

按照一般的理解，通过id或者name去定位一个元素效率上是最高的，也是比较推荐的一种方式。不过在很多情况下，一些开发规范遵守的不是很好的工程组织，可能对于给每个页面元素进行命名这种事情做得并不太好，或者随着现在比较主流的前端框架，或者开发库，如extjs、jquery等，一般都采用随机或者相同的id、name等，需要采用更为复杂的定位方法。这在后续章节中会有详细的介绍。

接下来根据一个样例来介绍如何进行 xml 文件的解析。假定有如下一个名叫locatorpaser.xml的文件。

从该xml文件的格式上看，单个定位数据以locator标记为一个元素，元素属性分别有name、by，而元素内容就是by对应的定位方法需要的定位信息。locator之间彼此独立，并同属于一个带locators标签的父元素。

从文件内容上看，该xml文件维护着某一被测应用ui自动化测试中的定位信息，并且显而易见是一个登录页面中有关用户名、密码输入框以及登录按钮这3个页面元素的定位信息。其中用户名和密码输入框分别使用了"id"、"name"等属性，而登录按钮则使用了xpath的定位串。

在实践中使用最为广泛、表现也最为稳定的可能是xpath或者cssselector这两大流派。首先，对于其他定位方式来说，这两个都是可以由相应方法实现相同的目的。其次两者虽然采用的技术路线不同，所能达到的效果也基本是伯仲之间。因此，只要学好学精一门，其余略懂即可。在本书中主要采用xpath来介绍相关的元素定位技术。相信采用cssselector的读者可以较为方便地进行转换。当然本节的主题是有关xml的解析，有关xpath等元素定位的基本方法，可以参见本书最后一部分有关webdriver的基础知识介绍。

2.4.2　使用dom4j进行解析

sax（simple api for xml）是一种事件驱动的xml api，其采用了输入流的方法，按照事件模型来解析xml文档。因为不必像dom那样加载整个文档，因此它对内存的要求较低，解析更快速、更轻量，非常适合于本案例中对于xml文件的只读访问。

下述locatorpaser类将对前述的xml文件进行解析，最终获取到像"xpath=//input [@name='login_submit']"这样的定位串，可以用于后续的元素定位。类的具体实现如下：

上述测试用例在一台笔记本上的执行结果是：

结果正确，文件解析的效率也是不错的。