Alberto Savoia的这篇散文恰好回答了这个问题(以一种非常有趣的方式!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus On Test Coverage Early one morning, a programmer asked the great master: “I am ready to write some unit tests. What code coverage should I aim for?” The great master replied: “Don’t worry about coverage, just write some good tests.” The programmer smiled, bowed, and left. ... Later that day, a second programmer asked the same question. The great master pointed at a pot of boiling water and said: “How many grains of rice should I put in that pot?” The programmer, looking puzzled, replied: “How can I possibly tell you? It depends on how many people you need to feed, how hungry they are, what other food you are serving, how much rice you have available, and so on.” “Exactly,” said the great master. The second programmer smiled, bowed, and left. ... Toward the end of the day, a third programmer came and asked the same question about code coverage. “Eighty percent and no less!” Replied the master in a stern voice, pounding his fist on the table. The third programmer smiled, bowed, and left. ... After this last reply, a young apprentice approached the great master: “Great master, today I overheard you answer the same question about code coverage with three different answers. Why?” The great master stood up from his chair: “Come get some fresh tea with me and let’s talk about it.” After they filled their cups with smoking hot green tea, the great master began to answer: “The first programmer is new and just getting started with testing. Right now he has a lot of code and no tests. He has a long way to go; focusing on code coverage at this time would be depressing and quite useless. He’s better off just getting used to writing and running some tests. He can worry about coverage later.” “The second programmer, on the other hand, is quite experience both at programming and testing. When I replied by asking her how many grains of rice I should put in a pot, I helped her realize that the amount of testing necessary depends on a number of factors, and she knows those factors better than I do – it’s her code after all. There is no single, simple, answer, and she’s smart enough to handle the truth and work with that.” “I see,” said the young apprentice, “but if there is no single simple answer, then why did you answer the third programmer ‘Eighty percent and no less’?” The great master laughed so hard and loud that his belly, evidence that he drank more than just green tea, flopped up and down. “The third programmer wants only simple answers – even when there are no simple answers … and then does not follow them anyway.” The young apprentice and the grizzled great master finished drinking their tea in contemplative silence.

我最喜欢的代码覆盖率是100%。星号之所以出现，是因为我更喜欢使用工具，允许我将某些行标记为“不算数”的行。如果我已经覆盖了100%“有用”的行，我就完成了。

底层流程是:

我编写测试来测试我能想到的所有功能和边缘情况(通常从文档开始工作)。 我运行代码覆盖工具 我检查了所有没有覆盖的线或路径，以及我认为不重要或无法到达的线或路径(由于防御性编程)，我将其标记为不算数 我编写了新的测试来覆盖缺失的行，并在没有提到这些边缘情况时改进文档。

这样，如果我和我的合作者将来添加新代码或更改测试，就会有一条亮线告诉我们是否错过了重要的东西——覆盖率下降到100%以下。然而，它也提供了处理不同测试优先级的灵活性。

如果这是一个完美的世界，100%的代码将被单元测试覆盖。然而，因为这不是一个完美的世界，这是一个你有时间做什么的问题。因此，我建议少关注特定的百分比，而更多地关注关键领域。如果你的代码写得很好(或者至少是一个合理的副本)，应该有几个关键点将api暴露给其他代码。

将您的测试工作集中在这些api上。确保api是1)良好的文档化的，2)已经编写了与文档相匹配的测试用例。如果预期的结果与文档不匹配，那么您的代码、文档或测试用例中都存在bug。所有这些都是值得调查的。

好运！

如果你已经做了相当长一段时间的单元测试，我认为没有理由不接近95%以上。然而，至少，我总是使用80%的测试，即使是刚开始测试的时候。

这个数字应该只包括在项目中编写的代码(不包括框架、插件等)，甚至可能排除完全由调用外部代码编写的代码组成的某些类。这种电话应该被嘲笑。

代码覆盖率很好，但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能，这些功能在会议中没有讨论)。

我不关心我的代码是否会在测试中被覆盖，但我关心的是我是否会重构我的代码并最终具有不同的行为。因此，100%的功能覆盖率是我的唯一目标。

这在很大程度上取决于您的应用程序。例如，一些应用程序主要由不能进行单元测试的GUI代码组成。