测试覆盖率之一——测试覆盖率分类
关于覆盖率，网络上最常见的两个词应该是“测试覆盖率”（Test Coverage）和”代码覆盖率“（Code Coverage）。今天就来探探这两个东西。
在测试里面，一般会将测试覆盖率分为两个部分，即”需求覆盖率“和”代码覆盖率“。可以看到，代码覆盖率其实是测试覆盖率的一部分而已。其中，最常讨论和关心的是”代码覆盖率“，代码覆盖率又分为程序语句和代码行覆盖，分支覆盖和条件覆盖。对于这些概念，我们逐个解释。
需求覆盖率：如果需求已经定义好，这个时侯我们就需要考虑需求覆盖率了。这个时候需要注意的是，这里的需求不仅仅是指功能需求，还要包括性能需求。衡量需 求覆盖率的最直观的方式是我们有多少功能点，我们有多少性能点要求，这些将作为分母；我们写了多少测试用例，覆盖了多少模块，多少功能点，我们的性能测试 用例考虑了待测程序多少性能点，这些作为分子。
代码覆盖率：为了更加全面的覆盖，我们可能还需要测试程序的流程，我们可能会考虑到一个函数的数据的输入与输出，甚至是每一行代码的执行情况，代码的每一 条逻辑和分支，这个时候我们的测试执行情况就以代码覆盖率来衡量，这也是我们常在单元测试中念叨的覆盖率覆盖率的问题。
语句覆盖率：换个名字叫做代码行覆盖率，这就是监视每行代码是否在用例（当然之所有的）中是否被执行到，准确点说是我们的用例里面大概执行了百分之多少的 语句/代码行数。需要注意的是，即使所有的语句都被执行到，也不一定执行到了所有的路径。比如有五条语句：ABCDE，如果我们执行了用例覆盖了 ABCDE，另外一个用例这个时候我们覆盖了所有语句，但是可能还存在一个路径（如ABC）没有执行,例如：
{
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语句中加入了判断组合，那就要考虑更多的问题了，因为主要出现在条件语句中，所以我们称之为”条件覆盖“。我们更改上述示例代码：
{
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%。100%的测试覆盖率有什么好处呢？
1、100%的覆盖率表示我们的测试覆盖到了所有语句，分支，条件
2、100%的覆盖率表示我们测试考虑的很完全，我们可以回去睡大觉了~~
测试仿佛在这里变得不那么可怖了，但是我们至少遗漏了两个重要的地方：怎么达到100%的测试覆盖率或者说是否能够达到100%的测试覆盖率，另外一个就是100%的测试覆盖率到底能告诉我们什么信息。
首先来讲，我们是否可以达到100%的测试覆盖率？如果我们简单的将测试覆盖率理解为需求覆盖率，代码覆盖率，那么我想这是可以达到的，只要拥有足够的时 间，我们的测试覆盖到每一个需求点，我们的测试覆盖到每一条语句，每一个条件，每一个分支，看起来的确没有问题。但是我们还要考虑另外一个问题，是否由我 们未曾列入到需求分析中的需求呢，这种情况是存在的，如果我们计算需求覆盖率是根据Feature Spec来的（实际上如果我们需要计算的话，一般就是这样计算得来的），那么当我们有需求没有被写入Feature Spec并且我们也没有在测试中考虑相关的测试，那么我们实际的“需求覆盖率”就不是100%了。在实际开发过程中，是不可能在Feature Spec中将需求全部列出来的，所以我们得到的100%的需求覆盖率是存在水分的。
另外，对于一个应用程序(除了一些极其简单的程序)来讲，要覆盖到所有的语句。条件，分支是极其困难的，甚至可以说是不可能的。笔者在经历的一个项目中花 了一整天写一个模块的单元测试，当我忙完一天并运行了所有的用例之后，我发现我的代码覆盖率仅仅增加了2%，而且是从35%到37%，不要说100%，连 80%我当时都觉得是奢望。
对于第二个问题，100%的测试覆盖率能代表什么？我在上面讲到，100%的测试覆盖率表示覆盖到了所有的语句，分支和条件，但是这又说明什么呢？这是否说明了我们做到了完全测试一个软件呢？很抱歉，答案是否定的。给出下面这一段代码：
{
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、测试覆盖率达到多少要考虑到软件整体的覆盖率情况，以及项目成本，包括人力，时间等等。
关于测试覆盖率100%的问题的讨论还会继续下去，如果必要的话，笔者将在本系列文章的后期继续总结，根据计划，在下一篇文章中我将介绍自己使用过的相关工具，以及我未使用但是可以从网上找到相关资料的工具，帮助大家总结一下，以备查看。
测试覆盖率之四——测试覆盖率工具汇总
在上一篇文章我提到的是关于测试覆盖率100%有关的话题，算是“跟风”谈论了最近关于测试覆盖率最流行的100%问题吧。关于上篇文章的详细内容，参见测试覆盖率之三——测试覆盖率100%相关的话题。
在上一篇文章中，和大家约定下一篇介绍关于测试覆盖率工具相关的东西，可是这两天一直出差，无暇顾及，希望关注我的朋友不要介意~ _ ~ 废话不说了，直接切入正题。由于本人对于测试覆盖率工具的使用仅限于.NET相关的，所以对于其他语言相关的测试覆盖率工具没有经验，因此也少了发言权， 这片文章就只能算作对于各种工具的一种简单的介绍罢了，主要内容都来自于google百度，笔者做简单的整理之后发表出来，希望对大家有所帮助。
● Javascrīpt 测试覆盖率工具
JSCoverage 是一个用于度量Javascrīpt程序的代码覆盖率的工具。能显示哪些行被执行过了，哪些行尚未执行，这些信息对于测试覆盖率的分析和测试质量的衡量都 很有用。JSCoverage通过度量Web页面使用的Javascrīpt代码，收集被Web浏览器执行的Javascrīpt代码信息来达到测试覆盖 率统计的功能。JSCoverage支持IE6、IE7、Firefox2、Firefox3、Opera、Safari等流行的浏览器、支持 Windows平台和Linux平台。JSCoverage是开源软件，官方网站：http://siliconforks.com /jscoverage/
● Java测试覆盖率工具
EMMA，开源工具，支持Java 1.2或更高版本的JVM，不依赖于任何第三方类库。EMMA支持maven，ant，报表格式简单。官方网站 http://emma.sourceforge.net/
Coverlipse，一个Eclipse的Code coverage插件。
Cobertura 是一种开源工具，它通过检测基本的代码，并观察在测试包运行时执行了哪些代码和没有执行哪些代码，来测量测试覆盖率。除了找出未测试到的代码并发现 bug 外，Cobertura 还可以通过标记无用的、执行不到的代码来优化代码，还可以提供 API 实际操作的内部信息。
Clover
NoUnit
● .NET测试覆盖率工具
Clover.NET http://www.cenqua.com/clover.net/
Visual Studio的代码覆盖率统计工具
NCover官方网站：http://ncover.org/
PartCover
● C/C++测试覆盖率工具
Bullseye Coverage 是Bullseye 公司提供的一款C/C++代码覆盖率测试工具除了支持各种Unix 下的编译器之外，在Windows 下支持VC、Borland C++、Gnu C++、Inter C++。提供的代码覆盖率是分支覆盖率而不是一般代码覆盖率，我个人认为分支覆盖率比代码覆盖率更好。Bullseye Coverage 可以从http://www.bullseye.com/上获取
● Ruby代码覆盖率工具
rcov是一个用于诊断Ruby代码覆盖率的工具，它最主要的用途就是用于确定单元测试是否覆盖到了所有代码，rcov使用一个经过优化的C运行时，因此性能相当惊人，同时它还提供多种格式的输出
● 其他
AutomatedQA公司的AQTime。AQtime运行在windows平台下，它支持.net应用和非.net应用,但不支持JAVA应用。 AQtime除了包含代码覆盖率监测以外，还包括了性能监视等功能。AQTime能够收集服务端C#和VB.net代码的覆盖率，但是不能收集客户端scrīpt脚本的覆盖率。
DevPartner Studio的Web scrīpt Coverage工具。该工具主要是收集Web客户端scrīpt脚本覆盖率的。 它使用起来也很简单，只要启动此工具，然后在浏览器中输入网址，收集工作就开始了。在形成的测试报告中清楚地反映了每个函数的实行情况，给出了覆盖率数 据，同时对于执行到的脚本和未执行到的脚本用不同的颜色表示，十分明了。该工具唯一的缺陷就是不能收集服务端脚本的覆盖率，同时存在中文字符无法正确识别 的问题。
关于测试覆盖率工具，有很多内容，上面提到的只是我平时收集到的一些知识，很大一部分并没有实际验证，因此对于可能出现的纰漏和错误，还望读者原谅。关于 测试覆盖率工具，笔者很有兴趣继续学习使用，并会在后期的学习中总结并发表在该系列文章中。在本系列的下一篇文章(测试覆盖率之五——提高测试覆盖率) 中，笔者将继续探讨有关提高测试覆盖率的问题。
测试覆盖率之五——提高测试覆盖率
在上一篇文章中，简单的而介绍了一些测试覆盖率相关的工具，由于大部分工具笔者并没有使用的经验，因此只是简单地从网络搜索了一下相关资料并将其整理出来，关于上篇文章的详细内容，参见：测试覆盖率之四——测试覆盖率工具汇总。
这篇文章中，主要讨论的是如何提高测试覆盖率的相关问题。其实，提高测试覆盖率最基本，甚至是唯一的办法就是增加测试用例，但是怎样通过增加测试用例而帮助我们“迅速”提高我们的测试覆盖率呢？
代 码走查 对于代码的不熟悉造成了我们的代码覆盖率迟迟上不去，我们需要了解到代码里面究竟有多少条件分支，多少怎样的循环，分支和循环向来是导致我们代码覆盖率比 较低的原因，另外，是不是存在一些过时的代码，没有运行过代码监测工具的代码中很可能存在一些没有被引用的死代码，而代码走查，尤其是对于覆盖率低的模块 的代码走查将有助于你增加相关的用例而提高代码覆盖率。
工具 这里倒不是说有些工具可以帮助你直接提高代码覆盖率，这样的工具至少我还没有就见过。这里提到的工具主要包括两种，一是代码分析工具另外一种就是上篇文章 中提到的代码覆盖率工具。代码分析工具可以帮助我们分析代码中的冗余部分，这样可以帮助我们干掉那些总是不可能覆盖到的死函数，有的编译器已经提供了类似 的功能。使用代码覆盖率工具则可以帮助我们快速监测代码覆盖率低的地方，这样我们可以快速定位我们测试的薄弱环节，通过代码走查或其他方式可以快速增加用 例。一般来讲，某一模块的代码覆盖率从30%提高到50%所需的时间遥远小于从60%提高到80%的时间。
规则 这里所指的规则其实是指一些基本测试方法，如等价类划分，边界值分析。我们有时候需要通过这些手段来逐一检查我们那些方面的测试用例没有考虑到，从而帮助我们增加相关的测试用例。
经 验 这个看起来有点像废话，因为一般都知道测试经验丰富有助于测试用例的设计，写出别人没有想到的测试用例。我在这里把这句话提出来的主要意图是告诉大家注意 平时的积累，某些时候的灵光一现可能成为日后的一个重要用例。以前的失败教训也可以帮助我们从中学到经验，毕竟“经验是人为其错误而找的代名词”。
注 意 有一点我想有必要再次提醒大家：单方面的提高测试覆盖率并不能有效的帮助测试质量的提升，尤其是在代码质量低劣的情况下。就拿一个经典的三角形测试用例来 讲，开发人员的代码可能仅仅判断了“两边之和大于第三边”然后就返回“这是三角形”。在测试用例中，我们可能考虑了很多的问题，考虑了输入数据的类型，合 法性等等的问题，但是这并无助于增加测试覆盖率。运行这些测试结果是万里江山一片红，记住在你的测试用例没有运行通过的时候考虑测试覆盖率是没有意义的， 我目前想到了两条理由：一是这些测试用例可能在代码的中间部分就已经出了问题，所以用例本该覆盖到语句没有覆盖到，这降低了代码覆盖率数据；第二个理由测 试用例没有通过可能就如刚才提到的三角形问题中一样，开发人员压根就没有那么多语句给你去覆盖，这时候的代码覆盖率数据显然是没有多大作用的。这也印证了 前面文章中提到的“高代码覆盖率比低代码覆盖率更加‘没用’”。
写到这里，我的观点已经表达完毕了。这一系列文章也差不多可以做个了结了。当然我们还留了一些重要的"尾巴"——测试覆盖率工具。在昨天的文章中提到，笔者将实际学习使用一些工具，并将整理相关的资料，当然我是不会爽约的，不过这些内容恐怕要等一段时间才能开始了。