不管是做服务端测试还是做客户端的测试，只要是深入到代码逻辑，那十有八九就得搞单元测试了。单元测试中一个很重要的衡量标准就是代码覆盖率。今天小编就跟大家一起聊聊关于代码覆盖率的那些事儿。

一、什么是代码覆盖率？

代码覆盖（英语：Code coverage）是软件测试中的一种度量，描述程式中源代码被测试的比例和程度，用被测试的（被覆盖的）代码数量除以总代码量所得比例称为代码覆盖率。

说白了，代码覆盖率就是一个参数，一个衡量标准，用来说明已经测试的代码所占的比例。在实际项目中，可能会出现对代码覆盖率的要求，比如达到50%，以此作为单元测试效果的衡量标准。

对于代码覆盖度，有几种不同的统计形式，下面向大家做一介绍。

二、常见的几种覆盖率统计方式

1.函数覆盖（Function coverage）

函数覆盖很好理解，就是对于代码中的每一个函数，只要这个函数在测试时被执行了，就算是覆盖到了。可见函数覆盖是以函数为单位的，粒度相对而言比较大。

2.语句覆盖（Statement Coverage）

是指程序中可执行语句被测试的比例。语句覆盖率=（至少被执行一次的可执行语句的数量）/（可执行语句的总数），它最简单的覆盖，适合用于自动化测试；几乎所有的测试都能实现语句覆盖率100%，所以它不是测试完整性好的度量。

3.判定覆盖（Decision Coverage）

即程序中真、假分支被测试占的比例。判定覆盖率=（判定结果被评价的次数）/（判定结果的总数），它直接针对代码，容易被理解，实现判定覆盖率100%是可能的； 
判定覆盖优于语句覆盖，但对于复合条件，两个或多个条件项的组合可能导致只有特定的分支被测到。 

举个例子，现在有如下的流程图:

判定覆盖时我们可以设计如下的case：

4.条件覆盖(Condition Coverage)

每个条件操作数(Operand)可能的取值被测试所占的比例。条件覆盖率=（条件操作数值被至少执行一次的数量）/（条件操作数值的总数）。条件操作符容易被确认，有助于自动化测试；条件覆盖优于判定覆盖，但不能替代判定覆盖率。

仍然以上面流程图作为例子来说明。上图中涉及到的条件一共有4个：

为了达到条件覆盖的目的，我们设计的用例需要在 a 点有：

这些情况出现，并且在 c 点有：

这些情况出现。现在可以设计如下用例：

5.路径覆盖（Path Coverage）

路径覆盖要求我们在测试时设计足够多的测试用例，遍历程序的所有可能的路径。 
路径覆盖率=（至少被执行一次的路径数）/（总的路径数）。遇到复杂程序，循环次数多的时候，完成路径覆盖是很困难的，也没有包含判定条件覆盖。

三、对代码覆盖率的观点

对于代码覆盖度，是不是越高越好呢？小编认为并不是这样，个人想法如下： 
1.在可提高的范围内，代码的覆盖率当然是越高越好。但是单元测试相对于其他类型的测试方法而言，投入的成本相对很高，如果不是什么长期项目，一般不会对代码覆盖率有太高要求； 
2.很多代码很难做到100%覆盖，比如异步IO处理、异常捕获的代码、多线程代码等等。这些情况下代码覆盖度对保证代码质量而言其实是没有那么至关重要的； 
3.测试工作需要多种方法联合起来进行，抛开其他的测试手段只谈代码覆盖率本身就是不对的，因此在实际的项目中，需要多种方法并用，以保证质量为最终目的，而不是一味追求单元测试和代码覆盖率而忽略了软件的整体质量。