Robotium 一点疑惑,请问大侠们,你们都在同时维护 APPIUM 和 ROBOTIUM 两套代码么?

magicyang · 2015年01月13日 · 最后由 magicyang 回复于 2015年01月28日 · 49 次阅读

一个 APK 的基本功能用 ROBOTIUM 实现,个人总觉得 ROBOTIUM 速度快很多,而且对于 LISTVIEW 这种组件,不用自己写 SCROLL。对于内部控件的可操作的内容也比 APPIUM 多很多。看了一下前两天论坛大侠提到的 ADB 跨进程的内容,感觉绕了一圈,可操作的 API 还没有 APPIUM 多啊。
但是 ROBOTIUM 不支持跨进程。所以又用了 APPIUM 来写跨进程的用例。
现在发现如果源 APK 最基本的一些操作修改,悲剧的就要改两套代码了啊。
大侠们也遇到过类似的情况么?请问是如何解决的啊?

共收到 7 条回复 时间 点赞
  1. robotium 跨进程的操作方式非常多,借助 adb 来跨进程不是什么高深的技术,它突出的是两个字:简单,更多地是针对那些不想花太多精力而又想突破 robotium 的进程限制去做一些跨进程的操作的人。
  2. 既然选择了 robotium 那肯定大多数测试都是针对单个 app 的,跨进程的操作不会特别多,封装那么多 API 来干嘛呢?而且这里可能会有很多人误会了这个 adb 框架的作用,它仅仅用作于协助你更方便地帮你完成跨进程操作,针对单个 app 的操作,请还是使用 robotium 自身的方法,它并不能取代 robotium,谢谢。
  3. 很多人纠结底层是不是用 uiautomator 去绕,其实用纠结么?我们更多地是使用框架给出的 API,原理我们心知肚明就行,在使用时的操作简单就行,何必太过于纠结底层是怎么绕的呢?

如果仅仅为了跨进程而去用 appium,一般操作用 robotium,那我才觉得是更绕了,完全没必要去维护两套框架的脚本。
个人愚见,欢迎拍砖!

两套框架的思想不同, 同时维护很伤身体.
最好是选择同一个.

appium 的方案是 selendroid+uiautomator. 基本可以替代 robotium.
robotium 也有跨进程测试的解决方案. 也可以替代 appium

总体来说 robotium 更快更稳定. 一般跨进程测试不应该是主要的测试体系. 所以选择 robotium 更好些.

@qinggchu @seveniruby
谢谢两位,谢谢 qinggchu 的分享。我再仔细看看 UIAUTOMATOR 的绕法和 XUXU 的接口吧~还是优先选择 ROBOTIUM 吧。我还需要第三方控件的 TEXT,控件大小等属性,UIAUTOMATOR 应该能取到,取到了再来分享~
后面还要玩 IOS 的,IOS 的还没有概念。。。

#3 楼 @yangchengtest 如果你后面还要玩 IOS,那建议直接上 appium,免得后面还得重新又去搞 appium,很累。技术没有绝对的好坏,适合的就是最好的。

我用一套框架支持了 appium,Monkeytalk。我们自己的框架不应该被这些 instrumentation 左右

iOS 还是用原生的吧,满足不了的功能可以借鉴 appium 自己去实现,后续用例多的情况下执行效率还是很重要的!脚步设计最好选取 PO 模式。从 appium 最早版本一路趟到 1.3.4 最终感觉还是回归原生,做适合自我测试需求的封装,学习 appium 的思想,才是一条明路…

@vigossjjj @squallff
谢谢两位的建议~正在补 JAVASCRIPT 的基本知识,准备学习一下 APPIUM 的插桩思想。
目前的想法是能用原生的 INSTRUMENTS 的架构的就用原生的,跨进程麻烦的再考虑 APPIUM。
应用需要调系统的音视频播放器,ROBOTIUM 插桩的话,播放器不同的话,成本太高,目前就这块还在用 APPIUM 实现。
多谢!~

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