通用技术 用数据说明为什么要减少 UI 自动化的比例

国文 · December 29, 2015 · Last by taozitao replied at November 21, 2018 · 2344 hits
本帖已被设为精华帖!

最近我产品的持续集成通过率大幅下降,刚好同事提取数据做了个dashboard,正好可以用来说明为什么要减少UI自动化比例。

先上一张Greenness的图,可以看出持续集成的成功率下降很厉害。

顺便提下我的产品:

  1. 过去是每提交一个changelist(简称CL)就持续集成一次,后来因为资源紧张,改成若干CLs跑一次持续集成,
  2. 持续集成中包含了所有的自动化测试,UT、E2E、API、UI等等,
  3. 每周发布选取的截止CL是取持续集成中前三个小时跑绿色的,如果持续集成一直红色,那么只能手动选取,这个版本的稳定性也大打折扣

接下来对各种测试进行分离统计,把UI的也就是webdriver的测试放一块,其他测试放一块。

非UI测试失败比例,通过率很高吧,效果还是很满意的


再看看失败原因

再看看惨不忍睹的UI自动化吧

失败比例

除了失败还有Flaky的比例

失败的原因

最后还是金字塔的图

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 31 条回复 时间 点赞

能接口自动化搞定的不要做UI自动化。。。

赞同用数据说话,UI自动化有其存在的理由,如何运用恰当是需要思考的

倒金字塔

—— 来自TesterHome官方 安卓客户端

求解,在分层测试体系中,对于API这层的代码稳定性 一般采用什么样的测试策略去保证呢?

不是应该从给项目/公司带来的实际收益来评判吗?

标题应该改为“用数据说明为什么要减少持续集成中 UI 自动化的比例”。楼主这样说有以偏概全之意。

#4楼 @alfor 你指的不稳定如果是发生变更的话,通常情况的接口都是增量变更,改逻辑通常情况下都是新起接口,老接口仍然要向旧版本兼容,所以通常api自动化只需要跟随新版本补充新接口即可。

#2楼 @quqing 赞同,存在即合理,但我个人觉得UI自动化测试不适合接入快速迭代的CI中,目前我们的做法是通过友好的前端,让响应变更速度更快,成本更低,然后交给业务测试团队自己按需去跑。

所以异步才是正途(滑稽脸

能不能对失败的原因做一下总结?

国文 #11 · December 31, 2015 作者

#6楼 @uncleleung ,我这没有减少持续集成中的UI自动化;最早UI自动化是测试用例能自动的都自动,那样比例可能会到80%甚至更高,目前我们选取p0/p1的用例来做自动化,大概是30%的比例,加入到持续集成后,发现UI自动化运行的时间过长(在google每个项目持续集成的时间会有一个限制),从失败原因可以发现元素找不到和超时是2大主要原因。现在我们的做法是分成2个持续集成,1个是非UI的另一个是UI的。

国文 #12 · December 31, 2015 作者

#10楼 @actionwind ,直接看图片,很直观。

#12楼 @oscarxie 是什么造成了这些问题?是测试代码没写好呢,还是被测程序存在bug,不能说测试不通过就怨到自动化测试的头上吧

国文 #14 · January 01, 2016 作者

#13楼 @actionwind ,API的没什么问题,是一些资源上的。Webdriver的我们统一用Byid的方法,每个元素都有固定的debugid,偶尔才会有元素定位不到的问题,主要是在timeout方面,目前我们在分离一些cases,过去一些case写得比较大,另外webdriver从15年开始已经都由开发自己编写,但是UI碰到年度的改版就会出现大面积失败,所以我们减少UI自动化的投入。
另,我的帖子没有任何地方提到怨自动化测试的方面,不知道哪里看出的,自动化测试包括了所有测试,不仅仅是UI的,我贴图里的Failure reason很直观。

#14楼 @oscarxie 比如说那个排第一的失败原因,看它写的大意是找不到断言中所规定的元素,也就是说测试的实际结果和期望结果不符,如果不是测试脚本写的有问题的话,那应该就是这种ui自动化测试在被测程序中找出大量的问题来了,那么恰恰说明这种ui自动化测试是很有必要的吧。看你的解释说主要是timeout方面的问题,那是不是说明被测程序在性能上跟不上?还有ui改版的时候出现这样的大面积失败,那还是回到那个问题:到底是ui测试脚本没跟着改好呢,还是被测程序改版的时候改出问题了?如果是前者,那就应该追究脚本编写者的责任,如果是后者,那应该给脚本编写者记上一功了,呵呵。总之,不论是以上哪种情况,好像都不应该说通过减少ui自动化来解决吧

#15楼 @actionwind ,你提到的这些在理论上都对,但实践起来却不是这么回事,考虑下维护成本吧。

#16楼 @oscarxie 其实,软件测试的目的之一就是为了降低总体的开发成本,因为问题越早发现,它的解决成本就越低,所以尽早的测试是必要的。现在你所遇到的问题是:你认为UI自动化测试给你的工作造成了巨大的麻烦(看你整篇文章的论调大致是这样子的)。但实际上,给你造成麻烦的根源其实是被测程序所存在的问题过多,而UI自动化测试找到了那些问题。从这个看来,应该说你们公司的UI自动化测试做得相当的好了,很多公司的自动化测试工作基本找不出什么问题来的。看来,软件质量保证工作独立成体系是很必要的,否则,如果让开发人员主导的话,测试做得好反而会被认为是“麻烦制造者”而被削弱甚至砍掉。

#17楼 @actionwind 我觉得你应该了解下 flaky 的意思。

另外,建议读下 http://article.yeeyan.org/view/66324/453360/。case 不稳定不代表被测软件有问题。我觉得这个才是 @oscarxie 想说的吧?

#17楼 @actionwind

  1. 元素变更并不能说明被测程序的不好也不说明测试脚本不好,恰好说明维护成本高。我们让开发来参与webdriver的编写可以让开发了解UI自动化,提高可测试性,比如过去开发对元素不命名或不给ID,通过编写webdriver,有了开发的配合,加上debugid,可以让元素定位更便利,但这种行为并不是每个开发都能做到或者说一直坚持。
  2. timeout正好说明webdriver不好的一面——耗时,也无法体现被测程序的好坏以及测试脚本的好坏。UI自动化可以很好的模拟用户行为,但是在前端很多关联依赖的情况下,一个用例跑完用时很长,可以增加等待时间,不过会极大的消耗硬件成本。
  3. 关于Flaky,@chenhengjie123 已经提到,在做浏览器兼容性测试会经常碰到,各个浏览器速度不一样。
  4. 测试团队如何在资源有限的情况下更高效,比如我的测试团队只有3个人(Google里开发测试比10比1很常见),测试团队参与各种类型的测试,那么在UI自动化应该投入多少呢,在实践中需要不断调整,你是愿意让你的团队成员每天陷入维护UI自动化还是做更多其他类型的测试。
  5. 软件质量是一个全员的工作,不是独立的,测试无法保证质量,测试提供及时的反馈和警示风险,开发才能保证质量,在明确的需求下,开发的代码质量是最关键的,如何让开发认识到质量的重要性,推动开发的质量意识,是一个长期的工作。

UI自动化的case维护成本是比较高,那么应该思考下如何降低case的维护成本了。可以看看 https://testerhome.com/topics/3394 海豚的思路,基于录制,自动生成测试脚本,对于小白用户可以基于录制去完成,对于高级用户可以更深层次的写测试case。
现在我们遇到最大的问题,是由于数据上的不稳定性(随机)导致UI的变动,使得录制的pagediff diff差异比较多。现在过渡的办法是做测试桩,将接口返回的数据固定化,达到UI界面的稳定。

1、脚本写太烂,现在Framework都是wait for idle的吧,何来延时一说
2、覆盖率,覆盖率,覆盖率!这玩意主功能回归覆盖一下就完事儿了。。 80%您太开玩笑了
3、正确使用的话维护成本还行,凑合

ui测试做得更轻,让它更专注在界面操作和渲染方面的验证,不要寄希望去用它检查后端功能,commen sense吧,需要用数据来说话?

ui自动化 也是有些必要性,咳咳看什么业务,某些消息是需要打开某个ui才可以下发(保存,读取,变更),直接接口测试当然也行,测试模拟真实操作。 《---自动化考虑拆分业务吧
一些ui伸缩性测试,有必要性。
单纯读取元素就意义不大,不过还是需要的。
补充:如果按多少行用例产出bug数量,级别和bug类型重复来看,ui产能就真不怎么样。

分层自动化测试

#19楼 @oscarxie

大神们,其他我不敢妄言,但是关于Flaky,你们的流程是怎样的呢?难道一旦UI级别的自动化报了错抛了异常,就直接丢给开发?例如Web的UI自动化,Chrome和Firefox在表现上必定有差异,那么不同的浏览器执行的脚本必定是有细微差别的两套。假设用Firefox跑了Chrome的脚本导致失败,第一层次的把关人员应该是测试人员——去确定问题是由软件造成的(回归测试发现Bug)还是Case本身的不稳定性。手工复现脚本中的步骤应该永远是第一步——打开Firefox确认Bug。我相信作为测试人员——脚本的开发者应该很容易确定是否flaky,对吧?

个人认为UI自动化绝对不适合所有的企业,当然也不是所有企业都不适合。是否开展UI自动化应该从一开始就有一个基本的判断;如果实施,重中之重就是不能有过于刻板的生产线。否则就会出现题主数据中所反应的问题。

Author only
国文 #28 · November 20, 2018 作者
taozitao 回复

团队里每个人都有机会做,没有只做自动化的人

29Floor has been deleted
Author only
国文 #31 · November 21, 2018 作者
taozitao 回复

这个你需要根据工作量来计算了,那么多客户端加上各种设备,几十号人至少了

Author only
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up