这明显是伸手帖。。。我把你移到伸手区了。

#25 楼 @anonymous 我觉得其实也要看实际情况。

1. 既然需求变化快，那么应该只对相对稳定的模块（最好也同时是核心模块）进行自动化，否则无论是哪个级别的自动化（UI，接口，单测），维护成本都比手工高很多。
2. 是不是越底层越稳定我不确定（也有不少变更是 UI 不变，底层变的，如性能优化），但越底层代码覆盖率正常来说代码覆盖率越高。
3. @lihuazhang 之前说过，好的团队测试不会只是某个人/某个职位做的，而是所有人一起做。用代码做测试还是人工做都只是手段，要高质量还需要全团队一起努力。

#24 楼 @anonymous 这个很正常，我们也在这么做。。。app 操作完看 web，web 操作完看 app。好处是如果 pass 能证明 web，app，接口三者都没问题（至少正常使用没问题，覆盖率相比单独测试肯定低很多），坏处是如果 fail 比较难定位具体原因（要配合日志分析）。

个人觉得，这个其实应该做分层的自动化。api 是一部分（mock app 来发请求，看 web 是否正确处理），app 是一部分（ UI 操作后是否有相应的请求发出），web 后台是一部分（后台数据是否正确更新）。当然最后也是需要整体做一下测试的（这样可以最真实模拟用户操作，有点类似验收测试，虽然覆盖率低，但不可省略）。不过资源受限的情况下，大部分人应该偏向于直接做整体的测试吧。

#14 楼 @laiyuncong8404 :plus1:

不过好奇怪啊，你不是试过绝对路径不行吗？怎么现在就可以了？

貌似本来是合并的，从某个版本开始作者把它分开了。
可以和作者说一下。如果作者还是需要分开，那就更新一下 sample-code 吧。

结果打印啥了？

Java client 不要使用 AppiumDriver，要用 AndroidDriver 或者 IOSDriver 。印象中官方的 api 文档里有提到的。

分别 getText 后 assertEqual。

能否把解决方案附在正文末尾并醒目标出？这样也方便后面的人出现类似问题后快速找到解决方案。

这个你要看看 chromedriver 有没有这方面的设置项。
appium 底层也是调用 chromedriver 的。

个人观点，欢迎拍砖：

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 就可以装到真机上，也可以在真机上做自动化了。