仅楼主可见

我先去解个题哈哈哈。简历先不急

介不介意被裁的来占个楼

那肯定是要想办法改正的；
关于要提升的东西，也在慢慢思考，一言难尽

没有呢，暂时没涉及到 kotlin 的项目需求

本人没有招聘经验，面试经验也不多，但将心比心，面试官和面试者在心理上很多地方也是互通的。

• 其实作为面试者，有一条挺重要的点就是理解面试官的意图，一个动作、一个表情、一个词语、一个姿势变化、一个语气的升降调，那些面霸除了基本功扎实以外，这一点做的也都不差 (可惜我不行，我也不喜欢去往这方面钻。以前就曾经载在一个稍微 “狡猾” 的问题上，虽然至今为止我也不认为我的回答有问题，只不过考虑的点不同而已)。奈何世界上多数人还是普通人，能做到可以清晰洞察面试官意图的人，还是少数，可怜的我是多数那一批。

• 如前面有哥们所说的，我也很喜欢"味道"这个词，其实味道对不对、三观互相合不合，几个问题问下来，基本上面试官和面试者都基本清楚了。再后面的就是即使三观或者味道不是百分之百合，如果有一方可以在一定程度上降低期望，那也是有可能完成合作的。

• 个人感觉，找工作跟谈恋爱是一样的，需要三观合又可以互相对对方起到积极作用。有的人喜欢一见钟情、有的人喜欢日久生情,但到最后一般都是三观合、互相扶持、又愿意互相欠就的人，走的长久。

• 一个人一生也就那么点追求

  • 找到合适的人过一生、
  • 找到合适的工作好好忙几年，多者几十年，至于中间碰到不合适的或者说不那么合适的，那些经历也不是完全无用。

有点啰嗦，共勉

啥情况

2019 最喜欢的话题，可惜还没有机会去深入研究，等有时间了一定好好分析下，他们的实现估计短时间内不会开源，所以需要自己摸索吧

杭州人民又无缘

占楼，已填

感谢提问，其实我对 jacoco 的理解也是有限的，很多原理性的东西或者更深入的东西我也不会 。
看完描述，我首先想到的是贤弟 (妹) 可能没有读完这个文章的内容，这个怪我文笔不好写的太啰嗦了，道个歉哈。
本身没有搞清楚你这四个工程是个怎样的结构，我姑且以为你这个四个工程属于父子工程（隶属一个 git url,而不是项目间交互），以此为基准，下面就聊聊你提到的几个点：

---

问点 1： 项目是用 dubbo 框架

答： 首先你提到 dubbo 框架让我心里一虚，因为我对 dubbo 的理解只停留在表面，所以我只能按照我理解的来说 (当然可能会错,这个需要你识别一下哈。)
dubbo 本身是基于接口进行的调用，所以你对 dubbo 的调用覆盖，势必要到 provider 端 (因为实现都在 provider 端)，一般来说，dubbo 项目会专门提供一个 client 端的 jar 包或者 GAV(通常是纯接口)，供 consumer 端调用，这至少在我理解的我们公司项目是这样。就比如你的 A B C D 四个项目，可能你对 A 项目发起的请求，它内部通过 dubbo 调用了 D(provider) 项目的接口，那么相当于你对 A 项目进行测试，那么这一部分测试一方面覆盖率你 A 项目的部分代码，另一部分也覆盖到了 D 项目的代码实现，虽然你在 A 项目中有用到一部分 D 项目的代码，但是可能它提供的都是接口，你 (应该) 是没办法统计到这些 D 项目中的具体实现。这个要计划清楚

---

问点 2： 但 182 上面三个应用没有 tomcat 怎么拿到覆盖率

答: jacoco 的本质工作机制，并不依赖于哪个 web 容器，它需要的是一个动态的或者静态字节码插桩，就是你这个应用或者 java 代码不管将来怎么运行，这并不重要，重要的是要给它插桩的时机 (也就是 class 的生成和运行)。这个点理清楚了，你下一个问题也就不是问题了。所以你这个问题就追溯到上面提到工作机制的 java -jar，如果你最后没有收到覆盖率数据，那我猜可能是启动命令写错了或者端口没有规划好，或者去参考下文章说的那些覆盖率报告为 0 的场景，有没有命中。

---

问点 3： 我参（尝？）试了在 java -jar 启动参数里面增加 JavaAgent，开启了三个监控端口，不知道是否可行

答： 肯定是可行的 ，完全支持这种机制。

---

问点 4： 这 4 个应用的覆盖率报告如何合并然后显示在 Jenkins 里面？

答前半句 (能否合并):

• 肯定是 OK 的，具体去看下这个文章的主题 (十二),覆盖率数据是可以合并的。

答后半句 (能否在 Jenkins 上运行):

• 我猜你想集成到 jenkins 上。这个我没法肯定回答，因为我暂时没有用过 jenkins 去统计这个覆盖率，我一直以为 jenkins 只支持单元测试的覆盖率统计 (可能显得很没文化，孤陋寡闻了哈)。 这个建议先去了解下你希望用 jenkins 能做到什么地步，如果它支持自定义覆盖率数据 (就是 exec 或者 ec 文件)，那么结合源码和 class 文件目录，那你这个目标应该是没问题的，上面覆盖率数据合并之后丢给 jenkins 去统计就行了。 如果 jenkins 只是支持像执行单元测试那样才能统计，那我暂时没有好的建议，你或许可以发帖求助下社区。

说的都是大实话，哈哈。
俗话说的好，提出问题和现象并不难，难的是给出解决方案并得以实现。
期待大佬新的解决方案出现

哇。阅文集团，斗破、全职、星辰粉怒赞

先赞后看。
好都地方点了跳转都是 403 错误

谢阅。
影响范围这个话题是比较大的，也很难一句两句说清楚。不过按照我当前能力的理解，对测试来说，最粗粒度的可以做到检测出变更的方法或者类，出现在哪些请求的调用链上，也就是说被哪些类的哪些方法调用了，这才是测试应该关注的。如果其他的请求链路，没有出现变更方法的调用，那从一定程度上一定范围内是安全的。所以你可以按照这个思路来想想可以做点什么，至于用到的技术和一些，我有些建议，但我没有完全试验过，所以可以看看能否参考：

• 1.你可以通过解析新版本的字节码，把整个应用的调用链路给解析出来，当然了这个调用链路多数情况下会有多颗树组成，对整个应用来说，最终会是一个由多个调用树组成的森林。这个用 ASM 字节码解析，应该可以做到，但数据量可能比较大，怎么存储怎么展示，可能需要细想，在 java 层可以想办法以 hashmap 来存。
• 2. 上面的森林拿到之后，可以根据新代码的源码和基线代码的源码，来解析变更类和方法，看你怎么存储，差不多可以拿到一个变更方法的列表 (当然也会有该方法的类信息存在)。
• 3. 结合上面的调用关系森林和变更方法的列表，可以初步判断在调用森林里，哪些树中的哪些路径是包含了变更方法的，针对这些请求链路，可以看看怎么补充测试。整个调用关系的存储，之前请教过思寒，可以尝试用 neo4j 或者 kibana 来处理，或者你有其他的思路也可以尝试下

当然了，以上只是我的设想，我之前也做过尝试，只简单做到了 1 和 2，至于 3 嘛，存储和展示都需要一定的技术和资源，我并没有深入研究下去，当然可能会有一定难度，但我之前想到的也就是这个思路。我这想的都比较浅，不知道会不会对你有所帮助。

好机会都在北上广深，心余力亏。
怒吼一声，杭州何在！！！

这个看起来就是你的构建 jdk 和你运行时的 jdk 不一致，最好是要保持一致。

在哪儿构建，就在哪儿运行，如果不能做到这样，那就干脆生成报告的时候，class 文件、源代码、和 exec 文件直接从运行时的机器上复制。

你可以看下我上面的回复，生成报告，要想准确，就得源码、class 文件、exec 最好是同一批构建的产物，当然不排除有时候分开也可以，但最好是要保证同一批~~

希望可以帮到你

你可以了解下 class 文件的构造，开头有一串东西 (好像叫魔数啥的)，是用来区分 jdk 相关的东西的，差别过大，可能就会被认为不匹配了。

嗯嗯，希望可以帮到你了。
等你研究完了可分享出来供大家食用，哈哈

没太明白你的问题出在哪儿，所以不能准确回答你的问题。。
但想说一点，就 jacoco 本身而言，如果你的服务启动的时候，不经过 jacocoagent 的代理程序，那么都是检测不到的。
当然了，即使你经过了 jacocoagent 的代理，也有可能是出不来的，出不来的原因就有很多了。

你可以再详细描述下问题。

就本质上来说，覆盖率报告的生成，只需要两个必须的东西，一个是 class 文件，一个是针对这些 class 产生的执行信息 (就是 exec 文件)。
当然了源码起到很重要的作用就是可以让你在报告里面来回跳转查看代码详情，如果没有源码，则没办法点进去方法。
综上来说，那也可以说成一个完善的覆盖率报告，可以有源码、class 文件、和对应的 exec 文件即可。

回到你的问题，针对你的变更，结合到这三个东西那就可以有以下合并的结论：

1. 首先，最先想到的就是多次发布产生的exec 合并，当然这是 jacoco 原本就支持的，或者说是 exec 文件本身的特性 - 支持合并
2. 第二，基于第一步，当然可以合并多次发布的报告，但也会有一些风险
3. 第三，风险 1，就是 exec 虽然可以合并，但是每次发布的时候，class 文件的变更，可能会导致同一个 class 在不同阶段中会有不同的形态，那会不会有覆盖率数据不准的问题，这个有待讨论
4. 第四，风险 2，多次发布，因为中间有停顿时间，或者覆盖率数据的收集有没有一定的时间间隔，会不会因为多次发布导致有些执行步骤的覆盖率信息没有收集到，这也在一定程度上可能会导致覆盖率数据的不准，甚至丢失
5. 第五，风险 3，多次发布，有没有可能在写入 exec 的时候，会导致数据写到一半的时候被停机，导致 exec 文件本身变得不完整，这有可能导致覆盖率数据不准，甚至有可能导致文件不完整，让 jacoco 没法读取这些信息、

综上步骤，可以简单得出，你的问题，在一定程度上可以做到，但最终能到什么地步，取决于你对这几个风险的把控，要么你可以忽略，要么你可以深度解析一下源码，看看有没有什么解决方案或者规避方案。

当然，这也是我个人现阶段对它的认知，猜出来的解决方案，也可能不对，但总归是个思路~希望可以帮到您

mvn install -Dmaven.test.skip=true -pl jacoco-maven-plugin -am

java
mvn install -Dmaven.test.skip=true -pl org.jacoco.agent.rt -am

这两个命令交替执行下再试试

find_all 返回的是数组，如果想返回一个要么用取索引，要么用 find

python 的命令行执行的时候，能找到的包跟你的执行路径有关系。
它会从你的当前执行命令的目录平级以及当前目录的子孙找，你这个执行位置的爷爷及以上，是找不到的。
解决办法：

1. 你这 run_test.py 目录，放到你的项目根目录下，那找模块的时候，你自己的模块一般都在项目根目录及以下，这基本没问题。
2. 设置 PYTHONPATH 这个环境变量，指向你的代码工程根目录或者里面包含你的项目根目录，也可以。
3. 还可以在你调用其他方法的文件中，把你的被调模块加到 sys.path 中 (我个人不喜欢这个，因为我觉得工作量太大，但确实是个可行思路)

你在 IDE 里创建 python 工程的时候，默认把你这个工程路径加到 PYTHONPATH 里了，所以 IDE 里是可以的，命令行不行。
希望可以帮到你。

仅楼主可见

有成果了哦，不错哦~~~你们用 diff 的话，可以把报告搞的再细一点，diff 可以精确到行，把变更方法里面没有变更的行其实也可以舍弃掉，这样可以更精确。

反正做平台不是个简单的事情，跟做业务又不同，有更多的坑要踩，要适配的场景也会更多~~~哈哈