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、H五、小程序几乎全部前端UI自动化上，都是适用的。由于接口请求的稳定性和维护成本永远低于UI操做。准确来讲，与CheckPoint无直接关联的UI操做，如数据的建立和删除。这里是post请求的方法封装：

---

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

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

采用这个方式的优点：
一、自动化测试任务中途异常退出结束了，也能够清理掉已建立的数据
二、支持多份的一样数据清理，数据之间不受影响
三、无需用完马上删除，统一清理，且支持并发，高效

---

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

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