Effective軟件測試

來自 孔夫子網 的圖片

《Effective軟件測試》，[荷] 毛里西奧·阿尼什 著，[荷] 毛里西奧·阿尼什 編，出版社： 清華大學出版社。

清華大學出版社成立於1980年6月，是教育部主管、清華大學主辦的綜合性大學出版社。清華社現年出版圖書、音像製品、電子出版物等近3000種，銷售規模和綜合實力以及在高等教育教材市場、科技圖書市場、館配圖書市場占有率均名列前茅。

目錄

內容簡介

近年來出現了一 些新的出版方式，MEAP(Manning Early Access Program)就是其中的一種，把開源運動擴展到出版行業。在MEAP中，讀者可在圖書出版前逐章閱讀早期版本。在作者寫作過程中，讀者可以及時提供反饋，幫助作者寫出更好的作品。 本書正是基於MEAP誕生的一本軟件測試圖書，其質量已得到多位讀者的檢驗。本書作者Mauricio Aniche試圖幫助開發人員避免常犯的錯誤。Mauricio博士是開發人員出身，曾親赴現場交付和部署軟件;在客戶提出問題後，及時對軟件進行了調試、分析和修正。教訓是深刻的，他對測試非常重視，親力親為，深信「要成為一名高效的開發者，必先成為一名高效的軟件測試者」，並強烈推薦在開發系統時構建一個 自動化測試集，隨時反饋測試結果，從而顯著提高軟件工程師的工作效率。

目錄

第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