你真正需要的代码测试覆盖率是多少？

　　本文是从 How much code coverage do you really need? 这篇文章翻译而来。

　　我写这篇文章的起因是由于看了@unclebobmartin在微博上的一些看起来言之凿凿的话语。给那些不认识Uncle Bob的人介绍一下——他是我们软件产业里最著名的一个专家，是《 Clean Code(代码整洁之道)》这本著作的作者，是敏捷宣言(Agile Manifesto)的签署人之一。在上世纪九十年代，他对文献最佳面向对象实践方法贡献了很大的力量。所以，当他说话时，我们一定要关注一下。

　　他给我们日常的TDD和单元测试制订了一个最高纲领。我们可以从他的微博里清楚的看到这点：

“两件事。可重复性和成本。跟自动化测试比起来，手工测试的成本高的可怕。”

“手工测试不是测试；那是在做实验。只要有人的因素牵涉其中，那结果就必然可疑。”

“你们告诉我的实际意思就是让我大开方便之门、不去测试某些程序。哼…”

“代码覆盖率100%并不是成绩，那是最低要求。即使只写了一行代码，你也要测试它。”

　　他接着把软件测试跟在其它领域里常见的但被认为很关键的活动进行了比较：

“战地外科医生也许没有最够的时间做严格的消毒，但这带来的风险可能是死亡或高昂的治疗代价。”

“会计难道只会把80%的数据表做双份备份吗？”

“有多少回你们都看到了那些严重的宕机事故都是因为一些愚蠢的程序员以为那些愚蠢的代码不许要经过测试而导致的？“

　　他的所有这些观点都很有价值，但他只向我们展示了问题的一面。现实中并不是所有的应用都需要如此谨小慎微的测试。并不是所有的应用都跟战地手术或巨额资金核算那么重要。(更不要说在很多情况下的为”合理避税“而做的帐务:))。

　　一个更重要的原因是，100%的测试覆盖率并不能保证bug的不出现。就连Uncle Bob自己也承认：

”测试并不能杜绝bug。但测试能保证程序的行为是符合预期的。“

　　这很显然指的是：同一个程序员在程序里埋下的概念性或逻辑性错误，由他自己测是绝对测不出来的。

　　最终，所有的问题归结于ROI(投资收回率)和实用主义。有些应用比其它应用需要更多的测试。有些bug需要比其它bug投入更多的精力去修复。究竟是否需要在自动化测试是投入更多的时间和财力，或多少覆盖率是合适的还是过分了，这都需要人的主观判断。