这种方式挺不错，可以解决配置问题，但历史数据问题如何解决？

最近线上出现了一次异常，原因是一些数个版本前的数据库数据不是以 json 字符串形式存储的，而新的开发不清楚这个，没有对应加上 json 字符串校验，导致读取解析时报错。

这些数据大概是半年前的，测试环境也没有，是开发通过线上异常预警才发现的，所以测试环境也很难发现。

需要具体问题具体分析。我只是说我们常遇到的问题。

你们遇到的正式环境能出现，但测试环境不能出现的问题有哪些？具体原因是什么？

PS：无论怎么模拟，线上终究会和测试环境有区别的。建议通过增加灰度测试环节来降低这类环境问题出现的影响面。

麻烦用 markdown 格式排版吧。现在的格式代码和正文混在一起，很难分辨。

另外，ddt 具体是什么框架，能否也说一下？之前没见过。

一般来说，这类问题会集中在数据库的旧数据兼容问题以及配置项没有对应做好变更。

能具体说下你们的问题是什么吗？这样信息量有点少，引不起讨论。

受教了，写得很细！

感觉是网站 SEO 没做好，html 爬虫直接访问读到的是模板信息，而非渲染后信息。

楼主写的很详细，赞！

不过，建议后续可以考虑用网上现成的安装脚本或者直接用封装好 jenkins 的 docker 镜像。效率上高很多，而且也容易避免配置文件改漏或者改错这类问题。

第三期了，支持！

挺不错的，想问下有考虑支持 callback 类型的 mock 不？不少第三方是通过 callback 的方式返回数据的。

现在耳机的一切需求已经通过一个 赛睿 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 带来的损失