1.以前作过开发,而且很牛.并且精通测试.
　　2.对软件的业务流程非常熟悉而且了解开发的实现机制,并且精通测试.

　　作为前者,我们没个几年的开发经验基本上不可能作到，都是开发和测试里面的大牛.对我们现在来说有点不符合实际．而后者应该是我们努力的方向,经过1-2年的测试基本上就能够非常熟悉公司的软件产品,在我们实际的测试过程中,不要满足与只是软件表面的业务流程,而且要多和开发人员交流,多多了解软件的实现机制.

　　软件的实现机制,无非就是通过各个开发技术来实现的.所以当我们学到相应开发的时候,重点关注的应该开发语言实现某一功能的实现机制.比如说你学到了XML,你要关注的不是简单的几十行代码,你要从整个XML的实现机制上来了解XML。
 
　　在说这个图之前你需要知道XML中主要包括１．XML文档声明２．关于文档的类型定义．（即验证自定义标签、元素之间关系的合法性）３．用XML标签创建的数据内容．（这个就是下面我们所说的数据）

　　在IE中使用XML，有一个好处就是实现数据和显示分离，XML中存储数据，而HTML利用DOM对象调用XML中的数据来显示．这样实现个过程是这样的：XML中存储数据，而CSS呢是对XML中的数据进行格式排版显示，通过JavaScript对XML数据元素的操作不能够直接进行，他要用到系统提供很多编程接口，也就是DOM模型，DOM模型实现XML数据和Javascript之间交流的平台．最终在IE中显示的是HTML调用XML中的数据和Javascript对数据操作后的结果．

　　理解了XML整个实现的机制后，如果程序不能实现把King Leer变成红色，你说这个缺陷是哪个模块产生的？这个肯定是Javascript的问题．

　　呵呵，这就是了解了开发技术实现机制的一个最大的好处．公司的软件的实现机制，就是现有的各种开发技术实现机制的一个混合体．各种开发技术我们肯定不能都精通，但如果我们知道它们的实现机制，这个时候对于找到缺陷产生的原因是莫大的好处．

从一月份到现在，面试了二十个左右的研究生，满意的很少，我开始去思考，到底是自己的要求过高，还是自己的面试方法有问题，抑或真的是现在的研究生的素质越来越低了？

我理想的人选，首先，我希望他对测试感兴趣，有测试的感觉，测试并不是一件很有创造性的工作，但其中的乐趣，是很多coding高手所无法体会的，但需要发现其乐趣，必须要喜欢上测试，才会更有效地发现软件存在的隐藏问题。其次，我希望他有一定的技术基础，对于在校的研究生的技术水平，我的要求不高，只需要掌握最基本的SQL语句，会简单得Linux命令，懂得用Java或C写一个简单的程序，这些知识，是需要在项目中使用到的技术，同时也是学校的基础课程上的东西。最后，是他的态度和性格，我希望他是一个责任心很强、具有良好沟通能力和团队精神的人，测试根软件开发最大的不同是，开发工程师可以只关心自己所负责的模块或功能，而测试则要把握全局，需要跟不同的人去沟通，发现问题需要协助不同的人去定位和解决，测试是一个团队的工作，我希望招聘进来的人，能够很快地融进我们的团队中，谦虚地学习，踏实地工作。

我的这三个要求，似乎真的很高，因为当我以这三个标准去衡量我的candidate的时候，我总是满怀希望地开始跟他们交谈，而又失望地与他们告别。首先是笔试的题目，至少有一半人，最基本的SQL和Linux命令都是没有把握地写进卷子的。“这份题目你觉得怎样啊？”我笑着问他们。“都是在学校学过的，不过忘记了，只要给我时间，我很快就会学会的。”果然都是名牌大学的研究生，那样的自信。“我们的工作要求有一定的JAVA/Oracle/Linux技术基础，如果给你时间，你要多长时间可以掌握呢？”“一两周就可以了。”“我们的招聘要求里面有些清楚这些要求吗？”“有。”“你从发简历到面试，大约多长时间了呢？”“两周左右。”“那你为什么不利用这两周把招聘要求中的技术都好好温习一下呢？”我仍然笑着问，只是接下来大多都是沉默。我发觉这个问题，真的能问倒所有人。其实，我不是想为难他们，只是，他们都是名牌大学研一或研二的学生啊，这些基础我当年大学三年级就已经可以灵活运用了，这些命令我也经常会忘记，但是，每次自己去面试之前，都会花些时间认真地复习一下招聘要求中的技术，有备而战。其实，我想看的是这个来面试的人，是否在来之前有认真地准备，我只是想看他对这个机会的态度。插一条记录到数据库中，居然有人用add，真叫我心疼！同事批评我说，别总拿态度来作要求，只要你给他培训两个月，什么技术不会？用add还是用insert into有什么关系？只要他足够聪明就可以了。态度真的不重要吗？我真的不需要他们有技术基础吗？他们真的可以没有任何基础就进来，这些技术，我两周的培训就可以让他们掌握，只是，他们的态度，我没信心让他们在两周之内扭转。当他们可以很高效地干活的时候，恐怕他们又要马上回学校去了。如果我培训的成本，已经远远高于我自己做的成本，那么，我宁愿自己辛苦一些。不要怪我以态度作为评判的准则。

简历，是用人单位初步刷选的一份资料，有些简历看上去就像一份草稿，或者是所展示的资料并不符合我们的要求，通常我们都会放弃进一步去了解。有些人的简历做得很漂亮，好像什么都会，而且还有很多的项目经验，看上去似乎很有吸引力，但简历给人的印象未必就是真实的。每个公司都希望招聘进来的人可以有一定的项目经验，因为这意味着他们一进来就可以给公司干活了，可以节省很多的培训成本。我也喜欢有项目经验的人，我还很喜欢跟他们聊他们曾做过的一两个项目，因为在在这个互动的过程中，你可以看出他的思维、表达和技术。简历中的项目经验可以是假的，但在面试的时候就不能假了，在面试过程中的交流足以让我们判断出这个人的技术水平和思维能力。很多人，在简历中写着正在做的项目或一两个月之前做的项目，当我们问他有关系统的框架或某个功能的流程时，表达起来却是不够清晰，再深入一些去追问，回答就差强人意了。我在想，是因为他们不善于表达，还是他们本身没有深入理解过自己所做的项目，甚至是自己根本上就没有这些项目经验？企业或者也应该思考一下，是否应该给没有项目经验的人一些平等的机会，以免他们投其所好，将简历粉饰得很漂亮，但事实上又没有那样的真实。我可以理解他们，因为简历写上如果连项目经验都没有，可能他们就连面试的机会也没有了，只是，有了面试机会，但如果没有把握这个机会的实力或者没有做好把握机会的准备，有了也是白有。

我最看重的，是这个人是否具有测试的感觉以及兴趣，我希望他对自己的发展和选择是清晰的，我希望他能清楚自己为什么来应聘，如果他来只是纯粹的找一个工作机会，或是冲着公司的名气而来，而对于测试是什么，自己所选择的这个测试机会是否有利于自己的长远发展都不清楚，只是为了工作而工作，是否能够将他的潜力挖掘出来呢？我没把握。而这样的candidate，偏偏又不少。

生产软件的最终目的是为了满足客户需求，我们以客户需求作为评判软件质量的标准，认为软件缺陷（ Software Bug ）的具体含义包括下面几个因素： 

•  软件未达到客户需求的功能和性能； 

•  软件超出客户需求的范围； 

•  软件出现客户需求不能容忍的错误； 

•  软件的使用未能符合客户的习惯和工作环境。 

考虑到设计等方面的因素，我们还可以认为软件缺陷还可以包括软件设计不符合规范，未能在特定的条件（资金、范围等）达到最佳等。可惜的是，我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来，认为软件测试仅限于程序提交之后。 

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。 

下面是一些软件测试的常识，对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。 

•  测试是不完全的（测试不完全） 

很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。 

•  测试具有免疫性（软件缺陷免疫性） 

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。 

•  测试是 “ 泛型概念 ” （全程测试） 

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。 

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。 

•  80-20 原则 

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。 

80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。 

80-20 原则还能反映到软件测试的自动化方面上来，实践证明 80% 的软件缺陷可以借助人工测试而发现， 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分，因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。 

•  为效益而测试 

为什么我们要实施软件测试，是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来，在软件测试中我们应该尽量地保持软件测试简单性，切勿将软件测试过度复杂化，拿物理学家爱因斯坦的话说就是： Keep it simple but not too simple 。 

•  缺陷的必然性 

软件测试中，由于错误的关联性，并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的，一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中，我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围，选择一个折中的方案或是从非软件的因素（比如提升硬件性能）考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。 

•  软件测试必须有预期结果 

没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果，我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般，不少测试人员常常凭借自身的感觉去评判软件缺陷的发生，其结果往往是把似是而非的东西作为正确的结果来判断，因此常常出现误测的现象。 

•  软件测试的意义 - 事后分析 

软件测试的目的单单是发现缺陷这么简单吗？如果是 “ 是 ” 的话，我敢保证，类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好， “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析，我们就无法了解缺陷发生的原因和应对措施，结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜，目前大多测试团队都没有意识到这一点，测试报告中缺乏测试结果分析这一环节。 

结论： 

软件测试是一个需要 “ 自觉 ” 的过程，作为一个测试人员，遇事沉着，把持尺度，从根本上应对软件测试有着正确的认识，希望本文对读者对软件测试的认识有所帮助。