完美测试:软件测试系列最佳实践



完美测试:软件测试系列最佳实践

朱少民 主编

ISBN 978-7-121-16078-3

20123月出版

定价:59.00

16

360

宣传语:本书可以使读者领会到软件测试的距离之美、空间之美、技巧之美、辩证之美以及贯穿测试过程的平衡之美。

每个人都怀有梦想或理想,测试人员也不例外,希望将自己的工作做得比较完美。本书力求通过一些典型案例告诉大家什么是完美测试,又如何做到完美测试。在给出的例子中,不仅包括功能测试、功能的异常测试、不同平台的功能测试和一些崩溃问题的处理,而且包括国际化测试、性能测试、用户体验测试、Accessibility测试等,并用较大的篇幅讨论了自动化测试。

为了达到完美测试,建立良好的测试体系、使产品具有可测试性以及缺陷预防等更为重要,对此,本书也做了讨论。最后,本书还展示了软件测试之美,使读者可以领会到软件测试的距离之美、空间之美、技巧之美、辩证之美以及贯穿测试过程的平衡之美。

虽然本书还很难覆盖完美测试应具备的各种方法和实践,但目的在于抛砖引玉,使读者能通过最有效的手段(包括方法、技术和工具)完成所有必要的测试,实现事先所要求的需求和代码的测试覆盖率,最终能准确地给出软件产品一个完整的质量评估,使测试达到相对完美的水平。

本书适合于软件测试工程师、产品管理和管理人员阅读,也适合于大专院校计算机相关专业师生作为参考用书。

业界热评

在工程上不存在完美(perfect)测试,但存在适应被测产品、开发环境和质量标准的良好(good)的测试。然而,卓越的工程师会精益求精,用务实的态度和正确的方法去逼近完美。《完美测试》通过一组生动的案例,传达了资深工程师的经验与思辨,展现了不同语境下测试实践的方法与技巧。在测试的漫漫征途上,这些有价值的内容将助您一臂之力。

——微软总部测试工程师  史亮

本书来的很是时候,在测试行业发展到今天,很需要有一本书能让我们全面、深刻地去体会测试之美。在我看来,本书既有广度又有深度,不管是初踏入还是摸索几年的测试同仁,读后都会有较大收获,能切实感受到测试的魅力。

——淘宝资深测试工程师  冯思荣(花名侯风)

软件测试金字塔体系,1个中心、5个要素、21个关键域、34种方法构成的创新性方法论,值得每一位从业者品悟。此外,丰富的最佳实践案例,会让你生出身处其中的默契,更有让人眼前一亮的测试创新点,贯穿于不同关键域及测试历练中。

——《软测之魂》作者 深圳迈瑞测试经理  肖利琼  

对所有从业者而言,本书都能给出非常好的测试思想、方法的提升路径与实践。除大范围阐述各种测试手段并提供其经典案例,本书在寻常的手工功能测试和自动化测试方面,提出诸多不为人知的方法与实施细节,实属难能可贵。

——淘宝资深测试工程师  高翔(花名季哥)

朱老师做为横跨工业界和学术界的测试前辈,一直都走在软件测试行业发展的前沿,在测试理论和实践等方面有较深厚的积累。这次贡献这本集测试理论和最佳实践于一体的著作,实在是国内测试同行的福音。

         ——Oracle资深技术工程师 朱波

本书深入浅出地涵盖了测试领域新技术的方方面面,从宏观层面高屋建瓴地抽象出一幅清晰的测试全景图,微观层面又融合业界众多资深测试专家的实战经验,让整幅图活灵活现,是非常值得推荐的一本好书。

——百度高级架构师  朱磊  

我认为本书是最权威的软件测试著作之一。定义出清晰的框架和过程,价值远超大量同类书籍。完美是测试最期待的,想知道如何一步步做到完美,请选择它。

——佳音游戏高级测试工程师  陈子昂

一本理论与实践结合的佳作,用金字塔形象诠释软件测试体系,描绘出一幅完美的测试蓝图,有助于清晰梳理测试理论;汇集众多精英的最佳实践,涉及之广令人叹为观止,极其便于将所读所悟应用到实际工作、学习之中。

——@让测试飞起来

本书与通常所见的技术类书籍不同,从一开始就引入了“人”的概念,与当前软件工程领域越来越回归“以人为本”的理念相通。它也能帮我很好地重新梳理公司的质量保证体系,并提供一些搭建测试架构的更好的思路。

——广联达质量管理部经理  彭月

受本书主编朱少民先生的委托已有时日,无奈平日工作繁忙没有余暇。此时在去往中国的飞机上,不再有电话、邮件、微博等的干扰,相对而言,或许这段时光非常适合完成这样的事情。这次去中国,是要参加思科中国研发中心的春晚,而本书正与思科(合肥)研发中心有着很深的联系。少民曾是思科-网迅(中国)软件有限公司的资深测试总监(网迅,即WebEx,于2007年被思科收购),现在同济大学软件学院任教。这本《完美测试》,是他和思科(合肥)研发中心的九位同事、思科(苏州)研发中心的一位同事共同创造的成果。这是思科文化所提倡的,同时也是我为思科中国研发团队深感骄傲之处。本书的出版将承载思科中国研发团队更多的知识共享,进而服务社会、贡献IT界的社会责任感。

去年,我作为思科全球副总裁全面管理思科协作技术集团的研发团队,而少民由于个人职业发展原因已于更早的时间离开思科,因此我们没有一起工作过。在之后的日子里,我更多地通过其他同事与各种报道了解到一些他的情况:他在2000年加入网迅,拥有优秀的软件开发与项目管理经验。但那时,国内软件测试才刚刚起步,业界对软件测试还缺乏足够重视,即使是软件从业人员对于专业的软件测试同样知之甚少。然而,他出任合肥网迅软件公司软件测试经理之后,迅速补充相关知识,同时在美国接受一年有余的在职培训,旋即打造出一支优秀的测试团队。在过去的十多年中,这支团队圆满完成来自美国总部交付的各种测试任务,而WebEx产品最终靠质量与创新在其所在领域全球市场获得第一份额。

然而,他本人并不满足于现状,一直期望从更高的层面来把握软件质量管理与测试工作,这种意识促成他不断把实践上升为理论,再将理论应用于实践,并保持和业界分享,最终在短短数年便成为国内最具知名度的软件测试专家之一。少民对于软件测试的把握,早期着重全局,举凡测试知识,皆能梳理充分而精致,所以他的著作可以作为大学教科书反复再版,其中早期的《软件测试方法与技术》,已入选十一五国家级规划教材,为软件测试领域教材的佼佼者。稍后的《全程软件测试》则是这种全局观念的集大成者,它提倡全过程的软件测试,即在项目开始就引入软件测试,从需求评审、设计评审到验收测试、部署验证,直至在线测试,将质量保证贯穿整个软件生命周期。之后,他还对于软件测试的热点与新的测试方法倾注心力,《轻轻松松自动化》是对近几年自动化测试和开源软件热潮的一个响应,而今《完美测试》则尝试以案例教学的方式,给人以更多的软件测试实际工作的切身体验。这次《完美测试》的阵容更强,不仅有自动化测试方面的好手,而且还有可达性、易用性、探索式测试等各个方面的资深测试工程师的参与。《完美测试》不仅涉及前端测试,而且包含后端测试;不仅介绍传统的测试流程,而且还着重讨论了敏捷测试流程。

软件的生命力最终取决于软件质量,但是我们更要时刻关注软件质量内涵的发展与变化。早期,人们只是简单地关注软件功能,只要功能运行正常就可以交付使用;后来,人们逐渐开始关注性能、安全性、可靠性和可用性。而在互联网时代,人们除了关注功能、性能、可靠性之外,更特别关注安全性和易用性,尤其是用户体验。互联网产品的用户(如GoogleFacebook、腾讯的QQ等)不只是成千上万,而是几千万,甚至几个亿。面对这种海量用户,完全无法实施传统培训。此时,只有靠产品的优秀设计来提高产品的易用性,让用户获得良好的体验,甚至愉悦的心情,产品才能使用户最终满意。这正是我们经常说的,产品的质量就是用户的满意度。此外,随着社会文明的不断进步,弱势群体也越来越得到重视。与此相应,软件设计和实现开始充分考虑残疾人士的使用,并形成了一套关于软件的Accessibility标准。而《完美测试》在易用性、Accessibility测试方面也有很好的经验分享,这应是本书的一个亮点。

互联网的发展对于软件开发的另一冲击是软件产品发布的频率。在互联网时代,软件服务竞争日趋激烈,促使企业要及时响应用户的变化,快速完成需求的实现和变更,及时推出有竞争力的产品。这也就是敏捷方法流行的主要原因,不论是在国外还是在国内,许多公司都在积极推行敏捷开发流程及其实践。本书则在敏捷测试上不仅有思想、流程上的指导,而且还有具体的案例示范。

《完美测试》以最佳实践的形式勾画与传递软件测试的知识和经验,以实际案例来反映全局的软件测技术、方法。陆游所谓纸上得来终觉浅,绝知此事要躬行,那么这本书算是往躬行层面前进一步。本书的内容都是作者们实际工作中的体会与总结。我很乐见这样的工作经验能够铺陈成章,分享给更多有志于软件工业的读者。众所周知,中国的软件业比之硅谷还有一定差距,随着软件外包业在中国的持续繁荣,这种差异必然逐渐缩小,而这项工作跟每位软件从业者息息相关,这是我们的机会,也是我们的责任。

最后,希望更多的读者从本书受益。

许良杰, 思科公司全球副总裁

——从完美说起

当写本书的时候,出于一种心愿,出于一种理想,取书名为《完美测试》。当真正开始写作时,又觉得是一件很困难的事。首先如何理解什么是完美的测试?然后又如何把测试工作做得完美?于是在微博上发出帖子,问大家如何理解什么是完美测试,但得到的答案也是不一样的。

    @张定勇_darren:值得思考的问题。我的理解,软件测试是建立对产品信心的过程,将产品引发最终用户损失的风险降低到一个可接受的程度。因此,完美只能是相对的,或者说测试永达不到完美的程度(这也是测试的魅力所在)。比如我们都知道的一个基本事实是,产品的缺陷是不可能100%消除的。

    @小马老矣:简单地讲,满足用户需要就可以了。从实践来看,重在测试需求分析。根据软件需求,先从功能角度,分析所有的功能点及非功能需求,并根据实际应用分级;其次是从技术角度,分析可能对功能产生影响的因素,根据风险高低分级。以此产生测试用例,并妥善安排测试计划。

    @Eagle_Yu:我心中完美测试的结果是产品推出之后,所有使用该产品的客户都认为它是一款设计合理、性能稳定并且没有什么Bug被发现的产品。(从实现完美测试角度看)我们测试人员希望产品初期PMRDQAUED能通力合作:即产品经理能明确规划出用户的需求,用户体验设计能设计出符合用户操作习惯的用户界面和性能,开发人员能分析出将要做的产品技术上是否可行、减少正式开发过程中因为技术达不到而做的返工,品质保证能明确测试范围。而且,测试计划达到测试范围明确、阶段目标清楚、风险分析准确、可执行性高。测试案例达到覆盖面广、优先级权重准确、可维护性强。测试人员经验丰富、时间充裕。同时,开发部门开发能力强、产品高内聚、松耦合。

    @狂奔的小溪流:要做到完美测试,就是在规定的时间内通过各种测试方法把软件各个方面(如功能、性能……)的质量状态全面地体现出来。

    @赵枚:一个自证明的系统!当这个系统交付的时侯,已经完成了其各部分的功能验证。

那我个人的理解又是如何呢?我认为完美测试是通过最有效的手段(包括方法、技术和工具)完成所有必要的测试,达到事先所要求的功能需求和非功能需求的测试覆盖率、代码的测试覆盖率, 最终能准确地给出软件产品一个完整的质量评估。因此,最有效的手段、必要的测试、测试覆盖率、准确又完整的质量评估是构成完美测试的关键要素。

1  最有效的手段:即以最短的时间或最少的资源来有效地完成给定的测试任务。自动化测试方法是一种有效的方法,但不一定是最有效的,需要具体问题具体分析。自动化测试方法的投入产出比(ROI)在某些测试场合低于手工测试的ROI,例如一次性的软件项目(而不是产品的系列开发),这时自动化测试方法就往往没有手工测试效率高。适合用自动化测试方法就一定要用自动化测试,该用手工测试的(如软件产品的易用性测试等)就一定用手工测试。

2  必要的测试:没有执行多余的测试任务,也没有漏掉该执行的测试任务。不需要的测试功能模块、不需要测试的特性、不需要测试的代码等能被隔离出来,它们会被排除在测试范围之外;而且能确定代码改动的影响范围,能够确定测试任务的优先级,从而根据有限的资源和时间,完成所需要执行的测试任务。如果时间非常有限,就完成优先级最高的那部分测试;如果时间稍微宽松些,就完成更多的测试任务,包括优先级较高的那部分。如果有足够的时间,那就完成所有任务的测试。

3  测试覆盖率:没有覆盖率的衡量,就不能确定测试的效果、不能确定完成了多少应有的测试任务;没有覆盖率的衡量,就很难知道测试什么时候可以结束;没有覆盖率的衡量,就难以对测试工作进行评估,甚至难以控制测试的进度。测试覆盖率包括两方面:实际用户需求验证的覆盖度和被测试代码的覆盖度。

4  准确又完整的质量评估:在完成必要的测试之后,并有能力发现测试范围中的软件缺陷,然后根据所发现的缺陷,以及前面所参与的需求评审、设计评审和代码评审的结果,针对待发布软件的各种质量特性做出准确的评估,从而能够全面地、准确地了解软件产品的质量,从而能快速地对软件产品能否发布做出正确的判断,对如何持续改进软件质量也能提出明确的举措。

 

那么,又如何将测试工作做到完美的程度呢?不外乎从人、流程、技术等方面去考虑。人是决定的因素,又是不够稳定的因素,把每个测试工程师都打造成优秀的测试工程师,几乎不可能。但是,我们打造一支优秀的测试团队是完全可能的。即团队的每个成员都有特长,在某个方面有很强的能力、形成互补,这样,从团队来看没有弱项。基于一支优秀的测试团队,我们就能建立或引入良好的测试流程,拥有良好的测试方法、技能,最终交出一份满意的答卷。

谈到测试流程,首先还得考虑整个组织的研发流程,测试流程也只能算研发流程的一部分,需要和产品开发、项目管理流程和谐共处。如果开发采用IBM的统一过程模型(RUP),测试流程可以采用迭代的W模型;如果开发采用敏捷开发,测试也得采用敏捷测试的流程。即使选用W模型或敏捷测试模型,如何细化流程、如何引入最佳实践等问题还是需要仔细考量的,针对不同的团队、不同的项目类型需要定制、剪裁软件测试流程。例如,互联网创新产品的开发,对软件缺陷有一定的容忍度,软件测试强调协作、灵活和效率,比如某些对于缺陷零容忍度的关键系统(如金融系统、交通自动控制系统等)对缺陷是零容忍度,在测试流程上要严格、规范得多。

从技术上看,构建覆盖整个测试流程的自动化测试框架是重中之重。总体上看,基于自动化测试的方法能够提高测试的效率,也能更好地衡量测试覆盖率,但是自动化测试工具只是工具,很难进行测试需求的分析和设计,测试人员自身的智慧、技术能力依旧是最重要的。他们需要理解软件系统架构的设计、深刻了解软件实现的技术环节,包括如何让开发人员保证软件的可测试性,从而找到有效的测试方法,并能在技术上保证测试的顺利进行,获得高效的生产力。

什么是完美测试如何做到完美测试,当然不是上面几段文字就能说清楚的,甚至难以用一本书把它说清楚。一方面,大家对什么是完美测试会有不同的看法;另一方面,每个方面(团队、流程、技术)要说清楚,都需要单独用一两本书完成,加起来,可能需要四五本书才能完全阐述清楚。所以,笔者对写好这本书,一直没有把握,怀着诚惶诚恐的心情,但必须迈出第一步,触发测试人员的不断思考、创新和提高。另外,由于刚到一个新单位工作,有很多事要做,心情也不够平静,对本书的写作也有较大的影响,所以到后来,不得不把如下一些已经写了几页初稿、内容很好的章节删去。

    让单元测试无处不在。

    模糊测试——距离之美。

    安全无底——但测试有方。

    回归测试——从有到无。

    测试过程之美——立体之美。

    测试的三重境界。

    如何构建一流的测试团队。

 

希望将来这些内容可以在本书再版时放进来,让大家看完本书后还怀有一丝期盼。

如果说软件测试是艺术,多数人都不会同意,他们觉得软件测试是一项技术工作,更乐意去讨论软件测试的自动化测试技术,讨论性能测试、安全性测试的技巧。虽然Glenford J. Myres写了一本《软件测试的艺术》,但许多人仍很难从软件测试中获得艺术的欣赏。后来,又有一本叫《测试之美》的书出版了,让我们能欣赏到一些测试的技巧之美,也能获得一些真知灼见、有价值的建议或者寓有挑战性的想法,距离软件测试艺术又前进了一大步,开始领略软件测试之美。

写《完美测试》还有另外一个含义,就是想将测试之美表现出来。因为为数不少的测试人员,特别是测试领域之外的IT人,总觉得软件测试缺乏技术含量,是一份枯燥而且重复性很强的工作,测试跟是没有任何关系的。为了改变这种看法,笔者想通过写一本书来展示测试之美,虽然之前已经有一本《测试之美》,觉得还不过瘾。但这本书做得也不够好,多数测试工程师因为是理工科出身、长期从事技术工作,那么仅有的几个艺术细胞早就被磨灭了,所以本书的多数作者还难以写出真正的测试之美,还需要更多的观察和更长时间的修炼。

最后,尽管本书没有完成全部使命,但还是带领大家完成了一趟快速的艺术之旅,在软件测试领域充分地欣赏各种测试之美,包括软件测试的距离之美、空间之美、技巧之美和辩证之美,更重要的是贯穿全部测试过程的平衡之美。当然,本书更多的篇幅还是在讨论如何进行更彻底的测试,从各个方面保证软件产品的质量。这里的完美测试,更多倾向于前面所叙述的那部分思想,即如何全面地、完整地、充分地完成测试,将测试工作做到相对完美的程度。

这就是本书写作的初衷和思路,但现在仅仅跨出第一步,算是敏捷方法的前一两个迭代,还需要根据读者的反馈,不断进行修改,不断迭代,争取在不远的将来推出本书的第2版、第3版,以回馈读者。

 

朱少民

2011年秋于上海同济大学嘉定校区

转载于:https://www.cnblogs.com/broadview/archive/2012/05/02/2479219.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录 第1章 软件测试的金字塔体系1 1.1 从1个中心到5个要素3 1.2 5个工作面5 1.3 8组关系6 1.4 13项原则8 1.5 21个关键域11 1.6 34个方法15 第2章 测试架构从何而来17 2.1 什么是测试架构18 2.2 测试领域架构21 2.3 自动化测试架构之说25 2.3.1 为何要建立自动化测试架构25 2.3.2 解决什么问题26 2.3.3 软件开发框架的启发30 2.3.4 测试自动化框架的基本构成31 2.4 谁能成为测试架构师34 第3章 如何让缺陷无处藏身38 3.1 什么是软件可测试性39 3.2 SOCK模型和James Bach的观点41 3.3 TDD和代码的可测试性43 3.4 设计的可测试性48 3.5 需求的可测试性51 第4章 可以像这样设计测试用例吗53 4.1 从需求到测试用例53 4.2 基于流程图设计测试用例56 4.3 基于UML视图的测试用例设计61 4.4 小结65 第5章 从虚拟测试环境到一键部署67 5.1 虚拟出更多的机器67 5.2 虚拟的疑问70 5.3 另一种把资源用到极致的方法71 5.4 一键部署73 第6章 客户端的GUI测试自动化79 6.1 初识自动化测试79 6.2 困惑80 6.3 建议81 6.4 三类标准控件的不同处理办法82 6.4.1 标准控件83 6.4.2 自定义控件84 6.4.3 自定义控件库84 6.5 微软的UIA和MSAA85 6.5.1 MSAA85 6.5.2 UIA86 6.5.3 Windows Automation API 3.088 6.6 和开发人员合作的好处88 第7章 后台自动化测试90 7.1 什么是后台测试90 7.1.1 后台测试的特点90 7.1.2 后台测试的自动化91 7.2 后台自动化测试的统一脚本控制92 7.2.1 自动化测试框架93 7.2.2 自动化测试脚本的分层实现93 7.3 后台自动化测试实例95 7.3.1 测试工具树形图95 7.3.2 基于STAF框架的Python脚本97 7.4 后台大规模性能测试102 7.4.1 测试工具的管理103 7.4.2 同步及异步控制模式103 7.4.3 测试逻辑的同步执行问题104 7.4.4 测试结果的收集106 7.5 小结107 第8章 高亢之龙——JMeter后台自动化测试108 8.1 潜龙勿用,见龙在田109 8.2 终日乾乾,或跃于渊113 8.3 飞龙在天117 8.4 亢龙有悔121 8.5 小结123
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值