爸爸今天又换了一个陌生的女人

一个感人的故事，希望大家喜欢！

怎样成为一个合格的测试工程师

前段时间和几个测试朋友聊天，说到06年上半年测试界的新闻，我想最大新闻莫过于智联招聘网站的一个测试行业的调查报告吧。
该报告指出“目前测试从业人员不会超过5万，合格的测试人员不会超过3万，而工作超过5年的更不会超过1万”，姑且不说数据是否准确（据我经验，应该八九不离十）。单在这里说说怎样才算是一个合格的测试工程师，怎么才能成为一个合格的测试工程师。

首先说说怎样才算是一个合格的测试工程师。

一个测试工程师应该具备的素质我想在很多介绍软件测试的书里已经都列举过了，这里就不在重复，而一个合格的测试工程师和一个测试工程师的最大区别在哪儿？不外乎就在与测试思想。合格就在于他接受到测试任务后所做的第一件事情是想而不是做。合格就在于他将他自己的想法始终贯穿于整个测试中，包括测试设计中，测试执行中，测试分析中。

许多人都会说测试思想是一个空洞的东西，而我也曾经写过或说过太多的例子用以证明它，这里只建议想做合格测试工程师的人去看一本书吧，它的名字是，在我眼里，它并不是一本讲技术的书，同时它也并不只适用于开发人员。

接着说说怎样才可以成为一个合格的测试工程师。

不是有一个玩笑说某某公司扫地的大妈都可以做软件测试，某某公司看门的大爷都可以做软件测试。由此可见人们对软件测试的误解和测试工程师的尴尬。其实并不是任何一个人都可以成为测试工程师的，其实并不是任何一个测试工程师都可以成为合格的测试工程师的，要想成为一个合格的测试工程师，你必须有血有肉还的有思想。技术没有可以学，思想是学不来的，思想是需要实践的。毛泽东思想也不是他老人家凭空想象出来的，你说是否？

于是我建议大家：
1.每半年读一本测试书籍（现在的测试书籍也多起来了，尽管很多都是东抄西抄的，能力够的话去读英文原版，译本基本都不能完全领会作者的思想，人家老外的测试发展要比我门多几十年呢

2.每半年学一门测试技术（IT行业变化很快，测试技术也同样，每年都有新的测试技术出现，不希望大家对每一个新出现的技术都掌握，只希望每一个测试人员对本人从事的这个行业要充分了解和熟悉，因为在你现在和将来测试的项目中，你要选择最合适和最有效于这个项目的测试技术，如果你连所选对象都不知，那谈何选择，又谈何合适呢？）

3.每半年学一门IT技术（这里的IT技术范围要更广一些，做测试人员要了解更多的知识，如你做性能测试，你需要了解操作系统，你需要了解软件架构，你需要了解低层实现，你需要了解中间件，你需要了解数据库，你需要了解他们的配置与实现方式，你还需要了解硬件，了解网络，了解内存管理机制，了解磁盘I/O原理等等）

4. 要学会思考（测试人员要学会在测试前思考，测试中思考，测试后思考，思考的结果要记录下来，每有一个人敢说他自己是天才，可以记住所有的东西。想好后那就去做吧，去验证吧，如果不对，那返回重新思考，然后再去做，只有这样，你才会做的更好。）

5.要重视测试设计（某开发人员曾说过他精通JAVA，精通C，我于是和他说，那给你10年或20年，你用你精通的JAVA来写出一个可以替换WINDOWS的操作系统。他从此不在这样说，因为他知道即使给他一辈子，这对他也是一个梦。测试何尝不是，你测试技术再高，你也不可能测试的更好，重视测试设计吧，这才是测试之关键。）

6.多和测试同行交流（在一个封闭的圈子里，或在一个公司里，你觉得你是测试高手，当有一天你走出这个封闭圈子的时候，你才发现，天外有天，或许捆饶你一个月的难题某些测试同行轻描淡写的一句话就可以为你解决。测试是相通的，测试思想更是相通的，多去做一些比较，才可以看到自己的不足。）

我是崇尚测试技术的，所以相信，尊重源于实力！因此希望更多的测试人员能得到测试同行的尊重，能得到开发人员的尊重，能得到企业的尊重。
同时我更崇尚测试思想，所以我更相信，在软件行业更加规范化后，企业对测试工程师的要求必定是测试思想第一，经验第二，而测试技术只能排第三了

用别的眼光去感悟软件测试

曾经对软件测试很轻视，因为我那时很无知，只是一名普通的中国程序员，这也是那时绝大多数程序员的心态，那时中国程序员最讲究“编程才是硬道理”。

如今却非常热爱软件测试，包括软件测试工具，方法，理论，技术。因为我在3年的测试工作中，深刻体会到软件测试的重要性和趣味性。此时，我已经跳出了“小程序员”的圈子，以软件系统工程的更大视角审视软件测试这项工作。

很长时间以来我一直被下面的问题而困惑，有些问题至今仍然只是具有肤浅的认识，而且，我感觉我做的测试项目越多，阅读的测试书籍越多，我越感到我对软件测试理解的越肤浅。因为我越来越感受到软件测试的广度和深度的无限性，它像大海宽广，像宇宙那样深邃。为什么要进行软件测试？软件测试的前途如何？软件测试的工具和思想谁更重要？软件测试的最高境界是什么？

软件测试是保证软件质量的重要活动，是软件项目实施的不可缺少的环节。软件测试的直接目的是发现软件中存在的缺陷。此为测试的有效性。

在软件项目没有结束之前的全部软件缺陷主要由软件开发人员负责，因为软件缺陷来自程序员的编程。软件项目结束后的软件缺陷主要由软件测试人员负责，因为软件测试人员没有在软件发布之前的测试中没有发现隐藏的错误。但这不是绝对的，因为软件项目是一个系统工程，软件质量牵扯到多个部门和人员，以及需求分析，设计，编码等各个环节和过程。软件测试只能证明软件存在缺陷，不能保证软件没有错误。

软件测试不是万能的，因为不可能发现全部的软件缺陷，而且软件的功能和性能不是由测试决定的。此为测试的有限性。

软件测试目前主要以手工测试为主，自动测试工具虽然很多，但实际应用的广度和深度还有很大潜力，自动将有很大的发展空间！。

软件驱动开发的观点说明了测试与编程的关系，测试应该贯穿于软件开发的整个生命周期，编程只是软件开发的一个环节。但往往大家非常重视软件编程，把测试作为编程后的一个辅助环节。这是典型的本末倒置。软件测试的缺陷管理流程非常重要，报告的软件缺陷的质量，应该由他人验证，做到责任明确，方法简便可行。

软件测试技术不断进步，但总体来看，国内的测试重视程度还不够，但已经发展很快。差不多两年之前，国内计算机书店中关于软件测试的书籍非常稀少，如今却琳琅满目，异彩纷呈。

软件测试是个可以很快入门的职业，门槛不高，但是，不要认为什么人都可以做好软件测试。因为会做和做好是两个概念。软件测试人员最好具有软件开发经验，理解软件工程的知识。这是提高软件测试能力的基础。对于刚刚毕业的学生，如果希望今后从事软件开发，那么，先从事一段时间的测试可能更有利于今后的编程。而对于具有多年编程经验的程序员，如果改行做测试，更容易提高技术。 软件测试不是孤立的活动或过程，需要开发和市场人员的参与和交流，需要软件质量保证人员SQA的积极配合和沟通。

软件测试的技术不断进步，与具体测试技术相比，掌握测试的核心思想比具体技术更重要！测试的最高境界在于运用最简单有效的测试技术，最大限度的发现软件缺陷!

应当承认，目前国内的软件测试工程师的地位和待遇仍然很低，而且不少测试人员存在浮躁的心态（我甚至感到整个软件行业始终存在着浮躁的泡沫）。如何改变这种局面，这应该是个漫长的过程。当整个IT业真正以客户为上帝时，当软件质量成为决定企业生存和发展的决定因素时，当软件测试工程师的测试工作给软件企业带来更大的经济效益时，软件测试工程师才会得到应有的尊重！

软件开发是一项复杂的、创造性的协作式游戏。作为游戏它自然存在着乐趣，所以程序员们才会乐此不疲，前仆后继。首先、这种快乐源于一种创造事物的快乐。其次、这种快乐来自于一种开发出对别人有用的东西时所带来的满足感。第三、快乐源自开发过程中，亲眼看到软件按自己预先设想的那种效果运行时所带来的迷人魅力。第四、快乐源自开发过程中持续学习的快乐。最后、快乐源自开发过程中，我们能象诗人一样，仅凭自己的想像，来建造自己的城堡时带来的快乐。编程的快乐在于它不仅满足了我们内心深处进行创建的渴望，而且还唤醒了每个人内心的情感。不幸的是，同样作为游戏它也有苦恼的一面：首先、苦恼来自追求完美主义。其次、苦恼来自总是由他人来设定目标、供给资源、提供信息。第三、苦恼来自于寻找琐碎的BUG却是一项枯燥的、重复性的活动。第四、人们通常希望在项目接近结束时，能收敛得快一些，然而，情况却是越接近完成，收敛得越慢。最后、苦恼来自当投入大量的辛苦劳动后，产品发布时却面临着陈旧过时的危险。作为软件开发者，我们别无选择，只有适应它们，就这样痛并快乐着地面对每一天。

来自领导的信息只有25%被下级知道并正确理解，从下到上的反馈信息不超过10%，平等交流的信息则可达到90%以上。平等造就信任，信任增进交流。有效地进行适当的意见交流，对一个组织的气候和生产力会产生有益和积极的影响。使顾客满意并和他们面对面地交流，才是蠃得市场的关键。

管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是"遭受损失的可能性"，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：

第一、风险识别：

从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。

第二、风险分析：

对风险出现的可能性和潜在的危害性进行量化分析。

第三、应急计划：

如果识别出的风险真的出现，你将采取的应急措施。

第四、风险缓解：

为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。

第五、持续的监控：

跟踪需要管理的风险，寻找风险出现的迹象。

项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：

第一、缺乏合理的进度安排

这是导致项目滞后的最主要的原因。

首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。

第二.它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。

第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。

最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。

第二、需求的变化
从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。

第三、人员的变更
在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。
另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。
同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。

第四、规约崩溃
这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。

第五、低效率

对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。

正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。

精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。

企业的最大风险则与价值相关：在低价值的项目上浪费资源，付出高价值的机会成本，就这是企业最大风险。勇于承担风险是好事，但必须由收益来导航，愿意承担多少风险，必须取决于能获得多少收益。真正的项目评估不是倾向于不断削减成本，来提高价值，而是在风险与价值之间取得平衡点。通过不确定的价值和不确定风险组合效果的净收益图，来指导你把资本投入到最适当的地方。我们每个软件从业人员都必须明白：顾客真正需要的，是我们能够给他的、某种他想得到的利益

软件测试工作心得－“热情”加“思考”

干测试也有一年多了，偶尔也会静下心来思考一些问题，但很多思考的结果都似灵光一现——过后就忘掉了，实在可惜，以后就记在这里吧。

　　技术类思考

　　软件工程的任何一个部分——从需求分析、架构设计到最后的Debug——都能引入Bug，有时候是单个引入，而有时候则是一窝一窝地引入。所以，优秀的测试员理应掌握丰富的软件工程知识。很难想象一个不懂材料力学和结构力学的工程师能够验收刚刚建好的大厦。

　　测试员不但需要学习编程，而且需要学习各种编程。初级测试员可以站在用户的角度上去观测和使用软件，以期找出Bug所在，但高级程序员更需要借助程序的原理来剖析更深刻的东西。毫不夸张地说：如果想深度测试Web程序，你应该学学Hacker;如果想研究.NET的程序，你应该学会MSIL;如果想深度Debug原生代码，你应该学习汇编、了解PE文件格式;如果想深度测试软件的安全性，你应该学学破解;如果……总之，理想的测试员应该比程序员更深一个层次。

　　保持对软件的喜欢和热情。小到FlashGet大到3DS Max，如果有机会都要上手玩一玩。这样做好处多多，一来可以丰富你的软件使用经验、无形中建立你对软件逻辑的把握;二来丰富你的行业软件知识，比如你让一个长期测Outlook的人去测Photoshop，那测试出来的结果肯定和一个长期使用Photoshop作图的人测出来的结果相去甚远。

　　深入理解操作系统，包括Windows系列(包括.NET平台也可以理解为是操作系统的一部分)，Linux系列(JDK算是操作系统的一部分)，Macintoch系列。一来，软件其实就是扎根在操作系统上的树木和花花草草(通过系统开放给程序员的API与系统血脉相连);二来，很多软件是跨平台的，要求你有丰富的多平台操作经验才能玩转，比如Adobe公司的很多优秀产品就是跨Windows和Mac平台的，这两个平台的API完全不同，为什么软件“看上去”却一模一样呢?再比如IBM公司的很多产品是跨Windows和Linux平台的等等。

　　行为类思考

　　软件测试不是万能的，所以测试员也不是万能的。测试员不是救世主。这至少说明两个问题：一，一个设计很烂、编码很烂的软件，你再怎么测试它也成不了优秀的软件。二，测试员(或者说软件质量保证人员)没有权利在团队里趾高气扬、四处挥动粘满Bug的大棒以图通过测试结果证明自己的英明神武——大家都是平等的。平等的观念在中国人的思想中尤其缺乏，特别要注意。

　　测试员应该是一个冥想者。所以，测试团队应该有一间独立的，安静的，没有计算机的屋子，以供进行深度而缜密的思考。

　　管理类思考

　　不要不懂装懂。你不懂不会，不足以让组员瞧不起你;你不懂装懂，所有组员都会瞧不起你。管理就是管理，是把项目做好，不是让你练擒拿格斗，一定要制服组员。勇于上问、不耻下问，快速学习，这才是团队学习之道。

　　作为Lead，如果没什么重要事情，到点就走人——不然你的组员会碍于面子而陪着你。你有没有想过他还有可能要陪父母、妻子和儿女呢?如果你经常这么干，建议你看一看《二十美元的故事》这则小寓言。

　　要做权威，不要做学霸。我想说的是：下属进谏的速度和广度决定于你的心胸与宽容度。正因为大多数初级管理人员心胸狭窄、宽容度低，才导致了团队习惯性的“绝对上下一致”。据我所知，印度程序不是这样的风格，属下和领导、新手和权威可以心平气和地讨论分歧而不必面红耳赤。我的建议是：在团队中，不要等级观念，要平等;不要讽刺刻薄，要尊重;不要放不下架子，要宽容;不要目中无人，要谦虚。总之一句话：大家都是普通人，谁能跟谁差哪儿去呢

我为什么雇佣家庭主妇做软件测试

软件测试是一门非常崭新的学科，目前研究的内容还不很深入，所涉及的只是测试数字、测试函数等一些非常简单的问题，可以说还处于婴儿阶段。当前，软件测试作为一个成长中的专业，在美国已经有大学开设。由于软件测试学科还不成熟，到底它需要一个什么样的专业基础，尚无定论，而且目前还没有一种很好的标准来衡量一个测试人员的优劣。陈宏刚博士以微软公司为例为我们讲述了软件测试的方法。

　　软件测试工程师：其职能是理解产品的功能要求，然后对其进行测试，检查软件有没有错误（Bug），决定软件是否具有稳定性（Robust），并写出相应的测试规范和测试案例。

　　国内的一位博士到微软总部参观之后，觉得非常奇怪：“测试人员是做什么的？为什么微软在做产品时，测试人员占了一半以上？”其实，软件测试在产品开发中占据相当重要的一部分，这是一种需要，是微软从二十几年的实践中明白的道理，也是微软从不断的失败中总结的经验。

　　大家可以感觉到，微软以前的产品有时会发生崩溃、死机等现象，而今天的产品则比五年前的产品更大、更完善，并且要稳定得多。为什么呢？这是因为测试工作越来越好，测试人员越来越多，而且越来越有经验。关于这一点，微软公司曾经算过一笔账：最初，微软公司与大家一样，认为测试不重要，重要的是开发人员。通常，一个团队中有几百个开发人员，但只有几个测试人员，并且开发人员的工资比测试人员高很多很多。经过多年的实践公司发现，为那些出现问题的产品再去修一个补丁程序所花的钱，比多雇用几个测试人员的费用要多得多。

　　但是，软件测试到底是一门什么样的科学？没有人知道，大家只是在摸索。它需要什么样的背景，也没有人知道。所以，微软的测试人员中，只有很少一部分是从计算机出身的，其余的有学俄语的、英语的、数学的、工程的、生物的……种类特别多，但有一点：测试人员一定要有一种感觉。

　　由于现在的软件测试仍然处于发展阶段，往往测试人员还是依据本能、靠感觉、靠天赋来做软件测试。如果像用户那样只是通过使用来发现Bug不是真正的测试，这只是一种最基本的测试，你只能发现一般用户的问题。

　　最后，我以一段有趣而又真实的故事来结束这篇文章。

　　我在微软总部做测试组长和经理时，经常需要招聘测试人员。我招聘人时通常会遵循两个原则：一是要看他的逻辑性，这是非常重要的一点；二是要看他的思维是否怪异，是否能经常产生一些怪点子。第一点是可以依靠后天培养的，但是第二点恐怕是后天培养不出来的，多少有些天生的因素在里面。

　　这两个原则是我在多年的实践中得出来的。由于软件测试学科还不成熟，目前还没有一种很好的标准来衡量一个测试人员的优劣。而且它到底需要一个什么样的专业基础，尚无定论。从目前来看，并不是说学计算机专业的就最适合做软件测试人员。

　　说起来也许大家不会相信，我曾经亲自招聘过一位家庭主妇来做微软的测试人员！

　　这名家庭主妇已经四十多岁了，是一位海军军官的妻子，三位孩子的母亲。她只读到高中毕业，连大专也没有上（在美国没有上过大专的人是很少的）。她使用计算机的水平也非常初级，而且还是跟着自己的女儿学的。后来她在家闲得无聊，就决定出来找一个工作，而且居然跑到微软来应聘了。

　　当时，我在面试她的时候就已经发现她的计算机水平很有限，只能达到一个一般用户的标准。但是，我发现她的思维很怪异，怪点子很多，能够很快地发现一些问题。于是，我就随便让她试用一下IE，结果她当场就给我找出了好几个Bug。她完全是凭着一种感觉来找Bug的。

　　后来，我对老板说，我想雇用她。老板一听，睁大了双眼：“Are　you　crazy？You　want　to　hire　a　housewife！（你疯了吗？你居然想雇用一个家庭主妇！）”

　　于是我跟他说了一下我的想法。他还是觉得让一个大学都没有上过的家庭妇女做测试人员是不可思议的。但是，最后他还是说：“You　are　the　hire　manager.You　make　the　decision！（你是招聘经理，还是你自己来决定吧！）”

　　我最终决定还是雇用她。在开始阶段，她的确存在许多问题。我只是认识到她的感知力很强，却忘了她的其他素质如何。由于她一直做家庭妇女，没有在职业环境中待过，因此显得很粗鲁，经常大声喧哗，利用办公电话到处大声打电话，在办公室里抽烟，而且还经常逞能，走到别人后面得意地告诉别人：“I　just　found　a　bug！（我刚刚找到一个Bug！）”，好像别人都发现不了Bug。但是，后来我警告过她以后，她就努力改正了这些毛病，并非常认真敬业。她学得非常快，三个月以后，就已经非常专业了。最后，我的老板终于承认她真是非常厉害，并将她转为了正式职员，现在她恐怕已经成为测试组长了。

　　从这个例子可以看出，做一名好的普通测试人员并不需要某方面（如计算机）的专业基础，我们不能像评价开发人员一样依照常理来评价测试人员。开发人员肯定需要专业基础，但是测试人员有多种，如做IE的一些手工测试（Manual　Test）就不需要任何专业基础，他们是在以用户的身份使用（甚至乱用）产品并从中发现问题。那位家庭妇女就具有这方面的天分。我当时也招聘了一些学生物、物理专业的博士，但他们做得并不怎么样，远不如这位家庭妇女干得好