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

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

2 重视度不够

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

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

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

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分的一劳永逸的解决方案。以此吸引了一大波人进入这个领域,看了一段伪代码就说自己会了,完整地写了一个用例就说自己精通了,在某个公司做着半吊子的项目就说自己是专家了。

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

我们要不要做呢?

要不要做呢?

……

最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走!

最后

大厂面试问深度,小厂面试问广度,如果有同学想进大厂深造一定要有一个方向精通的惊艳到面试官,还要平时遇到问题后思考一下问题的本质,找方法解决是一个方面,看到问题本质是另一个方面。还有大家一定要有目标,我在很久之前就想着以后一定要去大厂,然后默默努力,每天看一些大佬们的文章,总是觉得只有再学深入一点才有机会,所以才有恒心一直学下去。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值