作者：陈能技 编著
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
软件测试技术大全：测试基础 流行工具 项目实战(第二版)试读：
前言
目前软件的质量问题几乎都可以归咎为测试阶段没有发现问题，然而事实上我们在测试阶段是不可能发现所有问题的。这当然与软件的复杂度有关系，另外不规范的测试过程和缺乏测试管理也是造成很多测试不充分、测试遗漏，甚至软件未经测试就匆忙发布的原因。
但是测试人员本身的素质、技能、测试方法也存在一定的漏洞。测试人员一方面在抱怨测试环境不佳，另外一方面却又不断地有更多的人期待进入这个行业。目前的测试行业充满了浮躁的味道，测试人员的素质参差不齐，测试技能和水平亟待提高。
我们精心编写了本书，目的是指出很多人对测试的各种误解，以及测试过程中的各种误区，尤其是为测试新手进入测试行业提供一个测试知识的阶梯。结合自己多年的测试经验和测试团队管理经验，为广大测试人员介绍了各种先进的测试技术和测试理念，为测试人员提高自己的测试水平、完善自己的知识结构、扩展自己的测试知识面提供了经验。
本书的内容安排
本书分为4篇，共20章，从软件测试的基本概念讲起，再进一步介绍一个完整的测试过程所经历的各个阶段，然后结合目前测试流行的各种实用技术和常用工具，讲解如何进行各种类型的测试，最后结合我们的经验讲解如何营造一个良好的学习环境，让测试人员的水平得以不断的提高。
第1篇（第1章～第3章）
软件测试的基础
。本篇讲述了软件测试的基础知识，包括测试起源和发展、测试行业的现状、测试人员的现状，以及真正优秀的测试工程师应该具备的素质，为希望进入测试领域的人提供一些基础知识，测试新手能通过这3章的基础知识来判断自己是否适合在测试领域发展，自己目前的不足是什么，需要努力提高的方向是什么。
第2篇（第4章～第10章）软件测试必备知识。
本篇讲述了与软件测试相关的各种知识，包括软件工程、软件测试的目的与原则、软件测试的各种方法、软件测试的具体过程、软件测试的质量度量方法。软件测试是一门需要具备广泛的知识的职业，测试人员应该掌握与测试相关的方方面面的知识。这7章的内容是由一名初级测试人员通往测试工程师必备的知识。
第3篇（第11章～第23章）实用软件测试技术与工具应用。
本篇具体讲述了各种实用的软件测试技术的使用，以及目前常用的各种测试工具的使用，包括测试管理工具QC的应用、自动化测试工具QTP的应用、性能测试工具LoadRunner的应用、安全测试工具AppScan的应用、单元测试工具MSTest的应用。这几章的内容是笔者多年软件测试经验和测试管理经验的总结，其中还重点介绍了一些测试辅助工具的开发，是测试人员综合利用测试技术和测试方法进行各种类型测试的重要参考，也是普通测试工程师通往高级测试工程师需要掌握的核心知识。
第4篇（第24章～第25章）软件测试的学习和研究。
本篇主要介绍测试人员的发展和提高途径，以及测试团队管理的技巧。测试人员需要找到自己的发展方向，清楚自己的缺点，与其他测试人员一起营造一个共享的交流和学习的环境。
本书由浅入深，由理论到实践，尤其适合初级读者逐步学习和完善自己的知识结构。
本书的特点
本书深入浅出地讲解了各种测试理论和方法，以及目前流行的各种测试技术和常用的测试工具。在每章的最后，笔者还结合自己多年的测试团队管理和培训新人的经验，对初涉测试领域的新手进行“答疑解惑”。而且特地为希望进入测试行业的新手提供了面试模拟，提出并解答面试过程中面试官可能提出的各种问题。
本书基本涵盖了软件测试的各个方面的知识，从测试设计到测试开发，从测试执行到测试管理，从测试的基本理论到测试的实用技术，从测试工具的使用到测试工具的开发。讲述了各种常用的测试用例设计方法，讲解了各种测试技术的使用方法，还介绍了各种常用的测试工具、开源测试工具在测试项目中的使用。本书的特点主要体现在以下几个方面。
● 本书的编排采用循序渐进的方式，适合初级、中级学者逐步掌握软件测试的基本方法，软件测试设计和管理的精髓。
● 本书结合笔者多年的团队管理和新人培训经验，深入浅出地介绍各种测试知识，在每章的最后还特地指出初级测试人员可能存在的疑惑和误解，并且有针对性地进行解析，是测试新手摆脱“困境”的很好的参考。而且模拟面试问答也为希望进入测试行业或谋求新工作的测试人员提供了参考。
● 本书在介绍各种测试方法和技术时，采用了浅显易懂的例子，在介绍测试工具时也使用了大量的例子和代码，方便读者自己进行实践和演练，在介绍测试工具的开发时更是提供了丰富完整的开发示例代码，读者可直接使用，或者根据自己的实际情况进行调整。本书的所有例子、源代码和各种免费工具均可到作者的博客（http://blog.csdn.net/Testing_is_believing）下载，方便读者使用。
● 除了基础的测试知识外，本书还适当加入目前测试领域各种先进的前沿技术和理论，介绍国外先进的测试方法和技术，方便读者借鉴大型项目和组织的测试理念和技术。
● 本书结合笔者多年的测试团队管理经验，在各种类型测试的管理方面提出了自己的见解，在测试工具的引入和管理、测试人员的管理和度量方面也提出了全面的解决方案。
适合阅读本书的读者
● 希望进入测试行业的新手。
● 迫切希望提高个人测试技能和水平的初级测试人员。
● 具备一定的测试理论知识但是缺乏实践的测试工程师。
● 希望了解国内外测试动向以及最新测试技术的测试人员。
● 希望了解大型软件测试团队的测试理念和测试方法的测试人员。
● 目前正在考虑引入测试工具或正在使用测试工具的测试人员。
● 希望了解各种开源测试工具的测试人员。
● 希望了解测试工具开发过程和开发技术，希望自己动手开发测试工具的测试人员。
● 希望提高团队凝聚力和加强测试人员学习能力的测试管理者。
编辑联系邮箱为：zhangtao@ptpress.com.cn。
编者软件测试的基础第1章软件测试行业
有人把软件产品与药品并称为世界上两种无法根除自身的缺陷，却被允许公开合法销售的产品。人们明知药物不可能百分百治疗疾病，而且肯定存在一些副作用，但还是会购买，而软件产品也一样，人们也知道软件不是百分百可靠，但还是越来越依赖它们。
而在其他行业中，如果产品存在明显不可预测的缺陷，市场、用户和法律都会做出强烈的反映。所以有人说，如果微软不是生产软件，而是制造汽车，恐怕早就倒闭了。软件产品的缺陷难以根除，但是可以通过加强软件测试来控制质量，通过修正缺陷来提高软件产品的质量。
软件测试行业是一个新兴的行业，尤其是在国内。称为“行业”是因为，测试已经不是以前单纯依附在软件开发过程中的一个可有可无的角色，而是发展到了足以成为专门的行业。
软件测试开始得到越来越多人的重视。第三方测试、测试外包的涌现，测试培训、咨询、考证的红火，测试职位的高薪，软件测试网站的增多，软件测试专门杂志的出现，种种迹象表明，在国外早已是一个专门的学科的软件测试，在国内开始步入可以称之为“行业”的时期。
本章从测试的起源讲起，重点描述测试的几个发展阶段，最后分析目前的软件测试现状，展望软件测试的前景。1.1 软件测试的起源
通常称之为Bug的软件缺陷是伴随着软件出现的，软件测试同样是伴随着软件而出现的。随着软件Bug的增多，严重的质量事故也随之增多，所以人们“对抗”Bug的态度日益强硬，软件测试也不断得到加强和重视，并持续的发展。1.1.1 第一个Bug的故事
故事发生在1945年9月的某天，在一间老式建筑的窗外飞进来一只飞蛾，Hopper正在埋头工作在一台名为 Mark II 的计算机前，没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器（电子机械装置，那时还没有使用晶体管）。
突然，Mark II 死机了。Hopper 试了很多次还是不能启动，他开始用各种方法查找问题，最后定位到了某个电路板的电器出了问题。Hopper观察这个继电器，惊奇地发现一只飞蛾已经被继电器打死。Hopper小心地用镊子将飞蛾夹出来，用透明胶布贴到“事件记录本”中，写上“第一个发现虫子的实例”。
Hopper的事件记录本，连同那只飞蛾，现在都陈列在美国历史博物馆中。在单维彰的个人网站上收录了一系列关于 Hopper 和这个事件的照片（http://libai.math.ncu.edu.tw/bcc16/pool/ 3.06.shtml），如图1.1所示。图1.1 Hopper 关于飞蛾事件的记录1.1.2 几个导致严重错误的Bug
软件的Bug事件发生了大半个世纪后，并没有迹象要停止，而是愈演愈烈。或许人们早已忘记了半个世纪以前的几个航天事故，但是最近发生的几起Bug事件一定让人们记忆犹新。（1）2008年，北京奥运官方票务网站的浏览量达到了800万次，每秒钟从网上提交的门票申请超过20万张，票务呼叫中心热线从9时至10时的呼入量超过了380万人次。由于瞬间访问数量过大，技术系统应对不畅，造成很多申购者无法及时提交申请。（2）2007年6月，某热门的在线股票选购竞赛系统中存在一个软件缺陷，可以导致不公平的竞争，从而获取高额的竞赛奖金。经调查最后发现，原本前5位的优胜者都要取消资格。（3）2007年4月，某地铁系统软件存在缺陷未能检测和防止剩余动力在设备中的使用，最终导致列车过热而起火。
类似的报告数不胜数，而据NIST 报告指出，美国标准和技术研究机构（National Institute of Standards and Technology）在2002年公布的一项关于软件缺陷引起的美国经济损失高达595亿美元。1.1.3 软件测试的起源
早在周代的时候，就有叫“人”、“氏”的工官，职能相当于工长，他们懂技术，负责直接管理制作器物的工匠，保证器物制造的质量。因此这些人堪称历史上最早的测试员。
1961年，一个简单的软件错误导致美国大力神洲际导弹助推器的毁灭。这个简单而又昂贵的错误，导致美国空军强制要求在以后所有的关键发射任务中，都必须进行独立的验证。从此建立了软件的验证和确认方法论。软件测试也就从那时候开始存在了。
从上面的几个故事，大概可以看出，错误从远古的时候就出现了，针对这些错误再制定相应的管理措施。由此看来，测试对产品制造者可以进行管理，虽然可能不是直接的管理，而是间接地通过检查产品来对制造者进行管理。
人类从很早的时候就已经知道，不能自己检查自己的工作产品，必须由其他人来检查，以确保公平、公正和客观性。但是在软件开始出现时，人们似乎并没有意识到这条规律的重要性。
随着错误的不断出现，导致了很多严重的问题，人们开始反省，知道靠制造者本身对自己的产品进行检查和验证存在很大的弊端，因此引入了独立的检查者。
然而软件测试的发展经历了大半个世纪，软件缺陷仍然大量存在。一方面是软件越来越复杂；另一方面，与软件测试的技术发展缓慢也有一定的关系。1.2 软件测试的发展
伴随着软件行业的发展，软件测试也在不断地发展，软件测试大概经历了如图 1.2 所示的几个重要的阶段。图1.2 软件测试发展的几个阶段1.2.1 软件调试
早期软件的复杂度相对较低，软件规模也比较小，因此软件错误大部分在开发人员的调试阶段就发现并解决掉了。这个阶段的测试就等同于调试。
现在，大部分开发工具都把调试工具集成进来，调试已经成为开发人员开发工作中不可或缺的一部分。甚至测试脚本的开发工具也会把基本的调试功能集成进来。如图1.3所示为TestComplete的调试工具栏。图1.3 TestComplete的调试工具栏1.2.2 独立的软件测试
在20世纪50、60年代，人们开始意识到仅仅依靠调试还不够，必须引入一个独立的测试组织来进行独立的测试。
这个阶段的测试绝大部分是在产品完成后进行的，因此测试的力度、时间都非常有限，软件交付后还是存在大量的问题。
这个阶段没有形成什么测试方法论，主要靠错误猜测和经验推断。也没有对软件测试的定位，以及软件测试的真正含义进行深入的思考。1.2.3 软件测试的第一次定义
1973 年，Bill Hetzel 博士给出了软件测试的第一个定义，即“软件测试就是对程序能够按预期的要求运行建立起一种信心”。
1983 年，Bill Hetzel 博士对这个定义进行了修订，改成“软件测试就是以评价一个程序或系统的品质或能力为目的的一项活动。”
因此这个阶段对软件测试的认识是：软件测试是用于验证软件产品是正确工作的、符合要求的。
但是同一时期，Glenford J. Myers 则认为，软件测试不应该专注于验证软件是工作的，而是将验证软件是不工作的作为重点，他提出的软件测试定义是“测试是以发现错误为目的而进行的程序，或系统的执行过程”。1.2.4 软件测试成为专门的学科
20世纪80年代后，软件行业飞速发展，软件规模越来越大，复杂度越来越高。人们对软件的质量开始重视。软件测试的理论和技术都得到了快速的发展。人们开始把软件测试作为软件质量保证的重要手段。
1982年在美国北卡罗来纳大学召开了首次软件测试的正式技术会议，软件测试理论开始迅速发展，随之出现了各种软件测试方法和技术。
1983 年，电气电子工程师协会（Institute of Electrical and Electronics Engineers，IEEE）对软件测试做出了如下定义。
● 使用人工或自动的手段来运行或测量软件系统的过程，目的是检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。
● 这个阶段认为，软件测试是一门需要经过设计、开发和维护等完整阶段的软件工程。
因此，从这个阶段开始，软件测试进入了一个新的时期，软件测试成为一个专门的学科，形成了各种测试的理论方法和测试技术，某些测试工具开始得到广泛应用。1.2.5 开发与测试的融合趋势
20世纪90年代后，软件工程百花齐放，出现了各种软件开发的新模式，以敏捷开发模式为代表的新一代软件开发模式开始步入历史的舞台，并且赢得很多开发团队的拥护。
由此带来的是对软件测试的重新思考，而大部分人倾向于软件测试将与软件开发融合的趋势的观点，开发人员将担负起软件测试的责任，测试人员将更多地参与到测试代码的开发中去。软件开发与测试的界限变得模糊起来。TDD把测试作为起点和首要任务。1.2.6 为什么软件测试发展比较缓慢
尽管软件测试经过几十年的发展，已经得到了长足的进步，但是与软件开发的发展比较起来，可以看到软件测试的发展还是比较缓慢的。
软件开发得益于计算机硬件的发展、计算速度的提高，还有计算机语言的发展、编译器的发展、开发工具的发展，因此比起软件早期的开发，无论是开发速度还是工作效率都有了很大的提高。
软件开发摆脱了早期的机器语言编码方式和汇编语言，跨越了结构化编程语言，进入面向对象的时代，开发人员的编程能力得到了很大的提高。而开发工具的不断改进，则起到了推波助澜的作用，使得开发人员无论是在编码速度还是调试方面都受益匪浅。
反观软件测试，虽然测试工具层出不穷，但是并没有革命性的发展。测试人员大部分情况下还是要依赖手工的测试。
软件测试受到越来越多人的重视，但是大部分的软件测试方法和理论还是沿用20世纪的研究结果。因此，软件测试的发展还需要更多热爱测试的人投入，需要更多的研究，无论是在测试的理论、方法，还是工具上。
软件测试发展比较缓慢的另外一个原因与软件企业对软件测试的投入有关系。据 CSIP （前信息产业部软件与集成电路促进中心）在2007年度一个关于软件质量现状的调研分析报告指出：目前国内绝大部分的软件企业在软件质量控制方面，每年都会投入固定资金。但是从图 1.4 所示的调查图表可以看出，投入的资金比例集中在全年研发或运维资金总投入的1%～5%的企业居多，因此还是偏低。图1.4 软件企业在质量控制方面的资金投入情况1.3 软件测试行业的现状和前景
在国内，软件测试仍然处于相对初级的阶段，虽然发展速度很快，但是夹杂了不少炒作的成分，测试人员的心态普遍有点浮躁。
但是前景是光明的，有越来越多的人关注这个行业，因为有越来越多的人投身到这个行业中，有越来越多的人喜欢这个行业。1.3.1 国内测试行业现状
关于国内软件测试行业的现状，在2009年国内某软件测试专业机构有过一份调查，发现仍有一半左右的企业没有设立专门的软件测试部门，调查结果如图1.5所示。
而在专职测试人员的规模方面，10人以下的仍然占了大部分，如图1.6所示，可见大部分企业在软件测试的投入方面较弱。图1.5 关于设置独立软件测试部门的调查图1.6 关于专职软件测试人员数量的调查
再看测试人员与开发人员的比例，能达到1:1的寥寥无几，大部分是在1:3～1:5左右，如图1.7所示。图1.7 关于测试人员与开发人员比例的调查
从调查的结果来看，国内软件测试经过这几年的发展，各企业开始重视软件测试，但是总体而言，对软件测试的投入仍然偏低，测试人员的比例也偏低，一方面是由于公司对质量管理和软件测试的意识有待提高；另外一方面也跟软件测试人员缺口较大，尤其是优秀的软件测试人员比较缺乏，难以满足公司的要求有关。1.3.2 测试人员的现状
这几年的测试人员现状可以用“浮躁”两个字来形容。
一方面，测试的职位由于比较紧缺，受到大家的重视，测试人员的地位也开始提高，随之而来的是待遇、跳槽的机会。因此，有不少的软件测试人员不能安下心来努力积累经验、提高自己的能力。
另一方面，软件测试职位受到很多毕业生的青睐，也有很多希望转行到软件测试的人。这给一些培训机构创造了很好的商机，承诺参加培训课程保证就业。这加剧了测试行业的浮躁氛围，很多人冲着保证就业的名份来参加培训，真正静下心来学习软件测试的人不多。
分析这几年来很多测试人员的应聘表现，可以看到测试人员的主要表现有以下几种。
● 基础知识不够扎实：知道一些基本的测试设计方法，但是仅仅停留在表面的概念性了解，没有深入去理解这些基本的概念。
● 专业技术不够精通：简历上写着精通某某技术或某某工具，但是基本上没有真正地实实在在的应用过。
● 没有建立起相对完整的测试体系概念，忽视理论知识：大部分人对软件测试的基本定义和目的不清晰，对自己的工作职责理解不到位。测试理论知识缺乏，认为理论知识没用而没有深入理解测试的基本道理。
关于测试人员心态以及软件测试行业近年来的现状分析，推荐读者学习《虚假的测试繁荣》，该文从网站获取：http://blog.csdn.net/zeeslo/archive/2009/06/04/4243200.aspx。
尽管如此，这是软件测试行业在中国必然经历的一个不成熟阶段。软件测试行业最终会趋于平静、进入平稳的发展阶段。1.3.3 软件测试的前景
Harry Robinson在2004 年就曾经对软件测试的未来趋势进行过预测，他认为测试领域在将来会有如下的一些变化。
● 工程师、开发人员会成为软件测试人员中的一份子，他们与测试人员之间开始互相帮助。
● 测试的方法日趋完善，Bug 预防和早期检查将成为测试工具的主流。
● 通过仿真工具来模拟真实环境进行测试。
● 测试用例的更新变得容易。
● 对测试质量的衡量开始从计算Bug数量、测试用例数量转到需求覆盖、代码覆盖等方面。
● 机器将替代测试人员做大部分的工作，测试人员开始把注意力集中在更严重的问题。
● 测试人员将运行更多更好的测试。
● 测试执行与测试开发的界限开始模糊。
● 测试与开发的界限开始模糊。
● 顾客反馈与测试合为一体。
● 新的挑战，例如安全测试等新问题开始出现。
● 测试人员获得尊重、测试变得流行。
● 追求进度，到最后一刻才加入测试的行为仍然会存在。
在随后的这几年，可以看到，上面的一些变化已经开始。例如，人们逐步意识到测试只是事后的检测，并没有达到消灭缺陷的作用，人们开始转向缺陷产生的早期，对缺陷进行预防性的工作。
Harry Robinson 还提出了以下几点迎接测试未来挑战的建议。
● 要不满于现状：不要被动接受和满足于测试的现状，不要埋头苦“测”，要思考一下“我们在做些什么毫无意义的事情？”。
● 抛开人与人之间的隔阂：总结如何更好地测试，并且分享这些测试经验。只有每个人都试图使其所写的代码达到最佳状态时，整体质量才会改进。
● 学习更多关于测试的知识：软件测试行业发展受到各种软件测试创新思维、好想法的激发。通过参加交流会，加入邮件列表，上网搜索等方式来了解在测试前沿发生的事情。
● 学习更多关于开发的东西：参加一个编程培训课程，即使不打算编写大量的代码，也可以把培训当作是在BUG领域上的一次侦察飞行。
● 改变这个世界：正如PC 先驱Alan Kay所言“预测未来的最好方式就是创造未来”。
以上的建议对于测试人员来说是一个启示，测试领域有很多值得探索的东西，有很多值得思考的东西，有很多值得学习和研究的东西。1.4 小结
查询China-pub（中国互动出版网）网站上与软件测试相关的图书可知，超过100多本国内学者的著作和译作。
而这类图书在5年前还只有屈指可数的几本。测试类的图书已经从当初的只有测试理论的介绍，到现在涉及测试的方方面面，包括自动化测试、性能测试、单元测试、测试管理、测试工具。
对于那些准备进入软件测试行业的新手而言，建议先全面地了解软件测试行业、软件测试的工作内容和软件测试的知识体系，推荐大家去看一下“软件测试藏宝图”，以便窥探一下软件测试的全景：
http://sites.google.com/site/swtestingmap/stadventure1.5 新手入门须知
从某种程度上说，软件产品的竞争已经不仅是技术的先进与否，还有软件的质量稳定性和低缺陷率。随着用户对软件质量需求的不断增强，如何有效发现Bug，并研究Bug的产生原因，从而有效预防Bug已经成为软件行业的重点问题。
对于那些准备进入软件测试行业的人来说，测试行业挑战与机遇并存。
机遇是目前软件测试受到越来越多人的重视，尤其是软件企业开始意识到“作坊式”的软件生产不能达到以“质量求生存”的目的。
挑战是软件测试的工作面临多方面的压力，对于新手而言，首先面临的是测试能力缺乏带来的压力。如何克服这些压力和困难，是测试新手的首要问题。
可以找一家专门的软件测试培训机构作为学习的起步。但是要注意不能因为培训机构提出的“培训包就业”口号而迷失了方向和目标。目的是通过培训使自己具备一定的测试基础，仅此而已，其他的都是附带而来的结果。
对于测试方面的考证也应该抱着同样的目的和态度，通过了考试不代表就具备了多高的水平。目的不是拿到证书，而是通过考证的过程、备考的过程，经历一次软件测试的“修炼”的过程。1.6 模拟面试问答
本章介绍的是软件测试相关的背景，以及软件测试的发展情况等。身为软件测试员，应该或多或少地了解软件测试的发展动态，及其相关的历史事件等内容，这样无论是在与同行交流，向开发人员介绍和讲解测试，还是在应聘面试中，都会有更多的话题。
一般在应聘过程中，面试官可能会问到以下一些问题，读者可以根据自己的了解以及在本章中学到的内容做出相应的回答。（1）您觉得目前的软件测试行业的现状是怎样的？
参考答案：目前的软件测试行业在国内正在蓬勃地发展中，但是由于起步比较晚，虽然大部分公司都已经设置了专职的测试人员，但是对测试资源的投入、测试人员的培训、测试工具的购买方面都相对缺乏。但是这也需要一个发展的过程，需要软件企业逐渐认识到测试投入的必要性，对质量的认识逐步提高。另外，也需要我们测试人员不断地学习和提高个人能力，为软件企业创造更多的价值。（2）您认为现在的测试人员的能力水平怎样？
参考答案：目前国内的测试人员的测试水平都普遍偏低，尤其是在测试用例的设计能力、测试的规范化执行、自动化测试和性能测试等方面。这也跟测试行业起步相对晚，测试人员缺乏经验有关系。要想改变这些现状，我们需要多向国外同行学习，多借鉴他们的宝贵经验和最佳实践。（3）您对软件测试的发展过程了解多少？
参考答案：最早的软件测试只是开发人员在写完程序后，自己进行调试。这其实不是很科学的做法，因为存在很大的局限性，缺乏第三者的测试也会存在客观公正性和权威性的问题。后来人们意识到这点后，开始组建独立的测试小组，进行独立的专门的测试，慢慢地就形成了测试的专门职业。因此也有更多的学者专门研究测试的技术和理论，也开发出专门的测试工具帮助测试人员进行测试。（4）您认为软件测试将来的发展方向是什么？
参考答案：软件测试将来会逐渐出现更多更好的测试工具，自动化测试也会越来越普遍，开发人员的测试意识会不断增强，开始与测试人员一起讨论测试的设计，做更多的单元测试。（5）您认为是什么制约了软件测试的发展呢？
参考答案：软件测试的发展看起来没有软件开发的发展那么快，软件开发得益于开发语言、开发工具、设计模式、面向对象思想的发展，因此相比几十年前有了飞跃性的进步。而反观软件测试，则大部分仍然停留在手工测试的阶段，测试的组织也不够规范和严谨。
这当然与测试职业的本质有关系，测试更讲求测试人员对需求的理解、验证，对软件行为正确与否的判断，更加依赖测试人员的测试经验和发现Bug的直觉能力，因此不可避免地要进行大量的手工测试；另一方面，软件测试学科中缺乏其他学科的有力支持，例如数学、人工智能的应用，测试工具也还有待进一步地改进。第2章软件测试的组织
一个人的测试是不可能成功的，软件测试人员不是行走江湖的独行侠，测试是一项需要合作进行的工作。
本章从测试组织的形式分析各种测试组织结构的利弊，提出了一个综合型的软件测试组织结构模型。然后介绍对于一个新加入测试团队的测试人员而言，如何找准自己的角色定位，如何快速地融入测试组织。最后看一下测试团队的建设需要注意哪些方面的内容。2.1 测试的组织形式
早期微软的开发团队中也没有独立的测试组。那个时候通常由几百个人做几个项目，程序员写完程序自己测试一下就算完成了。后来随着微软的项目越来越大，开发的软件也越来越复杂，编码和测试的工作需要并行地开展，于是就渐渐产生了独立的测试组。在微软的产品组中测试人员和开发人员的普遍比例是1:1。2.1.1 微软的经验教训
在微软的起步初期，微软的许多软件都出现了很多的Bug。例如，在1981 年与IBM PC机绑定的BASIC软件，用户使用“.1”除以10时就会出错，引起了大量用户的投诉。
微软公司的高层领导觉得有必要引入更好的测试和质量控制方法，但是遭到很多开发人员和项目经理的反对，因为他们认为开发人员自己能测试产品，无需加入太多的人力。
1984年，微软公司请到Arthur Anderson咨询公司对其在苹果机上的电子表格软件进行测试，但是外部的测试没有能力进行得很全面，结果漏测的一个Bug，让微软为2万多个用户免费提供更新版本，损失达20万美元。
在这以后，微软得出了一个结论：不能依赖开发人员测试，也不能依赖外部的测试，必须自己建立一个独立的测试部门。2.1.2 最简单的软件测试组织
最简单的软件测试组织形式就是没有任何组织的测试，几个人就把所有软件测试工作做完，这样做没有任何分工、没有任何层次结构。
简单的软件测试组织带来的问题是：软件测试依附在软件开发的组织下，不能真正发挥软件测试的威力。
一两个人的软件测试缺乏交流和思维的碰撞，导致测试人员的进步非常有限。缺乏测试的组织，导致测试无计划进行，测试人员疲于应付各项突如其来的测试任务，测试经验也得不到很好的总结。2.1.3 组织形式的分类方式
软件测试的组织形式可以按测试人员参与的程度分为专职和兼职两类，如果按测试人员的从属关系则可分为项目型和职能型两大类。（1）专职VS.兼职。
按照测试人员的职责明确程度，可以划分成兼职测试和专职测试两大类。目前在很多软件企业，尤其是小规模的软件企业，往往没有专职的测试人员。在做测试工作的同时还要兼顾软件开发、配置管理、技术文档编写、用户教育、系统部署实施等工作。
即使是在一些比较大规模的软件企业，拥有专门的质量部门，也会有兼职的情况，最常见的兼职工作是测试+配置管理，或者测试+QA。这种方式的好处是节省成本，可以充分利用资源。但是这样测试人员缺乏专门的独立的发展空间，不利于测试的纵深方向的发展，很难把测试做得精细，也不利于测试经验的积累和测试知识的传播。
当然，由于目前软件企业的现状，很多企业还是使用这种方式。对于测试人员来说，不要过分地去抱怨这些工作，尤其是对于新入行的测试人员来说，可以认为这是对自己的很好的锻炼机会。
测试本身的要求就是知识面要广，而这些工作有助于从不同层面、不同角度、不同角色的位置考虑软件的相关问题。（2）项目型VS.职能型。
按测试人员参与项目的形式来划分，可分成项目型和职能型。
项目型的测试组织是指测试人员作为项目组成员之一紧密地结合到项目中，与项目组其他人员紧密协作，一般是从头到尾跟着项目走。当然，也有些项目是到了中后期才考虑把测试人员加入到项目中。项目型的组织结构一般如图2.1所示。图2.1 项目型软件测试组织
这种类型的测试组织一般不会有测试组长，测试的管理由项目的主管或项目经理负责。当然，在一些大的项目中，会划分处开发组长、也会划分出测试组长，但是最终报告的对象都是项目经理。因此项目经理是负责测试资源调配和测试计划的主要人员。
而职能型的测试组织是指测试人员参与到项目中是以独立的测试部门委派的方式进入的。职能型的测试组织如图2.2所示。
在这种结构中，一个测试人员有可能不仅仅测试一个项目的产品，可能会同时测试多个项目的产品。测试人员也可能不是长期稳定地从头到尾参与同一个项目。
测试人员不向项目主管或项目经理报告工作，而是向自己所在的部门经理报告工作。并且这种结构的项目经理也可能是虚拟的，或者由多个部门经理共同担当。
这两种方式各有利弊。项目型的好处是测试人员参与的力度很强，能深入了解项目的方方面面的信息，有利于稳定持续有效地测试出更多细节问题；但是同时也有弊端，就是测试人员受项目负责人的管理，在对待Bug的处理意见上往往受到约束，同时由于过于亲密，很可能出现“网开一面”，不能严格要求的情况。并且由于缺乏独立的组织，测试人员的知识可能局限在项目组内传播，不利于测试经验在不同项目组之间的传播。某些测试人员在这种组织中可能会感到孤独和无助。图2.2 职能型软件测试组织
而职能型的好处是能避免项目型的部分问题，并且能节省部分测试资源，充分利用各个项目阶段之间的时间差来合理利用测试资源；但是也不可避免地存在一些问题。例如，深入程度不够，尤其是对项目涉及的领域知识和业务知识理解可能不够深入，导致测试的问题比较表面。2.1.4 综合型的测试组织
尽管独立的测试部门会有一些不可避免的问题，例如参与项目的深入程度，容易导致“扔过墙”的测试。但是很多软件企业还是倾向于建立一个相对独立的软件测试组织。
一个理想的软件测试组织可以是综合和兼容了几种结构方式的组织，这要视公司的软件测试资源配备和项目经理、测试部门经理的具体职责定义来设计。
例如，可以将项目型结构和职能型结构组合并加以改造。测试部门是独立的部门，测试部门经理根据各项目组的项目经理的请求，结合公司对项目的投入和重点方向，决定委派哪些测试人员加入到项目组，并且长期稳定、持续地跟进项目，在项目的各个阶段都参与并做测试的相关工作内容。测试人员作为一种服务资源供项目组调用，测试的结果和报告作为评估软件产品质量的必要参考信息，为项目经理做出产品发布的决定提供参考价值。
测试部门的测试人员分为常规项目测试人员和专项测试人员，常规项目测试人员即参与到项目组中的测试人员。而专项测试人员一般由性能测试工程师、自动化功能测试工程师、界面及用户体验测试工程师、安全测试工程师等负责专门测试领域的人员构成，这些测试人员在项目发生专门的测试需求时，被调用到项目组，与常规项目测试人员一起工作，但是重点解决专项的测试问题。图2.3 综合型软件测试组织
当然还可以根据需要丰富这个组织结构，例如，设置一个专门的培训中心，负责对测试人员的内部培训，同时负责收集和整理各个项目的测试经验和测试知识。2.2 融入测试组织
不同的软件企业由于种种原因会设置不同的软件测试组织形式和结构，没有哪两家公司的软件测试组织是一模一样。即使是结构一样，由于职责范围和沟通方式不一样，也会导致测试组织的表现形式不一样。
这对于一个需要加入到新的测试组织中去，尤其是对于一些新入行的测试人员来说，要特别注意如何让自己快速地融入项目团队的测试工作中。
注意
如何让自己快速融入项目团队，是实现成功的软件测试的第一步。2.2.1 根据开发的模式判断自己的测试角色定位
每一个公司都会根据自己的研发模式和对质量的认识来界定测试组织的用途，以及测试人员的角色等位。（1）在不同的软件开发模式中，测试的角色定位是不一样的。
传统的软件开发模式中，软件测试人员可能仅仅需要完成系统测试的任务就行了。而在敏捷开发模式中，则可能需要进行更多的单元测试，与开发人员紧密配合，寻找Bug出现的根源。
不同的软件组织对于同一种开发模式存在不同的理解和应用，也会导致测试人员在其中的角色定位出现差异。例如，同样是实现微软的MSF开发模型，有些公司比较喜欢让测试经理担当软件发布决策人的角色，而有些公司则喜欢让测试经理作为程序经理的辅助角色，另外一些公司则更倾向于MSF的几个项目角色共同做出项目的决策，或者由更高层的项目经理来决定。
因此，测试人员在加入一个项目团队中时，要找准自己的角色定位，否则可能导致自己的工作职责范围不清晰，或者工作体现不出来，甚至感到现实与理想存在差距。（2）微软MSF模型中的测试角色。
图2.4所示的是微软的MSF组队模型。可以看到测试是其中一个重要的角色之一。
软件测试人员与其他项目角色之间的关系是平等的，没有上下级关系。每个角色负责自己职责范围内的工作，每个角色之间通过沟通来协调工作。MSF组队模型的核心和基础是沟通和协作。（3）敏捷测试角色。
在敏捷项目中，测试人员的角色可以进一步地细分，如图2.5所示。图2.4 MSF 组队模型图2.5 敏捷测试角色的细分
在这个矩阵中，可分成4个角色。
● 面向业务的批判产品角色。
● 面向技术的批判产品角色。
● 面向业务的支持编码角色。
● 面向技术的支持编码角色。
在解释这4个角色之前，先要解释一下两条轴线的意义。在横轴上，左边是偏向“支援编程人员”的测试，右边则是偏向于“批判产品”的测试。但是两种测试的意义和内涵存在很大的不同。2.2.2 “支援编程人员”的测试与“批判性”的测试
对于支援编程，测试主要作为准备和保证。通过写测试代码来阐明关于问题的思考。把它作为说明性的例子来描述代码应该怎样做。另一方面，测试是关于暴露主要错误和遗露，也就是对产品进行“批判”。这里，测试的原义就是关于Bug。有其他的意义，但是首要的意义是最主要的。（很多测试员，尤其是最好的测试员，在其身上已经融入了那些词语的内涵。）2.2.3 “面向业务”的测试与“面向技术”的测试
在纵轴上，下边是“面向技术”的方面，上边是“面向业务”的方面。两者缺一不可。“面向技术”是指测试人员在测试过程中更关注技术实现的正确性，并且需要应用到很多专门的技术来进行测试。而“面向业务”是指测试人员在测试过程中更加关注的是产品对业务实现的正确性，需要根据需求和用户的实际业务场景来进行测试。
面向业务的批判产品角色是指测试人员从用户的角度对产品进行测试，这种测试更关注产品对需求的满足程度，探索性测试是这种测试的常用方法。面向技术的批判产品角色是指测试人员应用专门的测试技术对产品进行测试，例如性能测试、安全性测试、可用性测试等。
面向业务的支持编码角色是指测试人员编写代码来激发出正确的代码，测试人员首先编写测试代码来举例说明某个即将添加的新功能特性要怎样工作。然后程序员编写代码来匹配这些例子。FIT 框架（Framework for Integrated）是这种测试方式经常用到的工具，利用FIT测试人员或者用户可以在 Word 文档中通过举例子，列表格的方式来说明某个功能需要满足的输入输出，FIT自动比较期待输出与实际输出之间的差异来判断测试是否通过。图2.6所示为Word文档截图是FIT的测试结果。图2.6 FIT测试结果文档
面向技术的支持编码角色是指测试人员使用单元测试代码来检查开发人员的编码，并且编写一些“保护性”的代码，来确保每次运行开发人员写的代码都能确保正确的仍然正确，如果开发人员针对代码进行了改动，测试人员编写的测试代码应该可以检测得出来。
关于敏捷测试角色的划分，Brian Marick 在《Agile Testing Directions》一文中有详细的描述：
http://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-12.2.4 测试的划分对敏捷项目开发的重要性
这种测试的划分对敏捷项目而言是重要的，因为不同方面的测试工作，可以由不同的项目组成员来进行。例如下面的几种。
● 面向业务的批判产品角色可以由用户来充当（在敏捷开发模式中，把用户作为项目角色之一）。
● 面向技术的批判产品角色由拥有专门测试技术的测试人员担任。
● 面向业务的支持编码角色由测试人员或用户充当。
● 面向技术的批判产品角色可由开发人员，或熟悉单元测试方法的测试人员担当。
注意
在实际中，这4个角色的工作都由同一个人来承担也是很有可能的。2.2.5 如何融入一个项目团队
对于一个新人，项目组可能表现出两种截然不同的态度，一种是非常热情地欢迎，并且主动提供了很多协助，让其可以更快地熟悉环境并且参与到实际的工作中。而同时可能存在的另外一种态度则让人有点恐惧。项目组采取了一种冷漠的态度，甚至是敌视的态度。在这种团队中工作，可能是测试人员的一个非常大的挑战。
注意
要想赢得大家的尊重是件不容易的事情。
一个非常重要的前提条件是要做好本份工作，并且把工作的成果表现出来。如果项目组中已经有一位值得学习的测试前辈，那么很幸运，因为如无意外，这位测试的前辈会给大家最大的支持。如果没有，那么就需要自己努力寻找各种项目相关的信息来帮助自己尽快熟悉项目。
测试新手如何融入一个项目团队中去，如图2.7所示。图2.7 快速融入团队需要注意的因素2.2.6 快速融入项目团队的技巧
与开发人员好好地相处，有效地工作在一起。测试人员需要掌握一些技巧。以下是想更快融入项目团队的测试人员可以参考的方面。
● 找到一些共同语言非常重要。例如找到跟自己一样喜欢某项运动的开发人员，经常邀请他一起运动。
● 尽量拉近距离，了解每位开发人员的性格特点。
● 开发人员要对正在开发的产品表现出的浓厚兴趣，与他们一起探讨软件的方方面面。
● 把缺陷跟踪库中的所有以前的Bug都看一遍，尤其是目前处于激活状态的Bug，避免录入一些重复的Bug。
● 虚心的学习态度永远会受到大家的认可，但是要注意把握问问题的时机。2.2.7 尽快投入测试工作的技巧
能否快速地掌握项目相关的知识，快速地投入工作，并表现出工作成果，是融入项目团队的关键因素。也是新加入的测试人员，是否能尽快得到大家的认可的前提条件。
下面是测试人员在接手一个新项目时需要注意的方面。
● 阅读需求文档、设计文档、用户手册是关键的第一步。如果项目已经启动并且进入了测试阶段，则一般会有需求规格说明书和相关设计文档可供参考，应该尽快熟悉和消化这些材料，获取测试需要的信息。如果用户手册已经编写出来，则对照用户手册操作软件系统，可以快速地熟悉系统各项功能，顺便也可以对用户手册进行检查。
● 如果处于前期的启动阶段，则应该多参与项目各种会议，尽量多了解项目的需求和各方面的知识（包括业务知识和测试技术）。
● 阅读已有的测试用例或根据需求和设计文档编写测试用例。如果项目已经启动并且进入测试阶段，则一般会有测试用例文档，这些测试用例也是后来加入项目组的测试人员的快速上手的参考材料。如果没有测试用例，则可以根据需求和设计文档编写测试用例，这也是熟悉需求和软件系统的一个好办法。
● 阅读缺陷库中旧有的Bug，尝试按录入的Bug描述的步骤重现问题或测试软件系统。这种方法能借鉴别人的经验，能使自己一步一步深入熟悉软件系统的功能细节。2.3 软件测试的团队建设
要做好测试工作，首先需要建立并维护一个高效的测试团队。良好的制度可以规范测试的工作开展，同时也有利于对测试人员进行绩效评估。相反，缺乏有效管理和良好的团队氛围，则可能导致人心散漫，缺乏凝聚力，测试人员工作效率低下。2.3.1 学习型团队的组建
一个好的组织，一定是一个让人觉得舒服的团队。一个好的测试团队，则一定会是一个学习型的团队。学习型的测试团队是有生命力的团队。测试人员可以不断地学习到需要的测试理论和技能，并且能把大部分人凝聚在一起，除了那些不思进取的人。
首先必须建立起一个学习或培训的机制，例如定期的测试交流、技术演讲，每年一度的测试技术日活动等。其次，要建立起共享的氛围和习惯，让每个测试人员都有学习的机会，都能把学到的、总结到的经验共享出来。一个专门的测试知识库是必不可少的。可以充分发挥人多力量大的优势，指定每个测试人员研究某个专门的领域，然后把研究的成功贡献出来。
当然，如果经济条件允许，也可以设置专门的测试技术研究人员。但是前提是每个人都有乐于助人、不吝赐教的心态。如果测试团队的人数在5个人以上，就可以办一份内部的杂志，专门发表测试知识、质量知识、测试工具的应用、测试理论的研究等方面的内容。并且要把这份杂志让更多的人看到，让大家了解到关于测试的更多方面。
声明
更多关于学习型团队建设的内容将在第19章介绍。2.3.2 让每一位测试人员找到适合自己的位置
团队建设的另外一个重要方面，是要让每一位测试人员找到适合自己的位置，并且清楚适合自己的发展方向。一个简单的分类就是把测试的方向分成技术型和管理型。技术型偏向于测试设计和架构方面，而管理型则偏向于测试组织和协调方面。
但是值得注意的是，由于中国传统官本位的思想，可能大部分人会喜欢往管理型方向发展。这虽然有其不合理的地方，但是也有它固有的优势。因为，大部分人不会喜欢被一位技术能力比自己弱的人领导，因此，这使得往这个方向发展的测试人员，必须具备一定的技术实力和坚实的测试基础。而实际情况也如此，不仅仅是测试，开发也一样，提拔成领导的人都是从技术能力比较强的骨干挑选的。
一些外企提供给测试人员的发展路线主要分为两条，如图2.8所示。图2.8 一般外企的测试人员发展路线
可以看到，测试人员的发展主要有两个方向：一个是往管理方向发展，另一个是往技术方向发展，两个方向都给予了同等的重视程度，让测试人员可以选择自己喜欢，而且适合自己发展的路线。在发展的初级阶段，两条路线要经历的阶段是一样的，都是从实习开始，先做测试人员的工作，成为正式的测试工程师后，再往测试设计工程师晋升，然后才考虑往不同的方向发展。
在微软公司，则更多的是开发人员与测试人员之间会出现互相转换的现象，因为在微软公司，测试与开发都受到同等的重视，比尔·盖茨甚至说“微软不是一个软件开发公司，而是一个软件测试公司”。在微软，很多测试人员都有很强的开发能力，而很多开发人员也会希望在测试领域锻炼自己。在微软的测试体系中，主要把测试人员分为两类，一类是SDET（Software Design Engineer Tester），另一类是STE（Software Test Engineer）。
对SDET的编程能力的要求与对开发人员的要求基本上是一样的，都需要有扎实的计算机基础知识和编程能力。区别在于开发人员对算法更加精通，或某一方面的技术钻研的更深入一些。而对SDET的要求则是技术面要很广，要能使用很多种技术，比如可以用C、C#、脚本等来写程序。
当然，STE的角色也很重要。对STE的要求是：解决问题的能力要特别强，有钻研精神，轻易不放弃，细心而且有创造力。好的STE不是只按照规定好的测试用例来执行，而是可以想到很多一般用户想不到的地方，可以用非常规的思路来寻找软件的Bug，而且懂多种软件，善于利用各种工具进行测试。2.3.3 “无规矩则不成方圆”
如果一个测试团队缺乏了规范和制度，则不能称之为组织。缺乏规范和制度的测试团队也很可能不是一个高效率的团队。测试人员一起遵循相同的规范可以减少不必要的沟通成本，一个测试人员调到另外一个项目组，能看懂所有相关的文档，能快速地融入测试组，与其他测试人员一起工作。2.3.4 测试规范
测试规范是一个公司测试的标准，既是测试人员测试的准则，同时也是测试人员与开发人员达成的契约。软件的测试规范应该包括内部和全局的规范。（1）内部规范是指测试人员在测试工作过程中需要遵循的规范，一般包括以下这些规范。
● 软件测试方法指南：是对测试人员在进行各种类型的测试时进行规范化的要求，例如，在做安装包测试时一定要包括安装、卸载、重安装过程，一定要检查注册表和文件的改变是否符合要求。通过规范的制订，可以有效统一测试人员的测试行为，避免了不同的人进行同类测试时出现测试效果上的很大的偏差。
● 测试用例设计规范：一般包含测试用例的模板以及测试用例设计的要求。例如，每个测试用例必须包括测试用例执行的估计时间、测试用例的优先级别等。
● 缺陷录入规范：用于规范化测试人员的Bug 录入过程。包括Bug 录入的格式，Bug录入的要素包括哪些，Bug描述需要注意的地方。
● 测试计划规范：一般包含测试计划的模板以及对测试计划的要求。例如，测试的进度和时间安排根据什么来制定。
● 测试报告规范：一般包括测试报告的模板以及对测试报告的要求。例如，测试报告需要包括哪些要素，测试报告的分析需要注意哪些方面的问题。
● 测试工具使用规范：指测试人员在什么时候使用哪些工具，工具的参数设置需要注意哪些方面的问题。例如，对于自动化回归测试工具 TestComplete，要求统一使用哪种脚本语言。（2）全局的规范是指测试人员与其他项目成员之间需要共同遵循的规范，一般包括以下这些规范。
● 缺陷分类规范：指如何把Bug 进行归类，归类有利于缺陷的分析统计，以及产品质量的评估。测试人员应该按照缺陷分类规范指定Bug的类型。
● 缺陷等级划分规范：是Bug 的严重程度标识和优先级标识的依据，测试人员按照规范来衡量某个Bug应该属于什么级别的缺陷。缺陷的等级划分有利于开发计划的优先级划分，有利于对产品的质量进行评估。
● 测试提交流程规范：是开发人员提交某项完成的功能模块给测试人员测试时应该遵循的流程，图2.9就是一个简单的测试提交流程的例子。图2.9 一个简单的测试提交流程
● 缺陷状态变更规范：要求项目组不同角色的人对Bug 状态的修改的权限和更改应该遵循的流程。例如，规定开发人员不能私自把Bug修改为“Rejected”状态或“Delay”状态，必须得到项目经理和测试组长的同意才允许更改。2.3.5 部门制度
制度是测试部门的做事原则，沟通方式等方面的内部契约，是测试人员在一个团队中获取资源、贡献力量的依据。部门制度是测试部门运转的依据，是各位测试人员明确自己的职责和做事方式的基础，也是测试沟通的定义。一般的测试部门制度可包括以下方面的内容。
● 测试部门的职责：明确测试部门对于公司而言承担哪些职责。例如，有些公司会把QA的职责和配置管理员的职责都放到测试部门。明确这些职责有利于测试人员顺利开展工作。
● 测试部门的组织结构：清晰地描述测试部门的组织结构有利于测试人员明确分工合作、沟通与报告的对象。
● 测试人员的工作内容：细分测试人员的工作内容，有利于测试人员明确自己的工作范围、对象等。例如，是否需要测试人员对实施手册、培训材料进行检查。
● 测试人员的工作流程：制定测试人员需要遵循的工作流程，例如明确测试计划、测试报告的审核流程，制定测试用例的评审机制等。
● 测试人员的日常工作规范：测试人员的日常工作规范可包括服务器的检查和备份规范、工作日报的编写规范等。例如，要求测试组长每天早上检查编译服务器的每日构建结果，要求测试人员每天早上要打开邮件并查看缺陷跟踪库的最新状态，要求测试人员每天下班前要提交每日工作简报等。
● 测试人员的培训制度：制定一个培训制度，例如定期的内部培训、交流、技术研讨会等。让培训工作成为日常工作的一部分。2.4 小结
测试人员不是行走江湖的独行侠，不管进入的测试组织是“丐帮”还是“少林”、“武当”，只要愿意，都要贡献自己的一份力量。如果组织的现状不理想，则应该积极地考虑改进，而不要满足于现状。“有困难，找组织”，不要忘了在身后有一大帮的测试“战友”，测试团队不是一个摆设，是测试人员可以充分利用来帮助自己有效工作的组织。2.5 新手入门须知
不管测试的组织形式如何，新手在软件测试组织中应该始终抱着一种虚心学习的心态。寻找现有的知识库，同时不要忽略了缺陷跟踪库中的那些“宝藏”。
很多人值得新手学习，测试的老前辈、测试组长、测试主管、开发人员、项目经理等，都是学习的好对象。
勤学好问是好事，应该发扬，但是要注意问问题的技巧。尽量不要每碰到一个问题就跑去问别人，应该先记录下来，累积若干个问题
试读结束[说明：试读内容隐藏了图片]