我给一些差异点吧，仅供参考。利弊的话，需要结合团队实际说才有意义。

语言：RF是 python ，Jmeter 是 java + JavaScript（写 beanshell 要用到）
编程语言能力要求（特指语法熟悉度）：RF 有一些，Jmeter 基本可以没有。
灵活度：在不做二次开发（即改动到库函数或者框架源码）前提下，RF 比 Jmeter 高一些。
泛用性：RF 除了做接口，还可以做其它形式的自动化，例如 UI 自动化。Jmeter 除了做接口，还可以做后端性能。
生态圈：个人感觉 RF 相对活跃一些。

瞬时弹窗指的是 toast ？

剪烛进平安了？

我理解的覆盖率有两类：白盒角度的（代码/配置项执行层面）、黑盒角度的（需求要求的覆盖、需求以外补充场景的覆盖）。一般情况下，测试覆盖率说的是后者。

单元测试的代码覆盖率是白盒角度覆盖率的一种，也是代码覆盖率的一种最常见的应用。不过，前提是你们有单元测试，否则没什么卵用。

除了单元测试的代码覆盖率外，还有集成测试（你也可以理解为手工测试）的代码覆盖率，即直接获取一个正在运行中程序的代码覆盖情况。这种方法核心工具用的还是和代码覆盖率一致的覆盖率收集工具（java 用 jacoco，javascript 用 instanbul ），不过一般要配套平台来自动收集和生成报告（我所在的组现在就在做这个），否则使用步骤太复杂了，落不了地的。

这方面以前调研的时候写过一篇文章，有涉及到单测覆盖率和手工覆盖率获取方式的区别，你可以参考下，也许能够有些启发：
React Native 代码覆盖率获取探索 (一)
React Native 代码覆盖率获取探索 (二)

代码覆盖率如果没有足够的代码能力去好好分析和增加代码覆盖（比如你从报告看到第100行没有覆盖，有没有能力分析出这一行对应什么功能，评估通过什么样的用例可以覆盖，以及是否有覆盖的价值），其实就只是一个指标而已了。集成测试的变更覆盖率目前没有现成开源工具可用，必须自研（核心点在于如何把代码变更集融入到覆盖率报告的生成中），不过一些思路或者方法分享倒是有不少，你可以在社区找下，之前美团在他们的公众号好像也分享过一个。

建议你考虑清楚，你需要这个覆盖率到底是为了应付老大们的需要，还是真的为了精细地衡量好每次测试的情况，并逐步根据覆盖率情况去改进测试方法，提高覆盖率。如果是后者，才值得投入。前者的话，给个黑盒角度的大致覆盖率就足够了。

不行具体是什么？

你这个问题是比较特定的问题，说实话我没有遇到过，所以很难给出完整的解决方案，只能根据经验和了解给你指一下方向。需要你提供足够齐全的信息。单纯的 “不行”、“失败” 很难帮你定位问题。

公式我觉得没啥问题，但可行性建议你考虑下：

1. 产品设计的所有功能点这个比较难量化，需求的形式千变万化，很难统计。
2. 自动化测试的覆盖率，从你的理解上看应该是代码覆盖率中的行覆盖率了。初期用这个确实可以，但要收集覆盖率，你需要衡量好现有的工具使用难度，以及自动化水平是否已经到达可以统计这个覆盖率的程度。

这些覆盖率如果收集起来非常费事且难以统一，最后还是没啥用的。建议先找下，老大们想要的是怎样的覆盖率。说不定只是作为一个参考值，那只需要用例里体现就好，比如开始阶段全用例执行，覆盖率90%，后面主要执行高优先级，覆盖率是 高优先级用例/全用例 。

我们是筛选了一套规则，分好优先级，新增代码有严重级以上问题不能提测。目前是提测邮件截图说明，有pipeline自动检查会更方便。

INSTRUMENTATION_FAILED: selendroid.com.kuparts.service/io.selendroid.server.ServerInstrumentation

顺着这个方向 stackoverflow 一下吧。

另外，除非是要在 android 4.3 以下或者其它特殊需求，automationName 建议不要设为 selendroid 。

你的内测需求是什么？也许你想的内测和现在大部分人理解的内测不大一样？

如果是想大规模内测（例如数千人），我觉得更接近灰度测试了，可能用灰度测试的方法更合适。

视频链接貌似挂了？