简单几步分析测试覆盖率

作者: 丑小丫大笨蛋 | 来源:发表于2016-08-13 23:30 被阅读0次

简单几步分析测试覆盖率
测试覆盖率
golang覆盖测试检测
03_测试覆盖率
SRS单元测试、覆盖率和自动回归怎么做
15使用 Go 进行单元测试
jacoco测试覆盖率
当谈论覆盖率时我们在谈什么？
jacoco-java测试覆盖率工具
代码覆盖度之jacoco

太久没有更新博客了，当初承诺的周更快变成月更了，(⊙﹏⊙)b

上次介绍了单元测试的重要性和如何开始写单元测试，今天再推荐给大家一种分析测试覆盖率的工具NUnit。本文测试环境为windows 10 + Visual Studio 2013。

1. 安装NUnit Test Adapter

你可以选择从NUnit官网下载NUnit Test Adapter，或者直接在VS的Tools -> Extensions and Updates里面搜索并安装NUnit3 Test Adapter。

在VS2013中安装NUnit3 Test Adapter

2. 载入需要做测试覆盖率的工程及其对应的测试工程

我们这里使用上次介绍单元测试中介绍的一个关于栈的例子（详细代码请参见单元测试）。

把我们要分析的工程加载进来之后，我们可以先在TestExplorer (Test->Windows->Explorer)窗口选择运行一些test或者所有的test，以保证所有的test都能正常运行。

在TestExplorer中执行所有的单元测试

3. 分析工程的测试覆盖率

下面就可以直接利用Test选项里的Analysis Code Coverage 来分析我们上面载入的工程的测试覆盖率了。依次选择Test->Analysis Code Coverage->All Tests之后，几秒钟就能得到分析结果。

测试覆盖率分析结果

这里覆盖率的计算有两种方法lines或者blocks，其中lines很好理解就是按行来计算的，而blocks则是指代码块，跟代码的逻辑有一定的关系，但至于具体是如何划分的，我并不清楚。上图中我们可以看到，单元测试那篇文章里我们写的测试能够在lines和blocks两个方面都100%覆盖MyStack类的所有逻辑。

4. 查看没有覆盖的代码

测试覆盖率分析结果其实不只是一个简单的列表，除了上图中我们看到的每个工程的覆盖率和每个函数的覆盖率之外，我们还可以看到每一行代码的覆盖情况。将鼠标放到上图中第二行的右二图标（删除图标的左侧）上，它会显示“Show Code Coverage Coloring”。这个时候再点击列表中的每一行，代码编辑器就会跟着调到相应的源代码文件或者函数的位置。如下图所示，所有代码都被标示为蓝色，表示我们的测试覆盖了这部分代码。

测试覆盖的代码被标记为蓝色

如果某些行的代码没有被测试覆盖到，则会被标示为红色。若某行只有一部分被覆盖，则会被标示为黄色。上面的测试覆盖率结果列表里显示MyStackTest工程的覆盖率并不是100%，我们点开Test_ThrowException_PopFromEmptyStack()那一行，可以看到
第83和91行被标记成了红色。
我们再来细看这部分代码的逻辑，在第82行调用pop()函数的时候，空栈会抛出异常，这个异常被该方法上面的ExpectedException特性验证，所以不会正常的结束该方法，即执行第83行。第91行也是一样。

没有被覆盖的代码被标记为红色

上面的红色一行可能不是很明显，这里又稍微修改了一下那个测试函数，再分析的结果就如下图所示。

没有被覆盖的代码被标记为红色

写在最后

NUnit Test Adapter是一款安装和使用都非常方便使用的软件，简单几个步骤就可以分析我们的工程的测试覆盖率。较高的测试覆盖率也可以作为一个工程较强的鲁棒性的一个证据，但是，千万不要过分追求测试覆盖率。首先，测试本身的测试覆盖率是不应该考虑的，上面我们举例只是为了展示没有被覆盖的代码的颜色。其次，有些不重要的逻辑是可以不被单元测试覆盖的，不要一味地为了写测试而写测试。比如结构化异常处理，我们可能除了catch预料之中的异常之外会在最外层再加上Exception来处理那些uncaught exceptions。而我们的单元测试里往往并不会覆盖这个catch块。

最后，如果你的代码中的主要逻辑里有块分支被标红了，那么就说明你的测试还不够全面。所以，测试覆盖率的分析还可以作为检验单元测试完整性的工具。