代码覆盖率在DevOps中的应用
单元测试不可能一直本地化执行，要找一个Jekenis，把代码传到gitte、github、gitlab等代码仓库中。在Jenkins上配一个任务，把代码拉取下来之后，进行打包、编译、出覆盖率报告，出完了覆盖率报告之后，推送到Jenkins前段去进行展示。
这个对于开发人员来说可能都比较熟悉了，咱们测试人员接触的可能少一些，但是我们要知道这个原理。总体来说就是把代码放到Jenkins上去，拉取之后先运行，编译，执行单元测试，统计代码覆盖率，然后代码覆盖率到达一个值之后，才允许你进行下一步的构建，这也是现在很多流水线上都做的一个操作。
下面是两个很简单的例子，拉取代码，执行shell文件，执行之后出报告，出报告之后把这个代码跑起来，在服务的架设上把代码的覆盖率推送给前端去展示。
刚才说的是运行单元测试用例，所以我们关心的是单元测试的覆盖率。现在我们说的是接口测试，运行的是接口测试的测试用例，统计的也是覆盖率，我们叫接口测试测到的代码覆盖率情况。
但实际上统计的都是代码。如果再进一步，测的是功能，在页面上点点点，那我们最终统计的是功能测试的代码覆盖率情况。最终的落脚点还是统计代码，只不过测试手段不一样。不管是接口还是功能，其实都一样。
有很多朋友会问，接口测试代码覆盖率是什么意思？接口测试代码覆盖率也是代码覆盖率，只不过你运行测试用例的手段是运行接口测试用例，所以没有区别。
操作流程：gitte拉取---> maven编译、打包--->启动event.jar并添加jacoco-agent监听 --->关联接口自动化项目开始执行--->向event项目发送dump指令--->生成jacoco覆盖率报告
下面我们来演示一下。我现在找了一台Linux主机，在这个主机上提前放好了一个项目。
这个项目是我以前写的一个做性能测试和持续集成时候的项目。这个项目是一个纯接口的一个项目，没有页面。执行Maven命令的时候，会把它打包成一个jar包，先把这个jar包运行起来。
一运行这个jar包就相当于这个Java的服务也就起来了，但是在运行这个服务的同时，把Jacoco也执行起来，换句话说就是启动这个服务的同时，让它不停地监听、监控代码的覆盖统计的情况。
是怎么监控的呢？一个是对程序里的java配置进行一些小的变更，其实不用污染代码，需要加一个jar包就可以，加一些依赖。加好之后，启动项目的时候要加一个额外的辅助命令：
nohup java-javaagent:jacocoagent.jar=includes=*,output=tcpserver,address=192.168.0.188,port=12345 -jar event-0.0.1-SNAPSHOT.jar &
这个jacocoagent.jar的包去哪下呢？刚才咱们展示的官方的那个包里就有这个jar包。这个jar包放在服务器上，启动项目的同时，连同这个jar包一起启动。
并且对外指定一个协议类型是tcp协议，地址是服务器的内网的地址，端口号随便写一个，比如说示例这里写的是12345，Jacoco的官方也是推荐使用12345，它的示例里面也是这样写的。
也就是说我在启动原始的服务的同时，启动一个server，这个server是用来出代码覆盖率报告的，也就是说我们同时启动了两个服务，一个是我的服务本身，还有一个是代码覆盖率统计的服务，这个服务依然在本地，端口号是12345。
放在服务器之后，我们可以看到大概花费了10秒钟的时间把它起来了。起来之后，去访问一个接口，然后看一下代码覆盖率到底覆盖了哪些代码。
然后我们在这个项目的本地，找到jacococli.jar，我们用这个包来出覆盖率的报告。刚才的服务起来了，并且开了一个端口号，用于出覆盖率，现在就应该访问刚才那个地址和12345端口，把刚才报告统计的信息输出出来。
dump结果文件：
现在执行第二个命令：java -jar jacococli.jar dump --address localhost --port 12345 --destfile ./jacoco-demo.exec
注意我们不是在一台电脑上执行的，这个是在本地执行的，填的是刚才那台服务器的外网地址，12345端口。出一个覆盖率的报告，这个文件就放在当前的路径下就可以。
它的含义是，访问远端的服务端口，出具这一段时间（从代码起来到目前为止）的代码覆盖的情况。 生成报告：java -jar jacococli.jar report ./jacoco-demo.exec --classfiles ./target/classes --html ./report
有了这个路径了，接着要出一个覆盖率的报告了，还在这个路径下，通过刚才那个文件生成了一个报告，把报告保存在当前路径下一个叫report的文件夹里，这叫远端出报告。
我们一起看一下这个报告，先来看一下controller控制器里面的东西。
可以看到有这么多的接口，其中有一个接口叫 findAllCity，这个接口被测到了，所以这个接口是百分之百。其他的接口都没有被测到，那我们现在再测一个，findCityByName。
再访问这个接口的地址，重复刚才的动作，再出一个报告，看看是否有变化，可以看到报告已经跟上面的不一样了。
也就是说，只要我们不停地去测，就可以看到在测接口的过程中代码覆盖率的情况了。
很多朋友可能会问了，如果要是测功能测试，页面测试呢？
现在测的是接口，假设现在有一个页面，我们在页面上点点点，出来一个报告，报告里同样会展示哪里被测到了，哪里没有被测到，测试过多少代码都可以被看到。
问题又来了，有时候开发测试团队并没有遵循那么标准的流程，经常先上一版，都改完后再上一版。这就是我们经常所说的全量覆盖率对于日常迭代，尤其是敏捷开发模型下其实是没有什么价值的。
张三可能在下午4点的时候测了一版，他的覆盖率是80%，李四是一个开发，就改了一点代码，张三没有必要把所有代码都测一遍，他只测李四的修改就可以了，这个时候他的代码覆盖率可能从第一个全量版本的80%一下子跌到下一个版本可能只有10%。
所以说我们在很多实际情况下要统计增量代码的覆盖情况，这个就需要我们自己来写脚本，来做代码库的diff，来对比两个代码库diff的不同点，来看是否被统计，我们要二次渲染、修改这个报告。
以上就是我们今天分享的所有内容了，给大家展示了什么是代码覆盖率，代码覆盖率的价值是什么，怎么做单元测试代码覆盖率的集成，以及怎么做功能测试代码覆盖率的简单演示。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
