实验简介

测试覆盖率是软件测试过程中非常重要的一套评价标准，通常包括代码覆盖率和用例覆盖率等指标。覆盖率可以很好地反应测试的执行情况，遗漏情况，帮助研发团队制定更好的测试策略，使软件测试的效果变得更加可视化。

Ecl-Emma是Emma在Eclipse中的一个插件，专门用于统计Java代码的测试覆盖率。

实验目的

(1) 掌握代码级测试覆盖率工具Ecl-Emma的使用。

(2) 理解覆盖率这一重要指标对测试的指导价值。

(3) 理解软件工程是覆盖率的各种维度，如代码级，需求级，用例级等。

实验流程

1. 安装Ecl-Emma

(1) 方法一：离线安装

先进入官网下载：http://www.eclemma.org/download.html，截止写作本书时，最新的版本是2.3.2。下载完成后解压缩到Eclipse安装目录下的dropins目录即可，目录结构如下：

重新启动Eclipse，在工具栏出现图标即表明EclEmma可以正常工作。如果此种方法无法成功安装，我们也可以使用第二种方式进行在线安装。事实上，所有的Eclipse的插件通常的安装方式都是这两种。

(2) 方法二：在线安装

在Eclipse中选择菜单“Help->Install New Software”，在打开的对话框中输入Ecl-Emma的在线安装地址：http://update.eclemma.org/，等待一会儿后选择相应的版本，点击“Next”按钮即可开始安装，根据网络速度不同，安装过程需要等待几分钟。

2. 执行覆盖率统计

安装完成后，重启Eclipse即可。我们打开包“com.woniuxy.test”下面的“MainTest”类，点击Ecl-Emma的运行按钮或者在类文件上右键选择“Coverage As”的方式运行该测试程序，运行完成后我们可以看到Ecl-Emma统计的代码覆盖率，如图：

3. 覆盖率的用途

(1) 通过使用Ecl-Emma的插件来运行我们的测试驱动程序，我们可以快速地统计出来本次测试的执行，哪些代码行被运行了，哪些代码行没有被运行。如果没有被运行的代码，则证明我们的测试用例并没有覆盖到此类情况，那么我们就应该扩展其测试用例，进而将被测代码完全覆盖。

(2) 通过覆盖率完善测试用例，并且设计高效的测试用例，而不是冗余的，毫无价值的测试用例。大家可以通过对splitString和isNumber两个方法进行测试，来验证这一点。

4. 生成覆盖率报告

(1) 每一次执行测试用例时，我们都可以直接通过Eclipse来观察其覆盖率。但是这都是一次性的观察，我们应该将每一次的覆盖率报告都保存起来，并且和对应的被测试版本进行关联，这样我们就可以看到更加完整的，不同版本进行迭代时，相关的代码级测试情况。通过这种方式，可以更加全面地了解历史变更情况和测试结果，有问题时也便于回溯跟踪。

(2) 在Ecl-Emma中，生成测试报告非常简单，只需要打开“Coverage”视图，在覆盖率统计数据表格任意位置点击“右键”->“Export Session”即可，如图。

(3) 接下来在“Export”对话框中，选择“Java”类别下面的“CoverageReport”即可。

(4) 点击下一步，选择最后一次的覆盖率执行编号，选择HTML格式或CSV格式的报告，浏览到一个保存位置即可。当然，大家也可以根据自己的需要，选择不同执行格式。甚至通过一些手段对该报告进行自动分析处理归档，都可以。

5. 关于覆盖率的思考

通过对Ecl-Emma这一代码级覆盖率工具的使用，相信大家对于测试用例设计方法有了更进一步的认识，特别是之前更多从事的是偏黑盒测试的朋友，对于各类测试用例设计方法和来由会深有感触。当然，这也是笔者希望大家通过阅读本书，能够达到的目的。事实上，针对不同的编程语言，都有代码覆盖率工具可以使用，当然，很多商业级的代码级测试工具（也称白盒测试工具），都可以做到这一点。这不是我们这一节需要来讨论的问题，本节内容笔者想带大家一起，通过对覆盖率的使用，进而引发的关于软件测试和软件质量的思考。

首先，覆盖率只所以有价值，是因为它可以更加可视化的为我们展现我们在测试层面的效果。之所以很多时候我们会有一种感觉，就是针对一个软件产品的测试好像永远没有头，甚至测试工程师有时候像一只无头苍蝇一样，不知道到底测试应该到什么程度才算是可以了。特别是针对比较繁琐的回归测试，难道我们为了一个BUG的修改，要把所有可能的功能都拿来测试一遍？不测试吧，又担心万一出现问题怎么办？相信很多组织，很多团队，都会有这方面的困惑，笔者在测试一线十几年的经验也同样逃不开这些问题。所以，如果有一种方法，能够非常清楚的告诉我，我们的测试工作完成到什么程度了，有没有尽可能多，尽可能好的完成呢？代码覆盖率虽然只是针对代码进行的功能性测试，但是给我们这方面的思考，是非常有价值的，这个价值就在于，如何更加可视化地评估测试的作用，建立质量信心。

当然，代码覆盖率自然有其局限。但是我们可以沿着这条线，继续往下深究，除了代码行和条件覆盖情况，我们当然也可以设计方法（或函数）覆盖率，类或者模块的覆盖率，从更高一个层面来统计每一次测试的执行情况。比如在Ecl-Emma中，我们可以看到，基于上一节的测试驱动情况，发现方法inputString()从来没有被调用过，所以这个方法的测试遗漏了，我们必须测试它，至于是利用手工测试完成还是通过Expect等脚本进行自动化的交互式输入来进行测试，本身并不是问题的关键。那么，同样的，我们可以继续往下考虑，各个类的覆盖情况，各个模块的覆盖情况，各个需求的覆盖情况，甚至大到各个测试类型（如功能性测试，性能测试，兼容性测试，可靠性测试等），以及各个用户场景的覆盖情况。

其次，在软件测试领域，一直流传着一个理论：缺陷放大模型，该理论指出在越早期发现程序的问题，其解决成本越低。假设在单元测试阶段，发现一个BUG的修复成本为1个单位，那么在集成测试阶段则会消耗10个单位的成本，在系统测试阶段该成本会放大到100，如果该BUG被客户发现，其修复成本更会达到夸张的1000个单位。所以，从这一角度来看，代码级测试工作的价值的确非常大。其实道理也非常简单，我们如果进行代码级测试发现了问题，我们可以很容易地定位问题在哪里，因为我调用的哪个接口，哪段代码块出了问题，是一目了然的。而到了系统测试阶段，或者在受控的客户现场出问题，我们可能连定位问题都很难，更别说修复它了。

最后，笔者想给大家谈谈一个非常重要，但是可能不太被提到的指标：DRE，缺陷清除有效性，英文全称为：Defect Removal Efficiency。是用于评估某研发阶段发现和修复的缺陷数量是否合理的一个重要指标。关于DRE的细节算法大家都可以在网络上查到很多资料，笔者主要来讲一讲更加宏观层面的DRE，我们定义其公式为：

通过上述公式，我们可以很容易地评估，产品在研发阶段的测试效果和测试工作质量。DRE比例当然是越高越好，说明研发阶段发现的BUG更多，而这样，客户发现的BUG就会更少，这当然是质量好的一种表现。

关于DRE这个指标，其实也从另外一个侧面告诉我们，也不必过分追求覆盖率，即使覆盖率做到100%，也不可能保证没有BUG。而更多地应该追求产品的外在质量表现，即有可能我们的产品还有很多BUG没有被测试出来，只要我们的使用场景足够丰富，能够覆盖绝大部分用户的日常使用情况，那么客户在真正使用该产品时，也不容易能够遇到问题。潜在的BUG每个软件产品都有，但是只要99%的客户没有使用到一些特别的场景进而触发到该BUG，那么这就是质量好的一种表现。所以DRE这个指标，相比于覆盖率之类的评估指标，更加接地气，也更具有可行性。

当然，以DRE来驱动我们的质量工作，必然容易变成一些测试团队的借口。觉得只要客户没发现，就不用管，这种对待产品质量的态度当然是不可取的。任何一类产品，把质量从50%提高到90%是容易的，而从99%提高到100%，这几乎是不可能的，除了单纯成本很高以外，即使不计成本，也几乎不能够实现。所以，针对绝大多数软件产品来说，根据笔者的经验，DRE能够高于90%就是非常不错的表现了。当然，我们也可以借鉴现在大多数互联网公司的玩儿法，把客户，变成最大的测试团队。只要客户一反馈问题，立即响应，立即修复，立即发布新版本。我们的产品质量不行，但是我们响应积极，反而比起从1.0版本开始，就要做出一个完美的产品来说，更加能够获得用户的理解与认可。

为了答谢大家对蜗牛学院的支持，蜗牛学院将会定期对大家免费发放干货，敬请关注蜗牛学院的官方微信。