我读了软件测试代码覆盖率的讨论。讨论主要是由哪些代码覆盖率数字单位测试或整体测试是正确的或所需。40%、60%、80%、甚至100%？一些声称，谷歌只需要60%。一些问我在微软代码覆盖数要求是什么。就我所知，也没有代码覆盖要求自己在微软，但只是指导。虽然我不克不及代表谷歌，但他们很有多是这里的相同。代码覆盖率，那里是只的指导，没有要求。而是奉告他‘没有要求’，以为写的几点思考更好我有关于代码覆盖率。（免责声明：当我讲话microsoft或谷歌，我必须使用"一般"，"在年夜大都情况下"，或"在许多产品团队"，因为微软和谷歌是那么年夜，多样，有这么多的产品团队、有没有通用体例每个工程实践。一些小组做这种体例，以其他的体例，可是有一些团队做常见的做法，通过很多或年夜大都团队。代码覆盖率是其中之一。）

代码覆盖率事实是什么？代码覆盖率是权衡多少测试的一组所涵盖的产品代码。它可以丈量的通过线、块、弧形的、由类，或文件，等等……在年夜大都情况下，我们作为代码覆盖率单位使用块。注：我们只收集基于自动化测试的代码覆盖率，不斟酌手动测试。

在年夜大都的microsoft产品团队，我们规定收集代码覆盖率编号。有不合的代码覆盖率，我们收集的数字按照不合类型的测试中，例如，代码覆盖率的单位测试，对组件测试，代码覆盖率和方案测试（e2e）的代码覆盖率。只要取得了运行单位测试，自动收集的单位测试的代码覆盖率。所以开辟整理编写代码/单位测试在签入之前，它们运行一组测试（签入质量年夜门），包含单位测试。所以你得单位自动测试代码覆盖率。组件测试和方案测试的代码覆盖率收集代码覆盖率生成peroidically，例如每周一次或上的需求。

总是有关于代码覆盖率的真正益处的争论。一些暗示代码覆盖率数字代表的产品质量，越高，号码是，产品的质量就越高。一些暗示，更高的代码覆盖率其实不料味着更高的质量，因为100%coverred代码仍有bug，哪个是正确的。

这里是我作为代码覆盖率上：

1.代码覆盖率是重要的。很容易和简单，收集和快速的体例，让您体会如何测试代码上。它让您直不雅显示和查抄如何测试代码。有点像在漆黑中闪烁的灯光，让你更清楚地看到许多对象。它没有保障，您不会当然看到漆黑中的对象。但没有闪光灯，它将很难看到该对象。

2.虽然代码覆盖率100%不其实不料味着bug免费的但代码覆盖率为0%不会心味着巨年夜的风险，产品质量。

3.代码覆盖率唯一的办法如何测试代码，不如何测试产品。

所以，我们需要对代码覆盖数的要求吗？如果是的是最好的有多少？

第一，任何数量是相聚的上下文。号自己不是目的。它是任何行动需要遵循的指标。它像你这样有100点学校测试，是功德吗？坏吗？谜底是：这取决于。它取决于什么是总积分，容易/坚苦的测试中，您的同行取得什么点，等等。。。它是相同的代码覆盖率数目的。60%、80%或100%没有任何意义没有上下文。

然后应怎么用它后收集代码覆盖率？这是完全收集代码覆盖率编号的意思，找出你应如何措置您的代码覆盖率号码，或如何使用/诠释数目：

1.测试差距阐发。我会说这是最重要的优点的代码覆盖率。有很多体例来做测试差距阐发，然而，阐发代码覆盖率的赛跑是最有效的体例之一。测验代码覆盖率编号，看看哪些范畴较低或零覆盖面，决定任何测试可能错过或potenail地区的危险。

2.测试效果阐发。我有1000年测试用例以1天来运行的。可它削减到500测试用例，200测试用例不当协整体测试覆盖率吗？

3.测试和代码更改关联阐发。求解带在软件测试中的疑难问题之一就是：我只是更改一行代码，您需要运行1000年测试用例以验证是否没有回归的一天吗？那里了更好的体例。其中，更好的体例是运行只影响测试。问题是，你怎么知道测试有什么影响。有研究东西可用来帮忙，通过使用代码覆盖率。

4.看到你的代码覆盖率的趋势，随着时间的推移，越来越更高和更高或更低，更低。

最后，如果您必须需要从我的一个数，这里是我的指导。同样，任何数量是相聚的上下文。

1.如果你的单位测试cc>80%，只有当你有时间时，您应采纳行动

2.如果您单位测试抄送是50%至80%之间，你应拨出一些时间内您当前的里程碑，对它采纳行动。