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

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

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

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

这个水平可以了

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

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

还是单元测试好。。。。

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

偏题了

探索性测试怎么理解那

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

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

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

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

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

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

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

说的太对了

case 这么多啊...

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

h5 怎么做？

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

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

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

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

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

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

先 UI ，没有 pass 的，再手工这样行不行？

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

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

默默点赞，一针见血。

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

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

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

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

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

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

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

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

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

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

你们尝试后，放弃的主要原因是啥？后面有做平台吗？

1、用 web 平台编写代码，稳定性太差
2、平台本身质量堪忧

现在直接培养测试用 python 写脚本，平台做触发、管理、报告展示

等于是平台来管理脚本，你们是已经实践过 web 平台编写脚本吗？

git 管理脚本，web 平台写脚本，本来就挺 low 的，而且不靠谱。只不过当时大家不信，非得试试。
结果惨不忍睹

确实如此，用 web 平台写代码实用性不强，而且很多开源的平台也是如此，二次开发还得去研究别人的源代码。简单的校验还可以，但是复杂的场景就不行了。web 平台做调度，展示挺不错，目前正考虑向这方面研究

还有个问题想请教一下各位，web 平台做调度、展示功能，各位大佬，当涉及到通过 jenkins 做 CI/CD 时如何去对接，有没有思路

我们目前是封装成 http 接口对接

好的，谢谢大佬

UI 自动化的真谛就是，写用例脚本，平台整合用例自由调度，手机用例执行信息。我已经整合好了，嘻嘻

上图吧老铁

2500+ 左右 UI 冒烟用例 通过率基本维持在 85~90% 之间 你说的指标很难达到

UI 测试受到各方面的影响太多了
而且很多用例之间有依赖的 前面的挂一个 后面的全 skip

你这个 85-90% 是通过率还是稳定性呢？你们的冒烟测试 2500+ 用例，回归用例有多少呢？

达到了

是指的通过率 是包括了失败和跳过的一起计算的，稳定性这个指标不好用数字量化吧。
2500+ 全是回归用例，现在大概有 430 个页面。 失败 case 里面 真正是功能有问题的 大概 20~30% 左右
有时候可能同一个问题引起很多页面测试失败

环境不稳定，那就改善环境让它尽可能稳定啊！
也不需要非常稳定啊，自动化运行有重试机制，好的重试机制是当前用例失败后并不立即重试，而是接着跑下一个用例，因为立即重试失败概率很大，失败用例每次重试都会是不同的时间段。比如设定最多重试 3 次，每次在不同的时间段全都撞上环境刚好不稳定的几率如同彩票头等奖，真全撞上了说明环境不是不稳定，是烂。
这些分布式系统本身就有抖动，你说的是你们的产品吗？如果是产品，这个抖动超出产品设计标准就是 bug，出 bug 的用例不用自动化。
case 本身不稳定，我们以前是要对 case 提 bug 的，以便督促 case 的 owner 修复。
UI 交互很恶心，这个具体怎么说呢？

ui 就是有点技术门槛的