软件测试的定义有许多种，其中比较权威的是IEEE在1983年提出的:“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。” Grenford J. Myers在《The Art of Software Testing》一书提出:

　　(1)软件测试是为了发现错误而执行程序的过程；

　　(2)测试是为了证明程序有错，而不是证明程序无错误；

　　(3)一个好的测试用例是在于它能发现至今未发现的错误；

　　(4)一个成功的测试是发现了至今未发现的错误的测试。

　　这种观点提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但认为发现错误是软件测试的唯一目，查找不出错误的测试就是没有价值的，事实并非如此。事实上，对于软件来讲，不论采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完全杜绝软件中的错误，软件中的错误需要测试来找出，软件中的错误密度也需要测试来进行估计。

    统计表明，在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40％以上。而在软件开发的总成本中，用在测试上的开销要占30％到50％。为了尽可能多地找出程序中的错误，生产出高质量的软件产品，加强对测试工作的组织和管理就显得尤为重要。

“工欲善其事，必先利其器”。要做好测试工作，首先需要建立并维护一个高效的测试团队。Barry Boehm（1981）指出，人的特点和与人相关的活动是软件开发改进中最具潜力的部分。换言之，人的因素比任何其他因素对工作效率的影响都大。Barry Boehm在他的cocomo工作量预估模型中考虑到这一点，允许不同情况下分析师和程序员的工作效率相差到4倍。测试计划、测试开发甚至测试执行（发现缺陷）的工作效率也有类似的情况。如果您正寻找一种提高团队快速测试产品能力的单一最佳方法，高素质的人员显然是值得优先考虑的。

一、       成功测试者的特质

人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试团队，测试就不可能实现。为高质高效地完成测试任务，好的测试者应具有如下能力。这份特质清单是基于经验和观察，而不是基于严格的科学依据。

1.     自信心

　　开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。自信心是指测试者必须对测试工作的价值具有足够信心，不会因开发者指责测试结果没有意义甚至反唇相讥而影响工作情绪。

经受得住坏消息而保持目标的能力。一个测试者必须忠实地汇报产品中的缺陷。这一信息应当被项目组欢迎，因为每一个测试者遇到的问题(除非加入新的问题)都意味着减少客户会面临的问题。但不幸的是很多人不想听到有问题，特别是在程序项目的后期。测试者应当能处理因为工作做得太好而引起责备的情况。这对有些人来说是很难做到的，会严重地影响斗志与自尊。

2.     怀疑精神

　 怀疑精神是指测试人员对任何可能出错的地方都亲自测试一番，不听信开发人员毫无意义的保证，坚持以事实说话的工作作风。

可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

怀疑的而不是敌意的态度。测试者不能按表面值接受事物，必须执着地对一切提出疑问直到被证实。测试者必须用一种与项目的其他的人合作精神来平衡这种怀疑性与执着性。特别是在大量缺陷被发现后，或者在每个找出的缺陷会潜在地延迟产品的发货时间而延迟了项目时，测试者与其有关部门的关系可能会变得紧张。测试者应当记住要攻击程序的整体性，而不是程序员。

否定性的创造力。一个软件工程师不能怕引起一个产品的瘫痪或烧毁。在软件测试中，边界意味着被超越而不是被遵从。如果一个程序对某个值的极限为10(例如，可以在一时间被打开的最大文件数)，测试者的第一想法应当是“如果我把那个值取11，或0，或10.1，甚至不设这个值会如何？” 有能力打破一些东西并且感觉不错。

由于测试的工作是发现缺陷，测试者必须对发现别人的缺陷感到满意。

3.     沟通能力

一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术开发者和客户、管理人员等非技术人员的交流能力。

与客户沟通，须用客户的眼光进行评价。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。测试者必须是客户的拥护者。被测程序有可能运行可靠满足所有的设计要求，但在客户的软件环境中未必能够用。产品被送到客户之前的测试之一就是要证实产品达到了客户的要求与期望。在这项测试中，测试者必须模拟用户的软件环境，把自己放到他们的位置上。计算机系统功能要“正确”，且满足用户的需求。

而和开发者谈相同的信息时，就必须将这些话重新组织以另一种方式表达出来，能够表达导致问题的事件发生次序和系统配置。这包括能够清晰地编写过程和结果文档，以及能够与开发人员、其他测试人员和管理层进行口头沟通。能够提出批评和接受批评（例如，能够向开发人员解释缺陷，以便缺陷最终能被修正）。

具有幽默感，在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

能够向开发者和管理层报告坏消息。如果到了最后时刻要发布的产品还是有不小的问题，测试者必须自愿站出来，说出这个不好的消息。

4.     技术能力

测试团队需要许多领域的专家，诸如数据库、通信、网络、GUI测试、测试工具、自动化测试脚本和相关业务领域的专家。因此，测试者须拥有一项或多项的技术专长。

　　就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试团队的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深入的理解，从开发人员的角度正确的评价测试者。其次，测试组成员应具备良好的专业技能或者技术学习能力。由于测试组各个岗位需要的技能各有差异，所要掌握的测试技术也千差万别。比如测试管理人员需要对测试管理工作的内容及相关辅助工具的使用胸有成竹；自动化测试人员需要对相关自动化测试工具炉火纯青；测试脚本撰写人员需要对脚本语言的领悟了然于胸；手工测试人员应对相关测试中最易发现问题的地方如数家珍；而测试团队负责人则必须既熟悉被测软件系统的概念模型、设计模型，又要掌握开发过程中涉及到的相关开发工具。除此之外，测试经理还必须深刻掌握测试流程的裁剪、测试环境的搭建、测试计划的撰写、测试活动的组织与开展以及测试效果的评价等必备技能。

5.     外交能力

外交能力是指测试人员在与其他人员交流的时候，要注意自己的辞令和行为方式，不要刻意夸大错误的严重性，也不要碍于面子替开发人员掩饰重大程序错误。

当测试者告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于"赢了战争却输了战役"。

6.     很强的记忆力

一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

迁移能力是指测试人员应能将以前曾经遇到过的类似错误从记忆中挖掘出来，并迁移到当前测试活动中。

7.     自我督促

干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

需要有耐心。能够根据需要反复执行测试，直到问题被解决，然后再反复执行，以验证问题已被修正并且不再出现。

8.     洞察力

　　一个好的测试者具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。　　

在一个理想的世界中，软件测试应当在一个经常更新的写得很清楚的功能与设计说明文件中被完整而精确地描述。不幸的是，这一完善被开发程序每一方面文件的任务，包括记录在开发中对程序不可避免的改变，要花很多的时间和精力以至于人们无法完成编程，而且花费也太大。

因为我们不是在理想世界里编程，测试者应当能够自己找出工作的方式。典型的是，总会有一些设计和功能说明书让测试者用于开始他的研究。这些文件能看成为描述被测试软件的“正式”系统。测试者应当能用更广大的“非正式”系统的信息来扩展“正式”系统的信息。同时，在项目周期的任何一个点，任何文件都可能是正确或不正确的，所以测试者必须根据对软件工作模式的观察，与开发人员和其他项目人员的交谈，或对有关或看上去不那么相关文件的审核，来确定文件的精确性。

9.     组织技能

每当执行一个软件项目的测试计划，几乎不可能不遇到至少会阻碍一些测试而必须解决的缺陷。一个测试者应当能灵活地停止测试产品的一部分而开始测试其他部分。灵活，能够快速地转到测试一个新产品上，甚至为了另一个优先级较高的产品而放下手头正在测试的产品。

有时被测软件需要做根本变动引起大量的测试结果失效，测试也许得重做不止一次。在问题被查找和改变在进行的过程中，测试者必须有条理，保持对执行测试的软件的前后关系的明确感受。

10. 学习能力

拥抱新技术的热望和知识面广而且能不断更新知识，能够快速地学习新技术。对多数人来说，年龄越大越难学习。在商业世界里，人员越往公司的食物链高处走，越远离他们所建立的技术基础。这一部分是因为他们需要把精力集中于其他的经营和指导其下属的任务中。有时也是因为他们不幸地认为自己已不需要进行实践的技术工作了。互联网增加了技术变化的速度。不继续学习或跟着发展就无法做出商务与技术的决断。 　　

11. 计划能力

能够设计和执行一步一步的过程。

网络时代要求的动态开发和测试模式使组织性的工作方式对测试者越来越重要。在整个开发过程中被测试软件可能会不断地改进。测试者在计划和实施测试的时候必须考虑这些变化因素，必须控制测试环境来保证测试结果的有效性。

记住计划是一个动词。作为一个软件工程师，你永远不会有你想要的所有时间和资源。你总是必须通过理解技术和产品，开发组织方式，从你和其他人的错误中学习，以及在设计必须改变和出问题的时候的迅速调整，使你的测试效果和效率最大化。如何能做到这点呢？量化任务、目标和结果来减少变数，把产品的功能定义成要求，在测试计划和测试中量化测试及其预期的和实际的结果，把信息提供给项目组。你东点一下西点一下是不能完成整个测试的。

12. 能够承受无休止的压力

测试工作位于开发过程的后半段，将处在一种充满压力环境中。由于项目周期的安排，产品交付的日期的临近，测试者面临巨大的压力。如何在计划的时间内完成测试任务、交出合格的产品，测试者需要能承受无休止的压力。

13. 既有大局观，又能根据需要关注细节。

总体理解产品。在一个程序项目是，软件开发工程师主要把他们的精力和注意力集于自己的项目部分。结果当这些项目部分组合在一起进行测试的时候，就会碰到兼容性的问题。到产品寄给一个客户之前，唯一能见到整个产品的就是测试者。因此测试者必须能够对整个产品的操作与使用保持一种“系统”的眼光。

测试者对产品的任何一部分的操作可能不是最好的专家，但他必须是产品整体操作的专家。例如，如果被测的产品是一个类似于Microsoft Office的由文字处理、扩展页和其他有关程序组成的办公室自动组件，测试者必须了解每个程序的操作，各个程序之间的相互作用和客户其他的软件硬件和软件环境。

二、       测试团队的组建

可能在测试行业中有一些耀眼的明星测试者，他们是测试者的楷模。但更常见的情况是，组成优秀测试团队的人员拥有各自不同的技能背景。有必要认识到的是没有一个人能全部拥有这些特质，因此测试团队作为整体应该尽可能多地拥有这些特质。

明确测试团队内部各类测试人员的职责分工可以使测试团队内部各类测试人员能集中精力在较短的时间内完成特定岗位必需的知识储备和经验积累，同时也使得测试团队的管理更科学，真正做到“用其所长，避其所短”。

三、       测试团队制度建设

　　良好的制度可以规范测试团队的工作开展，同时也便于对团队成员进行业绩考评。相反,则很有可能导致人心涣散，滋长负面风气。建设良好的测试团队制度，可以考虑以下几个方面：

1.      汇报制度

团队成员汇报本周工作情况及下周工作计划、遇到的问题以及需要提供的帮助，培养团队成员的汇报及计划习惯。

2.      工作总结制度

成员每个阶段汇报上阶段工作经验和教训，并在部门例会上交流、分享经验及教训，避免同样的问题重复出现。

3.      奖惩制度

对于贡献突出的成员予以奖励，对于业绩差的提出批评，有效地保持测试团队的工作热情。

4.      测试件审核制度

对测试件进行审核，去粗存精，鼓励测试人员使用和提出改进，保证提交到测试团队知识库的测试件的质量。

5.      会议制度

定期召开部门例会，讨论、解决工作中的问题，并提供部门内的学习平台。

四、       团队成员能力的逐步提高

　　有了明确、合理的职责分工后，需要针对这些分工对团队成员进行有意识的引导，稳步提升团队成员的技能。测试团队负责人需要负起监督和促进员工能力提升的任务。监督和促进测试团队成员能力提高，主要做好如下三个方面的工作: 一是，提倡资深测试人员在测试团队内部进行经常性的培训和测试经验交流，通过该渠道帮助资历浅的测试人员大幅提升业务技能，做到新老员工之间的知识传播和继承。二是，测试团队应充分利用好测试件知识库，对于纳入到测试团队知识库的测试件应充分消化和学习，在此基础上进一步鼓励测试团队成员对这些测试件提出改进性意见。三是，测试人员除了需要注重自身的测试技能提升，在条件许可的情况还应适度开发部门的基本知识，这样能减少与开发团队协同工作时的领域障碍。