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

  • 工作十年,很茫然 at July 04, 2019

    工作也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版本号。你新增任务的时候按照这个规范输入就好

  • 不是,针对服务端的