购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

前 言
——从完美说起

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

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

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

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

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

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

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

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

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

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

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

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

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

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

●让单元测试无处不在。

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

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

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

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

●测试的三重境界。

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

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

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

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

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

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

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

朱少民(第1、2、3、4、18、21章以及前言、后记的作者)

同济大学软件学院教授,Certified Scrum Master、CSTQB资深专家和中国科技大学软件学院教指委委员。曾任网迅(中国)软件有限公司QA高级总监,创建并领导过几百人的、国际化的软件测试团队。从事软件开发、测试、QA和过程改进等工作近二十年, 在软件工程领域有很高的造诣,在软件测试流程改进、自动化方法和测试管理等方面进行了大量探索和实践,提倡“全过程软件测试”和“缺陷预防”等先进的软件工程思想,先后出版专著《全程软件测试》、《软件测试》、《软件工程导论》和主编《软件测试方法和技术》、《软件项目管理》、《软件质量保证和管理》、《软件过程管理》等多部高等学校精品教材。并先后获得青岛市、合肥市、安徽省、机械工业部等多项科技进步奖,也是国内第一批获得国家人事部认证的“高级程序员”。

个人微博:http://weibo.com/KerryZhu

史玮(第5、6章作者)

思科(Cisco WebEx)软件测试资深工程师,6年自动化测试及相关工具开发经验。最近几年都被公司评为最优秀、最有价值工程师。由他主导开发的一款大规模自动化测试工具为公司节约了上百万美金的硬件成本,加上超过180万的人工测试时间,使他获得了思科全球包括先锋大奖在内的多项大奖。曾参与《轻轻松松自动化测试》一书的编写工作。

个人微博:http://weibo.com/2341323404

陈剑(第7章作者)

测试工具开发组组长。中国科学技术大学计算机系硕士,最近4年一直从事自动化测试框架及测试工具的研究与开发,该测试框架已经成为公司自动化测试的通用平台,同时为公司的大规模性能测试提供解决方案,具有很好的扩展性,实现了模拟数十万人同时在线的大规模性能测试,并很好解决了大规模测试中的工具控制、结果收集等问题。

刘涛(第8、19章作者)

北京航空航天大学明星教授张军的学生,曾参与神舟飞船的测试,和嫦娥一号用490N发动机阀门测试系统的研发。现任职于思科WebEx测试部门,专攻后台自动化测试。擅长工具:JMeter、Ant等。

傅健(第9、11章作者)

吉林大学硕士,国家认证网络工程师、信息系统项目管理师。发表教育信息化、软件测试相关论文十二篇,在校期间获吉林大学第二十四届研究生精英杯学术成果奖;在思科公司工作两年多,先后参与Cisco WebEx的移动项目及文档管理系统(DMS)等多个项目的测试,其中参与的BlackBerry Meeting项目测试工作获得2010思科测试革新会议(CTIC)二等奖。现主要专注于“云存储”领域质量保证工作。

个人微博:http://weibo.com/fujianthinking

黄超男(第10、12章作者)

合肥工业大学软件工程硕士,主要研究方向是软件测试、配置管理,特别是在自动化测试工具上进行了比较多的探索和研究,发表了多篇软件测试相关的论文。2008年1月加入Cisco WebEx,作为一名测试工程师,主要从事Client端的功能测试,特别是在Mac平台上的测试,并负责Cisco WebEx Client的多个项目,积累了丰富的软件测试和管理经验,还参与了《软件测试方法与技术实践指南》一书的编写工作。

姜文武(第13、16章作者)

兰州大学学士,软件测试资深工程师,从事软件测试工作已逾十年,注重软件测试理论、方法和流程的探讨,并实际负责或参与大量具体的软件测试项目,特别是基于SaaS平台的企业级网络会议系统的测试,具有Web、客户端、服务器端等各方面的丰富的测试经验。曾参与《轻轻松松自动化测试》一书的编写工作。

李茜(第14章作者)

中国科学技术大学软件工程硕士,现任职思科网迅(中国)软件有限公司合肥分公司软件测试工程师,从事软件测试工作近4年,注重前端UI与用户体验的分析研究工作。先后参与并负责基于Web、Client等多个大型测试项目,具有丰富的测试经验,对软件缺陷具有敏锐的洞察力。

李曾(第15章作者)

思科(Cisco WebEx)资深软件测试工程师,从事软件测试工作7年。负责或参与了URL API、Accessibility、Page/Client UI等前端测试领域的测试。具有多年的用户体验、流程管理等测试经验。关注于自动化测试方法和测试用例设计的研究,负责并成功发布了多个软件测试项目。

徐雪梅(第17章作者)

2006年毕业于北京交通大学信息与计算科学系。分别就职于博彦科技武汉分公司、思科网迅合肥分公司,有4年多软件测试经验。主要从事于嵌入式固件测试、Windows客户端以及跨平台功能测试,并参与重要测试项目的管理,对测试及项目管理工作有良好的理解和经验。

张丽丽(第20章作者)

1999年毕业于安徽大学计算科学与技术系。思科网迅合肥分公司软件测试资深工程师,系统自动化项目测试组组长,Certified Scrum Master,思科敏捷委员会成员,多次获得思科网迅最佳实践奖。2010年成功领导项目组从瀑布模型向敏捷模型的转型,使所在项目组成为中国部第一个成功使用敏捷模型的团队,为提高生产力和质量做出了突出贡献,同时积极组织整个中国部敏捷培训,并分享最佳实践。

个人微博:http://weibo.com/lukezhang66 f7BWiMzqnEJPWt1cAohe2JgFq68p9hjRVr+LCZSnZrzig7ESWJMIMMwb93UZ3SSS

点击中间区域
呼出菜单
上一章
目录
下一章
×

打开