移动测试基础 交流一下,各位公司都使用什么移动自动化技术?

water · 2018年05月03日 · 最后由 bauul 回复于 2018年05月10日 · 101 次阅读

先说一下我们公司的情况
1,移动自动化一做了 3 年多,目前大部分做 Android,iOS 很小一部分,Android 自动化覆盖率最多达到 90%;
2,使用 Appium+RF 作为自动化框架,自行研发了 Web 版的 RF 进行案例管理、执行、调度、报告统计等功能;
3,主要做 UI 自动化,App 的接口几乎没做;

想了解一下,业内各位大佬都是使用什么技术来做移动端自动化的?

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

楼主,你们 app UI 更新频繁吗?我们 app 很频繁变更 name,id,xpath。
appium 换成 1.7 后用着很不稳定,都放弃了,转战 uiautomator2。

蓝蓝 回复

appium1.6.5 是这几个版本中比较稳定的一个。

接口都没做 我不相信你的 UI 自动化能有多好...

心向东 回复

那么问题来了,dong 哥,UI 自动化怎么才算好

心向东 回复

接口没做,是开发框架的限制

接口一定是 UI 的基础,要不然更像空中楼阁

jhh 回复

我们也想做,真心做不了唉~~理论谁都知道。作为渠道产品,大部分逻辑集中在前端,接口能测的东西反而很少,具体问题具体分析。

心向东 回复

指的是与 App 端的 http 接口没做,我们后台主机接口还是都做了都。
目前 ui 自动化的效果依然不明显,请教下大佬,你们用什么工具做的 app 自动化?

你们版本 ui 这么稳定?case 量有多少?覆盖率 90% 这个我表示质疑。

water #11 · 2018年05月04日 Author
0x88 回复

不要纠结这个了 STO
请问下你们公司的移动自动化使用什么工具做的?

IOS 自动化,有人用 AutomatorX 的么?效果如何?

water 回复

之前公司用的是 appium 与 qtaf,用例、任务调度什么的都是自研。

bauul 回复

别把 ui 测试看得很重要,ui 更多的是当做冒泡测试,投入与产出比太低了。

15楼 已删除
water #16 · 2018年05月04日 Author

最大的收益就是几乎全部测试人员都学会了做 ui 自动化!

17楼 已删除
water #18 · 2018年05月04日 Author

除了发现 bug,质量保证也是一种收益吧。
在上线之前自动化回归,保证质量。
我们的项目比较分散,案例数量也很多,bug 数没统计

如果是为了发现更多 bug ,推荐用探索性测试。

自动化的用处主要是提高回归测试的效率,适用于需要频繁回归的项目。更新非常慢的项目,我觉得其实引入的必要性不大。

东宫娘娘烙大饼, 西宫娘娘剥大葱。
没见过几个讲技术架构的文章会提到组织架构,为啥咧。

90% 的覆盖率是指什么覆盖率,测试用例,还是系统代码覆盖率?

我们 web 项目人工测试后端代码覆盖率 70% 多(研发有垃圾代码没有处理的,还有很多未知异常等客观原因),ui 自动化实现后端代码覆盖率 53%

来参加 7 月份的大会吧,就会知道了吧~

water #23 · 2018年05月07日 Author
enjoysft 回复

我们是前端 UI 自动化率比较高。后端服务器的接口大部分覆盖了。
你们用的 UI 自动化框架是啥?

water #24 · 2018年05月07日 Author
恒温 回复

在北京好远 TAT
深圳有没有分会场?

楼主能否开源分享分享你们的框架,也让咱学习学习😄

water #26 · 2018年05月07日 Author
枫叶 回复

公司不允许 STO。。。
就是使用 easyUI + JFinal 开发的,难度不大,很多公司都自己写过类似的。例如卡总他们就有 @carl

water 回复

好吧,难度不大就自己研究研究,有问题就请教你哈

陈恒捷 回复

这个观点赞同,现在大家一味去追求自动化,忽略了如何找出更多的 BUG,探索式测试正当适用!但很多人这块不入门,这需要相当的技术积累、经验才能有高效的探索测试;

water 回复

那是基于 google 的源码做的二次开发,我以前写过约 1000 条自动化用例,写到吐了,跑到最后跑上个三天三夜,也没发现一个 BUG,不知是高兴还是悲伤
工具么基本上都是基于 ui2.0 的,没太大差别

bauul 回复

如果只写一条用例,每次代码提交之后就跑,一千次提交之后能发现 Bug 吗?

黑水 回复

能不能发现问题和提交方式没什么关系吧?

water 回复

也是用的 appium

water #33 · 2018年05月08日 Author
在路上 回复

探索性测试除了 App Crawler,还有别的工具推荐吗?

water 回复

这类伪随机测试工具只有利用机器实现点点,发现 BUG 的不确定性较大,而探索测试重点在于挖掘代码深层逻辑层面和系统层面的 BUG,更具备价值,目前要做好探索测试是无法完全依赖自动化,目前的自动化只是把现在有测试用例固化重用,毕竟人工智能还在初级阶段,探索测试需要的是测试人员的智慧,结合技术积累,有效思考,发掘系统潜在的薄弱点和风险点,做探索测试;这方面的介绍可以看之前微软的架构师 James Whittaker 写的《探索式软件测试》

water #35 · 2018年05月08日 Author
在路上 回复

膜拜大佬!

我们基于 SDK 打点的自动化测试(极少的 UI 界面),覆盖率只能达到 15% 左右,可节省回归测试时间大概是 30%,你们 UI 自动化 90% 是怎么做到的?

water #37 · 2018年05月08日 Author
simple 回复

全员自动化,完成手工案例之后就写自动化案例。或者直接写自动化案例,替代手工案例编写。

bauul 回复

找了个质量一般的产品,翻了一下提交历史。500 次提交里,修复缺陷的提交 102 个。可以归类为一个流程里第三次出现的缺陷,9 个。
如果在这个缺陷第二次出现的时候编写一条自动化用例,那这 500 次执行可以发现 9 个 bug。

黑水 回复

这个理解挺好,👍 这是回归测试的目的,原来正常的功能不应该因为新上的功能而出现问题

water 回复

产品形态不知道是什么样的,不好去评判。如果 UI 自动化能达到 90%,我只能惊叹你们产品的稳定性很好!

bauul 回复

倒不是想说这个,如果不是每次提交都跑一遍测试。
比如第 15 个提交引入了缺陷,第 50 次提交时开发发现了这个缺陷在第 51 次提交把它修复了,然后又发现第 20 到 25 次提交的代码是在错误的基础上开发的,所以用第 52 次提交重写了这部分。最后提测的时候跑测试,一切正常。
比如发生这种对话的时候,“这里功能怎么和以前不一样?”“你记错了吧,一直都是这样”
比如,开发没有提交过代码,第一次构建测试通过,第二次构建发现测试失败。发现构建策略是第三方库只限制大版本,小版本自动升级。如果小版本也限制死,就享受不到三方库升级带来的好处,比如重要的安全漏洞修复。

我觉得在选哪些场景做自动化的时候;需要在实现难度和测试效果之间取舍的时候;碰到那些 “这不是 Bug,是外部原因造成的” 情况时,判断到底是不是 “外部原因” 要不要采取措施。都很难很难。

黑水 回复

感觉问题被搞复杂了吧,功能是不是和以前一样,这个不是靠谁的记忆,应该是产品或需求定义的
至于构建策略,这个需要慢慢摸索,怎么做比较好了

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册