灌水 您公司的 UI 自动化稳定性达到 95%了吗?大家还在泥沼中挣扎吗?

zailushang · August 20, 2019 · Last by zailushang replied at September 02, 2019 · 3735 hits

目前的技术和框架太多了,但是实践效果还是不够好,看了看前辈和大佬以前的实践和理论分享,收获满满。

参考 京东技术的资料,并结合本人的经验,非常同意其中提到的关于UI自动化的落地指标:
1、用例执行通过率(稳定性): >=95%
2、核心用例覆盖率:100%的覆盖率是基本不可能的。该指标,客观的反应通过自动化手段代替手工劳动的覆盖比例。一味的提高覆盖率是不可取的,保持用例的通过率,提高用例的稳定性是重点。
3、资源投入度:自动化测试需要的是持续资源投入,只有自上而下的推动才能取得更好的效果,体现它该有的作用。

不知道有多少公司的UI自动化达到了95%以上的稳定性,实现了UI自动化的阶段性目标,欢迎大家留言。。。。。。

参考资料详见:
京东技术:《APP的UI自动化测试框架及平台化探索》https://cloud.tencent.com/developer/article/1170543
段念:《自动化测试——敏捷测试的基石》https://www.infoq.cn/article/2010/12/dn-agile-test-2
段念:《敏捷测试推进工作笔记(一)》https://www.infoq.cn/article/agile-test-notebook-1
恒温:《 分层自动化测试概念》https://testerhome.com/topics/125
玄黎:《分层自动化&持续集成 - Alibaba B2B探索之路》http://www.docin.com/p-315021205.html

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
最佳回复

基本上UI自动化稳定性超过95%的地方, 要么是用例太少, 要么就是把不稳定的直接删除了。 我们之前维护过几千多的UI自动化测试用例, 后来稳定性在97%。 但是你要知道我们曾经删除了上千条不稳定的测试脚本。 想不删用例达到95%很那。 我现在的项目目前是1700条UI自动化测试用例。 这一次我们没有删除不稳定的case,每一次跑少说也是几十个case的失败。 都是因为不稳定。

共收到 42 条回复 时间 点赞

大佬最近分享很多,有什么新的探索吗?

别,小弟最近在看十年前的大佬文章,发现现在还没做到人家当面的程度,太惭愧了

其实,不用当回事,只有当事人知道情况到底怎么样。 好多公司还没到那种级别,公司就死了。

老模块稳定性在95%以上,加上自定义的重跑机制,感觉还不错。新模块还在调优中,每个模块覆盖深度在70%左右(剩余部分交给人工)

小怪兽 回复

这个水平可以了

我们也要求95%以上了。。。

恒温 回复

我昨晚还在看你13年的帖子😂

恒温 回复

还是单元测试好。。。。

只知道昨晚猎豹涨势喜人。。。

Try ...Execpt 回复

偏题了

wywincl 回复

探索性测试怎么理解那

zhanglimin 回复

这玩意就是个概念,7、8年前开始说DEVOPS的时候就有了。
但是好像没有好的方法论支撑,大概率只能落在PPT里。

我们这边UI自动化只是用于指定场景,接近100%自动化的程度

15Floor has been deleted

相信我,开放出来的框架大多比较渣,UI自动化这块需要大量的实际实践积累的,testin做的很好了,就是不开源 ~

appium已经很好了,但就是个理想国,貌似没有经过大量设备的检验,尤其是国内的设备,某些场景还偏偏很明显,却不去解决,比如权限框,明显可以设计一个通用性适配的监听,官方却始终充耳不闻。

95%确实很难,自动化通过率影响的因子在我看来就是各种连接不稳定,usb,pc与手机的socket等等
很多不通过是因为确实检测到问题了,也应该算自动化通过,所以这个通过率标准并不是单纯的执行通过百分比

simple 回复

稳定性怎么样?用什么框架做的安卓自动化啊

基本上UI自动化稳定性超过95%的地方, 要么是用例太少, 要么就是把不稳定的直接删除了。 我们之前维护过几千多的UI自动化测试用例, 后来稳定性在97%。 但是你要知道我们曾经删除了上千条不稳定的测试脚本。 想不删用例达到95%很那。 我现在的项目目前是1700条UI自动化测试用例。 这一次我们没有删除不稳定的case,每一次跑少说也是几十个case的失败。 都是因为不稳定。

cmlanche 回复

说的太对了

孙高飞 回复

case这么多啊...

Cypress 试用中,目前感觉良好。仅限web 和 H5

回复

h5怎么做?

孙高飞 回复

飞哥,有做失败用例的问题分类吗?因为我发现有时候是框架的不稳定,有时候是应用不稳定导致的。
你们的重试机制是怎么样的?我们主要是APP,你们主要是WEB吗?

zailushang 回复

我们主要是web,我们大多数是因为环境不稳定。 因为我们的产品关系。 会起非常多的分布式任务, 这些分布式任务有hive的, 有spark的, 有k8s的。 环境依赖很重,这些分布式系统本身就有抖动, 比如k8s某个节点出现点问题, 可能就有一些case直接失败, hadoop如果出现IO抖动, 可能任务就超时了, 训练某些模型的时候,需要从外网下载数据, 如果当时网络卡了一点, 可能也失败了。 当然还有一些case就是不稳定, 有些UI交互很恶心, 就是非常不稳定的。

thanksdanny 回复

TO B的业务产品形态相对稳定, 节奏相对慢一些。 比较好积累自动化测试用例

孙高飞 回复

飞哥,有时间了,能不能写写你们的自动化平台和框架设计,特别想取取经

zailushang 回复

额,我不是写过么。 就是那个什么UI自动化军规和常用设计模式。 我们的UI自动化真的没别的花样了。 就是老老实实的写代码。 说有花样也就是grid是启动在k8s里的, 可以并发几百个浏览器进行测试。

孙高飞 回复

我觉得UI自动化平台,就像一个产品一样,产品逻辑其实没有那么简单

先UI ,没有pass的,再手工这样行不行?

zailushang 回复

为什么你们非要把自动化测试弄出个平台来。。。。。。还要弄的像个产品一样。。。。

孙高飞 回复

因为还有很多数据统计、数据展示的,除了自动化,其他的专项测试封装到了web平台中,做得不好用,确实没人用😂

孙高飞 回复

默默点赞,一针见血。

zailushang 回复

现在很多自动化平台,在填写请求的url,参数,header,响应内容断言等的时候,一个个的选择下拉项,填写参数名,参数值,太麻烦,很浪费时间。感觉这个是很多人不愿意用平台的其中一个原因

做平台,KPI,造轮子,爽歪歪

黑山老妖 回复

对,我们现在从UI自动化开始,要全部写脚本了,将写脚本的过程UI化是行不通的。
但是其他可以集成的工具,是需要集成到平台上的

zailushang 回复

我明白了, 你想做个统一的页面把所有自动化测试类型集成进去。 在这个上面操作。 这个可以啊,纯web开发的领域了。 你们想怎么搞就能怎么搞了~

直接用一个Jenkins job去调用自动化case不行吗

loshu2003 回复

除了自动化,还有各类测试工具的开发和集成

将写脚本的过程UI化,我们也简单的尝试过,页面上输入一些简单关键字,或者拾取页面元素,后台根据页面输入解析关键字执行相应的逻辑,简单的页面检查还行。复杂的就搞不定了,后来还是回归全部手写脚本上。

hello 回复

我们也是去年尝试了一年,现在全部回归手动写脚本了

zailushang 回复

平台做成从web端写用例,就是要做成傻瓜式给不懂代码的人用的,用起来太繁琐
平台做集成、调度、统计和展示会好一点

Night 回复

是的,平台做集成、调度、统计和展示会好一点

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