用Python脚本对ASP.NET站点进行预热

很多人可能都会注意到，当一些新的代码部署到一个ASP.NET的站点后，第一次访问的时候是非常慢的，有可能需要等待超过一分钟；如果我们更新了站点的bin目录下的一些dll文件，那么这种情况会变得更加明显。当第一个页面请求到达服务器的时候，IIS会重新编译文件，这时候可以观察到w3wp.exe和csc.exe都会占用很多CPU。我们不希望用户是IIS重启之后第一个访问者，所以每台服务器在上线之前，都需要做预热处理。所谓预热处理，原理很简单，就是向目标服务器发送一些HTTP请求，从而触发服务器对文件进行编译，实现预热。

为什么用Python？一位大师曾经说过，程序员要每6个月就要学习一门新的语言（这个要求还真苛刻），所以决定学习一下Python。

需求：其实这个需求特别简单
1. 发送HTTP请求，Python自带的httplib库就能满足这个需求了
2. 多线程访问不同的站点，现在MySpace常用站点至少有4个
3. 指定服务器的IP，因为测试的服务器也有多台
4. 获取HTTP请求的状态
5. 需要在登录状态下进行预热

刷新并且观察主机IP地址的好工具–Firefox DNS Flusher

首先祝大家端午节快乐。

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

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

Firebug网络监视详解

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如下图所示：

用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作为扩展名。

Web测试中三个好用的Firefox插件

对于从事Web开发和测试的工程师来说，Firefox是一个优秀的浏览器；因为基于Firefox的插件有很多，这些插件都极大地方便了开发和测试的工作。其中有著名的FireBug，FireCookie，Web Developer等，今天要介绍的是另外几个名气没那么大的Firefox插件，他们分别是FlagFox、Remove Cookie(s) for Site、Screengrab。

1. FlagFox

这是一个可以将网站服务器所在国家的国旗显示在状态栏上的插件。它通过查询扩展内建的IP地址库，同时通过维基和Geotool获得更多信息。可以参考下图，当我们浏览一个网站的时候在浏览器地址栏的最右边会有一个中国国旗，因为该网站的服务器就在中国；然后把鼠标挪过去放在国旗上面，就会出现该网站的IP，这里就是60.28.210.209。

其实我知道IP所在的国家对于测试没什么帮助，我只想知道我所访问的网站的IP。因为大家都知道做测试的时候经常需要配HOST，重启浏览器，但是有时候 配好了HOST重启完了还不一定生效；又或者HOST文件太大，有时候一个域名给配上了若干个IP（这是一个失误啦~）；又或者是一个域名下有多台测试 机。我想在测试的过程中清楚地知道我现在究竟在访问哪台测试机。这就是FlagFox能起到的作用了

单元测试中的异常处理

最近项目不是十分多，所以大部分的学习来自于书本还有同行的博客，淘宝的QA Team博客就是一个很好博客，里面N多淘宝的工程师写，而且更新的非常频繁，质量也很好。翠翠同学以后就要加入淘宝了，以后就能看到他写的博客了。

早上来看到一篇文章，大概讲的是在单元测试中容易用到了Try…Catch语句而容易出现的一个错误，这里想说一下我对单元测试中异常处理的。记得一个牛人曾经说过（实在想不起来谁也搜不到），大概的意思就是“处理一个问题的最好的办法就是不去处理它”。我不知道当时他讲这句话的具体场景是什么，不过我觉得这句话用在单元测试的异常处理中还是比较合适的。

首先来看看两条关于异常处理的原则

• 如果无法处理某个异常，那么就不要捕获它
• 如果捕获到一个异常，那么不要胡乱处理它

单元测试的代码和开发的生产代码，虽然同是程序代码，但是他们存在的意义是不一样的。前者是验证程序的正确性，属于为程序服务的；后者是实现某种功能，属于为客户服务的。然后在看上面的两条异常处理的原则。

测试工程师可以修复BUG吗？

昨天Check in了几行代码，部署到了生产环境，一切正常，这个是我第一次把代码提交到生产环境。今天早上看到一篇文章“Who fixes the bugs?”。这篇文章是讲述了一个测试工程师是否应该去深入到代码，然后自己把发现的BUG修复，这样的一个事情。很有趣，我刚做完这样的事情，就看到一篇文章讲述同样的问题。 读完那篇文章以后会发现，软件测试真的是一件跟上下文（Context）联系的特别紧密的事情。所以在做某一件事，或者讨论某一件事情的时候，最好先把上下文先弄清楚，然后再下判断。下面阐述一下文章的观点。

• 作为一个团队里面的成员，每个人都有义务和责任去提高产品的质量。
• 测试工程师来修复BUG这样的行为虽然不会京城在传统的软件行业里面发生，但是也不能以这个为理由去打击它。
• 你不必要去创造一个敏捷的过程来规定测试工程师可以修复BUG。

上面这三点非常模棱两可的观点，在我看来就是作者让读者知道，我们在充分了解上下文的前提下来进行判断。对于我现在所处的公司的环境下，昨天我做的事情是没啥问题的。

1. 公司没有严格的流程或者指引，规定了Tester不能往生产的代码库中check-in代码
2. 现在公司的Developer不是很多，有时候能帮的地方尽量帮助，自己也能学到东西
3. 对于我测试过的代码，熟悉起来还是会比较快
4. 我也需要对代码的质量负责

那么这样做会有什么问题呢？

1. 变相地成了自己测试自己的代码，不推荐
2. 对于测试小组来说，比较难留住人才（那篇文章的观点，也是一个现实）

在多数情况下，测试工程师的工作就是不断地折磨那个被测软件，不断地向被测系统提问题；然后等待被测系统的答案，从这些答案里面获得尽可能多的信息，软件测试在开发生命周期活动里面扮演一个服务者的作用，给开发经理，开发工程师，各个stakeholder们提供信息，所以软件工程师甚少去修BUG。而且在大多数非常正规的企业中，测试工程师设置没机会看到代码，所以也没有办法能修复BUG。软件工程师可以修复BUG吗？可以，不过不常见。

避免用户用一个邮箱在网站上注册多个帐号(马甲)

SNS的风已经刮过了，国内不少SNS网站正在刮第二阵风：游戏！像聚友网，开心网，山寨开心网，校内等社交网站都添加了大量的游戏，在这些游戏中都有一个共同之处–邀请朋友注册送积分（金币，道具等等……）。很多人就会多申请几个邮箱，然后再多注册几个马甲来获利。

我比较懒，一直想着有什么样的办法可以不申请更多的邮箱，而又能多注册几个马甲。可能大家都比较熟悉Google的Gmail邮箱，这个邮箱有一个特点就是它那神奇的“+”加号。例如现在我有这样一个邮箱abc@gmail.com那么我只需要在@符号和abc中间添加一个“+”，还有若干文字，就能“生成”一个新的邮箱，无需申请。例如abc+haha@gmail.com, abc+hi@gmail.com，这2个邮箱的邮件都发送到abc@gmail.com中，这就方便了我们注册马甲啦！

单元测试中三种准备Test Fixture的方法比较

首先说一下Test Fixture，我不知道怎么样翻译这个Test Fixture，没能搜到一个翻译的比较合适的。最让我气愤的是某人翻译的一本书中，直接把Test Fixture翻译成为测试夹具，这明显就是什么词霸词典硬翻译出来的，我强烈鄙视这样不负责任的翻译行为。

The test fixture is everything we need to have in place to exercise the SUT

我觉得这是一个对Test Fixture的一个很清晰明了的定义，就是运行被测软件所需要的一切东西，这个“东西”不单只是数据，同时还包括对被测软件的准备，例如实例化某个被测方法所在的类，准备数据库的ConnectionString等。通常来说，有三种方法来准备Test Fixture。

1. 内联方式：这种方式就是直接在测试方法中编写准备Test Fixture的代码。用这种方法的缺点是很容易造成代码的重复，出现很多复制粘贴的代码。同时，如果这个SETUP的过程比较复杂，也会降低测试代码的可读性，可维护性。另外的一个问题就是，这种方法很容易会带来测试数据Hard code的隐患。既然有那么多缺点，这种方法还有什么生命力呢？首先，可能对于初学者来说，这种方法是最简单的；其次，在一些只需要准备简单的Test Fixture的场合中，这种方法还是给编写测试的人提供了便利。