个人观点，欢迎拍砖：

1、自动化没有银弹，也不是银弹。不要以用自动化代替手工作为出发点，你会发现自动化的成本很有可能比手工更高。

2、不明白为何做完 UI 自动化还不能降低手工测试量？至少能减少一部分回归测试的工作吧，除非你们的自动化用例本来手工也不会执行。不过从成本角度和投入产出比角度，即使是比较熟练的 UI 自动化工程师， 保守估计编写一个用例使用的时间（包括查资料、封装代码、学习相关知识、调试用例等）约等于手工执行这个用例 10~20 遍。所以如果这方面期望太高（能达到手工编写用例的速度，或者能快速替代大部分手工测试的工作量）肯定会失望。

3、不要把自动化等同于 UI 自动化。不要随随便便把 UI 这个字眼省掉，两者之间差异太大了。如果只是做完了 UI 自动化，你会发现还有很多问题。例如：为啥这个用例跑 5 遍会有 1 遍 fail？为什么点了这个按钮有一定概率没有相应效果？这些问题手工测试时感觉不太严重的问题（测试人员很有可能会多执行几遍，有一遍 pass 就算通过了）在 UI 自动化测试中就会暴露出来，并影响你的测试结果可信度。所以你得收集日志，得收集更多的运行时数据来便于找出失败原因（ 无法定位出错原因或者忽略 fail 都会逐步扩展并最终让你的 UI 自动化变得不可信，然后就没有然后了。。。），所以要做的事情不仅仅是让程序帮你点就够了。

4、UI 自动化本来应该是金字塔的上层，占比最少。如果想往自动化，或者说往测试方向深入发展，要多扩展，例如了解一些灰盒/白盒的东西（这方面的自动化投入产出比相比 UI 自动化可能大一些，你也可以看看一些开源项目是怎么做测试的），了解开发（这点很重要），了解项目的整个过程而不只是关注其中自己负责的点（个人觉得无论你是项目里的哪个角色，这点都应该有基本的了解）。

#7 楼 @askaneverend :plus1: 加油！

#2 楼 @wuaini2006 那就是 appium 获取不到 webview 了。
如果获取到的话，应该有一个带有 WEBVIEW 字眼的值。

获取不到的原因可能有：
1、系统不是 4.4 及以上（4.4 以下的 webview 没有使用 chrome 内核，appium 只有在 selendroid 模式下支持）
2、使用的不是系统的 webview 。webview 内核可以有很多的，而且很多应用（例如微信）出于兼容性或者其他原因会使用第三方内核（微信用的是腾讯自家的 QQ 浏览器内核）。但 appium 目前只支持系统内置的 webview 。
3、应用没有开启 webview 的 debug 选项。在模拟器上由于使用的是开发版系统，所以默认是打开了 debug 的，但真机除了亲儿子基本默认都关闭，需要增加代码来打开。详细可以看官方文档：https://developer.chrome.com/devtools/docs/remote-debugging#debugging-webviews

另外，要看 android 系统版本的话装个看系统信息的 app 就能看到了吧？

:plus1: :plus1:
以后别人问我们测试人的生活过的怎样，我就让他看看小道消息。

首先，我不是大牛，但 appium 也有用过一段时间了，你的几个问题可以回答一下：

1、Appium 没有看到智能等待控件出现就点击的方法（查过 API，但没有看出哪个是），请问大家都是怎么设置这个点击的等待时间呢

appium client 大多继承了 selenium 的 client ，而 selenium client 本身就有各种智能等待可用。论坛里也有比较详细的文章说明。

2、Appium 生成报告有没有具体的例子啊，看到的文章都是直接带过的，没有看到详细的说明（比如说到的 build.xml pom.xml 是直接生成的吗？生成后要修改吗？）

生成报告不归 appium 管，你要看你使用的测试框架（如 jUnit，TestNG）的报告生成要怎么做。appium 只负责执行。

3、Appium 校验结果的方法都是用 jUnit 的 assertEquals 吗？还是有什么更好的办法呢？

assert 方法绝对不止 assertEquals ，还有很多的，这个你要熟悉一下 jUnit 的各种断言方法。

总的来说，虽然你接触 appium 3 天就能写基本的 case ，但个人觉得你很大可能只是通过看各种实战文章 + 自己理解来学习，实际上并不是真正掌握（比如要求你写个登录用例可以写，但写个在滑动列表里查找指定元素是否存在的方法的话，可能就又得一番查找了）。若想提高，建议先把你用到的主要工具（jUnit，appium，appium java client）的官方文档都看一遍，知道各个工具到底能干吗。

要耐得住寂寞，你用 3 天学到的东西别人 3 天也能学到。

建议你先看一下 driver.getContextHandles() 返回的 webview 名称是什么。切换 context 时 context 名称必须是使用前面方法返回的名称。这个名称是 appium 生成的，不是自己可以随便定义的。

#4 楼 @missgong0 多 google 和上官方网站。

#4 楼 @sanlengjingvv :plus1: 感谢！

原文地址是？

我快哭死了。。。只能说你不按常理出牌啊，明明是 appium-doctor ，你偏要在破折号前面加个空格。。。

建议读一下这个：
http://appium.testerhome.com/content/appium_basic/appium_install/windows.html

幸好我先把这个章节写完了。

#9 楼 @zsx10110 appium 的追加其实是先记录输入前的文字。输入时把记录的文字先输入，然后再输入 sendKeys 传入的文本。setText 方法本身只能替换，没带有追加功能。

从你的 Log 来看， clearText() 方法执行不成功，因此它假定没能删掉的文字是提示文字（hint text），即平时我们一旦在输入框输入内容后就会自动消失的文字。所以第二次 setText 时它认为留在输入框的文字（我估计就是你第一次 sendKeys 时输入的 helo.everyone ）是会自动消失的，所以就没有再次输入它了。

#4 楼 @huangke 证书想便宜点可以上淘宝买真机调试的证书，然后 app 就可以装到真机上，也可以在真机上做自动化了。

等待 荔枝 fm 的录音。昨晚在动车上，没信号。。。

#2 楼 @sainthunter 这不仅仅是针对 scroll 方法，而是所有手势（包括 swipe）在模拟器的 scrollable view（包括 ScrollViews, CollectionViews, 和 TableViews）都无效。
我实际使用试过，在模拟器上处在 scrollView 中时 swipe 确实无效。

虽然不等同于 swipe 在模拟器上肯定没用，但大多数需要 swipe 的操作都是在 scrollable view 中进行的（例如引导页），所以还需要自己看一下你需要 swipe 的区域处在什么 view 中。

请看：
译文版：
缺陷和解决方法
英文版：
bugs-and-workarounds

不错。
不过有些地方 markdown 貌似写错了，显示出来的格式不对。

#25 楼 @chungeguo 这个我没遇到过。。。看起来是 Xcode path 有问题。你的 Xcode 有打开过吗？
如果还有问题，你可以上 appium 的项目主页搜一下。

提醒一下，论坛的标题格式 井号与文字之间必须有空格：

正确的：
## 标题

错误：
##标题

文中部分标题格式写错了哦。

流畅吗？

不错，感谢分享。
想了解下，对于用 gradle 或者其他方式编译打包的 app 有对应的编译方法吗？

文章总结的不错，感谢分享。等 Xcode7 出了再去实践一下，手上只有一台 mac book，不敢上 10.11 。。。

#7 楼 @testbird
统一在这个帖子回复吧。。。
我上面说过了：

appium 里面的 log 记录的都是 appium 的操作，你这个问题是 app 本身的问题，需要看 app 本身的 log 。看 appium log 可以获取一些辅助线索，然并卵。

查看真机实时 sys log 可以用 idevicesyslog 这个工具，它是 libimobiledevice 的一部分（libimobiledevice 同时包含了 appium 用来安装应用到真机使用的 ideviceinstaller）。

同时思考一下，为啥开发那边没问题，你这边有问题？环境配置到底有什么不同的地方？

找出问题原因首先要找到足够的数据，然后再根据这些数据思考、分析才能知道原因。

appium 看不到元素只是表象，深层次的原因得去查源码或者调试。而且这些方面的数据相信你也不方便给我，所以主要要靠你多思考、自己去分析了，其他人只能给大致方向。