调试部署在IIS上的ASP.NET程序实用小技巧

远程调试ASP.NET程序，似乎是每一个做ASP.NET的人都肯定要掌握的技能，大家都知道，从IIS6开始，就有了application pool(应用程序池)的概念，每个应用程序池都会有单独的worker process，这样可以保障不同的应用程序池之间互相不会影响，就好像MySpace上有博客应用，有论坛应用等等……如果这些应用都用的同一个应用程序池，那么只要一个挂了，其他的也跟着挂。但是如果每个站点都单独使用一个应用程序池，那么A站点挂了对B站点不会有影响。同时如果A站点有部署更新，需要回收应用程序池，B站点不受影响，照常工作。

创建多个应用程序池虽然好处多多，不过却增大了调试的难度。假如一台服务器上有5个站点，那么正常运行的情况下就会有5个w3wp.exe进程，要找到合适的进程进行调试就是一个问题，以前比较笨，就看哪个进程的ID比较小，或者哪个进程占用的内存较多来“判断”，今天发现其实微软有一个非常靠谱的方法。

1. 打开一个命令行窗口

2. 浏览到“Windows > System32”

3. 运行“cscript iisapp.vbs”

得到如图结果，哪个应用程序池对应哪个W3WP.EXE一目了然，从此告别瞎猜

Linq to Object在测试中的应用

.NET Framework 3.5中引入了一个新特性LINQ（集成语言查询），据说.NET Framework 3.5中很多特性都是为LINQ而服务的，例如Lambda表达式的支持，匿名类型，等等……这篇文章会讲述一个把Linq to Object应用于测试的例子。

前一阵子需要测试一个搜索在线会员的功能，如果一个用户是在线的，那么他所能够被搜索到的信息都会作为一条记录，保存在一个表中，主要的字段有5个，也就是根据这5个字段的信息可以查询出用户想要的在线会员。一个简单的方案就是写一个比较复杂的存储过程，然后根据5个输入来查询出不同的结果，不过DBA说在SQL SERVER中进行逻辑运算的性能不是很好，所以开发人员写了12条存储过程，分别对应不同的组合，那么对于我做集成测试来说，我起码要有12个测试方法对应这12条存储过程。同时我还要设计一定数量的测试数据，供我查询测试，而比较要命的是，这些测试数据随着我对这个功能的理解的深入，在不断地增加，结果就是如果我写第一个测试的时候，我准备的数据是30条，OK，测试通过；等我写到第五个测试的时候，测试数据可能有40条了，当我用这40条测试数据重新指向第一个测试的时候，FAILED!!!这让人非常郁闷。所以我想到了能不能用round trip的方法来进行测试。做一个比喻，假如说我想证明WIN7的计算器程序是正确的，那么可以把相同的计算在WIN XP的计算器中跑一遍，如果两者结果一样，那么我可以认为WIN7的计算器程序也是正确的（如果XP的计算器有错怎么办？先别较真，有风险，但很小）。

我的做法就是，准备一些数据，首先用SUT进行查询，然后用LINQ进行查询，如果两者查询结果一致，那么可以认为程序是正确的，否则就是两者之一存在问题。

首先准备一些测试数据，保存为XML文件，第一方便对测试数据进行CRUD，第二可以用XmlSerializer把这些数据转换为对象，方便用LINQ查询。

自己动手创建Web测试验证规则

”Web测试”是由一系列 HTTP 请求组成，通过发出 HTTP 请求在协议层工作的测试类型。在VSTS中自带了若干个预先定义好的验证规则，例如在返回的页面上寻找某些字符，返回的文档中是否包含某些Tag，等等。前一段时间在测试一个安全过滤器，这个过滤器的基本功能就是过滤用户输入中的一些有可能构成安全隐患的内容，例如<script>标签的内容，JS内容等等。按照预先给出的测试用例执行完测试以后，OK，没有问题，不过在上线一个小时后发现一个问题，就是经过安全过滤器输出的内容会比原来输入的内容多了两个字符–“rn”，这个问题一下就修复好了，Trim一下。然后我就要给原来的测试加上对于这个问题的回归测试实现。很不巧，Web测试没有一个对返回内容长度进行验证的验证规则，不过微软提供了创建自定义验证规则的接口，我们可以创建一个验证ContentLength的规则。

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

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

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

4. 重写基类的Validate方法

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

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

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

VSTS 2010 Test Edition文章收集

STS 2010 BETA 1在近期已经开始发布了，各路高手纷纷出动，在这里我就把我看到的一些不错的关于VSTS2010测试人员版本的文章收集一下，希望对其他人有帮助，也便于我以后复习用 😆

文章：

《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官方博客

用VSPerfMon在测试ASP.NET程序的过程中收集代码覆盖率信息

前两篇文章介绍了VSTS性能分析工具Profiler和如何用Profiler发现性能问题并且进行优化。今天想分享一下如何在测试ASP.NET程序的过程中获取代码覆盖率的信息。

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

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

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

VSInstr “D:WebsitessomewherebinMySpace.Web.UserHome.dll” /COVERAGE

2. 停掉IIS

iisreset /stop

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

VSPerfClrEnv /globaltraceon

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

用VSTS Profiler发现性能问题并且进行优化实例

上一篇文章介绍了如何使用VSTS的Profiler，今天想分享一下对于一个ASP.NET应用程序，用Profiler找到性能问题并且对之进行优化。

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

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

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

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

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

VSTS性能分析工具Profiler的介绍

在MSDN文档中，对于VSTS中的Development Edition的介绍主要分两大块，第一是“编写高质量的代码”，第二就是“使用分析工具对应用程序性能进行分析”。在VSTS里面有一个工具，叫Profiler，这个工具可以帮助研发人员在程序运行的过程中收集相关的数据，并且对之进行分析，从而达到帮助实现性能调优的目的。本文讲述如何在使用命令行工具来对ASP.NET程序进行性能测试相关数据的收集。

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

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

VSTS测试人员版本快速指南已经发布

今天从VSTS LOAD TEST TEAM的一位成员的博客得知，他们今天发布了VSTS测试人员版本快速指南，我下载了浏览了一下，WEB TEST和LOAD TEST的内容讲的较多，这个指南是以问答的形式出现，个人感觉比较好。引用他们的一句原话就是“This doc is a must have for anyone working in VSTT”。可见这个分量多重。

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

下载地址：VSTT Quick Reference Guide 1.0

利用序列化和反序列化实现深拷贝

假如说有一个简单的类，只有2个属性，那么可以用比较简单的方法实现深拷贝。

[Serializable]
public class Person
{
    public int Height { get; set; }
    public string FirstName { get; set; }
}

class Program {
    static void Main(string[] args) {
        //实例化一个对象
        Person PersonOne = new Person();
        PersonOne.FirstName = "John";
        PersonOne.Height = 1;
        //深拷贝
        Person DeepCopyPerson = new Person();
        DeepCopyPerson.FirstName = PersonOne.FirstName;
        DeepCopyPerson.Height = PersonOne.Height;
    }
}

测试代码重构实例

Martin Fowler的《重构》这本书基本上每个程序员都会看，对于做单元测试的测试工程师来说，测试的代码本身也是程序，也需要重构。最近在看《XUnit Test Patterns》，把以前的做的东西重新梳理了一下，并且落实到新的项目中。

首先来看看一个最原始的单元测试代码：

[TestMethod]
public void GetPaymentAccountByOwnerID()
{
	int ownerId = 1300100000;
	//Delete the account
	TestHelper.DeletePaymentAccountByOwnerId(ownerId);

	//Here should be create an account
	PaymentAccount paymentAccount = PaymentGateway.PaymentProvider.GetPaymentAccountByOwnerID(ownerId, AccountOwnerType.NormalUser);

	//Verify the payment account instance
	Assert.IsTrue(paymentAccount.AccountID > 0);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.CreateTime.DayOfYear);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.UpdateTime.DayOfYear);
	Assert.AreEqual(0, paymentAccount.Balance, 0.0001);
	Assert.AreEqual(0, paymentAccount.AvailableBalance, 0.0001);
	Assert.AreEqual(0, paymentAccount.FreezeAccount, 0.0001);
}

以上是个很简单的单元测试代码，应用了AAA原则，首先做好准备（删掉原有的数据），然后执行测试，最后再验证返回结果。看起来很好也很清晰。首先发现一个问题，就是那一堆Assert让人觉得迷惑，究竟想干啥？其实那6句Assert都是验证程序返回的PaymentAccount对象是是否符合设计。我把这些Assert语句提取出来，作为一个方法，让测试代码更加容易让人明白。也就有了版本2。