灌水 您公司的 UI 自动化稳定性达到 95% 了吗？大家还在泥沼中挣扎吗？
目前的技术和框架太多了，但是实践效果还是不够好，看了看前辈和大佬以前的实践和理论分享，收获满满。
参考 京东技术的资料，并结合本人的经验，非常同意其中提到的关于 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 的失败。 都是因为不稳定。
大佬最近分享很多，有什么新的探索吗？
其实，不用当回事，只有当事人知道情况到底怎么样。 好多公司还没到那种级别，公司就死了。
老模块稳定性在 95% 以上，加上自定义的重跑机制，感觉还不错。新模块还在调优中，每个模块覆盖深度在 70% 左右（剩余部分交给人工）
我们也要求 95% 以上了。。。
敏捷推崇有效的快速反馈 fast feedback, 所以按照测试金字塔，做好 TDD，单元测试，CodeReview 来保障软件内建质量。集成 API 测试，关键路径的 UI 验证测试来保障软件外部质量。释放聪明的测试人员双手，用来做探索性测试，以及全流程质量保障工作。
只知道昨晚猎豹涨势喜人。。。
zhanglimin
回复
这玩意就是个概念，7、8 年前开始说 DEVOPS 的时候就有了。
但是好像没有好的方法论支撑，大概率只能落在 PPT 里。
我们这边 UI 自动化只是用于指定场景，接近 100% 自动化的程度
相信我，开放出来的框架大多比较渣，UI 自动化这块需要大量的实际实践积累的，testin 做的很好了，就是不开源 ~
appium 已经很好了，但就是个理想国，貌似没有经过大量设备的检验，尤其是国内的设备，某些场景还偏偏很明显，却不去解决，比如权限框，明显可以设计一个通用性适配的监听，官方却始终充耳不闻。
95% 确实很难，自动化通过率影响的因子在我看来就是各种连接不稳定，usb，pc 与手机的 socket 等等
很多不通过是因为确实检测到问题了，也应该算自动化通过，所以这个通过率标准并不是单纯的执行通过百分比
基本上 UI 自动化稳定性超过 95% 的地方， 要么是用例太少， 要么就是把不稳定的直接删除了。 我们之前维护过几千多的 UI 自动化测试用例， 后来稳定性在 97%。 但是你要知道我们曾经删除了上千条不稳定的测试脚本。 想不删用例达到 95% 很那。 我现在的项目目前是 1700 条 UI 自动化测试用例。 这一次我们没有删除不稳定的 case，每一次跑少说也是几十个 case 的失败。 都是因为不稳定。
Cypress 试用中，目前感觉良好。仅限 web 和 H5
孙高飞
回复
飞哥，有做失败用例的问题分类吗？因为我发现有时候是框架的不稳定，有时候是应用不稳定导致的。
你们的重试机制是怎么样的？我们主要是 APP，你们主要是 WEB 吗？
在路上
回复
我们主要是 web，我们大多数是因为环境不稳定。 因为我们的产品关系。 会起非常多的分布式任务， 这些分布式任务有 hive 的， 有 spark 的， 有 k8s 的。 环境依赖很重，这些分布式系统本身就有抖动， 比如 k8s 某个节点出现点问题， 可能就有一些 case 直接失败， hadoop 如果出现 IO 抖动， 可能任务就超时了， 训练某些模型的时候，需要从外网下载数据， 如果当时网络卡了一点， 可能也失败了。 当然还有一些 case 就是不稳定， 有些 UI 交互很恶心， 就是非常不稳定的。
在路上
回复
额，我不是写过么。 就是那个什么 UI 自动化军规和常用设计模式。 我们的 UI 自动化真的没别的花样了。 就是老老实实的写代码。 说有花样也就是 grid 是启动在 k8s 里的， 可以并发几百个浏览器进行测试。
先 UI ，没有 pass 的，再手工这样行不行？
在路上
回复
现在很多自动化平台，在填写请求的 url，参数，header，响应内容断言等的时候，一个个的选择下拉项，填写参数名，参数值，太麻烦，很浪费时间。感觉这个是很多人不愿意用平台的其中一个原因
做平台，KPI，造轮子，爽歪歪
在路上
回复
我明白了， 你想做个统一的页面把所有自动化测试类型集成进去。 在这个上面操作。 这个可以啊，纯 web 开发的领域了。 你们想怎么搞就能怎么搞了~
直接用一个 Jenkins job 去调用自动化 case 不行吗
将写脚本的过程 UI 化，我们也简单的尝试过，页面上输入一些简单关键字，或者拾取页面元素，后台根据页面输入解析关键字执行相应的逻辑，简单的页面检查还行。复杂的就搞不定了，后来还是回归全部手写脚本上。
青谷
回复
1、用 web 平台编写代码，稳定性太差
2、平台本身质量堪忧
现在直接培养测试用 python 写脚本，平台做触发、管理、报告展示
在路上
回复
确实如此，用 web 平台写代码实用性不强，而且很多开源的平台也是如此，二次开发还得去研究别人的源代码。简单的校验还可以，但是复杂的场景就不行了。web 平台做调度，展示挺不错，目前正考虑向这方面研究
还有个问题想请教一下各位，web 平台做调度、展示功能，各位大佬，当涉及到通过 jenkins 做 CI/CD 时如何去对接，有没有思路
UI 自动化的真谛就是，写用例脚本，平台整合用例自由调度，手机用例执行信息。我已经整合好了，嘻嘻
2500+ 左右 UI 冒烟用例 通过率基本维持在 85~90% 之间 你说的指标很难达到
UI 测试受到各方面的影响太多了
而且很多用例之间有依赖的 前面的挂一个 后面的全 skip
达到了
Thirty-Thirty
回复
是指的通过率 是包括了失败和跳过的一起计算的，稳定性这个指标不好用数字量化吧。
2500+ 全是回归用例，现在大概有 430 个页面。 失败 case 里面 真正是功能有问题的 大概 20~30% 左右
有时候可能同一个问题引起很多页面测试失败
孙高飞
回复
环境不稳定，那就改善环境让它尽可能稳定啊！
也不需要非常稳定啊，自动化运行有重试机制，好的重试机制是当前用例失败后并不立即重试，而是接着跑下一个用例，因为立即重试失败概率很大，失败用例每次重试都会是不同的时间段。比如设定最多重试 3 次，每次在不同的时间段全都撞上环境刚好不稳定的几率如同彩票头等奖，真全撞上了说明环境不是不稳定，是烂。
这些分布式系统本身就有抖动，你说的是你们的产品吗？如果是产品，这个抖动超出产品设计标准就是 bug，出 bug 的用例不用自动化。
case 本身不稳定，我们以前是要对 case 提 bug 的，以便督促 case 的 owner 修复。
UI 交互很恶心，这个具体怎么说呢？