进化的测试

远程调试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一目了然，从此告别瞎猜

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

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

前两篇文章介绍了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

假如说有一个简单的类，只有2个属性，那么可以用比较简单的方法实现深拷贝。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [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(); [...]

Martin Fowler的《重构》这本书基本上每个程序员都会看，对于做单元测试的测试工程师来说，测试的代码本身也是程序，也需要重构。最近在看《XUnit Test Patterns》，把以前的做的东西重新梳理了一下，并且落实到新的项目中。 首先来看看一个最原始的单元测试代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [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 [...]