对代码覆盖率价值的初步认识

关于代码覆盖率，之前6年的工作经历中，只是依稀听闻过。之前的组织里，从未关注过这个指标，只是有一段时间用NUnit做了单元测试，主要是测试一些关键类关键方法是否正常，对代码覆盖率的印象就真的一直是停留在听闻的程度。汗一个！

前些时日，关于自动测试的讨论中有人提及到代码覆盖率，激发了我的好奇，到底什么是代码覆盖率？最重要的是于测试工作而言有怎样的价值呢？今天花了一点时间查了一下，有了初步的认识。大致归纳如下：

一。基本概念

   代码覆盖率是单元测试活动任务之一；

   覆盖率分语句覆盖率（即通常所说的行覆盖率）和分支覆盖率。

二。价值

   代码覆盖率的分析能在一定程度上评判代码质量，一般覆盖率高的代码出错的几率会相对低一些。但是高覆盖率只是表示执行了很多的代码，并不意味着这些代码被 很好地执行了。所以，似乎覆盖率测试结果出来并不能帮我准确的评价代码质量。那么我们为什么要做覆盖率测试呢？如何让它给我们带来价值呢？

   1. 尽早评估代码质量。

比如在开发的过程中，定时的去看整个项目的代码覆盖率，监控覆盖报告可以帮助开发团队迅速找出不断增长的但是没有相应测试的代码。例如，在一周开始 时运行覆盖报告，显示项目中一个关键的软件包的覆盖率是 70%。如果几天后，覆盖率下降到了 60%，那么您可以推断：软件包的代码行增加了，但是没有为新代码编写相应的测试（或者是新增加的测试不能有效地覆盖新代码）。能够监控事情的发展，无疑 是件好事。定期地查阅报告使得设定目标（例如获得覆盖率、维护代码行的测试案例的比例等）并监控事情的发展变得更为容易。如果您发现测试没有如期编写，您 可以提前采取一些行动，例如对开发人员进行培训、指导或帮助。

   2. 为功能测试关注点提供情报

假设覆盖报告在指出没有经过足够测试的代码部分方面非常有效，那么质量保证人员可以使用这些数据来评定与功能测试有关的关注区域，可以更有针对性地加强这些区域的测试，因为没有被测试代码覆盖到的区域，出错的几率应该相对更高。

   3. 估计修改已有代码所需的时间

对一个开发团队而言，针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比，经过测试的代码更容易重构、维护和增强。测试案例因为 暗示了代码在测试工作中是如何工作的，所以还可以充当内行的文档。在另一方面，没有经过相应测试的代码更难于理解和安全地修改。因此，知道代码有没有被测 试，并看看实际的测试覆盖数值，可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。

   -----

   当然，这样的理解还是比较浅层的，我想实际应用中除了以上三点之外，还有一个很重要的工作就是提高测试代码的质量来更好的体现代码覆盖率的价值。

原文出处：http://www.51testing.com/?uid-101957-action-viewspace-itemid-70695