宣傳語
“程式設計心理學”一書作者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
