+ 首页>>扫货>>好书>>内容

扫货《全程软件测试(第2版)》全新亮相!500+次围观

来自 @朱少民 老师的作品,时隔6年,作者倾心打造的《全程软件测试(第2版)》全新亮相!

新书前言

“人生天地间,若白驹之过隙,忽然而已”,这样开头虽然比较俗,但也的确反映真实感受。2007年《全程软件测试》第1版和读者见面了,一晃六年了。欣慰的是,本书深受读者喜欢,在当当网有2百多人评论,总评是五颗星,在京东网也得到五星级的好评,甚至有些公司把这本书作为新员工的培训教材,有些公司的测试工程师人手一本。但随着时间推移,越来越感觉这本书需要修改,但似乎“笔头懒”,迟迟没有动手修改本书,出版社编辑常常催促,我似乎不为所动,但终究拗不过编辑,趁着节日终于完成其修改,使本书第2版能够与读者见面。
六年来,笔者经常参加一些软件技术大会,和测试同仁有很多交流,阅读了不少测试类图书,也经常上网浏览国外测试大师的博客,自己对软件测试有着更深的理解,每当浏览《全程软件测试》第1版,总觉得其中许多内容都需要修改,本书可能会被改得面目全非,但那需要很多时间,甚至不如重新写一本书,这也就是为什么迟迟没有修改本书的潜在原因之一吧。后来想,也不能翻天覆地地大改,应该保持其基本面貌,否则就不是原书的第2版。
幸好,当初本书写作时就认定“软件测试是贯穿整个软件生命周期的活动”,这个主题在今天依旧有效,即使在敏捷开发模式下,“全过程的软件测试”也是大家全力提倡的,可以说本书主题和敏捷测试是不谋而合,虽然在局部或某些具体的实践有冲突。本书所介绍的许多实践来自美国硅谷,具有很好的先进性和普适性,即使若干年后,这些实践中大部分内容在今天依旧有很好的借鉴作用。
在本次修改中,为了保持本书的风格和一致性,全书结构没有进行大的改动,还保持原来的12章,从引子、项目启动到最后的思考与总结,但有几个小节还是做了较大调整,使全书结构更合理,同时融入了一些敏捷测试实践,包括持续测试、验收测试驱动开发、探索式测试等内容,以适应目前业界的环境。

第2版的主要修改

(1)引子:增加两部分内容,即“究竟什么是敏捷测试?”、“敏捷测试过程”,以达到更好的铺垫效果。
(2)把第2章“团队组建”、“培训”两小节移到第1章,删除“测试组长的人选”这一小节,在1.2节比较彻底地讨论测试团队相关的问题。
(3)将“需求评审”移到第3章,第2章加强了测试需求分析,包括质量要求和测试目标、测试需求的分析方法和技术。测试需求分析不仅是测试设计的基础,也是制定测试计划的基础,第2章定义为“测试需求分析与计划”,就更加自然,先进行测试需求分析,再逐步完成测试计划所要进行的工作,包括测试风险分析、工作量估算。
(4)第3章的重点放在需求和设计的评审上,构成了完整的“静态测试”篇章。而且,在这一章增加了“需求可测试性”和“设计可测试性”两小节,使需求评审和设计评审更具价值,也为将来的测试设计和执行打下更坚实的基础。
(5)第4章不仅增加了“探索式测试设计”,顺带介绍了基于会话的测试管理(SBTM),而且对黑盒测试的具体方法重新组织,让读者更有效地运用测试方法,如将等价类划分方法和边界值分析法结合在一起来应用。Pair-wise方法使用起来方便,所以也添加进来了。
(6)第5章进行了简化,把具体工具的介绍和对比删去了,工具变化很快,尽量避免工具的一般介绍性内容。同时,增加了自动化测试策略,包括整体策略和功能测试自动化策略。
(7)第7章增加了“敏捷测试的执行”一节,这节包含两个小节:“敏捷测试策略与实践、探索式测试的执行”。第1章已讨论了“培训”,本章删除了原来的“培训和知识传递”,并简化了测试环境爆炸性组合的优化方法。
(8)第9章改为“系统非功能性测试”,所以原来“安装测试”一节的内容,整改为“部署测试”,移到第10章。删除原9.1节讨论的非功能性测试内容,部分内容和第2、第3章进行了合并。
(9)第10章删除“10.2文档测试”,少量有价值内容并入“验收测试”,而且将敏捷流程的“验收测试”考虑进来,和传统“验收测试”加以区分。最后,把“α测试和β测试”整合为在线测试。
(10)将第12章中的一节移到第11章,整合为“测试自动化的管理准则”,对测试自动化的框架做了较大修改,更准确地定义了自动化测试框架的概念。对“软件缺陷清除率”、“测试管理思想和策略”两小节也做了较多修改,测试用例的管理也从原来三小节整合为两小节。
(11)第12章改动也比较大,测试原则由原来的10条增加到12条,而更大的改动在“12.3 软件测试之辩证统一”、“12.5 持续改进”这两节,增加了“基于脚本测试和探索式测试”、“TMMi和TPI Next分析”,而且对相应的内容做了删减。另外两节“12.2 软件测试的多维空间”、“12.4 软件测试的优秀实践”也有一些修改。
(12)附录删除了“完整的项目检查表”和“完整的测试工具列表”,因为前者和测试关系不是十分密切,而删除后者则是因为在第5章已将主要的测试工具做了介绍,有那么多工具对读者使用已足够了。如果还需要其他工具,可以借助网络搜索引擎来查找。而增加了“用例设计模板”、“缺陷报告模板”、“测试相关的国家标准”三个附录,“软件测试计划模板”也换了最新的国家标准定义的模板。
(13)第6、第8章没有大的改动,只进行了细节上的文字修改。
看起来,第2版做了比较大的改动,但自己也不是十分满意,可能是第1版的基础还不够扎实,总觉得有些内容还可以不断改下去,但时间又不允许。而且,在敏捷时代追求完美也是不合情理的,虽然不能做到持续交付、快速交付,但缩短迭代时间还是可以的,如1~2年本书出一个版本还是可以的,也是比较好的。
希望经过修改后,本书更能满足当今软件测试的知识传递和技能培养的需求,可以给读者带来更多的收益,更希望读者不吝赐教,我将继续努力修改本书,继续更好、更多地为测试人服务。

朱少民
2013年国庆节于上海

2000年刚建立测试团队时,测试人员和开发人员是一种对立的关系,开发人员觉得软件测试是挑他们的毛病,和他们过不去,有一个简单的故事可以说明这一点。当时,条件有限,测试人员和开发人员共享一台小型机服务器,测试人员发现了一个缺陷,告诉了某个开发人员,而他趁测试人员不注意,回到自己的座位上偷偷地修改了代码,处理了那个缺陷,然后跑到测试人员身边说:“你把那个Bug再现给我看看?”结果,可想而知,这个测试人员无论如何也不能复现那个Bug(缺陷)了。
几年以后,这种情况不再出现了,不是因为条件好了,可以买很多服务器,将测试环境和开发环境分离开来,而是观念改变了。虽然的确是购买了几百台服务器(不用小型机,越来越多的服务器采用Linux系统),将测试环境和开发环境分离开了,在客观上可以避免那类“悲剧”的发生,但是观念远比机器重要。拥有正确的观念,就比较容易创建良好的质量文化,开发人员的态度也随之发生变化,他们已经深深认识到:
软件测试是帮助自己,测试人员是在找产品定义、设计和实现的缺陷,不是找自己的缺陷,是对事,不是对人;
测试人员越快地发现缺陷,项目越能尽早结束;
测试人员尽可能多地发现Bug,遗留在产品中的Bug就会越少,产品的质量就会越高;
测试人员和自己(开发人员)的工作都是为了相同的目标——按时、高质量地发布产品;
开发人员的水平越高,所写的程序中的Bug越少,而不在于使用了别人不知道的技巧。
现在,有的开发人员向我抱怨,是不是换了一个新人测试他写的模块?因为这次发现的缺陷比前次发现的少多了。开发人员希望更多的缺陷被测试人员发现出来,绝不希望缺陷被留给客户去发现。
今天,我们高兴地看到开发人员和测试人员心往一处想。从项目启动的第一天起到需求和设计的评审阶段,从后期的缺陷修正到产品维护——在整个软件生命周期中,开发人员和测试人员愉快地合作、共同努力,将软件产品的开发效率和质量推到一个新的高度。一方面,开发人员主动介绍自己对产品特性是如何理解的,又是如何实现这些特性的,他们主动邀请测试人员参与代码的走查并对新发现的Bug快速响应。另一方面,测试人员提前将设计好的一些测试用例交给开发人员,让开发人员先根据这些测试用例验证正在开发的功能特性,测试人员还愉快地帮助开发人员再现某个缺陷。
所有这些,都可以看出软件测试在国内越来越受重视,软件测试领域正迎来朝气蓬勃的新气象。当更多的人投入到测试行业时,需要一本实践性强、富有启发性的专业书,指导大家如何进行测试,出色地完成测试任务。这本《全程软件测试》就承担了这样一个任务,它会从项目启动开始,一步一步地教会大家如何做好测试工作,包括建立测试组、计划测试、设计测试用例、选择测试工具、开发测试脚本、执行测试和编写测试报告等。这也是我与大家分享多年来积累的软件测试经验与技术实践,以及不断思考所升华的体会。
为了写这本书,我事先也做了一些尝试,尽量收集大家对软件测试需求的反馈,并在CSDN的个人博客http://blog.csdn.net/KerryZhu上演义了30回的软件测试,受到了大家的好评。也许就因为这个,在CSDN建立博客不到8个月,我的博客就成为当年(2006年)十大最具价值的博客之一。
此前,我曾写过一本《软件测试方法和技术》的教材,这本教材在比较短的时间内印刷了好几次,也颇受欢迎。但那本书在很大程度上是从理论、概念上讲解软件测试的方法和技术的,适合在校学生使用。而这本书重实践、重应用,适合软件公司的测试经理、工程师和想进入软件测试行业的人员学习。
全书共12章,以两个案例为背景,以项目向前发展的实际过程为路线图,全面展开软件测试的思想、流程、方法、技术和最佳实践。全书力求做到方法有效、技术实用,集中讲解实际测试工作,没有单纯地介绍概念,而是将概念准确地穿插在测试进程活动之中。

好书主要内容

第1章 介绍测试项目启动后要做好哪些准备,如何掌控项目背景和要素,为制定测试计划打下坚实的基础。
第2章 本章的焦点是测试计划,主要讨论测试人员在需求评审中的作用。
第3章 本章从系统架构的审查开始,深入到系统组件设计、设计规格说明书、界面设计和系统部署设计等一系列的审查。
第4章 本章围绕测试设计展开讨论,先从测试用例框架的设计入手,然后逐步涉及测试用例的构成、设计方法、评审、功能测试用例和系统测试用例的设计。
第5章 本章着重介绍测试工具的选择和脚本的开发。
第6章 本章展示测试和编程的交互过程。
第7章 本章开始进入功能测试的执行阶段,并着重介绍了自动化功能测试的执行。
第8章 本章介绍如何进行国际化测试和本地化测试。
第9章 本章的重点内容是如何执行系统测试。
第10章 本章介绍验收测试、文档测试、α测试和β测试、产品后继版本的测试。
第11章 本章介绍测试管理的思想和系统、测试用例的管理、测试自动化的管理、缺陷跟踪和分析、测试进度和风险的控制、测试覆盖度和结果分析等。
第12章 最后一章是对测试的总结和思考。
本书最后附有软件测试全景图、完整的项目检查表、软件测试计划通用模板、完整的测试工具列表和代码审查的示范性列表等资料。
由于水平和时间的限制,书中难免会出现错误,欢迎读者及业界同仁不吝指正。
-笔者

+ 猜你喜欢...

===== 关于 DiggerPlus =====
DiggerPlus是国内新锐测试人垂直内容博客,专注于挖掘测试工具,普及测试技术,专注于测试人能力提升,博客上线后就受到广大测试人的热烈追捧;此外,DiggerPlus深度整合评测资源,揭秘科技数据和真相,让读者更懂科技,更好地把玩科技。 我们始终保持"独立,客观,严谨,优秀"的优良作风,努力为读者带来源源不断的优质内容。想访问更多酷毙的测试人网站?赶紧来DiggerPlus测试人网址导航看看吧!

===== DiggerPlus Team =====
DiggerPlus Team是DiggerPlus官方发起的团队,这是一群热爱科技,热爱测试,喜欢深度挖掘的热血测试人,他们是评测师,测试专家。 我们欢迎优秀的测试人加入DiggerPlus Team。 加入DiggerPlus,可以成为我们的认证Dper,认证Dper拥有DiggerPlus独一无二的专栏并得到个人展示。

===== DiggerPlus 官方读者群 =====
DiggerPlus官方读者群(一)

+ 关于本文作者

Python/C/C++/Javascript程序员,持续学习者,目前专注于前端开发。

的专栏 | 专栏作者 | 访问小A的主页

+ 已有1个评论

开源中国精彩推送

基于开源中国OpenAPI开发
  • Copyright © 2014 DiggerPlus. 88 queries in 1.155 seconds.
    使用合作网站账号快速登录,更多精彩等着您: 开源中国