在上一章中介紹了持續集成，這讓我們的項目在整個生命周期中都是可控的，一直處于可運行狀態，對于后期的集成也是起很大的幫助的，但是要獲得這些優點，就需要團隊之間良好的協作，共同遵守一些良好的實踐，比如，使用版本控制工具，頻繁提交，多些注釋，測試覆蓋等。
那在這一章就講其中一個很重要的實踐——測試，主要講解如何實現測試策略，而不涉及具體測試的書寫。
為什么要寫測試
我們不應該將所有的檢查都依賴于手工或者人為的檢查，這樣耗費時間不說，還會讓代碼的結構性降低。正確的做法應該是在項目一開始就一直做測試。
在一個理想的項目中，項目一開始，測試人員就會與開發人員一起寫自動化測試，這些測試應該在開發人員開始要測試的功能之前就寫好。這樣，這些測試就成了一個可執行的且從系統行為角度描述的規格說明書。當這些測試全部通過以后，也足以說明客戶所需要的功能實現了。這樣在之后的修改重構時，也有了足夠的保證。
測試的分類
這是由Brian Marick提出的測試象限圖，他將測試分為兩個維度，一個是業務導向，還是技術導向，另一個維度是為了支持開發過程，還是為了對項目進行評價。
1.業務導向且支持團隊的測試
這一象限的測試通常稱作功能測試或驗收測試。為了確保用戶故事的驗收條件得到滿足，在開發一個用戶故事之前，就應該寫好驗收測試，采取完美的自動化形式。
2.技術導向且支持開發過程的測試
這一象限的測試通常都包含：單元測試，組件測試，部署測試。單元測試用于測試一個特定的代碼段，使用測試替身來模擬系統系統其他部分，不應該訪問數據庫，文件系統等外部系統。組件測試用于測試更大的功能集合，涉及更多的準備工作并執行更多的I/O操作。部署測試用于檢查部署過程是否正確。
3.業務導向寫評價項目的測試
這一象限的測試通常包含：探索性測試，易用性測試。都是手工測試驗證我們實際交付的軟件是否符合期望。這并不知識驗證應用是否滿足需求規格說明書，還驗證需求說明規格書的正確性，及時的獲取反饋并對需求說明規格書進行修改。
4.技術導向且評價項目的測試
這一象限的測試有非功能測試，比如：容量測試，性能測試，安全性測試等和項目功能無關的測試。我應該將非功能需求和功能需求放在同等的地位看待。
測試替身
測試替身用于在測試代替還未實現的模塊數據。可以分為下面這幾類：
- 啞對象
- 假對象
- 樁
- spy
- 模擬對象
流程
在項目開發中，我們應該盡可能提前寫好各種自動化測試，并且實踐敏捷開發，測試不僅僅是測試人員一個人的事，應該讓整個開發小組以及客戶參與進來，共同制定一些標準，并且在之后的開發過程中，開發人員要和測試人員緊密合作。對于檢測出現的問題，進行進行處理，對于已有待修復缺陷的列表，應該重視起來，不要堆積。
總結
我的收獲
- 有一些軟件可以讓客戶參與測試的編寫，需求更加清晰
- 演示是項目的核心，這樣可以從客戶那里確認是否需求理解正確
- 了解到測試替身這個概念
- 終于完全明白了非公能需求是啥
- 之前一直以為遺留系統就是之前留下的系統，現在看了這本書才知道是沒有自動化測試的系統。
我的疑惑
- 回歸測試是什么？，都包含哪些方面
- 對于測試替身中的幾個分類，概念不清晰
- 書中描述的全方位測試的書寫，持續交付的實踐，現實中大多數人會這么做么？感覺準備工作太多了，是不是得自己衡量下。
- 為什么會有待修復缺陷列表的存在，有錯誤不是應該及時的修復么，堆積著開發總是有風險的。
