对于想要API代码覆盖的具体目标号码的人，您会给出多少人数？
更新：澄清，声明/行代码覆盖。我意识到具体数字没有多大意义，但这是针对这样一种情况：你告诉人们具体数字没有多大意义，他们仍然坚持从你那里得到一个数字，无论如何。我专门编写了API / SDK，因为有些人可能会发现应用程序/ GUI级软件更容易接受更低的代码覆盖率，而不是暴露更多接口的库。
答案 0 :(得分：0)
实际上具体数字没有多大意义。
如果有14个等效案例，如果不对所有14个案例进行测试，那么您的测试会更多地给出错误吗？如果你有一个不可能失败的边界检查怎么办？我喜欢在这些情况下抛出描述性异常，然后通过电子邮件发送给我们的开发人员？
最好确保涵盖所有逻辑路径。
有关更详细的答案，请参阅this (very similar) question。
答案 1 :(得分：0)
我会给他们一些建议，他们需要检查他们的API部分，以确定哪些实际上是无关紧要的，需要不超过20％，哪些部分是超级关键的，需要＆gt; 90％。
答案 2 :(得分：0)
看看C.R.A.P. - 它将覆盖范围与复杂性分析相结合如果您是Java，则有Crap4J实现。我们一直在组织一个我们在这里写博客的Crap4Net：
http://www.atalasoft.com/cs/blogs/insertqualityhere/archive/2008/03/28/crap4j-port-to-net.aspx
如果您使用简单的小方法，或者更复杂的方法具有良好的覆盖范围，您的想法就是获得良好的数字。
答案 3 :(得分：0)
忘记代码覆盖率。它只是一个数字，在测试代码时不能成为焦点。场景必须成为焦点，然后是高质量的API。我知道这可能听起来有些夸夸其谈，但是你必须将你的思维方式从代码覆盖改为场景：你是否正在测试你的API有意处理的很多场景？
代码覆盖率对于检测到您缺少某些场景非常有用，如果您编写了很多好的场景，您将获得接近100％的覆盖率，但同样，它只是一个数字而且不能成为您关注的焦点。< / p>
亲切的问候
答案 4 :(得分：0)
您可以使用一些代码覆盖工具为您提供“功能覆盖”，例如，是否执行了某项功能。我坚持认为API中的每个功能都已被涵盖。
API实施中的线上覆盖范围是另一回事。良好做法建议根据线条或陈述以及总规模拍摄70-80％的覆盖率。
答案 5 :(得分：0)
如果您使用PHP，80％似乎是一个很好的建议： http://jordionsoftware.blogspot.com/2009/09/code-coverage-targets.html