其实算上实习，我已经在4个公司工作过了，回头来看看这些公司研发团队的开发测试比例，从一个小职员的角度。

第一个公司是一家年收入10亿美元的百年老店，传统软件企业，在那里，开发和测试的比例大概是3:1。作为一个传统的软件企业，这家公司的自动化测试在那时候（2006年）才是刚起步，公司内部有较为规范的流程，QA在公司里面的工作大概就是从需求文档开始到各种设计文档进行review，之后dev开始写code，这时候QA也开始写测试用例，当时用的是QC。写好以后QA会review用例，然后就开始执行用例（真的是step by step，不夸张）。一个人一天如果能执行完40个用例，那是相当的高效率。3:1这个比率，看上去挺正常，但是其实QA做的工作并不多，总的来说QA的工作效率不是很高。在自动化测试程度不高的情况下，要保持产品质量，所以需要更多的QA来达到这个要求。我个人认为3:1的比率有点高。

之后在一家做统计分析的美资企业实习过一段时间，这个公司现在已经被IBM收购鸟……在这个公司，开发和测试比大概是2:1。QA的工作主要是阅读设计文档，设计测试用例，执行测试。同样，我觉得这个公司跟之前那个公司有着相同的问题，自动化测试程度不高，但是产品的质量要求非常高，所以需要更多人力物力在QA团队，而且由于各种各样的问题，团队的效率好像不是非常高。所以2：1这个比率有点高，但是其中是有他的原因的。

在MySpace，我们的开发测试比大概是5:1，互联网公司，要的就是一个快字，所以对产品的质量不需要很高，有Bug没关系，只要改的快就行了，抢在竞争对手前把产品发布出去才是根本。那时候基本上是一个人负责一个项目，一个项目可能持续2~3个月，完了以后继续第二个项目，QA要做的事情是，在拿到产品的设计文档以后，跟开发一起开会做设计，做测试用例，测试，上线，回归。我做的是后台的测试，所以我这边其实是4个开发写的代码给我1个人测试，那些接口测试用例其实都是自动化的（VSTS的mstest）。所以工作基本能很好完成。在这个互联网公司，有互联网的血统（快），但是对产品的质量要求也不低，QA做的工作比较细（其实主要是要经常性地在IE6的样式上纠结）。在自动化测试开展的还可以的情况下，比率是5:1。

终于到FreeWheel了，首先说一下我们的开发测试比，1.2:1，具体说就是12个开发对10个测试。说一下那么多QA都是干嘛的呢？QA的工作主要是拿到PM的设计以后，参与开发的设计，之后设计用例，测试，把测试转化为自动化回归测试（其实很方便的）；解答客户遇到的各种问题（为什么我的广告没出来，我想要XXX的数据，等等）。我个人觉得这套服务的特点是（相对于其他系统来说）商业逻辑非常复杂，软件本身的复杂度相对商业逻辑来说较低。据我的工作的体会，DEV很少会出现比较低级的bug，出现bug的地方大多数都是在商业逻辑上，说白了这是一套business driven的系统，客户需求是第一位，如果他说要一个算法，要1+1=7的，都是要实现的。所以QA在看需求的时候需要看的非常细，所以就需要更多的QA，并且会花比较多的时间去解决客户遇到的问题。

这个开发测试比，基本上每家公司都是不一样的。这个原因有很多，公司传统，领导风格，人员素质，工作内容，等等……如果离开了当前公司的这个Context去谈开发测试比，并没有太多的意义。就譬如说两家公司的开发测试比都是3:1，但是其中一家公司的可能很糟蹋，另一家很高效。谈这个开发测试比例，最好是在相同的类型的公司（创业型VS大公司），相同的行业（互联网VS传统），人员素质在同一个水平，等等。。。在这些前提条件下，如果发现自己的所在的组织的效率不如其他公司，可以参考同行有什么好的实践，取其精华去其糟粕。

开发测试比例只是浮云，整个组织的效率才是关键。

No related posts.

gcc -fprofile-arcs -ftest-coverage hello.c -o hello

编译后会得到一个可执行文件hello和hello.gcno文件，当用gcc编译文件的时候，如果带有“-ftest-coverage”参数，就会生成这个.gcno文件，它包含了程序块和行号等信息
接下来可以运行这个hello的程序

./hello 5
./hello 12

运行结束以后会生成一个hello.gcda文件，如果一个可执行文件带有“-fprofile-arcs”参数编译出来，并且运行过至少一次，就会生成。这个文件包含了程序基本块跳转的信息。接下来可以用gcov生成代码覆盖信息：

gcov hello.c

运行结束以后会生成2个文件hello.c.gcov和myfunc.c.gcov。打开看里面的信息：

-: 0:Source:myfunc.c
-: 0:Graph:hello.gcno
-: 0:Data:hello.gcda
-: 0:Runs:1
-: 0:Programs:1
-: 1:#include
-: 2:
-: 3:void test(int count)
1: 4:{
-: 5: int i;
10: 6: for (i = 1; i < count; i++)
-: 7: {
9: 8: if (i % 3 == 0)
3: 9: printf (“%d is divisible by 3 \n”, i);
9: 10: if (i % 11 == 0)
#####: 11: printf (“%d is divisible by 11 \n”, i);
9: 12: if (i % 13 == 0)
#####: 13: printf (“%d is divisible by 13 \n”, i);
-: 14: }
1: 15:}

被标记为#####的代码行就是没有被执行过的，代码覆盖的信息是正确的，但是让人去读这些文字，实在是一个杯具。不用担心，有另外一个工具叫lcov，可以用程序解析这些晦涩的字符，最终输出成html格式的报告，很好吧！

lcov -d . -t ‘Hello test’ -o ‘hello_test.info’ -b . -c

指定lcov在当前目录“.”去找代码覆盖的信息，输出为’hello_test.info’ ，这个hello_test.info是一个中间结果，需要把它用genhtml来处理一下，genhtml是lcov里面的一个工具。

genhtml -o result hello_test.info

指定输出目录是 result。一个完整的html报告就生成了，做一个连接，把这个目录连到随便一个web server的目录下，就可以看报告了。

测试结果概览

具体某个文件的覆盖率

gcov和lcov基本上能满足测试过程中收集代码覆盖率信息的需求，不过有个遗憾就是gcov不能收集.so文件的代码覆盖信息。

No related posts.

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和某个测试关联起来了。

No related posts.

以前在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.

No related posts.

第一个网站是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（哎，要翻墙才能看）发表文章

No related posts.

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

那怎么对付这样投机取巧的人呢？其实可以获取他的真正的邮箱，因为万变不离其中，其实注册的邮箱就是abc@gmail.com，用一个小小的方法获取一下base email就OK了，参考代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public static string GetBaseEmail(string email)
{
	if (string.IsNullOrEmpty(email))
		throw new ArgumentNullException("email");
	string TrimedEmail = email.Trim();
	int PositionofAdd = TrimedEmail.IndexOf('+');
	int PositionofAt = TrimedEmail.IndexOf('@');
	if (PositionofAdd > 0 && PositionofAt > 0)
	{
		return TrimedEmail.Substring(0, PositionofAdd) + TrimedEmail.Substring(PositionofAt);
	}
	else
	{
		return TrimedEmail;
	}
}

这样就可以稍微减少一点恶意注册，增加注册马甲的成本。其实还有很多更加有效的防止注册马甲的方法，例如在浏览器里面记录一个COOKIE来唯一标示该浏览器，不过清一下COOKIE就能搞定，或者换一个浏览器。又或者记录下注册和登陆的IP，但是这个有可能会误伤了网吧用户。总之就是道高一尺魔高一丈。今天突然想起来以前曾经看过这样一个方法，拿出来分享一下。

Related posts:

1. WebDriver测试失败后自动获取截图
2. 利用序列化和反序列化实现深拷贝
3. 用XSD自动生成XML对应的.NET实体类