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.

从Testivus的帖子中，我认为答案上下文应该是第二个程序员。

从实际的角度来看，我们需要争取参数/目标。

我认为这可以在敏捷过程中进行“测试”，方法是分析我们拥有的代码、架构、功能(用户故事)，然后得出一个数字。根据我在电信领域的经验，我认为60%是一个很好的值。

85%是签入标准的一个很好的起点。

我可能会选择各种更高的发布标准——这取决于正在测试的子系统/组件的临界性。

从另一个角度查看覆盖率:具有清晰控制流的编写良好的代码是最容易覆盖、最容易阅读的，并且通常是错误最少的代码。在编写代码时牢记清晰和可覆盖性，并在编写代码时并行编写单元测试，以我之见，您将得到最好的结果。

直到几天前，我们的目标是>的80%，但在我们使用了大量生成代码后，我们并不关心%age，而是让审核人员决定覆盖率要求。

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