改动过，必测过---增量代码测试覆盖报告

希望解决的问题：

有些代码改动了，但没有被测到。

目标：

通过提供“本轮DEV改过，但测试环境没有跑到的代码”的报表，指导QA补测这些地方，实现“凡改动过，必测过”。

借鉴的思路：

1.通过GIT 拿到当前正在开发的DEV branch和产品的Release branch之间的差别，识别出改动过的代码

diff_cover 请参看（https://tech.youzan.com/you-zan-go-xiang-mu-dan-ce-ji-cheng-zeng-liang-fu-gai-lu-tong-ji-yu-fen-xi/ 里的 四、集成测试增量覆盖率分析）（https://www.jianshu.com/p/18c284cd3fa0）

2. 通过jacoco得到测试环境的累计的代码覆盖情况

需要实现多个版本测试覆盖率的合并（例如，昨天的QA版本和今天的QA版本，虽然source code改变了，但是coverage能够累加，而不是每次都生成一个新的）。

参考 https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA%3D%3D&mid=2455758761&idx=1&sn=0f758117c1aee1cf34565b7a57e7416f&chksm=8c68618cbb1fe89a0d56996e43648c916a41a3496be7a407956a4f6ed8a9028de81b1c6a0b02&mpshare=1&scene=23&srcid=0405YHtuC8yHr5Ee8DMJzrrL%23rd 提到的“在项目测试过程中，会遇到需要重新发布代码的情况，此时大部分人不希望之前测试覆盖的记录被清空，希望对 dump 出来的覆盖率进行累加。对于虚拟机，只要在 javaagent 参数里面设置 append=true（默认就为 true）即可，但对于用 docker 部署的应用，每次重新发布，原先的 exec 文件会丢失，且 ip 也可能会变，需要找运维团队进行配合支持。”

3. 通过1和2，得到本轮改动过，但没有被测试覆盖过的代码。

实践结果：

在diff cover report基础上我们做了一点改进（红色部分），将没有覆盖的行的修改人和修改comments显示出来，这样可以按照comments里的bug#或者story#快速定位到这个改动和什么相关，方便各个QA迅速找到自己负责的story/bug中没有覆盖的部分，并找到对应DEV进行讨论。