《微服務設計》閱讀筆記（七）測試

《微服務設計》，Building Microservices，作者Sam Newman，譯者崔力強、張駿，人民郵電出版社，2016年。

筆記中有些內容直接引用原書。

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

第七章 測試

1. 測試類型

面向技術的測試：單元測試、非功能性測試（響應時間、可擴展性、性能測試、安全測試）。面向業務的測試：驗收測試、探索性測試（可用性測試、我如何破壞系統功能）。對於微服務，要儘可能擴大自動化測試範圍。

2. 測試範圍

Mike Cohn的《Scrum敏捷軟體開發》提出了測試金字塔，底層是單元測試，中間是服務測試，上層是用戶界面測試（這裡稱為端到端測試）。

單元測試。通常只測試一個函數和方法調用，面向技術而不是業務，能快速反饋功能是否正常，對代碼重構非常重要。

服務測試。繞開用戶界面，直接對服務進行測試。需要給所有外部合作者打樁。

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

權衡。三種測試在測試範圍、運行時間、反饋周期、定位範圍都不同，要為不同目的選擇不同測試來覆蓋。

比例。好的經驗：下面一層的測試的數量要比上面一層的多一個數量級。

3. 實現服務測試

mock還是打樁。打樁，是指為被測服務的請求創建一些有著預設響應的打樁服務。mock，與打樁相比，mock還會進一步驗證請求本身是否被正確調用，需要創建更智能的合作者。但過度使用mock會讓測試變得脆弱。關於二者的權衡，可以參考弗里曼和普雷斯的書《測試驅動的面向對象軟體開發》。

智能的打樁服務。Mountebank是一個打樁/mock伺服器，可以避免很多重複工作。

4. 端到端測試

讓多個流水線扇入到一個獨立的端到端測試的階段。也就是各個服務有自己的構建、單元測試和服務測試，但沒有自己的端到端測試，所有服務都共享最後的端到端測試。

5. 端到端測試的缺點。有很多缺點（詳見下面章節）。

6. 脆弱的測試

端到端測試由於依賴太多的因素，比如其它服務、網路等等，很可能出現失敗時並不是由被測的那個服務所導致的。這就導致測試變得脆弱。Martin Fowler建議當出現脆弱測試時，如果不能立即修復，就將其從測試套件中移除。另外，還可以嘗試用小範圍測試替代脆弱測試。

誰來寫這些測試。測試由所有人來寫，會導致測試用例爆炸，測試失敗後，都認為是別人的問題。由專門的團隊來寫，開發人員遠離測試代碼，周期變長，並且難以理解和修複測試中的問題。好的平衡在於共享端到端測試套件的代碼權，對測試套件聯合負責。

測試多長時間。很多端到端測試時間很長，有的要一天，有的甚至六個星期。並行測試工具如Selenium Grid可以緩解該問題。但重要的在於權衡哪些測試需要哪些可以拋棄。這很困難。

大量的堆積。測試周期長導致部署等待時間長，部署次數少，代碼變更就會不斷累積。因此要儘可能頻繁地發布小範圍的修改。

元版本。不要追求一起部署服務，以及使用相同的版本號，這會導致失去服務單獨部署的能力，並且導致服務之間的耦合。

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

針對少量的核心場景進行端到端測試，避免針對龐大規模服務的端到端測試。但更好的方法可能是下面的CDC測試。

8. 拯救消費者驅動的測試

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

Pact。Pact是一個開源的消費者驅動的測試工具，Ruby語言開發，支持JVM和.NET版本。Pacto是另外一個工具，名字很相近。

關於溝通。CDC需要消費者和生產服務之間有良好的溝通。

9. 還應該使用端到端測試嗎

CDC可以替代端到端測試，但在語義監控進行生產系統監控時，還是會用到端到端測試。端到端測試可以在你需要的時候使用，比如尚未構建好CDC測試，完成後可以減少。

10. 部署後再測試

區分部署和上線。部署在生產環境，在真正負載之前進行測試，有助於發現特定環境的問題。還可以使用藍/綠部署，部署兩份軟體，但只有一個接受真正的請求。藍/綠部署需要能夠切換生產流量到不同的主機，需要提供足夠多的主機支持兩個版本部署。藍/綠部署甚至可以做到零宕機部署。

金絲雀發布。金絲雀發布是指通過將部分生產流量引流到新部署的系統，來驗證系統執行情況。與藍/綠髮布不同的是，新舊版本共存的時間更長，而且經常會調整流量。

平均修復時間（MTTR）勝過平均故障間隔時間（MTBF）。要好好考慮如何監控以及從故障中恢復過來，而不僅僅是考慮充分的測試。

11. 跨功能的測試

跨功能需求（Cross-Functional Requirement, CFR）比非功能需求更好地涵蓋了一個事實：這些系統行為僅僅是許多橫切工作融合的結果。跨功能需求包括數據的持久性、服務的可用性、吞吐量和服務可接受的延遲等方面。CFR測試也是金字塔分層的。建議儘早去看CFR，並定期審查。

性能測試。微服務使得跨網路邊界的次數增多，因此追蹤延遲的根源很重要。需要一個類似生產的數據量，更多的機器。性能測試運行時間長，每次構建的時候運行性能測試並不可行。可以每天運行一個子集，每周運行一個更大的集合。還是要儘可能頻繁。

12. 小結

使用不同類型測試，反饋要迅速；盡量使用CDC測試來替代端到端測試；使用CDC測試提供團隊之間的對話要點；在努力測試與更快地在生產環境中發現並修復問題之間找到平衡。

BrianZhang：《微服務設計》閱讀筆記(一)微服務zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（二）演化式架構師zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記(三)如何建模服務zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（四）集成zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（五）分解單塊系統zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（六）部署zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（八） 監控zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（九）安全zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（十）康威定律和系統設計zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（十一）規模化微服務zhuanlan.zhihu.comBrianZhang：《微服務設計》閱讀筆記（十二完結篇）總結zhuanlan.zhihu.com軟體開發之路zhuanlan.zhihu.com
推薦閱讀：