软件测试是一门新兴的学科，同时，又是一门越来越重要的学科。本书首先从软件测试的产生和定义出发，描述了一个完整的软件测试知识体系轮廓，让读者从全局来把握软件测试；然后，针对软件测试不同的知识点展开讨论。
　　本书在内容组织上力求创新，尽量使软件测试知识具有很好的衔接性和系统性，使需求和设计评审、软件测试用例设计、自动化测试和各个阶段的实际测试活动有机地结合起来，使读者更容易领会如何将测试的方法和技术应用到单元测试、功能测试、系统测试和本地化测试中去。本书提供了丰富的实例和实践要点，更好地体现软件测试学科的特点，使读者掌握测试方法的应用之道和品味测试的极佳实践。
　　本书条理清晰、语言流畅、通俗易懂，内容丰富、实用，理论和实践能有效地结合。本书可作为高等学校的软件工程专业、计算机软件专业和相关专业的教材，也可作为软件测试工程师以及其他各类软件工程技术人员的参考书。

《软件测试》条理清晰、语言流畅、通俗易懂，内容丰富、实用，理论和实践能有效地结合。《软件测试》可作为高等学校的软件工程专业、计算机软件专业和相关专业的教材，也可作为软件测试工程师以及其他各类软件工程技术人员的参考书。
　　内容与软件测试行业实际需求相吻合
　　理论和实践有机结合
　　简单易懂、循序渐进、案例丰富
　　《软件测试》从软件测试的基本概念出发，对单元测试、集成测试到功能测试、性能测试进行全面介绍，深入讲解其中涉及到的测试方法。《软件测试》将软件测试自动化作为重点内容进行介绍．包括测试工具的介绍、使用以及脚本的开发和维护。软件测试是一门实践性很强的课程，这对其教材的编写有更高的要求，《软件测试》充分吸收软件业界的经验和最佳实践，并力求简单易懂、循序渐进，配以丰富的案例。

　在过去半个世纪，软件获得了空前的发展，逐渐渗透到各个领域，从最早的科学计算、文字处理、数据库管理、银行业务处理，到工业自动控制和生产、办公自动化、新闻媒体、通信、汽车、消费电子、娱乐等，软件无处不在，改变了人类的生活与生产方式。随着计算机软件在各行各业的普及应用，人们对软件质量的要求也越来越高，软件的专业化和多样化特点越来越显著。但同时，我们看到软件产业目前还不够成熟，软件质量的现状不容乐观，软件在运行和使用过程中出现的问题还比较多。例如，2008年互联网Web发展十大失败事件中，90％都是由质量问题造成的，与"宕机"、"停机"、"崩溃"等一系列严重的质量问题联系在一起。
　　软件质量一直是软件工程中的一个焦点，成为人们几十年来不断研究、探索的领域。为了改善软件质量，人们不仅从企业文化、软件过程模型、需求工程、设计模式等不同方面来获取有效的方法和实践，而且开始重视软件测试，在软件测试上有更多的考虑和投入。虽然质量是内建的，但软件测试依旧承担着非常重要的作用。软件测试自身也在发生变化，已经不再只充当门卫——仅在软件发布之前进行检验，而是正在形成一个持续的反馈机制，贯穿软件开发的整个过程，以便尽早地发现问题，降低开发成本，提高软件开发生产力。软件测试人员不再是软件开发的辅助人员，而是软件开发团队的主体之一、积极的参与者。从项目开始的第一天，测试人员就参与项目需求和设计的讨论、评审等各种活动，尽早发现软件需求定义和设计实现上的问题，及时发现软件项目中存在的质量风险。软件开发团队必须尽可能地在交付产品之前控制未来的质量风险，这就必然需要依赖于卓有成效的软件测试。将传统的程序测试的狭义概念扩展到今日业界逐渐认可的、广义的软件测试概念，测试涵盖了需求验证（评审）、设计验证（评审）等活动。软f牛测试贯穿整个软件生命周期，从需求评审、设计评审开始，就介入到软件产品的开发活动或软件项目的实施中，和其他开发团队相互协作、相互补充，共同构成软件生命周期中的有机整体。
　　软件测试不是一项简单的工作，它远比人们所直观想象的要复杂。高效、高质量地完成一个软件系统的测试，涉及的因素很多，也会碰到各种各样的问题，并且要在测试效率和测试风险之间找到最佳平衡点和有效的测试策略，这些都需要测试人员一一克服。要做好软件测试，测试人员不仅需要站在客户的角度思考问题，真正理解客户的需求，具备良好的分析能力和创造性的思维能力，完成功能测试和用户界面的测试，而且要能理解软件系统的实现机理和各种使用场景，具备扎实的技术功底，能通过测试工具完成相应的性能测试、安全性测试、兼容性测试和可靠性测试等更具挑战性的任务。软件测试的主要目的是发现软件中的缺陷；坚持"质量第一"的原则，就会在实际操作中遇到一些阻力，这都需要测试人员去克服。从这些角度看，相对设计、编程人员，对一个优秀的测试工程师的要求要高得多，不仅要体现高超的技术能力，如系统平台设置、架构设计分析、编程等方面的能力，而且要展示自己的业务分析能力、对客户需求的理解能力和团队沟通协作的能力。

第1章 软件测试概述 1
1.1 一个真实的故事 1
1.2 为什么要进行软件测试 2
1.3 软件缺陷的由来 4
1.4 软件测试学科的发展历程 5
1.5 软件测试的定义 6
1.5.1 基本定义的正反两面性 6
1.5.2 服从于用户需求——V&V 7
1.6 软件测试和软件开发 8
1.6.1 软件测试过程 9
1.6.2 软件测试和开发的关系 11
小结 12
思考题 12


第2章 需求和设计评审 13
2.1 软件评审的方法与技术 13
2.1.1 什么是评审 13
2.1.2 评审的方法 15
2.1.3 评审会议 16
2.1.4 评审的技术 18
2.2 产品需求评审 19
2.2.1 需求评审的重要性 19
2.2.2 如何理解需求 21
2.2.3 需求评审的标准 22
2.2.4 如何对需求进行评审 24
2.3 设计评审 25
2.3.1 软件设计评审标准 25
2.3.2 系统架构设计的评审 27
2.3.3 组件设计的评审 28
2.3.4 界面设计的评审 28
小结 29
思考题 30


第3章 测试用例设计 31
3.1 什么是测试用例 31
3.1.1 一个简单的测试用例 31
3.1.2 测试用例的元素 32
3.2 为什么需要测试用例 33
3.3 测试用例的质量 34
3.3.1 测试用例的质量要求 34
3.3.2 测试用例书写标准 35
3.3.3 如何设计出高质量的测试用例 36
3.3.4 测试用例的评审 39
3.4 测试用例的组织和使用 40
3.4.1 测试用例的创建 40
3.4.2 测试用例套件 41
3.4.3 测试用例的维护 43
小结 43
思考题 44


第4章 软件测试自动化 45
4.1 测试自动化的内涵 45
4.1.1 简单的实验 46
4.1.2 自动化测试的例子 47
4.1.3 什么是自动化测试 48
4.1.4 自动化测试的特点和优势 49
4.2 自动化测试的原理 51
4.2.1 代码分析 51
4.2.2 GUI对象识别 52
4.2.3 DOM对象识别 54
4.2.4 自动比较技术 55
4.2.5 脚本技术 56
4.3 测试工具的分类和选择 59
4.3.1 测试工具的分类 59
4.3.2 测试工具的选择 61
4.4 自动化测试的引入 62
4.4.1 普遍存在的问题 62
4.4.2 对策 63
小结 65
思考题 66


第5章 单元测试和集成测试 67
5.1 什么是单元测试 68
5.2 单元测试的方法 68
5.2.1 黑盒方法和白盒方法 69
5.2.2 驱动程序和桩程序 70
5.3 白盒测试方法的用例设计 70
5.3.1 分支覆盖 71
5.3.2 条件覆盖 71
5.3.3 基本路径测试法 72
5.4 代码审查 74
5.4.1 代码审查的范围和方法 74
5.4.2 代码规范性的审查 75
5.4.3 代码缺陷检查表 76
5.5 集成测试 79
5.5.1 集成测试的模式 79
5.5.2 自顶向下集成测试 79
5.5.3 自底向上集成测试 80
5.5.4 混合策略 80
5.6 单元测试工具 81
5.6.1 JUnit介绍 82
5.6.2 用JUnit进行单元测试 83
5.6.3 微软VSTS的单元测试 87
5.6.4 开源工具 88
5.6.5 商业工具 91
小结 92
思考题 93


第6章 功能测试 94
6.1 功能测试 94
6.2 功能测试用例的设计 95
6.2.1 等价类划分法 96
6.2.2 边界值分析法 99
6.2.3 循环结构测试的综合方法 101
6.2.4 因果图法 102
6.2.5 决策表方法 105
6.2.6 功能图法 107
6.2.7 正交试验设计方法 108
6.3 可用性测试 111
6.3.1 可用性的内部测试 111
6.3.2 可用性的外部测试 114
6.4 功能测试执行 115
6.4.1 功能测试套件的创建 115
6.4.2 回归测试 116
6.5 功能测试工具 118
6.5.1 如何使用功能测试工具 118
6.5.2 开源工具 119
6.5.3 商业工具 121
小结 123
思考题 124


第7章 国际化和本地化测试 125
7.1 国际化和本地化的概念 125
7.2 国际化测试 126
7.2.1 软件国际化的基本要求 126
7.2.2 全球通用的字符集 128
7.2.3 国际化及其标准 129
7.2.4 国际化测试方法 132
7.2.5 国际化测试点 133
7.3 本地化测试 135
7.3.1 软件本地化的实现 135
7.3.2 功能测试 136
7.3.3 数据格式验证 138
7.3.4 UI验证 141
7.3.5 配置和兼容性验证 142
7.3.6 翻译验证 143
7.4 I18N和L10N测试工具 144
小结 146
思考题 146


第8章 系统测试 147
8.1 什么是系统测试 147
8.2 概念：负载测试、压力测试和性能测试 149
8.2.1 背景及其分析 149
8.2.2 定义 150
8.3 负载测试技术 151
8.3.1 负载测试过程 151
8.3.2 输入参数 152
8.3.3 输出参数 154
8.3.4 场景设置 155
8.3.5 负载测试的执行 157
8.3.6 负载测试的结果分析 157
8.4 性能测试 158
8.4.1 如何确定性能需求 159
8.4.2 性能测试类型 160
8.4.3 性能测试的步骤 160
8.4.4 一些常见的性能问题 163
8.4.5 容量测试 163
8.5 压力测试 164
8.6 性能测试工具 165
8.6.1 特性及其使用 165
8.6.2 开源工具 167
8.6.3 商业工具 169
8.7 兼容性测试 171
8.7.1 兼容性测试的内容 171
8.7.2 系统兼容性测试 172
8.7.3 数据兼容性测试 173
8.8 安全性测试 174
8.8.1 安全性测试的范围 174
8.8.2 Web安全性的测试 175
8.8.3 安全性测试工具 177
8.9 容错性测试 178
8.9.1 负面测试 178
8.9.2 故障转移测试 179
8.10 可靠性测试 181
小结 181
思考题 182


第9章 缺陷报告 183
9.1 一个简单的缺陷报告 183
9.2 缺陷报告的描述 184
9.2.1 缺陷的严重性和优先级 185
9.2.2 缺陷的类型和来源 186
9.2.3 缺陷附件 186
9.2.4 完整的缺陷信息列表 187
9.3 如何有效地报告缺陷 188
9.4 软件缺陷的处理和跟踪 189
9.4.1 软件缺陷生命周期 189
9.4.2 缺陷的跟踪处理 190
9.4.3 缺陷状态报告 191
9.5 缺陷分析 192
9.5.1 实时趋势分析 192
9.5.2 累计趋势分析 194
9.5.3 缺陷分布分析 195
9.6 缺陷跟踪系统 197
小结 199
思考题 199


第10章 测试计划和管理 200
10.1 测试的原则 200
10.2 测试计划 202
10.2.1 概述 203
10.2.2 测试计划过程 203
10.2.3 测试目标 204
10.2.4 测试策略 205
10.2.5 制定有效的测试计划 208
10.3 测试范围分析和工作量估计 209
10.3.1 测试范围的分析 209
10.3.2 工作量的估计 210
10.4 资源安排和进度管理 212
10.4.1 测试资源需求 212
10.4.2 团队组建与培训 213
10.4.3 测试进度管理 214
10.5 测试风险的控制 215
10.5.1 主要存在的风险 215
10.5.2 控制风险的对策 217
10.5.3 测试策略的执行 218
10.6 测试报告 219
10.6.1 评估测试覆盖率 220
10.6.2 基于软件缺陷的质量评估 221
10.6.3 测试报告的书写 223
10.7 测试管理工具 223
10.7.1 测试管理系统的构成 223
10.7.2 主要工具介绍 225
小结 226
思考题 227


附录A 软件测试术语中英文对照 228
附录B 测试计划简化模板 233
附录C 测试用例设计模板 235
附录D 软件缺陷模板 237
附录E 软件测试报告模板 239
参考文献 242

2．缺乏相应的人才有些软件公司舍得花几十万元去买测试工具软件，但缺乏具有良好素质、经验的测试人才。软件测试自动化并不是简简单单地使用测试工具，需要建立良好的自动化测试框架、开发测试脚本，这就要求测试人员不仅要熟悉产品的特性和领域知识，而且要掌握开发平台构建技术和具备较高的编程能力。
　　3．测试脚本的质量低劣有些软件组织对待测试脚本，不像对待软件产品自身的源代码，既没有将脚本进行有效的配置管理，也没有遵守设计原则和编码规范，测试脚本存在很多问题，例如结构混乱、变量命名不规范、缺少注释等，从而导致测试脚本的质量低劣。测试脚本的质量将直接影响到测试执行过程，脚本执行不稳定，并导致测试结果不准确、不可靠。
　　4．缺乏培训
　　在引入测试工具前后，有些组织缺乏对测试人员的培训，其结果，测试人员对测试工具了解的深度和广度都不够，从而导致测试工具的使用效率低下，不能达到管理者的期望。测试自动化的培训是一个长期的实践过程，不是通过一两次讲课的形式就能达到效果，而应该提供具有实际项目背景的系列培训，从头开始，逐步深入，直至掌握主要的方法和技巧等。
　　5．没有考虑到公司的实际情况。盲目引入测试工具
　　有一点很明确，不同的测试工具面向不同的测试目的、具有各自的特点和适用范围，所以不是任何一个优秀的测试工具都能适应不同公司的需求。某个公司怀着美好的愿望花了不小的代价引入测试工具，半年一年以后，测试工具却成了摆设。究其原因，就是没有能够考虑公司的现实情况，不切实际地期望测试工具能够改变公司的现状，从而导致了失败。
　　例如，许多软件公司是针对最终用户进行一次性的项目开发，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下就不适合引入功能测试工具，因为需求、界面变化比较大，测试脚本的开发和维护工作量很大，而脚本的复用频率不高，从而导致投入产出率很低，不但不能减轻工作量，反而加重了测试人员的负担。