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

water · May 03, 2018 · Last by bauul replied at May 10, 2018 · 3275 hits

先说一下我们公司的情况
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。

water #2 · May 04, 2018 作者
蓝蓝 回复

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

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

心向东 回复

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

water #6 · May 04, 2018 作者
心向东 回复

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

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

water #8 · May 04, 2018 作者
jhh 回复

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

water #9 · May 04, 2018 作者
心向东 回复

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

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

water #11 · May 04, 2018 作者
0x88 回复

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

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

water 回复

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

bauul 回复

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

15Floor has been deleted
water #16 · May 04, 2018 作者

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

17Floor has been deleted
water #18 · May 04, 2018 作者

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

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

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

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

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

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

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

water #23 · May 07, 2018 作者
enjoysft 回复

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

water #24 · May 07, 2018 作者
恒温 回复

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

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

water #26 · May 07, 2018 作者
枫叶 回复

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

water 回复

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

陈恒捷 回复

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

water 回复

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

bauul 回复

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

黑水 回复

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

water 回复

也是用的appium

water #33 · May 08, 2018 作者
在路上 回复

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

water 回复

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

water #35 · May 08, 2018 作者
在路上 回复

膜拜大佬!

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

water #37 · May 08, 2018 作者
simple 回复

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

bauul 回复

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

黑水 回复

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

water 回复

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

bauul 回复

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

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

黑水 回复

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

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