代码覆盖率（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操作，否则是不会收集到覆盖数据的。
步骤二 ：执行自动化测试用例
步骤三 ：查看代码覆盖率结果
随着编程语言和开发工具的现代化和傻瓜化，现在获取和分析代码覆盖率工作越来越简单了，但人们对代码覆盖数据的使用却仍然停留在比较原始的阶段。其中还有很多值得去深入发掘的好东东，用于帮助测试团队优化测试过程和测试用例的设计。《代码覆盖从简到繁 (四) – 为代码签入把门儿 》一文中介绍了，如何在代码签入的流程中引入覆盖率检查。