水大了，还是面大了？

        早年间北方人过年的时候，有很多忌语的，凡是不好的字眼一律不许多。比如包饺子的时候，水少了不能说水少了，要说“面大了”，面少了呢，要说“水大了”，总之不允许说“少”、“小”一类的字眼。

        我们固然宣称自己是无神论者，也不信仰什么宗教，但也没必要对此上纲上线，因为这也是人之常情，古今中外皆是如此，外国人过圣诞节时也是见面互称“哈屁”，大过年的——你看，又带个大字——谁不图个吉利呢。然而凡事都有个度，过了就不好了。还拿包水饺这事来说，即使是上了年纪的老人们，也是在过年这种特殊的时候才提这档子事情，没有说平时过日子的时候就定这么些个规矩的。

        那么我们在做软件测试时，是不是覆盖率越高越好呢？

        软件测试对应不同的开发阶段也有不同的测试方法，一般来说从小到大有单元测试、组件测试、集成测试、系统测试等，这些不同的测试方法测的对象不同，针对的内容也就有所不同。例如单元测试验证类、函数这个级别的代码，组件测试是验证组件的接口，集成测试验证子几个模块组成的子系统，系统测试当然就是面向最终用户的应用级别的验证工作了。跟洗汽车一样，相对于把整个车放水龙头下乱喷一气而言，肯定是拆开了一个一个零件的插洗能够更全面的——单元测试就像洗零件，覆盖率最高，很容易达到100%。但只有单元测试是远远不够，毕竟，每个零件都锃亮并不说明拼装起来就能跑，零件之间能不能很好的相互协作还是个问题呢，所以我们还需要组件测试、集成测试、系统测试等等，需要一层一层地逐步验证，从小到大保证在每一个级别都是可用的，最后拿出去一个完整的产品才放心。

        是不是在每一级的测试都要保证100%的代码覆盖率呢？我看并不一定，我们知道，对于大型的商用软件来说，异常处理往往占据相当多的代码量，小到系统级别的内存等资源申请失败，大到错误的流程、操作，这些异常处理的代码通常并不长，也不太涉及太多的模块交互，通过单元测试很容易覆盖到，也可以保证充分验证。但是利用其它测试方法，比如组件测试来覆盖这些异常处理的代码相对来说就很困难了，而且也没多大必要。软件代码毕竟不是汽车，不是每行代码都测试过，就保证一定没有问题了，从理论上讲，一个小到几十行的代码可能其路径数就已经是相当大的天文数字了，代码行100%覆盖，并不能保证路径、判定等也100%覆盖。所以，只要保证良好的设计，在做较高级别的测试时，只要得出一个稳定的覆盖率就已经足够了，倒并不一定越高越好。话说回来，在同一个项目中，同一批人写的代码，前几个星期的覆盖率是80%，这个星期是70%，那说明可能是测试不充分。但如果是这个星期突然变成90%呢，倒不一定说明测试充分，而是很可能异常处理没有做充分。

        软件的质量有很多数据可以衡量，但并不是所有的数据都是越“大”越好，过分地追求“大”的数据，很可能丢了西瓜捡个芝麻。毕竟，在浩如烟海而又变化莫测的软件代码面前，人的精力是有限的。