编者按：本文是作者在2006年测试人员招聘会上的亲身经历。或许这个题目涉及范围太大，打击面太大，本可以加上一长串的修饰语，来缩小这个圈子，也完全可以保持沉默。但作者身为测试届中青年一代，认为自己有责任提出自己的观点，大家有则改之，无则加冕。从作者的亲身经历中我们可以看得出，国内的测试界确实还需努力。

　　我面试的测试应聘人员大多是有一定从业经验的测试人员，其中不乏优秀者，但是也有相当多的应聘人员反映出这样那样的问题，概括说来就是“浮躁”，具体拆解来看主要表现在以下几点。

一、根基不牢

　　问题：利用等价类划分的方法，对某问题设计测试用例。

　　分析：98%以上的应聘者只知道按照有效等价类和无效等价类进行划分，殊不知此种分类方法只是等价类划分的一个典型应用而已，等价类划分远非只能划分为有效和无效两类。根据种种划分依据，还可以进一步划分很多其他类别。

　　问题：根据事件描述，画出对应的因果图。

　　分析：标准答案中只画了“两条恒等，两条非，一个与，一个或”。如此简单的问题，上百名应聘者中竟然无一人答对，痛心啊。黑盒测试方法就那么几种，既然你已知这个名，怎么就不知道多看几眼。

　　小结：

　　上面提到的是软件测试的最基本的方法，作为从业测试实际工作已经有1-2年的应聘人员，未能真正领悟，实属不应该，心浮气躁，忽视了你身边最简单，也是最厉害的技能。根基不牢，怎么可能把测试做深。

二、专业不精

　　问题：音视频文件都有哪些格式，这些格式之间有什么差别？

　　分析：此问题是问那些做过多媒体方面测试的，但是我们的应聘者向来都是拿来主义，别人给我什么媒体文件我就用什么做测试，而根本不管不问。“为什么MIDI文件比WAV文件小那么多？我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式的？”，面对这些问题，应聘者默默无语，只是无奈的笑笑。不去看别人，想想自己测试涉及的专业，是否把那个行业知识搞清楚了呢？

　　问题：测试脚本运行不畅如何调试？

　　分析：此问题是问那些标明自己熟练掌握WinRunner、Robot、QTP等测试工具的应聘人员，但是当真正问到他们关于脚本的具体调试时，有7成以上人员表示他们只是参加测试培训时老师讲过，或者自己在网上看过相关资料，另外有2成以上人员表示他们虽然用过，但是只是简单的录制回放，根本不会自己调试。可能是迫于无奈吧，简历里面什么都不写，可能面试的机会都没有，但是简历如此夸大的来写，终归是浪费自己的面试时间和路费。

　　小结：

　　从事测试仅1-2年时间，要想测试也精通，专业也精通确实不易，但是不说精通，至少也该知道个60%才对的起你的测试工作。一两年时光如此荒废，静下心来反思一下，身边还有哪些技能我们应该掌握扎实一点呢。

三、无测试体系概念，忽视理论

　　问题：请说出软件测试的定义，BUG的定义。

　　分析：99%的人不能说出这两个测试名词的定义，只是在给我解释测试是为了发现bug之类的片面理解，残留的几个人也说得不够准确。这两个词目前尚不能说业内已经有了成熟统一的定义，但是无论是对是错，身为测试人员已经数年，自己竟然说不出这两个词的概念，多少也说不过去啊。有些人和我说，理论名词概念不重要，我会做测试就是了。想想金庸老先生早就告诉我们，武功仅有招式是不够的，必须配合上什么心法口诀才能行。你只会测试执行的招式，却不懂测试理论的心法，怎么能够修炼成上乘的软件测试呢？

　　问题：请介绍一下你们的测试流程，流程和过程有什么不同，为什么好的测试需要好的流程？

　　分析：但凡做过1、2年测试的人都能给我说出他们先做什么后做什么，但是当我继续问“这是否可以叫做过程？流程和过程有什么差别”，应聘者一棒子被打晕，继续追问“为什么好的测试需要好的流程”的时候，早已经找不到东南西北了。每天公司各项制度叫你做什么你就做什么，让你怎么做你就怎么做，完全不管不顾为什么，那么自己岂不成了没头脑的工具。这样你能干的工作别人也能做，自己的优势不就没有了吗。

　　小结：

　　目前测试业内流传着学院派和实践派的说法，学院派的理论给人的感觉往往是好听但不实用，而实践派的知识，往往能够立即见效。所以眼下测试培训往往实践派的更受欢迎。继续引用金庸先生的观点，练武分练内气宗，练外剑宗，但是真正的高手是内外兼修。如果我们不想只做普通的测试小弟子的话，就要理论实践并重，方能有所作为。

四、周边知识知之甚少

　　问题：能给我介绍一下软件工程中的瀑布模型吗？

　　分析：又是8成应聘者不会回答，都是曾在遥远的学生时代有所耳闻，现今早已忘得一干二净了。软件测试因何而生——软件危机，软件危机导致软件工程的兴起，软件工程中又包含软件测试，就好像鱼儿活在水里，如果没有软件工程这个水，哪里能够养活这软件测试的鱼，如果我们对于身边的软件工程不够了解，怎么可能在里面自由的畅游呢。

　　问题：用你最熟悉的开发语言实现sum=1+2+3+…+100

　　分析：保守统计7成以上的应聘者写出来的程序无法执行或者运行结果错误，更少有人能够一气呵成，而且精准。这道编程题难吗？肯定不难，那么为何答错，自己没有真正写过程序，即使写过几行，也早就是如烟往事了。做测试一定需要懂开发吗？这个问题讨论以久，当然不一定，但是如果要做好测试，做深测试，分析问题原因，提出问题解决方案，编写测试脚本或工具，哪一个又能离开软件开发呢？

　　小结：

　　我们学习测试也应该有个先后顺序，有步骤。掌握周边知识的紧迫程度可能不如测试知识和行业知识。但是对于我们已经从业1-2年的测试人员来说，学校里面学到的知识不应该丢，之后的发展中，周边知识的学习也应该开始了。周边知识的范畴其实很广，还包括各种其他测试理念的学习，机械工业出版社翻译的那套测试丛书就很不错，观点众多而新颖，博众家之长，集大成，向来都是大家风范。

五、缺乏必要的责任心、细心、耐心、虚心等

　　问题：请数出下图中三角形的个数（平面图，有几根弧线做干扰）

　　分析：我总是问自己，这道题真有这么难吗？连中小学生都能数对的十几个三角形，到了我们这二十几岁的年轻人手中，正确率才1%，为什么？其实就是现在我们已经很少有人能够静下心来，耐心细致的去做事情了。很多应聘者告诉我她的优点就是“踏实，坐的住，正适合这繁琐的测试工作”。我需要的不是坐在那里不做事或者做错事的人，而是需要能够按时保质量完成测试工作的测试人员。

　　问题：你离职的原因？

　　分析：这是面试中最常见的问题了。应聘者往往也是充分准备，理由多种多样，但是看看应聘者的工作记录统计，70%应聘者平均跳槽频率是1年/次（实习情况除外），不会都那么凑巧吧，赶上什么公司倒闭，每隔一年就会想一次自己学不到东西，需要去外面看看。而在我看来，真正的原因更多的应该是希望通过跳槽提高工资，或者因为自身水平不足被公司炒鱿鱼吧。

　　小结：

　　我并不认为所有的人都适合做测试。非技术素质方面，这点或者那点不足够优秀也很正常，心浮气躁也可以理解。但是作为用人单位，理解归理解，却也不会用不胜任岗位，或性价比不高的人员。那么对于此类应聘者，我的忠告就是，要么你另谋高就，要么你就放低姿态，培养好你必备的素质后再谈。

六、缺乏诚信

　　这一点本应该被归在上一条素质中，但是这点的重要性我认为远超过了上一条所列各项，因此单独提出。相关表现主要体现在：1、虚报自己历史工薪；2、笔试题目作弊；3、编造离职原因；4、虚报学历，工作经验；5、夸大自己工作技能等。对于严重缺乏诚信的，一旦发现，其他表现再好，也无济于事了。

Morgan IT 18万＋bonus，共25万左右

Google 17万9千多 NI 拿到手14万，四金全部是公司交。

 MS atc 15.3万

百度 7000至8500，发14个月，每个季度有4500至6000的奖金。

 美国道富银行IT部 8000至12000，发15个月

浙大网新恒天 9500×15 网易杭州研究院 9000至10000，发14个月

 ask.com 9000至12000，发14个月

IBM CRL (7500+800+900)*12+7500*2.5+3.3万（住房补贴，三年10万，平均到一年。）

IBM CDL (7500+800)*12+7500*2.5+3.3万

 nVidia 测试8000×15，研发10000×15，有期权。 (另一说9000×13，有期权)

Trilogy 16万左右上海威盛 7500×13，不再提供宿舍

杭州威盛 6000×13

UT斯达康 6500/月，福利不错

腾讯 7000×13，年终奖金15000，但是没有住房公积金

 MicroStategy 杭州职位每月12000，14个月，美国职位待遇不详

泰鼎 8000×13，年终奖2个月薪水左右

北京瞬联 9000至10000×12，第一年有10000元安家费

上海展讯 6500至7000，发14－16个月，有期权

 Intel 8000×13，加上一些乱七八糟的补贴

华为 5500+1000，年终奖不定，几千到几万都有可能。

中兴 8－10万

摘要：

测试人员越早介入项目工作越好的观点已经被越来越多的测试人员所接受。在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵的论断也已经成为了大家的共识。

测试人员需要参加需求评审，我想大部分测试人员都接受了这个观点，同时也是这么做的。但测试人员为什么需要参加需求评审，恐怕不是每一个人都知道个中道理。本文从作者多年从事软件测试和过程管理的经验出发进行论述，供同行们参考。

关键词：

测试  测试人员 需求评审

正文：

我们知道，在项目的生命周期中，需求、设计、编码、测试等活动往往是由不同的专业技术人员协同完成的。这样，由于下游技术人员对上游技术人员工作产出物的理解偏差，将导致不同阶段的产出物之间不一致的现象出现，这也是导致项目可能不成功的重要风险之一。

基于以上的观点，需求人员编写的《软件需求规格说明书》、系统设计人员编写的《系统设计说明书》、编码人员实现的系统、测试人员编写的《测试用例》之间不可避免地存在不一致的现象。

由于测试工作的主要面向对象是《软件需求规格说明书》和可运行系统，为便于分析，我们先用图来表述一下三者之间的关系：

从理论上讲，上图中“需求”（S圆表示）、“可运行系统” （P圆表示）和“测试用例” （T圆表示）应该是重合，但实际上这三个圆很难重合。

从上图可以看出：可能会有没有测试到的已描述行为（区域2和区域5）；经过测试的已描述行为（区域1和区域4）；对应未描述行为的测试用例（区域3和区域7）；可能会没有测试的程序行为（区域2和区域6）；经过测试的程序行为（区域1和区域3）；对应于未通过程序实现的行为（区域4和区域7）。

由于我们今天讨论的主题是“测试人员为什么需要参加需求评审”，因此我们重点来看看与这一问题关系密切的区域2和区域5、区域3和区域7。

区域2和区域5这两部分是测试用例没有覆盖到的需求，即“没有正确的测试用例与该部分需求对应”。出现这种情况本人认为有三种可能：

1、                设计测试用例的测试人员对需求理解不完整，出现了应该被测试的需求而没有被测试用例覆盖到的现象；

2、                《软件需求规格说明书》中区域2和区域5对应的需求，具有不可测试性，测试人员无法设计用例；

3、                《软件需求规格说明书》中区域2和区域5对应的需求，不是用户的需求，是需求分析人员凭空增加的，测试人员无须设计与这部分需求对应的测试用例。

区域3和区域7这两部分是需求没有覆盖到的测试用例，即“没有正确的需求与该部分测试用例相对应”。出现这种情况本人认为有两种可能：

1、设计测试用例的测试人员对需求理解不充分，从而设计出了多余的测试用例；

2、《测试用例》中区域3和区域7的测试用例所对应的需求，是用户的真实需求，只是《软件需求规格说明书》中没有描述到而已。

从上面的分析可以看出，如果测试人员参加了“需求评审”，则上面出现的问题可以最大程度地避免，因为测试人员参加“需求评审”的重要作用正是针对产生这些问题的因素而进行的。

由此总结出，测试人员参加“需求评审”活动所需要达到的目标包括如下三个方面：

1、充分地理解需求，确保对需求的理解与需求分析人员是一致的；

2、从可测试的角度，努力发现《软件需求规格说明书》中不可测试的需求，从而提醒需求分析人员尽早修改；

3、从测试人员的角度努力发现《软件需求规格说明书》中的不完整性，从而提醒需求分析人员及时补充遗漏掉的这部分用户需求。