第1章 上班第一天，新人培训

　　1.1  测试专家的第一步

　　小艾是某名牌大学计算机科学专业硕士毕业生，这天是他离开校园走上工作岗位的第一天。他将成为大型外资IT公司IBM的软件测试工程师（Software Test Engineer），开始一段新的旅程。

　　1.1.1  我是菜鸟

　　在离开校园以前，小艾对将要从事的工作几乎一无所知。记得面试时被问及对测试的想法时，他的理解是，测试就是给产品挑错吧，目标应当是保证产品以高质量交付给用户。面试经理告诉他，其实测试是软件开发过程中必不可少的重要流程。在追求质量和效率的软件工程里，如何有效地对复杂的软件半成品进行测试，其实有许多问题值得工程师们去思考和探索。软件测试工程师的工作将很有趣、充满挑战。于是，对新事物充满好奇心的小艾欣然接受了软件测试工程师这个职位邀请，充满期待地走进这个他完全不了解的神秘领域。

　　产品开发组的同事，包括组长和老员工，对小艾这只菜鸟照顾周到，一会儿工夫他就把入职的流程办妥，工作的机器也准备就绪。坐在新的座位，小艾开始憧憬自己的新工作。可是测试却是一张陌生的面孔，让他有点无所适从。于是，小艾找到公司给他安排的“导师”凯文，希望凯文能帮他排解困惑。凯文是测试组组长，一位具有丰富工作经验的老员工。未来，就从这一刻开始向小艾展露出微笑。

　　“凯文，我对将要从事的工作一无所知。你能告诉我测试工作都包含些什么内容吗？我们应该如何做测试？什么时候可以真正开始工作？”

　　凯文对小艾的问题一点儿也不陌生，这些问题不正是几年前他入职时的困惑吗？“小艾，别着急，请慢慢听我说。我也像你一样，是从菜鸟一步一步成长起来的……”

　　经过与凯文的谈话，小艾心中的一团迷雾逐渐消除了。

　　原来，在大型软件开发团队中，测试被分成很多种类和步骤，每种测试有针对性地模拟使用测试对象的场景，并试图找出测试对象的潜在问题和缺陷（Bug）。在确定原因后，制定严谨完善的解决方案并根据方案修复缺陷。测试其实是发现并解决问题的过程，而其目标则是让软件产品以尽可能高的质量交付给客户，使软件产品中存在的问题尽可能少，这样，软件的用户可以得到最完美的使用体验。

　　除了小型项目，进行完全（各种输入和前提条件的组合）的测试是不可行的。可行的方法是运用风险分析和不同系统功能的测试优先级，来确定测试的关注点，从而替代穷尽测试。软件开发本身是追求产出和投入比的工程性过程。因此，考虑测试的内容和方式时，都应当以高产出投入比为最终目标，最大化地利用现有资源排除潜在的问题。

　　小艾听说过风险控制，在软件测试过程中，风险控制是通过专业有效的方法实现的。测试团队由许多个测试分队组成，每个分队的测试任务和方法都具有高度的针对性。

　　小艾回想，在学校的时候，他曾经参加过软件工程课程的项目实训。在项目中，测试很简单，其目的仅仅是验证开发的功能点是否正确并与设计一致。测试是在所有功能开发完毕后才开始的。当时项目规模很小，从计划的时候开始，大家就没有仔细地考虑过怎样做测试。由于项目组人数很少，在功能开发阶段大家也无暇顾及测试，而是到了功能开发已经完成后，大家才匆忙地花些时间测试。当然，这种测试非常简陋，没有计划细节，方向也不清晰，测试过程中的所有流程都手工操作一遍。发现问题则随时修改代码，如果修改后流程能走通，就认为测试已经通过了。

　　通过凯文对测试的类型和当今流行的开发模式的介绍，小艾发现测试远不是从前软件工程项目实训测试那般随便和简单。软件测试是一个严谨、全面且有条理的过程。这个过程中包含了多种测试类型，每种测试类型都有针对性地验证软件，发现相应的问题。测试就像河流中一张精心编织的网，软件的功能和流程就像河流中的鱼，要通过这张网的鱼必须足够优秀才能最终存活。正是这种“优胜劣汰”的思想，保证软件只有通过了测试这张网才得以与用户见面。

　　凯文娓娓道来，小艾对IBM的测试方法有了初步的了解：原来测试的种类可以如此多种多样。

　　单元测试是和开发最接近的一种测试。开发人员编写单元测试用例并执行，验证单元模块是否得出预期的结果。在敏捷开发模式中，有一种流行的开发模式叫做测试驱动开发（Test Driven Development，TDD）。测试驱动开发的核心就是把单元测试用例先做好，功能开发以通过相应的单元测试用例为目标。单元测试是粒度最小的软件测试，小粒度能保证复杂系统中的每个“螺丝钉”都质量合格。通过了单元测试的代码才可以继承到系统中，进行进一步测试。

　　功能测试是通过黑盒子模式发现代码集成后存在的功能问题的测试。顾名思义，功能测试关注的重点是系统的功能。通过执行自动或手动的测试用例，可以验证相应的功能点是否正确。只要测试用例设计完整，功能测试的网能把最终用户可能遇见的功能问题都“提前”发现并解决。可以说，功能测试保证了提供给用户的是产品而不是一堆垃圾。单元测试和功能测试的区别主要是粒度的不同。单元测试关注的是一个最小的代码片段，如一个类或接口，而功能测试关注的是一个完整的业务功能。

　　功能测试通过后，性能测试就随之开始了。性能测试是重点验证软件的非功能性需求的测试。企业级软件通常用于应对复杂苛刻的用户场景。在软件设计和安装的过程中，有许多细节能提供软件的性能，包括吞吐率、稳定性、可靠性等。性能测试通过自动化的方法模拟真实用户并发访问的场景，以验证系统的性能指标或发现其性能瓶颈。性能缺陷常常不是显而易见的，有时候得通过复杂的场景模拟方可重现问题。由于性能问题的复杂性，要定位问题的原因也是一个艺术的过程。通过了性能测试的软件系统从根本上保证了用户体验和长远利益。

　　正式版本发布前，测试组还要组织成品测试（GMV），测试软件的安装、部署、发布等情况，确保软件能最终顺利地安装到用户的环境中。通过集成测试后，软件的质量有了进一步的保障。

　　软件正式版本发布以后，根据用户的反馈，产品组需要发布多个小版本。发布以前，当然也要有针对性地测试小版本的功能、性能，以及和正式版本的兼容性。小版本的开发和测试周期比正式版本短得多，因此对测试团队的项目管理要求更高。

　　“在IBM，为了保证软件质量而进行的测试是全面而苛刻的。”凯文说，“等你完成了新员工培训并开始接触项目时，你将有更多机会从方法到实践了解我们的软件测试。”

　　1.1.2  苦练基本功（1）

　　小艾所在开发团队所负责的产品是电子商务平台。电子商务平台是一个功能强大的企业级应用，它支持多种计算机平台。要成为一名合格的测试工程师，首要的就是熟练掌握基本功。所谓基本功，指的是作为任何开发团队的一员，都应该掌握的基本知识和技能。

　　小艾发现上大学时学习的专业课还是非常有用的，诸如数据结构与程序设计、计算机组成原理、操作系统原理等。但这些课程大多只注重理论，缺少在真实环境中实践的经验。公司的软件开发通常都有比较成熟的基础设施，对于新人来说，了解开发平台和方式也是锻炼基本功的一部分。

　　操作系统是平台的基础。IBM的产品通常都支持多种流行的操作系统，如Windows，UNIX，Linux等；为了满足更大规模的应用，产品还能提供对大型机的支持。小艾最熟悉的操作系统是Windows，在学校和日常生活中基本都用这个系统，而对UNIX和Linux却是一知半解。在开发组的数据库里，小艾学习了大量关于UNIX/Linux基础的材料。在学习的过程中，他有机会操作各种平台的机器，这样在实践中学习效果是最好的。几周下来，小艾已经掌握了UNIX/Linux的系统管理知识和编程基础。他发现，在简洁的黑色文本界面背后，隐藏着超乎想象的强大计算能力。

　　学习了操作系统基本知识后，小艾满怀兴奋地找凯文：“我是不是可以开始测试产品了？”凯文摇头说：“离测试还远着呢！不过你可以接着实践测试环境搭建了。”所谓测试环境搭建，是指在操作系统基础上，安装测试需要的应用程序，并部署测试的功能代码，准备测试数据，建立起一个可供测试的环境。电子商务系统是基于中间件的网络应用程序，因此，必须从安装服务器程序开始。一个完整的企业级网络应用程序，通常需要集成多个服务器，包括网络服务器、应用服务器、数据库服务器等。坐在机器前，小艾发现搭建测试环境是一个艰巨的过程。

　　测试环境的搭建从安装网络服务器开始，接着是数据库服务器和应用服务器的安装。网络应用程序作为企业级应用，部署在应用服务器上。面对一系列的设置步骤，小艾感到头晕目眩。一连几天，小艾都在直接和服务器打交道。在UNIX/Linux上搭建测试环境，用户的权限管理是关键的部分。因为涉及许多手动操作的部分，一时疏忽引起的用户权限错误会导致搭建失败。小艾自问还是很有耐心的，这次也被测试环境安装折腾得“体无完肤”。经过凯文的多次“指点迷津”，在安装配置好服务器以后，电子商务应用程序也安装好了。

　　小技巧：正确的流程和步骤一定要及时记录。有了流程和步骤的指引，可以避免大量不必要的重复劳动。

　　这也仅仅相当于一个新建的购物商城做好了“硬装修”，商城还是空空的，还不足以接受业务流程。根据测试用例的要求，需要安装并激活业务模块。网上商城的经营模式、页面的样式、能够提供的功能等特性，都是通过激活业务模块并配置数据等步骤决定的。

　　激活了业务模块以后，工程师的测试才可以开始。

　　领教了测试环境安装的烦琐步骤，小艾想，要是测试工程师不得不耗费大量资源兼顾测试环境的安装和配置，那么将难以保障软件测试的质量。从资源利用优化的角度而言，这似乎也不是很好的方式。

　　带着疑惑，小艾找到了凯文，“环境安装耗时费劲，测试人员必须每次都从头到尾安装测试环境吗？”

　　凯文说：“看来你对环境安装的难度有了很深的体会啊。你的顾虑项目组很早以前已经考虑到了。我们发现，更细的分工是提高效率的源泉。你应当看看我们用什么样的方式实现了测试平台的高效搭建。”

　　凯文说，其实许多新同事也有着和小艾一样的疑惑，解决环境安装问题的方式是执行构建测试（Build Verification Testing，BVT）。

　　的确，构建测试是个烦琐、重复性的过程。为了有效搭建环境，避免人为原因的错误，采取的策略是最大程度上地使构建过程自动化。因为环境的原型和步骤基本上是类同的，这种条件很适合自动化。于是工程师们使用构建了参数化的脚本、响应文件等构建测试的元素，有了这些元素，构建过程不再每一步都需要人工干预，出现错误的可能性有效降低。当然，由于平台本身的复杂性，自动化元素的构建由构建组专门维护。构建组把这个过程称为构建测试。通过测试验证环境安装的正确性。

　　软件的构建（Build）本身是依赖于Java的，因此没有平台依赖性。但是，Java虚拟机是安装在不同的操作系统中的，于是测试环境的安装就有了平台依赖性。构建完整的测试应该包括对多种平台的支持。不同操作系统平台结构通常很不一样，需要提供有针对性的自动化构建程序。构建完成后，构建组还必须完成对所有支持的平台的构建测试。

　　有了自动化的构建程序和构建测试的步骤，可以保证测试环境正确和顺利地安装。但是，每次安装还是得花时间的。熟练的工程师使用构建程序在某个平台构建一个测试环境得花大半天时间。小艾从兴奋转为沮丧：每次安装半天时间的成本并不小啊，大家测试环境的资源耗费问题还没有解决。

　　幸运的是，开发实验室利用虚拟技术构建了基于不同平台的测试镜像。有了虚拟技术，时间和步骤也是“可复制”的。由于测试环境必须支持多平台，使用自动化方式搭建第一个测试平台的时间是不可节省的；但是，第二个、第三个测试环境的搭建时间确实可以节省。奥秘就在于虚拟技术。成功搭建一套测试环境后，就可以把这个环境保存成镜像（Image）。以后任何时间需要再使用这套环境，不必重新安装，仅需要把镜像恢复，并替换必要的机器信息即可。虚拟技术被多个平台支持，包括AIX、Windows、UNIX/Linux。用于恢复镜像的硬件环境既可以是实际存在的，也可以是虚拟的。

　　虽然没有仔细了解过虚拟技术，但小艾在学校的时候使用过Ghost克隆软件。凯文说：“虚拟技术的原理和Ghost有相似的地方，随着使用的深入，你会对虚拟技术有更多的认识。”

　　对测试环境安装有了初步的了解，作为菜鸟，小艾接着需要知道的是中间件技术。要知道，功能强大的电子商务平台是建立在IBM的WebSphere中间件基础上的。凯文开始给小艾介绍一些基于中间件的应用服务的基础内容。

　　中间件（Middleware）是提供系统软件和应用软件之间连接的软件，以便于各种部件之间的沟通，特别是应用软件对于系统软件的集中的逻辑。中间件技术在现代信息技术应用框架，如Web服务（Web Service）、面向服务的体系结构（Service Oriented Architecture，SOA）等应用中应用得比较广泛。中间件不提供具体的功能，但它却是系统中各个部件有机连接的桥梁。中间件可以提供对外围服务器，包括数据库服务器、应用服务器、Web服务器等的支持和管理。中间件技术建立在对应用软件部分常用功能的抽象上，将常用且重要的过程调用、分布式组件、消息队列、事务、安全、连接器、商业流程、网络并发、HTTP服务器、Web服务等功能集于一身或者分别在不同品牌的不同产品中分别完成。

　　接下来的日子里，小艾开始研究WebSphere中间件提供的功能。经过一段时间的学习，他掌握了通过应用服务器对应用程序进行管理和监控的方法。这部分知识对于测试中发现和解决问题起着关键的作用。

　　经过基本能力的训练，小艾基本上已经达到了进入项目组的要求。然而，对于项目如何运作，如何确保项目顺利达到预期结果，小艾却还是一知半解。接着，小艾在凯文的指导下，认识了敏捷项目管理的基本知识。

　　对于敏捷开发（Agile Development）的定义，工业界其实还没有标准的定义，而相关的描述倒是五花八门，各种定义也出现在出版物或网络博客中。缺乏标准定义，其实是因为敏捷开发的实现方式非常多样化。我们可以容易地找到关于敏捷的方式、方法、实践及技术等的描述。在IBM的软件开发和测试中，团队使用了多种流行的敏捷开发方式进行项目管理。使用敏捷项目管理的目的并不复杂，是为了提高开发效率，激发团队的积极性并尽可能降低项目失败的风险。

　　提到敏捷开发，会把某种开发方式作为“非敏捷”方式来对比，而这种开发方式通常会是传统的瀑布开发模型。在瀑布开发模型中，整个系统的开发被划分成需求分析、设计、实现、测试、集成和维护等阶段。这种划分本质上是把不同性质的项目内容分隔到不同的阶段，而某个阶段则专注地进行某种任务。专注在许多情况下带来了高质量，单一流程的划分却很容易带来资源浪费和失败风险的增加。如果在一个阶段，项目组只完成一组相同性质的任务，那么，团队中其他无关的人员在这段时间里就无事可做了。项目的成果必须到最后阶段才完成，中间任何步骤出现差错都有可能导致项目全盘失败，这样的项目风险是很高的。

　　敏捷开发从根本上避免了瀑布模型的弱点，它有两个核心点--迭代开发（Iterative Development）和增量开发（Incremental Development）。

　　迭代开发是一种“重复时序安排”的开发方式。迭代开发把一个完整的瀑布模型开发流程分成多个迭代，每个迭代可以看做独立的开发过程，其中包含了项目的主要步骤，如设计、开发和测试等。把完整过程分成多个持续时间较短的迭代，其好处是生产的周期变短了，每个完整的周期都会产出相应的产品，这种方式有利于在完整项目开发的过程中跟踪和控制开发进度及产品质量。

　　1.1.2  苦练基本功（2）

　　增量开发用的则是一种"分段完成"的策略。在增量开发模式中，系统中不同的部分被安排在多个阶段完成，各个部分完成后再集成到系统中。

　　在敏捷开发模式中，迭代开发和增量开发的策略通常会被同时使用，并统称为迭代开发，迭代开发框架如图1-1所示。

　　增量地实现系统的思想是迭代开发的基础。项目成员通过不断学习和总结，使开发效率不断提高，同时避免在后期的迭代中重犯某些错误。因此增量开发对于团队的进步也很有好处。

　　......

　　查看全文：http://www.51testing.com/html/44/n-844944.html