一、 现状

在自动化的过程中， 我们知道web自动化测试的开发和维护成本是比较高的，能否采用技术以及流程改进等手段来降低web自动化测试的成本呢？
我们先看看目前的实现方式，通常，实现步骤如下：
(1) 首先使用domsipder抓取我们所需要的网页上的元素，存储在xml文件中。
(2) 实现相应的关键字。这里的关键字主要有两类，一类是一些基础功能的实现，拿alb项目来举例：“RadioButton是否被选中”、“CheckBox 是否被选中”、“Button是否可用”、“Link跳转验证”等等；另一类是业务相关的关键字：“登陆alb系统”、“退出alb系统”、“设置时间段 查询”、“选择查询方式”等等。
(3) 实现testcase，这里case会调用(2)实现的关键字。
在具体的实现中有两个缺点：
(1) 关键字不利于共享和维护。主要体现在以下几点：
? Domspider抓取的xml文件没有统一的组织和管理。即使对同一页面元素，我们可能在不同的项目中重复的抓取，实现关键字，一旦页面元素改变了，维护变得很困难。
? 业务关键字没有好的组织形式。如果需要复用关键字，必须在整个关键字列表中去寻找相关的功能，这个查找过程是比较盲目的。通常的结果是各自实现自己的关键字，造成了资源的浪费。
(2) Case对页面的直接依赖。Case实现中有直接对相关页面的操作，如果相应的页面改变了，可能对很多的case造成影响，并且我们很难定位影响的case的范围，给维护自动化case带来了很大的困难。
二、 改进方法

在tplmaker1.0.0这个项目中，我做了一些相关的尝试：总的来说，这里我们用分层的思想，把页面单独抽象为一层，把页面对象化。因为系统的功能可以转化为一系列的页面操作，所以也可以转化为一系列页面对象的调用。具体来说，主要完成了以下两项工作:
1. 页面元素的聚合
这里的页面可以是一个具体的页面，也可以是一个相关页面的集合，比如：在tplmaker中，MaterialType页面可以包括物料类型管理页，添加页，修改页，查看页。把这些页面相关的元素聚合一起，放在一个文件中定义，成为一个ui对象，如下所示：

这项工作主要有两个目的：
(1) 把相关的元素按照它们在页面上的关系组合在一起，当页面变化时，很容易通过页面的关系找到代码中应该修改的地方。
(2) 可以帮助我们通过页面的关系定位页面元素。比如我们通过某个属性来定位元素，可能页面上会有多个属性相同的元素，这时候如果我们需要的元素在一个 frame中，我们可以通过这种逻辑关系，通过先定位frame，然后只选择出在frame中的含有该属性的元素。在tplmaker中，并没有完全实现 功能，后续可以参考Tellurium进行改进。
使用groovy作为开发语言，使Ui的定义和使用都比较直观和方便。
2. 页面对象化
在另一个文件中（这里也可以写在一个文件中，写在不同的文件只是为了可以在ide中打开不同的窗口，方便编辑），我们定义这个物料类型管理页的对象，重点是对象的方法，这里的方法只是针对该页面得相关操作，如下图所示:

方法列表：

方法包括了对物料类型的增删改查，以及针对页面的更简单的一些必要的操作。
在具体的case中，没有具体的对页面元素的解析和操作，只有对页面对象的调用，使得页面与具体的Case解耦。如下图所示：

如上图绿框部分所示，通过主页面打开物料类型管理，然后通过物料类型管理列表页面进行添加物料类型操作，这里调用的都是页面对象的方法。这样做带来了以下优点：
(1) 便于共享。由于我们的操作是针对页面的，我们可以在对应的页面中寻找相应的方法。例如：我需要一个物料类型查看的功能，很容易确定我要在物料类型管理对象进行该操作，打开如下图所示的由groovydoc生成的文档，查找相应的类是否有所需的方法。

如没有查到相应的方法，可以自己实现，并注意写好doc注释，上传代码库，以便于他人复用。（页面的Ui对象也是同样的道理）
(2) 便于维护。如有某个页面元素发生变化，我们只需要在相应的页面对象中去修改，Ui和方法，不会对testcase造成影响。并且查找和修改都在一个文件中，降低了遗漏修改的可能性。
这里使用groovy作为开发语言，既可以使用Java强大的类库和资源，又可以使用一些脚本语言的高级特性，减小代码量。
三、 缺点和改进
缺点：
? 在写case的过程中，可能会有一些对页面的操作是很简单并且不常用的，按照上述做法，也需要在页面对象中抽象并添加一个方法，增加了一定的自动化成本。 如果一个页面上的 方法过多，也会影响我们查找。
? 对方法的设计和实现需要在建立在对业务有一定熟悉程度的基础上，否则页面对象的方法可重用性差，就会造成页面对象方法的爆炸，达不到我们想要的效果。
改进：
? 页面元素的抓取。如果可以通过插件实现对象的抓取，并且自动的生成聚合后的文件会减少大家很多工作量。在抓取对象时，需要选择定位的方式，目前的工具都会优先采用id进行定位，但有些元素是动态生成id的，抓取的元素没有意义。
? 对方法的抽取和实现提供一些建议和规范，尽量避免上面所提到的缺点
四、 总结

上述是在tplmaker项目中所做尝试的一点想法，和大家分享一下，难免其中有一些不合理之处，或者有更好的解决方法。虽然在尝试的过程中使用了selenium，但是一些想法应该同样可以用在ficus中。大家在自动化方面更有经验，欢迎大家拍砖、讨论。

（全文完）