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

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

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

共收到 7 条回复时间点赞

qing #7 · 2015年01月13日

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

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

思寒_seveniruby #6 · 2015年01月14日

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

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

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

magicyang #3 · 2015年01月14日 Author

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

qing #4 · 2015年01月14日

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

leonhart #5 · 2015年01月27日

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

vigossjjj #2 · 2015年01月28日

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

magicyang #7 · 2015年01月28日 Author

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

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