片面追求单元测试覆盖率之我见

一些个人之见，讲出来希望大家讨论。这完全是工作中遇到的一些具体问题抽象出来的一个东西，仅属于个人之见，任何的意见都是欢迎的。

----------------------------------------------------------------------
在工作中，当被问到“如何提高代码质量”，回答无非如下几个，增加评审，代码规约，单元测试。不知起自何年何月，如今一些机构开始引入“单元测试覆盖率”的概念，并由此对程序员提出了覆盖率要达到70%，90%，以此来评判程序员工作的质量，以及产品的质量。这里先预为单元测试下定义以免混淆，即，基于Junit，类与代码级别的，与运行时无关的白盒测试。

而单元测试覆盖率，何以得知呢？一个（当然不是所有）最常使用的办法便是如cobertura之类的工具来执行Junit的测试用例，这些工具不会去统计程序的逻辑，而是判断用例执行到的行数。如果再引入hudson一类的持续集成工具，便可生成漂亮的日报表，管理层也就可能直接地了解这些技术数据。这些都是好的实践，但我想说的并非这些，而是想与大家探讨这些数据是否与产品的质量有着必然的相关。

写过测试用例的朋友们一般地会了解，测试用例与接口有必然的关联，而多数情况下会是直接调用。修改接口会带来测试用例的修改，这是多数情况下不争的事实。有人说为测试可以预留专用的接口，但这种做法在一个要求代码安全的机构中不会得到接受。所以，代码评审/重构或代码上下文变更导致的接口变化，多数情况下会带来测试用例的修改；用例越丰富，这部分的工作量越大，此其一。

其二，讨论单元测试覆盖率与正确代码逻辑的相关性。我们需要衡量的代码的逻辑，乃是在运行时外部触发系统时可能运行的所有逻辑，其包含接口内部逻辑，也包含接口调用逻辑。当接口间存在内容耦合和控制耦合时，合理的测试用例中对于接口间的调用顺序和想定上下文都有要求，与覆盖率并不相关。如a-b-c与c-b-a的调用，覆盖率完全相同，但结果可能完全不同。这一点在测试状态机相关的代码时显得更为重要。

其三，我们经常说到20%和80%的关系。即有80%的时间应当用在20%重要性的事情上。反观程序员写的代码，关键模块与非关键模块的比例也如是。倘时间不是问题自然可以把所有的事情做到完美，一旦时间是问题，哪一个优先，自一目了然。问题是，关键模块由于逻辑复杂，依赖较多，往往是最难测试，其用例也最难写作。人性往往倾向于先易后难。若覆盖率是唯一的指标，最关键的部分便很容易因为覆盖率目标已经达到而被忽略，80%的覆盖恰恰没有覆盖的是最应该测试的代码，很不幸，最易测试的，是那些对于POJO，数据库，配置文件操作的清晰逻辑，通过一个集成测试的用例就可以全部保证的。

那末，为什么覆盖率会成为这样多项目经理趋之若鹜的管理方法呢？显然，这是一个节约管理成本可见收效的举措。只需要把cobertura和hudson配好了放在那里并说明给所有程序员，就可以坐看数字一天一天的上升而觉得质量在一天一天地变好，不需要组织什么评审，不需要去过问每一个人的状况，不需要再去费力地去看报告，何乐而不为？

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