我不止一次听到有些人在说他们不知道测试覆盖率该用来做什么，或者有些人说会以他们的测试覆盖率感到自豪。这些说法都不是测试覆盖率的所表达的意义。测试覆盖率是一个发现项目中未测试代码的一个很有用的工具；但是却并不是一个有用的衡量项目中测试用例质量的工具。

　　我们先看看另一个观点，我经常听到人说：

　　你的项目不能发布如果测试覆盖率少于87%。

　　还有人说：

　　你必须使用测试驱动开发（TDD）并且测试覆盖率必须是100%。

　　一位明白人曾经说过：我期望测试覆盖率能很高。有时候管理者需要这个。这两者之间的差异是微妙的。

　　如果项目中指定要求一定的测试覆盖率，开发者会尽力去达成。不过问题是，开发者很容易达成覆盖率这个数字，用低质量的测试用例，最差的情况你会发现项目中的测试用例都是assert（true）（我们称之为空用例）的。但是即使你有很多非空用例，你也会发现这些用例很难发现代码中的问题。

　　从编写代码的角度来说，编写测试用例是一件很费脑精的事情（不会比写功能代码轻松）。测试驱动开发是一个很好的工具，但是仅仅测试启动开发不能帮助你写出高质量的测试用例。如果你写测试代码时候，考虑比较周全，你会期望测试覆盖率达到80%或90%，但是我很怀疑100%，100%只能让对测试覆盖率这个数字感兴趣的人们开心，而完全不知道100%的内容。

　　人们关注测试覆盖率这个数字的原因是他们想知道项目测试是否充分。很低的测试覆盖率，如低于50%，很确定是有问题的；但是很高的测试覆盖率并不表示代码测试很充分。是否充分测试这个问题很复杂，并不是一个测试覆盖率数字就能回答的。我的观点是，如果下面两点成立，你项目的测试覆盖率就比较充分：

　　● 发布的版本中bug很少。

　　● 你非常反感改某些代码因为你害怕改动会引入bug

　　为了测试覆盖率，有时候你会写很多测试用例，过多的测试用例不仅对提高测试质量没有用并且还会提高维护成本。当你删除一些测试用例后发现测试还是充分的，就说明你的测试用例过量了。但是这个很难衡量。测试用例过量的一个比较明显的特征是测试用例执行很慢。还有就是当你改动一处代码，需要改动很多处测试代码的时候，可能你的测试用例过量且重复了。

　　因此又回到初始的问题：测试覆盖率的意义是什么？它能帮你找到项目中未测试到的代码，每天执行测试用例来发现项目中未测试的代码，是很有价值的。你是否会感到忧虑如果又代码未被测试？

　　如果你的测试用例在某些方面很脆弱，覆盖率能够发现；如果你的测试用例在某些方面很脆弱，覆盖率不能发现。