顛覆完美軟件：軟件測試必須知道的幾件事

1      進行測試的原因 1
1.1  人類不是完美的思考者 2
1.2  我們要做出有關軟件的決定 2
1.2.1  日記條目1 2
1.2.2  日記條目2 3
1.2.3  日記條目3 3
1.2.4  日記條目4 3
1.2.5  日記條目5 4
1.2.6  日記條目6 4
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  可能進行測試的數(shù)目是無限的 19
3.2  測試最多只是采樣 20
3.3  信息的成本可能超過無知的成本 21
3.4  也許我們可以用較少的測試獲取更多的信息 22
3.5  測試自助餐 22
3.6  小結 23
3.7  常見錯誤 23
4      測試和除錯的區(qū)別 25
4.1  測試會隨著機構的成長發(fā)生變化 28
4.2  以時間限制試探法作為管理法則，但根據(jù)需要進行調整 30
4.3  小結 31
4.4  常見缺陷 31
5      元測試 33
5.1  我們有說明書，但是找不到了 34
5.2  我們的錯誤太多了，導致缺陷數(shù)據(jù)庫無法高效運轉 35
5.3  我們沒找到任何缺陷，實際上我們并沒有真正地找 35
5.4  我們修改記錄讓缺陷看起來沒那么嚴重 36
5.5  這不是我的組件中的問題，所以我不記錄 36
5.6  我不知道在測試錯誤的應用程序 37
5.7  我們不測試最差的組件，因為花的時間太長 37
5.8  我們已經發(fā)現(xiàn)了這么多缺陷，不會再多了 38
5.9  我們的測試證明程序是正確的 38
5.10  我們運行了很多測試用例，根本就看不過來 38
5.11  如果我們的軟件在有三名用戶時工作良好，顯然它在有一百
名用戶時也不會有問題 39
5.12  我們不希望測試人員知道我們將忽略他們提供的信息 39
5.13  我沒有報告缺陷，所以開發(fā)人員不會對我發(fā)脾氣 40
5.14  我們不需要測試它，因為開發(fā)人員非常有  水平 40
5.15  接著說元信息 41
5.16  小結 41
5.17  常見錯誤 41
6      信息免疫 44
6.1  我們在生存規(guī)則受到威脅時會感到害怕 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      如何應對防衛(wèi)反應 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  只能根據(jù)事實來評估良好性 61
8.3  你可能希望故意插入一些缺陷 62
8.4  對良好性的估算總是統(tǒng)計性的 62
8.5  可以對非差性進行估算 63
8.6  小結 64
8.7  常見錯誤 64
9      有關測試的主要誤區(qū) 66
9.1  指責誤區(qū) 66
9.2  窮舉測試誤區(qū) 67
9.3 “測試產生質量”誤區(qū) 68
9.4  分解誤區(qū) 69
9.5  合成誤區(qū) 70
9.6 “所有測試都相同”誤區(qū) 71
9.7 “隨便哪個笨蛋都可以測試”誤區(qū) 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  攝?。↖ntake） 85
11.1.2  確定含義（Meaning） 85
11.1.3  確定重要性（Significance） 86
11.1.4  做出反應（Response） 86
11.2  人們聽取信息時是有選擇性的 87
11.3  數(shù)據(jù)來源會影響到攝取 87
11.4  時機也會導致差異 88
11.5  人們會出現(xiàn)信息過載 88
11.6  減少測試的數(shù)量也許可以傳遞更多的信息 89
11.7  尋找測試之外的信息攝取 90
11.8  不要混淆理解和攝取 90
11.9  使用數(shù)據(jù)質疑來過濾理解 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  重要性依賴于上下文環(huán)境 107
13.4  不能總是根據(jù)金錢來確定重要性 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  對測試所需時間的估算與現(xiàn)實差距很大的 原因 118
14.4.1  好天氣估算 119
14.4.2  不切實際的過程模型 119
14.4.3  低質的過程數(shù)據(jù) 119
14.4.4  沒有過程數(shù)據(jù) 121
14.5  確定是否已經錯過了可以有所改變的時刻 122
14.6  小結 122
14.7  常見錯誤 122
15      避免軟件測試變得越發(fā)困難 124
15.1  情況變得更糟的原因 124
15.2  讓系統(tǒng)盡可能小 126
15.3  讓“系統(tǒng)”模型是可擴展的 126
15.4  增量構建有清晰接口的分立組件 127
15.5  減少進入產品的缺陷數(shù)目 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