是的，覆盖了代码未必一定没问题，但是没覆盖的代码肯定可能存在遗漏

老实说，这个做不到。因为你光看改动代码，你并不知道它会影响到多少函数。它只是作为补充测试一个手段

优秀

是的，但是比如你现在发布的 1.1 版本（因为不是每次开发代码提交，都会立即进行代码发布），你 git 上提交的已经是 1.3 版本，这时候你直接去 git 上拉，实际你会发现你拉取的代码和实际运行的代码是不一致的

工作也 10 多年了，好像前 10 年也是这种状态，别说看技术论坛了连测试书都不看，反正工作要求做啥就做啥，觉得自己啥都会一点，觉得测试好像就这么点东西没有什么价值，整天想着是不是应该转岗。
突然有一天觉得自己不应该再停留在原地，也没有转岗的勇气，就想跳槽看看，然后就很主动的去找各种测试圈子，去看教学视频，了解大公司的技术有哪些。然后逼自己一把，加上一些运气，努力跳到一个比较大的互联网公司。在那里终于也让自己很好的开阔了眼界。
其实说这么多我想说的是：
1.测试技术发展其实一直都是比较缓慢的，一个初级测试和高级测试的差别可能你只要找对方法通过半年的努力就可以赶上
2.要找准自己的价值点，我一直觉得人应该尽力去寻找自己的价值和优势，并且努力把它发挥到最大化
3.对测试来说年龄有时候是个障碍，但有时候也不是，关键你要考虑这个年纪你应该要做的是什么，没有人一辈子都是做点点点，也没有公司要一个员工一辈子只会点点点
4.拥抱未知的变化，很多时候运气是成功的一部分，但是运气来源于你生活的复杂度，越复杂，你可能的得到运气的几率越大。所以多去认识朋友，多去参加论坛，让你的生活复杂度高，可能运气就来了

这个具体网上都有教程，jenkins 上下载 jacoco 插件，然后创建一个任务，在任务中实现拉取源代码、编译代码和覆盖率文件，通过 jacoco 插件分析这些数据来获取覆盖率详情。

现在都要 7000 了吗，这么贵，我以前上的时候才是 1000 多，然后考了第一名奖了 3000 多。不过那个时候有点久远了，现在估计课程应该丰富很多。
因为我当时是传统行业测试的，所以对我们来说为后来跳到互联网行业帮助还是挺大的，但是如果一直都在互联网行业做测试，有一定测试技术基础的同学可能帮助有限，当然我也就是以当时的课程作为评价。
顺便说一下，因为当时考了第一名，所以后来就顺利进了网易。虽然现在走了，但是我觉得这个是对我参加这次课程最大的收益吧。

理论上这个 merge 结果不就是你想要的吗，100 行第一次覆盖了，第二次因为代码改动，所以统计为没覆盖。

我们全量覆盖率是 通过 jenkins 的 jacoco 插件来生成的，就是你需要在 jenkins 上面创建一个覆盖率任务用来生成全量覆盖率报告。而我们代码变更覆盖率报告就是基于这里生成的全量覆盖率报告而来的。
其中我们这里配置的覆盖率任务名称是为了得到对应覆盖率报告的路径。服务发布的任务名称也是为了在服务发布路径目录下获取 git 信息，从而得到当前 commit 的版本和比对版本的代码差异。

针对这个问题我之前也查过资料，我是这么理解的。生成 jacoco 报告的时候是会比对覆盖率文件和编译文件，假如两者代码不一致就不会显示覆盖。这就是为什么，明明你测试了，但是你覆盖率代码和编译代码不一致的情况下生成的覆盖率报告数据为空的情况了。所以即使你合并了覆盖率文件，当发现 100 行在覆盖率文件中虽然覆盖了，但是代码与源代码不一致，仍然不会显示为覆盖。

首先 jacoco 的统计的覆盖率情况是根据拉取 exec 文件来的，如果你要 v2 的报告也要统计 v1 的覆盖率数据，你可以在 jacoco 的 build.xml 文件里对每次拉取的 exec 进行 merge。这样统计出来的是历史以来的全量的覆盖率情况。如下：

<target name="merge_exec">
    <jacoco:merge destfile="/jenkins/workspace/xxxxxx/merged.exec">
        <fileset dir="/jenkins/workspace/xxxxxx" includes="*.exec" />
    </jacoco:merge>
</target>

当然在你在获取所有版本全量的覆盖率的情况下，再针对其中某个版本到最新版本的覆盖率，可以通过我的平台来生成。但是如果你直接要做整合多次覆盖率报告，只要修改 build.xml 就可以了。

项目在 github 的 readme 上有说明：任务名称为 jenkins 上创建的覆盖率任务的名称。发布名称为 jenkins 上服务发布的任务名称，比对版本为 git 上对应的版本的 commit 版本号。你新增任务的时候按照这个规范输入就好

不是，针对服务端的

目前我上传的平台代码是只针对在同一台机器上的。当然因为我们的测试环境也部署了多个 jenkins，所以也会存在你说的服务需要去调用其他机器上的 jenkins 的情况，不过这部分代码我没放到 github 上。这块你可以考虑用把平台中获取覆盖率的数据和报告的代码提取出来部署在 jenkins 的服务器上，然后在平台上通过 python 的 paramiko 库去实现远程执行 linux 命令去触发覆盖率数据的获取和报告生成，再通过这个库的文件下载功能把覆盖率文件拉下来。不过这样子执行效率会比正常的慢一点。

首先要你在重启或者服务停止前去 dump 数据，当然你的方案也是可以的。
但是有个风险就是，如果服务自己重启。如果你的服务比较稳定，我觉得也是可行的。
当然这个方案也是基于你每天有个定时任务去执行 dump 的基础上，毕竟你不可能指望要等到发布服务的时候才去 dump 覆盖率数据

自从当了测试主管之后，越来越发现影响一个测试人员能力的不仅仅是技能的提升，而是思维方式的变化。遇到过很多测试人员，当你工作分给他们的时候，第一种人他们第一感觉是拒绝的，勉勉强强把事情做完交差，另一种人呢好一点他们会接受也会认真执行，但是抱着完成任务的心态去做，做完就完了，而第三种人，则会在做时候思考我交给他这个工作目的是什么，他会努力在这个工作中提出自己的想法，并在我的要求上多做一些。三种不同的心态，也造成了这 3 类人能力的差别。有时候我会同时给所有人培训技能，但是你会发现最后第一种人压根就不学，第二种人学的很好，作业也做的很好，但是学完也不会用，过段时间就荒废了，第三种人，学完了会努力把它变成自己的亮点成为自己的价值的一部分。

我说这些其实想给楼主一个建议是，很多人都会发现自己技能上的缺失，又会发现学了很多好像都没什么用，其实这个时候你应该去思考自己的思维方式是不是有什么要改变的。我经常对下面的人说，当你接到任务的时候，小孩子才考虑要不要做，大人应该考虑怎么做才能通过它给自己创造最大化的价值

哈哈，我一般都要求测试对开发和产品都要强势一点，质量的推进是需要革命的精神，又不是请客吃饭

个人意见啊，绝对愿意，当然要求是名副其实的培训课程。有一点我一直觉得，投资自己永远是回报率最高的投资，所以在自己身上花费在学习的每一分钱，都会成倍的回报给你。很多人在小孩教育身上花很多钱，对自己教育却一份都不花，可是对一个孩子来说你花的那些钱实际收益很有限，而且要很久才会有收益，但是在自己身上花的投入，可能一段时间你就会换工作涨工资，很快就会有收益。

哈哈，至少证明做过运营是不会假的。

有点意思