敏捷软件测试 测试人员与敏捷团队的实践指南PDF电子书下载

第Ⅰ部分 简介 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