原创 【转】覆盖率的一点理解

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

 

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

 

　　需求覆盖率：如果需求已经定义好，这个时侯我们就需要考虑需求覆盖率了。这个时候需要注意的是，这里的需求不仅仅是指功能需求，还要包括性能需求。衡量需求覆盖率的最直观的方式是我们有多少功能点，我们有多少性能点要求，这些将作为分母；我们写了多少测试用例，覆盖了多少模块，多少功能点，我们的性能测试用例考虑了待测程序多少性能点，这些作为分子。

 

　　代码覆盖率：为了更加全面的覆盖，我们可能还需要测试程序的流程，我们可能会考虑到一个函数的数据的输入与输出，甚至是每一行代码的执行情况，代码的每一条逻辑和分支，这个时候我们的测试执行情况就以代码覆盖率来衡量，这也是我们常在单元测试中念叨的覆盖率覆盖率的问题。

 

　　语句覆盖率：换个名字叫做代码行覆盖率，这就是监视每行代码是否在用例（当然之所有的）中是否被执行到，准确点说是我们的用例里面大概执行了百分之多少的语句/代码行数。需要注意的是，即使所有的语句都被执行到，也不一定执行到了所有的路径。比如有五条语句：ABCDE，如果我们执行了用例覆盖了ABCDE，另外一个用例这个时候我们覆盖了所有语句，但是可能还存在一个路径（如ABC）没有执行,例如：

 

　　public verifyToken(string yourname, string yourtitle)

 

　　{

 

　　A   output（”Hello, my dear friends“）;

 

　　B   if(yourname == "uniquestudiowcd")

 

　　{

 

　　C      output("Hello, Aaron");

 

　　}

 

　　D   if(yourtitle == "tester")

 

　　{

 

　　E     output("Hello, my dear tester");

 

　　}

 

　　}

 

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

 

　　分支覆盖率：我们也给它换个名字即”路径覆盖率“，尽管并不完全对。在上面的例子中，如果我们仅考虑了第一个用例（即输入参数”uniquestudiowcd“和”tester“），我们的语句覆盖率为100%，带式路径覆盖率可就低了，因为它存在ABD,ABCD,ABCDE,ABDE等等很多路径。

 

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

 

　　public verifyToken(string yourname, string yourtitle，string gendar)

 

　　{

 

　　A   output（”Hello, my dear friends“）;

 

　　B   if(yourname == "uniquestudiowcd" && gendar == ”man“)

 

　　{

 

　　C      output("Hello, Aaron");

 

　　}

 

　　D   if(yourtitle == "tester")

 

　　{

 

　　E     output("Hello, my dear tester");

 

　　}

 

　　}

 

　　很明显即使我们输入参数”uniquestudiowcd“”tester“，”woman“和”uniquestudiowcd“”tester“”man“，这两个用例的路径走的分支是一样的，但是条件覆盖不一样，实际上两者的”路径“也是不一样的。

 

　　上面主要介绍的测试覆盖率的一些基本知识，在关于测试覆盖率的第二篇文章中，我将介绍归纳一下测试覆盖率的用处，或者说测试覆盖率的意义。

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

 

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

 

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

 

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

 

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

 

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

 

　　测试覆盖率的意义在瀑布式的开发模式里面可能显得没那么重要，但是如果在螺旋式开发模式中，如果我们没有控制好我们上一个迭代中的测试覆盖率，当一个版本一个版本累加下来后，你就很难确定我们哪些模块在开发过程中没有给予足够的测试；在近些年兴起的持续集成浪潮中，由于要求短迭代（有人建议3-5天一个迭代），如果没有很好的测试覆盖率保证，很难在这么快的代码变迁中保证测试的质量。在持续集成工作中，代码提交频繁，我们可以通过测试覆盖率来了快速对应新写的，没有对应测试的代码。

 

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

上一篇文章中，介绍了测试覆盖率的意义之类的东西。测试覆盖率可以帮助我们检查测试质量，检查测试用例的有效率。如果有兴趣的话，可以阅读测试覆盖率之二——测试覆盖率有什么用？

 

　　关于测试覆盖率，我个人的感觉是说的多，用的少。最近在网络上看到一篇文章，讨论一个问题“测试需要100%的覆盖率吗？”被转载了很多次，有兴趣的同行可以找来看看。的确，一想到测试覆盖率，立马就有完美主义者跳出来说100%。100%的测试覆盖率有什么好处呢？

 

　　1、100%的覆盖率表示我们的测试覆盖到了所有语句，分支，条件

 

　　2、100%的覆盖率表示我们测试考虑的很完全，我们可以回去睡大觉了~~

 

　　测试仿佛在这里变得不那么可怖了，但是我们至少遗漏了两个重要的地方：怎么达到100%的测试覆盖率或者说是否能够达到100%的测试覆盖率，另外一个就是100%的测试覆盖率到底能告诉我们什么信息。

 

　　首先来讲，我们是否可以达到100%的测试覆盖率？如果我们简单的将测试覆盖率理解为需求覆盖率，代码覆盖率，那么我想这是可以达到的，只要拥有足够的时间，我们的测试覆盖到每一个需求点，我们的测试覆盖到每一条语句，每一个条件，每一个分支，看起来的确没有问题。但是我们还要考虑另外一个问题，是否由我们未曾列入到需求分析中的需求呢，这种情况是存在的，如果我们计算需求覆盖率是根据Feature Spec来的（实际上如果我们需要计算的话，一般就是这样计算得来的），那么当我们有需求没有被写入Feature Spec并且我们也没有在测试中考虑相关的测试，那么我们实际的“需求覆盖率”就不是100%了。在实际开发过程中，是不可能在Feature Spec中将需求全部列出来的，所以我们得到的100%的需求覆盖率是存在水分的。

 

　　另外，对于一个应用程序(除了一些极其简单的程序)来讲，要覆盖到所有的语句。条件，分支是极其困难的，甚至可以说是不可能的。笔者在经历的一个项目中花了一整天写一个模块的单元测试，当我忙完一天并运行了所有的用例之后，我发现我的代码覆盖率仅仅增加了2%，而且是从35%到37%，不要说100%，连80%我当时都觉得是奢望。

 

　　对于第二个问题，100%的测试覆盖率能代表什么？我在上面讲到，100%的测试覆盖率表示覆盖到了所有的语句，分支和条件，但是这又说明什么呢？这是否说明了我们做到了完全测试一个软件呢？很抱歉，答案是否定的。给出下面这一段代码：

 

　　private int add（int a，int b）

 

　　{

 

　　return a+b;

 

　　}

 

　　够简单的一段代码了吧，我们可以很轻松的达到100%的覆盖率，比如我们使用用例 add（3，4）就可以覆盖所有的语句，分支，条件（当然这里面是不存在分支和条件的，所以只需要覆盖语句就可以达到代码覆盖率100%了），但是聪明的你一定会发现我们的测试远远不够：如果输入的是add（2147483647，2），这个应用程序是会出现问题的，如果我们仅仅满足于100%的代码覆盖率，是不能保证我们的软件的质量的。

 

　　关于代码覆盖率，由一个很有趣的现象：高覆盖率有时候比低覆盖率还“没用”。注意“没用”是打了引号的，我的意思是高覆盖率不能说明我们做了完全的测试，低覆盖率却可以说明我们测试远远不够，从这一点来讲，低覆盖率似乎更有意义。当然我不是在讲我们不去追求高覆盖率，我的意思是与其把A模块覆盖率从85% 提高到90%，还不如把与其类似的B模块的覆盖率从30%提高到50%更有意义。绕一大圈说回来，在任何时候高覆盖率都比低覆盖率好，但是作为一个软件，我们要顾及软件整体的测试质量，我们还要估计成本，时间等等很多问题。

 

　　上面说了不少，最后总结一下我的观点：

 

　　1、测试覆盖率100%是一个理想的情况，是很难达到的；

 

　　2、测试覆盖率100%不能说明我们做了完全的测试；

 

　　3、较低的测试覆盖率能说明我们的测试还不够，反之是不成立的，参考第二条；

 

　　4、同一模块高覆盖率相对于低覆盖率能说明我们做了更多的测试；

 

　　5、测试覆盖率达到多少要考虑到软件整体的覆盖率情况，以及项目成本，包括人力，时间等等。

 

　　个人观点，仅供参考。如果问题或意见，请联系 unique.wuchaodong@hotmail.com 或直接留言~

 

　　关于测试覆盖率100%的问题的讨论还会继续下去，如果必要的话，笔者将在本系列文章的后期继续总结，根据计划，在下一篇文章中我将介绍自己使用过的相关工具，以及我未使用但是可以从网上找到相关资料的工具，帮助大家总结一下，以备查看。