Appium Appium 在 Android Emulator 上运行不稳定的问题

蜗牛 · 2015年12月22日 · 最后由蜗牛回复于 2015年12月24日 · 2246 次阅读

环境：Appium 3.2.0(Java) + Windows + Android Emulator
遇到的问题：

档持续运行 case 超过十几分钟之后，Appium server 会显示 press home button 然后自动退出应用，cases block 住了。日志如下：

info: [debug] [BOOTSTRAP] [debug] Got data from client: {"cmd":"action","action":"find","params":{"strategy":"id","selector":"com.cargosmart.BigSchedules:id/et_username","context":"","multiple":true}}
info: [debug] [BOOTSTRAP] [debug] Got command of type ACTION
info: [debug] [BOOTSTRAP] [debug] Got command action: find
info: [debug] [BOOTSTRAP] [debug] Finding com.cargosmart.BigSchedules:id/et_username using ID with the contextId: multiple: true
info: [debug] [BOOTSTRAP] [debug] Using: UiSelector[RESOURCE_ID=com.cargosmart.BigSchedules:id/et_username]
info: [debug] [BOOTSTRAP] [debug] getElements selector:UiSelector[RESOURCE_ID=com.cargosmart.BigSchedules:id/et_username]
info: [debug] [BOOTSTRAP] [debug] Element[] is null: (0)
info: [debug] [BOOTSTRAP] [debug] getElements tmp selector:UiSelector[INSTANCE=0, RESOURCE_ID=com.cargosmart.BigSchedules:id/et_username]
info: [debug] [BOOTSTRAP] [debug] Element[] is null: (1)
info: [debug] [BOOTSTRAP] [debug] getElements tmp selector:UiSelector[INSTANCE=1, RESOURCE_ID=com.cargosmart.BigSchedules:id/et_username]
info: [debug] Responding to client with success: {"status":0,"value":[{"ELEMENT":"2"}],"sessionId":"271c921b-b35a-41cc-8e78-01d88153dc44"}
info: <-- POST /wd/hub/session/271c921b-b35a-41cc-8e78-01d88153dc44/elements 200 149.315 ms - 89 {"status":0,"value":[{"ELEMENT":"2"}],"sessionId":"271c921b-b35a-41cc-8e78-01d88153dc44"}
info: --> POST /wd/hub/session/271c921b-b35a-41cc-8e78-01d88153dc44/element/2/value {"id":"2","value":["test01@cs.com"]}
info: [debug] Pushing command to appium work queue: ["element:setText",{"elementId":"2","text":"test01@cs.com","replace":false}]
info: [debug] Didn't get a new command in 60 secs, shutting down...
info: Shutting down appium session
info: [debug] Pressing the HOME button
info: [debug] executing cmd: "D:\android Dev\Android\Sdk\platform-tools\adb.exe" -s emulator-5554 shell "input keyevent 3"
Click Element 问题：通过 WebDriver 的方式查找返回 WebElement，然后调用 WebElement 的 click，对于部分的元素，Click 操作不是在元素本身，而是发生在相邻近的元素上了，不知道大家在做的过程有没有遇到这类问题呢？

共收到 17 条回复时间点赞

虚冰丶夜 #1 · 2015年12月22日

1、接收命令超时：Didn't get a new command in 60 secs, shutting down... 初始化的时候把 newCommandTimeout 设长一点
2、WebElement 监听的不一定是 click 事件，还有 tap、touch，这几个是不一样的，你可以都试试

蜗牛 #2 · 2015年12月22日 Author

#1 楼 @xubin98246 newCommandTimeout 这个是 function 吗？我在 AppiumDriver 上没看到有这个 function 的。另外我详细查看发现，当发生上面接受命令超时的时候，ADB devices 找不到当前启动的虚拟机了，但实际是启动的，好奇怪

虚冰丶夜 #15 · 2015年12月22日

#2 楼 @cxli2 不是，初始化的一个参数。adb 的问题就难说了。

—— 来自 TesterHome 官方安卓客户端

蜗牛 #14 · 2015年12月22日 Author

#3 楼 @xubin98246 嗯，我找到了，Desiredcapabilities 里面设置，现在设置为 120 了。但是连续运行 cases 之后，大概十几分钟，都会导致某个 step block 大概 10 分钟，然后就会 adb devices 找不到设备了，接着所有剩下的 cases 都 failed 了。

蜗牛 #13 · 2015年12月22日 Author

#3 楼 @xubin98246 你好，刚才跟一个使用 Robotium 的同事讨论一下，他说 case 里面频繁的 Close Application 和 Open Application，就会导致 adb 运行过程中自动关闭了，不知道是否由此一说。PS：我每个 cases 都会重新打开 app，结束后，就会关闭 app，这种思路不知道是否有问题？谢谢

陈恒捷 #6 · 2015年12月22日

印象中 711 大会时 mujun 有提到过原生 adb 稳定性有问题。不过是否和频繁打开关闭 app 有关就不清楚了。

蜗牛 #11 · 2015年12月23日 Author

#6 楼 @chenhengjie123 @xubin98246 尝试了用 override-session flag, 每次重新打开 APP 的时候，都会覆盖掉之前的 appium session，总共 17 个 cases，每次运行至第七个的时候，就开始 adb 个 Emulator 连接不上了。如果是 adb 本身的稳定性问题，那 Appium 依赖于 ADB 来执行，岂不是下策？看见 appium 在国内这么流行，不知道各位前辈如何解决这个问题？

陈恒捷 #8 · 2015年12月23日

#7 楼 @cxli2 我不会那么频繁开关 app ，而且我用的是真机，至少跑 20-30 个 case 是没问题的。

这不是是否下策的问题，应该说是综合考虑的结果吧，毕竟 7x24 小时的服务对于大部分自动化测试必要性不是那么大。

蜗牛 #9 · 2015年12月23日 Author

#8 楼 @chenhengjie123 如果不频繁开关 app，每个 cases 之间的影响岂不是很大，这样子上面一个 case 失败了，界面停留在 failed case 当前界面，其他 case 如果不是从当前界面继续，该怎么办？请前辈赐教，谢谢。

黑水 #10 · 2015年12月23日

#7 楼 @cxli2

override-session 没有用新的 adb ，重启 appium server 会用新的 adb ，不怕慢可以每次杀进程重启
Appium Wrapper for Java
以前感觉 Linux 和 OS X 上 adb 不容易出问题，后来发现在 “干净” 的 Window10 表现也不错
模拟器本身也很容易卡出问题
更新 platform-tools 保持 adb 是新的

陈恒捷 #11 · 2015年12月23日

#9 楼 @cxli2 有种函数叫做 teardown 。既然你每个 case 都是从打开 app 后的默认界面开始，那你每个 case 结束时都回到那个界面不就好了嘛。

蜗牛 #6 · 2015年12月23日 Author

#11 楼 @chenhengjie123 teardown 我还是知道的，case 的结束有可能是 pass，有可能是 failed，那回退到开始界面所需的步骤就是不确定了呀

蜗牛 #5 · 2015年12月23日 Author

#10 楼 @sanlengjingvv 感觉，重启 appium server 这种方式，有点奇怪。现在研究的结果就是，我每个 case，都会 new 一个 AppiumDriver，就是说每个 case 都会重新和 Appium Server 创建一个新的 session，估计是这种频繁创建 session 的操作导致了 adb 和 Emulator 失去了连接。我再想想有什么办法先，谢谢。

陈恒捷 #4 · 2015年12月23日

#12 楼 @cxli2 可以确定的吧。
如果是界面方式，一路返回直到回到开始界面
如果是非界面方式，可以直接开指定 activity

蜗牛 #15 · 2015年12月23日 Author

#14 楼 @chenhengjie123 界面方式，回退使用的是 WebDriver 的 back() 吗？

陈恒捷 #16 · 2015年12月23日

#15 楼 @cxli2 具体方法很多，可以发送返回按钮事件，或者点击界面中的返回按钮。back() 这个我没用过，不知道是不是返回按钮，你可以试试。

蜗牛 #17 · 2015年12月24日 Author

#16 楼 @chenhengjie123 再奋战了一天时间，问题还是没有解决，因为我的 cases 有的需要登录，有的不需要登录，以返回方式处理，感觉太不理想了。尝试了 Appium 的 closeApp 和 launchApp 方法，但是运行时间超过十几分钟之后，同样会发生 Appium server 连接不上的问题，并且报了 404 错误，如下：

info: <-- GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot 404 0.562 ms - 40
info: --> POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/close {}
info: <-- POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/close 404 1.125 ms - 40
info: --> GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot {}
info: <-- GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot 404 0.788 ms - 40
info: --> POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/launch {}
info: <-- POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/launch 404 1.307 ms - 40
info: --> GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot {}
info: <-- GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot 404 0.573 ms - 40
info: --> POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/close {}
info: <-- POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/close 404 0.545 ms - 40
info: --> GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot {}
info: <-- GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot 404 0.969 ms - 40
info: --> POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/launch {}
info: <-- POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/launch 404 0.598 ms - 40
info: --> GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot {}
info: <-- GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot 404 0.574 ms - 40
info: --> POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/close {}
info: <-- POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/close 404 0.538 ms - 40
info: --> GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot {}
info: <-- GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot 404 0.419 ms - 40
info: --> POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/launch {}
info: <-- POST /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/appium/app/launch 404 0.595 ms - 40
info: --> GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot {}
info: <-- GET /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904/screenshot 404 0.591 ms - 40
info: --> DELETE /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904 {}
info: <-- DELETE /wd/hub/session/64ef1ea4-bbf1-4621-9d86-d5b341faa904 404 0.667 ms - 40
info: [debug] Didn't get a new command in 300 secs, shutting down...
info: [debug] Trying to stop appium but there's no session, doing nothing
info: [debug] We shut down because no new commands came in

感觉 Appium 太难用了，慢还不是主要障碍。考虑用 Robotium 做 Android 的 automation 了。谢谢@xubin98246 @sanlengjingvv 关注和帮助

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