职业经验 我的 UI 自动化经历

naughtz · 2021年11月08日 · 最后由 alex 回复于 2021年11月11日 · 1723 次阅读

接触 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 的效果较差。
结论是,自动化录制对于少量用例,或者时效短的用例效果很好,可以节约大量时间而且门槛低,但长期维护的用例不可用。

当然,一切都要基于具体的项目特点。彼之蜜糖,吾之砒霜。

共收到 5 条回复 时间 点赞

点个赞

airtest 的图像识别,是集成到了 robotframework 里面吗?

tigerwu 回复

是的。robot 本质是 python,把图像识别元素位置的代码整理一下导入 robot 就可以了

naughtz 回复

赞,我也正在做,只是现在遇到点问题。

我们也是使用 PO 模式,你可以看下这个工具:https://testerhome.com/topics/30503 可以自动帮你管理页面对象,不过是基于 json 的, 结构也很清晰。我们自己使用过程中能感受到节省很多时间。有小问题还是可以实时的单命令调试 selenium。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册