不错，写得很详细。
不过真的很容易看晕。。。代码数量比较多，而且大多是代码片段，得结合导入了代码的 IDE 来看效果才好。

#2 楼 @shu 另外，麻烦添加一下头像，谢谢。

wife 是什么网络？
无法联网这个要看下到底是手机连不到服务器还是服务器返回这样的错误信息吧？

写得很详细！赞！

不过源码包导入后不是应该跳到 Solo.java 文件吗？为什么是 Solo.class ？这个不是很明白。

PS：Markdown 的超链接写法是这样的：

[超链接](url)

你文中用错了。

#2 楼 @adfghzhang 不客气。
麻烦添加一下头像吧。

#2 楼 @shu 同问，印象中 scrollTo 传的是 element.id ，不是 text 啊。不过不知道你的 scrollTo 和我们理解的是不是同一个?
我说的是这个：
http://appium.io/slate/en/master/?python#scroll-to

另外，通过 id 查找这个其实局限性更大，因为一般情况下 scrollView 中的元素使用的 resource-id 是一样的。

实际实践中应该是支持多种定位方式（id, text, xpath 等）。

没猜错的话你是拿对应真机的 ipa/app 放到模拟器上跑了。

iOS 模拟器都是 x86，真机都是 arm ，两者编译时使用的参数是不一样的，所以真机能跑的放到模拟器就会无限闪退。

至于 XCode 里面直接点 run 的话它会自动根据你选择的设备使用不同的编译参数现场编译，所以会有用的是同样程序的错觉。

PS：遇到 app 自己闪退方面的问题不要光看 appium server log，此时设备自身的包含应用内部日志的 log 才是能够有效定位问题的。

相当清晰了！赞！

这里的 “全栈测试工程师” 其实就是项目的保姆啊。。。啥都要干还必须是背锅侠。。。

不过开发还根据他的技术栈来安排工作，测试基本是哪里需要测试就去哪里，从服务器后台到接口，再到前端。有些时候全栈就是这样被逼出来的。。。

补充一下添加打赏二维码的步骤：

1. 准备好二维码图片：

   • 在微信的 “面对面支付” 中截图（包含二维码）
   • 把截图传回电脑，处理成只包含二维码并保存成 jpg、jpeg 或 png 格式

2. 上传二维码：

   • 点击右上角的用户名 -> 个人资料设置 -> 打赏二维码
   • 把你的二维码图片选中，点击页面底部【更新资料】

3. 还等什么，赶紧发帖争取精华啊！

Good Job！UIAutomatorViewer 本身的架构确实很方便扩展。

录制那块有个疑问：看你写的是 Appium 的 python 脚本，但没看到具体是哪些代码把每个操作步骤 write 到文件中的。是不是把 writeFile 分别放在了各个点击事件中了？

#4 楼 @kendydrm 好快！赞！你是在微信工作的？

#2 楼 @kendydrm 但这个 X5WebView 在兼容性方面有点小问题，如 ruby china 的一片红。

答案是：

3. els[0].find_element_by_class_name与driver.find_element_by_class_name，实际是一样的效果

两年多，和我差不多啊，我的阅历果然太少了。
好期待！

#1 楼 @duoyou
#2 楼 @cloudits
两位麻烦加下头像吧。。。

找到这个：
https://github.com/appium/appium/issues/5107
看起来是 app 自身问题。
你打开 iOS log 看看系统 Log 里面有没有什么特别的 log ？如果有，那估计确实是 app 的问题了，恭喜你找到一个 crash issue 。

#56 楼 @chenhengjie123 Sorry，发了才看到你的回复。此贴就此打住吧。

#24 楼 @anonymous 我客观点回答你的几个问题吧：

为什么测试行业没有一本书或者一系列书去更详细的讲解测试，有的是泛泛而谈，有的是博客里自己的零散的心得。

讲解测试的书是有的，经典书籍也是有的，例如《软件测试》（ISBN: 9787111185260）《软件测试的艺术》（ISBN: 9787111376606）。至于其他公司是怎么做测试的，有《Google 测试之道》（ISBN: 9787115330246），《微软的测试之道》（ISBN: 9787111277538）。只是像你例子里的很具体的工具书籍基本没有。
测试行业是发展好多年了，但移动测试发展也没几年啊（iPhone 2007 年出来，到现在也不过 10 年）。你例子里举的 adb ，monkeyRunner 出来也没多少年，而且他们深度上和应用上与其他工具（如 Java 的 Spring）之间差别太大了，一个是常用的基本工具，看完官方文档基本会用。一个是设计良好的大型框架，会用和用精完全两码事。拿 adb 这些工具和 Java 这门语言，或者 一些经典工具比较不是太恰当。

PS：你想要系统了解同时也造福行业的话，可以自己通过阅读这些零散的心得，然后把它们组织起来，在 gitbook 或者什么地方把它们写成书，造福大家。

3.你怎么知道我不愿意学习？我买书是为了什么？就拿 Appium，我有去看官方文档，有看 API，有在 testerhome 上学习基础，然后就在想有没有一本书可以具体的讲解用在项目里。到网上去找书，买了上面说的三本，然后发现讲 Appium 的就那么点。我并不是没有自理能力，只是想更深入学习。

这类书我想短期内不会有，以后也不一定会很深入地讲。一方面具体用在项目中的东西大多通用性不会十分强，写成书后菜鸟还是没办法按照书中的说明把它用起来的，毕竟不同项目间差异还是不小的；另一方面 Appium 在国内流行也是这 1~2 年的事情，估计还没有什么企业/人敢说自己在项目中的实践强大到可以出书了吧。之前倒是听说淘测试有在用，而且还对 appium 进行了一些改造以符合自己的需要，但具体如何我就不大清楚了。

我有看 Android 官方文档啊，我只是在想学习的方式不一定是只看官方的，我是一个习惯去买书学习的人。请问学习的方式一定要 先源码吗？这么说我又要开始学 Python 了？我一个 java 都只是基础的人又 tmd 开始学 python 了？

我在 IT 技术方面的学习路线一般是：

1. 如果有入门书籍就入门书籍，没有就看经典书籍或者直接官方 Getting started 或者 Tutorial 。如果是比较新的技术的话还是直接上官网。
2. 动手写/用，在用的过程中发现一些疑问并自己解决。解决的过程中能学到很多教程里面没提到的相关知识，方便建立比较完整的知识体系
3. 当发现有些地方实在 google 不到解决方案/自己觉得有必要更深入了解了，上源码。看源码和写源码是两码事，现在大部分语言的可读性不至于差到一个学过基本编程知识的人完全摸不着头脑（甚至不会编程的也能看出点东西），但一些语言入门知识得了解就是了。另外，上源码能更清晰看到这个工具可以改进的地方/存在的缺陷（我相信不存在没有缺陷的软件），也便于以后自己再去修改。
4. 上面都基本掌握了，那这个工具就能进入你的技术库了，你也可以考虑用它上项目了。

PS：我也喜欢看纸质书，不过现状是任何纸质书出版时里面的内容至少是半年前的了，在移动测试这个领域半年时间意味着可能只剩下 80% 左右的内容还是可以用起来的了，所以里面还是会有坑的。而且那些 “实战”、“实例” 的书籍本来就不是给初学者看的，初学者看了很容易在流沙上面筑高楼，觉得自己懂得里面的例子就学会这个东西了，结果一上项目傻眼了，这些情况和书里说的不一样啊！

2.其次你一上来就让我看源代码，请问源代码很容易吗？是 1+1=2 吗？你现在是 NBA 职业球员，就以为一个小学生就可以直接去打 NBA 了？Appium 的源码很容易懂吗，Node.js 是一个 java 还在基础阶段的人轻易能学会的？我看你们的商业培训也在从基础讲起，并没有从源码讲起？

源代码确实不那么容易，但 Monkey 的源码没有你想象中那么难，而且 Monkey 源码分析网上是有系列文章的，你可以去看看，辅助理解。至于 Appium 是比较难（编程语言上有 Java，Javascript，并且需要熟知 UIAutomator API，UIAutomation API，Xcode command line tool），但对于只想了解基础的初学者来说 Appium 的文档、sample-code、各个 client 自己的文档以及 webdriver api 的文档加起来足够入门，甚至熟练使用了。精通的话源码是不二之选。

据我所知，学编程的人也是差不多的路线：刚开始通过各种入门书只知道怎么用官方的 library ，然后通过多用和看官方文档熟练掌握，最后学习源码。

最后我想说的时，你说到的一些问题确实是问题，然而单纯把这些问题在一个公众平台上抛出来，并且带有比较强烈的指责态度，你指望能得到怎样的回复呢？换位思考一下，你见到这样的帖子，你会回复什么？另外，这些问题如果不仅仅是抛出来，而是提出后组织大家把这些书籍资料整理出来，造福未来的新人，收到的效果是否会截然不同？

测试行业是需要改变，但是单纯提问题，叹可悲是改变不了行业的。

1. 请问贴主有看过 java 从入门到精通的书吗？有看到精通了吗？这些书不一定有你想象中那么大的作用，关键还是你自己。
2. 如 monkey 所言，不断更新的领域出书用处也不大，书出版时里面的内容可能都过时了，官方文档才是王道。

#2 楼 @jennifer xml 无效会导致所有解析 xml 的程序报错，然后无法解析。
不过因为这个 xml 只是 dump 界面控件树，只是供 UIAutomator 使用，对应用实质功能没啥影响，只对测试有影响。如果表情符号不是测试点，建议在执行测试时去掉它。

屏蔽理由：请参考排版说明，代码及日志使用代码块。

那个。。。能否按照排版规范优化一下排版？现在的代码没用代码块看起来有点乱。。。