我们以前经常讲DevOps，其实这个概念现在已经过时了，现在已经在讲DevSecOps这个概念了，开发-安全-运维一体化。我们先一起来简单看一下DevOps。

从下面这行图里我们可以看到，左边这一部分是开发流程，从需求设计一直到代码编写完成都在左边这一环。右边这一环是运维、上线、发布、使用，这么一个流程，它们都被归在运维这一个大的面里面。
所以我们说的DevOps就是运维和开发的一体化，从开始写代码到项目上线这样一个整体的流程。

咱们的测试人员，在这个流程里面要发挥什么样的角色呢？咱们经常说左移和右移。这里我们简单提一下，因为我们做代码覆盖率也跟左移和右移相关。以上面图片中的两个圆形为分界，往左移就是更偏向于开发的部分，也是我们经常所说的测试早介入。更偏向于开发、系统架构设计和需求，除了可以更早的发现问题之外，还可以提高后续的功能测试的效率。

往右就是更靠向运维和监控这一部分，往左的价值的是提效，往右的价值是度量和监控。这就是经常说的测试左移和测试右移。咱们今天讲的测试代码的覆盖率就在左移的范围内。

什么是代码覆盖率？

我们运行单元测试用例或者执行功能测试用例(UI、接口)时，查看代码被执行的情况。把测试覆盖作为质量目标没有任何意义，而我们应该把它作为一种发现未被测试覆盖的代码的手段。

很简单的一句话，代码覆盖率就是在运行测试之后，哪些代码被测到了，哪些代码没有被测到。也就是说在运行测试用例后，哪些代码别覆盖到了，哪些代码没有被覆盖到，这就是代码覆盖率。

这里面就有一个隐含的含义，比如我们刚才说的在“运行测试”的过程中，这个“运行测试”就要加一个引号了。

因为我们运行的测试有很多，假如我运行的是功能测试，那么就要看我们的功能测试，我在网站上点点点，我们到底测试了哪些代码，哪些代码覆盖到了。

如果我们运行的是单元测试，我们就要看我们的单元测试覆盖到了哪些代码。

如果是接口测试，就要看我们的接口测试到底覆盖到了服务端的哪些代码。咱们这个代码一般是指服务端的代码，我们一般很少会去统计前端代码的覆盖情况，那个是没有什么太大意义的。

我们概括一下，代码覆盖率就是运行测试之后，代码被覆盖到了多少，哪些代码跑了，哪些没有跑。根据运行测试手段不同，代码覆盖率分成了单元测试代码覆盖率、接口测试代码覆盖率和功能测试代码覆盖率。

我们看上面这张图，什么意思呢，就是说我们的代码覆盖率最终的目的是找到那些没有被覆盖到的代码。

有的朋友会问，没有覆盖到的代码就一定有问题吗？我没有说它一定有问题，但是起码你要知道，当你运行了一个完整的测试之后，有哪些代码没有跑到，这些代码有可能是有问题的，也有可能是没有问题的，有可能是冗余的，也有可能是架构设计有问题，这些都有可能。
我们不能说它是不好的代码，但至少是有问题的代码，这个是我们的目的，而不是度量某一个质量指标。

这是在做代码覆盖率比较初级的朋友比较容易犯的一个误区，会觉得我的代码覆盖率到达了80%就一定说明是没有问题。

没有一概而论，就像有的同学做性能测试的时候说，我的TPS上到了多少，CPU使用率到达了多少就一定怎样。我们经常说，去抓一些数据的把手是一个很不好的习惯，找一些指标让自己心里变得舒服。
比如说指定CPU使用率到达75%就一定怎样了，拿着这根线去卡一切，这样很多事就变得简单了，实际上根本就没有那么简单。

所以上面这张图的意思是发现没有被覆盖到的代码，而不是简单的做一些质量的标准，那样很没有意义。总结来讲，代码覆盖率的意义就是： 1、分析未覆盖部分的代码，从而反推在前期测试设计是否充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？需求/设计不够清晰，测试设计的理解有误，之后进行补充测试用例设计。 2、检测出程序中的废代码，可以逆向反推在代码设计中思维混乱点，提醒设计/开发人员理清代码逻辑关系，提升代码质量。 3、代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量不会高到哪里去，可以作为测试自我审视的重要工具之一。

接下来的文章我们会针对代码覆盖率的实施和落地方法继续进行分享，欢迎大家继续关注。