《信息科學與技術叢書：設計驅動測試》是2014年機械工業出版社出版的圖書，作者是Matt Stephens、Doug Rosenberg。
基本介紹
- 書名：信息科學與技術叢書：設計驅動測試
- 作者：（美國）Matt Stephens （美國）Doug Rosenberg
- 譯者：鄭靜 等
- 出版社：機械工業出版社
- 出版時間：2014年
內容簡介,圖書目錄,序言,
內容簡介
《信息科學與技術叢書:設計驅動測試》主要介紹了設計驅動測試（DDT）的思想和一種全新的軟體開發過程—ICONIX。作者希望通過一個個真實而具體的案例告訴讀者，如何在實踐中達到測試的最佳平衡和最佳化。全書共分12章，第1～3章介紹了全新的DDT和傳統的TDD之間的差異。第4～8章通過一個真實的Web地圖案例，講解了如何在項目實踐中運用DDT的思想。第9～12章主要描述了如何在自動化測試、算法測試、單元測試等環節中使用DDT。
《設計驅動測試》作者斯蒂文斯、羅森伯格有多年大型軟體開發經驗，他們從自身工作中總結經驗教訓，參考流行的敏捷開發模式，提煉出一套全新的理念——設計驅動測試，並介紹了如何在項目中具體實施。希望這本書能有助於開拓軟體開發者的思路，並幫助讀者找到真正適合自己的軟體開發模式。
圖書目錄
出版說明
譯者序
序
關於作者
關於技術評審人
致謝
開場白
第一部分 DDT vs. TDD
第1章 有人弄反了
DDT要解決的問題
很難知道什麼時候完成
將測試放在後期代價更大
測試設計糟糕的代碼很困難
用戶級測試很容易被遺忘
開發人員變得自負
測試有時缺少目標
對DDT的與工具無關的快速概覽
DDT的結構
DDT實戰
TDD與DDT的不同之處
示例項目：Mapplet 2.0介紹
小結
第2章 使用TDD的Hello World
TDD的十大特性
10．測試驅動設計
9．完全沒有文檔
8．所有東西都是單元測試
7．TDD測試不是完全的單元測試
6．驗收測試提供針對需求的反饋
5．TDD導致盲目自信的變更
4．設計在不斷增長
3．有一些預先設計就可以了
2．TDD產生了大量測試
1．TDD實在太難了
使用TDD實現登錄用例
理解需求
考慮設計
編寫第一個測試先行的測試
編寫登錄檢查代碼從而使測試通過
創建模擬對象
從重構代碼看設計的浮現
TDD中的驗收測試
結論：TDD實在太難了
小結
第3章 使用DDT的Hello World
ICONIX/DDT的十大特性
10．DDT包含業務需求測試
9．DDT包含場景測試
8．測試是被設計驅動的
7．DDT包含控制器測試
6．DDT測試更靈活，更簡單
5．DDT中的單元測試是“經典”的單元測試
4．DDT中的測試用例可以轉換成測試代碼
3．DDT測試用例指導測試計畫
2．DDT測試對開發和測試團隊都很有用
1．DDT可以消除重複工作
使用DDT實現登錄
步驟1：創建健壯性圖
步驟2：創建控制器測試
步驟3：添加場景
步驟4：將控制器測試用例轉換成為類
步驟5：生成控制器測試代碼
步驟6：繪製序列圖
步驟7：創建單元測試用例
步驟8：填充測試代碼
小結
第二部分 真實世界中的DDT：Mapplet 2.0旅遊網站
第4章 Mapplet項目簡介
ICONIX 流程/DDT十大“To-Do”列表
10．創建架構
9．對需求達成共識並進行測試
8．從問題域驅動設計
7．使用UI故事板編寫用例
6．編寫場景測試驗證用例
5．測試概要設計和詳細設計
4．經常更新模型
3．保持測試腳本與需求同步
2．更新自動化測試
1．比較待發布版本和原始用例
小結
第5章 詳細設計和單元測試
單元測試十大“To-Do”列表
10．從序列圖開始
9．在設計中標識測試用例
8．為每個測試用例編寫場景
7．聰明測試：避免重疊測試
6．把測試用例轉換為UML類
5．編寫單元測試和相關的代碼
4．編寫白盒單元測試
3．使用模擬對象框架
2．用單元測試測試算法邏輯
1．編寫集成測試的獨立套件
小結
第6章 概要設計和控制器測試
控制器測試十大“To-Do”列表
10．從健壯性圖開始
9．為控制器標識測試用例
8．為每個測試用例定義一個或者多個場景
7．填寫描述、輸入和驗收標準
6．生成測試類
5．實現測試代碼
4．編寫容易測試的代碼
3．編寫“灰盒”控制器測試
2．串聯控制器測試
1．編寫集成測試的獨立套件
小結
第7章 驗收測試：擴展用例場景
場景測試的十大“To-Do”列表Mapplet用例
10．從一個敘述性用例開始
9．把這個用例轉換成一個結構化的場景
8．確保涵蓋所有的可選方案和意外場景
7．增加前置條件和後置條件，將每個場景分支連線起來
6．生成活動圖來檢查結構化場景
5．創建外部測試集來細化場景
4．把測試用例放進用例圖
3．進入EA測試視圖
2．根據需要細化場景
1．為測試團隊生成測試計畫文檔
這個過程的精髓是……
小結
第8章 驗收測試：業務需求
十大需求測試“To-Do”列表
10．從一個域模型開始
9．編寫業務需求測試
8．對需求進行建模和整理
7．從需求創建測試用例
6．與用戶一起審查你的計畫
5．編寫手工測試腳本
4．編寫自動化需求測試
3．導出需求測試用例
2．使測試用例可見
1．讓你的團隊參與其中！
小結
第三部分 高級DDT
第9章 單元測試的反模式（反面案例）
末日聖殿（特指某一種代碼）
大背景
HotelPriceCalculator類
支持類
服務類
反模式
10．複雜的構造函式
9．濫用類繼承
8．靜態微觸發器
7．靜態方法和變數
6．單例設計模式
5．緊耦合
4．UI代碼里實現業務邏輯
3．濫用私有屬性
2．聲明為final的服務對象
1．熱心的程式設計師開發的不成熟的功能
小結
第10章 為易於測試而設計
十大為測試而設計的“To-Do”列表
末日聖殿——徹底修正
用例——確定我們需要做什麼
識別控制器測試
計算總價格測試
獲取最新價格測試
為易於測試而設計
10．將初始化代碼放在構造函式之外
9．慎用繼承
8．避免使用靜態初始化塊
7．使用對象級別的方法和變數
6．避免使用單例設計模式
5．保持類解耦合
4．將業務邏輯放在UI代碼之外
3．使用“黑盒”和“灰盒”測試
2．為常量預留“final”修飾符——通常需要避免修飾複雜類型（如Service Objects）為final
1．堅持使用用戶用例和設計
Quote Hotel Price用例的詳細設計
控制器測試：計算總價
控制器測試：獲得最新價格的測試
重構設計和代碼
小結
第11章 自動化的集成測試
十大集成測試“To-Do”列表
10．在概要設計里尋找測試模式
9．不要忘記安全性測試
安全性測試：SQL注入攻擊
安全性測試：建立安全會話
8．決定編寫哪個“等級”的集成測試
三個等級的不同點
了解編寫哪個等級的集成測試
7．概要設計驅動單元/控制器級別的集成測試
6．從用例場景驅動場景測試
5．編寫端到端場景測試
模擬一個場景中的步驟
共享測試資料庫
Mapplet例子：“高級搜尋”用例
Vanilla xUnit場景測試
4．使用“業務友好”型測試框架
3．將測試GUI代碼作為場景測試的一部分
2．不要低估集成測試的難度
網路延遲
資料庫元數據變化
隨機變化的（又名“敏捷”）接口
遠程系統中的bugs
陰雨天
1．不要低估集成測試的價值
編寫集成測試的關鍵點
小結
第12章 單元測試算法
十大算法測試“To-Do”列表
10．從概要設計的控制器開始工作
9．將控制器擴展成算法設計
8．把圖和域模型對應起來
7．分割那些看上去不止做一個檢查的判斷結點
6．為每個結點（活動和判斷結點）建立一個測試用例
5．為每個測試用例定義測試場景，一組輸入和期望結果
4．按照算法，從不同的源中創建輸入數據
3．把邏輯流程對應到獨立的方法和類上
2．編寫“白盒”單元測試
1．在其他類型的設計圖上使用DDT技術
小結
附錄 愛麗絲漫遊用例國
介紹
第1部分
愛麗絲在看書的時候睡著了
用例驅動開發的承諾
一種把用例文本和對象連線起來的分析模型
簡潔且直接
《包含》還是《擴展》
我們遲到了！我們必須開始編碼了！
愛麗絲想知道如何才能把用例變成代碼
抽象的……基本的
有點太過抽象了？
目的中心化……
我們真的打算為每個用例都指定這些東西嗎？
第2部分
愛麗絲口渴了
愛麗絲感到頭暈
構想……（敬請約翰·列儂原諒，這首歌改編自他的作品）
結對編程意味著再也不用把需求寫下來了
沒時間去寫需求了
你也許也會說“代碼就是設計”
誰在乎用例？
C3項目被中止了
一次且只有一次？
沒有寫下需求之前，愛麗絲拒絕開始寫代碼
你因為預先設計而被定罪……
CMM已經死了，砍掉她的腦袋！
一些嚴肅的設計重構
第3部分
愛麗絲醒了
縮小“什麼”和“如何”之間的距離
靜態模型和動態模型被連線在了一起
行為被定位到序列圖里
這裡面的教訓在於……
尾聲——亂七八糟的測試……
索引
譯者序
序
關於作者
關於技術評審人
致謝
開場白
第一部分 DDT vs. TDD
第1章 有人弄反了
DDT要解決的問題
很難知道什麼時候完成
將測試放在後期代價更大
測試設計糟糕的代碼很困難
用戶級測試很容易被遺忘
開發人員變得自負
測試有時缺少目標
對DDT的與工具無關的快速概覽
DDT的結構
DDT實戰
TDD與DDT的不同之處
示例項目：Mapplet 2.0介紹
小結
第2章 使用TDD的Hello World
TDD的十大特性
10．測試驅動設計
9．完全沒有文檔
8．所有東西都是單元測試
7．TDD測試不是完全的單元測試
6．驗收測試提供針對需求的反饋
5．TDD導致盲目自信的變更
4．設計在不斷增長
3．有一些預先設計就可以了
2．TDD產生了大量測試
1．TDD實在太難了
使用TDD實現登錄用例
理解需求
考慮設計
編寫第一個測試先行的測試
編寫登錄檢查代碼從而使測試通過
創建模擬對象
從重構代碼看設計的浮現
TDD中的驗收測試
結論：TDD實在太難了
小結
第3章 使用DDT的Hello World
ICONIX/DDT的十大特性
10．DDT包含業務需求測試
9．DDT包含場景測試
8．測試是被設計驅動的
7．DDT包含控制器測試
6．DDT測試更靈活，更簡單
5．DDT中的單元測試是“經典”的單元測試
4．DDT中的測試用例可以轉換成測試代碼
3．DDT測試用例指導測試計畫
2．DDT測試對開發和測試團隊都很有用
1．DDT可以消除重複工作
使用DDT實現登錄
步驟1：創建健壯性圖
步驟2：創建控制器測試
步驟3：添加場景
步驟4：將控制器測試用例轉換成為類
步驟5：生成控制器測試代碼
步驟6：繪製序列圖
步驟7：創建單元測試用例
步驟8：填充測試代碼
小結
第二部分 真實世界中的DDT：Mapplet 2.0旅遊網站
第4章 Mapplet項目簡介
ICONIX 流程/DDT十大“To-Do”列表
10．創建架構
9．對需求達成共識並進行測試
8．從問題域驅動設計
7．使用UI故事板編寫用例
6．編寫場景測試驗證用例
5．測試概要設計和詳細設計
4．經常更新模型
3．保持測試腳本與需求同步
2．更新自動化測試
1．比較待發布版本和原始用例
小結
第5章 詳細設計和單元測試
單元測試十大“To-Do”列表
10．從序列圖開始
9．在設計中標識測試用例
8．為每個測試用例編寫場景
7．聰明測試：避免重疊測試
6．把測試用例轉換為UML類
5．編寫單元測試和相關的代碼
4．編寫白盒單元測試
3．使用模擬對象框架
2．用單元測試測試算法邏輯
1．編寫集成測試的獨立套件
小結
第6章 概要設計和控制器測試
控制器測試十大“To-Do”列表
10．從健壯性圖開始
9．為控制器標識測試用例
8．為每個測試用例定義一個或者多個場景
7．填寫描述、輸入和驗收標準
6．生成測試類
5．實現測試代碼
4．編寫容易測試的代碼
3．編寫“灰盒”控制器測試
2．串聯控制器測試
1．編寫集成測試的獨立套件
小結
第7章 驗收測試：擴展用例場景
場景測試的十大“To-Do”列表Mapplet用例
10．從一個敘述性用例開始
9．把這個用例轉換成一個結構化的場景
8．確保涵蓋所有的可選方案和意外場景
7．增加前置條件和後置條件，將每個場景分支連線起來
6．生成活動圖來檢查結構化場景
5．創建外部測試集來細化場景
4．把測試用例放進用例圖
3．進入EA測試視圖
2．根據需要細化場景
1．為測試團隊生成測試計畫文檔
這個過程的精髓是……
小結
第8章 驗收測試：業務需求
十大需求測試“To-Do”列表
10．從一個域模型開始
9．編寫業務需求測試
8．對需求進行建模和整理
7．從需求創建測試用例
6．與用戶一起審查你的計畫
5．編寫手工測試腳本
4．編寫自動化需求測試
3．導出需求測試用例
2．使測試用例可見
1．讓你的團隊參與其中！
小結
第三部分 高級DDT
第9章 單元測試的反模式（反面案例）
末日聖殿（特指某一種代碼）
大背景
HotelPriceCalculator類
支持類
服務類
反模式
10．複雜的構造函式
9．濫用類繼承
8．靜態微觸發器
7．靜態方法和變數
6．單例設計模式
5．緊耦合
4．UI代碼里實現業務邏輯
3．濫用私有屬性
2．聲明為final的服務對象
1．熱心的程式設計師開發的不成熟的功能
小結
第10章 為易於測試而設計
十大為測試而設計的“To-Do”列表
末日聖殿——徹底修正
用例——確定我們需要做什麼
識別控制器測試
計算總價格測試
獲取最新價格測試
為易於測試而設計
10．將初始化代碼放在構造函式之外
9．慎用繼承
8．避免使用靜態初始化塊
7．使用對象級別的方法和變數
6．避免使用單例設計模式
5．保持類解耦合
4．將業務邏輯放在UI代碼之外
3．使用“黑盒”和“灰盒”測試
2．為常量預留“final”修飾符——通常需要避免修飾複雜類型（如Service Objects）為final
1．堅持使用用戶用例和設計
Quote Hotel Price用例的詳細設計
控制器測試：計算總價
控制器測試：獲得最新價格的測試
重構設計和代碼
小結
第11章 自動化的集成測試
十大集成測試“To-Do”列表
10．在概要設計里尋找測試模式
9．不要忘記安全性測試
安全性測試：SQL注入攻擊
安全性測試：建立安全會話
8．決定編寫哪個“等級”的集成測試
三個等級的不同點
了解編寫哪個等級的集成測試
7．概要設計驅動單元/控制器級別的集成測試
6．從用例場景驅動場景測試
5．編寫端到端場景測試
模擬一個場景中的步驟
共享測試資料庫
Mapplet例子：“高級搜尋”用例
Vanilla xUnit場景測試
4．使用“業務友好”型測試框架
3．將測試GUI代碼作為場景測試的一部分
2．不要低估集成測試的難度
網路延遲
資料庫元數據變化
隨機變化的（又名“敏捷”）接口
遠程系統中的bugs
陰雨天
1．不要低估集成測試的價值
編寫集成測試的關鍵點
小結
第12章 單元測試算法
十大算法測試“To-Do”列表
10．從概要設計的控制器開始工作
9．將控制器擴展成算法設計
8．把圖和域模型對應起來
7．分割那些看上去不止做一個檢查的判斷結點
6．為每個結點（活動和判斷結點）建立一個測試用例
5．為每個測試用例定義測試場景，一組輸入和期望結果
4．按照算法，從不同的源中創建輸入數據
3．把邏輯流程對應到獨立的方法和類上
2．編寫“白盒”單元測試
1．在其他類型的設計圖上使用DDT技術
小結
附錄 愛麗絲漫遊用例國
介紹
第1部分
愛麗絲在看書的時候睡著了
用例驅動開發的承諾
一種把用例文本和對象連線起來的分析模型
簡潔且直接
《包含》還是《擴展》
我們遲到了！我們必須開始編碼了！
愛麗絲想知道如何才能把用例變成代碼
抽象的……基本的
有點太過抽象了？
目的中心化……
我們真的打算為每個用例都指定這些東西嗎？
第2部分
愛麗絲口渴了
愛麗絲感到頭暈
構想……（敬請約翰·列儂原諒，這首歌改編自他的作品）
結對編程意味著再也不用把需求寫下來了
沒時間去寫需求了
你也許也會說“代碼就是設計”
誰在乎用例？
C3項目被中止了
一次且只有一次？
沒有寫下需求之前，愛麗絲拒絕開始寫代碼
你因為預先設計而被定罪……
CMM已經死了，砍掉她的腦袋！
一些嚴肅的設計重構
第3部分
愛麗絲醒了
縮小“什麼”和“如何”之間的距離
靜態模型和動態模型被連線在了一起
行為被定位到序列圖里
這裡面的教訓在於……
尾聲——亂七八糟的測試……
索引
序言
隨著信息科學與技術的迅速發展，人類每時每刻都會面對層出不窮的新技術和新概念。毫無疑問，在節奏越來越快的工作和生活中，人們需要通過閱讀和學習大量信息豐富、具備實踐指導意義的圖書來獲取新知識和新技能，從而不斷提高自身素質，緊跟信息化時代發展的步伐。
眾所周知，在計算機硬體方面，高性價比的解決方案和新型技術的套用一直備受青睞；在軟體技術方面，隨著計算機軟體的規模和複雜性與日俱增，軟體技術不斷地受到挑戰，人們一直在為尋求更先進的軟體技術而奮鬥不止。目前，計算機和網際網路在社會生活中日益普及，掌握計算機網路技術和理論已成為大眾的文化需求。由於信息科學與技術在電工、電子、通信、工業控制、智慧型建築、工業產品設計與製造等專業領域中已經得到充分、廣泛的套用，所以這些專業領域中的研究人員和工程技術人員越來越迫切需要汲取自身領域信息化所帶來的新理念和新方法。
針對人們了解和掌握新知識、新技能的熱切期待，以及由此促成的人們對語言簡潔、內容充實、融合實踐經驗的圖書迫切需要的現狀，機械工業出版社適時推出了“信息科學與技術叢書”。這套叢書涉及計算機軟體、硬體、網路和工程套用等內容，注重理論與實踐的結合，內容實用、層次分明、語言流暢，是信息科學與技術領域專業人員不可或缺的參考書。
眾所周知，在計算機硬體方面，高性價比的解決方案和新型技術的套用一直備受青睞；在軟體技術方面，隨著計算機軟體的規模和複雜性與日俱增，軟體技術不斷地受到挑戰，人們一直在為尋求更先進的軟體技術而奮鬥不止。目前，計算機和網際網路在社會生活中日益普及，掌握計算機網路技術和理論已成為大眾的文化需求。由於信息科學與技術在電工、電子、通信、工業控制、智慧型建築、工業產品設計與製造等專業領域中已經得到充分、廣泛的套用，所以這些專業領域中的研究人員和工程技術人員越來越迫切需要汲取自身領域信息化所帶來的新理念和新方法。
針對人們了解和掌握新知識、新技能的熱切期待，以及由此促成的人們對語言簡潔、內容充實、融合實踐經驗的圖書迫切需要的現狀，機械工業出版社適時推出了“信息科學與技術叢書”。這套叢書涉及計算機軟體、硬體、網路和工程套用等內容，注重理論與實踐的結合，內容實用、層次分明、語言流暢，是信息科學與技術領域專業人員不可或缺的參考書。
