关于测试覆盖率，我个人的感觉是说的多，用的少。最近在网络上看到一篇文章，讨论一个问题“测试需要100%的覆盖率吗？”被转载了很多次，有兴趣的同行可以找来看看。的确，一想到测试覆盖率，立马就有完美主义者跳出来说100%。100%的测试覆盖率有什么好处呢？
原文发表于2008-12-10 21:39:48
上一篇文章中，介绍了的意义之类的东西。测试覆盖率可以帮助我们检查测试质量，检查测试用例的有效率。如果有兴趣的话，可以阅读测试覆盖率之二——测试覆盖率有什么用？
关于测试覆盖率，我个人的感觉是说的多，用的少。最近在网络上看到一篇文章，讨论一个问题“测试需要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%的问题的讨论还会继续下去，如果必要的话，笔者将在本系列文章的后期继续总结，根据计划，在下一篇文章中(测试覆盖率之四——测试覆盖率工具)我将介绍自己使用过的相关工具，以及我未使用但是可以从网上找到相关资料的工具，帮助大家总结一下，以备查看。 测试覆盖率
关于测试覆盖率，我个人的感觉是说的多，用的少。最近在网络上看到一篇文章，讨论一个问题“测试需要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%的问题的讨论还会继续下去，如果必要的话，笔者将在本系列文章的后期继续总结，根据计划，在下一篇文章中(测试覆盖率之四——测试覆盖率工具)我将介绍自己使用过的相关工具，以及我未使用但是可以从网上找到相关资料的工具，帮助大家总结一下，以备查看。 测试覆盖率
