代码覆盖率（Code Coverage）是反映测试用例对被测软件覆盖程度的重要指标，也是衡量测试工作进展情况的重要指标。它也是对测试工作进行量化的重要指标之一，测试工作往往不如开发那样激动人心，一个重要原因之一就是测试难于量化，而代码覆盖率恰恰是解决着一问题的重要指标。

　　根据其覆盖内容的不同，又可以细分为：语句覆盖、判定覆盖、条件覆盖、路径覆盖以及循环覆盖等等，这里有一篇很好的博客《代码覆盖率浅谈》介绍了各种不同覆盖率的定义。有的理解起来还是蛮拗口的，但其实不难，用到了再看就成！在所有这些覆盖中语句覆盖（Statement coverage）是最简单的，但也是最常用的、最实际有效的覆盖率，Visual Studio采用的是语句覆盖中的基本块覆盖（Basic block coverage）。

　　对于敏捷开发团队而言，代码覆盖率是每个Sprint要完成的硬性质量标准（Exit Criteria）之一，覆盖率高低根据项目的不同而不同：75%，80%甚至100%都是可能的。代码覆盖率是一个白盒概念，应为毕竟它最后要落实到代码。既然代码覆盖率如此重要，那么什么时候该用它？该如何用它？

　　有人认为代码覆盖率重要，所以从项目的一开始就要进行代码覆盖率的检查和分析，即 获取覆盖率 –> 发现未覆盖的代码 –> 添加新测试用例。这样的使用方式，我把它命名为“代码覆盖率驱动的测试（CCDT，Code Coverage Driven Test）”。CCDT看起来很美，理论上无懈可击，但实际操作则完全不是那么回事儿。先不说这种方式是否正确，单就由此引入的开销来说，就够项目组喝一壶的，呵呵！之所这样说，是因为CCDT需要经历：获取覆盖率、分析覆盖率和添加测试用例这三步，每一步都存在着很多潜在“副产品”开销，尤其是前两步。要获取覆盖率，需要执行所有的测试用例，而你知道现在业界70%的测试仍然是手动的，仅为了覆盖率就频繁的执行测试用例，显然是不现实的；频繁分析覆盖率结果也是一件耗时的工作，无论开发人员还是测试人员做都是如此，尤其是对于采用敏捷开发方法的团队，短迭代不允许引入如此劳神的工作内容。胡凯在他的博客中称这种唯覆盖率论症状为“测试覆盖率强迫症”，其中有一句描述很精彩：

　　我认为对于测试团队而言，测试的过程应该是用户场景覆盖驱动的测试（USCDT，User Scenario Coverage Driven Test） ，即测试人员应该从用户真实使用场景出发，思考要测试的内容和设计测试用例。代码覆盖率是对USCDT的必要补充，以发现其中未覆盖的场景（Test Hole）。代码覆盖应该是在项目/迭代的中后期引入，不用很频繁，点到为止，例如对一个3-4周的迭代，3次的覆盖率检查就已经足够了。当然，如果你的自动化测试比例比较高，采用持续集成（Continuous Integration）的方式，例如：Visual Studio 2010中持续集成的构建功能，每次都能自动的进行代码覆盖率的统计，则可以更早，更频繁进行代码覆盖率，但前提一定是这不会带来过多的开销。

　　说了这么多，下面来点儿实际的吧，看看Visual Studio 2010中如何获取代码覆盖率数据！在Visual Studio的集成开发环境中获自动化测试用例的码覆盖率数据是最简单的（采用命令行方式则稍复杂一些，但它还可以用来获取手动测试用例的覆盖数据），只需要下面三步：

　　步骤一 ：在Test Settings配置中选择Code Coverage

　　（Updated 2011/6/1） 这里需要注意，当选择Code Coverage项时，还要选择“Configure”按钮去配置一下要针对哪一个文件（.exe/.dl）收集覆盖数据，Visual Studio会自动对这个文件进行instrument操作，否则是不会收集到覆盖数据的。