不错的一天，很有条理。

#3 楼 @Yuiking 印度同事

#2 楼 @link1220 你是羡慕我有这么长的学习时间呢，还是佩服我有这么长的学习时间呢？

Hi，我们建立了一个 wiki 作为近期 MonkeyTalk 文章的合集：
https://testerhome.com/wiki/monkeytalk

能否在更新文章的同时更新一下这个合集，并把这个合集的地址附在文章开头，方便大家查看和浏览？
谢谢！

selendroid 可以测试 webview 啊。

那个权限是网络通讯权限，是必须的。

Selendroid 的方式类似于在 app 里面增加一个 agent ，所以需要获得网络通讯的权限才能和电脑通讯。

Good job！

你的 markdown 是不是用错了？标题都不是重点。

info: [debug] [BOOTSTRAP] [debug] Encoded text: T&AOk-stB&AOA-e&Ti1W,XaEgfpwYzDGMLkwy-

应该是 encode 时出错了。

#1 楼 @doctorq 你们可以一起做啊

#10 楼 @520szh NoSuchElementException 是 webdriver api 自定义的 exception，你要先 import 进来。

同 1 楼，看到了截图，没看到自动。

我们的做法是使用 decorator（我们用 python），所有 action 如果有 exception（无论是 assertion error 还是别的 error）都执行指定操作（默认是截图）。

其实也可以考虑在 case 层面做，如果 case 出现异常就执行指定操作。

如果想获取更多信息的话，可以起个线程进行录制屏幕（adb shell 命令里就有录制屏幕的功能）。如果不出错就删掉录制的视频，否则就把视频保存起来，方便后面查看。

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

#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 的。