进化的测试

Pex是微软研究院开发的一个自动化白盒测试工具，前面我也写过一些博客来对Pex进行介绍，上周决定正式把Pex应用到真正的项目中，不过效果没有想象中的好，不过还是决定记录下一些心得。

1. 关于测试类名称和测试方法名称

为了把Pex和其他的单元测试方法区分开来，本人选择了把所有Pex的测试都以PexTest作为方法名和类名的前缀。因为Pex会根据已经写好的PUT(Parameterized Unit Test)生成一般的单元测试代码，规则可以自定义，一般都是PUT的名字然后跟上01，02，03……如果我们以PexTest作为前缀，那么就比较容易区分PexTest和普通的单元测试。

2. 每个PexTest都会生成一些普通的单元测试代码，这些代码都是存放在一个叫{TestMethodName}.g.cs的文件中，对于这个文件里面代码，不建议手动修改。

3. 在组织测试代码的时候，应该吧PexTest和一般的单元测试分开，如图：

4. 如果需要测试Singleton实例中的方法，需要给这个实例创建一个带有[PexFactoryMethod]属性的方法，来告诉Pex如何获得Singleton实例。例如：
[Read the rest of this entry...]

首先祝大家端午节快乐。

前一段时间写了篇文章介绍了一个在Firefox下查看主机IP的插件，那个插件虽然不错，但是还是有点麻烦，要把鼠标挪过去才能看，最近发现一个更加好用方便的插件：Firefox DNS Flusher。这个插件使用起来很简单，安装完毕以后在Firefox的状态栏的右侧，会有一个显示当前主机IP的地方，如果修改完了HOSTS文件，想要刷新一下DNS，那么可以左键或者右键单击那个IP地址栏就可以了，实现了不重启浏览器也能使得最新的HOSTS文件生效！不错吧！不过测试的时候建议还是要重启一下浏览器，因为当前的域名的IP指向是刷新了，但是其他域名的呢？例如专门存放css或者js文件的子域名，他们不一定能被刷新哦。抓个图：

”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”，选择刚才编写好的验证规则。

现在看看在自定义验证规则中添加参数，让用户输入相应的参数，从而使得验证规则更加灵活。
[Read the rest of this entry...]

做过单元测试的朋友都知道，几乎每一个单元测试的框架都提供了类似于TestInitialize、TestCleanup这样的操作，可以在测试的开始和完成测试以后让我们处理一些问题，例如初始化一些数据，或者销毁一些数据等操作。在VSTS中有一种测试类型叫”Web测试”，它由一系列 HTTP 请求组成，通过发出 HTTP 请求在协议层工作。Web测试没有单独的TestInitialize、TestCleanup操作，但是VSTS所提供的Web Test插件能够帮助我们完成这样的工作。以下是MSDN对Web测试的定义：

使用 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插件，完成。
[Read the rest of this entry...]

昨天介绍了如何创建一个简单的CodedUI Test。我们也知道，依靠录制回放产生的自动化测试是非常不可靠的，那些在微软的大牛们肯定也早就知道了。虽然用VSTS录制一个自动化测试脚本的过程不是那么友好，也不是很方便，不过它产生的测试代码修改起来还是比较容易的。下面我们就看看如何把一个简单的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)
	{
		//按那个等于号
	}
}

[Read the rest of this entry...]

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

VSTS2010 Beta 1 终于出来了，安装的体积不大，只有1.22GB。之前看了很多VSTS2010的新特性，尤其是测试方面的，非常期待，昨天从MSDN下下来以后，失望了一下，因为很多新功能都是基于TFS2010的，我没有装，所以很多新功能都体验不了。例如让人很激动的Lab Manager，这个需要TFS，还有支持虚拟化技术的CPU。

如果你对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会提示用户，是否立刻创建相关的自动化测试代码，如图所示：

[Read the rest of this entry...]

Firebug是一个非常强大的Firefox附加组件，可以查看、编辑HTML，CSS，JavaScript，Cookies，是开发者必不可少的工具，现在Firebug的发行版本是1.3.3。

Firebug中有一个叫“网络”的面板，在这里我们可以看到各个元素的详细信息。

从左往右分别是

• 请求部分
• http状态码
• 域名
• 文件大小
• timeline

请求部分

这个地方是可以展开的，里面包括了请求的地址，请求的方法（是GET还是POST），请求的参数，Headers等等。

http状态码

如果是成功，就是200，404就是请求资源部存在，具体可以看这里

域名

查看该资源所属的域名，其实在请求部分中已经有这个信息了，不过在这里列出来会方便查找某些域名下在资源

文件大小

没什么可解释的

timeline

这里是重点。在Firebug 1.3.3中，timeline如下图所示：
[Read the rest of this entry...]

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

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

解决这个问题的其中一个方法，就是对关键部分的代码进行代码覆盖率的统计。平时我做单元测试和接口测试的时候，得益于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作为扩展名。
[Read the rest of this entry...]

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

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

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

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

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

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