容我说，懂得我上面说的话，却坚持还要这样做的人可以被看成软件项目管理中的官僚主义。人力是人力，它不会凭空变少，也不会凭空变多。用在70%-90%覆盖率上的人力成本，与其他方法比起来值与不值？软件工程没有银弹，只有综合各种方法形成适合自己产品的方法才是好的质量控制。在我个人看来，单元测试而言，确定我们拥有高质量的测试用例，确定关键的模块都有相关的测试对应，比简单地追求覆盖率要重要得多。而这些通过传统的评审和走查可以轻易做到的事情，却常常被我们定义流程和日常管理中忽略了。

　　开发人员测试（请注意我没有说单元测试）的好处已经基本上成为共识，其目的在于在软件流程的上游发现尽可能多的问题，从而减少质量问题带来的人力成本。实际上，单元测试的覆盖率之所以成为一个话题，关键在于该方法是否能够在相对低的人力成本下尽可能地保证提交给测试团队的产品质量，而不是在有限的效果下带来人力资源的浪费与士气低落。

　　正如上面所定义的，能够完成代码行数统计的单元测试，是限于在某种工具范围内能够完成的狭义的单元测试，是开发人员测试的一部分而不应该属于全部。很多讨论，其实是忽视了开发人员测试与单元测试的差别。片面追求这种单元测试的覆盖率的一个影响是，它不鼓励开发团队使用其他的测试方法，往往只适用于某些产品和某些场景（如，纯算法等与上下文关系不大的模块），对于特殊的软件模块（如，与IO和多线程相关和一些强烈依赖上下文的模块）则事倍功半。（有人可以举出JMock，Easy-Mock这样的例子，来说明测试与上下文解耦合的可行性；但我想说的是这样Mock出的上下文逻辑只是保证调用顺序与开发人员设计的相同，却不能保证结果正确；有关Mock的话题太长，如果大家感兴趣可以另外讨论）

　　做为项目经理，需要保证测试进行，更要保证测试有效地进行。是否测试代码覆盖的是有意义的部分，是否测试用例是合格而有用的，需要组织有效的评审与专家走查，从而根据上下文，使用合适的技术写出有针对性的用例。

　　一个能够量化的产品的Q值，也许应该综合代码覆盖率，集成测试个数，测试用例质量和代码评审质量来考量。

　　我们不想见到的，是质量不高的高代码覆盖率，掩藏了很多其他方面的问题（我可以写一个基于反射的小用例轻易地覆盖50%以上的代码）。这不是拿工具来生成一个覆盖报表并复制到PPT里那样简单的事情，但却更加重要而有意义。然而软件质量的管理是一个系统工程，应综合使用技术手段进行科学，合理的计划与评估，绝不是某一种方法放之四海而皆准。