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

解决这个问题的其中一个方法，就是对关键部分的代码进行代码覆盖率的统计。平时我做单元测试和接口测试的时候，得益于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程序的解决方法了，呵呵。

No related posts.

由于ASP.NET程序运行在一个硕大的框架上，所以一般用Sample模式收集到的数据，对发现性能问题帮助不大，以下是一个用Sample模式收集的结果：

从这个报告中我们可以看到，前5个工作量最大的函数和执行单独工作最多的函数都是系统函数。

下面看一下有针对性地用检测模式收集的数据：

本文就采用“检测”模式收集性能数据来进行分析和处理。

首先，把本次测试的目标DLL用VSInstr工具进行处理，使得Profiler能够收集相关的性能数据，这一个步骤非常关键，通常来说不需要设置额外的参数，就是默认的方式就可以了，例如：VSInstr “D:\Websites\xxxx\bin\xxxx.dll”，在处理的过程中可能会提示一些错误，具体错误的信息可以在这里查找。把相应的DLL处理完毕以后，就在命令行输入以下指令（命令行的指令用斜体加下划线表示；说明文字加黑）

停止IIS

iisreset /stop

设置分析.NET应用程序所需要的环境变量，在运行完这个命令以后需要重启。由于使用检测方式进行数据采集，所以这里我用globaltraceon参数。

VSPerfClrEnv /globaltraceon

启动性能数据收集。/start:trace，告诉收集器要收集检测数据；/user:”NETWORK SERVICE” ，由于是要对IIS进行的数据进行采集，所以需要制定用户NETWORK SERVICE；/CS，启用跨进程分析，看了一些文章说是分析ASP.NET程序一般都把这个选项打开，原因不详；/output:”d:\magus\0422.vsp”，指定输出文件的路径和名称；/wincounter:”\Processor(_Total)\% Processor Time”，收集处理器的参数，这里需要注意的是，wincouter后面的性能计数器名字一定要是全名，有一个方法可以查询系统的性能计数器的全称，就是用VSTS的Server Explorer，然后找到相应的服务器(一般是本机)，下面有一个“Performance Counters”；如果要收集多个性能计数器的数据，只需要多加几个 /wincounter 参数即可，例如我在收集处理器时间的同时，还想知道Context Switcher每秒的数据。

VSPerfCmd /start:trace /user:”NETWORK SERVICE” /CS /output:”d:\magus\0422.vsp” /wincounter:”\Processor(_Total)\% Processor Time” /wincounter:”\System\Context Switches/sec”

在IIS起来之前先停止性能数据的收集

VSPerfCmd /globaloff

启动IIS

iisreset /start

对程序进行预热，这一步也是很关键，因为IIS启动以后，程序需要预热才能达到稳定的状态，因为程序首次被访问的时候有些代码会被编译，所以为了降低对性能测试的影响，应该现对被测的程序进行预热。在预热完毕以后重新启动性能数据的收集。

VSPerfCmd /globalon

– 运行性能测试场景 –

测试运行完毕以后，停止性能数据的收集

VSPerfCmd /globaloff

停掉IIS

iisreset /stop

关闭性能数据收集器，这一步完成以后就能生成包含数据的文件了

VSPerfCmd /shutdown

首先来看看收集到的报告

在这个方法里面有一段不知名方法（其实是因为没有相应的Symbol，⊙﹏⊙b汗）占用了大量的计算时间，然后就找到相应的代码，原来该不知名方法是一个动态生成的代码，该段代码大概就是会创建一个新的Client对象，然后向另外一台服务器发起一个请求。其实不用每次调用该方法都创建一个新的Client对象。然后我尝试着把这个Client改为静态变量，经过优化以后的报告对比如下：

效果还是挺明显的，但是当我重新测试一下性能的时候，被打击了一下，改动前后的性能对比相差很小，小的都可以认为是误差：P，因为在一个颇为庞大的项目中，这点小小的改动的确不可能影响大局。不过这次试验让我学会了用Profiler来找到ASP.NET运行中执行较慢的语句，并且看看这些语句有什么问题（可能是一个调用存储过程的方法很慢，而真正的原因是数据库有问题），定位问题所在，然后解决问题，最后回测一下对比改动前后的结果。看是否达到预期的优化效果。

No related posts.

在VSTS的Profiler中，有两种(VSTS2010好像有5种了)Profiling的方法，第一种是采样(Sampling)，第二种是检测(Instrumentation)。对于采样模式，它的工作原理是Profiler定期中断CPU并且收集函数的调用堆栈信息。在网上找到一个图，对于采样工作方式的描述非常清晰：

对于检测模式，他的工作原理是用VSInstr程序在原始的代码中插入一些用于计算时间的代码，例如A函数调用B函数，那么在调用B函数的前后都会被插入用于计算时间的代码，具体可以看下图：

下面我自己写了一个小的Sample类，然后把编译好的代码用Reflector来查看，很容易地就能看出区别。第一个图是没有经过VSInstr处理的原始代码：

下图就是经过VSInstr处理后，反编译后的代码：

可以看到VSInstr程序修改了原来的DLL。在检测模式下，只有经过修改后的DLL才能收集到数据。

在VSTS中，一般可以通过Analyze菜单下的Launch Performance Wizard来新建一个性能会话，然后进行性能数据的采集。

对于ASP.NET程序，可以通过以下步骤来进行“采样”

iisreset /stop
VSPerfClrEnv /globalsampleon
VSPerfCmd /start:sample /user:”NETWORK SERVICE” /output:”d:\somewhere\xxxx.vsp”
VSPerfCmd /globaloff
iisreset /start
VSPerfCmd /attach:xxxx
VSPerfCmd /globalon

–run the test scenario–

VSPerfCmd /globaloff
VSPerfCmd /detach
iisreset /stop
VSPerfCmd /shutdown

1. 第一步是停掉IIS
2. 然后通过VSPerfClrEnv对环境变量进行设置，具体可以查文档，做完这一步以后通常需要重启一下电脑
3. 第三步就是通过VSPerfCmd启动性能数据收集
4. 接下来的VSPerfCmd /globaloff就是暂停性能数据的收集
5. 然后重启IIS，并且访问一下这个服务器上的页面，使得W3WP进程启动
6. 查看W3WP.EXE的进程ID，然后通过VSPerfCmd /attach:xxxx把Profiler attach到IIS中
7. 通过VSPerfCmd /globalon重新让Profiler进行性能数据的采集
8. 然后就可以运行性能测试的场景
9. 运行测试完毕以后就用VSPerfCmd /globaloff停止性能数据的采集
10. 接着用VSPerfCmd /detach让Profiler不要附着在IIS上
11. 停掉IIS — iisreset /stop
12. 执行VSPerfCmd /shutdown，这一步执行完毕以后，在d:\somewhere\下就有一个xxxx.vsp的性能报告。

对于ASP.NET程序，可以通过以下步骤来进行“检测”

检测和采样其实是大同小异的，但是有一个关键的步骤就是在进行检测之前，一定要记得用VSInstr命令对需要进行检测的DLL或者EXE文件进行处理，建议一次不要检测太多文件，检测时间不要太长，因为检测所产生的数量是非常大的，产生的文件大小都是按G级别计算了。

iisreset /stop
VSPerfClrEnv /globaltraceon
VSPerfCmd /start:trace /user:”NETWORK SERVICE” /CS /output:”d:\xxx\0422.vsp”
VSPerfCmd /globaloff
iisreset /start
– 预热 –
VSPerfCmd /globalon

–run code–

VSPerfCmd /globaloff
iisreset /stop
VSPerfCmd /shutdown

重复一次，在做以上的步骤之前必须要用VSInstr对目标二进制文件进行处理。这里详细步骤就不做解释了，命令的主要区别就是在做检测的时候，就免去了Attach到IIS这个步骤了。

采样和检测，前者是宏观的性能数据采集，后者是微观的性能数据采集。对于CPU负载较高的程序，用采样会得到比较好的效果；但是如果程序运行过程中并没有消耗很多的CPU资源，那么用采样可能就不能收集到太多有用的信息。所以在不同的场景下需要应用不同的性能数据收集方法。

No related posts.