现在耳机的一切需求已经通过一个 赛睿 V2 + bose qc20 满足了。耳机方面无欲无求了。

代码写，根据实际协议需要来从 response 里面取数据吧？例如 json 的可以用 jsonpath 提取数据。

以我的理解，尝试回答下你的问题

1. 各种异常参数，实际测试的是系统健壮性。建议更多地从业务场景去考虑参数组合，用例会更有效。
2. host 切换，一般是框架层面设计的时候做好，用例永远只会从框架取环境设置。我们目前的做法是在命令行加了一个环境的参数，换个参数就切换环境了。
3. 公共模块这个，通过框架的接口层完成。例如 rest-assured 通过 filter 可以完成你说的加解密或者自动加字段，用例不需要关心。（当然 filter 也是写接口测试的同学来写的，项目强相关）

最后两个 @jacexh 已经说得很不错了。至于线上数据问题，线上是不可能跑全量测试环境的用例的，需要另外有一个用例集，主要进行查询类接口的测试。

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

语言：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 。

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

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

视频链接貌似挂了？

感谢分享，sonar 可以关联质量阈这个涨知识了，我们之前都只是用 sonarlint 来扫描，一直苦于无法只以新增代码问题数来作为准出。

这个是设计如此，微信公众号、个人微信号没有电脑端的 web 首页可以跳转。

减少由于 bug 带来的损失

谢谢推荐，网站挺赞的~

完成度挺高的一个轻量级接口测试工具，对于简单的单接口测试来说还是挺方便的。

项目已 star

哈哈，能帮到你就好~

建议从小事做起，比如自己把一些执行频率最高的用例做成 UI 自动化，或者对一些最核心的接口做成接口自动化。渐渐有成效后，老大会注意到，你得到做自动化项目的机会也会越来越大。

自动化测试项目可遇不可求，但任何一个测试项目其实都有可以自动化的部分的，没必要等到很正式的自动化项目才开始。

好赞的功能，辛苦恒温~

貌似文章中除了末尾的二维码，其他图片都显示不出来，能否修复下？

试了一下，公众号里提供的百度网盘里，饿了么的 pdf 单独下载是没有问题的。能把你的下载地址发出来一下吗？

你好，在微信公众号 程序员技术前沿 找到了这篇文章，没有任何转载自此原文的声明。想问下此文章你是否有授权过给 程序员技术前沿 微信公众号发送吗？

我的疑问是为啥第一段会更快。貌似文中没说明具体原因。

思路很赞，这样测试埋点确实省力多了。