1

对于想要 API 代码覆盖率的具体目标数字的人，您会给多少数字？

更新：为了澄清语句/行代码覆盖率。我意识到具体数字没有多大意义，但这是针对您告诉人们具体数字没有多大意义而他们无论如何都坚持要从您那里获得数字的情况。我专门编写了 API/SDK，因为有些人可能会发现应用程序/GUI 级软件更容易接受较低的代码覆盖率，而不是暴露更多接口的库。

4

6 回答 6

0

实际上，具体数字没有多大意义。

如果有 14 个等效案例，如果您不测试所有 14 个案例，您的测试是否更容易出错？如果您有一个不可能失败的边界检查怎么办（我喜欢在这些情况下抛出描述性异常，然后通过电子邮件发送给我们的开发人员）？

最好确保覆盖所有逻辑路径。

有关更详细的答案，请参阅这个（非常相似的）问题。

于 2008-11-13T14:47:36.803 回答
0

我会给他们的建议是，他们需要检查 API 的各个部分，以确定哪些实际上无关紧要并且需要不超过 20%，哪些部分非常关键并且需要 > 90%。

于 2008-11-13T14:47:58.737 回答
0

如果您使用的是 PHP，80% 似乎是一个不错的建议：http: //jordionsoftware.blogspot.com/2009/09/code-coverage-targets.html

于 2009-09-25T01:01:26.330 回答
0

Take a look at C.R.A.P. -- it combines coverage with complexity analysis. There is a Crap4J implementation if you are Java. We have been putting together a Crap4Net that we blogged about here:

http://www.atalasoft.com/cs/blogs/insertqualityhere/archive/2008/03/28/crap4j-port-to-net.aspx

The idea is that you get good numbers if you have small simple methods or if the more complex ones have good coverage.

于 2008-11-13T14:51:27.700 回答
0

您可以获得一些代码覆盖率工具来为您提供“功能覆盖率”，例如，是否执行了某个功能。我坚持要涵盖 API 中的每个函数。

API 实现内部的行覆盖是另一回事。好的做法建议根据行或语句和总大小拍摄 70-80% 的覆盖率。

于 2009-07-20T08:39:11.527 回答
0

忘记代码覆盖率。只是一个数字，不能作为测试代码的重点。场景必须是焦点，然后是高质量的 API。我知道这听起来可能是胡说八道，但您必须将思维方式从代码覆盖转变为场景：您是否正在测试您的 API 打算处理的大量场景？

代码覆盖率将有助于检测您是否遗漏了一些场景，如果您编写了很多好的场景，您将拥有接近 100% 的覆盖率，但同样，它只是一个数字，不能成为您的重点。

亲切的问候

于 2008-11-16T23:23:39.223 回答