接触 UI 自动化也有相当长时间了，想在这里分享一下自己的一些小经验。自己实现自动化覆盖和维护的 UI 用例数量在 1000 左右，从实践的角度谈一下 UI 自动化的框架、代码、设计等问题。因为我参与的主要都是对埋点的测试，只涉及在 UI 一步步操作，所以不谈论类似如何保障校验相关的话题。
一开始因为是新开一个坑，所以团队进行了对一些常用工具/框架的学习研究，包括 cypress、Katalon、robotframework 之类的。从易用性、易学习性、是否可录制等等多方面去比较。最后我们团队选择的是 robotframework。主要原因就是我们已经有一套使用 robotframework 编写的成熟稳定的测试代码，重新用其他的有学习成本和习惯成本，而且其他工具的优点没有压倒性的优势。
我个人对于选择框架、工具甚至编程语言的看法是，跟着团队习惯来。以前有成熟案例的，就用以前的方案；大家都会某个语言的，就选用那种语言的框架；有极端需求的，仔细研究探索；什么都没参考的，就大家都每样写个 demo，哪个顺手用哪个；没有特殊需求不要自己搞框架/平台。一般情况下，框架之间没有什么太大差别。
一开始直接把 xpath 一把梭在了代码里。不过也不是直接在用例层，是代码里的页面元素层。从逻辑上讲，这样和单独存文件里是一样的。但是查找元素麻烦。因为我们的产品比较复杂，元素还是比较多的。当我需要做点击某元素的操作时，想找出这个元素写在了哪个地方非常麻烦，而且大量的代码非常晃眼。
后来决定把 xpath 单独存出去，选择了 xml 结构。xml 的好处如下:
1.有层次
可以很好地模拟 html 的层次，也可以虚拟出抽象的层次。找元素方便了很多。
2.可以携带很多信息
xml 的元素节点可以容纳无数信息，只需在后面添加属性即可。
这个方案其实是不错的，但有个实践上的问题：多少元素放在一个文件里？
是按页面区分开？还是按抽象的组件区分开？或是一把梭在一个文件里？那如果有一天页面结构变了，我的 xml 如何维护？
再后来我采用了 yml 文件存储元素定位信息。yml 的好处是简洁，没有多余的符号。把每个页面分开，再把一个页面里的不同 tab 分开 (这种得看具体的项目决定结构)。实践下来我认为比上面两种方案都要优秀一些，而且后来移交给代码能力较弱的成员时对方也能很好地编写和维护。
到这里我发现了一些问题。当我已经自动化覆盖了很多用例后，发现了设计上的缺陷 (仅指 PO 部分)，想修改时，不得不耗费大量精力。然而实际上，最核心的信息是一样的，就是页面元素和其定位的对应关系。我只不过想更改这些信息外在的包装结构。那我能不能只提供最基本的信息，其他的我设计好让程序自动去做呢？于是我自己编写了一个小工具来实现我的想法。我只需维护好一个个元素信息文件，然后自动生成可以直接粘贴到项目里面的代码。为了方便，注释、基本操作函数 (click、setValue 等) 也放了进去。我也不用再去管这个 input 的输入函数除了输入内容外，还要传递几个参数来定位到这个 input——程序会替我安排好。我对这个工具给我节省的时间相当满意。工具原理很简单，说白了就是字符串模板，代码贴上：
https://github.com/flora-team/flora
我尝试过极端的方式：无业务逻辑层。用例里直接操作元素，如点击 A、点击 B、输入 C。我希望用这种方式来减小巨大设计变更给我的用例带来的影响。我现在的建议是，永远不要这样做。它给你带来的是无尽的维护工作。但这样的经历也给了我其他的思考。
我现在的经验是，对于复杂的项目，不要想着事先设计好业务逻辑的封装。当然，一些简单的封装还是可以的，比如应对菜单中的"更多"。我指的是在简单封装之上的封装可能没办法事先设计出较好的方案。但是，如果一开始覆盖自动化时，挑出大概 20 个场景差不多的用例，不进行任何业务逻辑的封装，直接在用例中操作元素，这样，当你完成 20 条用例的编写后，你就已经知道如何封装业务逻辑了。然后进行一些复制粘贴的工作，可能有少量的细节修改，就完成了 20 条拆分业务逻辑合理的用例。
我基于 uirecorder 魔改了一个工具，试图应用在工作中。结论是这类记录元素路径的录制方案的应用场景极其有限，而且几乎不可维护。即使我魔改的工具根据产品特点能直接录制出稳定性较高的 xpath，但再怎么高，毕竟每条录制下的用例都是独立的，一旦有变动，要么一个个改，要么一个个重录。用例数量多的话，很难承受这样的代价。
airtest 也用过，用图片定位的设计很好。我把 airtest 这部分的代码拿了出来，放在了自己项目的 canvas 操作里，效果非常好。但全部用图片定位不太行，一个是定位速度，一个是精准度。对移动端可能不错，但复杂的 web 产品页面杂、相同类型元素多，还有很多元素需要用文字定位，airtest 的效果较差。
结论是，自动化录制对于少量用例，或者时效短的用例效果很好，可以节约大量时间而且门槛低，但长期维护的用例不可用。
当然，一切都要基于具体的项目特点。彼之蜜糖，吾之砒霜。