Jacoco 在计算覆盖率时，会根据每个方法的代码自动生成一个 class_id，当方法变更时，class_id 自动发生变更。默认存储到 exec 内的数据格式：{[{"class_id":"name=classname,id=xxx,probe=true,true,false"}。
其中，classname 指包含路径的类名，id 是 class_id 唯一键，probe 则是每一行是否被覆盖，覆盖了则是 true。
我们可以根据这个来判断方法的变更情况，最终实现对代码的操作； 但实际调查中，当重构服务应用后，存储在内存中的覆盖率被清空，jacoco.cli 再次解析时得到的结果覆盖率为 0。这种场景就要求每一次服务变更后，你都需要全量执行一遍测试才能获取覆盖率。 而当前企业架构内是需要调用过这个方法才会将探针 probe 改为 true,这样就导致每次服务不是后都需要重新执行脚本才能正确获取覆盖率。

新的版本中需要将报告文档做对比：
1、每次扫描前生成一个 base.exec 作为基准报告，内部包含了所有 classe_id。
2、每次生成新报告前，自动备份上一次的 exec 数据文档；
3、自动将本次的数据文档 jacoco_new.exec 和上一次的数据文档 jacoco_old.exec 做对比，将对比结果保存到 base.exec 内，最终作为 jacoco_result.exec 保存。对比逻辑如下：
任何场景，只要 base.exec 内 class_id 存在，那么必然需要一个结果。
add 场景内，base.exec 必然存在 id,此时 old 不存 id,取 new.exec 的覆盖率放入 base.exec;
update 场景，base.exec 必然存在 id,此时 new.exec 内也必然存在 id,而 old.exec 内的 old_id 由于与新生成的 id 不同，通过 oldjson.get(id) 无法获取数据，此时视为新增，将 new.exec 的覆盖率放入 base.exec；而原本的 old_id 则视为删除，自动忽略
nochange 场景，base.exec 必然存在 id,此时如果 service 服务发生过重构，内存中的覆盖率丢失，生成的 new.exec 内不包含这个 id,但由于代码未发生变更，此时 old.exec 内 id 依旧存在且与 base.exec 的 id 相同。此时通过 oldjson.get(id) 可自动获取上一次的覆盖信息，将其赋值到 base.exec 内
delete 场景，base.exec 内的 id 无法获取，此时直接跳过。原本存在于 old.exec 内的数据不会被查询，自动忽略
4、针对 jacoco_result.exec 直接解析结果即可
通过这样处理，就可以保证每次代码不变更的前提下，代码覆盖率也不会发生改变。 一方面可以减少扫描范围；另一方面每次改动后的结果更适合大屏播放。 (原版本只会展示修改过代码并执行了用例的那块覆盖率)

其实俺们更想线下见见面。

我次哦，这玩意我现在居然忘得差不多了

亲测，官网链接里的 chrome 插件下载 404，这是多久没人维护了

kafka 数据查询和使用，大数据测试会问。 问 K8S 的话赶紧润，他们是招运维的

干了 3 年的公司，开发转测试，后来忽然空降一个测试 TL，功能测试还行，其他基本都不会。果断撂挑子，2 个月后跑路。我走了之后一个月，那位空降 TL 也跑路了，你说这是为啥？

将其中 coca_cmd 指向 coca 可执行文件 的路径即可。
请教下，这里的 coca 可执行文件是指什么文件？如果是自动生成的，是从哪生成的呢？
方便给个样式吗

支持下 metersphere，不为别的，java 写的。适合大规模使用。

期待开源

夯实下基础知识（一面用），然后总结下最近干的项目（二面三面用）