本來計劃讀《需求實例化》，考慮自己打算寫TDD總結文檔，還是選一些相關內容，決定先讀《持續交付-發布可靠軟件的系統方法》（根本原因是沒有書^_^）。
《持續交付-發布可靠軟件的系統方法》全書51.2萬字，15章，384頁。在仔細讀完序言部分和目錄，挑選了三個最有興趣的主題進行精讀，即：測試策略（第四章），容量設計（第九章部分內容），測試數據管理（第十二章部分內容）。
1、測試策略
戴明14條之一就是“停止依賴于大批量的檢查來保證質量的做法。改進過程，從一開始就將質量內嵌與產品之中”[9YhQXz]
【對于軟件研發的過程改進來說，減少人工測試，盡可能考慮使用自動化的單元測試，并且內嵌到CI中。】
1.1測試象限
系統闡述了Brian Marick提出的測試象限。來為軟件進行測試建模。
1.2 Happy Path
在4.2.1業務導向且支持開發過程的測試中：
* 定義：對于每個需求或者用戶故事來說，根據用戶執行動作，一定會找到應用程序中一個中規中矩的執行路徑。
* 描述方式：就是（Gievn-When-Then）書寫模型。假如[當測試開始時，系統所處狀態的一些重要特征]，當[用戶執行某些動作后]，那么[系統新的狀態的一些特征]。【以前描述不準確，需改正】
* 引申：執行結果狀態不同時，就會出現Alternate Path。引發的錯誤處理叫Sad Path.
* 工具：定價劃分分析和邊界值劃分析可以幫助我們找到最小的用例集合。【單元測試需要這樣的技能】
1.3 自動化測試相關
-自動化驗收測試限于Happy Path行為，并僅覆蓋其他一些極其重要部分。（這是高效的策略，前提是其他自動化測試很全面）
* 一般將代碼覆蓋率搞80%測試視為“全面的”測試，測試質量也非常重要。
* 第二條規則包含單元測試，組件測試和驗收測試，單獨滿足，而不是累加滿足
* 每個故事至少要有一個Happy Path的自動化驗收測試。給開發人員充當冒煙測試，檢測“是否破壞已有功能”快速反饋。
【看來我們的測試時萬里長征第一步，需要繼續努力】
1.4 單元測試和組件測試（集成測試）
單元測試：依賴于測試替身模擬系統其它部分。要求：
* 不應該訪問數據庫，文件系統與外部系統交互。
* 不應有組件間交互
* 運行非常快
【單元測試現在方向是對的，思路也是對的，時間的玫瑰o(*￣︶￣*)o】
組件測試（集成測試）:更大的測試集，連接真實的數據庫
1.5 現實中情況與應對策略
新項目：理想國。1）技術平臺&測試工具；2）自動化構建；3）制定INVEST的用戶故事并考慮驗收條件。
項目進行中：Happy Path自動化，覆蓋高價值的場景。逐步補全盡可能多的場景。
遺留系統：測試你修改的代碼。以及高價值的場景。
【我們的產品是各種合體，可以針對不同部分選擇策略】
迭代前找到高優先級的場景。利用工具或者DSL可以場景變成測試用例。【這塊感覺很難，也許是一個很好目標和方向，需關注】
管理待修復缺陷列表。根據嚴重、阻塞、中、低來管理缺陷。
2、容量設計
2.1 如何容量編程
高德納的過早優化理論指出早期的預料可能是錯的。也不是后期解決所有的問題。正確策略：
--為系統決定一種架構。包括：進程、網絡邊界和IO
--使用真確的模式，避免影響容量和穩定性的反模式。書《Release it！》
--研發過程中，可讀性（清晰簡單）優先。在沒有測試數據時，避免過早優化。
--選擇高性能的算法和數據結構【聽過一句更好的描述：數據結構決定性能上限，算法決定性能下限】
--注意線程阻塞。
--自動化測試斷言所期望的容量級別。
--修復調測中問題。
--盡可能用真實數據度量性能。
2.2 容量度量
-擴展性測試：擴容能力下，響應時間和并發數用戶的指標。
持久性測試：用來檢測內存泄露和穩定性問題。
吞吐量測試：每S處理多少事務。
負載測試：在生產環境情況下，系統容量。
完全負載生產環境是不可能的，需要做流量分析，結合經驗和直覺來表達盡可能接近真實環境的模擬。
【以前性能測試關注吞吐量和響應時間是不夠的】
2.3 自動化容量測試
目標：創建比較現實的類生產環境的負載；選擇并實行代表性且現實生產中非正常負載狀態的場景。
還有一種有效中方法“識別系統中代價最高的事務，然后在系統中把他變成兩三倍的數量”（《Release It！》）。【這個思路棒，可以作為后續的內容】
對于我們來說，有兩種方法更為實用：實用錄制的交互模板；使用容量測試樁開發測試
2.4 將容量測試加入到部署流水線
避免容量的過度設計；盡早發現容量的問題，進行修復。【這也是個目標】
2.5 容量測試附加價值
把容量測試設計為組合式，基于場景的測試。可以用來診斷問題、預測問題并找到辦法解決問題。
3? 測試數據管理
主要有兩點：測試性能-盡可能快的完成；測試獨立性-收入受控，才能評估出他的輸出。
3.1 為單元測試進行數據庫模擬
單元測試不實用真正的數據庫是非常重要的。可以考慮兩種策略：
1、測試替身對象來代替訪問數據庫的代碼。【對于C++后來來說，就是gtest+gmock的方式。】
2、使用假的數據庫。作者建議內存型數據庫例如H2，SQLit，Java。【我們的MOCKDB也是屬于這種思路，但比這個開源數據更有優點，看來我們找到最優解了。棒！以后寫總結】
3.2 管理測試和數據耦合
有三個方法來做測試設計:
-測試獨立性：測試的數據只對該用例可見。【Mockdb的測試框架成功做到這點】
-適應性測試：先檢查環境，從環境中獲取數據進行測試。
-測試順序性：按照已知的順序進行測試，并且具備依賴性。
作者強烈推薦第一種。【看來我們的測試框架是最優選擇】
3.3 連貫的測試場景
作者認為這是需要抵制的誘惑。這種耦合會導致設計困難，設計失敗后會造成一系列的影響。【這個值得思考和注意】
總結
作為實用主義者，選擇自己最有興趣的三個部分，從泛讀，到精讀，然后整理并輸出筆記。前后耗時5小時，收獲頗豐，值！
