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

　　----------------------------------------------------------------------

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

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

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

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

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

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