《Effective軟體測試》是一本清華大學出版社出版的圖書,作者是[荷]毛里西奧·阿尼什(Maurício Aniche),譯者是朱少民、李潔、張元。
基本介紹
- 中文名:Effective軟體測試
- 作者:[荷]毛里西奧·阿尼什(Maurício Aniche)
- 譯者:朱少民、李潔、張元
- 出版社:清華大學出版社
- ISBN:9787302629375
內容簡介,圖書目錄,作者簡介,
內容簡介
《Effective軟體測試》將幫助你交付優質軟體。在軟體開發過程中,測試是最關鍵的部分。為編寫良好測試以及防止bug進入生產環節,你必須精通掌握基於需求規格的測試、邊界測試、結構化測試以及其他核心策略。
這本實用指南將引導開發者了解不同類型的單元測試和集成測試。開發者將學會如何使代碼便於測試,以及如何編寫易於維護的測試代碼,從而創建無缺陷的軟體。本書的講解全面、系統且透徹,富有清晰注釋的示例代碼,呈現緊貼現實的場景,並對此做了深刻的闡述。
主要內容
•設計嚴格的測試套件來查找bug。
•適時地使用單元測試、集成測試和系統測試
•前置條件、後置條件、不變式、契約測試和基於屬性的測試
•設計測試友好的系統
•測試最佳實踐和測試壞味道
•利用基於Java的示例來闡釋概念,這些概念也適用於其他面向對象的語言
圖書目錄
第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
作者簡介
Maurício Aniche博士是荷蘭代爾夫特理工大學軟體工程系的助教,併兼任Adyen公司技術部總監。