探索式软件测试

如何发现和修复被常规软件测试忽略的关键软件缺陷？在《探索式软件测试》中，享誉业界的软件测试专家Ja rrlesWhittaker揭示了当下很严重、隐藏很深的软件错误的真正诱因，并介绍了如何利用功能强大的探索式测试技术来找到并纠正这些错误。
先后就职于谷歌、微软和其他很好软件公司的james Whittaker，在软件测试的前沿阵地拥有近20年的丰富经验，他为传统的手工测试引入了可重复、规范、可传授和特别高效的新过程。Whittaker定义了针对单个测试人员的简单技术和针对大规模测试团队的复杂技术。他还引入了一个混合策略，将探索式概念引入传统脚本测试。在《探索式软件测试》中，可以体会到如何在恰当的时机使用这些方法，如何成功地充分应用这些方法。
简洁、诙谐和可行，《探索式软件测试》引入的这些技术已经经过上市软件的测试人员广泛应用，人们在实际测试过程中深受这些方法的启发，成功实现了预期目标。《探索式软件测试》是为测试人员、QA专家、开发人员、程序经理和架构师所写的。
《探索式软件测试》涉及以下重要问题：为什么自动化测试无法消除所有缺陷，如何才能让这些缺陷无处遁形？哪些技术可帮助我不断发现和消除致命错误？如何更高效地进行手工测试，增加些许轻松和愉悦的感觉？对于每个项目，如何确定优选效的不错测试策略？在我无法进行全部测试时，哪些输入是必须测试的？哪些测试用例能提供很理想的特性覆盖率？在结合使用探索测试和传统脚本或场景测试时，如何才能获得理想效果？如何体现来自开发过程的反馈意见，代码更改吗？

《探索式软件测试》任命软件测试人员，OA专家、开发人员、程序经理和架构师阅读，对他们的工作具有重要的启发作用。探索式软件测试作为一种富有创新精神和现实意义的测试方法，引起越来越多软件测试人员、质量保证人员和项目经理的高度重视。《探索式软件测试》作者结合自己二十年的经验，从多个角度结合富的实例阐述了探索式软件测试的使用技巧、提示和相关技术。全书共8章，3个附录，为手工测试流程提供了重要的指导，技术和规划。

James A.Whittaker，近日已加入谷歌担任测试工程主管，他曾在微软担任Visual Studio Team SysterTl架构师，负责为微软测试业务知名品牌产品策略，并领导内部团队应用探索式软件测试。
Whittaker博士曾在佛罗里达理工学院担任计算机科学教授一职。在校期间，他被The Jourhal of Systems and Software授予“首席学者”称号，并领导一个研究团队创建了许多靠前的测试工具和技术，包括备受称赞的运行时错误注入工具Holodeck。Wtlittaker博士还著有《如何攻破软件》、《如何破坏软件安全》和《如何破坏网络软件》。他发表过50+有关软件开发和安全的同级评审论文。他持有安全测试和安全防御技术方面多项发明的专利。
译者简介：
方敏，现任微软业洲工程院UIS项目首席测试部门主管，拥有20年软件测试管理和开发的丰富经验，曾参加过微软多项重大产品和技术的研制，包括UIS，Windows Server／Client／Security，SQL Server，Exchange Server，MSN，COM+Services，Windows Medi和微软内部IT工具等。方敏曾在清华大学获得电子工程学士和硕士学位，在美国新墨西哥技术学院获得计算机硕士学位。
张胜，现任微软总部不错软件开发测试主管，拥有10余年软件开发测试和团队管理经验，参与Visual Studio，SQL Server和Office Live的开发测试与发布，现主管Office Communications Server本地化软件开发测试工作。张胜拥有复旦大学计算机系硕七和学上学位。

第1章 软件质量 1
软件的魔力 1
软件失效 4
小结 9
练习题 9

第2章 手工测试 11
软件缺陷的根源 11
缺陷预防和检测 12
缺陷预防 12
缺陷检测 13
手工测试 15
手工测试中使用脚本 16
探索式测试 16
小结 21
练习题 21

第3章 局部探索式测试法 23
想不想测试软件？ 23
测试就是有所变，有所不变 25
用户输入 26
状态 36
软件状态的基本知识 36
如何测试软件状态 37
代码路径 39
用户数据 39
运行环境 41
小结 41
练习题 42

第4章 全局探索式测试法 45
探索软件 45
旅游者比喻 47
漫游测试 49
商业区测试类型 51
历史区测试类型 58
娱乐区测试类型 60
旅游区测试类型 63
旅馆区测试类型 66
破旧区测试类型 68
漫游测试法实战 70
小结 72
练习题 72

第5章 混合探索式测试技术 73
场景和探索 73
使用基于场景的探索式测试 75
通过场景操作引入变化 76
插入步骤 76
删除步骤 77
替换步骤 77
重复步骤 78
替换数据 78
替换环境 78
通过漫游测试引入变化 80
卖点测试法 80
地标测试法 81
极限测试法 81
深巷测试法 81
强迫症测试法 81
通宵测试法 81
破坏测试法 82
收藏家测试法 82
超模测试法 82
配角测试法 82
取消测试法 83
混票测试法 83
小结 83
练习题 83

第6章 实践中的探索式测试 85
漫游测试 85
Dynamics AX客户端的漫游 86
有用的探索漫游 87
收藏家测试法和收集缺陷 89
漫游测试提示 92
利用漫游查找隐错 94
测试用例管理解决方案的测试 94
取消测试法 95
破坏测试法 96
快递测试法 97
测一送一测试法 98
在Windows Mobile设备中的
漫游实践 98
我的测试方法和哲学 99
漫游测试法找到的有趣缺陷 101
破坏测试法实例 102
超模测试法实例 103
Windows媒体播放器的漫游测试
实践 105
Windows 媒体播放器 105
遍历测试法 106
超模测试法 108
极限测试法 109
与WMP相关的25个“假如”
类型的问题 109
极限测试法：边界之旅 110
停车场测试法及其在 Visual Studio
Team System测试版的应用 112
Sprint中的测试 112
停车场测试法 114
漫游测试中的测试规划与管理 115
定义地貌 115
旅行计划 116
让漫游测试运转起来 118
漫游结果的分析 118
判断：里程碑和发布 119
在实践中 119
小结 120
练习题 120

第7章 漫游与测试中的棘手问题 121
软件测试的五个棘手问题 121
漫无目的 122
重复性 124
暂时性 126
单调性 127
健忘 128
小结 130
练习题 130

第8章 软件测试的未来 131
欢迎来到未来世界 131
测试人员的专有提示显示 132
测试百科 134
测试用例的重用 135
测试原子和测试分子 136
虚拟化的测试资产 137
可视化 138
未来的测试 141
发布之后的测试 142
小结 143
练习题 144

附录1 经营成功的测试职业生涯 145
你是如何开始做测试工作的？ 145
回到未来 146
上山 147
巅峰 149
下山 150
附录2 JW的专业博客摘录 151
教我一些东西吧 151
软件诫律 151
测试错误代码 157
真正的职业测试人员，请上前一步 160
我找到的一些常见的共同特性
(无特别顺序) 161
建议总结 162
三击不中出局，是新的打击手上场的
时候了 163
正式方法 164
工具 164
流程改进 165
第四种提案 166
软件测试是艺术、技巧或学科？ 166
恢复对软件行业的尊重 169
事与愿违的过去 170
寻找更好的方法 171
分析安全漏洞和质量问题的
流程 171
附录3 JW微软博客修订版 175
加入博客圈 175
2008年7月 176
开篇 176
PEST(泡吧与软件测试) 177
测试人员评估 179
预防与治疗(一) 181
用户与John 182
手工测试人员的赞歌 182
预防与治疗(二) 185
欧洲，你好！ 186
测试赋 187
预防与测试(三) 189
回到测试 190
2008年8月 192
预防与治疗(四) 192
如果微软擅长测试，为什么软件
依然糟糕呢？ 194
预防与治疗(五) 197
自由式探索式测试 198
基于场景的探索式测试 198
基于策略的探索式测试 198
基于反馈的探索式测试 199
软件测试的未来(一) 199
软件测试的未来(二) 201
2008年9月 203
测试认证 203
软件测试的未来(三) 205
软件测试的未来(四) 207
软件测试的未来(五) 208
2008年10月 210
软件测试的未来(六) 210
软件测试的未来(七) 212
软件测试的未来(八) 214
谈到谷歌 216
再议手工测试与自动化测试 216
2008年11月 218
不再需要测试人员？ 218
让测试人员继续测试 219
2008年12月 220
谷歌与微软的开发∶测试
比例之争 220
2009年1月 221
Zune的问题 221
解释探索式测试 223
(未来的)测试用例重用 224
测试用例重用(续) 226
休假归来 227
鼹鼠和受感染的花生 228
……

    已经有很多文章阐述了漫无目的的生活会带来哪些坏处，但盲目的测试和现代测试实践中的无目标性，导致了这样一个问题。软件测试不是简单地拿起来就做的事情。它要求有计划、有准备、有策略和有多变的战术，这是成功进行软件测试的前提。但是，太多的软件企业因偏爱“想干就干”而忽略适当的准备。测试工作很好重要，所以决不能如此随便地对待它。
    我在佛罗里达理工学院担任教授的时候，我教过软件测试课程。有一个学期，注册这门课的学生多得超乎我的想象。我决定做一个试验，想把少数随意选择这门功课的学生吓走。在开学的第，我在计算机房上课，我指导学生们确定要测试的应用程序，两人为一个测试小组。我没有给学生们完成这个测试任务提供进一步的指导。作为鼓励，我答应他们，如果我对他们采用的技术留下深刻的印象，他们就会被留在我的班上。如果他们不能满足要求，我就认为他们自动放弃（我不是有意要赶他们走，但是这种要求达到了我想要的效果）。
    我在实验室里走来走去，无形中对学生们产生了压力，有时我会与一组学生攀谈，要求他们解释如何找到软件错误。每当我提出这样的问题，就会得到类似的答案，如“不太清楚，我们只希望它会出错。”很后，一些聪明的学生意识到这种回答并不奏效，他们在随后的回答中渐渐地开始包含一些策略。事实上，我清楚地记得有两个学生说“我们将要对所有的文本输入框输入较长的字符串，希望能够找到一些不检查字符串长度的地方。”①我当即接受他们成为我的靠前组学生，并鼓励他们继续做下去。
    太好了！虽然这不是优选的或者很重要的策略，但它至少是一种策略，有助于减少测试的无目标性。软件测试人员运行测试程序时，经常缺乏策略或没有指定明确的目标。在他们进行手工测试时，他们漫无目的地测试应用程序。在他们实现测试自动化时，仅仅由于他们熟悉怎样编写测试自动化，就去这么做了，而不考虑这样的自动化是否能发现有价值的缺陷，是否经得起时间的考验，是否值得付出维护费用。 ……