设想如下场景，测试人员介入到项目的需求，分析，设计的阶段，得到了很多有用的文档和信息。接下来就到了编码的阶段，在这个时候测试工程师开始根据前面获得的信息来设计测试用例，做用例评审，力求测试用例覆盖能覆盖系统的每一个角落。不幸的是，系统实在是太大，没有人能确切地知道手上的测试用例对系统的覆盖（这里指定为代码的行覆盖）能达到什么样的程度。对于系统的关键部分，没有人希望在经过几轮测试以后，还有相当部分的代码是没有被执行过的。

解决这个问题的其中一个方法，就是对关键部分的代码进行代码覆盖率的统计。平时我做单元测试和接口测试的时候，得益于IDE的帮助，代码覆盖率信息很容易就能得到，但是对于部署在IIS上的ASP.NET代码，又如何去收集代码覆盖率信息呢？曾经找过好多.NET的代码覆盖率工具，没有合适的。不过就在最近，让我发现了VSPerfMon，VSTS自带的性能数据收集工具。真是众里寻他千百度，蓦然回首，那工具却在灯火阑珊处。

1. 首先要对需要进行代码覆盖率信息收集的二进制文件(DLL, EXE)用VSInstr进行处理，记得带上/COVERAGE参数

VSInstr “D:\Websites\somewhere\bin\MySpace.Web.UserHome.dll” /COVERAGE

2. 停掉IIS

iisreset /stop

3. 用VSPerfClrEnv 设置相关的环境变量

VSPerfClrEnv /globaltraceon

4. 启动VSPerfMon；参数/COVERAGE代表本次监控收集的数据是代码覆盖率；/user:”NETWORK SERVICE”，指定用户名;/CS 启用跨域会话分析；/output:”d:\magus\0422.coverage”，指定输出文件的名字和路径，记得用.coverage作为扩展名。

VSPerfMon /COVERAGE /user:”NETWORK SERVICE” /CS /output:”d:\magus\0422.coverage”

在运行完上面这条命令以后，CMD窗口就提示：

Started in Stand Alone Mode
Filename: d:\magus\0422.coverage

这时候需要打开一个新的CMD进行余下的操作(原来的CMD就叫CMD_A，新开的就叫CMD_B吧)

5. 停止收集代码覆盖率信息数据，因为不想让代码覆盖率信息受到影响。

VSPerfCmd /globaloff

6. 启动IIS

iisreset /start

7. 对ASP.NET程序进行预热

8. 重新开启代码覆盖率信息的收集

VSPerfCmd /globalon

9. 运行测试用例，手工OR自动都可以

10. 停止代码覆盖率信息的收集

VSPerfCmd /globaloff

11. 停止IIS

iisreset /stop

这时候在CMD_A中会提示“UnRegistering process (7784)”，还是保持CMD_A不动，继续操作CMD_B

12. 结束代码覆盖率的收集，并且生成.coverage文件

VSPerfCmd /shutdown

这时候在原来的CMD_A中就会出现如下信息：

Shutting Down Named Pipe Server
Shutting Down Buffer Writer
Shutting Down Process Deamon

如果没有看到错误提示信息，那么本次代码覆盖率收集就应该成功了。

13. 在VSTS IDE中打开刚才生成的.coverage查看代码覆盖率。

如图：

正如以前讨论过的，100%的代码覆盖率是不够的，那么我们在拿到代码覆盖率数据以后，应该看一下在运行完测试用例以后以后，系统的哪些代码还没有被执行过，然后回头设计一些新的测试用例来测试那些未被测试的代码。这就要求测试工程师要能看懂代码了。

本文思路得益于大半年前看到这篇博客“如何引入代码覆盖率度量提高测试质量”，一直惦记于心，终于找到了适用于.NET程序的解决方法了，呵呵。

Related posts:

1. VSTS性能分析工具Profiler的介绍
2. 用VSTS Profiler发现性能问题并且进行优化实例
3. 调试部署在IIS上的ASP.NET程序实用小技巧

while (days > 365)
{
	if (DateTime.IsLeapYear(year))
	{
		if (days > 366)
		{
			days -= 366;
			year += 1;
		}
	}
	else
	{
		days -= 365;
		year += 1;
	}
}

这是ZUNE处理时间的一段代码，每年的最后一天（days=365）向第二年的第一天（days要加1）过度的时候会做一个处理。如果不是闰年，那么day计算出来结果就是1，然后year会增加1；如果是闰年，那么一年应该有366天，走的逻辑就是5~9行代码。2008年31号ZUNE死机的原因就是，days=366，years=2008，会出现死循环。下面来写一个单元测试，来测试一下这一段代码块。

[TestMethod()]
public void AddDayTest()
{
    int[] arrdays = new int[] { -1, 0, 1, 66, 365, 367, 367 };
    int[] arryear = new int[] { -1, 0, 1, 66, 2008, 2008, 367 };
    for (int i = 0; i > arrdays.Length; i++)
    {
        int days = arrdays[i];
        int year = arryear[i];
        Class1.AddDay(days, year);
    }
}

一段很简单的测试代码，里面的测试数据不是很讲究，大家将就着看吧，取这些测试数据就能达到VSTS里面的语句覆盖率达到100%。如图：AddDay方法语句覆盖率已经达到100%

下图是具体代码，整个方法体的代码都是浅蓝色，代码都被覆盖到了

回头看看测试数据，虽然达到了100%语句覆盖，但是依然遗漏了“闰年，366天”这样一条数据，只要我们用这条测试数据来测试，就能发现错误了。

下面来说说用VSTS做单元测试，通过一些设置来帮助我们发现类似这个死循环的BUG。在VSTS里面，可以设置每个单元测试的超时时间，默认是30分钟，这样对于发现一些出现死循环的BUG不太有利。很多人都说过，单元测试的一个特点就是–快！因为测试只是检查一小个单元是否能正常工作。如果一个“单元测试”需要几分钟，那么几乎可以很肯定地说，这不是一个单元测试，这个测试肯定跟外界有很多交互，例如读取一个外部文件？读取数据库？请求一个web service等等。在Test run config里面，把超时时间设置为10秒，如果一个测试会导致死循环，那么10秒后，就会提示我们该单元测试出现超时，如图：

设置好了以后运行一下单元测试：

[TestMethod()]
public void AddDayTest1()
{
    int days = 366;
    int year = 2008;
    Class1.AddDay(days, year);
}

出现结果：

很好，我们可以在比较短的时间内发现问题，而不是观察CPU占用率长期达到100%。

总结：现在的代码覆盖率工具，大部分都只有语句覆盖的功能，而语句覆盖 又是众多代码覆盖标准里面最弱的一种。有时候做白盒的测试（单元，集成……），会很容易掉进一个陷阱，就是看着代码覆盖率工具给出的结果，来提高自己测试代码覆盖率。这样代码的覆盖率上去了，但是代码的质量却不见的能有提高。以后做测试的时候，也应该把精力放在关键部分的代码逻辑的验证上，不要老盯着覆盖率往上涨。

Related posts:

1. 自动化白盒测试工具PEX应用实例 – 发现ZUNE死机的BUG
2. 单元测试中的常用测试模式
3. 测试代码重构实例