这篇文章中，主要讨论的是如何提高测试覆盖率的相关问题。其实，提高测试覆盖率最基本，甚至是唯一的办法就是增加测试用例，但是怎样通过增加测试用例而帮助我们“迅速”提高我们的测试覆盖率呢？
原文发表于2008-12-14 20:49:49
在上一篇文章中，简单的而介绍了一些测试覆盖率相关的工具，由于大部分工具笔者并没有使用的经验，因此只是简单地从网络搜索了一下相关资料并将其整理出来，关于上篇文章的详细内容，参见：测试覆盖率之四——测试覆盖率工具汇总。
这篇文章中，主要讨论的是如何提高测试覆盖率的相关问题。其实，提高测试覆盖率最基本，甚至是唯一的办法就是增加测试用例，但是怎样通过增加测试用例而帮助我们“迅速”提高我们的测试覆盖率呢？
代码走查 对于代码的不熟悉造成了我们的代码覆盖率迟迟上不去，我们需要了解到代码里面究竟有多少条件分支，多少怎样的循环，分支和循环向来是导致我们代码覆盖率比较低的原因，另外，是不是存在一些过时的代码，没有运行过代码监测工具的代码中很可能存在一些没有被引用的死代码，而代码走查，尤其是对于覆盖率低的模块的代码走查将有助于你增加相关的用例而提高代码覆盖率。
工具 这里倒不是说有些工具可以帮助你直接提高代码覆盖率，这样的工具至少我还没有就见过。这里提到的工具主要包括两种，一是代码分析工具另外一种就是上篇文章中提到的代码覆盖率工具。代码分析工具可以帮助我们分析代码中的冗余部分，这样可以帮助我们干掉那些总是不可能覆盖到的死函数，有的编译器已经提供了类似的功能。使用代码覆盖率工具则可以帮助我们快速监测代码覆盖率低的地方，这样我们可以快速定位我们测试的薄弱环节，通过代码走查或其他方式可以快速增加用例。一般来讲，某一模块的代码覆盖率从30%提高到50%所需的时间遥远小于从60%提高到80%的时间。
规则 这里所指的规则其实是指一些基本测试方法，如等价类划分，边界值分析。我们有时候需要通过这些手段来逐一检查我们那些方面的测试用例没有考虑到，从而帮助我们增加相关的测试用例。
经验 这个看起来有点像废话，因为一般都知道测试经验丰富有助于测试用例的设计，写出别人没有想到的测试用例。我在这里把这句话提出来的主要意图是告诉大家注意平时的积累，某些时候的灵光一现可能成为日后的一个重要用例。以前的失败教训也可以帮助我们从中学到经验，毕竟“经验是人为其错误而找的代名词”。
注意 有一点我想有必要再次提醒大家：单方面的提高测试覆盖率并不能有效的帮助测试质量的提升，尤其是在代码质量低劣的情况下。就拿一个经典的三角形测试用例来讲，开发人员的代码可能仅仅判断了“两边之和大于第三边”然后就返回“这是三角形”。在测试用例中，我们可能考虑了很多的问题，考虑了输入数据的类型，合法性等等的问题，但是这并无助于增加测试覆盖率。运行这些测试结果是万里江山一片红，记住在你的测试用例没有运行通过的时候考虑测试覆盖率是没有意义的，我目前想到了两条理由：一是这些测试用例可能在代码的中间部分就已经出了问题，所以用例本该覆盖到语句没有覆盖到，这降低了代码覆盖率数据；第二个理由测试用例没有通过可能就如刚才提到的三角形问题中一样，开发人员压根就没有那么多语句给你去覆盖，这时候的代码覆盖率数据显然是没有多大作用的。这也印证了前面文章中提到的“高代码覆盖率比低代码覆盖率更加‘没用’”。
写到这里，我的观点已经表达完毕了。这一系列文章也差不多可以做个了结了。当然我们还留了一些重要的"尾巴"——测试覆盖率工具。在昨天的文章中提到，笔者将实际学习使用一些工具，并将整理相关的资料，当然我是不会爽约的，不过这些内容恐怕要等一段时间才能开始了。
测试覆盖率系列中文章均为作者个人观点，如有问题或者建议请联系unique.wuchaodong@hotmail.com或直接留言。
