qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

一个软件测试工程师的成长日记(连载一)

 第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所示。

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




 因为时间周期缩短,和传统瀑布模式相比,迭代开发的进度会紧凑很多。项目组必须定期开会确保项目如期进行。项目的周期称为冲刺(Sprint),每个Sprint通常持续2~6周时间。在Sprint开始之前,项目组会进行Sprint计划会议,安排当前开发周期的任务;而在Sprint结束时,项目组举行Sprint评审会议,对这个周期的交付件进行评审核实;评审会议结束后,项目组还需要进行简明扼要的Sprint回顾会议,回顾这个开发周期中做得好的或需要提高的方面,以便在下一周期提高开发效率。

  在每个Sprint中,为了确保开发进度,项目组还需要举行周期的会议(通常是每天),确定各个小组成员更新已经完成的任务、即将开始的任务及使进度受阻的问题,并通过讨论得出解决问题的方案。这种周期的会议叫做每日站立会议(Daily Scrum Meeting),由Scrum Master主持。

  小艾最讨厌开会了,他认为开会浪费时间却常常没什么有效的结果。但凯文告诉他,每日站立会议有个重要原则,为了避免浪费时间,每个成员的汇报时间必须严格限制,会议的持续时间只能在15到20分钟。更细节的问题都放在会后讨论。这样的安排优势是明显的,既能让所有成员了解项目进度,又不耽误所有人的时间。

  听完凯文的介绍,小艾对敏捷开发条件下的项目运作有了最基本的了解。对于敏捷开发范畴而言,这仅仅是冰山的一角。凯文还列举了许多开发的方法,包括测试驱动开发(Test Driven Development)、极限编程(Extreme Programming)、开发统一过程(Open Unified Process)、结对开发(Pair Development)等。不同的项目根据实际情况会使用不同的具体开发方式。然而,有两样东西是所有这些方法的基础--计划和流程。

  计划定义的是做什么(What)和什么时候做(When)。在项目或迭代的初期,项目负责人要根据需求定义项目的计划,计划的内容包括要执行的任务、任务依赖条件、负责人选、执行任务的时间等。对于测试而言,测试计划的制订非常重要。测试计划详细描述了测试的环境、场景、执行要点、依赖等内容。项目执行完全根据计划实施,因此,好的计划是项目成功的基础。

  流程是项目成功的保障,它定义了怎么做(How)。无论是开发还是测试,每个步骤都有标准的流程。在软件测试中,测试环境的准备有标准流程,没有按标准流程安装的环境就可能有潜在的错误;执行测试的步骤有标准控制流程,没有按流程执行的测试结果是无效的。完全按照标准流程完成的测试,如果存在失败的测试用例,我们就可以很直接地从产品本身找原因,而不用怀疑是错误的执行导致了失败。流程控制每个步骤的正确完成,有了流程控制,软件的质量才得以保证。

  作为菜鸟的小艾对测试工程师的基本功掌握得差不多了,他明白,这些基本功需要在实践锻炼中不断加深理解,才能得心应手,融会贯通。

  1.1.3  培养专业技能

  这天中午,小艾经过凯文的座位,发现他正在专心致志地阅读一本技术书籍。小艾好奇地问凯文,究竟是什么书那么有趣。面对小艾的一脸好奇,凯文细致地解释自己学习的内容:“我在学习脚本语言编程技术。作为测试工程师,开发技术对我们而言也同样重要。为了更好地进行测试,得学点脚本编程知识。”

  “测试工程师也必须掌握开发技术吗?还有哪些技能是测试工程师应该掌握的呢?”小艾有些疑惑。

  “的确,我们的工作应该专注在测试上,但这并不代表我们不需要掌握开发技术。恰恰相反,开发技术是测试工程师应该掌握的基本专业技能之一。先给你解释什么是专业技能,再介绍我们应该掌握哪些专业技能吧。”

  在软件开发团队中,作为软件测试工程师,为了完成测试任务,有一些技能是必须掌握的,我们把这部分技能定位为专业技能。在开发团队里的“专业”,与高等院校中的“专业”不同。开发团队的专业,强调的是长时期从事的行为作业规范,规范保证了产品的质量。

  一名专业的测试工程师,应该把开发技能作为其技能体系的基础。测试人员虽然不需要编写功能代码,但是测试人员在测试过程中需要完成测试代码的编写。掌握开发技能,有利于理解功能实现的方法和逻辑。我们知道,测试就像一把手术刀,务求一击即中要害,不让存在问题的地方漏网。测试工程师掌握了开发方法,基于对开发的了解,更容易设计出有效的测试场景和用例。例如,使用Java EE开发的应用程序,程序的实现逻辑很有可能影响垃圾回收的效率,那么设计测试用例时,应当重点测试功能模块对垃圾回收的影响。又如,使用JavaScript实现的前端页面,在不同的浏览器中的显示状况可能有明显差异,有些脚本是针对特定的浏览器开发的。了解JavaScript的这种特性及开发的逻辑后,设计测试用例时就应当在不同浏览器中针对可能有问题的脚本进行测试。测试工程师应该掌握数据结构和算法设计、设计模式和体系结构,了解不同的开发语言和平台的差异。

  开发技能不仅包括设计和实现功能的技术,还包括发布和部署代码、配置环境的技术。软件产品的测试通常具有严格的版本限制,小版本的差异也完全有可能得出不一样的测试结果。测试人员了解代码的发布和部署,能够评估新代码的影响范围,并根据评估适当地调整测试的内容。当然,掌握代码发布和部署以后,至少不会糊里糊涂地就开始测试,而能够在确认代码的发布和版本都没有问题之后再行动。

  开发团队使用了版本控制工具来管理程序的版本,了解新代码如何进入到软件版本中,对测试人员而言也很有用。在对原始代码进行修改前,程序员或测试人员需要创建一个“缺陷”,“缺陷”意味着系统有需要更新的地方。缺陷创建后,系统会生成唯一的缺陷号码,用于跟踪代码的更新状态。无论是因为加入新功能还是测试失败而创建的缺陷,都通过统一的平台进行管理。有了这种版本控制方法,对代码的任何改动都记录在案,任何引起新问题的线索都得以保留,系统也可以在需要时回滚到任何较早的状态。了解“缺陷”模式的运作,有助于测试人员执行测试或回归,验证缺陷是否修复。

  鉴于测试工程师的专职工作是完成软件测试,因此测试专业技能是测试工程师技能体系的核心。

  小知识:软件测试,从宏观角度而言,是指针对被测试的产品或服务进行的一系列关于软件质量的调查,软件测试结果对软件的拥有者(Product Owner)负责。软件测试还从一种独立的视角为业务运作提供客观评估,这种评估包括软件的质量达标程度及因为某种相应的实现方式而存在的风险等。


 测试得到的是一种相对客观的结果,通过事实和数据对软件的质量进行定义,为软件的拥有者提供决策的参考。测试通过执行程序或应用的方式,达到发现存在的错误或缺陷的目标。至于测试,使用的方法则是多种多样的。理论上,任何方法,只要发现的错误或缺陷是确实存在的,都是可行的测试方法。但是在项目实践中,我们不可能把所有可能的方式都用上,而只能采取最有效和可控的方法。有效,是指这种方法有效模拟真实的应用,并有效地暴露潜在的问题;可控,指的是使用方法有明确的步骤,通过相应的步骤可以使暴露的问题重现。

  真正的测试中,有效可控的测试方法通常有两类,分别是白盒测试(White-box Testing)和黑盒测试(Black-box Testing)。

  白盒测试指测试人员可以直接访问内部数据结果、算法及其代码实现的测试,常见的方法包括编程应用接口测试、代码覆盖率测试、缺陷注入方法等。通过调用应用程序的公有或私有接口,验证返回内容的正确性的方式,是很常用的白盒测试方法。通常一个测试用例可以用于验证一个被测的接口。如果需要验证一个代码分支,还可以把分支需要使用的多个接口调用放在一个用例中。

  代码覆盖率测试是检验代码是否满足指定覆盖率的测试。例如,可以设计一个测试,通过改变输入条件,使程序中所有代码行都被执行至少一次,并检验输出是否符合预期。覆盖率测试在一般条件下,最大限度地覆盖代码,评估代码的整体质量。缺陷注入关注代码在错误和临界条件的表现。错误和临界条件在所有输入条件中只占小部分,但这部分输入却非常关键,而且存在问题的可能性较大。测试涵盖了错误和临界条件,就能保证代码的健壮性。健壮的程序不仅能处理期望的输入,对于“不速之客”,同样能够从容应对。

  白盒测试用最直接的方式,从根源上发现程序中的缺陷。然而,底层代码的逻辑往往错综复杂,分支繁多,白盒测试的方法需要测试人员对实现的细节比较了解,方可设计出有效的测试用例。而且,因为时间等条件的限制,要覆盖所有分支的所有条件,简直是个“不可能的任务”。于是便有了黑盒测试,通过触发业务相关的功能点,检验集成条件下系统的正确性。虽然不能期待黑盒测试方法能覆盖更多的代码分支,但这些方法针对的都是和实际系统应用相关的分支,因此黑盒测试对于评估系统是否达到需求是至关重要的。理论上,只要黑盒测试的用例设计得足够细致,测试能发现所有应用中可能存在的问题。当然,因为进行黑盒测试的时候系统是集成的,所以发现问题后,需要“打开黑盒子”,用额外的工作定位问题的确切原因。相对而言,白盒测试发现问题后,定位原因的过程会简单得多。

  综合应用白盒测试和黑盒测试,可以达到有效测试系统的目的。

  定义了测试方法,测试工程师应该明确的下一个内容是测试的执行。大型电子商务系统的业务逻辑非常复杂,集成测试往往需要涉及多个功能模块。如何执行测试用例问题,实际上是如何提高工作效率的问题。

  对于界面操作、简单的功能验证用例,通常可以使用直接手工操作的测试方式;但是对于大多数逻辑复杂或者有特殊要求的测试用例来说,自动化测试是主要的测试执行方法。

  手工操作的优势是方便灵活,只需有明确的测试用例作为指导便能执行,不需要花额外的时间准备完备的自动化测试材料。我们甚至可以通过手工操作的方式执行随机测试(Adhoc Testing)。探索式测试不使用可识别的测试用例,而采用相对“随机”的方式验证某些功能点的正确性。但是手工操作的重复开销是测试策略的设计人员必须重视的。由于测试步骤必须通过手工的方式执行,重复执行测试用例的时间与资源开销和第一次执行基本上没有任何区别。对于一线测试工程师而言,不停地重复手工测试用例是个无法摆脱的梦魇,至少热衷于接受新挑战的小艾这么认定。

  自动化测试则能弥补手工测试在重复开销方面的不足。自动化测试,顾名思义,就是测试过程并不需要人工干预的测试方式。其优点是一旦测试的材料(包括自动化工具、自动化测试环境和测试脚本)准备好,测试可以在无须人工干预或在有限度的人工干预的条件下重复执行。对于流程复杂的测试场景,自动化测试在节省重复执行的资源的同时还能很好地控制测试质量和效率。当然,自动化测试对测试团队的组织和技术要求更高。要进行自动化测试,首先,测试团队必须有一套完备的测试工具集;其次,测试人员需要掌握测试工具的使用方法,包括如何编写自动化测试代码,如何执行并收集结果等;最后,对测试资源的维护也有更高的要求。自动化测试脚本和对应的测试环境应当严格归档保存,以备日后查询和重复使用。

  作为一个成熟高效的测试团队,手工测试和自动化测试都是不可或缺的测试执行方法。两者优势互补,可以有效保障软件产品的质量。

  在产品开发过程中,特别在使用敏捷开发模式的项目中,新功能的完成大多是分阶段的。功能点在不同的迭代中陆续发布,同时,在新的发布中还会包含对老版本的问题修复。作为测试,除了需要测试新发布的内容,还必须验证已经存在的功能是否正确,存在的问题是否已经修复。这是测试执行中很重要的一环--回归测试。就理论而言,只要有新的软件版本发布,对执行所有测试用例的回归测试是必需的,因为只有这样,才能从事实上保证所有功能在最新版本中的正确性。随着开发完成的功能越来越多,回归测试中要执行的测试用例也随之增加。自动化测试在重复执行方面的优势正好能满足回归测试的这种要求。

  作为测试工程师,掌握了测试执行方法,可以认为已经掌握基本的专业技能了。然而测试工程师专业技能的涵盖范围其实非常广,因为高质量的测试要求工程师掌握更多的技术,包括架构设计、软件开发技术等。更好地掌握这些专业技术,目的是更好地服务于测试,测试的目的则是发现和排除软件中存在的问题。

  “发现、解决问题其实是一种艺术。”凯文语重心长地指导小艾,“等你熟练掌握基本的测试专业技能的时候,我们还会从更深入的层次探讨测试的核心价值和技术。”

  (未完待续)

posted on 2013-05-02 10:42 顺其自然EVO 阅读(509) 评论(1)  编辑  收藏 所属分类: 测试学习专栏

评论

# re: 一个软件测试工程师的成长日记(连载一)[未登录] 2016-08-10 22:47 哈哈

真好
  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 
<2016年8月>
31123456
78910111213
14151617181920
21222324252627
28293031123
45678910

导航

统计

常用链接

留言簿(54)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜