先说一下我们公司的情况
1，移动自动化一做了 3 年多，目前大部分做 Android，iOS 很小一部分,Android 自动化覆盖率最多达到 90%；
2，使用 Appium+RF 作为自动化框架，自行研发了 Web 版的 RF 进行案例管理、执行、调度、报告统计等功能；
3，主要做 UI 自动化，App 的接口几乎没做；
想了解一下，业内各位大佬都是使用什么技术来做移动端自动化的？
楼主，你们 app UI 更新频繁吗？我们 app 很频繁变更 name,id,xpath。
appium 换成 1.7 后用着很不稳定，都放弃了，转战 uiautomator2。
接口都没做 我不相信你的 UI 自动化能有多好...
接口一定是 UI 的基础，要不然更像空中楼阁
心向东
回复
指的是与 App 端的 http 接口没做，我们后台主机接口还是都做了都。
目前 ui 自动化的效果依然不明显，请教下大佬，你们用什么工具做的 app 自动化？
你们版本 ui 这么稳定？case 量有多少？覆盖率 90% 这个我表示质疑。
IOS 自动化，有人用 AutomatorX 的么？效果如何？
最大的收益就是几乎全部测试人员都学会了做 ui 自动化！
除了发现 bug，质量保证也是一种收益吧。
在上线之前自动化回归，保证质量。
我们的项目比较分散，案例数量也很多，bug 数没统计
如果是为了发现更多 bug ，推荐用探索性测试。
自动化的用处主要是提高回归测试的效率，适用于需要频繁回归的项目。更新非常慢的项目，我觉得其实引入的必要性不大。
东宫娘娘烙大饼， 西宫娘娘剥大葱。
没见过几个讲技术架构的文章会提到组织架构，为啥咧。
90% 的覆盖率是指什么覆盖率，测试用例，还是系统代码覆盖率？
我们 web 项目人工测试后端代码覆盖率 70% 多（研发有垃圾代码没有处理的，还有很多未知异常等客观原因），ui 自动化实现后端代码覆盖率 53%
来参加 7 月份的大会吧，就会知道了吧~
楼主能否开源分享分享你们的框架，也让咱学习学习
陈恒捷
回复
这个观点赞同，现在大家一味去追求自动化，忽略了如何找出更多的 BUG，探索式测试正当适用！但很多人这块不入门，这需要相当的技术积累、经验才能有高效的探索测试；
water
回复
那是基于 google 的源码做的二次开发，我以前写过约 1000 条自动化用例，写到吐了，跑到最后跑上个三天三夜，也没发现一个 BUG，不知是高兴还是悲伤
工具么基本上都是基于 ui2.0 的，没太大差别
water
回复
这类伪随机测试工具只有利用机器实现点点，发现 BUG 的不确定性较大，而探索测试重点在于挖掘代码深层逻辑层面和系统层面的 BUG，更具备价值，目前要做好探索测试是无法完全依赖自动化，目前的自动化只是把现在有测试用例固化重用，毕竟人工智能还在初级阶段，探索测试需要的是测试人员的智慧，结合技术积累，有效思考，发掘系统潜在的薄弱点和风险点，做探索测试；这方面的介绍可以看之前微软的架构师 James Whittaker 写的《探索式软件测试》
我们基于 SDK 打点的自动化测试（极少的 UI 界面），覆盖率只能达到 15% 左右，可节省回归测试时间大概是 30%，你们 UI 自动化 90% 是怎么做到的？
bauul
回复
找了个质量一般的产品，翻了一下提交历史。500 次提交里，修复缺陷的提交 102 个。可以归类为一个流程里第三次出现的缺陷，9 个。
如果在这个缺陷第二次出现的时候编写一条自动化用例，那这 500 次执行可以发现 9 个 bug。
这是回归测试的目的，原来正常的功能不应该因为新上的功能而出现问题bauul
回复
倒不是想说这个，如果不是每次提交都跑一遍测试。
比如第 15 个提交引入了缺陷，第 50 次提交时开发发现了这个缺陷在第 51 次提交把它修复了，然后又发现第 20 到 25 次提交的代码是在错误的基础上开发的，所以用第 52 次提交重写了这部分。最后提测的时候跑测试，一切正常。
比如发生这种对话的时候，“这里功能怎么和以前不一样？”“你记错了吧，一直都是这样”
比如，开发没有提交过代码，第一次构建测试通过，第二次构建发现测试失败。发现构建策略是第三方库只限制大版本，小版本自动升级。如果小版本也限制死，就享受不到三方库升级带来的好处，比如重要的安全漏洞修复。
我觉得在选哪些场景做自动化的时候；需要在实现难度和测试效果之间取舍的时候；碰到那些 “这不是 Bug，是外部原因造成的” 情况时，判断到底是不是 “外部原因” 要不要采取措施。都很难很难。