Effective軟件測試

第1章　有效和系統的軟件測試 1
1.1  測試的開發(fā)者與不測試的開發(fā)者的對比 2
1.2  開發(fā)者的有效軟件測試 14
1.2.1  開發(fā)過程中有效的測試 14
1.2.2  有效測試是一個迭代過程 16
1.2.3  專注于開發(fā)，然后專注于測試 16
1.2.4  “設計正確性”的神話 17
1.2.5  測試的成本 17
1.2.6  有效和系統的含義 17
1.2.7  測試自動化的作用 18
1.3  軟件測試的原則(或者，為什么測試如此困難) 19
1.3.1  詳盡的測試是不可能的 19
1.3.2  知道何時停止測試 19
1.3.3  可變性很重要(殺蟲劑悖論) 20
1.3.4  缺陷在某些地方更容易發(fā)生 20
1.3.5  測試永遠不可能完美或充分 20
1.3.6  上下文信息特別重要 21
1.3.7  驗證不同于確認 21
1.4  測試金字塔，以及我們應該關注的地方 22
1.4.1  單元測試 22
1.4.2  集成測試 24
1.4.3  系統測試 25
1.4.4  何時使用每個測試層次 27
1.4.5  偏愛單元測試的原因 28
1.4.6  在不同層次上測試什么 28
1.4.7  如果你不同意測試金字塔，該怎么辦 29
1.4.8  本書能幫助大家找到所有bug嗎 31
1.5  練習題 32
1.6  本章小結 34
第2章　基于需求規(guī)格的測試 35
2.1  需求告訴我們一切 36
2.1.1  步驟1：理解需求、輸入和輸出 39
2.1.2  步驟2：探索程序在各種輸入情況下的行為 39
2.1.3  步驟3：探索可能的輸入和輸出，并確定分區(qū) 41
2.1.4  步驟4：分析邊界 43
2.1.5  步驟5：設計測試用例 46
2.1.6  步驟6：測試用例的自動化 48
2.1.7  步驟7：用創(chuàng)造力和經驗增補測試集 51
2.2  基于需求規(guī)格的測試簡述 52
2.3  通過SBT發(fā)現缺陷 54
2.4  實際工作中的SBT 64
2.4.1  測試過程是迭代的，而不是順序的 64
2.4.2  SBT的測試深度 64
2.4.3  分區(qū)還是邊界？這并不重要 65
2.4.4  上點和離點就足夠了，但可以加入一些內點和外點 65
2.4.5  通過相同輸入的變化來促進理解 65
2.4.6  當組合數量激增時，務實一點 66
2.4.7  有疑問時，選擇最簡單的輸入值 66
2.4.8  為無關緊要的輸入選取合理的值 66
2.4.9  測試null值和異常情況，但只在有意義的時候 67
2.4.10  當測試用例的骨架相同時，采用參數化測試方法 67
2.4.11  適用于任何層次的需求或單元測試以外的測試 67
2.4.12  如何測試有狀態(tài)的類 68
2.4.13  經驗和創(chuàng)造力的影響 70
2.5  練習題 70
2.6  本章小結 73
第3章　結構化測試與代碼覆蓋 75
3.1  代碼覆蓋的正確使用方式 76
3.2  結構化測試概述 79
3.3  代碼覆蓋標準 81
3.3.1  行覆蓋 81
3.3.2  分支覆蓋 82
3.3.3  條件 分支覆蓋 82
3.3.4  路徑覆蓋 84
3.4  復雜條件語句和MC/DC覆蓋標準 84
3.4.1  一個抽象的例子 84
3.4.2  創(chuàng)建一個實現MC/DC的測試集 85
3.5  處理循環(huán)語句及類似結構 88
3.6  標準之間的包含關系及標準的選擇 89
3.7  基于需求規(guī)格的測試結合結構化測試：一個實例 90
3.8  邊界測試和結構化測試 96
3.9  單靠結構化測試往往不夠 97
3.10  實際工作中的結構化測試 99
3.10.1  為什么有些人痛恨代碼覆蓋率 99
3.10.2  100%的覆蓋率意味著什么 101
3.10.3  應該選擇哪種覆蓋率標準 103
3.10.4  MD/DC：非常復雜且不能簡化的表達式 103
3.10.5  其他覆蓋標準 105
3.10.6  哪些代碼不應被覆蓋 105
3.11  變異測試 106
3.12　練習題 109
3.13　本章小結 113
第4章　契約式設計 115
4.1  前置條件和后置條件 116
4.1.1  斷言關鍵字 118
4.1.2  前置條件和后置條件的強弱 119
4.2  不變式 121
4.3  契約變更與里氏替換原則 125
4.4　契約式設計和測試的關系 130
4.5　實際工作中的契約式設計 131
4.5.1　弱契約還是強契約 131
4.5.2  輸入確認與契約必須2選1嗎 131
4.5.3  斷言語句還是異常處理 134
4.5.4  拋出異常還是軟返回值 135
4.5.5  契約式設計有不適用的情況嗎 136
4.5.6  前置條件、后置條件和不變式的代碼需要測試嗎 136
4.5.7  工具支持 137
4.6  練習題 137
4.7  本章小結 139
第5章　基于屬性的測試 141
5.1  示例1：PassingGrade程序 141
5.2  示例2：測試unique方法 146
5.3  示例3：測試indexOf方法 148
5.4  示例4：測試Basket類 155
5.5  示例5：創(chuàng)建復雜的領域對象 163
5.6  實際工作中的基于屬性的測試 165
5.6.1  基于實例的測試與基于屬性的測試 165
5.6.2  基于屬性測試中的常見問題 165
5.6.3  創(chuàng)造性是關鍵 167
5.7  練習題 167
5.8  本章小結 168
第6章　測試替身和模擬對象 169
6.1  啞對象、偽對象、樁對象和模擬對象 172
6.1.1  啞對象 172
6.1.2  偽對象 172
6.1.3  樁對象 172
6.1.4  模擬對象 173
6.1.5  間諜對象 173
6.2  模擬框架的介紹 174
6.2.1  依賴項插樁 174
6.2.2  模擬對象及預期 180
6.2.3  捕獲參數 184
6.2.4  模擬異常 188
6.3  實際工作中的模擬 190
6.3.1  模擬的局限性 191
6.3.2  適合使用模擬的場景 193
6.3.3  日期和時間包裝器 197
6.3.4  模擬第三方類庫 200
6.3.5  其他人對模擬的看法 202
6.4  練習題 204
6.5　本章小結 205
第7章　可測試性設計 207
7.1  基礎設施代碼和領域代碼分離 208
7.2  依賴注入和可控制性 217
7.3  讓類和方法具有可觀察性 221
7.3.1  示例1：引入有助于斷言的方法 221
7.3.2  示例2：觀察void方法的行為 223
7.4  構造函數的依賴項，還是使用方法的參數 227
7.5  實際工作中的可測試性設計 230
7.5.1  被測試類的內聚性 231
7.5.2  被測試類的耦合 232
7.5.3  復雜條件與可測試性 233
7.5.4  私有方法的可測試性 233
7.5.5  靜態(tài)方法、單例模式與可測試性 233
7.5.6  六邊形架構與設計技術中的模擬 234
7.5.7  延伸閱讀 234
7.6  練習題 235
7.7　本章小結 237
第8章　測試驅動的開發(fā) 239
8.1  第一個TDD練習 239
8.2  針對TDD練習的思考 249
8.3  實際工作中的TDD 251
8.3.1  采用TDD還是不采用TDD 251
8.3.2  需要100%的TDD嗎 252
8.3.3  TDD適用于所有應用程序和領域嗎 252
8.3.4  學術研究對TDD的觀點 253
8.3.5  TDD的其他學派 254
8.3.6  TDD和徹底的測試 256
8.4  練習題 256
8.5  本章小結 258
第9章　編寫大型測試 259
9.1  什么時候使用大型測試 259
9.1.1  測試大型組件 260
9.1.2  測試超出代碼庫的大型組件 269
9.2  數據庫與SQL測試 275
9.2.1  SQL查詢中測試的內容 275
9.2.2  為SQL查詢寫自動化測試 277
9.2.3  為SQL測試設置基礎設施 284
9.2.4  最佳實踐 286
9.3  系統測試 287
9.3.1  Selenium簡介 288
9.3.2  設計頁面對象 291
9.3.3  模式與最佳實踐 301
9.4  關于大型測試的最后說明 305
9.4.1  如何讓所有的測試技術匹配 305
9.4.2  執(zhí)行成本效益分析 306
9.4.3  當心那些已覆蓋但未測試的方法 306
9.4.4  適當的編碼基礎設施是關鍵 307
9.4.5  干系人編寫測試的DSL和工具 307
9.4.6  測試其他類型的Web系統 307
9.5  練習題 308
9.6  本章小結 309
第10章  測試代碼的質量 311
10.1  可維護的測試代碼的原則 312
10.1.1  測試要快 312
10.1.2  測試應該是內聚的、獨立的和隔離的 312
10.1.3  測試要有存在的理由 313
10.1.4  測試應該是可復用且穩(wěn)定的 313
10.1.5  測試應該有強斷言 314
10.1.6  行為改變時測試要中斷 315
10.1.7  測試失敗應該有單一且明確的原因 315
10.1.8  測試應該易于編寫 316
10.1.9  測試應該易于閱讀 316
10.1.10  測試應該易于修改和演化 321
10.2  測試壞味道 321
10.2.1  過度重復 322
10.2.2  不明確的斷言 322
10.2.3  對復雜或外部資源的處理不當 323
10.2.4  過于通用的測試夾具 324
10.2.5  敏感斷言 325
10.3　練習題 327
10.4  本章小結 330
第11章  全書總結 333
11.1  盡管模型看起來是線性的，但迭代是基礎 333
11.2  沒有缺陷的軟件開發(fā)：現實還是神話 334
11.3  讓最終用戶參與進來 335
11.4  盡量多使用單元測試 335
11.5  在監(jiān)控上投入精力 336
11.6  未來的方向 337
附錄  習題答案 339