在《代码覆盖从简到繁（一）》中曾经介绍过，获取和分析代码覆盖数据是为了发现被测试产品中可能存在的测试漏洞（Test Holes），同时也是衡量当前测试覆盖效率的重要指标。代码覆盖率是测试团队的重要工具和测试活动之一，但由于要涉及代码的走查和分析，所以需要开发人员的参与和配合。

　　那么除了发现测试漏洞，代码覆盖率还有其它什么作用吗？在回答这个问题之前，让我先谈谈软件测试的目的。记得Google的段念在第二届（杭州）互联网测试技术交流会上有一个题为《颠覆者生存：互联网产品测试观点》的演讲。其中，他提出了4个PK，第一个PK是：度量质量的测试 vs 提高质量的测试。中心思想是说，如果测试仅是以找到缺陷为目标，那么它就是质量度量测试，而如果通过软件测试活动辅助改善软件开发流程，在早期就有效避免缺陷的发生，那就是软件测试一个更高的境界 – 提高软件质量的测试。讲得很有道理！那么这和代码覆盖率又有什么关系呢？其实，代码覆盖率也可以作为一种手段，用来辅助我们改善开发活动。

　　持续集成是敏捷开发中重要的一环，无论是代码签入前验证（Pre-check-in validation）还是签入后检查（Post-check-in validation），都要求签入的代码达到比较全面的测试，这通常是通过执行一组事先选定好的测试用例，这组用例都通过，也就任务认为签入的代码达到了比较全面的测试。那么该如何选择测试用例才能达到比较全面的测试呢？对于实际的工程而言，“比较全面的测试”就是一个模糊的定义，用例的选择带有一定的主观和随意性。在这方面，代码覆盖率可以提供更为客观和量化的度量手段。基本的假设是：在大多数情况下，代码覆盖率的高低与测试的覆盖程度成正比，代码覆盖率高的情况下缺陷，特别是回归缺陷（Regression Bug），发生的概率更低。所以，如果能够将代码覆盖率作为持续集成中代码签入的约束条件之一，就能够更客观的保证签入代码确实经过比较全面的测试。

　　例如，你的应用程序可能有多个模块组成：商务逻辑模块、数据访问模块和界面模块等。根据重要性级别的不同，可以为模块设置不同级别的代码覆盖率约束条件。比如说，商务逻辑模块>75%， 数据访问模块>60%， 界面模块>30%。由于有了这些约束条件的存在，可以保证任何代码的签入都需要是经过比较全面测试的，否则它签入不到代码库中。有了代码覆盖率约束在此处“把门儿“，可以带来以下的好处：

　　1）测试团队可以更准确、及时的把握和调整测试的重点。比如：针对regression bug频发的模块，可以适当提高代码覆盖率约束条件的比例。

　　2）促使开发人员更积极地编写单元测试用例，特别是在对产品代码有比较大的改动时。

　　3）促使开发人员和测试更积极的互动， 包括：及时通报重大产品变化、交流测试重点、协调单元测试、功能测试等合理覆盖比例。

　　上述的内容也仅是本人的想法，俗话说得好：“光说不练假把式，光练不说傻把式，又练又说真把式。”说了这么多想法，有什么ALM（Application Lifecycle Management，应用生命周期）工具实现了上面所提到的代码覆盖约束了吗？本人也只是对微软ALM工具Team Foundation Server （简称 TFS）比较了解，但对其它的ALM工具了解的比较少。TFS的最新的版本TFS 2010及其早先的版本中是没有代码覆盖约束。不过也不用着急，由于TFS 2010的Team Build功能采用Workflow Foundation（WF）技术，所以对它的定制和二次开发就更为容易。

　　我花了点时间尝试着实现了一个名为CodeCoverageChecker WF activity，用它扩充了TFS 2010自带的DefaultTemplate.xaml过程模板，实现了支持的代码覆盖约束的新模板- CodeCoverageCheckTemplate.xaml。 如下图所示，在CodeCoverageCheckTemplate.xaml模板中，CodeCoverageChecker被放置在编译并执行完测试工作之后。

　　有了这个过程模板，就可以定义TFS Build Definition，并在其中加入针对代码签入到代码库所需要的代码覆盖率约束条件，这些条件可以是针对模块一级的（如：.exe 、.dll），也可以是针对类型（如：class、struct等），甚至还可以是函数或者方法。例如：下面是基于CodeCoverageCheckTemplate.xaml的Build Definition，在其中我定义各种覆盖约束规则。