我读了软件测试代码覆盖率的讨论。讨论主要是由哪些代码覆盖率数字单元测试或整体测试是正确的或所需。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%之间，你应拨出一些时间内您当前的里程碑，对它采取行动。

　　3.如果您的单元测试抄送是<50%，你应拨出时间尽快对它采取行动。

　　4.如果您的单元测试抄送是<30%，你叫你自己开发人员杂项费用:)

　　希望此帮助……。