进化的测试

”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”，选择刚才编写好的验证规则。 现在看看在自定义验证规则中添加参数，让用户输入相应的参数，从而使得验证规则更加灵活。

做过单元测试的朋友都知道，几乎每一个单元测试的框架都提供了类似于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插件，完成。

昨天介绍了如何创建一个简单的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 [...]

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 [...]

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

前两篇文章介绍了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作为扩展名。

上一篇文章介绍了如何使用VSTS的Profiler，今天想分享一下对于一个ASP.NET应用程序，用Profiler找到性能问题并且对之进行优化。 由于ASP.NET程序运行在一个硕大的框架上，所以一般用Sample模式收集到的数据，对发现性能问题帮助不大，以下是一个用Sample模式收集的结果： 从这个报告中我们可以看到，前5个工作量最大的函数和执行单独工作最多的函数都是系统函数。 下面看一下有针对性地用检测模式收集的数据： 本文就采用“检测”模式收集性能数据来进行分析和处理。 首先，把本次测试的目标DLL用VSInstr工具进行处理，使得Profiler能够收集相关的性能数据，这一个步骤非常关键，通常来说不需要设置额外的参数，就是默认的方式就可以了，例如：VSInstr “D:\Websites\xxxx\bin\xxxx.dll”，在处理的过程中可能会提示一些错误，具体错误的信息可以在这里查找。把相应的DLL处理完毕以后，就在命令行输入以下指令（命令行的指令用斜体加下划线表示；说明文字加黑）

在MSDN文档中，对于VSTS中的Development Edition的介绍主要分两大块，第一是“编写高质量的代码”，第二就是“使用分析工具对应用程序性能进行分析”。在VSTS里面有一个工具，叫Profiler，这个工具可以帮助研发人员在程序运行的过程中收集相关的数据，并且对之进行分析，从而达到帮助实现性能调优的目的。本文讲述如何在使用命令行工具来对ASP.NET程序进行性能测试相关数据的收集。 在VSTS的Profiler中，有两种(VSTS2010好像有5种了)Profiling的方法，第一种是采样(Sampling)，第二种是检测(Instrumentation)。对于采样模式，它的工作原理是Profiler定期中断CPU并且收集函数的调用堆栈信息。在网上找到一个图，对于采样工作方式的描述非常清晰： 对于检测模式，他的工作原理是用VSInstr程序在原始的代码中插入一些用于计算时间的代码，例如A函数调用B函数，那么在调用B函数的前后都会被插入用于计算时间的代码，具体可以看下图：

今天从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

最近在用VSTS做性能测试的时候发现本地发起请求只能占用1个CPU，其余的CPU都是空闲的，上网查了一下，这个是因为用VSTS做性能测试的时候，发起压力的进程是VSTESTHost.exe，如果想让多核CPU的每一个CPU都产生压力，需要安装使用Visual Studio Team System Test Load Agent。这个工具是要钱的，即使你订阅了MSDN的什么版本，在下载中心里面下载到的都是90天试用版，可能也是因为这个原因，网上很少资料介绍如何安装和使用这个Load Agent。经过1个下午的摸索，成功配置成功，以下是在Windows Server 2003下安装Visual Studio Team System Test Load Agent的过程，VSTS，Controller和Agent都安装在同一台电脑上。