《颠覆完美软件：软件测试必须知道的几件事》 - Gerald M. Weinberg[杰拉尔德.温伯格] 著 - 电子工业出版社 - 香港大書城

	登入帳戶　 \|　訂單查詢　 \|　購物車/收銀台(0)　\|　在線留言板　 \|　付款方式　 \|　運費計算　 \|　聯絡我們　 \|　幫助中心　\|　加入書簽
		會員登入新用戶登記

HOME

新書上架

暢銷書架

好書推介

2023年度TOP

臺灣用戶

品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心

服務：香港／台灣／澳門／海外

送貨：速遞／郵局／服務站

新書上架：簡體書繁體書
暢銷書架：簡體書繁體書
好書推介：簡體書繁體書

『簡體書』颠覆完美软件：软件测试必须知道的几件事

書城自編碼： 2575853
分類：簡體書→大陸圖書→計算機/網絡→软件工程/开发项目管理
作者： Gerald M. Weinberg[杰拉尔德.温伯格] 著
國際書號(ISBN)： 9787121258619
出版社：电子工业出版社
出版日期： 2015-07-01
版次： 1 印次： 1
頁數/字數： 176/195000
書度/開本： 16开釘裝：平装

售價：HK$ 90.7

我要買件

** 我創建的書架 **
未登入.

新書推薦：

《一间只属于自己的房间女性主义先锋伍尔夫代表作女性精神独立与经济独立的象征，做自己，比任何事都更重要》
售價：HK$ 44.6

《泉舆日志幻想世界宝石生物图鉴》
售價：HK$ 134.2

《养育女孩：官方升级版》
售價：HK$ 50.4

《跨界：蒂利希思想研究》
售價：HK$ 109.8

《千万别喝南瓜汤（遵守规则绘本）》
售價：HK$ 44.7

《大模型启示录》
售價：HK$ 112.0

《东法西渐：19世纪前西方对中国法的记述与评价》
售價：HK$ 201.6

《养育男孩：官方升级版》
售價：HK$ 50.4

建議一齊購買：

HK$ 90.7
《技术管理之巅：如何从零打造高质效互联网技术团队?》

HK$ 146.2
《Python 3面向对象编程》

HK$ 146.2
《程序开发心理学（银年纪念版）》

HK$ 127.7
《成为技术领导者：掌握全面解决问题的方法》

HK$ 120.3
《高性能网站建设进阶指南：Web开发者性能优化最佳实践》

HK$ 166.3
《图灵的大教堂：数字宇宙开启智能时代》

編輯推薦：

推荐购买：

《像外行一样思考，像专家一样实践》——科研成功之道（修订版）

《代码大全
第2版》——两届Software Jolt Award震撼大奖得主！软件开发世界的地图，经典中的经典

《成为技术领导者》：掌握全面解决问题的方法

程序开发心理学（银年纪念版）

编码：隐匿在计算机软硬件背后的语言永不退色的计算机科学经典著作

內容簡介：

本书是从事软件行业五十余年的Gerald M. Weinberg针对软件测试所写的新作。他在软件项目的管理、设计、开发和测试方面都具有极其丰富的经验，对于与软件开发有关人员的心理尤其有深入的研究。在本书中，他重点讨论了与软件测试有关的各种心理问题及其表现与应对方法。作者首先阐述软件测试之所以如此困难的原因——人的思维不是完美的，而软件测试的最终目的就是发现对改善软件产品和软件开发过程有益的信息，故软件测试是一个信息获取的过程。接着，作者利用丰富的经历和大量的实例，展现了在软件测试中可能会出现的各种与人的心理有关的现象、误区、欺诈，以及容易犯下的常见错误等等。

1 进行测试的原因1
1.1 人类不是完美的思考者2
1.2 我们要做出有关软件的决定2
1.2.1 日记条目12
1.2.2 日记条目23
1.2.3 日记条目33
1.2.4 日记条目43
1.2.5 日记条目54
1.2.6 日记条目64
1.3 决定可能是有风险的5
1.4 测试可以提供降低风险的信息6
1.5 小结8
1.6 常见错误8
2 测试无法做的事10
2.1 信息未必有助于降低风险11
2.2 也许我们不会使用那些花钱得到的信息12
2.3 决定是感性的而不是理性的13
2.4 不良的测试也许比不测试更糟14
2.5 产品可能尚未准备好接受测试14
2.6 小结15
2.7 常见错误15
3 不对所有可能性进行测试的原因18
3.1 可能进行测试的数目是无限的19
3.2 测试最多只是采样20
3.3 信息的成本可能超过无知的成本21
3.4 也许我们可以用较少的测试获取更多的信息22
3.5 测试自助餐22
3.6 小结23
3.7 常见错误23
4 测试和除错的区别25
4.1 测试会随着机构的成长发生变化28
4.2 以时间限制试探法作为管理法则，但根据需要进行调整30
4.3 小结31
4.4 常见缺陷31
5 元测试33
5.1 我们有说明书，但是找不到了34
5.2 我们的错误太多了，导致缺陷数据库无法高效运转35
5.3 我们没找到任何缺陷，实际上我们并没有真正地找35
5.4 我们修改记录让缺陷看起来没那么严重36
5.5 这不是我的组件中的问题，所以我不记录36
5.6 我不知道在测试错误的应用程序37
5.7 我们不测试最差的组件，因为花的时间太长37
5.8 我们已经发现了这么多缺陷，不会再多了38
5.9 我们的测试证明程序是正确的38
5.10 我们运行了很多测试用例，根本就看不过来38
5.11 如果我们的软件在有三名用户时工作良好，显然它在有一百
名用户时也不会有问题39
5.12 我们不希望测试人员知道我们将忽略他们提供的信息39
5.13 我没有报告缺陷，所以开发人员不会对我发脾气40
5.14 我们不需要测试它，因为开发人员非常有水平40
5.15 接着说元信息41
5.16 小结41
5.17 常见错误41
6 信息免疫44
6.1 我们在生存规则受到威胁时会感到害怕45
6.2 我们压抑无法接受的事物46
6.3 我们让不可接受的事物合理化47
6.4 我们将自己的负面品质投射给其他人48
6.5 我们转移指责从而免除自己的责任49
6.6 我们对自己的不足进行过度补偿51
6.7 我们在觉得失去控制时开始强迫自己51
6.8 小结52
6.9 常见错误52
7 如何应对防卫反应54
7.1 确定恐惧55
7.2 使用危机思维55
7.3 实践，实践，再实践56
7.4 对自己进行测试57
7.5 小结58
7.6 常见错误58
8 良好测试的要素59
8.1 永远无法确切地知道59
8.2 只能根据事实来评估良好性61
8.3 你可能希望故意插入一些缺陷62
8.4 对良好性的估算总是统计性的62
8.5 可以对非差性进行估算63
8.6 小结64
8.7 常见错误64
9 有关测试的主要误区66
9.1 指责误区66
9.2 穷举测试误区67
9.3 “测试产生质量”误区68
9.4 分解误区69
9.5 合成误区70
9.6 “所有测试都相同”误区71
9.7 “随便哪个笨蛋都可以测试”误区72
9.8 小结73
9.9 常见错误73
10 测试不仅仅是敲击键盘75
10.1 毫无目的地敲击键盘是不是测试76
10.2 白手套测试77
10.3 狗食测试78
10.4 对测试人员也要进行测试80
10.5 可能在没有意识到的情况下进行测试80
10.6 演示不是测试81
10.7 小结82
10.8 常见错误82
11 信息摄取84
11.1 使用萨提亚交互模型来解析沟通84
11.1.1 摄取（Intake）85
11.1.2 确定含义（Meaning）85
11.1.3 确定重要性（Significance）86
11.1.4 做出反应（Response）86
11.2 人们听取信息时是有选择性的87
11.3 数据来源会影响到摄取87
11.4 时机也会导致差异88
11.5 人们会出现信息过载88
11.6 减少测试的数量也许可以传递更多的信息89
11.7 寻找测试之外的信息摄取90
11.8 不要混淆理解和摄取90
11.9 使用数据质疑来过滤理解91
11.10 小结91
11.11 常见错误91
12 确定含义93
12.1 案例1：四个缺陷，五种含义94
12.2 案例2：四个缺陷，七种含义95
12.3 案例3：四个缺陷，自行确定含义96
12.4 进行解释之前先弄清期望的是什么96
12.5 不知道期望时的做法98
12.6 使用已经获得的信息98
12.7 使用间接信息99
12.8 使用未获得的信息99
12.9 同样的话可能具有不同的含义100
12.10 “相同”可能并不一样101
12.11 某些时候不精确会更好101
12.12 小结102
12.13 常见错误102
13 确定重要性104
13.1 不同人会给同样的信息赋予不同的重要性105
13.2 公共的重要性也许和个人的不一样106
13.3 重要性依赖于上下文环境107
13.4 不能总是根据金钱来确定重要性108
13.5 不要采用过细的尺度110
13.6 首先解决重要问题110
13.7 听从自己的情绪反应111
13.8 小结112
13.9 常见错误113
14 做出反应115
14.1 是运气不好还是管理不善115
14.2 项目最后会赶进度的原因116
14.3 接近项目结束时应如何反应117
14.4 对测试所需时间的估算与现实差距很大的原因118
14.4.1 好天气估算119
14.4.2 不切实际的过程模型119
14.4.3 低质的过程数据119
14.4.4 没有过程数据121
14.5 确定是否已经错过了可以有所改变的时刻122
14.6 小结122
14.7 常见错误122
15 避免软件测试变得越发困难124
15.1 情况变得更糟的原因124
15.2 让系统尽可能小126
15.3 让“系统”模型是可扩展的126
15.4 增量构建有清晰接口的分立组件127
15.5 减少进入产品的缺陷数目127
15.6 小结128
15.7 常见错误128
16 不使用机器进行测试130
16.1 用机器进行测试总是不够的130
16.2 首先对最差的部分进行评审可以让人了解缺陷的严重性135
16.3 事实并不总是能令人信服的136
16.4 测试人员是颇有价值的评审者136
16.5 小结137
16.6 常见错误137
17 测试欺诈138
17.1 我们会卖给你一个神奇的工具138
17.2 我们的演示是欺诈139
17.3 这么多的证明信表明它一定很好141
17.4 我们可以通过定价来欺诈141
17.5 我们的工具会读心术142
17.6 我们保证你不用做任何事144
17.7 我们一起密谋144
17.8 避免欺诈的方法145
17.9 小结145
17.10 常见错误145
18 忘却型欺诈146
18.1 推迟文档化造成的后果146
18.2 不明确的测试报告就像流沙一样147
18.3 伪造的测试报告阻止了改进147
18.4 在别的地方进行报复148
18.5 早期的答案可能产生误导149
18.6 “量”不是“质”的同义词149
18.7 不要将非测试活动当做测试150
18.8 太整洁了，不可能是真的151
18.9 电子表格中的垃圾还是垃圾152
18.10 小结152
18.11 常见错误152
尾声153
尾注155
其他阅读材料159

內容試閱：

译者序
软件测试的目的是什么？
我想大多数人对于这个问题的回答会是“保证交付高质量的软件”。也许从最终目的上来说是这样的，但是单纯只是软件测试本身是无法为软件的质量提供足够保证的。软件的质量是从需求分析甚至是刚刚产生软件相关概念的时候就开始产生，受到整个开发过程影响的一个性质，而测试只是用来将这一性质数值化、表面化的过程。是不是拥有良好的测试过程就能够保证交付高质量的软件呢？显然是不够的。要保证软件具有较高的品质，需要管理、开发、测试等多个部门的共同努力，尤其是管理部门如何看待测试，如何利用测试获得的信息是至关重要的。
当我们按照一个预定的过程对软件进行测试，却未能获得预期结果的时候，往往会说：“这次测试失败了。”或者是“这个测试没有通过。”而实际上正确的说法应该是：“软件在这个测试中失败了。”或者是“软件没能通过这个测试。”
在许多人看来，这种说法上的差异也许是微不足道的，或者只是文字游戏。但是事实上，它反映了大家对于软件测试的心理误区。人们往往并不能很清楚地区分测试与除错、开发过程甚至是软件本身的关系。这一误区正是导致对测试产生不切实际的期望、夸大或者忽视测试作用的根源。
如果你从事测试已经有很长时间了，就很可能听到过这样一些问题：
“你为什么没有发现那个问题？”
“我们为什么要在可以自动化测试的情况下雇佣人来进行测试？”
“一定要让它在下周可用。”
而产生这些问题的原因，往往就在于人们对软件测试的误解。本书的主要目的，就是要破除这样的一些误解，还软件测试以本来面目。这本书的预期读者非常广泛，涉及与软件开发有关的所有人，包括但不限于软件开发人员、测试人员、客户、项目经理及高层管理人员，等等。
本书的作者Gerald M. Weinberg在软件行业浸淫了五十余年，几乎开发过所有类型的软件，出版了四十余本技术书籍，发表过数百篇技术文章。他对软件项目的管理、设计、开发和测试具有极其丰富的经验，对于与软件开发有关人员的心理尤其有深入的研究。他的The Psychology of Computer Programming（中译本名《程序开发心理学》）开创了“以人为本”的研究方法，它以其对程序员的智力、技巧，团队和问题求解能力等方面独特的视角和敏锐的观察经受住了时间的考验，具有深远影响。
而在《完美软件》这本书中，Weinberg采用的是纯散文和故事化的风格，没有使用花哨的指标和图表。他深入浅出地讲述了与软件测试有关的各种误解与错觉，可以让行政人员、经理或者开发人员对测试有足够的了解，以便他们理解测试所要面对的挑战，进而对测试设置恰当的期望并就这些期望进行清晰的交流。
本书回答的问题包括：
为什么在看起来测试只会耽搁时间的时候还要进行测试？
为什么无法一开始就构建正确的软件，从而不需要测试？
需要对所有可能性都进行测试吗？
为什么不对所有可能性都进行测试？
是什么原因导致测试如此困难？
为什么测试需要这么长的时间？
是否有可能构建完美的软件？
为什么我们不能接受一些缺陷？
本书的入手点更多的是出于心理学而不是计算机技术。通过对心理学的研究，我们会发现人类本身就不是完美的，自然也不应该期望软件是完美的。除了某些最简单的情况以外，软件的可能路径实际上都是无限的，因此对软件进行穷举测试通常是不可能的。由于人类容易出错，而且程序中产生缺陷的可能途径也非常多，所以没有任何缺陷的（完美的）程序是一个无法实现的目标。虽然这不是什么好消息，但是事实就是如此。
虽然软件不可能是完美的，但是受乐观主义和必要性的推动，人们每年仍然会创造数百万行代码，而这些程序中的相当一部分将会被发布到客户群中。因此，负责任的开发人员别无选择，只能通过建立测试过程来发现软件中最重要的和最有可能出现的那些缺陷。
正如Weinberg指出的那样，有些人确实选择只进行很少的测试，有时是依赖于诸如“如果我们运气好的话，就没有人会遇到那个缺陷”的想法。其他一些人只是将该缺陷重新定义成一个特性就继续别的工作。这些做法既不合乎道德，也可能导致法律问题。
Weinberg以非常诙谐而含蓄的风格介绍了他遇到过的众多例子，揭示了与软件测试有关的众多常见误解与谬论，还揭露了在测试中常见的各种欺诈方式。通过阅读本书，应该认识到软件测试是一个与人的心理活动密切相关的过程；测试工作的核心是收集信息，这些信息是关于软件产品、开发过程及测试过程本身的；要达到“保证软件质量的目的”，不仅仅要进行良好的测试，更重要的是要对测试获得的信息进行合理的利用。
本书是给涉及软件开发的所有人的一本指南，告诉他们：对于软件而言，完美是一个不现实的目标。因此，本书对软件开发团队中的所有人都是必备的。
宋锐
致谢
一本书是一个产品。从某种意义上来说，也是一个软件产品。和所有可行的软件产品一样，一本书在向公众发布之前也应该经过测试，从而让它对读者没有帮助的风险最小化。我真心实意地感谢本书的测试团队——James Bach、Michael Bolton、Fiona Charles、Elisabeth Hendrickson、Pradeep Soundararajan和Dani Weinberg。他们从本书的早期草稿中找出了数十处错误。这些错误原本就是由我制造的，所以消除或修复这些错误也是我的工作。如果书中还有错误的话，那也应该由我来承担责任，而不是由他们承担。
我同样感谢我遍及世界各地的客户和学生，因为他们提供了许多故事和例子，为我这本书的骨架增添了血肉。所有这些例子和故事都是真实可靠的，虽然大部分都进行了一定程度的掩饰以保护隐私。
如果读者发现了某些我未发现的错误，或者也有适合本书主题的故事或例子，我希望你能提醒我加以注意。我提前感谢你加入我的测试团队。
前言
五十多年以前，当我刚开始从事计算机行业的时候，计算机是极其稀少而珍贵的。当我坐在一间巨大的房间前的控制台面前时，还只是一个十几岁的少年。那个房间里塞满了硬件，大约拥有当时世界上整个计算能力的百分之十。我只要伸出手指按一下，就可以关掉这样的计算能力——有时候这确实就是我的工作。
那时，只要愿意排队，你就可以用大约两倍于我月薪的钱来租用这样的计算能力一个小时。今天，计算机已经非常便宜，实际上我已经在捐赠一些计算速度比那些早期型号快五万倍、内存也要大五万倍的计算机。捐赠的这些机器非常紧凑而轻便，我可以很轻松地把它放进公文包中。而它的计算能力却连当今世界计算能力的十亿分之一都不到。
显然，我目睹了计算机技术的长足发展，不过这一发展对我的影响是潜移默化的。我实际上并未注意到这些变化，直到几年前听到一则有关卡纳维拉尔角取消一次火箭发射的新闻报道。在播音员结束新闻报道时，其中一个人说：“太空总署（NASA）说这是一个计算机软件错误。”
另一名播音员回应道：“像计算机这么简单而常见的东西也会出这样的错，难道不奇怪吗？”
第一个人回答道：“是很奇怪，难道你认为他们不会对软件进行测试？”
不错，我认为他们会对软件进行测试。事实上，我确信他们进行了测试。不过，播音员显然认为测试必然产生完美的、没有任何缺陷的产品。
我无法停止思考这段对话及播音员不切实际的期望。一开始，我只是耸耸肩膀，对自己说：“这就是普通大众对软件测试的无知。”不过现在要忽视这一问题已经太晚了。我的警觉已经提高了。我开始发现甚至是我那些生产软件的客户公司的经理们也表现出了同样的无知。尤其是那些经理们，软件测试简直要让他们发狂了。
我是一个容易情绪化的人。当我周围的人痛苦时，我同样会感到痛苦。我理解软件经理们正在感受痛苦，他们的员工和客户同样如此。我还知道他们感到痛苦的原因，几乎所有人都不完全是因为软件测试非常复杂或者耗时耗力，而更多的是由于他们对软件测试的不合理期望和那些靠不住的测试模型。
“最后，我决定还是采取我解决无知导致的问题时最喜欢采用的方法：写下这个问题及可能的解决方案。我写下的内容最终形成了本书。”
多年前，在我写作The Psychology of Computer Programming一书时，我希望它能够帮助那些想了解编程的人[1]。有不少人告诉我这书确实为他们提供了帮助，所以，在一定程度上也许是那本书的成功促使我着手写作这本书：为了帮助那些想了解测试的人。
这本书的预期读者非常广泛：我预想这本书会拿在专业测试人员、开发人员、客户、分析师、设计师、程序员，以及他们的所有经理和同事手中。
大部分专业测试人员都知道这本书中的大部分内容，但我还是希望他们可以通过阅读本书发现一些新的途径，来和他们的经理、开发人员、同事和客户交流他们知道的那些信息。
我希望能够帮助开发人员和测试人员了解他们的经理在遇到软件测试事宜时会面对哪些情况。
我希望能够帮助客户，也就是那些买软件的人，了解更多的信息。
最后，现在每个人都会受到软件的影响，并且受到未经良好测试的软件的伤害，而我希望能够帮助所有人更加注意测试。
由于希望本书能够获得广泛的受众，所以我选择尽可能使用通俗的文字，避免那些高度技术化的术语和过于详细的分析。（对于那些有兴趣学习有关软件测试的更多技术细节的人，我在本书结尾的其他阅读材料部分指出了一些非常有用的参考书籍。）为了集中精力帮助那些希望了解软件测试的人，我根据下面这些会让大多数人感到困惑的问题来组织本书：
为什么在看起来测试只会耽搁时间时我们还要进行测试？
为什么大家不能一开始就构建正确的软件，从而不需要测试？
我们需要对所有的可能都进行测试吗？
为什么不对所有的可能都进行测试？
是什么原因导致测试如此困难？
为什么测试需要这么长的时间？
是否有可能构建完美的软件？
为什么我们就是不能接受一些缺陷？
G. M. W.
2008年4月于新墨西哥州阿尔伯克基

書城介紹　 \|　合作申請　\|　索要書目　 \|　新手入門　\|　聯絡方式　 \|　幫助中心　\|　找書說明　 \|　送貨方式　\|　付款方式	香港用户　 \|　台灣用户　\|　大陸用户　\|　海外用户

	megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.