关于测试覆盖率讲的最多的地方应该实在测试停止标准里面。在测试停止标准里面经常出现这样的语句“测试覆盖率达到或超过95%”之类的概念。其实，如果你看了我前一篇文章中提到的测试覆盖率分类的话，就知道这是一个不准确的描述。关于更准确的描述，我认为应该是“性能测试需求覆盖率达到100%，功能需求测试覆盖率达到100%，语句覆盖率达到85%”这样的句子。“测试覆盖率”本来就包含了很多子部分，所以提测试覆盖率是不明智的一种做法。而我所说的语句覆盖率85%相对于性能测试需求覆盖率这个数据来讲似乎更难获得准确数值，不过现在已经有了很多工具用于测试“语句覆盖率”，而不用我们自己去计算已执行的测试用例覆盖到了数万或者更多代码中百分之多少，也有一些工具可以帮助我们得到代码覆盖率中“分支覆盖率”等其它数据。关于覆盖率检测工具，我将在本系列的后续文章中给予介绍。
测试覆盖率是测试结束标准中的一部分，这显然不是我们今天讨论的重点——测试覆盖率有什么用？直观上讲，我们可以这样理解：
-> 性能测试覆盖率如果没达到100%，表示我们有些性能测试点没有覆盖到，这在一个对于性能有所要求系统显然是不可取的，这表示我们应该增加用例来覆盖到所需要的性能测试点。
-> 重要模块的语句覆盖率和条件覆盖率很低，表示我们测试用例过少，我们应当增加用例；如果我们已经写了很多用例（相对于代码行数来讲），但是这两项数据还是很低，那我们得检查一下我们的用例了，是否有重复的用例？是否应该重新设计用例结构？
对于测试覆盖率，我们有这样一个简单的算式，如果A模块的条件覆盖率为80%，B模块也为80%，C模块也为80%，那么我们的总覆盖率则是 51.2%，而不是我们想当然的80%。至于为什么这样，我就不解释了。因此在我们审查覆盖率报告时候，我们关注的是覆盖率低的模块，我们要检查为什么低，我们要思考怎么提高，对于覆盖率低的地方，是不是有一个等价类被我们忽略了？
测试覆盖率的意义在瀑布式的开发模式里面可能显得没那么重要，但是如果在螺旋式开发模式中，如果我们没有控制好我们上一个迭代中的测试覆盖率，当一个版本一个版本累加下来后，你就很难确定我们哪些模块在开发过程中没有给予足够的测试；在近些年兴起的持续集成浪潮中，由于要求短迭代（有人建议3-5天一个迭代），如果没有很好的测试覆盖率保证，很难在这么快的代码变迁中保证测试的质量。在持续集成工作中，代码提交频繁，我们可以通过测试覆盖率来了快速对应新写的，没有对应测试的代码。
总之，测试覆盖率可以提供给我们两个方面的信息：测试覆盖率低的模块 和 重要模块的测试覆盖率。这些数据可以帮助我们快速定位需要更多测试的模块，可以帮助我们了解重要模块的测试情况，以此来衡量我们测试用例的质量乃至测试的质量。
个人观点，仅供参考~~（如有问题请联系unique.wuchaodong@hotmail.com）在下一篇文章中，我将介绍关于测试覆盖率应该达到的数据，是不是需要100%呢？
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/