溫伯格編寫的《顛覆完美軟件(軟件測試必須知
道的幾件事溫伯格技術思想三部曲)》是從事軟件行
業五十餘年的Gerald M. Weinberg針對軟件測試所
寫的新作。他在軟件項目的管理、設計、開發和測試
方面都具有極其豐富的經驗，對於與軟件開發有關人
員的心理尤其有深入的研究。在本書中，他重點討論
了與軟件測試有關的各種心理問題及其表現與應對方
法。作者首先闡述軟件測試之所以如此困難的原因—
—人的思維不是完美的，而軟件測試的最終目的就是
發現對改善軟件產品和軟件開發過程有益的信息，故
軟件測試是一個信息獲取的過程。接著，作者利用豐
富的經歷和大量的實例，展現了在軟件測試中可能會
出現的各種與人的心理有關的現像、誤區、欺詐，以
及容易犯下的常見錯誤等等。本書的重點不是告訴大
家要做什麼或者如何做，而更多的是讓讀者明白在與
軟件測試相關的活動中會出現某些特定現像的原因。
理解這些與人的心理有關的現像有助於與軟件開發有
關的所有人之間更好地就軟件測試的目的和實現過程
進行溝通，從而實現具有更高品質的軟件。

1 進行測試的原因
1.1 人類不是**的思考者
1.2 我們要做出有關軟件的決定
1.2.1 日記條目
1.2.2 日記條目
1.2.3 日記條目
1.2.4 日記條目
1.2.5 日記條目
1.2.6 日記條目
1.3 決定可能是有風險的
1.4 測試可以提供降低風險的信息
1.5 小結
1.6 常見錯誤
2 測試無法做的事
2.1 信息未必有助於降低風險
2.2 也許我們不會使用那些花錢得到的信息
2.3 決定是感性的而不是理性的
2.4 不良的測試也許比不測試*糟
2.5 產品可能尚未準備好接受測試
2.6 小結
2.7 常見錯誤
3 不對所有可能性進行測試的原因
3.1 可能進行測試的數目是無限的
3.2 測試*多隻是采樣
3.3 信息的成本可能超過無知的成本
3.4 也許我們可以用較少的測試獲取*多的信息
3.5 測試自助餐
3.6 小結
3.7 常見錯誤
4 測試和除錯的區別
4.1 測試會隨著機構的成長發生變化
4.2 以時間限制試探法作為管理法則，但根據需要進行調整
4.3 小結
4.4 常見缺陷
5 元測試
5.1 我們有說明書，但是找不到了
5.2 我們的錯誤太多了，導致缺陷數據庫無法高效運轉
5.3 我們沒找到任何缺陷，實際上我們並沒有真正地找
5.4 我們修改記錄讓缺陷看起來沒那麼嚴重
5.5 這不是我的組件中的問題，所以我不記錄
5.6 我不知道在測試錯誤的應用程序
5.7 我們不測試*差的組件，因為花的時間太長
5.8 我們已經發現了這麼多缺陷，不會再多了
5.9 我們的測試證明程序是正確的
5.10 我們運行了很多測**例，根本就看不過來
5.11 如果我們的軟件在有三名用戶時工作良好，顯然它在有一百名用戶時也不會有問題
5.12 我們不希望測試人員知道我們將忽略他們提供的信息
5.13 我沒有報告缺陷，所以開發人員不會對我發脾氣
5.14 我們不需要測試它，因為開發人員**有 水平
5.15 接著說元信息
5.16 小結
5.17 常見錯誤
6 信息免疫
6.1 我們在生存規則受到威脅時會感到害怕
6.2 我們壓抑無法接受的事物
6.3 我們讓不可接受的事物合理化
6.4 我們將自己的負面品質投射給其他人
6.5 我們轉移指責從而免除自己的責任
6.6 我們對自己的不足進行過度補償
6.7 我們在覺得失去控制時開始強迫自己
6.8 小結
6.9 常見錯誤
7 如何應對防衛反應
7.1 確定恐懼
7.2 使用危機思維
7.3 實踐，實踐，再實踐
7.4 對自己進行測試
7.5 小結
7.6 常見錯誤
8 良好測試的要素
8.1 永遠無法確切地知道
8.2 隻能根據事實來評估良好性
8.3 你可能希望故意插入一些缺陷
8.4 對良好性的估算總是統計性的
8.5 可以對非差性進行估算
8.6 小結
8.7 常見錯誤
9 有關測試的主要誤區
9.1 指責誤區
9.2 窮舉測試誤區
9.3 “測試產生質量”誤區
9.4 分解誤區
9.5 合成誤區
9.6 “所有測試都相同”誤區
9.7 “隨便哪個笨蛋都可以測試”誤區
9.8 小結
9.9 常見錯誤
10 測試不僅僅是敲擊鍵盤
10.1 毫無目的地敲擊鍵盤是不是測試
10.2 白手套測試
10.3 狗食測試
10.4 對測試人員也要進行測試
10.5 可能在沒有意識到的情況下進行測試
10.6 演示不是測試
10.7 小結
10.8 常見錯誤
11 信息攝取
11.1 使用薩提亞交互模型來解析溝通
11.1.1 攝取（Intake）
11.1.2 確定含義（Meaning）
11.1.3 確定重要性（Significance）
11.1.4 做出反應（Response）
11.2 人們聽取信息時是有選擇性的
11.3 數據來源會影響到攝取
11.4 時機也會導致差異
11.5 人們會出現信息過載
11.6 減少測試的數量也許可以傳遞*多的信息
11.7 尋找測試之外的信息攝取
11.8 不要混淆理解和攝取
11.9 使用數據質疑來過濾理解
11.10 小結
11.11 常見錯誤
12 確定含義
12.1 案例1：四個缺陷，五種含義
12.2 案例2：四個缺陷，七種含義
12.3 案例3：四個缺陷，自行確定含義
12.4 進行解釋之前先弄清期望的是什麼
12.5 不知道期望時的做法
12.6 使用已經獲得的信息
12.7 使用間接信息
12.8 使用未獲得的信息
12.9 同樣的話可能具有不同的含義
12.10 “相同”可能並不一樣
12.11 某些時候不**會*好
12.12 小結
12.13 常見錯誤
13 確定重要性
13.1 不同人會給同樣的信息賦予不同的重要性
13.2 公共的重要性也許和個人的不一樣
13.3 重要性依賴於上下文環境
13.4 不能總是根據金錢來確定重要性
13.5 不要采用過細的尺度
13.6 首先解決重要問題
13.7 聽從自己的情緒反應
13.8 小結
13.9 常見錯誤
14 做出反應
14.1 是運氣不好還是管理不善
14.2 項目*後會趕進度的原因
14.3 接近項目結束時應如何反應
14.4 對測試所需時間的估算與現實差距很大的 原因
14.4.1 好天氣估算
14.4.2 不切實際的過程模型
14.4.3 低質的過程數據
14.4.4 沒有過程數據
14.5 確定是否已經錯過了可以有所改變的時刻
14.6 小結
14.7 常見錯誤
15 避免軟件測試變得越發困難
15.1 情況變得*糟的原因
15.2 讓繫統盡可能小
15.3 讓“繫統”模型是可擴展的
15.4 增量構建有清晰接口的分立組件
15.5 減少進入產品的缺陷數目
15.6 小結
15.7 常見錯誤
16 不使用機器進行測試
16.1 用機器進行測試總是不夠的
16.2 首先對*差的部分進行評審可以讓人了解缺陷的嚴重性
16.3 事實並不總是能令人信服的
16.4 測試人員是頗有價值的評審者
16.5 小結
16.6 常見錯誤
17 測試欺詐
17.1 我們會賣給你一個神奇的工具
17.2 我們的演示是欺詐
17.3 這麼多的證明信表明它一定很好
17.4 我們可以通過定價來欺詐
17.5 我們的工具會讀心術
17.6 我們保證你不用做任何事
17.7 我們一起密謀
17.8 避免欺詐的方法
17.9 小結
17.10 常見錯誤
18 忘卻型欺詐
18.1 推遲文檔化造成的後果
18.2 不明確的測試報告就像流沙一樣
18.3 偽造的測試報告阻止了改進
18.4 在別的地方進行報復
18.5 早期的答案可能產生誤導
18.6 “量”不是“質”的同義詞
18.7 不要將非測試活動當做測試
18.8 太整潔了，不可能是真的
18.9 電子表格中的垃圾還是垃圾
18.10 小結
18.11 常見錯誤
尾聲
尾注
其他閱讀材料