第Ⅰ部分 简介 3
第1章 敏捷测试的定义 3
1.1 敏捷价值 3
1.2 “敏捷测试”意味着什么 4
1.3 敏捷团队中角色和活动的情境 6
1.4 敏捷测试有何不同 7
1.5 整体团队运作方式 11
1.6 小结 12
第2章 敏捷测试人员的十条法则 15
2.1 敏捷测试人员的定义 15
2.2 敏捷测试思想 16
2.3 应用敏捷法则和价值 16
2.4 创造价值 23
2.5 小结 24
第Ⅱ部分 组织挑战 27
第3章 文化挑战 27
3.1 组织文化 27
3.2 测试／质量保证团队成功适应敏捷的障碍 31
3.3 引入变化 35
3.4 管理层期望 36
3.5 改变并不容易 39
3.6 小结 40
第4章 团队构成 41
4.1 团队结构 41
4.2 人员分布 44
4.3 人力资源 45
4.4 团队建设 47
4.5 小结 49
第5章 迁移传统过程 51
5.1 寻找轻量级过程 51
5.2 度量标准 52
5.3 缺陷跟踪 55
5.4 测试计划 60
5.5 现有的过程和模型 61
5.6 小结 64
第Ⅲ部分 敏捷测试象限 67
第6章 测试的目的 67
6.1 敏捷测试象限 67
6.2 知道一个用户故事何时完成 72
6.3 管理技术债务 73
6.4 上下文环境中的测试 73
6.5 小结 74
第7章 支持团队的面向技术测试 75
7.1 敏捷测试基础 75
7.2 为什么编写并运行这些测试 77
7.3 面向技术的测试在何处停止 82
7.4 如果团队不做这些测试怎么办 83
7.5 工具箱 84
7.6 小结 86
第8章 支持团队的面向业务测试 89
8.1 通过面向业务测试驱动开发 89
8.2 需求困境 91
8.3 小增量 98
8.4 如何知道我们完成了 100
8.5 小结 102
第9章 面向业务测试工具包 103
9.1 面向业务测试的工具策略 103
9.2 激发示例和需求的工具 104
9.3 基于示例自动化测试的工具 111
9.4 编写测试的策略 119
9.5 可测试性 123
9.6 小结 125
第10章 评价产品的面向业务测试 127
10.1 象限三简介 127
10.2 实例演示 129
10.3 场景测试 129
10.4 探索测试 131
10.4.1 基于会话的测试 135
10.4.2 自动化和探索测试 136
10.4.3 探索测试人员 136
10.5 可用性测试 136
10.5.1 用户需求和角色测试 136
10.5.2 导航 137
10.5.3 研究竞争对手 138
10.6 图形用户界面背后 138
10.6.1 API测试 138
10.6.2 Web服务 140
10.7 测试文档和文件 140
10.7.1 用户文档 140
10.7.2 报告 141
1 0.8 探索测试辅助工具 142
10.8.1 测试设置 143
10.8.2 生成测试数据 144
10.8.3 监控工具 144
10.8.4 模拟器 144
10.8.5 仿真器 144
10.9 小结 145
第11章 利用面向技术的测试评价产品 147
11.1 象限四简介 147
11.2 谁应该做 149
11.3 何时做 150
11.4 ility测试 151
11.4.1 安全性 151
11.4.2 可维护性 153
11.4.3 交互性 154
11.4.4 兼容性 155
11.4.5 可靠性 155
11.4.6 可安装性 156
11.4.7 ility小结 157
11.5 性能、负载、压力以及可伸缩性测试 157
11.5.1 可伸缩性 157
11.5.2 性能与负载测试 158
11.5.3 性能与负载测试工具 158
11.5.4 基准 159
11.5.5 测试环境 160
11.5.6 内存管理 160
11.6 小结 161
第12章 测试象限总结 163
12.1 回顾测试象限 163
12.2 系统测试实例 164
12.2.1 介绍该应用软件 164
12.2.2 团队和工作流程 165
12.3 测试驱动开发 166
12.3.1 单元测试 166
12.3.2 验收测试 166
12.4 自动化测试 166
12.4.1 自动化的功能测试结构 167
12.4.2 Web服务 168
12.4.3 嵌入式测试 168
12.5 评判产品的面向业务测试 169
12.5.1 探索性测试 169
12.5.2 测试数据源 169
12.5.3 端对端测试 169
12.5.4 用户验收测试 170
12.5.5 可靠性测试 170
12.6 文档 170
12.6.1 用文档记录测试代码 170
12.6.2 汇报测试结果 171
12.7 熟练运用测试象限 172
12.8 小结 172
第Ⅳ部分 自动化 175
第13章 自动化的原因和障碍 175
13.1 为什么要自动化 175
13.1.1 手动测试需要太长的时间 176
13.1.2 手动过程容易出错 176
13.1.3 自动化让人们有时间做更有价值的工作 177
13.1.4 自动化回归测试提供了安全网 178
13.1.5 自动化测试较早并频繁地给出反馈 179
13.1.6 驱动编码的测试和实例可以做更多事情 179
13.1.7 测试是强大的文档 179
13.1.8 投资回报率和回报 180
13.2 自动化的障碍——妨碍自动化的因素 180
13.2.1 Bret的列表 180
13.2.2 我们的列表 181
13.2.3 程序员的态度——“为什么要自动化” 181
13.2.4 “痛苦的积累”（学习曲线） 181
13.2.5 初始投入 182
13.2.6 总是改变的代码 183
13.2.7 遗留代码 184
13.2.8 恐惧 184
13.2.9 旧的习惯 184
13.3 可以克服这些障碍吗 184
13.4 小结 185
第14章 敏捷测试自动化策略 187
14.1 测试自动化的敏捷方法 188
14.1.1 自动化测试的分类 188
14.1.2 测试自动化金字塔 189
14.2 哪些测试可以自动化 191
14.2.1 持续集成、构建与部署 192
14.2.2 单元与组件测试 193
14.2.3 API或Web Services测试 193
14.2.4 GUI底层的测试 193
14.2.5 测试GUI 193
14.2.6 负载测试 194
14.2.7 比较 194
14.2.8 重复的任务 194
14.2.9 创建数据 194
14.3 什么测试不应该自动化 195
14.3.1 可用性测试 195
14.3.2 探索性测试 196
14.3.3 永远不会失败的测试 196
14.3.4 一次性测试 196
14.4 哪些测试不易于自动化 197
14.5 从哪里开始自动化策略 198
14.5.1 不愿自动化的原因 198
14.5.2 多层方法 199
14.5.3 思考测试设计与维护 200
14.6 选择正确的工具 201
14.7 将敏捷法则应用到测试自动化上 204
14.7.1 保持简单 204
14.7.2 迭代式反馈 205
14.7.3 整体团队运作方案 205
14.7.4 花时间做正确的事情 207
14.7.5 边做边学 208
14.7 6 将敏捷编码实践应用到测试上 208
14.8 为测试提供数据 209
14.8.1 数据生成工具 209
14.8.2 避免访问数据库 210
14.8.3 如果数据库访问不可避免或是必须要使用数据库 211
14.8.4 明确所需 213
14.9 评估自动化工具 213
14.9.1 确定自动化工具的需求 213
14.9.2 一次一个工具 214
14.9.3 选择工具 215
14.9.4 适用于敏捷的工具 217
14.10 实现自动化 217
14.11 管理自动化测试 219
14.11.1 组织测试 219
14.11.2 组织测试结果 221
14.12 开始行动 222
14.13 小结 222
第Ⅴ部分 测试人员经历的一个迭代第15章 测试人员在发布或主题计划阶段的工作 227
15.1 制定发布计划的目的 227
15.2 故事评估 229
15.2.1 如何评估故事 229
15.2.2 测试人员在评估故事工作中的角色 230
15.2.3 一个故事评估的实例 231
15.3 设定优先级 233
15.3.1 为什么要为故事设定优先级 234
15.3.2 设定优先级时关于测试的注意事项 234
15.4 开发的范围 235
15.4.1 截止日期和时间表 235
15.4.2 关注产品价值 236
15.4.3 系统范围的影响 236
15.4.4 第三方的介入 238
15.5 制订测试计划 238
15.5.1 从何处开始 239
15.5.2 为什么要写测试计划 239
15.5.3 测试的种类 239
15.5.4 测试基础设施 240
15.5.5 测试环境 240
15.5.6 测试数据 241
15.5.7 测试结果 241
15.6 测试计划的可选形式 242
15.6.1 轻量级测试计划 242
15.6.2 使用测试矩阵 243
15.6.3 测试表格 245
15.6.4 白板 245
15.6.5 自动化的测试列表 245
15.7 准备可见性 245
15.7.1 跟踪测试任务及其状态 245
15.7.2 传达测试结果 248
15.7.3 产品发布的关键 248
15.7.4 已通过的测试数 248
15.7.5 代码覆盖率 250
15.7.6 缺陷度量 252
15.8 小结 254
第16章 迭代前的准备 255
16.1 积极主动 255
16.1.1 益处 256
16.1.2 真的需要吗 257
16.1.3 提前准备的潜在弱点 258
16.2 事先明确 258
16.2.1 客户意见一致 258
16.2.2 用户故事的规模 259
16.2.3 地域分散的团队 260
1 6.3 实例 261
16.4 测试策略 263
16.5 确定缺陷的优先级 264
16.6 资源 264
16.7 小结 264
第17章 迭代开始 265
17.1 迭代计划 265
17.1.1 了解细节 266
17.1.2 考虑所有观点 267
17.1.3 确定工作量 272
17.2 可测试故事 272
17.3 与客户协作 274
17.4 高层次测试和示例 275
17.4.1 与客户一起审查 277
17.4.2 与开发人员一起审查 277
17.4.3 测试用例作为文档 278
17.5 小结 278
第18章 编码和测试 279
18.1 驱动开发 280
18.1.1 从简单入手 280
18.1.2 增加复杂度 280
18.1.3 评估风险 280
18.1.4 编码和测试同时进行 282
18.1.5 识别变更 282
18.1.6 三方协作的力量 283
18.1.7 关注一个故事 283
18.2 评判产品的测试 284
18.3 与开发人员协作 284
18.3.1 结对测试 284
18.3.2 自我展示 285
18.4 与客户交流 285
18.4.1 展示给客户 285
18.4.2 理解业务 286
18.5 完成测试任务 286
18.6 处理缺陷 287
18.6.1 这是一个缺陷还是一项功能 287
18.6.2 技术债务 287
18.6.3 零缺陷容忍 288
18.7 如何选择 288
18.7.1 判断应该记录哪些缺陷 289
18.7.2 何时修补缺陷 290
18.7.3 选择记录缺陷的介质 291
18.7.4 处理缺陷的方案和建议 292
18.7.5 从简单入手 294
18.8 促进沟通 295
18.8.1 测试人员促进沟通 295
18.8.2 分散式团队 296
18.9 回归测试 297
18.9.1 确保构建“通过” 297
18.9.2 确保构建快速 298
18.9.3 构建回归测试集 298
18.9.4 注意“全局观” 298
18.10 资源 298
18.11 迭代度量 299
18.11.1 度量进度 299
18.11.2 缺陷度量 300
18.12 小结 302
第19章 迭代结束时的收尾工作 303
19.1 迭代演示 303
19.2 迭代回顾 304
19.2.1 开始、停止、继续 304
19.2.2 做出改进 306
19.3 庆祝成功 307
19.4 小结 309
第20章 成功的交付 311
20.1 产品的构成 311
20.2 为测试计划足够的时间 313
20.3 结束阶段 313
20.3.1 测试候选发布构建 314
20.3.2 在分期环境上测试 314
20.3.3 最后的非功能测试 315
20.3.4 与外部应用集成 315
20.3.5 数据转换和数据库更新 315
20.3.6 安装测试 317
20.3.7 沟通 317
20.3.8 如果没有准备好该怎么办 318
20.4 客户测试 319
20.4.1 UAT（用户验收测试） 319
20.4.2 alpha/beta测试 320
20.5 开发后的测试周期 320
20.6 可交付的东西 322
20.7 发布产品 323
20.7.1 发布验收标准 323
20.7.2 发布管理 325
20.7.3 打包 326
20.8 客户期望 326
20.8.1 产品支持 326
20.8.2 理解对业务的影响 326
20.9 小结 327
第Ⅵ部分 总结 331
第21章 关键成功要素 331
21.1 成功要素之一：使用团队整体参与的方法 331
21.2 成功要素之二：采用敏捷测试思维 332
21.3 成功要素之三：自动化回归测试 333
21.4 成功要素之四：提供并获取反馈 333
21.5 成功因素之五：构建核心实践的基础 334
21.5.1 持续集成 334
21.5.2 测试环境 335
21.5.3 管理技术债务 335
21.5.4 增量工作 335
21.5.5 编码和测试是同一个过程的组成部分 336
21.5.6 实践之间的协作 336
21.6 成功因素之六：与客户合作 336
21.7 成功要素之七：保持大局观 337
21.8 小结 337
术语表 339
参考文献 345