《全程软件测试(第2版)》全力主张“软件测试贯穿软件开发整个生命周期”的思想及其实践,无论在传统测试中还是在敏捷测试中都具有很好的指导作用。《全程软件测试(第2版)》的素材来源于十几年的测试工作,进行了很好的组织和提炼,力求做到易于理解、所学即所用、行之有效,并融入了敏捷测试、探索式测试等新的实践经验,能更好地满足测试人员的当前实际工作需求。《全程软件测试(第2版)》共分12章,以案例为背景,以项目实际运行的全过程为路线图,全面展开软件测试的思维方式、流程、方法和**实践,涉及测试计划、测试需求分析与设计、软件评审、自动化测试、测试执行、缺陷跟踪、结果评估等关键内容,*后辅以深刻的剖析与总结。
全程软件测试-(第2版)_朱少民_电子工业出版社_

翻阅少民的这部新作时,不禁让我想起一位好朋友前几天提到的《叙事谣曲》中“只弯一次腰”的故事:有一次,耶稣带着他的门徒彼得出门远行,在路上发现了一块破烂的马蹄铁,耶稣就让彼得拣起来,不料彼得懒得弯腰,假装没有听见。耶稣没说什么,自己弯腰拣起马蹄铁,用它在铁匠那里换了几文钱,并用这些钱买了十几颗樱桃。出了城,两人继续向前走,沿途都是茫茫的荒野,看不到人烟,也找不到水源。耶稣猜到彼得渴得厉害,就让藏在袖子里的樱桃悄悄掉出一颗。彼得一见,赶紧捡起来吃掉。耶稣边走边掉,彼得也就狼狈地弯了十七八次腰。于是耶稣对他说:“要是你刚才弯一次腰,就不会在后来没完没了地弯腰了。小事不干,就将在更多的小事上操劳。”
这个故事,不同的人有不同的感悟。作为一个软件行业的多年从业者,我很自然就联想到了软件开发过程。软件测试(具体到每一个测**例的实施)正是在庞大复杂的软件产品开发过程中确保软件产品质量的“小事”。软件测试工作繁杂、琐碎又耗时,甚至有时吃力不讨好,这使得许多软件从业者对其不够重视;好多技术人员热衷于编码而不愿从事测试工作这样的“小事”;有些公司认为开发能出成果而测试可有可无,因而非常重视开发但不重视测试;许多国内软件企业存在着漠视测试过程、测试时间不充分、测试计划不细致、测试软硬件资源不足等问题,从而在软件质量控制上存在相当大的问题,以致项目延迟甚至失败。
在软件产业发展的几十年中,软件测试已逐步渗透到各个领域,成为越来越不可或缺的技术成分。例如,以前被认为距离软件技术比较远的汽车工业,现在已把**车制造费用的20%~25%投入到电子设备与软件系统上。由此看来,软件的品质已成为人们日益关注的重中之重。如何找到一种全面的分析方法,来检测软件开发过程中不同阶段的结果,以便尽可能早地系统地保证或提高软件产品的质量和可靠性,从而减少后期“弯腰”的必要性与次数,已成为影响软件企业生产力与生产效率的关键问题。
可喜的是,越来越多的软件公司和管理技术人员在工作中将更多的时间和资源投向了测试方面。很多**企业中开发与测试的人员比例达到了3:1或2:1,许多**的技术人员在从事质量控制和软件测试工作。而国内这几年软件测试人员的短缺和招聘难度的提高从反面证明了软件测试正越来越得到重视。
近年来,软件产业发展正从产品模式向服务模式(Software as a Service,SaaS)转变。 在过去的多年中,WebEx公司一直处于这一浪潮的领导地位。WebEx提供的网络会议服务(Web Conference)被称为改变人们工作方式的技术革命。朱少民先生与他带领的团队非常自豪而荣幸地参与了WebEx产品开发的整个过程,在这个过程中他们夯实了软件测试的理论基础,���积累了丰富的实战经验。
少民从事高校教育及软件开发测试工作多年,并且在美国硅谷工作两年,其经历是很好的理论与实践相结合的典范。与少民共事多年,了解他在软件测试领域的积累,从开始时采用简单、初级的测试方法,一步步发展到今天系统、科学的软件质量管理体系;从手工测试向自动化测试过渡;从几个人的测试小组到几百名测试工程师的大规模团队。现在,是到了将过去的经验教训作一番总结,以其亲身经历为业界同仁指点软件测试的规律与介绍成功实践经验的时候了。
这部《全程软件测试》是少民与其工作团队多年来的经验积累,其中一些观点与见解已经成为WebEx公司的基本工作准则,对软件研发领域有着重要的实质性贡献。本书通过实例全面描述了软件测试的整个过程,覆盖了测试管理的各个重要方面。对测试管理的各个层次和环节做了系统的介绍,包括测试策略制定、风险控制、缺陷跟踪和分析、测试管理系统的应用等,并且更进一步对如何执行本地化测试和国际化测试进行了阐述。作者**聚焦在实践性上,从软件测试项目启动、测试计划开始,深入到测**例设计、测试工具选择、脚本开发,以及功能测试和系统测试等各个步骤,并对它们都做了详细阐述。
让人印象深刻的是本书对软件测试工作中几个看似简单,实际上非常关键的问题做了详细的说明。例如就开发团队模式,作者介绍了以开发为核心、以项目经理为核心,以及“三国鼎立”(以项目经理、开发组长、测试组长为核心)的模式。而“三国鼎立”的测试团队具有独立、权威性地位的概念也是工作经验的总结。相信读者会从实战中体会到作者的深刻用意。
在探索**软件测试与软件开发的过程中,本书覆盖了全面的理论分析和详细的实战阐述,对任何从事软件测试的人员和软件开发人员,以及软件工程相关专业的高校师生,都具有重要的参考价值。希望书中的一些真知灼见对广大读者有所裨益。
李钦敏(Jim Li)
WebEx总部工程技术及中国研发**总监
2007年6月于美国硅谷
2007年春节后,我从美国返回国内,曾在美丽的西子湖畔与作者一叙,其间我们谈到了《全程软件测试》这本书。我高兴地接受了作者的邀请——为本书写**序。我和作者共事近7年,结下了深厚的友谊。我们从2000年开始,就合作开发美国网迅公司(WebEx Communications, Inc,纳斯达克上市公司,2007年5月被CISCO以32亿美元收购)互联网通信平台产品**个基于PHP的网页。那时,我在美国领导着整个Web开发部门,他则在国内负责软件测试。再到后来,我们在产品研发、部署和服务运营等多个领域的合作不断深入。在我管理整个网迅(中国)公司的这段时间里,他作为公司的质量管理总监直接向我汇报工作。当然,这也是我们合作*亲密的一段时间。
话说回来,作者在加盟网迅之前,虽然已是一所**大学的副研究员、硕士生导师,而且拥有良好的软件开发和项目管理经验,但那时国内软件测试还刚刚起步,他对软件测试也了解甚少,可以说是一个门外汉。
时光如梭,7年的时间一晃而过。同样拥有7年的时光,如果缺乏思考,收获就****;如果勤于钻研,就会硕果累累。而他不仅勤于思考、善于思考,而且凭着智慧、毅力和坚实的计算机基础,很快就从一个门外汉成为软件测试领域的**专家,他先后主编了3本有关软件工程领域的高等学校教材。在这7年里,他不断通过自学、努力和追求,帮助网迅(中国)公司从零开始建立和发展软件测试团队,圆满地完成了全线产品的软件测试任务,并向全球的客户提供了高质量的软件产品和服务。目前,他领导着这支近300人的国内**测试团队,正向下一个目标前进。
软件质量管理在软件研发团队中的作用是显而易见的。其中软件测试人员在保障和改进软件质量工作中发挥着越来越大的作用。但是从整个软件工程周期来看,软件质量其实是在整个开发过程中形成的,或者说软件质量是构造出来的,而不是测出来的。程序代码完成之后,其质量水平就基本确定了,虽然可以通过测试发现大部分缺陷,但是,程序代码中存在的缺陷越多,遗漏的缺陷就会越多,质量很难得到改善。如果缺陷发生在需求阶段或设计阶段,则将带来更大的成本和风险。如果将软件测试贯穿于整个软件开发过程,从项目启动的**天开始就将软件测试引入进来,情况就完全不一样了。贯穿于软件开发全过程的测试,不仅可以在**时间内发现缺陷,而且能有效地预防缺陷的产生。缺陷预防,可以大大减少软件缺陷的数量、提高软件质量,更有价值的是,它可以极大地缩短开发周期、降低软件开发的成本。
全过程的软件测试,赋予了软件测试更多的责任和内容,软件测试不再是事后检查,而是缺陷预防和检查的统一。在需求分析时,通过测试团队和开发团队的共同努力,尽可能把用户的需求全部挖掘出来,清除一切模糊的需求描述;在设计阶段,测试人员可以对不合理的设计提出质疑,督促开发人员在设计时充分考虑性能、可靠性和**性等各个方面的要求,以确定每一个设计项的可测试性;在编程阶段,测试人员参与代码评审、单元测试等。所有这些都是为了告诉人们,测试过程可以看作质量保证的过程,测试不再是产品质量的一个检验环节。这也就是《全程软件测试》书名的由来,将软件测试扩展到软件质量保证的全过程中,作者赋予了软件测试新的含义和新的生命!
全程软件测试的另一层含义就是手把手地教会读者如何做测试,从头到尾,覆盖每一个环节。从项目启动——如何把握项目的背景和需求、如何选定测试组长等开始,逐渐深入测试计划、设计评审、用例设计、测试执行等过程,直至缺陷报告、测试结果分析和测试报告,每一过程都能得到细致的辅导。作者还用了不少笔墨来介绍如何选择测试工具、如何更有效地开展测试自动化的工作。因为测试自动化非常重要,它可以解放测试人员,使测试工作变得非常有趣,又获得很高的技术挑战。测试自动化能够提高测试效率,使测试人员有更多的时间思考,从而可以更好地分析测试范围和设计好测**例,形成一个良性的循环。
本书不仅阐述了先进的、独特且成熟的软件测试思想和方法,而且呈现了丰富多彩而又实实在在的测试技术和实践。测试的知识、概念是比较容易获得的,但要获得多年通过实践积累下来的体会和经验,却是非常难得的。现在,这些内容就在您的眼前,唾手可得。《全程软件测试》能帮助您获得您所需要的东西、帮您解开心中的疑惑。本书给出的*佳实践,不仅代表着国内的*高水平,而且与美国硅谷的软件测试水平同步。它一定会帮助读者**地、高质量地完成测试和软件质量保证任务。
*后,希望大家喜欢这本书,进而从中受益。
沈剑(Joss Shen)
Founder and CEO
Dreamcast Systems, Inc.
http://YouMonitor.Us/

第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.6 PAIR-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 测试覆盖率工具EMMA 207
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.3 I18N测试实例 255
8.2 本地化测试 257
8.2.1 软件本地化的质量需求 258
8.2.2 本地化测试的基本内容 260
8.2.3 L10N的功能测试 262
8.2.4 L10N的数据格式验证 264
8.2.5 L10N的UI验证 268
8.2.6 L10N的配置和兼容性验证 268
8.2.7 L10N的翻译验证 270
8.3 I18N和L10N测试工具 271
8.4 小结 273
第9章 系统非功能性测试 275
9.1 实施要求和策略 276
9.2 WEB应用服务器的负载测试 278
9.2.1 负载测试的加载方式 278
9.2.2 负载测试的准备工作 279
9.2.3 负载测试的执行 282
9.2.4 负载测试的结果分析 284
9.3 WEB应用服务器的性能测试 285
9.4 WEB**性测试 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.1 TMMI和TPI NEXT分析 380
12.5.2 构建更实用的持续改进模型 382
附录A 软件测试全景图 388
附录B 测试计划(GB8567-2006) 391
附录C 测**例设计模板 398
附录D 软件缺陷模板 401
附录E 代码审查的示范性列表 403
附录F 软件测试相关的**标准 407
附录G 软件测试术语中英文对照 409
附录H 参考书目和资源 414

时隔6年,作者倾心打造的《全程软件测试(第2版)》全新亮相!