关于覆盖率

关于覆盖率，网络上最常见的两个词应该是“测试覆盖率”（Test Coverage）和”代码覆盖率“（Code Coverage）。今天就来探探这两个东西。

在测试里面，一般会将测试覆盖率分为两个部分，即”需求覆盖率“和”

代码覆盖率“。可以看到，代码覆盖率其实是测试覆盖率的一部分而已。其中，最常讨论和关心的是”代码覆盖率“，代码覆盖率又分为程序语句和代码行覆盖，分支覆盖和条件覆盖。对于这些概念，我们逐个解释。

需求覆盖率：如果需求已经定义好，这个时侯我们就需要考虑需求覆盖率了。这个时候需要注意的是，这里的需求不仅仅是指功能需求，还要包括性能需求。衡量需求覆盖率的最直观的方式是我们有多少功能点，我们有多少性能点

要求，这些将作为分母；我们写了多少测试用例，覆盖了多少模块，多少功能点，我们的性能测试用例考虑了待测程序多少性能点，这些作为分子。

代码覆盖率：为了更加全面的覆盖，我们可能还需要测试程序的流程，我们可能会考虑到一个函数的数据的输入与输出，甚至是每一行代码的执行情况，

代码的每一条逻辑和分支，这个时候我们的测试执行情况就以代码覆盖率来衡量，这也是我们常在单元测试中念叨的覆盖率覆盖率的问题。

语句覆盖率：换个名字叫做代码行覆盖率，这就是监视每行代码是否在用例（当然之所有的）中是否被执行到，准确点说是我们的用例里面大概执行了百

分之多少的语句/代码行数。需要注意的是，即使所有的语句都被执行到，也不

一定执行到了所有的路径。比如有五条语句：ABCDE，如果我们执行了用例覆盖了ABCDE，另外一个用例这个时候我们覆盖了所有语句，但是可能还存在一个路径（如ABC）没有执行,例如：

这个时候我们输入参数”uniquestudiowcd“和”tester“覆盖到了所有的语句，但是我们漏掉了一个路径：即输入参数”uniquestudiowcd“和”coder“。

分支覆盖率：我们也给它换个名字即”路径覆盖率“，尽管并不完全对。在上面的例子中，如果我们仅考虑了第一个用例（即输入参

数”uniquestudiowcd“和”tester“），我们的语句覆盖率为100%，带式路径覆盖率可就低了，因为它存在 ABD,ABCD,ABCDE,ABDE等等很多路径。

条件覆盖率：这也就是为什么不能说”分支覆盖“不同于”路径覆盖“的原因所在。如果我们在一个IF语句中加入了判断组合，那就要考虑更多的问题了，因为主要出现在条件语句中，所以我们称之为”条件覆盖“。我们更改上述示例代码：

很明显即使我们输入参

数”uniquestudiowcd“”tester“，”woman“和”uniquestudiowcd“”test er“”man“，这两个用例的路径走的分支是一样的，但是条件覆盖不一样，

在上一篇文章里面我们介绍了测试覆盖率的分类，举例揭示了需求覆盖率，语句覆盖率，分支覆盖率很条件覆盖率这些问题，在这篇文章里面，则主要介绍为什么要千方百计来找“测试覆盖率”。（关于上一篇文章，参见测试覆盖率之一——测试覆盖率分类）

关于测试覆盖率讲的最多的地方应该实在测试停止标准里面。在测试停止标准里面经常出现这样的语句“测试覆盖率达到或超过95%”之类的概念。其实，如果你看了我前一篇文章中提到的测试覆盖率分类的话，就知道这是一个不准确的描述。关于更准确的描述，我认为应该是“性能测试需求覆盖率达到100%，功能需求测试覆盖率达到100%，语句覆盖率达到85%”这样的句子。“测试覆盖率”本来就包含了很多子部分，所以提测试覆盖率是不明智的一种做法。而我所说的语句覆盖率85%相对于性能测试需求覆盖率这个数据来讲似乎更难获得准确数值，不过现在已经有了很多工具用于测试“语句覆盖率”，而不用我们自己去计算已执行的测试用例覆盖到了数万或者更多代码中百分之多少，也有一些工具可以帮助我们得到代码覆盖率中“分支覆盖率”等其它数据。关于覆盖率检测工具，我将在本系列的后续文章中给予介绍。

测试覆盖率是测试结束标准中的一部分，这显然不是我们今天讨论的重点——测试覆盖率有什么用？直观上讲，我们可以这样理解：

->性能测试覆盖率如果没达到100%，表示我们有些性能测试点没有覆盖到，这在一个对于性能有所要求系统显然是不可取的，这表示我们应该增加用例来覆盖到所需要的性能测试点。

->重要模块的语句覆盖率和条件覆盖率很低，表示我们测试用例过少，我们应当增加用例；如果我们已经写了很多用例（相对于代码行数来讲），但是这两项数据还是很低，那我们得检查一下我们的用例了，是否有重复的用例？是否应该重新设计用例结构？

对于测试覆盖率，我们有这样一个简单的算式，如果A模块的条件覆盖率为80%，B模块也为80%，C模块也为80%，那么我们的总覆盖率则是51.2%，而不是我们想当然的80%。至于为什么这样，我就不解释了。因此在我们审查覆盖率报告时候，我们关注的是覆盖率低的模块，我们要检查为什么低，我们要思考怎么提高，对于覆盖率低的地方，是不是有一个等价类被我们忽略了？

测试覆盖率的意义在瀑布式的开发模式里面可能显得没那么重要，但是如果在螺旋式开发模式中，如果我们没有控制好我们上一个迭代中的测试覆盖率，当一个版本一个版本累加下来后，你就很难确定我们哪些模块在开发过程中没有给予足够的测试；在近些年兴起的持续集成浪潮中，由于要求短迭代（有人建议3-5天一个迭代），如果没有很好的测试覆盖率

保证，很难在这么快的代码变迁中保证测试的质量。在持续集成工作中，代码提交频繁，我们可以通过测试覆盖率来了快速对应新写的，没有对应测试的代码。

总之，测试覆盖率可以提供给我们两个方面的信息：测试覆盖率低的模块和重要模块的测试覆盖率。这些数据可以帮助我们快速定位需要更多测试的模块，可以帮助我们了解重要模块的测试情况，以此来衡量我们测试用例的质量乃至测试的质量。