Effective 軟件測試 Effective Software Testing: A Developer's Guide

目    錄

 

 

 

第1章　有效和系統的軟件測試 1

1.1  測試的開發者與不測試的開發者的對比 2

1.2  開發者的有效軟件測試 14

1.2.1  開發過程中有效的測試 14

1.2.2  有效測試是一個迭代過程 16

1.2.3  專註於開發，然後專註於測試 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  缺陷在某些地方更容易發生 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章　基於需求規格的測試 35

2.1  需求告訴我們一切 36

2.1.1  步驟1：理解需求、輸入和輸出 39

2.1.2  步驟2：探索程序在各種輸入情況下的行為 39

2.1.3  步驟3：探索可能的輸入和輸出，並確定分區 41

2.1.4  步驟4：分析邊界 43

2.1.5  步驟5：設計測試用例 46

2.1.6  步驟6：測試用例的自動化 48

2.1.7  步驟7：用創造力和經驗增補測試集 51

2.2  基於需求規格的測試簡述 52

2.3  通過SBT發現缺陷 54

2.4  實際工作中的SBT 64

2.4.1  測試過程是迭代的，而不是順序的 64

2.4.2  SBT的測試深度 64

2.4.3  分區還是邊界？這並不重要 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  如何測試有狀態的類 68

2.4.13  經驗和創造力的影響 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  創建一個實現MC/DC的測試集 85

3.5  處理循環語句及類似結構 88

3.6  標準之間的包含關系及標準的選擇 89

3.7  基於需求規格的測試結合結構化測試：一個實例 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：創建復雜的領域對象 163

5.6  實際工作中的基於屬性的測試 165

5.6.1  基於實例的測試與基於屬性的測試 165

5.6.2  基於屬性測試中的常見問題 165

5.6.3  創造性是關鍵 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  靜態方法、單例模式與可測試性 233

7.5.6  六邊形架構與設計技術中的模擬 234

7.5.7  延伸閱讀 234

7.6  練習題 235

7.7　本章小結 237

第8章　測試驅動的開發 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  執行成本效益分析 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  測試應該是可復用且穩定的 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  沒有缺陷的軟件開發：現實還是神話 334

11.3  讓最終用戶參與進來 335

11.4  盡量多使用單元測試 335

11.5  在監控上投入精力 336

11.6  未來的方向 337

附錄  習題答案 339