前面的文章里我们讲了代码覆盖率的理论知识以及代码覆盖率的工具介绍，接下来的文章我们介绍一下代码覆盖率在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包就可以，加一些依赖就可以。加好之后，启动项目的时候要加一个额外的辅助命令：
nohupjava-javaagent:jacocoagent.jar=includes=*,output=tcpserver,address=..0.,port=-jarevent-0.0.1-SNAPSHOT.jar
这个jacocoagent.jar的包去哪下呢？刚才咱们展示的官方的那个包里就有这个jar包。这个jar包放在你的服务器上，启动项目的同时，连同这个jar包一起启动。
并且对外指定一个协议类型是tcp协议，地址是你的服务器的内网的地址，端口号随便写一个，比如说示例这里写的是，Jacoco的官方也是推荐你使用，它的示例里面也是这样写的。
也就是说我在启动原始的服务的同时，启动一个server，这个server是用来出代码覆盖率报告的，也就是说我们同时启动了两个服务，一个是我的服务本身，还有一个是代码覆盖率统计的服务，这个服务依然在本地，端口号是。
放在服务器之后，我们可以看到大概花费了10秒钟的时间把它起来了。起来之后，我们去访问一个接口，然后看一下代码覆盖率到底覆盖了哪些代码。
然后我们在这个项目的本地，找到jacococli.jar，我们用这个包来出覆盖率的报告。刚才的服务我们起来了，并且开了一个端口号，用于出覆盖率，那我们现在就应该访问刚才那个地址和端口，把刚才报告统计的信息输出出来。
dump结果文件：现在执行第二个命令：java-jarjacococli.jardump--addresslocalhost--port--destfile./jacoco-demo.exec注意我们不是在一台电脑上执行的，这个是在本地执行的，我们填的是刚才那台服务器的外网地址，端口。出一个覆盖率的报告，这个文件就放在我们当前的路径下就可以。
它的含义是，访问远端的服务端口，出具这一段时间（从代码起来到目前为止）的代码覆盖的情况。生成报告：java-jarjacococli.jarreport./jacoco-demo.exec--classfiles./target/classes--html./report我们有了这个路径了，接着要出一个覆盖率的报告了，还在这个路径下，通过刚才那个文件生成了一个报告，把报告保存在当前路径下一个叫report的文件夹里，这叫远端出报告。
我们一起看一下这个报告，我们先来看一下controller控制器里面的东西。
我们可以看到有这么多的接口，其中有一个接口叫findAllCity，这个接口被测到了，所以这个接口是百分之百。其他的接口都没有被测到，那我们现在再测一个，findCityByName。
我们再访问这个接口的地址，我们再重复刚才的动作，再出一个报告，看看是否有变化，我们可以看到报告已经跟上面的不一样了。
也就是说，只要我们不停地去测，我们就可以看到在测接口的过程中代码覆盖率的情况了。
很多朋友可能会问了，如果要是测功能测试，页面测试呢？
我们现在测的是接口，假设现在有一个页面，我们在页面上点点点，出来一个报告，报告里同样会展示哪里被测到了，哪里没有被测到，测试过多少代码都可以被看到。
问题又来了，有时候开发测试团队并没有遵循那么标准的流程，我先上一班，都改完后再上一版，这就是我们经常所说的全量覆盖率对于日常迭代，尤其是敏捷开发模型下面其实是没有什么价值的。
什么意思呢，张三可能在下午4点的时候测了一版，他的覆盖率是80%，这时候李四是一个开发，就改了一点代码，但张三没有必要把所有代码都改一遍了，他只测李四的修改就可以了，这个时候他的代码覆盖率可能从第一个全量版本的80%一下子跌到下一个版本可能只有10%。
所以说我们在很多实际情况下要统计增量代码的覆盖情况，这个就需要我们自己来写脚本，来做代码库的diff，来对比两个代码库diff的不同点，来看是否被统计，我们要二次渲染、修改这个报告。
以上就是我们本系列文章分享的所有内容了，给大家展示了什么是代码覆盖率，代码覆盖率的价值是什么，怎么做单元测试代码覆盖率的集成，怎么做功能测试代码覆盖率的一个简单演示。