Web UI自动化最佳实践

三思而后行

UI自动化测试最终目的是啥？投入产出比的最佳平衡点在哪？很多实施者在搭建UI自动化框架前往往缺乏思考，为了自动化而自动化。三思而后行，方向决定成败。由于项目接口（API and Service）自动化代码行覆盖率已经达到70%，基于当前自动化人力和项目质量目标，我们的自动化最终目的是覆盖上线回归的UI CheckPoint，为了降低后期维护成本，CheckPoint偏重于入口展示和用户事件响应逻辑。围绕目标，在搭建UI自动化框架的过程中探索了一些优化点，来分享一下

最佳实践

• 资源代码分离

XML与Java Object建议映射关系，一个页面对应一个XML，页面、控件信息和测试数据统一管理维护，如图：

测试用例执行之前，会将XML转化成Java Object，且会实例化一些操作类的方法，如图：

通过Override可以满足同一事件不同场景下的使用，也便于日志格式的一致性，提高脚本失败原因分析效率

---

• 自动抓取控件生成XML

既然采用XML管理Page和Element数据，那么生成XML这件事就可以自动化了，不过困难在于如何定义控件XPath生成规则，需要把手动写控件XPath的思考过程，抽象化，规则化。需要通过两方面来完成：

1. 有事件响应的控件，如button、a、input。而这些控件具备通用属性，且在一个页面大多时候具备唯一性，如：text、value、herf、placeholder，所以优先生成这个规则的XPath：
   
2. 业务通用组件一般基于div的形式，获取class生成唯一识别的XPath:

---

• 操作步骤使用接口请求代替UI操作

这一点套用在iOS、Android、Web、H5、小程序几乎所有前端UI自动化上，都是适用的。因为接口请求的稳定性和维护成本永远低于UI操作。准确来说，与CheckPoint无直接关联的UI操作，如数据的创建和删除。这里是post请求的方法封装：

---

• 命令模式进行测试后的数据清理

命令模式是Java种开发设计模型的一种，在这里具体是这样运用的：
1、每一项测试数据的清理，都是一个任务类，所有的任务类都继承了一个抽象类，在action方法里定义了数据清理的接口请求。
2、在每次创建数据后，实例化任务类，然后添加到队列里
3、所有测试用例执行完成后，afterTest里遍历队列依次数据清理

采用这个方式的优势：
1、自动化测试任务中途异常退出结束了，也可以清理掉已创建的数据
2、支持多份的同样数据清理，数据之间不受影响
3、无需用完立刻删除，统一清理，且支持并发，高效

---

• 通过Listener收集数据生成测试报告

日志统一，操作事件和检查点清晰可见，加上失败截图保存，一旦出现失败可以快速定位问题，大大降低后期维护成本