#29 楼 @weamylady 额，我现在也才刚申请到 mac，刚开始用。不过研究 appium 的时候跑过一下它自带的用例，就以我的了解给些参考吧：

1、你指的 绑定 UDID 是指绑定 UDID 到开发者账号吗？如果是，这个是一定要的。真机调试必须绑定 UDID（除非你是 299 美刀一年的那种高级开发者账号，有 in-house 分发功能），否则你的 app 只能在模拟器上跑。至于 in-house 分发的能否通过 appium 来做自动化测试，我没试过，所以不清楚。

2、优点是遵循 webdriver 规范，可以使用各种语言的 client 编写，支持真机、webview，而且基本不需要改动应用代码。缺点的话环境配置可能算一个（要装的东西有点多，不过都是 iOS 开发必装的），不过因为没怎么实际用过使用其它方式做 ios 自动化测试的框架（如 calabash, monkeyTalk），所以也比较不了太多。

3、执行效率和人工点击不会相差太大，某些时候甚至会慢一点。不要想着会有 selenium+web 那样飞一样的速度，因为移动设备的 UI 有很多切换动画，即使做到这么快的速度你也会因为动画不得不放慢速度。不过优势是重复执行不需要花费人力。

4、没有代码基础的话难度相对于 MonkeyTalk 比较大（有录制和没录制的质的区别）。其实 Appium 的最大优势是遵循 webdriver 规范和基本不需要改动被测应用。如果这两点你都不需要，那么最容易产生产出的应该是 MonkeyTalk。

#9 楼 @mildshark 我昨天看了 appium 源码，好像它会把 press->wait->moveTo->release 转化才 swipe（必须按照前面的顺序），然后 swipe 才是你实际需要用的动作。具体情况我今晚再看看吧。
另外，你确定你移动的速度和范围足够了？可以打开触控指示看看触控点的变化看看是不是符合需要。

不错，不过想了解一下为何 tap 完需要固定等待 2 秒呢？是因为业务需要？

额，你的 waitAction 等待时间也太长了吧，这个 touch Action 一共花了 10 秒来移动，肯定是龟速啊。
你改成下面的再试试：

action.press(200, 250).waitAction(1000).moveTo(10, 250).release().perform();

相关源码：
appium/lib/devices/ios/ios-controller.js

// we need to change the time (which is now an offset)
// and the position (which may be an offset)
var time = 0;
_.each(touchStateObjects, function (state) {
  if (state.touch[0] === false) {
    // if we have no position (this happens with `wait`) we need the previous one
    state.touch[0] = prevPos;
  } else if (state.touch[0].offset && prevPos) {
    // the current position is an offset
    state.touch[0].x += prevPos.x;
    state.touch[0].y += prevPos.y;
  }
  // prevent wait => press => moveto crash
  if (state.touch[0]) {
    delete state.touch[0].offset;
    prevPos = state.touch[0];
  }


  var timeOffset = state.timeOffset;
  time += timeOffset;
  state.time = time;

  delete state.timeOffset;
});

相关文档：https://github.com/testerhome/appium/blob/master/docs/cn/writing-running-appium/touch-actions.cn.md

从左边的 log 看，你正在执行的应该是右面第二个 touch 的代码：

action.press(170, 250).moveTo(150, 250).release().perform();

第一个 log 表明一次性传入了 3 个动作（action）（这里 log 太长了，我就只写前面一小部分）：

--> POST /wd/.....

这个 log 和你的执行代码是一致的，即 appium server 收到的命令是没问题的。
然后你有疑惑的应该是下一个 log：

[debug] Pushing command to appium ...

此处的第二个 touch 坐标和你代码不是完全一样。代码是150, 250，而命令则是320, 500。这个应该是做了一个计算：170+150=320, 250+250=500，即moveTo在传坐标时会认为传的是相对于起始元素的偏移量。

你没有滑动的原因应该是没有加wait方法。你可以尝试在press和moveTo之间加个wait方法。

能把标题改改，改成类似"xx 错误原因及解决方案"吗？
看到这标题我还以为是提问帖。。。

#17 楼 @springs412 你先试试adb devices能不能找到设备。adb 能找到 appium 一般都能连到。

#4 楼 @testly 设置了unicodeKeyboard为true后会自动安装 appium 的输入法并设为默认输入法。你想在测试完成后自动改回原有输入法可以把resetKeyboard设为true。
详见：https://github.com/appium/appium/blob/master/docs/cn/writing-running-appium/caps.cn.md

#4 楼 @staticfield 麻烦更新一下标题和帖子内容，说明已解决及解决方案吧。这样其他人也可以方便地解决类似的问题。

能提供详细点的上下文不？例如你脚本大部分情况下执行到哪里会出现这个问题，appium 上对应的详细 log 是什么？
只有 client 端的 exception 信息量太少了。

试试在desired_caps里添加这个?
'browserName': 'Browser',

你的问题和那个帖子应该不一样。你这个是应用内置 webview。
appium 相关文档：https://github.com/appium/appium/blob/master/docs/cn/advanced-concepts/hybrid.cn.md

#3 楼 @lihuazhang 那不就类似于 selenium 1 的做法吗？

好文，后面学习 seledroid 就参照这个文章来撘环境了。
在 google 的规划中，webview 的自动化貌似是用 chromedriver 来做的，和 uiautomator 定位有所不同。

话说怎么那么多人写 xpath 都那么喜欢用工具生成的……自己写不是更灵活吗……

#4 楼 @hssdx 麻烦提供一下你运行这个命令时所在目录路径及你配置的 appium 源码根目录路径，以及你是否运行成功了reset.sh --dev命令。

受教了，又学了一个很不错的设计模式！

先收藏了！
这压缩好强悍……我当时下源码搞了一个晚上……

话说下载链接干嘛用代码块……

根据我目前对那两个工具的了解，可能是你的自定义的 view 没有实现 accessibility 方面的方法，你提到的两个工具貌似都是通过 accessibility 服务获取控件的。
帮你找一下分析过这两个工具源码的人，看他的意见吧。@doctorq

#6 楼 @yangchengtest 对，你说的我都赞同，确实目前图片识别技术准确性还不能达到很高的实用价值，但在某些特定场景下（如文中的场景）可以起到很大的辅助作用。
我主要想分享一下它这种另类的解决思路（用较低成本达到较大的产出）而已。

#4 楼 @adfghzhang 有试过像我那样在 sendKeys 前先 clear 吗？效果如何？

#5 楼 @misnull 我也遇到过，貌似三星的默认输入法映射有点问题，后来改成用 google 拼音输入法就好了。
对于非 ASCII 字符（如中文），目前只有 Appium 的 unicode 输入法一条路。坏处是它触发不了输入法的按键事件（因为它压根就没按键，直接传信号的）

#2 楼 @yangchengtest
文中第一部分已经说明图和关键字对应起来放数据库走不通。。。图库量太大了。。。所以要用识图工具。
百度识图不是单纯的数据库比对，里面有识别算法的，当然也包含大数据。简单地说就是它能识别近乎于任意图片的对应关键字，这样即使你图库再大，再怎么更新也不怕。
附上文中提到的知乎的讨论链接：http://www.zhihu.com/question/19738567