《微服務(wù)設(shè)計》，Building Microservices截酷，作者Sam Newman涮拗，譯者崔力強、張駿迂苛，人民郵電出版社三热，2016年。

筆記中有些內(nèi)容直接引用原書三幻。

================================================================

第七章測試

1.測試類型

面向技術(shù)的測試：單元測試就漾、非功能性測試（響應(yīng)時間、可擴展性念搬、性能測試抑堡、安全測試）。面向業(yè)務(wù)的測試：驗收測試朗徊、探索性測試（可用性測試首妖、我如何破壞系統(tǒng)功能）。對于微服務(wù)爷恳，要盡可能擴大自動化測試范圍有缆。

2.測試范圍

Mike Cohn的《Scrum敏捷軟件開發(fā)》提出了測試金字塔，底層是單元測試温亲，中間是服務(wù)測試妒貌，上層是用戶界面測試（這里稱為端到端測試）。

單元測試铸豁。通常只測試一個函數(shù)和方法調(diào)用，面向技術(shù)而不是業(yè)務(wù)菊碟，能快速反饋功能是否正常节芥，對代碼重構(gòu)非常重要。

服務(wù)測試逆害。繞開用戶界面头镊，直接對服務(wù)進行測試。需要給所有外部合作者打樁魄幕。

端到端測試相艇。模仿用戶使用的測試。

權(quán)衡纯陨。三種測試在測試范圍坛芽、運行時間留储、反饋周期、定位范圍都不同咙轩，要為不同目的選擇不同測試來覆蓋获讳。

比例。好的經(jīng)驗：下面一層的測試的數(shù)量要比上面一層的多一個數(shù)量級活喊。

3.實現(xiàn)服務(wù)測試

mock還是打樁丐膝。打樁，是指為被測服務(wù)的請求創(chuàng)建一些有著預(yù)設(shè)響應(yīng)的打樁服務(wù)钾菊。mock帅矗，與打樁相比，mock還會進一步驗證請求本身是否被正確調(diào)用煞烫，需要創(chuàng)建更智能的合作者浑此。但過度使用mock會讓測試變得脆弱。關(guān)于二者的權(quán)衡红竭，可以參考弗里曼和普雷斯的書《測試驅(qū)動的面向?qū)ο筌浖_發(fā)》尤勋。

智能的打樁服務(wù)。Mountebank是一個打樁/mock服務(wù)器茵宪，可以避免很多重復(fù)工作最冰。

4.端到端測試

讓多個流水線扇入到一個獨立的端到端測試的階段。也就是各個服務(wù)有自己的構(gòu)建稀火、單元測試和服務(wù)測試暖哨，但沒有自己的端到端測試，所有服務(wù)都共享最后的端到端測試凰狞。

5.端到端測試的缺點篇裁。有很多缺點（詳見下面章節(jié)）。

6.脆弱的測試

端到端測試由于依賴太多的因素赡若，比如其它服務(wù)达布、網(wǎng)絡(luò)等等，很可能出現(xiàn)失敗時并不是由被測的那個服務(wù)所導(dǎo)致的逾冬。這就導(dǎo)致測試變得脆弱黍聂。Martin Fowler建議當(dāng)出現(xiàn)脆弱測試時，如果不能立即修復(fù)身腻，就將其從測試套件中移除产还。另外，還可以嘗試用小范圍測試替代脆弱測試嘀趟。

誰來寫這些測試脐区。測試由所有人來寫，會導(dǎo)致測試用例爆炸她按，測試失敗后牛隅，都認為是別人的問題炕柔。由專門的團隊來寫，開發(fā)人員遠離測試代碼倔叼，周期變長汗唱，并且難以理解和修復(fù)測試中的問題。好的平衡在于共享端到端測試套件的代碼權(quán)丈攒，對測試套件聯(lián)合負責(zé)哩罪。

測試多長時間。很多端到端測試時間很長巡验，有的要一天际插，有的甚至六個星期。并行測試工具如Selenium Grid可以緩解該問題显设。但重要的在于權(quán)衡哪些測試需要哪些可以拋棄框弛。這很困難。

大量的堆積捕捂。測試周期長導(dǎo)致部署等待時間長瑟枫，部署次數(shù)少，代碼變更就會不斷累積指攒。因此要盡可能頻繁地發(fā)布小范圍的修改慷妙。

元版本。不要追求一起部署服務(wù)允悦，以及使用相同的版本號膝擂，這會導(dǎo)致失去服務(wù)單獨部署的能力，并且導(dǎo)致服務(wù)之間的耦合隙弛。

7.測試場景架馋，而不是故事

針對少量的核心場景進行端到端測試，避免針對龐大規(guī)模服務(wù)的端到端測試全闷。但更好的方法可能是下面的CDC測試叉寂。

8.拯救消費者驅(qū)動的測試

CDC(Consumer-Driven Contract)消費者驅(qū)動的契約，可以不需要使用真正的消費者也能確保新的部署不會破壞給消費者的服務(wù)总珠。CDC測試的層次與服務(wù)測試的層次一樣办绝，都在金字塔中間，但其更側(cè)重消費者如何使用服務(wù)姚淆。

Pact。Pact是一個開源的消費者驅(qū)動的測試工具屡律，Ruby語言開發(fā)腌逢，支持JVM和.NET版本。Pacto是另外一個工具超埋，名字很相近搏讶。

關(guān)于溝通佳鳖。CDC需要消費者和生產(chǎn)服務(wù)之間有良好的溝通。

9.還應(yīng)該使用端到端測試嗎

CDC可以替代端到端測試媒惕，但在語義監(jiān)控進行生產(chǎn)系統(tǒng)監(jiān)控時系吩，還是會用到端到端測試。端到端測試可以在你需要的時候使用妒蔚，比如尚未構(gòu)建好CDC測試穿挨，完成后可以減少。

10.部署后再測試

區(qū)分部署和上線肴盏。部署在生產(chǎn)環(huán)境，在真正負載之前進行測試，有助于發(fā)現(xiàn)特定環(huán)境的問題洼专。還可以使用藍/綠部署镇草，部署兩份軟件，但只有一個接受真正的請求恍飘。藍/綠部署需要能夠切換生產(chǎn)流量到不同的主機榨崩，需要提供足夠多的主機支持兩個版本部署。藍/綠部署甚至可以做到零宕機部署章母。

金絲雀發(fā)布母蛛。金絲雀發(fā)布是指通過將部分生產(chǎn)流量引流到新部署的系統(tǒng)，來驗證系統(tǒng)執(zhí)行情況胳施。與藍/綠發(fā)布不同的是溯祸，新舊版本共存的時間更長，而且經(jīng)常會調(diào)整流量舞肆。

平均修復(fù)時間（MTTR）勝過平均故障間隔時間（MTBF）焦辅。要好好考慮如何監(jiān)控以及從故障中恢復(fù)過來，而不僅僅是考慮充分的測試椿胯。

11.跨功能的測試

跨功能需求（Cross-Functional Requirement, CFR）比非功能需求更好地涵蓋了一個事實：這些系統(tǒng)行為僅僅是許多橫切工作融合的結(jié)果筷登。跨功能需求包括數(shù)據(jù)的持久性哩盲、服務(wù)的可用性前方、吞吐量和服務(wù)可接受的延遲等方面。CFR測試也是金字塔分層的廉油。建議盡早去看CFR惠险，并定期審查。

性能測試抒线。微服務(wù)使得跨網(wǎng)絡(luò)邊界的次數(shù)增多班巩，因此追蹤延遲的根源很重要。需要一個類似生產(chǎn)的數(shù)據(jù)量嘶炭，更多的機器抱慌。性能測試運行時間長逊桦，每次構(gòu)建的時候運行性能測試并不可行∫纸可以每天運行一個子集强经，每周運行一個更大的集合。還是要盡可能頻繁寺渗。

12.小結(jié)

使用不同類型測試匿情，反饋要迅速；盡量使用CDC測試來替代端到端測試户秤；使用CDC測試提供團隊之間的對話要點码秉；在努力測試與更快地在生產(chǎn)環(huán)境中發(fā)現(xiàn)并修復(fù)問題之間找到平衡。