#1 楼 @monkey 到现在竟然还坚挺地没被删！？

@doctorq 有个地方我提议详细描述一下：

UIAUTOMATOR STDOUT是系统执行 uiautomator 时显示在 shell 中的信息（在操作系统层面都称为 STDOUT ，即标准输出 (对应地，标准输入为 STDIN，错误输出为 STDERR)。我们编程中使用 print 语句输出的对象就是 STDOUT ），BOOTSTRAP 是 bootstrap.jar 内部的 socket server 与 appium server 通讯的信息（通过 bootstrap port 输出），我觉得意义上这才是 bootstrap 内部操作的 log 。

单纯说 脚本输出 我觉得有些人可能会误解为是 bootstrap 让这些东西输出的，因为实质上是 UIAutomator 的执行过程自动输出的。

#3 楼 @kendydrm 好的，学习了。
@huokedu 你的问题已经得到解答了。你可以尝试后把过程和结论补充到正文中，让其他人也学习一下吧。

大赞，同通过《第一行代码 Android》学习 Android 开发中。
学习到后面你会发现 Fragment 也有生命周期的，而且比 activity 更好玩！

#3 楼 @ivy8_zhang 那就是不能通过 keyevent 来输入了（sendkey 在 UIAutomator 里本质上是发送 keyevent ）。如果真的需要纯自动化输入，只能图像识别了。

认同 @doctorq ，最关键的还是技术能力。做测试还是开发只是分工、着重点不同，本质上还是研发的一部分。你有能力，想做测试还是开发其实都可以的。不过，我认为目前测试转开发确实比开发转测试要难，因为测试工作用到的技术栈都比较浅，要转开发需要补充的东西比较多（在特定领域工作经验的差距）。

我目前选择做测试主要是因为我希望更加全面地了解软件，特别是原理层面，而不仅仅是从某个/些点。引用《 google 测试之道》里面一个测试工程经理 Joel Hynoski 的一句话：测试是开发过程里工程师能涉及的最远的地方。

至于那些觉得手动测试点点点没技术含量的，你看到开发在调试时也是不断点点点吗？点点点本身也许没啥技术含量，但懂得需要点什么、怎么点最容易发现问题就含有技术含量了。如果你发现问题后还能分析出具体哪些代码导致这个问题，甚至 fix 这个问题，那你绝对是一个很受开发欢迎的测试。

#13 楼 @doctorq 回复好快。。。
后面我也要加把劲了！

写得好细啊！
之前的 appium 源码分析大多重点在 bootstrap ，对 appium server 本身关注度都不高。终于有研究 server 本身的了。
我最近都没怎么研究，自愧不如啊。。。

找到这个：
http://stackoverflow.com/questions/16953809/can-one-android-application-control-another-application-via-ui-automator/17561071#17561071
原理就是把 UIAutomator 测试用例打包成 jar ，放到手机里，然后用一个应用调用系统 shell 命令来启动 UIAutomator 测试。

我猜测你看到的应该是把 UIAutomator 的测试用例打包成 jar 后，再用一个可以通过调用 shell 启动测试的 apk 把 jar 包起来。

#2 楼 @snake 直接把你的解决方案贴到正文里把。
Jenkins 调用的 shell 确实和我们平时用的 shell 不一样，坑不少。

不错，受教了。以后遇到需要对元素注入 tap 事件可以这么用。

#6 楼 @sunrise 求 Log 。。。
你可以先试试用 log_source 把页面元素打印出来，然后看看里面是否确实有你需要的信息。
Selendroid 和 appium 不一样，它不是使用 uiautomator 的。

#7 楼 @cissysnail 额，你前面提到的测试任务触发，测试执行，测试结果收集以及邮件发送用 Jenkins 跑你的测试就能做到了。小公司确实挺难，因为配环境比较麻烦，而且迭代速度快的话自动化测试（按照你的描述应该是用自动化的端到端测试）测试用例维护成本高。

手动测试大部分情况下是端到端测试（测试中包含系统的两端，如服务端和客户端）。基于业务流程的 UI 自动化是可以实现端到端测试。

这个文章的主旨是仅靠端到端测试创造的价值不够高（开发修 bug 时间慢），而且原文是 Google Test Blog 的，所以应该没考虑小公司。不过他的一些思想（指定测试策略时不仅要考虑能否覆盖所有功能，还要考虑修复 bug 的时间成本）小公司其实可以借鉴。

#4 楼 @seveniruby 工作经验多了解层面高很多啊！赞！
确实现状是单测在国内的比例不高，大部分做自动化的都是端到端，Google 的以单测为基础的测试体系在国内很难推动（开发会说影响进度，不干）。
我个人比较赞同文中关于只有 bug fix 才能创造价值的观点。同时我觉得端到端通过监控/完整的日志可以尽可能让开发容易定位问题所在（前提是程序有良好的日志/提供监控的接口）。

从你的 log 看，你的 device name 有错误，所以识别不到你想用哪个设备。你把 desired_caps 的内容都贴出来看看？

#1 楼 @lihuazhang 嗯，我把原文补上了。这句大意就是端到端测试在理论上有合理性和存在意义吧。

#5 楼 @emily 对。
#9 楼 @emily 你太抬举我了。我的经验和各个大牛比还是太少了。

你这个问题我的理解其实就是脚本架构设计和编码规范。其实这和开发已经是一个概念的东西了（都是编程序嘛），所以你也可以请教一下你们开发（最好是架构师这个级别的，他们走过很多坑，所以给出的方案一般可行性比较好）

我在这里按照我所知道的回答一下你的两个问题吧：

我想知道大家都是用的什么方式对脚本和数据进行的分离，最好说具体些

我们目前没有做很明确的分离，只是把跨用例的共用的数据放到一些 global 变量中共用。因为我们的项目基本上没多少数据输入的场景。对于登录这类需要用很多种数据来尝试的，我们在登录这个脚本里面单独写（因为其他脚本也用不上，分离出来意义不大）

关于命名规则，什么样的命名方式方便日后维护和阅读，包括类名，方法名，数据名等...

命名规则这个还真说不准，看你的脚本架构是按什么来确定这是一个类/方法的。如果是按照模块，那么类名自然是模块名称，方法名就是用例名称。用例名称能表达这个用例的测试点就可以了。如果你说的是调用的方法的封装，我们采用的是类似 robotframework 的命名方式：带有自校验的用 xxx should be，进行元素操作的：click element，get element text，get element attribute。

PS：对于数据，正常情况下我不会采用你上面这种用序号结尾的命名方式，因为从名字上完全不知道这个数据是干嘛的，每次使用数据都要去声明文件里查，而且后面改数据也不知道这个数据是干吗用的，应该改哪个数据。
如果是同一用途的数据，我会用个 array 封装起来。如果是不同用途的，我会根据数据的用途来命名。如果数据实在太复杂，我会用表格来保存数据（其实表格保存是最清晰的和容易修改的）。

#4 楼 @gaoxing200851 根据你的描述，应该是你的手机上打开了不止一个 webview ，而你 switch 到的刚好不是你在界面上看到有内容的那个。但你的情况和之前我和恒温研究的有点出入，我们那个是一个 webview 里面开了不止一个 window ，你这个是本来就有多个 webview（webview 里面是否还有多个 window 还不知道）。
看你的代码是用 python ，可以用一个循环切换所有 context ，然后把每个 webview 的 source 都打印出来，看到底哪个是你在手机界面上看到的那个。然后再做进一步操作。

log 和代码请使用代码块。
为了论坛的排版统一，请先更新一下排版，然后我再继续回答你的问题。谢谢。

#2 楼 @gaoxing200851 代码使用代码块就好了，不要全部都放到代码块里面。。。
例如：

代码：

driver.findElementById("abc")

建议花 1~2 分钟学习一下 markdown 语法中 单行代码 和 代码块 部分。

同时参考一下论坛中精华帖的排版。

代码请使用代码块。谢谢。
另外，请把完整脚本附到正文中。

#11 楼 @gaoxing200851 对。上 google 的网站基本都需要 ***。