引言
Martin Fowler（重构那本书的作者）曾经写过一篇博客来讨论这个问题，他指出：把测试覆盖作为质量目标没有任何意义，而我们应该把它作为一种发现未被测试覆盖的代码的手段。
Brian Marick（敏捷宣言最早的17个签署人之一）也说过，作为一名程序员，我当然期望我的代码有较高的测试覆盖率。但是，当我的经理要求这样的指标时，那就有别的目的了（绩效考核？）。
我认为，高的测试覆盖率应该是每个“认真”写单元测试的程序员得到的必然结果，管理者把一个结果作为指标来衡量，本身就是没有意义的。如果你把“万能”的程序员逼急了，他就会从 “神秘的工具箱”中拿出一两个“法宝”来，“高效”地达成指标。我就见过很多这样的“法宝”，比如在单元测试中连一个“assert”也没有，或者写很多get和set方法的单元测试（写起来简单啊）来提高整体的覆盖率等等。更何况，测试充分的代码也有可能无法达到100%的覆盖率，本文的后面就有这样的例子。
那你大概会问：“那测试覆盖到底有什么用呢？”。我的答案还是很简单，“测试覆盖是一种学习手段”。学习什么呢？学习为什么有些代码没有被覆盖到，以及为什么有些代码变了测试却没有失败。理解“为什么”背后的原因，程序员就可以做相应的改善和提高，相比凭空想象单元测试的有效性和代码的好坏，这会更加有效。
接下来，我会给大家介绍一些传统的测试覆盖方法和一种称为“代码变异测试”（Mutation Test）的方法。大家将会看到这些方法都可以产生什么样的学习点，以及代码变异测试相比传统方法更有价值的地方。如果你是一名程序员（我不会区分你是开发人员还是测试人员，那对我来说都一样），希望你看完这篇文章之后，可以找到一些提高测试和代码质量的方法。如果你是一位管理者，不论你正在用还是想要用“测试覆盖率”来做度量，希望你看完这篇文章之后，可以放弃这个想法，做点更有意义的事情（比如去写点代码）。
传统的测试覆盖方法
传统的测试覆盖方法常见的有以下几种：
函数覆盖（Function Coverage）
语句覆盖（Statement Coverage）
决策覆盖（Decision Coverage）
条件覆盖（Condition Coverage）
还有一些其他覆盖方法，如Modified Condition/Decision Coverage，就不在这里讨论了。
函数覆盖：顾名思义，就是指这个函数是否被测试代码调用了。以下面的代码为例，对函数foo要做到覆盖，只要一个测试——如assertEquals(2, foo(2, 2))——就可以了。如果连函数覆盖都达不到，那应该想想这个函数是否真的需要了。如果需要的话，那又为什么写不了一个测试呢？
语句覆盖：（也称行覆盖），指的是某一行代码是否被测试覆盖了。同样的代码要达到语句覆盖也只需要一个测试就够了，如assertEquals(2, foo(2, 2))。但是，如果把测试换成assertEquals(0, foo(2, -1))，那就无法达到所有行覆盖的效果了。通常这种情况是由于一些分支语句导致的，因为相应的问题就是“那行代码（以及它所对应的分支）需要吗？”，或者“用什么测试可以覆盖那行代码所代表的分支呢？”。
