我们基于 ms 2022 年初的 v1.17 做了二开，删减了一半的功能，增加了几百个需求和优化。 基于 1.17 版本可以后端打 jar 包，现在把前后端代码分离管理了

用内部项目尝试了一下，行覆盖率有点偏低，大致在 30% 左右。按照谷歌的行覆盖率标准，仅用这款工具，目前还达不到 acceptable 标准。

逆水行舟，不进则退，无退路可言

前端表现力很赞

有理论，有实践，有分析，有建议。 深度好文，来扩充下视野

body 参数不重要，本质都是 super.getResultNode()

@Override
public Object getSummaryNode(HTMLElement body) throws IOException {
return super.getResultNode();
}

每年都有这么多本专业和它专业的毕业生进到这个行业，但工作岗位不会增加同等比例，门槛只能越来越多，越来越高。想着不学习，不努力跨过门槛，只能待在原地和更多的竞争者卷了。PS: 就算跨过了门槛，和同 P 级的研发开发水平比，差了多少倍，大家心里没数儿么，这已经是放了很大的水呀。技术要求差那么多，薪资也给上去，借口都是来糊弄自己的

主要是检测发布平台当前部署的版本是哪个，然后去到打包平台下载对应版本的源码，还有就是从部署平台拿部署 jacoco agent 的 ip 用来下载 exec。 我这边不是业务部门，没有 app 的需求，所以没有做这块。按说可以在打包编译期增加 jacoco 的统计代码织入，后期 app 运行后再从 sd 卡获取 exec。这篇文章可能对你有用：https://zhuanlan.zhihu.com/p/88317244

首先分析一下 exec 是否包含其他模块的覆盖率统计，也就是监测的服务是否包含了其他模块代码。
然后看报告是否需要按照模块来进行统计，如果只想看到，不介意各模块的包在同一层目录统计，用 MultiSourceFileLocator 就可以

 MultiSourceFileLocator sourceLocator = new MultiSourceFileLocator(4);
for(File sourceDirectory : sourceDirectorys){
    sourceLocator.add( new DirectorySourceFileLocator(sourceDirectory, "utf-8", 4));
}
visitor.visitBundle(bundleCoverage,sourceLocator);

如果对按模块统计有需求，需要上 MultiReportVisitor

final IBundleCoverage module1BundleCoverage = analyzeStructure(classDirectorys.get(0));
MultiReportVisitor mrv = new MultiReportVisitor(visitors);
IReportGroupVisitor irgv = mrv.visitGroup(appName);
irgv.visitBundle(module1BundleCoverage, new DirectorySourceFileLocator(sourceDirectorys.get(0) , "utf-8", 4));
irgv.visitBundle(module1BundleCoverage2, new DirectorySourceFileLocator(sourceDirectorys.get(1), "utf-8", 4));
mrv.visitEnd();

以上代码供参考

按两个方向说：
① 代码版本变化了，如果没有重新部署，就是按照旧的代码进行报告生成，新代码对环境和报告无影响。我这边的代码版本是和公司的发布平台对接的，代码构建部署后，才按新代码生成报告。另外重新部署后覆盖率肯定会清零，但可以和老版本代码的 exec 合并，用新代码生成合并报告
② 实时染色页面停留这块，每刷新一次报告，都会删除旧的报告，展示全新生成的

先留言瞅瞅

是的，覆盖方式。前端做定时器调接口，接口每次生成报告时候都删除指定项目环境下的报告，生成一个新的。如果需要永久保存的话 ，可以走保存功能，去别目录再存一份

百度报错内容，前三条可解

正好这周末没啥事 抓紧写了

原生报告有的 RD 和 QA 看不太明白，不够直观。并且发报告时候还需要把各包层结果统计后自己调格式，再粘贴到测试报告里，不统一且有算错 (也包含故意) 的可能性，

还真是 大意了，已改正