#4 楼 @otori 思路没错，大致就是这样了。
但有个小问题，这种写法 catch 的东西太多了，没指定 exception 的话会 catch 所有 exception 。但我们实际上只需要 catch NoSuchElementException 。

catch 所有 exception 的坏处是其它错误也会被 catch 住，然后用户就不知道到底出错原因是啥了，只知道出错了，然后他就只能按照自己的猜想去 fix 。例如他认为是找不到元素，然后一直往这个方向走，但实际上可能是因为 driver 初始化时有问题。

#5 楼 @tobecrazy 嗯。这样也行。
方法有很多。

xpath 错了，你用 get source 看看 xml 里面节点的名称吧。

#10 楼 @mads 实践出真知，你试一下嘛。

未找到不就是 failed 了吗。。。
find element 的方法如果没找到元素都会抛出 NoSuchElement 异常的。

#6 楼 @lihuazhang 行啊，你完整目录结构怎样的？我看下哪方面我比较熟悉可以写下。

appium/lib/devices/android/android-common.js

if (this.adb.udid) {
      if (!_.contains(_.pluck(devices, 'udid'), this.adb.udid)) {
        return cb(new Error("Device " + this.adb.udid + " was not in the list " +
                            "of connected devices"));
      }
      deviceId = this.adb.udid;
    }

android 上 deviceName 确实没啥用，要指定设备需要用 udid 。

这个文档也有说明：
https://github.com/appium/appium/blob/master/docs/en/writing-running-appium/caps.md

selendroid 的东西建议还是去看 selendroid 官方的文档，appium 在这方面只是把 selendroid 包了进来，然后所有请求都直接转发给 selendroid server 。
Selendroid 自己的文档还是不少的，只是坑略多。

#9 楼 @andward 如果模块耦合度高，那么搞什么测试都会很痛苦。。。
另外，不是很理解你前面提到的

这三个的实现基本是：

• component 级别的 unittest case
• component 级别的 unittest framework
• front-only 的 integration test

你说的是主要用的地方是吧？ unittest framework 具体是指什么？

#10 楼 @htmlbiji 对于你上面提到的，按照文中的说明应该是实现一个服务器的 fake ，而不是 stub 。stub 更多的是在同一模块内的东西，例如你直接把解析返回值的函数替换成返回确定值的函数，这才是 stub 。

我觉得有点像是给开发擦屁股。。。
这些是比较锻炼能力，但如果每次发版都要做这些就太浪费时间了。这些东西要不就让开发搞，要不就做个程序自动搞。而且这么搞下去部署很容易出各种问题。

个人对应上面那几个问题的建议：

问题 1：拿到开发的代码打开的页面缺少样式，导致数据排列混乱

不能添加样式是什么情况？我表示不能理解。。。如果是没办法改，那就做个脚本来干这活。

问题 2：图片资源加载无法显示

这个完全是开发的问题，把这个目录和代码一起放代码库就可以了。如果实在不能放到代码库（例如线上环境数据和测试环境数据不一样），那就在测试环境搞一份就好了。

问题 3：真正测试的才刚刚开始，需要替换资源的行、列数，多种不同组合进行测试

这部分是接口还是配置文件？如果文件格式比较固定，建议写个小程序来自动替换不同组合对应的 xml（自己预先准备好就行）+ 屏幕截图，然后每次检查屏幕截图就好了。手动改实在是吃力不讨好，还容易出错。

问题 4：还需要对比实际返回的 XML 数据是否和开发的 API 格式一致以及数据正确性

有一种日志级别叫做 debug (console.debug("debug message"))，遇到没有加 log 的就加上去并设为 debug 级别的就好了，生产环境把日志级别调高就不会输出这些 log 了。首次添加可能有点累，但好处是一劳永逸，以后就不用加了。至于具体数据格式验证，开发那边应该有对应的解析模块，可以直接取过来做解析看能否正确解析。 xml 如果由人来看速度慢还容易出错。

问题 5：真实的环境需要在 PC Web 和 Web App 上一起测试，有时候在 web 端可以跑通，但在 Web App 上跑不同

这个你没有给具体例子，所以我也不知道具体是什么情况了。如果 web 和 web app 使用同一套代码（特指逻辑处理部分），有可能是前台事件响应的问题，如果不是，那就要看具体情况了。

我觉得要通过改代码解决的问题都可以通过程序来做，毕竟改代码是个技术活，改错了说不定后面就白测了，而且纯文本处理用编程来做也比较简单，说不定以后就可以变成一套部署脚本呢。

而且从上面你提到的这些问题猜测，开发本地会有不少 work copy，说不定某一天 commit 了一个不该 commit 的。。。你懂的。。。

1、 log 和代码使用代码块：

代码块

2、 不要只给你觉得有问题的少数几条 Log ，给出完整的 log（接收到 create session 请求到返回 fail 信息）

#5 楼 @wuyan 你清空一下缓存。

#2 楼 @woniu 换了，你刷新看看。

论坛好多工作刚满两年的。。。不过我也是。。。
组建团队我目前没做过，恒温这方面经验可能比较多，帮你找下他。 @lihuazhang

#8 楼 @zb460989093 如果用 npm 下载的话，这个文件貌似要 *** 才能下到。

#9 楼 @springs412 你报的是什么错？

#3 楼 @tobecrazy 我看出来，但我没用过这个软件，所以不能确定。

#4 楼 @jinmincn 你可以 @ 他。。。

麻烦给出完整的 appium server log 。

预期结果（正常的安全键盘）长啥样？