本书全力主张“软件测试贯穿软件开发整个生命周期”的思想及其实践，无论在传统测试中还是在敏捷测试中都具有很好的指导作用。本书的素材来源于十几年的测试工作，进行了很好的组织和提炼，力求做到易于理解、所学即所用、行之有效，并融入了敏捷测试、探索式测试等新的实践经验，能更好地满足测试人员的当前实际工作需求。本书共分12章，以案例为背景，以项目实际运行的全过程为路线图，全面展开软件测试的思维方式、流程、方法和优秀实践，涉及测试计划、测试需求分析与设计、软件评审、自动化测试、测试执行、缺陷跟踪、结果评估等关键内容，最后辅以深刻的剖析与总结。
编辑推荐
时隔6年，作者倾心打造的《全程软件测试（第2版）》全新亮相！ 名人推荐
这是一本为软件测试团队创作的融实践性、专业性、思想性和实用性为一体的软件测试书籍。
——崔启亮 昱达软件科技有限公司技术与培训总裁
非常欣喜地得知又一本国内原创的软件测试专著问世了，目前国内的软件测试书籍理论偏多，介绍最佳实践的偏少，希望本书能成为软件测试工程师的案头手册，为国内软件测试行业的蓬勃发展添砖加瓦。
——贺炘 慧灵科技首席测试专家、北京软件行业协会测试工作委员会副秘书长
如果你想通过一本切合实际而不仅仅是纸上谈兵的书来学习软件测试，《全程软件测试》会是一个很好的选择！
——周泽睿 百度高级测试工程师
很难得，久未看到如此让人畅快的文章。能将软件工程实践系统地贯穿在一起，并不失理论佐证，这本身就是个胜利。
——高磊 百度高级测试工程师
优秀的测试思想，体现着对人生反思的哲学。从某种意义上说，生活和软件开发一样，要在试错的磨炼中成长。
——李晓杰 百度测试与项目管理工程师
本书最吸引我的地方在于其真实的项目背景，这对于缺乏丰富实践经验的从业人员来说无疑是最宝贵的材料。
——周可杉 对外经济贸易大学信息学院硕士研究生
作者对于测试项目从启动、计划、验证、设计、工具和脚本开发等多个角度由浅入深地介绍，非常有利于初学者对于测试流程的理解。
——曹辉 某公司软件测试工程师 作者简介
朱少民，国内软件测试界的领军人物和资深专家，二十多年来一直从事软件测试、质量管理和过程改进等工作，先后出版了十多部著作，包括测试方面的畅销书《完美测试》、《轻轻松松自动化测试》、《软件测试方法和技术》、《软件测试》和译作《自动化测试最佳实践》等，经常在国内外会议上发表演讲。之前曾任思科-网迅（中国）软件有限公司QA高级总监，目前是同济大学软件学院教授、中国科技大学软件学院教指委委员。 目录
第0章引子1
0.1究竟什么是软件测试？2
0.2究竟什么是敏捷测试？3
0.3软件测试的作用6
0.4软件测试在SDLC中的位置7
0.5传统的软件测试过程9
0.6敏捷测试过程12
第1章测试项目启动14
1.1了解软件的质量需求15
1.1.1软件产品的质量需求15
1.1.2软件质量的对立面——软件缺陷18
1.1.3软件缺陷产生的原因20
1.1.4软件测试的目标22
1.2项目测试团队24
1.2.1测试过程和开发过程的关系24
1.2.2团队组建27
1.2.3培训29
1.2.4测试团队在项目中的位置30
1.3掌控项目背景32
1.3.1软件测试的项目要素32
1.3.2两个典型项目的介绍34
1.4确定测试规范36
1.5小结44
第2章测试需求分析与计划45
2.1软件测试的目标和基本需求46
2.1.1质量要求46
2.1.2测试目标49
2.1.3基本的测试需求50
2.2项目的测试需求53
2.2.1测试需求分析的基本方法54
2.2.2测试需求的分析技术55
2.2.3功能测试范围分析56
2.2.4非功能性的系统测试需求60
2.3测试工作量估算66
2.3.1工作量的估计66
2.3.2工作分解结构表方法68
2.3.3工作量估计的实例70
2.4测试资源需求73
2.5测试里程碑和进度安排74
2.5.1传统测试74
2.5.2敏捷测试75
2.6测试风险分析76
2.7制定有效的测试策略81
2.8完整生成测试计划书85
2.9小结86
第3章需求与设计的评审88
3.1产品需求评审89
3.1.1需求评审的重要性89
3.1.2测试人员在需求评审中的角色92
3.1.3需求评审的标准94
3.1.4需求的可测试性96
3.2系统架构的审查97
3.2.1系统架构选型的确认97
3.2.2软件设计评审标准99
3.2.3设计的可测试性102
3.2.4系统组件设计的审查105
3.3产品设计规格说明书的复审107
3.3.1重视设计规格说明书的审查107
3.3.2设计规格说明书的多层次审查108
3.3.3界面设计的评审109
3.3.4验证过程与确认过程110
3.4系统部署设计的审查112
3.4.1系统部署逻辑设计的审查113
3.4.2软件部署物理设计的审查114
3.4.3可用性设计的审查115
3.4.4可伸缩性设计的验证119
3.4.5安全性设计的验证121
3.5小结121
第4章测试设计123
4.1测试用例框架的设计124
4.1.1为什么需要测试用例124
4.1.2测试用例设计考虑因素125
4.1.3测试用例框架的构成127
4.1.4测试用例的元素129
4.2探索式测试之设计130
4.3功能测试用例的设计133
4.3.1功能测试用例的内容135
4.3.2功能测试用例的设计方法136
4.3.3等价类划分法与边界值分析法136
4.3.4决策表与因果图法141
4.3.5功能图法144
4.3.6Pair—wise方法和正交实验设计方法145
4.4非功能性测试设计148
4.4.1故障转移测试设计148
4.4.2系统安全性测试设计150
4.5测试用例的审查153
4.5.1测试用例书写标准153
4.5.2测试用例评审要点154
4.6测试套件的创建157
4.7小结160
第5章测试工具选择和脚本开发161
5.1测试工具的需求分析162
5.1.1测试工具的优势162
5.1.2测试工具的实现原理163
5.2测试工具的选择167
5.2.1测试工具选择的标准167
5.2.2测试工具选择的误区170
5.3商业测试工具解决方案171
5.4开源测试工具解决方案172
5.5测试脚本的开发174
5.5.1测试自动化策略175
5.5.2适应测试脚本开发的测试用例176
5.5.3测试脚本的重构和优化178
5.6小结179
第6章单元测试180
6.1程序代码的审查181
6.1.1代码审查的方法和范围181
6.1.2代码风格的审查183
6.1.3编程规则的审查186
6.2单元测试内容189
6.2.1什么是单元测试189
6.2.2单元测试的现状和作用191
6.2.3单元测试的方法192
6.3单元测试用例的设计194
6.3.1语句覆盖法194
6.3.2判定和条件覆盖法196
6.3.3基本路径测试法198
6.3.4多种白盒测试方法的比较和总结199
6.3.5循环结构的测试用例201
6.3.6单元测试的典型实例203
6.4单元测试工具205
6.4.1静态代码分析206
6.4.2测试覆盖率工具EMMA207
6.5小结210
第7章功能测试的执行211
7.1测试执行概述212
7.2测试执行的准备214
7.2.1测试任务安排215
7.2.2测试环境的建立216
7.2.3测试环境的设置217
7.2.4测试自动化运行平台219
7.3如何有效地创建测试套件221
7.3.1功能测试套件的创建221
7.3.2测试环境的爆炸性组合及其优化223
7.4功能测试自动化的执行226
7.5敏捷测试的执行229
7.5.1策略与实践229
7.5.2探索式测试的执行231
7.6用户界面和适用性测试233
7.7回归测试237
7.8软件缺陷的报告240
7.8.1缺陷的属性240
7.8.2缺陷的详细描述243
7.8.3如何报告缺陷245
7.9小结246
第8章国际化和本地化测试247
8.1国际化测试248
8.1.1软件国际化的基本要求249
8.1.2国际化测试253
8.1.3I18N测试实例255
8.2本地化测试257
8.2.1软件本地化的质量需求258
8.2.2本地化测试的基本内容260
8.2.3L10N的功能测试262
8.2.4L10N的数据格式验证264
8.2.5L10N的UI验证268
8.2.6L10N的配置和兼容性验证268
8.2.7L10N的翻译验证270
8.3I18N和L10N测试工具271
8.4小结273
第9章系统非功能性测试275
9.1实施要求和策略276
9.2Web应用服务器的负载测试278
9.2.1负载测试的加载方式278
9.2.2负载测试的准备工作279
9.2.3负载测试的执行282
9.2.4负载测试的结果分析284
9.3Web应用服务器的性能测试285
9.4Web安全性测试287
9.5容错性测试289
9.6数据库的性能测试290
9.7兼容性测试294
9.8小结297
第10章后续测试299
10.1验收测试299
10.2部署测试303
10.2.1客户端软件安装测试303
10.2.2后台系统的部署测试305
10.3在线测试306
10.4后继版本的测试308
10.5小结310
第11章测试的跟踪和管理311
11.1测试管理312
11.1.1测试管理的全局性312
11.1.2测试管理思想和策略313
11.1.3测试管理系统的应用315
11.1.4测试管理工具317
11.2测试用例的管理320
11.2.1测试用例管理架构320
11.2.2管理与维护要点321
11.3测试自动化的管理323
11.3.1测试自动化的管理准则323
11.3.2测试自动化的框架327
11.3.3测试自动化的流程328
11.4缺陷跟踪和分析330
11.4.1缺陷生命周期330
11.4.2缺陷状态的跟踪332
11.4.3缺陷的分析333
11.4.4累计缺陷趋势分析336
11.5测试进度和风险的控制337
11.5.1测试进度管理337
11.5.2测试风险的控制341
11.6测试覆盖度和结果分析343
11.6.1测试覆盖评估344
11.6.2基于软件缺陷的质量评估346
11.6.3软件缺陷清除率348
11.6.4测试报告的模板、实例350
11.7小结354
第12章总结与思考355
12.1软件测试的现实和原则356
12.1.1测试的现实356
12.1.2测试的原则357
12.2软件测试的多维空间363
12.3软件测试之辩证统一364
12.3.1白盒测试方法和黑盒测试方法365
12.3.2静态测试和动态测试366
12.3.3主动测试和被动测试366
12.3.4基于脚本测试和探索式测试367
12.3.5手工测试和自动化测试369
12.3.6测试方法综合应用的总结370
12.4软件测试的优秀实践371
12.4.1测试有效性和风险性的平衡372
12.4.2测试计划的优秀实践373
12.4.3测试设计的优秀实践374
12.4.4测试执行的优秀实践375
12.4.5测试团队建设中的优秀实践377
12.5持续改进379
12.5.1TMMi和TPINext分析380
12.5.2构建更实用的持续改进模型382
附录A软件测试全景图388
附录B测试计划（GB8567—2006）391
附录C测试用例设计模板398
附录D软件缺陷模板401
附录E代码审查的示范性列表403
附录F软件测试相关的国家标准407
附录G软件测试术语中英文对照409
附录H参考书目和资源414 序言
“人生天地间，若白驹之过隙，忽然而已”，这样开头虽然比较俗，但也的确反映真实感受。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章最后一章是对测试的总结和思考。
本书最后附有软件测试全景图、完整的项目检查表、软件测试计划通用模板、完整的测试工具列表和代码审查的示范性列表等资料。
由于水平和时间的限制，书中难免会出现错误，欢迎读者及业界同仁不吝指正。
笔者
文摘
版权页：
而软件测试团队的任务是相对明确的，包括制订测试计划、设计测试用例、执行测试、评估测试结果和递交测试报告等。除了这些主要的任务，测试团队还要完成其他任务：阅读和审查软件功能说明书、设计文档，审查代码，与开发人员、项目经理等进行充分交流，参加各种业务、技术讨论会等。一个比较健全的测试团队包含的角色有以下6种。
（1）测试组长或测试经理：全面负责该项目的测试工作，如协调测试计划、统筹资源、组织测试件的评审、监控测试的执行等。测试组长的能力要相对全面，包括项目管理、测试流程控制、沟通、业务、技术等各个方面的能力。
（2）系统工程师：负责测试环境的部署和调试，甚至包括持续构建、持续集成的工作，以及产品发布的技术流程。
（3）自动化测试工程师，或者说，测试开发工程师（Software Development Engineer inTest，SDET）：负责所需的测试工具开发，以及自动化测试框架或整个应用测试平台的维护。
（4）测试分析和设计人员：一般由具有丰富经验的资深测试工程师承担，和测试组长一起，比较早进入项目，负责需求评审、设计评审、测试需求分析、测试用例设计或测试脚本开发等。
（5）性能测试、安全性测试人员：性能测试和安全性测试都需要性能或安全性方面的知识、技术和经验，一般由专职的测试人员完成。
（6）测试执行人员：如果项目规模大，测试团队人员需求量大，有一部分外包人员。另外，每个团队也不可能是清一色的资深测试人员，总是有一些刚加入公司的新手，这些初级测试人员则适合测试的执行。
对于规模小的测试团队，上面某些角色（如2）、3）、5）等）的资源可以和其他团队共享。测试组长是一个关键的角色，不只是管理，还会兼任测试分析和设计人员，参与或主导测试分析与设计的工作。虽然测试组长不是神人，但要承担的责任还是很多的（也可以授权其他资深测试人员承担部分责任），列举如下。
负责一个独立的测试项目及其测试组的管理工作。
制定整个项目的测试计划、测试策略，包括风险评估、日程表安排等。
负责工作量的预估和测试项目内部的资源、任务安排。
熟悉产品的功能、特性，审查产品需求规格说明书，并提出改进意见。
审查系统、程序设计说明书。
验证产品是否满足规格说明书所描述的需求。
| ISBN | |
|---|---|
| 出版社 | 电子工业出版社 |
| 作者 | 朱少民 |
| 尺寸 | 16 |