标题：软件测试的各种幻想
图书信息
作　者：[美]Gerald M. Weinberg(杰拉尔德 M.温伯格)　著  
  宋锐　译
出 版 社： 电子工业出版社
出版时间： 2009-12-1
页　数：376页
开　本： 16开
ISBN 978-7-121-09931-1
分类： 图书>>软件测试
估价：55.00元
宣传语
“程序设计心理学”一书作者Weinberg的另一力作
内 容 简 介
本书是从事软件行业五十余年的Gernald M. Weinberg针对软件测试所写的新作。他在软件项目的管理、设计、开发和测试方面都具有极其丰富的经验，对于与软件开发有关人员的心理尤其有深入的研究。在本书中，他重点讨论了与软件测试有关的各种心理问题及其表现与应对方法。作者首先阐述软件测试之所以如此困难的原因——人的思维不是完美的，而软件测试的最终目的就是发现对改善软件产品和软件开发过程有益的信息，故软件测试是一个信息获取的过程。接着，作者利用丰富的经历和大量的实例，展现了在软件测试中可能会出现的各种与人的心理有关的现象、误区、欺诈，以及容易犯下的常见错误等等。本书的重点不是告诉大家要做什么或者说如何做，而更多的是让读者明白在与软件测试相关的活动中会出现某些特定现象的原因。理解这些与人的心理有关的现象有助于与软件开发有关的所有人之间更好地就软件测试的目的和实现过程进行沟通，从而实现具有更高品质的软件
前    言
五十多年以前，当我刚开始从事计算机行业的时候，计算机是极其稀少而珍贵的。当我发现自己坐在一间巨大的房间前的控制台面前时，还只是一个十几岁的少年。那个房间里塞满了硬件，大约拥有当时世界上整个计算能力的百分之十。我只要伸出手指按一下，就可以关掉这样的计算能力——有时候这确实就是我的工作。
只要愿意排队，你就可以用大约两倍于我月薪的钱来租用这样的计算能力一个小时。今天，计算机已经非常便宜，实际上我已经在捐赠一些计算速度比那些早期型号快五万倍，内存也要大五万倍的计算机。捐赠的这些机器非常紧凑而轻便，我可以很轻松地把它放进公文包中。而它的计算能力却连当今世界计算能力的十亿分之一都不到。
显然，我目睹了计算机技术的长足发展，不过这一发展对我的影响是潜移默化的。我实际上并未注意到这些变化，直到几年前听到一则有关卡纳维拉尔角取消一次火箭发射的新闻报道。在播音员结束新闻报道时，其中一人说：“太空总署（NASA）说这是一个计算机软件错误。”
另一名播音员回应道：“像计算机这么简单而常见的东西也会出这样的错，难道不奇怪吗？”
第一个人回答道：“是很奇怪，难道你认为他们不会对软件进行测试？”
不错，我认为他们会对软件进行测试。事实上，我确信他们进行了测试。不过，播音员显然认为测试必然应该产生完美的、没有任何缺陷的产品。
我无法停止思考这段对话以及播音员不切实际的期望。一开始，我只是耸耸肩膀，对自己说：“这就是普通大众对软件测试的无知。”不过现在要忽视这一问题已经太晚了。我的警觉已经被提高了。我开始发现甚至我那些生产软件的客户公司的经理们也表现出了同样的无知。尤其是那些经理们，软件测试简直要让他们抓狂。
我是一个容易认同别人感情的人。当我周围的人痛苦时，我会同样感到痛苦。我理解软件经理们正在感受痛苦，他们的员工和客户同样如此。我还知道他们感到痛苦的原因，几乎所有人都并不完全是因为软件测试非常复杂或者耗时耗力，而更多的是由于他们对软件测试的不合理期望和那些靠不住的测试模型。
“最后，我决定还是按照我发现无知导致了问题时喜欢采用的应对方法来做：写下这个问题以及可能的解决方案。我写下的内容最终形成了本书。”
在我多年以前写作《The Psychology of Computer Programming》一书时，我希望它能够帮助那些想了解编程的人[1]。有不少人告诉我它确实为他们提供了帮助，所以，在一定程度上也许是那本书的成功促使我着手写作这本书：为了帮助那些想了解测试的人。
这本书的预期读者非常广泛：我预想这本书会拿在专业测试人员、开发人员、客户、分析师、设计师、程序员，以及他们的所有经理和同事手中。
大部分专业测试人员都知道这本书中的大部分内容，但我还是希望他们可以通过阅读本书发现与他们的经理、开发人员、同事和客户交流他们知道的那些信息的新途径。
我希望能够帮助开发人员和测试人员了解他们的经理在遇到软件测试事宜时会面对哪些情况。
我希望能够帮助客户，也就是那些买软件的人，了解更多的信息。
最后，既然现在每个人都会受到软件的影响，并且受到未经良好测试的软件的伤害，我希望能够帮助所有人更为注意测试。
由于我希望能够获得广泛的受众，所以我选择尽可能使用平直的文字，避免那些高度技术化的术语和过于详细的分析。（对于那些有兴趣学习有关软件测试的更多技术细节的人，我在本书结尾的其他阅读材料部分指出了一些非常可靠的参考书籍。）为了集中精力帮助那些希望了解软件测试的人，我根据下面这些会让大多数人感到困惑的问题来组织本书：
为什么在看起来测试只会耽搁时间的时候我们还要进行测试？
为什么大家不能一开始就构建正确的软件，从而不需要测试？
我们需要对所有的可能都进行测试吗？
为什么不对所有的可能都进行测试？
是什么原因导致测试如此困难？
为什么测试需要这么长的时间？
是否有可能构建完美的软件？
为什么我们就是不能接受一些缺陷？
G. M. W.           
2008年4月于新墨西哥州阿尔伯克基
目    录
前  言 XXI
第1章  进行测试的原因 1
1.1  人类不是完美的思考者 3
1.2  我们要做出有关软件的决定 3
1.2.1  日记条目1 3
1.2.2  日记条目2 5
1.2.3  日记条目3 5
1.2.4  日记条目4 7
1.2.5  日记条目5 7
1.2.6  日记条目6 7
1.3  决定可能是有风险的 9
1.4  测试可以提供降低风险的信息 13
1.5  小结 17
1.6  常见错误 17
第2章  测试无法做的事 21
2.1  信息不一定有助于降低风险 23
2.2  也许我们不会使用那些花钱得到的信息 25
2.3  决定是感性的而不是理性的 27
2.4  不良的测试也许比不测试更糟 29
2.5  产品可能尚未准备好接受测试 31
2.6  小结 33
2.7  常见错误 33
第3章  不对所有可能性进行测试的原因 39
3.1  可能进行测试的数目是无限的 39
3.2  测试最多只是采样 43
3.3  信息的成本可能超过无知的成本 45
3.4  我们也许可以用较少的测试获取更多的信息 47
3.5  测试自助餐 47
3.6  小结 49
3.7  常见错误 49
第4章  测试和除错的区别 53
1．通过测试来发现 53
2．查明问题 55
3．定位 55
4．确定重要性 57
5．修改 57
6．解决问题 57
7．通过测试来学习 59
8．任务切换 61
4.1  测试会随着机构的成长发生变化 61
4.2  以时间限制试探法作为管理法则，但根据需要进行调整 65
4.3  小结 67
4.4  常见缺陷 67
第5章  元测试 73
5.1  我们有说明书，但是找不到了 75
5.2  我们的错误太多了，导致缺陷数据库无法高效运转 75
5.3  我们没找到任何缺陷，实际上我们并没有真正地找 77
5.4  我们修改记录让缺陷看起来没那么严重 77
5.5  这不是我的组件中的问题，所以我不记录 79
5.6  我不知道在测试错误的应用程序 79
5.7  我们不测试最差的组件，因为花得时间太长 81
5.8  我们发现了这么多缺陷，不会还有更多的 81
5.9  我们的测试证明程序是正确的 83
5.10  我们运行了很多测试用例，根本就看不过来 83
5.11  如果我们的软件在有三名用户时工作良好，显然
它在有一百名用户时也不会有问题 83
5.12  我们不希望测试人员知道我们将忽略他们提供的信息 85
5.13  我没有报告缺陷，所以开发人员不会对我发脾气 87
5.14  我们不需要测试它，因为开发人员非常有水平 87
5.15  接着说元信息 89
5.16  小结 89
5.17  常见错误 91
第6章  信息免疫 95
6.1  我们在生存规则受到威胁的时候会感到害怕 97
6.2  我们压抑无法接受的事物 99
6.3  我们让不可接受的事物合理化 101
6.4  我们将自己的负面品质投射给其他人 105
6.5  我们转移指责从而免除自己的责任 107
6.6  我们对自己的不足进行过度补偿 111
6.7  我们在觉得失去控制时开始出现强迫 111
6.8  小结 113
6.9  常见错误 113
第7章  如何应对防卫反应 119
7.1  确定恐惧 121
7.2  使用危机思维 121
7.3  实践，实践，再实践 123
7.4  对自己进行测试 125
7.5  小结 127
7.6  常见错误 127
第8章  良好测试的要素 129
8.1  永远无法确切地知道 129
8.2  只能根据事实来评估良好性 131
8.3  可能希望故意插入一些缺陷 135
8.4  对良好性的估算总是统计性的 135
8.5  可以对非差性进行估算 137
8.6  小结 139
8.7  常见错误 139
第9章  有关测试的主要误区 143
9.1  指责误区 143
9.2  穷举测试误区 145
9.3 “测试产生质量”误区 147
9.4  分解误区 149
9.5  合成误区 151
9.6 “所有测试都相同”误区 151
9.7 “随便哪个笨蛋都可以测试”误区 155
9.8  小结 157
9.9  常见错误 157
第10章  测试不仅仅是敲击键盘 161
10.1  毫无目的地敲击键盘是不是测试 163
10.2  白手套测试 165
10.3  狗食测试 167
10.4  对测试人员也要进行测试 171
10.5  可能在没有意识到的情况下进行测试 173
10.6  演示不是测试 173
10.7  小结 175
10.8  常见错误 175
第11章  信息摄取 181
11.1  使用萨提亚交互模型来解析沟通 181
11.1.1  摄取 183
11.1.2  确定含义 183
11.1.3  确定重要性 185
11.1.4  做出反应 185
11.2  人们听取信息时是有选择性的 187
11.3  数据来源会影响到摄取 187
11.4  时机也会导致差异 189
11.5  人们会出现信息过载 191
11.6  减少测试的数量也许可以传递更多的信息 193
11.7  寻找测试之外的信息摄取 193
11.8  不要混淆理解和摄取 195
11.9  使用数据质疑来过滤理解 197
11.10  小结 197
11.11  常见错误 197
第12章  确定含义 201
12.1  案例1：四个缺陷，五种含义 201
12.2  案例2：四个缺陷，七种含义 205
12.3  案例3：四个缺陷，自行确定含义 207
12.4  进行解释之前先弄清期望的是什么 209
12.5  不知道期望时的做法 211
12.6  使用已经获得的信息 213
12.7  使用间接信息 213
12.8  使用未获得的信息 215
12.9  同样的话可能具有不同的含义 217
12.10 “相同”可能并不一样 217
12.11  某些时候不精确会更好 219
12.12  小结 221
12.13  常见错误 221
第13章  确定重要性 225
13.1  不同的人会给同样的信息赋予不同的重要性 227
13.2  公共的重要性也许与对个人的不一样 229
13.3  重要性依赖于上下文环境 231
13.4  不能总是根据金钱来确定重要性 233
13.5  不要采用过细的尺度 237
13.6  首先解决重要问题 237
13.7  听从自己的情绪反应 239
13.8  小结 243
13.9  常见错误 243
第14章  做出反应 247
14.1  是运气不好还是管理不善 247
14.2  项目最后会赶进度的原因 249
14.3  接近项目结束时应如何反应 253
14.4  对测试所需时间的估算与现实差距很大的原因 255
14.4.1  好天气估算 255
14.4.2  不切实际的过程模型 255
14.4.3  低质的过程数据 257
14.4.4  没有过程数据 261
14.5  确定是否已经错过了可以有所改变的时刻 263
14.6  小结 263
14.7  常见错误 265
第15章  避免软件测试变得越发困难 267
15.1  情况变得更糟的原因 267
15.2  让系统尽可能小 269
15.3  让“系统”模型是可扩展的 271
15.4  增量构建有清晰接口的分立组件 273
15.5  减少进入产品的缺陷数目 275
15.6  小结 275
15.7  常见错误 275
第16章  不使用机器进行测试 279
16.1  用机器进行测试总是不够的 279
16.1.1  即时评审 281
16.2  首先对最差的部分进行评审可以让人了解缺陷的严重性 293
16.3  事实并不总是能令人信服 295
16.4  测试人员是颇有价值的评审者 295
16.5  小结 297
16.6  常见错误 297
第17章  测试欺诈 301
17.1  我们会卖给你一个神奇的工具 301
17.2  我们的演示是欺诈 303
17.3  这么多的证明信表明它一定很好 307
17.4  我们可以通过定价来欺诈 307
17.5  我们的工具会读心术 309
17.6  我们保证你不用做任何事 313
17.7  我们一起密谋 313
17.8  避免欺诈的方法 315
17.9  小结 315
17.10  常见错误 315
第18章  忘却型欺诈 319
18.1  推迟文档化造成的后果 319
18.2  不明确的测试报告就像流沙一样 319
18.3  伪造的测试报告阻止了改进 321
18.4  在别的地方进行报复 323
18.5  早期的答案可能产生误导 323
18.6 “量”不是“质”的同义词 325
18.7  不要将非测试活动当做测试 327
18.8  太整洁了，不可能是真的 329
18.9  电子表格中的垃圾还是垃圾 331
18.10  小结 331
18.11  常见错误 331
尾声 333
尾注 335
其他阅读材料 343