1.可以把链路上涉及到的服务都以单服务维度进行录制回放
2.做全链路的流量回放，把对数据库做改造，比如影子库，但是这样成本比较大，涉及面太广

必须可以

欢迎

是的

中间人代理具体能讲讲么？repeater 的录制回放是单服务维度的，并不会涉及到问题 2

可以把验证 Authorization 的方法 mock 掉

不是通过 log 具体可以看看这篇文章 https://testerhome.com/topics/23534

可以 我们是 ecs docker 混部的

问题一 怎么解决这个成本和收益的问题呢？

在平台落地过程中, 我们也发现单测的成本问题, 不仅是研发侧为提高单测覆盖率付出的实际编码成本, 更是研发侧对覆盖率指标的质疑。

我们摸索出的可行模式: 收窄覆盖率指标, 看的见的收益

1. 从整个 Repo 的覆盖率指标收窄为热点代码块的覆盖率指标, 热点代码块的来源是根据线上代码执行的频率选取的
2. 从历史代码问题导致的 Bug 中, 统计出能在单测阶段发现的问题, 并以此形成单测改进规范, 推动规范落地 这样达到的目的就是让研发侧真切的感知到, 你的单测覆盖是真正跟线上功能和故障捆绑在一起的, 而不是一个 KPI 指标。

问题二 单测的覆盖率目标是怎么做到合理的设定？

从以下几个维度考量设定:

1. 当前项目单测实际情况
2. 当前项目的是否为核心服务
3. 当前项目本季度的业务开发繁忙情况
4. 覆盖率指标选取 (行/方法/分支...)

总结下来就是: 在不影响业务开发情况下的一个够得着的覆盖率指标。

如果想了解如何从数据维度衡量代码质量，建议您看看https://testerhome.com/articles/24210。

看来您也是行家，感谢支持~

没有实践过，但我认为可以这么做：每个 SDK 独立插桩，独立调用接口上报覆盖率信息，独立维护 sourcemap 进行映射。依赖 SDK 的总工程，是没有办法帮助已编译的包插桩的

在我们的工程实践中，是的。但具体用法参考这个啦：https://github.com/istanbuljs/babel-plugin-istanbul

原生的 jacoco 是按 class info 来区分 exec 文件，如果测试阶段的代码一个是 A 分支，一个是 B 分支，如果这两个都是从同一个父分支上 clone 下来的话，那这俩分支 merge 是没有问题的，如果这两个源分支不一样，merge 的时候就会失败。。所以这其实应该是个代码规范问题，因为一般来说都是从 master 上拉下来几个分支，然后开发在上面开发自己的代码，测试的话就部署这些开发分支测试，这样的分支是可以 merge 的，而且因为咱们的覆盖率是按不同环境来的，一般一个环境下的 merge 是没有问题的，如果要把不同环境比如 stable 和 sit 环境的覆盖率 merge，我这里还没测试过，目测是不行的😳

平台提供了 merge 功能，测试同学可以选择把 srint 开始到结束的覆盖率 merge 起来，拿到的就是一个完整的覆盖率数据。

速度大概在一分钟左右，但是因为咱们的手动环境下的任务比较多，有时候 cpu 比较满的时候可能要花上五分钟左右等待队列。

说说我的理解：

• nyc 是新版 istanbul，解决了大量 istanbul 存在的问题
• nyc 和 istanbul 都用于【本地运行，本地统计覆盖率】的场景
• istanbul-middleware 是 istanbul 的一个 用于【多端运行，在服务端统计覆盖率总和】的场景

然后说说问题：
istanbul 有问题，一般报告和实际覆盖的行，往往有一两行偏差。我们对比过 coverage 和报告中的覆盖行数确实是一样的，因此我们怀疑 babel-plugin-Istanbul 太旧，如果工程用到较新的 babel/webpack 编译时，插桩可能就不太准确

如果我理解没错的话：

• 你贴的 Repo 似乎仅做了单元测试，属于【本地运行，本地统计覆盖率】的场景，这并不需要用到 middleware。升级 nyc 是没毛病的选择
• 但 nyc 未提供 middleware，对于【多端运行，在服务端统计覆盖率总和】的场景，我暂时没有什么好的解决方案

不知道我理解对不对，你有什么好想法我们可以接着讨论

楼主你好，我想实现一个功能，就是在 console 的服务器上先调用 pushConfig 进行配置推送，然后马上调用 repeat 进行回放。但发现似乎执行 pushConfig 以后，配置生效有一定的延迟 (repeat 使用的还是旧配置)，不知道楼主知道是什么原因吗，怎样优化可以马上生效？

当然如果强制等几秒以后，再调用 repeat 的时候配置是生效的，但不想这样强制等待，似乎不太优雅。

感谢楼主~

申请开通专栏~

感谢恒温大佬的支持

不知道你会在什么情况下发生统计不准确呢？

我们在实践过程中发现，有俩坑：

1. 如果前端工程发布前做过代码混淆，那么覆盖率统计是不准确的，但未混淆代码的统计是基本准确的
2. 产品迭代过程中会产生代码的 commit 和 merge，并产生不同版本；但不同版本的覆盖率的累加难以相应 merge（或者说我们未能找到支持覆盖率 merge 的库）

同时感谢你的回复，我们调研一下 nyc。

1. 本身 jvm-sandbox-repeater 这款工具已经通过 mock 的方式解决了依赖问题。
2. 首先，目前我们的流量存储在 ES 中，并没有做备份。其次，对于"数据库备份库是如何控制在录制时的准确时间节点的"是基于何种场景下的需求呢？