在代码签入之前运行测试

很久没有写文章,看着每天仅有的可怜的访问量,实在觉得对不起读者,决定再写点什么吧。

测试工程师应该做什么?如何体现测试工程师的价值?类似的问题如果放到一些测试会议或者沙龙上讨论,估计一定很热闹。每个人心中都有自己的认识和答案。我个人理解的较为简单,假如整个团队没有测试,会达得到什么样的一种成就?那假如把测试加进去这个团队,能否帮助大伙提高成就?如果测试是在做正功,那么就是有价值,至于价值多少不容易衡量,如果测试在做负功,那还是自求多福吧。

软件天生就有缺陷(Defect, Bug),缺陷从哪来?缺陷从不平白无故地出现,它总是伴随着功能(Feature)而来,谁创造了功能?随便啦,但是最后通常来是开发工程师动手的,所以大部分时间开发都会负责修bug。一般的流程都是:1. 写了一些功能; 2. 测试;3. 发现一些bug;4. 修bug。如果我们可以加速这个反馈的时间,那么也算是做了正功了。

在网上找到一张很好的图: http://www.jetbrains.com/teamcity/features/delayed_commit.html 很好的解释了怎么样在真正提交代码之前运行测试。至于如何做,基本上每个代码管理工具都有类似的支持,例如Git的Hook: http://git-scm.com/book/en/Customizing-Git-Git-Hooks, 又例如一个号称更加好的Hook:https://github.com/jish/pre-commit,SVN也行:http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.pre-commit.html

我只分享一下我自己在使用上的一些经验:

  • 如果你的测试是Flaky的,不要放在pre-commit里面去。一切看起来很没好,但是如果当开发经常在写完一段代码正准备提交的时候,被一个fail的测试挡住了,然后花了半天时间发现不是他的代码有问题而是测试有问题,结果谁都不太爽
  • 不要把大量的end to end测试放在pre-commit里面跑,想一下让你跑10分钟测试才能提交代码,你能不抓狂吗?
  • 要让开发写测试,而不是测试工程师写测试。这样做的好处是开发自己了解测试代码,可以自己修改测试,更新测试,而不需要等测试来做修复。另一方面,产品质量真的不是测试工程师能保证的,大家测才是真的测
  • 不要在刚开始的时候就添加过多的测试,少量的测试总是比较容易跑过并且让大家接受
  • pre-commit测试不是万能,千万不要生搬硬套

TestLink和BugZilla集成中的一些问题

前两天有个朋友写信给我问一个testlink和bugzilla集成的问题,从他信里面的描述得出,他已经成功把这两个系统集成好了,但是有一些功能用不了,例如不能显示bugzilla里面的id、状态、标题信息等。其实原因是testlink的作者只实现了bugzilla集成的部分接口,其他的接口是要我们自己来写的。大家可以浏览一下testlink安装目录下的/lib/bugtracking,里面有好些文件,其中文件int_bugtracking.php是testlink和其他所有bug tracking系统(bugzilla, jira, mantis等)做集成的基类。还有一个文件叫int_bugzilla.php,这个文件就是testlink和bugzilla集成的代码,里面定义了一个类:bugzillaInterface,它是bugtrackingInterface的子类,并且在类bugzillaInterface里面重写了一部分方法,这也是为什么如果我们自己不修改代码的话,只能用到部分功能(例如只能连接,但却不能显示相关的信息)。

假如说,现在想在testlink关联bugzilla的一个bug之前,验证一下bug id是否存在,就要在int_bugzilla.php里面重写checkBugID_existence方法。

$query = "SELECT bug_id FROM {$this->dbSchema}.bugs WHERE bug_id='" . $id."'";
$query_results = $this->dbConnection->exec_query($query);
if ($query_results && ($this->dbConnection->num_rows($query_results) == 1))
{
    return true;
}
return false;

如果要自己补充这个int_bugzilla.php的时候,需要一点php的知识,并且对bugzilla数据库有所了解,以前公司的同事告诉我用php的一个神器,vardump。你懂的。

开发人员与测试人员比例

上周末去参加了第二届(杭州)互联网测试技术交流会,下午结束了以后有个小型的交流会,会中淘宝的郭芙在自我介绍的时候提出了一个问题,就是开发人员与测试人员比例多少才是合适的呢?这个话题引起了各位嘉宾们的踊跃讨论,infoQ的泰稳整理了这次讨论(推荐看1楼回复),我也想谈谈自己的一些看法。

其实算上实习,我已经在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传统),人员素质在同一个水平,等等。。。在这些前提条件下,如果发现自己的所在的组织的效率不如其他公司,可以参考同行有什么好的实践,取其精华去其糟粕。

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

C/C++代码覆盖工具gcov与lcov入门

gcov是一个可用于C/C++的代码覆盖工具,是gcc的内建工具。下面介绍一下如何利用gcov来收集代码覆盖信息。
想要用gcov收集代码覆盖信息,需要在gcc编译代码的时候加上这2个选项 “-fprofile-arcs -ftest-coverage”,把这个简单的程序编译一下

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的目录下,就可以看报告了。

Continue reading “C/C++代码覆盖工具gcov与lcov入门”

内部自动化测试交流有感

上周公司组织了一个交流会,主题是关于自动化测试,这个已经在公司引起高层们足够重视的话题,说是交流会,其实我更觉得是个成果展示会,本人代表CORE QA跟大家分享了一下我们组内自动化测试的一些情况,并且在做的过程中的一些经验。我是第一个,下面是VI的自动化测试,VI主要是跟Video播放器结合的比较紧密,最后是UI同事的介绍。我从头到尾都参与,所以说说的我感受吧。

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作为对象的识别并不是一个好的选择

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

TestLink不能连接BugZilla的解决办法

TestLink是一个基于Web的PHP开源测试管理系统,虽然用起来跟QC那些商业软件比起来不是那么爽,但是由于是开源、免费,所以越来越多的公司在用TestLink。BugZilla作为老牌的bug管理工具,同样有着很大的用户群。

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

谁来保证测试工作的质量

在一个公司或者是某个组织里面,测试人员扮演的角色通常都会被认为是软件质量的保证者,把关者,仿佛经过测试的产品都是没有任何缺陷的。但事实大家都知道,即使经过多么“完美”测试的产品,总免不了在发布以后还会发现或多或少的问题。

以前在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. 互相监督

敏捷测试只是手段不是目的

首先我要声明:本人不懂敏捷测试。
敏捷开发在这两年一直很火,很多时候作为一个测试人员,经常会“被敏捷”。一些常见的现象有,当你所要文档的时候,相关人员可能会告诉你“我们是敏捷开发,没有文档”;当你索要进度表的时候,答案也是相似的。既然软件开发已经迈入了敏捷时代,那么软件测试还能原地踏步麽?那什么是敏捷测试?我不知道,不过我想说说我在“敏捷”组织里面进行软件测试的经历。
由于我不懂敏捷测试,所以我不知道它的定义,我只能通过“敏捷测试不是传统测试”这样的思路来开展工作。
首先,那种拿着各种需求文档设计文档来设计Test Case的日子是一去不复返了,因为敏捷开发强调的是能工作的软件比漂亮的文档要有用,人和人之间的沟通胜于文档。所以作为我,一个测试员,我对被测软件的知识的了解来源有2个方面,第一是代码,第二是开发人员。
其次,如果在测试过程中发现一个问题,第一件事情并不是把这个问题记录在Tracking system里面,而是找相关的开发和产品进行确认,究竟这是不是一个真的Defect。
然后,需要知道一个现在很流行的新玩意儿:探索性测试(Exploratory Testing)。每个人对Exploratory Testing的定义都不一样,最近两个大牛(James Bach, James Whittaker)也在掐架。我觉得如果简化这个定义的话,就是我们一边熟悉被测软件,一边进行测试,在测试进行的过程中,随着对软件的熟悉,继而设计出新的Test case来对被测软件进行测试,我个人觉得就像是一个小的迭代一样。
最后,忘记敏捷测试这个词。我觉得现在业界能说清楚这个概念的人很少,所以没有必要在这些定义上纠结。人们为什么要实施敏捷开发,是因为想交付更好的软件;我们为什么要实施敏捷测试,是想提高测试的质量以及生产力,从而帮助公司交付更加高质量的产品,至于是不是真正的敏捷,又有什么重要的呢

窥探云测试

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

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

推荐阅读: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(哎,要翻墙才能看)发表文章