这个 nice 了，不用发贴之后才发现一堆错别字

不是第一生产力，测试能做的就是：促进生产力，这种促进法，也是由于第一生产力的能力不足以支撑业务的发展，其实第一生产力足够支撑业务，再投入成本促进生产力的边际效益就低了，但目前没有一家公司敢说不用促进生产力的，所以做为一个能够提升生产能力的角色，测试人员可以做很多，质量保证也是提高生产力的一种，工具平台支撑也是一种，可以做的东西很多，价值也会在实现中体现出来，关键是看一个测试人员是仅仅盯着测试两个字看，还是立足于行业，业务，团队以及未来来看

我们这边的解决方案，去年大会上讲的 warship:http://m.imooc.com/video/12550

要先看看 adb devices 连接的设备正不正常，看不到或 offline 都是不行，appium 也是调 adb

你用个同屏连接到电脑上，然后 libcecap 去录电脑上就挺方便的，都不用传回图片到电脑

那你找找看回车是哪个吧，差不多是这样了

1、用 docker 作基础数据库，维护一套标准数据
2、利用 diffy 的方法回流收集线上数据作为测试数据

首先你要理解什么是 rpc，rpc 本身已经是和业务结合起来的，不同的业务可能用法还不一样，还有 grpc，目前很多都是在 http 协议的基础上写的，具体的还是要结合业务，rpc 更像一种定制的内部规范，要测这类接口的话其实和测 http 也差不多，关键是用什么样的头格式，api 格式以及 body 格式等，可以了解一下springcloud

这场景下的输入法中的搜索即回车确认按钮，对应的 keycode 是 66，相当于模拟点去确认按钮就好，试试

已用两年，还有 Mac 版，神器，如果可以用来做录制测试用例更好，正在研究中

社区现在挂在腾讯的那本

个人信息那里有

docker 就是有这个好处，做接口测试，肯定有一套基础的测试数据，这套数据就是存储在测试中要用到的基础数据库，docker 可以将数据库以镜像的形式版本化，以及挂载不同的数据卷，这样的话就可以做到测试前的数据和测试后的数据是分开的，要执行第二次的测试，其实只要还原一下到基础数据库就好，以前的老办法就是直接在测试数据库上删数据，或者导出一些 sql 做冷备份，对比现在，只要一步还原就好，而且速度很快

你的问题我也遇到过，估计你有可能比较多用 xpath 定位吧，每台手机上同一个应用的 xpath 是有所差异的，我之前在 iPad 上定位的元素在 iphone 上定位不了的，对于 xpath 的定位，我用自底而上的方法，就是用最深的那一层先匹配，因为这层上必定匹配到的，然后一层层上来，这是为了降低查询效率，最后匹配到这几台机器都能识别到的 xpath 路径，对于滞后的问题，涉及网络层和硬件层，我只能说可以优化，因为这可能要去优化 wda，adb 等支撑模块

谢谢鼓励 ，欢迎多交流交流经验哈

多交流交流

今天有点倒霉，车被撞了，都不知道能不能及时修好，希望最好赶在下周六前搞定吧，不然去深圳参加社区活动就有点麻烦了，写一下文章定定神，总结一下，也当激励一下自己吧

小弟向高 P 低头，膜拜 orz

我目前对 bug 管理工具接触还比较少，但我自己了解到的有两种，一种就是比较针对性的 bug 管理平台，bug 是平台的基本元素，研发，测试整个 bug 的生命周期进行工作计划或安排，同时也会有比较专业的模块统计分析以及 bug 版本管理等，另外一种是通用性的，其实是项目管理平台，缺陷管理是其中的一个模块，，综合来说，其实 bug 管理工具具备了项目工作流和统计模块就基本能用的了，但我个人比较向往有一种可以通过历史版本的 bug 数据预测之后版本的 bug 分布以及能通过数据分析提供相应风险应对措施的 bug 管理平台，这种是可以结合当前测试智能化的一个趋势下做起来的，不过这种的话可能就偏向于大公司大项目了，因为小团队小项目的话，数据量可能不大，当今互联网时代一切都是说数据，bug 也是数据，做好数据分析，加以利用以之来预测下一步，这是比较客观的做法，朋友您有兴趣的话也可以研究一下

JNI 这种本来 anyproxy 就不支持吧，如果需要做 jni 的 mock，还不如直接在代码上对方法或 api 做，而且最好理解一下 stub 桩服务器和 mock 程序的区别吧，我也是最近才理解区分 stub 和 mock

（2017.08.05 更新）
1、修复在 windows 上执行的 bug
2、增加-d 参数，可选择从第 n 台设备开始执行自动化测试，配合-p 和-sp 参数使用
3、已支持 ios，android，web，api 的并发自动化
脚本化的框架应该到此为止了，接下来会转入对平台的研究、无线连接和空闲机器调度策略上

能发一下定位这个元素的代码？

检查一下真机设备的模拟事件开关开启了没，没有的话是跑不了自动化的，第二个，windows 上跑还有个小 bug，今天再更新一个班

其实现在的核心应该还是数据监控和数据分析，执行的话相对还比较好实现一些，期待楼主把未来那块补全，加油

之前已经实验过了，以为搞多个 docker 的 jmeter 轰炸机，后面看看执行效率和资源消耗情况，还是算了，感觉多此一举，为了用 docker 而用 docker