已经很久没有使用这个框架了，所以你的问题我没法直接回答。不过，有几个问题定位思路你可以参考下：1、换个模拟器试试，相对而言模拟器的权限开放更加彻底；2、单独将 hook 失败的 apk 拿出来验证下，不用配置文件的方式；3、确认下 hook 失败的 apk 权限设置和其它 apk 有什么区别。

任何一个在大学里学过编程语言的，基本上一个月就可以上手了，真的没有啥难度。
——上手难易程度和技术深度没有直接关系，不是难以上手的技术才叫技术。自动化测试的核心竞争力之一就是尽量降低上手难度，让尽可能多的测试人员能够无障碍使用，为了达成这一点本身就需要很深的技术

编程能力或者技术能力很容易到天花板，很多人学了一身的开发技能，在公司中根本用不上，大多数还是以手工测试为主
——天花板有，但看你愿不愿意伸手去推它。你看到的天花板往往受限于你所处的环境、你们的产品性质、你们的流程管理等等，有客观的因素，但最主要的还是你们团队和个人对于产品的质量追求，自动化测试往往只有在主动改进的团队能发挥用处，而且一旦你们积极去做，就会发现没有什么开发技能在自动化测试中是用不上的，懂得开发才能更好的做测试。

我看了很多外面自动化培训班也就 app 自动化测试，web 自动化测试，接口自动化测试反复在滚概念，这本身对这行业没啥发展，招聘也是千篇一律的上述这些
——测试是围绕产品的，如果产品的对外呈现方式就这些，自动化测试的范围也就只能是这些，总不能凭空测莫须有的东西。而且这些只是基础，在这些基本技能上衍生的如契约、性能、可靠性、兼容性、UI 体验、安全等自动化测试，你真的都了解过吗？

真的技术强的早转开发做架构师了
——自动化测试技术强的人不仅仅对产品架构很熟悉，更重要的是他对产品质量和如何保障产品质量的理解很深，这样的人不一定要转开发做架构师，还有很多领域是他完全能胜任的。

其实测试现在这个局面还是以手工测试为主，如果你说 app web 接口跑完出个报告也算技术的话，我真是没话说了。知道很多人不服气，但是自动化测试真的没啥技术含量，其他技能很少或者根本用不上。自动化测试技能对测试人员来说真的很鸡肋！！！
——如上，你可以认为自动化测试没啥技术含量，但做好自动化测试从来都是一件很有技术含量的事。

appium 客户端中 webdriver 管理的部分实际上就是 selenium，上面这个命令也是 selenium 中默认就有的参考

以python的appium客户端为例：

在webdriver初始化的地方添加reconnect参数

如果reconnect为true的情况下，直接获取server端的session信息，并直接将这些信息保存至客户端脚本上下文中

调试时，脚本代码中只要将reconnect值设为true就行了

有点复杂，介绍下我们之前用 appium 调试的简单思路：

因为 appium 是 C/S 架构，每次测试执行的上下文信息都保存在 appium server 端，其中最主要的就是会话 session，所以，只要重写或者添加个 driver 初始化的方法，先去 server 端获取下已存在的 session 信息，就能实现无需重启的单步调试了

可以参考ApiMatic，能实现各种借口定义之间的转化，我们项目使用了 Postman collection -> Swagger 的方式，配合 chrome 到 postman 中的导流功能，接口定义生成本身的成本不高。

2、接口文档标准化，很多时候真的是可遇而不可求，特别是在中途接手一个质量不是很高的项目的时候，接口文档滞后或甚至是没有。实现自动生成测试用例这块儿，不知道你们有没有成功实践经验，可否分享下？

—— 看下 swagger 吧，一种标准的接口定义规范，可通过代码注解或者 postman collection 自动转化生成（当然也可手写^{），而且也是 yaml 格式，挺适合你这框架的}

从个人经验看，接口测试的最佳工程实践应该包含从开发的接口定义到测试脚本（至少是单接口的参数遍历脚本）全自动化生成，这样才能保证接口测试的准确性、覆盖率和运作效率。

1、如果用 xposed 的话，你要知道请求最终是调用系统的什么接口接受响应内容的，然后 hook 对应方法就行
2、但个人不推荐上述方式，因为你要自己构造各种响应结果，这个工作量很大，建议直接使用 peach，有非常强大的 fuzz 测试能力

WebElement 监听的不一定是 click 事件，还有 tap、touch，这几个是不一样的，你可以都试试

批量操作这种建议做成接口测试框架本身的功能，比如你在请求中加个占位符test%100%，表示该请求从test1、test2...test100自循环 100 次；同理再加个全局的随机值，如 $RANDOM$，这样和上面的搭配在一起test%100%$RANDOM$，就可以基本保证你每次运行产生的数据都不会冲突了，而且脚本会很简洁

我们目前在搞的精准测试方案是这样的：通过分析变更代码的调用路径，找到最上层的触发接口，然后测试对应的接口请求。

但是有个比较扯的疑问，我们把所有测试接口跑一边也花不了多少时间，搞这么精确的意义在哪=。=

Q：Android 6.0 及以上版本时，卡在授权界面？

这个问题可以通过解析AndroidManifest文件中的permission声明，应用安装之后启动之前再使用 adb shell pm grant <package name> android.permission.* 指令解决。

当然，这样并不符合真实用户的使用场景。

建议接口改用 csv 文件，否则数量多了之后很难通过配置库管理

#37 楼 @appetizer.io 嗯，基于坐标的局限性太大了，根本没法应对界面加载延迟、分辨率变化、界面变更等导致的非确定过程，说白了，容易沦为一次性买卖。但如果通过控件解析的话，有个问题比较好奇，对于 WebView 页面，要怎么把初始的坐标操作转化到对应的 Html 控件上呢？还是说解析的时候，就把 WebView 上的控件作为 Native 视图下的元素？

请教下，这个录制回放的功能是基于坐标点还是控件解析的？

提供几种思路：
1、最简单的肯定是搞清楚为什么会弹，设置下就行。
2、写一个继承 accessibilityservice 的辅助应用，监控弹窗，自动点击（不适用 uiautomator 模式）
3、在底层的点击、输入和检查方法中加判断，如果失败了看看是不是此类弹窗造成的，是的话处理掉重来一遍。

—— 来自 TesterHome 官方 安卓客户端

#3 楼 @summiter appium 我这真机模拟器都可以，但 uiautomatorview 一直没看到 WebView 子元素过。

—— 来自 TesterHome 官方 安卓客户端

真机也不行。

—— 来自 TesterHome 官方 安卓客户端

#89 楼 @yrguo_iflytek 你这设备是一直这样，还是偶尔出现这种情况？必现的话感觉没什么救，偶现的话通过 adb 重启下手机上的 minirev 服务：
1、ps |grep minirev 杀掉已经起来的服务；
2、adb shell LD_LIBRARY_PATH=/data/local/tmp /data/local/tmp/minirev 重启下服务 忘了，会自动重启该服务的

在 testerhome 的一段时间受益匪浅，作为一名新人，希望能共同成长，越来越好！

#65 楼 @quqing ios 可以通过 uiautomation 脚本 UIATarget.localTarget().logElementTree() 读取。将以上语句导出为 js 脚本，再通过 cmd instruments 命令执行，应该可以，未经验证。

#57 楼 @seveniruby 功率，自带的电源的 usb hub。刚发现 20 台还是不太行，mac 的内存爆了 ，4g 物理内存耗尽，还用了 6.6g 虚拟内存。也就运行了不到一星期而已。

#55 楼 @doctorq 不是这个意思，你文章中的方法更偏向于屏幕监控这种画面不间断的实时传输，所以需要也应该起这么多服务。不过就截图而已，我希望的是 adb shell screencap 这样一次性的操作，前后两次之间最好不存在关联，这样的话里面的流程就显得有点长了。

#52 楼 @quqing 直接用 uiautomator dump 应该是最快的: adb shell uiautomator dump /data/local/tmp/uidump.xml