做管理的时候，比做一线的时候焦虑的多的多了。。
一线的时候，按时完成任务，不出严重问题就行，相比潇洒自在，做管理的时候，是真的迷茫。。。
当然，可能也跟年纪越来越大也有不小的关系吧。。

关于改造后的 jacococli.jar 和链路分析的代码，有望开源不？

jacococli.jar 自带 merge 功能，可以通过这个命令去合并.exec 文件后再生成报告，不过某个类只要改过一行代码，内置的 classid 就变了。这个类就没法 merge 了。所以有的公司二开了 merge 逻辑，不再根据 classid 去 merge，吧里搜下吧，印象中看到过

我们对于 k8s 里 dump exec 文件的方式是，pod 中映射对外的 jacocoagent 的 port，再从 eureka 上获取应用 ip。有了 ip 和 port，剩下的就跟普通的玩法一样了。

很有意思的文章， 每看一条，都反向思考一下。站在测试管理的角度，如果这些问题我们都解决了，必将是一个成功强大的团队~~

金九银十不是买房的说法么。。。

统计增量覆盖率，没覆盖到的代码，很容易辨别是不是本次迭代的相关代码~

---常逛的测试网站，说三个

想知道这个题的答案。。。。

你这应该是用 cli 的 execinfo 命令吧，这命令只输出了覆盖信息，并不代表 exec 文件里只有这些信息。。
至于覆盖了哪些方法。。report 中都有列出来。。

不熟悉业务是没法做自动化的。。。

你的 class 文件是怎么来的？report 覆盖率是 0 不一定真的是覆盖率为 0，也可能是打包的方式或者版本问题，导致 classid 对不上。你可以先对 exec 文件做 execinfo 操作，看下是否有覆盖数据，merge 后再看下 merge 后的 exec 文件有没有覆盖数据。先确定是 exec 文件的问题还是 report 的时候出的问题。
建议可以先用 jacococli.jar 进行操作 (java -jar jacococli.jar --help)。操作的时候可以看下日志。

exec 文件合并了解一下~~

现在的公司如果没啥成长了，如果还年轻，还是去拼一把吧。965 做久了，人容易疲软，倒也不说一定要去 996，至少充实点没坏处~

这个得看应用了，遇到过应用中很多已经弃用的代码没有删除的，那覆盖率肯定不会高
然后得看是自动化还是手工测试了，自动化我们这代码行覆盖率保 60% 争 70%(做了点小动作，过滤了一些工具类，domain，dto 之类的)，如果是手工测试，建议只统计增量覆盖率，否则覆盖率肯定上不去。

之前照着楼主和 ELes 大神的几篇帖子，已经把这套给玩起来了，真的是非常感谢两位大神的攻略帖。但是部分场景不知道该怎么处理，比如 某接口中会新起一个线程去异步处理一些事情，这种情况下除了把这个子调用 mock 掉之外，还有更好的处理方法么？主要是被 mock 掉的那部分功能就没法回放到了。

辣个男人还在坚持挖矿~~~

用 uiautomator2 试试，之前遇到过，印象中好像是有蒙层，记不清了。。

到 jenkins 的服务器上，workspace 中对应的脚本路径下打 git pull，系统会提示你打一个命令，照着执行就可以了。

贵公司质量技术真是厉害~~~

请问，Cypress 的 code coverage，能否在手工测试后统计覆盖率呢？istanbul 已经弄好了，但是看 Cypress 好像依赖于它的自动化后才能生成覆盖率？这边现在没条件写前端的自动化。只想在手工测试后能看一下覆盖率，另外，楼主有做过前端的增量覆盖率嘛？