CORE这边测试的特点就是，针对MRM系统的后台进行测试，肩带来说就是模拟各种跟后台打交道的“程序”的工作，进行测试。我们测试有以下特点：

1. 直接跟后台程序交互，基本没有现成的开源或者商业工具可以支持自动化测试快速开展
2. 测试验证结果大多数是后台的输入，也就是前台或者是第三方系统的输入，所以验证的方法不能简单地观察输出结果，同时需要知道后台的输出拿到别的系统能否正常工作
3. 牵涉到数据迁移或者数据重处理的时候，QA需要直接读取生产环境的数据进行校验

由于以上特点，所以我们的自动化测试85%都是自己开发工具来做，常用的脚本语言是Python，经常用到的一些模块包括读取MySQL的MySQLdb；csv模块；re模块；总得原则就是把重复性强，容易引入错误的工作都写成小工具。并且尽可能使用已有的成熟的库，而不是自己重复发明轮子。例如我们的前端页面使用了web.py轻量级框架，JSON库。到目前为止，我自己感觉我们的自动化测试还是做的不错的，主要是以下几点

1. 简单。说起自动化测试，可能有部分人，或者说是外行的人吧，都觉得这个东西非常酷，人只要倒杯咖啡看着电脑执行测试就好了。但是其实实用有效的自动化测试并不是说看起来有多酷，而是这个东西能把人从重复劳动中解放出来。
2. 强大。我刚到公司的时候，已经有600多个回归测试跑在自动化框架上，我当时就觉得已经挺不错的，因为这个自动化测试是由大概4~5个不同的人做的，我以前在MySpace的时候SOA大概有300个CASE，不过那都是我一个人做的，相比较而言FreeWheel应该是更好。
3. 持续改进。虽然我刚到公司的时候自动化测试已经存在并且也算是行之有效，但是任何系统都是有可改进的空间的，我把前端UI改了一下，很高兴可以帮助大家缩短了找问题的时间
4. 全面。基本上所有的模块都有自己的一堆自动化测试工具。

引用一句我非常喜欢的英语：So far so good。那下面我想做什么事情呢？

1. 自动化测试其实不是测试，只是重复运行测试用例而已。真正的测试用的是脑，而不是工具，工具只是辅助我们的工作的
2. 自动化测试是危险的，不要看到所有回归测试都通过了，就高枕无忧
3. 手动测试才是根本
4. 希望能给大家灌输一些思想，如果发现自己在重复做一件事情，那么应该停下来，想想有什么办法能够让自己停止重复，尽可能自己解决问题，培养自己的动手能力
5. 看看有没有一些开源工作能让现在的工作做的更加好

下面说说对VI TEAM自动化测试介绍的一点感觉吧，VI和CORE有点儿相似，就是都是用的自己开发的自动化工具，而没用应用了太多开源工具，我个人觉得这里面原因有2个

1. VI的测试面向Video播放器的SDK，也是一个后台，所以也没有太多现成的工具
2. 用户怎么用我们的SDK？就是调用接口，跟CORE面对的问题相似

估计由于经常跟XML打交道，所以VI的自动化测试用到很多XML文件作为配置。由于隔行如隔山，所以没有看懂里面的一些玄机，总的来说就是跟我们CORE有点相似。

我们CORE和VI一样，这些工具如果跳出了这个公司，基本上就不能应用到其他地方，这也是对整个系统来说的底层部分做自动化测试的特点：高度定制化，通用性低，自己开发居多

最后就是UI的介绍，终于等到一个看得懂的啦。

UI那边就是大量使用开源工具，这个也是很有道理的

1. UI的自动化测试实施难度比后台程序的自动化要大
2. 现有的UI自动化测试非常丰富

那我们的UI是怎么做的呢？首先UI的同事用了一个持续集成的工具hudson作为一个颗粒度比较粗的测试用例管理工具，hudson作为自动化测试的主心骨，QA们可以在hudson上触发自动化测试的运行，运行完了以后可以看到测试结果，并且，利用了hudson的分布式结构，由多个测试机来执行测试，达到了很好的资源调配。对浏览器的控制方面，用了Selenium，会上没有问UI是否利用了Selenium的多浏览器支持，从演示上来看应该只做的Firefox的。他们的分工很明确，分了专门做功能测试的QA和专门做自动化测试工具开发的SDET，SDET主要是负责写RUBY代码，封装并且暴露了一些通用的方法给QA使用，并且同时使用了Cucumber作为一个DSL，QA是用Cucumber来做自动化测试的一些描述，Cucumber的作用就是对功能测试的QA屏蔽了底层RUBY脚本，对上就是“翻译”功能测试QA的意图，“翻译”成RUBY。说一下我觉得的优点：

1. 分开了自动化测试工具开发和自动化测试实施
2. 使用了大量开源工具，提高效率
3. 而且都是业界常用工具，对以后跳槽帮助不小（嘿嘿）
4. One click automation (只需要点一下hudson）

一些工具带来的制约

1. 一次只能运行一批测试，不能重跑单个测试
2. 个人觉得使用XPATH作为对象的识别并不是一个好的选择

总得来说大家都各有特色，并且都做得挺好，并且都有不少可以提高的空间。多点交流的确能带来不少灵感。

No related posts.

TestLink有一个BugTracking的接口模块，可以使得TestLink可以与其他BugTracking系统集成。在集成的过程中发现TestLink提示错误：Bug ID does not exist on BTS（中文的话是’bug的ID在BTS中不存在！’），找到TestLink的代码文件bugAdd.php，找到下面这段代码块

if($args->bug_id != "")
{
	$msg = lang_get("error_wrong_BugID_format");
	if ($g_bugInterface->checkBugID($args->bug_id))
	{
		$msg = lang_get("error_bug_does_not_exist_on_bts");
		// 问题在这里
		if ($g_bugInterface->checkBugID_existence($args->bug_id))
		{ 	  
			if (write_execution_bug($db,$args->exec_id, $args->bug_id))
			{
				$msg = lang_get("bug_added");
				logAuditEvent(TLS("audit_executionbug_added",$args->bug_id),"CREATE",$args->exec_id,"executions");
			}
		}
	}
}

问题出在$g_bugInterface->checkBugID_existence($args->bug_id)这个方法中。在、TestLink的int_bugzilla.php文件中，并没有overload这个checkBugID_existence的方法，所以这个方法就会按照int_bugtracking.php中的默认实现，返回false。TestLink就会出现error_bug_does_not_exist_on_bts这个ERROR

解决这个问题很简单，就是在int_bugzilla.php中自己实现checkBugID_existence方法，简单的实现如下：

function checkBugID_existence($id)
{
	$status_ok = 0;
        //关键是下面这个Query bug id的语句，大家自己看看数据库是哪个表，根据实际情况自己修改	
	$query = "SELECT bug_id FROM bugs WHERE bug_id='" . $id ."'";
	$result = $this->dbConnection->exec_query($query);
	if ($result && ($this->dbConnection->num_rows($result) == 1))
	{
		$status_ok = 1;    
	}
	return $status_ok;
}

OK。在int_bugzilla.php文件中添加了 checkBugID_existence() 方法后，就可以从TestLink中直接把BugZilla里面的BUG ID和某个测试关联起来了。

Related posts:

1. 在Lua中实现简单的StringBuffer

以前在MySpace做测试的时候，主要是写代码来测试一些接口、模块等。这样就会出现一个问题，我用一段程序A去测试层序B，那么测试代码也是程序，如何保证程序A的正确性呢？OK，我们可以写一个程序C去测试程序A，由此来保障程序A的正确性，但是程序C的正确性又由谁来保证呢？who watches the watchers？当时只有我一个人负责白盒测试，最多也就是让开发帮忙看看。其实对于一段程序，只要写的足够简单，那么就可以认为这段简单的程序的正确性是能得到保证的。所以我一直都给自己强调，单元测试的代码不要写的复杂，尽可能不用判断，让测试代码顺序执行下去。

但是对于功能测试来说，怎么样才能尽可能地保证测试的方法，测试的数据，测试的覆盖率是能达到某项标准的呢？在这次MRM 2.9 Release的测试过程中，我们引入了peer review的做法，一个功能点一般会以ticket的形式存在，每个人拿到ticket的时候首先自己设计测试用例，包括测试数据的准备，用什么样的方法等等。然后找另外一个同事来review自己的用例。这样做的好处有：

1. 强迫自己有一个较为系统的测试用例设计，因为这个是需要给同事看，并且让别人看懂的
2. 同事之间的knowledge share在不知不觉中就达到
3. 两个人的review总是比一大群人坐到会议室里面要有效，帮助提高测试覆盖率，尽可能避免测试盲点
4. 互相监督

No related posts.

Related posts:

1. 推荐阅读：5 Ways to Revolutionize Your QA

第一个网站是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的公司，其实他们可以兼营性能测试，因为他们的服务器分布的跟真实情况最接近的，而且也有足够多的服务器资源和带宽。

No related posts.

若干个月前他在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（哎，要翻墙才能看）发表文章

Related posts:

1. 如何成为一名优秀的测试工程师
2. 《Software Testing》第二十一章 – 软件质量保证
3. 敏捷测试只是手段不是目的

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

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

这个方法做了大部分的事情，Http请求，带登录状态的，能够指定IP的，指定站点的，指定页面的

1
2
3
4
5
6
7
8
9

def warmwww(inputServer,inputHost,inputPage):
	conn = httplib.HTTPConnection(inputServer)
	headers = {"Host":inputHost,"Cookie": "MYUSERINFO=MIIxxx%3d"}
	conn.request("GET", inputPage,"",headers)
	r1 = conn.getresponse()
	data = r1.read()
	conn.close()
	global results
	results.append((inputHost,r1.status))

主要用到了httplib.HTTPConnection类，获得一个httplib.HTTPConnection的对象；登录就是在Headers里面加一个标志登录的Cookie；由于要支持多个服务器，所以在初始化httplib.HTTPConnection对象的时候，指定的是IP，然后在Headers里面的Host中指定需要预热的站点；最后GET某个站点下的某个页面作为预热；最后获取response的状态码。这里需要import httplib。

接下来要做的就是用多进程来访问需要预热的站点

1
2
3
4
5
6
7
8
9
10
11

def run(server,paras):
	threadcount = 0;
	threadList = []
	for pa in paras:
		rm = threading.Thread(target = warmwww, args=(server,pa[0],pa[1]))
		rm.start()
		threadList.append(rm);
	for rt in threadList:
		rt.join()
		threadcount = threadcount + 1
	print threadcount,"Threads started. Run on server", server

threading.Thread()可以实例化一个Thread对象，参数target就是需要运行的方法，在Python里面，方法也是一个对象；如果target是带有参数的，那么就要通过args把参数传递进去。这里需要import threading。

1
2
3
4
5
6
7
8
9
10
11
12

if __name__ == "__main__":
	successFlag = True;
	begintime = time.time()
	run(server,paras)
	endtime = time.time()
	print "Finish the task in", endtime-begintime, "seconds"
	for sr in results:
		if(sr[1]!=200):
			print "Warm up",sr[0], "failed.", "status code:",sr[1]
			successFlag = False
	if successFlag:
		print "all warm up script run successfully."

paras是一个预先定义好的列表。results是一个全局变量，每个预热的结果都会存到results中，等预热程序执行完毕以后，检查其返回的状态码，如果等于200，就算通过；否则，就认为预热失败，并且打印出返回状态码。

经常会看有有人在论坛上提问，例如如何在XXX工具中发送带有cookie的请求，如果在YYY工具中模拟已经登录的用户做操作。其实这当中最根本的问题应该是，登录的原理是什么，知道这个原理以后，就很容易找到实现的方法，不管用的是C#还是Python。工具是手段，原理是根本。

Related posts:

1. 在C#单元测试中使用HttpContext的简单解决办法

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

Related posts:

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

文章：

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

Related posts:

1. 图解微软性能测试工具VSTS2008 Load Test Agent安装
2. VSTS2010的一个新功能–CodedUI Test简介
3. 《Software Testing》（软件测试）读书笔记系列 – 第十六章

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

从左往右分别是

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

请求部分

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

http状态码

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

域名

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

文件大小

没什么可解释的

timeline

这里是重点。在Firebug 1.3.3中，timeline如下图所示：

有2个时间信息是让人比较迷惑的。

Queuing：这个Queuing一开始我以为是从浏览器发送请求，到服务器返回第一个字节的时间；后来我发现我的瞎猜是错的，Queuing是Firefox浏览器的一种机制，就例如如果一个页面上有很多个图片元素，那么其中一些图片元素的请求就被放到队列里面。

Receiving Data：接收数据的时间

在Firebug 1.3.3中，这两个数据让人很迷惑，而且实用价值很小。后来我发现了现在Firebug有 1.4 alpha版本，在1.4中，会把请求的时间细分，具体如下图所示：

分别是：

1) DNS Lookup （DNS查找时间）
2) Connecting （这个我没搞清楚是什么连接时间）
3) Queuing (Firefox内部的队列)
4) Waiting for the response (请求发出去以后，等待服务端响应的时间)
5) Receiving Data (接受到服务端响应以后，下载数据所用的时间)

有了这些时间，可以帮助对页面进行优化，例如如果发现接受数据时间很长，那是不是因为图片文件太大，或者没有用GZIP压缩；如果等待响应时间很长，是不是程序设计有性能问题，导致响应时间很长。

最后推荐大家一个WEB工具，Cuzillion，这个工具可让用户在线创建一个他们想要的页面，例如可以放一个引用的JS到HEAD里面，或者在BODY中放几个图片，IFRAME等。通过创建不同的页面，可以对一些前端最佳实践进行验证。例如把JS放在页面的底部，CSS放在页面的顶部等等。

No related posts.