为什么UI自动化难做?—— 关于Selenium UI自动化的思考

在快速迭代的产品、团队中,UI自动化通常是一件看似美好,实际"鸡肋"(甚至绝大部分连鸡肋都算不上)的工具。原因不外乎以下几点:

1 效果有限

通常只是听说过,就想去搞UI自动化的团队,心里都认为「UI自动化」等于「减少人工 提高效率」,这固然没什么大错,但是他们也会认为减少的人工成本和提高的效率会非常高,所以会对UI自动化寄予非常高的期望,这就很有问题了。毕竟现实是很残酷的,UI自动化真实的效果并没有那么好。

这个效果没那么好通常体现在两个方面:

A.本身无法完全满足复杂的业务代码框架

除了ID,Name这些常用元素不足,还有些本身框架就比较复杂,需要对开发有非常高的要求才能比较好地添加需要的信息,比如说VUE,非常好用的框架,封装得非常好的同时也意味着,改造VUE非常困难。更何况还有些前端代码直接是动态生成的,这使本就难搞的自动化雪上加霜。

B.UI自动化仅能就已知的问题做兜底,基本无法检查出新的BUG

有些同学会说,不适用还要强行用,用了不好用还要怪工具,真有你的。确实,第一点是因为被测系统框架本身和Selenium不兼容导致的,但是第二点就是目前自动化都无法逾越的问题。

这个特性是天生的,平常我们自己做测试的时候也知道,很多BUG其实是在测试用例之外发现的,而UI自动化毕竟是一段编码,它无法对超出预设的BUG进行报告,仅能对已知的问题做兜底。

其实兜底能做的好,就已经是非常好了,依然可以为公司和团队提供非常好的帮助,但是除开上述框架层面的原因外,公司层面的原因也非常关键。

2 重视度不够

众多设置了UI自动化岗位的公司,通常情况下,只有1到2位同学用仅一半不到的时间在写自动化脚本,而这些同学被寄予了厚望,希望可以做出一个覆盖面积广、测试通过率高、持续集成稳定、领导拿出去展示倍有面的UI自动化系统。

想想都气抖冷,但是这就是比较真实的现状。而除此之外,大部分招聘UI自动化的公司给出的薪资也较低,普遍在8-20之间(15以上一般都在大厂了)。我们换位思考一下,如果一个公司的主程月薪20K,你觉得这个公司的研发水平是怎么样的?答案不言自喻。有很多同学不服了,你UI自动化测试跑去跟正经开发比,真有你的。我还真就要说了,UI自动化想要落地,招人的标准就要冲着开发水平去招,不然就毫无意义。

当然,给出高工资并且全职做UI自动化的公司并不是没有,可是效果也一言难尽,因为这涉及到了执行层面的内容。

现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:110685036【暗号:csdn999】

3 维护起来太痛苦

自动化要做好,难在维护,这个是很多人都知道的。维护的原因只有一种:需求变更。无论是页面修改、逻辑修改还是底层代码变动导致的维护,其实都可以归结于需求。

每次维护通常分为以下几步:

1.跑全部用例,拿到出错的用例。

2.分析出错用例,找出因为本次修改导致的错误用例。

3.修改用例后复跑,确认没有问题。

4.重复步骤3,直到所有出错用例都修改完。

5.再次跑全部用例,确认没有问题合并代码。如果有问题,重复步骤3和4。

上述步骤已经非常耗时了,通常1到2个人的自动化团队,即使是全职,当用例累积到五六百时,大部分时间都会消耗在维护上,更何况很多都不是全职。耗时耗力,如果改好后能保证效果的话,其实勉强也能接受。但是非常不幸,上述的维护动作,通常是在我们正式跑用例出报告时才会发现有问题,这也导致了我们发出去的报告中的通过率会忽高忽低,没有UI修改时风平浪静,一旦有修改一地鸡毛。

而通过率的波动会导致很可怕的事情:不受信任。试想,你是测试leader或者开发又或者是业务测试同学,当一份自动化测试报告发过来的时候,点开一个错误用例发现是UI修改导致的,点开第二个还是,终于在一堆因为未维护导致的失败用例中找到一个其他原因导致的错误,找你一核对,发现是网络问题。看这份报告的人心态会是怎么样的?

多次这样之后,会关心这份报告的人,都不会记得你成功率是95%时的模样,只会记得成功率是80%时的模样,并给出结论:这东西没什么用。事实上,这还是做得好的情况,毕竟通过率可以达到95%已经非常不错,而市面上绝大部分公司的UI自动化通过率从来没有达到过95%,甚至80%都达不到,试问这样的结果拿出去,给谁看呢?丢谁的人呢?

总结:维护耗心耗力,结果依旧不受信任。

以上三点,是我自己总结的"UI自动化说了这么多年依旧鸡肋"的原因。它目前是一个实际投入100分,产出只有90分,然后还要持续投入越来越高的成本才能继续维持90分产出的东西。 但是却被不了解或者了解也装不了解的人看成是实际投入50分,产出可以到150分的一劳永逸的解决方案。以此吸引了一大波人进入这个领域,看了一段伪代码就说自己会了,完整地写了一个用例就说自己精通了,在某个公司做着半吊子的项目就说自己是专家了。

那么问题来了,它似乎没那么美,我们要不要做呢?

我们要不要做呢?

要不要做呢?

......

END今天的分享就到此结束了,点赞关注不迷路

相关推荐
未来的嗒嘀嗒2 小时前
探秘Sketch及其替代者:设计软件精选指南
ui
测试小小怪下士2 小时前
怎么用Python+selenium自动化生成测试报告
selenium·测试工具·自动化
墨笺染尘缘2 小时前
Unity——对RectTransform进行操作
ui·unity·c#·游戏引擎
牧魂.3 小时前
软件测试入职要求汇总
自动化测试·软件测试·功能测试·接口测试·性能测试
Sweet_vinegar4 小时前
Wireshark
网络·测试工具·安全·wireshark·ctf·buuctf
我非夏日13 小时前
JMeter进阶篇
jmeter
惜.己13 小时前
Jmeter中的配置原件(三)
功能测试·测试工具·jmeter·1024程序员节
綦枫Maple13 小时前
Jmeter基础篇(23)TPS和QPS的异同
数据库·jmeter·oracle
惜.己13 小时前
Jmeter中的配置原件(二)
测试工具·jmeter·1024程序员节
我非夏日13 小时前
JMeter项目实战
jmeter