本來計(jì)劃讀《需求實(shí)例化》胶滋，考慮自己打算寫TDD總結(jié)文檔板鬓，還是選一些相關(guān)內(nèi)容，決定先讀《持續(xù)交付-發(fā)布可靠軟件的系統(tǒng)方法》（根本原因是沒有書^_^）究恤。
《持續(xù)交付-發(fā)布可靠軟件的系統(tǒng)方法》全書51.2萬字俭令，15章，384頁部宿。在仔細(xì)讀完序言部分和目錄抄腔，挑選了三個(gè)最有興趣的主題進(jìn)行精讀，即：測試策略（第四章）理张，容量設(shè)計(jì)（第九章部分內(nèi)容）赫蛇，測試數(shù)據(jù)管理（第十二章部分內(nèi)容）。
1雾叭、測試策略
戴明14條之一就是“停止依賴于大批量的檢查來保證質(zhì)量的做法悟耘。改進(jìn)過程，從一開始就將質(zhì)量內(nèi)嵌與產(chǎn)品之中”[9YhQXz]
【對(duì)于軟件研發(fā)的過程改進(jìn)來說织狐，減少人工測試作煌，盡可能考慮使用自動(dòng)化的單元測試掘殴，并且內(nèi)嵌到CI中∷谑模】
1.1測試象限
系統(tǒng)闡述了Brian Marick提出的測試象限。來為軟件進(jìn)行測試建模起意。
1.2 Happy Path
在4.2.1業(yè)務(wù)導(dǎo)向且支持開發(fā)過程的測試中：
* 定義：對(duì)于每個(gè)需求或者用戶故事來說鹰服，根據(jù)用戶執(zhí)行動(dòng)作，一定會(huì)找到應(yīng)用程序中一個(gè)中規(guī)中矩的執(zhí)行路徑揽咕。
* 描述方式：就是（Gievn-When-Then）書寫模型悲酷。假如[當(dāng)測試開始時(shí)，系統(tǒng)所處狀態(tài)的一些重要特征]亲善，當(dāng)[用戶執(zhí)行某些動(dòng)作后]设易，那么[系統(tǒng)新的狀態(tài)的一些特征]∮纪罚【以前描述不準(zhǔn)確顿肺，需改正】
* 引申：執(zhí)行結(jié)果狀態(tài)不同時(shí)，就會(huì)出現(xiàn)Alternate Path渣蜗。引發(fā)的錯(cuò)誤處理叫Sad Path.
* 工具：定價(jià)劃分分析和邊界值劃分析可以幫助我們找到最小的用例集合屠尊。【單元測試需要這樣的技能】
1.3 自動(dòng)化測試相關(guān)
-自動(dòng)化驗(yàn)收測試限于Happy Path行為耕拷，并僅覆蓋其他一些極其重要部分讼昆。（這是高效的策略，前提是其他自動(dòng)化測試很全面）
* 一般將代碼覆蓋率搞80%測試視為“全面的”測試骚烧，測試質(zhì)量也非常重要浸赫。
* 第二條規(guī)則包含單元測試，組件測試和驗(yàn)收測試赃绊，單獨(dú)滿足既峡，而不是累加滿足
* 每個(gè)故事至少要有一個(gè)Happy Path的自動(dòng)化驗(yàn)收測試。給開發(fā)人員充當(dāng)冒煙測試凭戴，檢測“是否破壞已有功能”快速反饋涧狮。
【看來我們的測試時(shí)萬里長征第一步，需要繼續(xù)努力】
1.4 單元測試和組件測試（集成測試）
單元測試：依賴于測試替身模擬系統(tǒng)其它部分么夫。要求：
* 不應(yīng)該訪問數(shù)據(jù)庫者冤，文件系統(tǒng)與外部系統(tǒng)交互。
* 不應(yīng)有組件間交互
* 運(yùn)行非车祷荆快
【單元測試現(xiàn)在方向是對(duì)的涉枫，思路也是對(duì)的，時(shí)間的玫瑰o(*￣︶￣*)o】
組件測試（集成測試）:更大的測試集腐螟，連接真實(shí)的數(shù)據(jù)庫
1.5 現(xiàn)實(shí)中情況與應(yīng)對(duì)策略
新項(xiàng)目：理想國愿汰。1）技術(shù)平臺(tái)&測試工具困后；2）自動(dòng)化構(gòu)建；3）制定INVEST的用戶故事并考慮驗(yàn)收條件衬廷。
項(xiàng)目進(jìn)行中：Happy Path自動(dòng)化摇予，覆蓋高價(jià)值的場景。逐步補(bǔ)全盡可能多的場景吗跋。
遺留系統(tǒng)：測試你修改的代碼侧戴。以及高價(jià)值的場景。
【我們的產(chǎn)品是各種合體跌宛，可以針對(duì)不同部分選擇策略】
迭代前找到高優(yōu)先級(jí)的場景酗宋。利用工具或者DSL可以場景變成測試用例〗校【這塊感覺很難蜕猫，也許是一個(gè)很好目標(biāo)和方向，需關(guān)注】
管理待修復(fù)缺陷列表哎迄。根據(jù)嚴(yán)重回右、阻塞、中芬失、低來管理缺陷楣黍。
2、容量設(shè)計(jì)
2.1 如何容量編程
高德納的過早優(yōu)化理論指出早期的預(yù)料可能是錯(cuò)的棱烂。也不是后期解決所有的問題租漂。正確策略：
--為系統(tǒng)決定一種架構(gòu)。包括：進(jìn)程颊糜、網(wǎng)絡(luò)邊界和IO
--使用真確的模式哩治，避免影響容量和穩(wěn)定性的反模式。書《Release it衬鱼！》
--研發(fā)過程中业筏，可讀性（清晰簡單）優(yōu)先。在沒有測試數(shù)據(jù)時(shí)鸟赫，避免過早優(yōu)化蒜胖。
--選擇高性能的算法和數(shù)據(jù)結(jié)構(gòu)【聽過一句更好的描述：數(shù)據(jù)結(jié)構(gòu)決定性能上限，算法決定性能下限】
--注意線程阻塞抛蚤。
--自動(dòng)化測試斷言所期望的容量級(jí)別台谢。
--修復(fù)調(diào)測中問題。
--盡可能用真實(shí)數(shù)據(jù)度量性能岁经。
2.2 容量度量
-擴(kuò)展性測試：擴(kuò)容能力下朋沮，響應(yīng)時(shí)間和并發(fā)數(shù)用戶的指標(biāo)。
持久性測試：用來檢測內(nèi)存泄露和穩(wěn)定性問題缀壤。
吞吐量測試：每S處理多少事務(wù)樊拓。
負(fù)載測試：在生產(chǎn)環(huán)境情況下纠亚，系統(tǒng)容量。
完全負(fù)載生產(chǎn)環(huán)境是不可能的筋夏，需要做流量分析蒂胞，結(jié)合經(jīng)驗(yàn)和直覺來表達(dá)盡可能接近真實(shí)環(huán)境的模擬。
【以前性能測試關(guān)注吞吐量和響應(yīng)時(shí)間是不夠的】
2.3 自動(dòng)化容量測試
目標(biāo)：創(chuàng)建比較現(xiàn)實(shí)的類生產(chǎn)環(huán)境的負(fù)載条篷；選擇并實(shí)行代表性且現(xiàn)實(shí)生產(chǎn)中非正常負(fù)載狀態(tài)的場景啤誊。
還有一種有效中方法“識(shí)別系統(tǒng)中代價(jià)最高的事務(wù)，然后在系統(tǒng)中把他變成兩三倍的數(shù)量”（《Release It拥娄！》）⊥ぃ【這個(gè)思路棒稚瘾，可以作為后續(xù)的內(nèi)容】
對(duì)于我們來說，有兩種方法更為實(shí)用：實(shí)用錄制的交互模板姚炕；使用容量測試樁開發(fā)測試
2.4 將容量測試加入到部署流水線
避免容量的過度設(shè)計(jì)摊欠；盡早發(fā)現(xiàn)容量的問題，進(jìn)行修復(fù)柱宦⌒┙罚【這也是個(gè)目標(biāo)】
2.5 容量測試附加價(jià)值
把容量測試設(shè)計(jì)為組合式，基于場景的測試掸刊∶飧猓可以用來診斷問題、預(yù)測問題并找到辦法解決問題忧侧。
3? 測試數(shù)據(jù)管理
主要有兩點(diǎn)：測試性能-盡可能快的完成石窑；測試獨(dú)立性-收入受控，才能評(píng)估出他的輸出蚓炬。
3.1 為單元測試進(jìn)行數(shù)據(jù)庫模擬
單元測試不實(shí)用真正的數(shù)據(jù)庫是非常重要的松逊。可以考慮兩種策略：
1肯夏、測試替身對(duì)象來代替訪問數(shù)據(jù)庫的代碼经宏。【對(duì)于C++后來來說驯击，就是gtest+gmock的方式烁兰。】
2余耽、使用假的數(shù)據(jù)庫缚柏。作者建議內(nèi)存型數(shù)據(jù)庫例如H2，SQLit碟贾，Java币喧」煊颍【我們的MOCKDB也是屬于這種思路，但比這個(gè)開源數(shù)據(jù)更有優(yōu)點(diǎn)杀餐，看來我們找到最優(yōu)解了干发。棒！以后寫總結(jié)】
3.2 管理測試和數(shù)據(jù)耦合
有三個(gè)方法來做測試設(shè)計(jì):
-測試獨(dú)立性：測試的數(shù)據(jù)只對(duì)該用例可見史翘⊥鞒ぃ【Mockdb的測試框架成功做到這點(diǎn)】
-適應(yīng)性測試：先檢查環(huán)境，從環(huán)境中獲取數(shù)據(jù)進(jìn)行測試琼讽。
-測試順序性：按照已知的順序進(jìn)行測試必峰，并且具備依賴性。
作者強(qiáng)烈推薦第一種钻蹬『鹨希【看來我們的測試框架是最優(yōu)選擇】
3.3 連貫的測試場景
作者認(rèn)為這是需要抵制的誘惑。這種耦合會(huì)導(dǎo)致設(shè)計(jì)困難问欠，設(shè)計(jì)失敗后會(huì)造成一系列的影響肝匆。【這個(gè)值得思考和注意】
總結(jié)
作為實(shí)用主義者顺献，選擇自己最有興趣的三個(gè)部分旗国，從泛讀，到精讀注整，然后整理并輸出筆記能曾。前后耗時(shí)5小時(shí)，收獲頗豐设捐，值借浊！
