进化的测试

关注软件测试,白盒测试,自动化测试,性能测试

VT100终端下screen key binding参考对照表

从此就在Linux环境下工作了,最近听说一个软件,名叫screen,主要应用的场景就是当你需要运行一些耗时较长的任务的时候,终端很容易就超时了,超时了以后你前面做的所有东西都白费了,但是有了screen,永远在线成为可能。developerWorks上有一篇文章专门介绍screen的使用,推荐阅读。

我碰到的问题就是想修改screenrc这个配置的时候,不知道具体的Key Binding,看到默认配置里面K7对应的F7按键,F1对应的F11,比较迷茫。还好终于谷歌出来一个很有用的对照表。具体怎么设置可以看这里

工作上有些变化

我即将离开工作了17个月的MySpace,有点不舍,希望以前的同事在今后一切都顺利。我的新公司是FreeWheel,一家提供在线视频广告技术服务的公司。

新工作,新起点, Good luck to me :-)

窥探云测试

云计算是当今的一个热点,也是一个潮流,那么软件测试能否借助云计算的威力而更上一层楼呢?最近看了几个号称云测试的网站,有感,记录一下。

第一个网站是Cloud Testing。这个公司能提供多种平台,多种浏览器的平台,一般的用户在本地用Selenium把自动化测试脚本编写好,然后上传到他们网站,然后就可以在他们的平台上运行Selenium脚本了。他们的优点是:平台和浏览器覆盖得广,按需付费。不过我自己对这样的服务有以下的疑问:

  1. 基于UI的自动化测试通常都会遇到一些不稳定的问题,本地编辑好的自动化脚本是否也能够在他们的平台上正常运行
  2. 如果出现错误,有没有办法进行调试。究竟这个错误是SUT的错误,还是测试脚本的错误,如何区分
  3. 用户自己开发的插件能否在这个云测试平台上使用(我觉得是不行的)

总得来说Cloud Testing是一个基于UI自动化测试的云测试平台,但是我认为这样的平台并没有太多的优势,一般做互联网的公司产品发布都是比较快的,根本是不可能有时间和资源去覆盖所有的浏览器和平台,根据80/20原则,在中国搞互联网,只要搞定Windows下的IE6和IE7基本上就万事大吉了,一般好一点的前端TEAM都是在Firefox下进行开发的,所以Firefox的兼容应该是不成问题,最后在Chrome和Safari上过一下关键流程,差不多了。再说,现在虚拟化技术日渐流行,自己搭建多个平台也不是非常耗费资源。

第二个是keynote公司的kite,这个感觉比Cloud Testing更加弱一点,kite有自己的浏览器,然后用户在这个浏览器上录制脚本,然后上传,然后可以在keynote公司不同的可用地点中运行测试,查看结果。这个平台给我的感觉更多的是关注终端用户性能,里面有一个页面元素下载的timeline,用户可以查看那些页面资源下载花费多少时间,DNS查询时间等等……

这个平台的问题有:

  1. 可用的节点不多,现在为止只有北美地区的几个节点可用
  2. 专门的工具,可能对测试的结果有影响

估计是keynote公司的一个实验性产品。

第三个是SOASTA。这个公司不单只提供了功能测试,而且还有性能测试。感觉上性能测试应该是利用云计算的一个非常重要而且有意义的点。貌似这个公司不是那么开放,没有太多公开的资料,所以不知道他们是怎么运作的。看他们的网站的一些成功案例,说的挺好,不过这样相对于在公网做性能测试,不知道会不会有问题:

  1. 带宽问题,例如云那段设定的带宽是1Mb,那么云和端之间的带宽是否能真正达到1Mb呢
  2. 安全问题,这些性能测试的脚本不会日后成为攻击的工具吧

突然觉得,现在做CDN的公司,其实他们可以兼营性能测试,因为他们的服务器分布的跟真实情况最接近的,而且也有足够多的服务器资源和带宽。

调试部署在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一目了然,从此告别瞎猜

IIS-WORKER-PROCESS

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查询。
[Read the rest of this entry...]

推荐阅读:5 Ways to Revolutionize Your QA

James Whittaker,两个月前还是微软Visual Studio的一个产品经理,好像是负责VSTS 2010的最新产品Lab Managment。现在已经跳槽到Google做测试总监了。

若干个月前他在utest有一个讲座,题目是《5 Ways to Revolutionize Your QA》,今天早上我又翻出这个文档仔细看了看,觉得真是受益匪浅,推荐推荐,在这里可以下载《5 Ways to Revolutionize Your QA》

主要讲了5条:

Insight 1:  There are two types of code and they require different types of tests
Insight 2:  Take your testing down a level from features to capabilities
Insight 3:  Take your testing up a level from test cases to techniques
Insight 4:  Improving development is your top priority
Insight 5:  Testing without innovation is a great way to lose talent

其中我个人对第一条和最后一条感触比较深,第一条里面提到了当年Vista就是过分信任自动化测试,结果……大家都能看到;第五条就解释了为什么在测试这个行业,大牛那么少,而牛人又经常转做开发或者别的工作去了。

James Whittaker在微软的博客

James Whittaker现在偶然会在Google Testing Blog(哎,要翻墙才能看)发表文章

用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. 需要在登录状态下进行预热
[Read the rest of this entry...]

在测试项目中应用Pex的经验分享

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和一般的单元测试分开,如图:

test

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

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

首先祝大家端午节快乐。

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

flusher

自己动手创建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”,选择刚才编写好的验证规则。

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