1. 创建一个新的类库项目，这个项目是一个独立的可重用的类库，所创建的Web测试插件可以在不同的包含有Web测试的项目中使用。其实可以跟上一篇文章说的WebTest Plugin公用一个类库项目

2. 在该类库项目中添加对“Microsoft.VisualStudio.QualityTools.WebTestFramework”的引用

3. 在该类库项目中创建一个从ValidationRule派生出的类

4. 重写基类的Validate方法

5. 打开包含有Web Test的项目，并且在该项目中引用刚才添加的包含有自定义验证规则的类库项目

6. 打开需要调用自定义验证规则的Web测试，点击”Add Validation Rule”，选择刚才编写好的验证规则。

现在看看在自定义验证规则中添加参数，让用户输入相应的参数，从而使得验证规则更加灵活。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class ResponseContentLength : ValidationRule
{
	public int Length { get; set; }                   //输入的长度
	public bool PassIfEqualsToContentLength { get; set; }
 
	public override void Validate(object sender, ValidationEventArgs e)
	{
		if (e.Response != null)
		{
			e.IsValid = !((e.Response.ContentLength == Length) ^ PassIfEqualsToContentLength);
		}
		if (!e.IsValid)
		{
			e.Message = string.Format("The length of the ContentLength: {0} is not equal to the expected result: {1}.", e.Response.ContentLength, Length);
		}
	}
}

如果我们添加该自定义规则，那么会提示我们输入两个参数，一个是Length，另一个是一个布尔值；如果Response中的ContentLength和设置的Length相等，并且该布尔值设置为True，那么这个验证规则就算是通过。如图：

Related posts:

1. 在VSTS中创建Web Test的插件
2. Linq to Object在测试中的应用
3. 实现数据驱动的CodedUI Test

使用 Web 测试插件，可以隔离代码并在 Web 测试中的主要声明性语句外部重用代码。自定义的 Web 测试插件为在运行 Web 测试时调用某些代码提供了途径。在每个测试迭代中，Web 测试插件都要运行一次。此外，如果重写测试插件中的 PreRequest 或 PostRequest 方法，这些请求插件将分别在每个请求之前或之后运行。

可见Web测试插件给使用者带来了很大的灵活性，下面就看看如何创建一个Web测试插件。

1. 创建一个新的类库项目，这个项目是一个独立的可重用的类库，所创建的Web测试插件可以在不同的包含有Web测试的项目中使用。

2. 在该类库项目中添加对“Microsoft.VisualStudio.QualityTools.WebTestFramework”的引用，该Dll是在.NET选项卡上

3. 在该类库项目中从WebTestPlugin派生出一个自定义的Web测试插件类

4. 重写相关的基类方法，例如 PreRequest、 PreWebTest、 PostWebTest等

5. 打开包含有Web Test的项目，并且在该项目中引用刚才添加的包含有自定义Web测试插件的类库项目

6. 打开需要调用Web测试插件的Web测试，点击”Add Web Test Plug-in”，选择刚才编写好的Web插件，完成。

以下是一个Web测试插件的实例代码，该插件重写了PreWebTest方法，所以会在Web测试执行之前运行一次。改插件的作用就是在每次运行Web测试之前，会读取一个配置文件，然后把相关的配置写到Web测试的Context中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

public class FilterRuleWebPlugin : Microsoft.VisualStudio.TestTools.WebTesting.WebTestPlugin
{
	static readonly string key = "RuleName";
	public override void PreWebTest(object sender, PreWebTestEventArgs e)
	{
		base.PreWebTest(sender, e);
		//Add the new context
		if (!e.WebTest.Context.ContainsKey(key))
		{
			e.WebTest.Context.Add(key, string.Empty);
		}
		string filter = GetFilter();
		if (string.IsNullOrEmpty(filter))
		{
			e.WebTest.Context[key] = "default";
		}
		else
		{
			e.WebTest.Context[key] = filter;
		}
	}
 
	private string GetFilter()
	{
		string filter = string.Empty;
		XmlDocument doc = new XmlDocument();
		try
		{
			doc.Load("Config.xml");
			if (doc != null)
			{
				filter = doc.SelectSingleNode("Settings/Filter").InnerText;
			}
		}
		catch (Exception)
		{
			return "LoadFilterError";
		}
		return filter;
	}
}

我们还可以在Web测试插件中定义一些公开的属性（Property），利用公开的属性，可以在运行Web测试之前对一些参数的输入进行指定。

VSTS的Web测试用起来挺方法，功能也挺强大，如果大家在使用的过程中遇到什么不爽的事情，可以尝试自己编写Web测试插件来改变那些不爽的状态。;-)Web测试插件还有很多的应用场景，今天抛砖引玉啊。

Related posts:

1. 自己动手创建Web测试验证规则
2. 在C#单元测试中使用HttpContext的简单解决办法
3. 实现数据驱动的CodedUI Test

对于每一段录制的操作，VSTS都可以把它抽象成一个方法，它会把这些操作以静态方法的形式存放在一个叫RecordedMethods的类里面。可以对这些方法做任意的修改，我就把给需要输入的方法增加一个输入的参数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class RecordedMethods
{
	public static void FirstClick(TestContext testContext, string first)
	{
		//第一个输入
	}
 
	public static void Operation(TestContext testContext, string operater)
	{
		//操作符
	}
 
	public static void SecordClick(TestContext testContext, string second)
	{
		//第二个输入
	}
 
	public static void GetResult(TestContext testContext)
	{
		//按那个等于号
	}
}

这些方法其实是怎么工作的呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public static void Click(TestContext testContext, string first)
{
	// Click '1' button
	WinWindow 计算器Window = new WinWindow();
	#region Search Criteria
	计算器Window.SearchProperties.Add("Name", "计算器", "ClassName", "SciCalc");
	#endregion
	WinWindow item1Window = new WinWindow(计算器Window);
	#region Search Criteria
	item1Window.SearchProperties.Add("ControlId", "125");
	#endregion
	WinButton item1Button = new WinButton(item1Window);
	#region Search Criteria
	item1Button.SearchProperties.Add("Name", first);
	#endregion
	Mouse.Click(item1Button, new Point(7, 12));
}

首先是创建一个WinWindow对象，这个WinWindow类最终是继承自UITestControl类，这个类在Microsoft.VisualStudio.TestTools.UITesting.dll，是VSTS2010新引入的。程序首先找到计算器这个窗口，然后在计数器窗口上面找到输入的控件，然后在输入的控件上找到具体点击的按钮。这里我只需要对最后的一个搜索的条件进行参数化就可以了。

下面就是要准备一些数据作为输入：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

< ?xml version="1.0" encoding="utf-8" ?>
<testdatas>
  <test>
    <first>1</first>
    <operator>+</operator>
    <last>1</last>
    <expected>2</expected>
  </test>
  <test>
    <first>0</first>
    <operator>-</operator>
    <last>0</last>
    <expected>0</expected>
  </test>
  <test>
    <first>3</first>
    <operator>*</operator>
    <last>3</last>
    <expected>9</expected>
  </test>
</testdatas>

通过向该CodedUI Test添加数据源，实现简单的数据驱动。

完成后的代码如下

1
2
3
4
5
6
7
8
9
10
11

public void AddOperationTest()
{
	// From the context menu, select "Edit CodedUITest" and choose any of options to add automation code.
	RecordedMethods.Click(this.TestContext, TestContext.DataRow["First"].ToString());
	RecordedMethods.Click(this.TestContext, TestContext.DataRow["Operator"].ToString());
	RecordedMethods.Click(this.TestContext, TestContext.DataRow["Last"].ToString());
	RecordedMethods.GetResult(this.TestContext);
 
	// Validate UIItemEdit.Text AreEqual 'xxx. '
	Assert.AreEqual(TestContext.DataRow["Expected"].ToString()+". ", UIMap.UI计算器Window.UIItemWindow.UIItemEdit.Text);
}

体会：VSTS自动生成的那个RecordedMethods类，里面的方法都是可以重用的，稍加修改，就能达到比较好的效果，同时也需要对这个类的方法进行清理。例如在本文中，RecordedMethods类中总共有4个方法，其中的三个方法FirstClick，Operation，SecordClick，它们其实都是一样的，就是点击计数器上的某个按钮，所以说这3个方法可以统一为一个方法Click。

微软一直以来所提供的傻瓜式的数据驱动的支持，很好地帮助我们实现数据驱动，有利于把测试脚本的编写与测试的设计分离。这一点如果有安装了TFS以后就能体验到，CodedUI Test可以与某个测试用例关联起来，公用数据。

如果大家对CodedUI Test很感兴趣，推荐大家看这个人（Mathew Aniyan）的博客，满城尽带CodedUI Test。

Related posts:

1. 单元测试中三种准备Test Fixture的方法比较
2. 在VSTS中创建Web Test的插件
3. 单元测试中的常用测试模式

文章：

《Automated User Interface Testing with Coded UI Test》VSTT官方博客出品，Coded UI Test入门

《VSTS 2010 Load Test Feature: Saving Test Logs》如何在VS的负载测试中记录日志，帮助定位问题

《VSTS 2010 Feature: Load test virtual user activity visualization》如果在用VSTS进行性能测试进行的过程中，CPU突然有一个不寻常的峰值出现，在以前是比较难找到原因的，此文给我们介绍了VSTS 2010的最新功能virtual user activity visualization 是如何帮助测试工程师找到问题的根源

《VSTS 2010 Feature: Web Test Recorder Plugins》如何在VSTS 2010中利用Web Test Recorder Plugins来做自定义的关联

《VSTS 2010: Enabling Test Impact Analysis》文章介绍了如何使用Test Impact Analysis

《The Evolution of the UI Design of Test and Lab Manager》一篇概要介绍 Lab Manager的文章

《Quick Start Guide for Manual Testing》MSDN上一篇讲述手动测试工程师如何用Lab Manager开展工作的文章

《VS2010 Tutorial: Testing Tutorial (Step 2)》文章极其详细地讲述了如何用VSTS 2010来提交一个BUG，并且展示一系列的新功能，来说明VSTS 2010如何帮助消除开发和测试之间的隔阂，减少那些不可重现的BUG。

《Testing in the Application Lifecycle with Visual Studio 2010 Test Edition》此文详细介绍了在VSTS2010中，测试工程师在整个应用开发生命周期中如何利用VSTS来帮助开展工作

《Running automated tests in Manual Test and Lab Manager》此文介绍了在Lab Manger中如何运行各种测试的方法

《VSTS 2010 Feature: Web Test Playback Enhancements》文章介绍Web Test在UI方面的更新

《Read this Before Running a Load Test with Dev10 Beta 1》如果你的VSTS2010和2008是安装在同一台机器上，并且你又实用了VS的负载测试，那么这篇文章会告诉你如果对数据库进行设置，使得两个版本的负载测试数据能够共存互不影响

《How to enable code coverage in Visual Studio 2010 Unit tests》，由于VSTS2010对于测试运行的一些改变，所以要打开代码覆盖率的操作与VS2008有所不同，这篇文章给我们讲述了操作细节

《Coded UI Test from Microsoft Test & Lab Manager》如何在VSTS的最新的Lab Manager中运行CodedUI Test

《Coded UI Test in a Team Build》这篇文章讲述了如何把一个CodedUI Test加到TEAM BUILD里面

《The Lab Management Product – An Overview》 Lab Management产品介绍。

《Official Names for the 2010 Test Products now announced! 》介绍了VSTS2010中，3个不同版本所包含的不同功能。

《VSTS 2010 Feature: Creating excel reports for Load Test Data》，一篇介绍在VSTS2010中，如何创建一个Excel格式的性能报告的文章。

《Rename load test database name before running a long test with VSTS2010 beta1》，这篇文章告诉我们，如果VSTS2008和2010都安装在同一台机子上，那么在2010中运行负载测试的时候会更新数据库的schema，为了让VSTS2008的负载测试数据库和VS2010的共存，需要修改数据库的名字。

《How to extend Visual Studio 2010 Web- and Load-Testing with Transactional Tracing》这篇文章讲述了如何给WEB测试做扩展。图文并茂！

《Elevating the Role of the Tester with Visual Studio 2010》这篇文章详细讲述了各种各样测试工程师可以利用VSTS2010做什么样的东西，作者是VSTS测试人员版本的经理

《Dev10 Beta 1 Available!》这篇文章详细列出了VSTS2010 BETA1中，有关测试部分的更新。

视频：

Automated User Interface (UI) Testing with Microsoft Visual Studio Team System 2010。一个微软的人介绍CodedUI Test，还有Test Impact，17分钟。

An Introduction to Manual Testing。

博客：

Amit Chatterjee’s Blog，VSTS的一个产品经理，这里经常会有关于VSTS测试部分的更新介绍

Ed Glas’s blog on VSTS load testing，也是VSTS的一个经理，他的博客主要关注Load Test和Web Test

Mathew Aniyan’s Blog，来路不明，Coded UI Test之霸！

VSTS Lab Management team blog，Lab Management官方博客

VS Team System Test，VSTT官方博客

Related posts:

1. 图解微软性能测试工具VSTS2008 Load Test Agent安装
2. VSTS2010的一个新功能–CodedUI Test简介
3. 《Software Testing》（软件测试）读书笔记系列 – 第十六章

如果你对VSTS的测试员版本感兴趣，而又没有TFS2010，只装了VSTS2010 BETA 1，那么就只能体验一下VSTS2010的一个新功能–CodedUI Test。微软在VSTS2010以前的版本都不太重视手工测试和功能测试的支持，估计是因为Visual Studio本来是一个集成开发环境的原因吧，不过到了2010，情况完全不一样了，微软想把VS改造成为一个贯穿整个ALM（Application lifecycle management）的主要工具，所以在VSTS2010中加强了对测试计划，测试用例，相关报告等的支持，CodedUI Test就是面向功能测试工程师，给他们提供自动化测试支持的这么一个新功能。

下面我一步步演示一下怎么用CodedUI Test来对WINDOWS自带的计数器实现简单的自动化功能测试。

1. 新建一个测试项目，这个步骤与前几个版本的VS一样，就不重复累赘了。

2. 在该测试项目中新建一个CodedUI Test，如图所示

3. 当CodedUI Test被创建以后，VS会提示用户，是否立刻创建相关的自动化测试代码，如图所示：

这里会看到3个选项

1. Use an action recording associated with a test case or shared steps，这个选项是建立在有TFS的情况下才能实现的，因为在2010中，测试工程师可以编写测试用例，并且保存在TFS中，当有人要用CodedUI Test来实现某个测试用例的时候，就可以通过这个选项来把自动化测试和测试用例关联起来，不过可惜我没有TFS……
2. Use the recorder，这个选项比较常用，就是启动一个VSTS自带的录制工具来实现自动化测试，这个也是下面要详细分享的。
3. User the UI control Locator，这个选择会直接用VS的UI Control Locator来对被测程序的控件进行识别。本文不会详细描述。

4. 选择User the recorder，然后就会弹出一个录制的窗口，如图：

点击那个“Record Actions”就能开始录制了。VS的录制器做的挺人性化的，如果焦点不在录制器上，那么录制器就会变成透明，方便用户对被测软件的关注，下面是两个比较的图片。

选中录制器

没有选中录制器，而且在被测软件的标题栏中还有一个状态提示，表面现在录制器在工作。

5. 开始执行测试用例，录制器会记录下所有的步骤，如图：

我是在计算器上进行了1+1的操作。录制器记录下了所有操作（大家可以看到是Click ’1′ button, Click ‘+’ button等操作），现在把这3个操作合并成为一个方法，填入方法名，然后点击“Generate Method”，测试方法就被生成了，回到刚才的Record Actions的TAB，我们可以看到所有已经被录制的操作，如图：

这里每一个操作，到最后对应的都是一个方法，也意味着这些操作都是可以被重用的，所以每一个Action的颗粒度大家可以自己把握，个人认为不应该做太大颗粒度的Action，首先不利于重用，其次也不利于维护。

6. 增加检查点，对于一个自动化测试来说，自动化执行和自动化检查都是必不可少的。

现在把标签从Record Actions切换到 Add Assertions中，选中“UI Control Map”下方那个唯一可用的按钮，系统会弹出一个新的窗口，如图：

拖动右上角的那个十字按钮到某个控件上，这里可以把这个十字拖动到计算器的结果栏中。这时候VS识别出这是可以Edit控件，我也确定这个就是我想要对之进行验证的地方。点击ADD

选择了正确的控件，还需要对正确的属性进行比较。第一步是显示该控件的所有属性

如图：

图中，上面的部分是公共的属性，例如类名，名称，是否激活等；下面的部分是该控件特有的属性，例如它的文字属性（Text），是否是只读的等等。我现在只需要比较Text属性是等于2.的就可以了。因为很简单，1+1=2. 完成这一步以后就能看到一个控件被添加到了UI Control Map中，里面已经记录了那些属性需要进行比较。

7. 回放检查，浏览到刚才生成的测试，然后点进运行，我们就会看到VSTS在重复我们刚才的操作，并且对结果进行了比较，测试执行完毕。

至此，我们已经完成了一个简单的CodedUI Test。微软的VSTS2010提供了与其他类似的自动化功能测试软件的录制回放功能，但是与常见的功能测试自动化工具（例如QTP，微软的RFT）比较而言，VSTS2010所提供的Recordor使用起来并不是十分方便，感觉操作起来都不如其他测试工具用起来方便。不过有一点是非常值得肯定的，就是微软没有大肆宣扬他的工具能够实现录制回放功能，而解除过自动化测试的朋友都知道，用录制回放来实现自动化测试是相当地危险的，而且成功的机会也很小。这可能就是微软把VSTS2010提供的功能测试自动化的功能命名为CodedUI Test的原因吧。首先这是一种测试，其次，它还是一种针对UI的测试，而其实现是代码。这个对于以后修改和维护测试来说，是比较方便的。

由于没有TFS，所以没有能把自动化测试和测试用例联系起来，我个人觉得，如果单独使用CodedUI Test的话，实现自动化测试真的比较费劲（可能由于BETA,加上我在虚拟机上安装，奇慢无比），而且看不出来VSTS2010比其他商业软件或者开源解决方案有什么优势。不过我感觉如果能把CodedUI Test与测试用例管理结合起来，然后再利Lab Manager上的一些功能，一定会有不错的效果。不过Lab Manager这个东西太大太重，在中小公司估计是比较难推广的。

VSTS版本不断升级，慢慢地从一个纯粹的集成开发环境，过度到贯穿整个应用程序开发生命周期管理的平台了。

Related posts:

1. VSTS 2010 Test Edition文章收集
2. 《Software Testing》（软件测试）读书笔记系列 – 第十六章

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

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

由于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运行中执行较慢的语句，并且看看这些语句有什么问题（可能是一个调用存储过程的方法很慢，而真正的原因是数据库有问题），定位问题所在，然后解决问题，最后回测一下对比改动前后的结果。看是否达到预期的优化效果。

Related posts:

1. VSTS性能分析工具Profiler的介绍
2. 用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息
3. Linux下的snmpd.conf配置说明

在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资源，那么用采样可能就不能收集到太多有用的信息。所以在不同的场景下需要应用不同的性能数据收集方法。

Related posts:

1. 用VSTS Profiler发现性能问题并且进行优化实例
2. 用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息
3. VSTS 2010 Test Edition文章收集

这本指南有别于MSDN文档，这个PDF更加注重实用，主要是总结了在使用VSTT的过程中出现的问题，以及解决这些问题的方法，推荐用MSTEST的同行都下一个哦。

下载地址：VSTT Quick Reference Guide 1.0

Related posts:

1. VSTS 2010 Test Edition文章收集
2. 图解微软性能测试工具VSTS2008 Load Test Agent安装

然后去微软的网站下载Visual Studio Team System Test Load Agent试用版。是一个ISO文件，用虚拟光驱挂上，然后开始安装。

如果要把Controller和Agent都安装在同一台电脑上，需要先安装Controller。安装的时候需要输入Windows的帐户和密码。整个过程不会太长，期间会默认安装SQL 2005 EXPRESS版，因为controller需要把测试的结果记录在数据库中。

安装好了controller以后，就可以安装Load Agent了，如图，也是需要输入windows的帐户和密码：

安装Agent会比安装controller多一个步骤，就是要指定controller，这里需要输入的controller的计算机名字，而不是什么LocalHost……

如果都安装成功的话，可以在任务管理器里面找到以下3个进程：QTAgent.exe, QTAgentService.exe和QTController.exe

至此， Test Load Agent算是安装成功了，现在进入配置环节。

打开VSTS，配置Test Controller，如图：

进入配置菜单以后，需要配置：

控制器的名字：这里应该是计算机的名字，例如magusvm2003se

Load Test Result Store：由于安装控制器的时候顺带安装了SQLEXPRESS，所以就用这个数据库

Agent：添加一个Agent，由于Agent也安装在一台机子上，所以就选择本机就好了。注意！状态需要为Ready才是正确的配置。

至此，Load Agent算是配置完毕了，但是还不能使用，因为当前的测试还没有配置为使用Load Agent来产生负载。

每一个测试项目，都有一个测试配置文件，现在我们就来修改这个测试配置文件吧，如图：

进入配置的窗口以后如图：需要把控制器选择为Remote，虽然其实是本地，但是从模式上来说就是Remote的。也因为只有选择Remote以后，才能选择controller，填入controller名字，这个名字是计算机的名字！！！

到了这一步，就算是配置完成了，攻击吧，8个核心的压力机！

最后希望大家能多讨论VSTS自带的性能测试工具，其实VSTS的LOAD TEST也是很强大的，还有推荐一篇关于如何安装Load Test Agent的文章

http://blogs.msdn.com/edglas/pages/load-agent-and-load-controller-installation-and-configuration-guide.aspx

Related posts:

1. VSTS 2010 Test Edition文章收集
2. 实现数据驱动的CodedUI Test