我们目前采用加入源码的方式，但前期由于我们自己的覆盖率收集也不大完善，所以通过把添加的代码做成 git patch ，然后每次打包通过 git apply patch 的形式把为了覆盖率添加的配置项及代码加上，再打出带有覆盖率收集的包（在 BaseActivity 中的 onStop 加了自动生成和上传覆盖率的功能）。测试团队在测试环境统一使用带有覆盖率收集的包进行测试，这样收集到的覆盖率信息相对比较齐全，分析价值比较大。

也和开发团队沟通过，他们的诉求是只要能确保对外发布的 release 的包不带有覆盖率相关信息（即采用 release 方式打包时，覆盖率的相关代码全部不生效或不会包含在编译后的包中），开发是可以接受把覆盖率收集加入到他们的代码仓库中的。

框架不是我写的，建议直接看源码学习吧。目前根据我的了解，用的应该是 testNG 本身提供的并行执行机制。

不用急，你已经知道好代码长什么样了，下一步就是怎么逐步优化，写出好代码了。

把 config.log 贴上来给大家看看？

好久没搞这个了，不大清楚。

UIAutomation 已经被淘汰了吧，XCode 8 开始就不支持了。现在应该用 UI Testing Bundle 了。

至于 UIAutomation 的多模拟器并行，以前在 GTAC 的视频看到过 Uber 有类似的演示，有没有说具体技术细节不是很记得。要做到模拟器同时多开，需要用到一个很重要的工具：FBSimulatorControl

学习下怎么用 markdown 语法把，骚年。。。现在的排版代码块部分太乱了，所有缩进都没有了。

lifecycle 那段，应该是用于通过 ctrl+c 关闭 stf 服务时，能给当前正在运行的每个模块发送关闭操作来实现友好关闭（比如释放资源）的。基本上每个 stf 的模块都有类似的方法。

lifecycle 相关的代码：

...
function Lifecycle() {
  this.observers = []
  this.ending = false
  process.on('SIGINT', this.graceful.bind(this))
  process.on('SIGTERM', this.graceful.bind(this))
}
...
Lifecycle.prototype.graceful = function() {
  log.info('Winding down for graceful exit')

  this.ending = true

  var wait = Promise.all(this.observers.map(function(fn) {
    return fn()
  }))

  return wait.then(function() {
    process.exit(0)
  })
}

偶的错，当时写那篇 docker selenium 文章的时候更多的是关注 selenium 部分，所以没放在 docker 板块。我看到刚刚管理员已经移到 docker 板块了。

做得很深入呀，赞~

zip -r compressed.zip path/to/dir -x *.git*

# 压缩同时不包含 .git 文件夹
zip -r compressed.zip path/to/dir -x \*.git\*

收集覆盖率这种场景经常需要把本次构建的整个文件夹（包括源码和生成的 class 文件）压缩上传服务端。此时 .git 文件夹一般是不需要一起上传的，通过这个命令就可以排除这个文件夹。

PS：一直在用一个很好用的 linux 命令帮助工具：tldr 。现在遇到命令忘了参数怎么写都直接用这个工具来查。tldr 是 too long don't read 的缩写，也非常好记。

话说，你 sonar 里面 oc 用的什么插件？这几天也在调研这个，今天试着部署了一个，结果导致 oc 相关的 key 冲突，server 无法解析 scanner 上传的数据，只能把插件干掉先恢复。。。

jacoco 配套做得很好，而且网上实践文章也多，坑比 iOS 少很多。

分享计划很好~也同意上面同学的观点，有个擂台或者相互交流的方式，能更快地促进双方的提升，顺带也能结识一些朋友。

现在坚持业余保持每天 1 小时左右的自主学习，但因为分得比较散，有些时候偷懒没有写文章 之类的而分享记录下来，后面也得坚持下来。

这个没找到合适的技术方案，jacoco 本身不具备这样的能力。而且覆盖率数据统计上也不好统计。你们现在有做这个？

如果想换框架，建议你先从 iOS 有什么 UI 自动化框架开始调研起。可以 google 下 "iOS 自动化测试框架选型" ，前条搜索结果都值得一读。

你的 embedded.mobileprovision 对应工程的 bundle id 有和你想重签名的 bundle id 一致不？

mobileprovision 中绑定了开发者证书 id 、应用 id 以及 Entitlement 等信息，主要用来检测这几者是否对的上号。如果对不上号，安装时系统会自动检测到。

好赞呀~尤其是平台的界面效果。相比之下感觉我们自己的平台界面 low 爆了。。。

从项目的实践情况来看，到了这个程度基本可以找个项目试点了。我们现在在试点中，发现了以下几个主要问题：

1. 实际迭代过程中，由于不断的 bug fix ，会出现一天一个版本的情况，导致单个版本覆盖率看起来都不高。这个技术上支持的难度比较高，还是得在流程上增加一个封版期，此期间不更改任何代码或不使用更改后的代码进行测试。
2. 分析覆盖率报告并给出建议是个体力活，需要比较长的时间去熟悉源码并整理出报告。目前在尝试和开发合作，通过添加注释的方式增加报告本身的可读性，再看是否可以通过工具自动生成一些覆盖率建议。

这部分比较细，估计没有文档记录，直接看 appium 相关源码可能更直接。

当你有超过 10 个用例，需要实现诸如报告生成、失败后自动重启应用、失败后自动截图、失败后重跑用例、断言校验结果甚至并行执行用例等等需求时，你就知道为啥需要用类似 unittest 这样的用例执行管理框架了。

很实用的技巧，赞~

不是这个，是你用脚本获取到的 page source ，不是浏览器界面或者 uiautomaterviewer 获取的。

把你 page_source 的输出贴上来？

木有。。。

建议不要随便用 “大神” 这样的称呼，社区里面对这个称呼欢迎度一般。

另外，你第二个截图里面，是先切换了 webview 再查找原生控件的，顺序错了。切换 webview 后只能找到 webview 里面的网页控件，无法找到原生控件了。

至于为何找不到元素，可以先在你查找元素前增加一个输出页面 xml 布局源码的函数查看布局情况（函数印象中是 driver.page_source ，建议你查下 api 文档），确认下是否布局里面就没有你这个元素。