微服務架構中測試的復雜度進一步增加，了解測試的類型可用幫助我們盡早交付軟件與保持軟件高質量之間的平衡
1. 測試象限
面向技術的測試：首先幫助開發(fā)人員構建系統(tǒng)的測試，這個象限里的測試大都是可用自動化測試的，例如性能測試和小范圍的單元測試
面向業(yè)務的測試：幫助非技術背景的人了解系統(tǒng)是如何工作的。
支持團隊：幫助開發(fā)人員是否正確實現(xiàn)了功能，幫助業(yè)務人員了解系統(tǒng)是否實現(xiàn)了正確的功能
評價產(chǎn)品：非功能測試（響應時間，可擴展性前翎，性能測試、安全測試）及可用性測試
2. 測試范圍：測試金字塔
Mike Cohn在《Scrum敏捷軟件開發(fā)》介紹了測試金字塔畅涂，描述了不同的自動化測試類型
金字塔模型可用幫組我們思考：1）不同的測試類型應該覆蓋的范圍港华；2）為不同的測試類型投入多大的比例
1) 單元測試：通常只測試一個函數(shù)和方法調用
a. 通過TDD（Test-Driven Design，測試驅動開發(fā)）寫的測試
b. 基于屬性（午衰？）的測試技術所產(chǎn)生的測試
單元測試的主要目的：對于功能是否正沉⒁耍快速給出反饋冒萄；對于代碼重構非常重要。
2) 服務測試：繞開用戶界面橙数，直接針對服務的測試
a. 獨立應用程序中尊流，服務測試可能只測試為用戶界面提供服務的一些類
b. 包含多個服務的系統(tǒng)，一個服務測試只測試其中一個單獨服務的功能
服務測試比單元測試的范圍大灯帮，比單元測試更難定位問題崖技。和端到端測試相比，服務測試包含的組件已經(jīng)少多了钟哥。
3) 端到端測試：用戶界面是系統(tǒng)功能的集成點迎献，所以改成了端到端的測試。會覆蓋整個系統(tǒng)瞪醋，通常需要打開一個瀏覽器來操作GUI忿晕。
1) 權衡：
越靠近金字塔頂端
a. 優(yōu)勢：測試覆蓋的范圍越大装诡；同時對被測試的功能也越有信心
b. 劣勢：需要更長的時間運行測試银受，反饋周期變長。測試失敗后鸦采，比較難定位哪個功能被破壞宾巍。
越靠近金字塔的底部：
a. 優(yōu)勢：測試會越快，反饋周期變短渔伯，測試失敗后更容易定位被破壞的功能顶霞，持續(xù)集成的構建時間也很短
b. 劣勢：只測試了一行代碼，很難有充足的信心認為系統(tǒng)作為一個整體依然正常工作
當范圍更大的測試（比如服務測試或者端到端的測試）失敗后锣吼，會嘗試一個單元測試來重現(xiàn)問題选浑，以便能更快的速度捕獲同樣的錯誤。
2) 比例：
好的經(jīng)驗法則：順著金字塔向下玄叠，下面一層的測試數(shù)量要比上面一層多一個數(shù)量級古徒。
3. 實現(xiàn)服務測試
服務測試只要測試一個單獨服務的功能，為了隔離其他的相關服務读恃，需要一種方法給所有的外部合作者打樁隧膘。
1) 打樁，是指為被測試的服務的請求創(chuàng)建一些有著預測響應的服務
步驟：
a. 對于每一個下游服務寺惫，都需要一個打樁服務疹吃，在運行服務測試的時候啟動它們；
b. 另外需要配置被測試的服務西雀，在測試過程中連接這些打樁服務
c. 為了模擬真實的服務萨驶，需要配置打樁服務為被測試服務的請求發(fā)回響應
2) Mock與打樁
Martin ?Fowler把Mock和打樁統(tǒng)稱為測試替身（Test Double），如何權衡兩者艇肴，請參考《測試驅動的面向對象軟件開發(fā)》
Mock和打樁的對比：
Mock的優(yōu)勢：
1) 會進一步驗證請求本身是否被正確調用腔呜，如果與期望請求不匹配判莉，測試便會失敗
2) 驗證預期的副作用是否發(fā)生
Mock的劣勢：
1) 過度使用mock會讓測試變得脆弱
3）智能的打樁服務
Mountebank（http://www.mbtest.org)，可以發(fā)送命令告訴它需要打樁什么端口育谬、使用哪種協(xié)議以及當收到請求時該響應什么內容
4. 端到端的測試
通過用戶界面的測試覆蓋其涉及的所有服務券盅。從另外一個層面講，用戶界面也集成了其涉及的所有的服務膛檀。所以運行端到測試需要部署多個服務锰镀。
會經(jīng)常碰到的兩個問題：
1) 應該使用服務的哪個版本？是生產(chǎn)環(huán)境的版本還是全部使用新版本進行驗證咖刃？
2) 不同的用戶界面測試會有很多的重疊測試泳炉，會重復部署這些重疊的服務。有沒有更好的辦法處理嚎杨？
方法：讓多個流水線扇入（fan in）到一個獨立的端到端測試的階段
任意一個服務在任何時候只要發(fā)生變化花鹅，都會運行針對這些服務的測試。如果測試通過枫浙，便會觸發(fā)端到端測試刨肃。
5. 端到端測試的缺點
1) 脆弱的測試：測試失敗的原因有時和服務的功能沒有任何關系
2) 測試緩慢：端到端測試需要大量的時間，進而會造成大量的堆積
3) 元版本：所有服務在這些版本下可以一起工作箩帚，為何不一起部署真友？為何不給整個系統(tǒng)使用同一個版本號？這樣做舊丟棄了微服務的主要優(yōu)勢之一：獨立于其他服務單獨部署一個服務的能力
把多個服務一起部署不可避免地會導致服務的耦合
6. 消費者驅動契約的測試
替代端到端測試的一個解決方案
CDC：Customer-Driven Contract消費者驅動的契約
使用CDC時紧帕，我們會定義服務（或生產(chǎn)者）的消費者的期望者的期望盔然。這些期望會變成對生產(chǎn)者運行的測試代碼，成為生產(chǎn)者CI流水線的一部分是嗜。如果這些契約被破壞愈案，生產(chǎn)者就無法部署。另外鹅搪，只運行CDC測試站绪，周期更短，也更可靠涩嚣。
1) Pact：CDC測試的工具崇众，現(xiàn)在已經(jīng)開源，使用Ruby語言編寫航厚，現(xiàn)在支持包括JVM和.Net的版本
a. 使用Ruby DSL來定義生產(chǎn)者的期望
b. 啟動一個本地mock服務器顷歌，并對其運行期望來生成Pack規(guī)范文件（標準的JSON規(guī)范）
c. 在生成者端，使用JSON Pact規(guī)范來驅動對生產(chǎn)者API的調用
d. 驗證響應來測試消費者的規(guī)范是否被滿足
7. 跨功能的測試
非功能性需求幔睬，是對系統(tǒng)展現(xiàn)的一些特性的一個總結的術語眯漩，包括一個網(wǎng)頁的響應時間，系統(tǒng)可以支持的用戶數(shù)量等。
使用跨功能需求（CFR赦抖， Cross-Functional Requirement）來替換非功能需求舱卡，因為這些系統(tǒng)行為是很多橫切工作融合的結果。
很多CFR只能在生產(chǎn)環(huán)境測試队萤。
8. MTTR優(yōu)于MTBF轮锥，平均修復時間優(yōu)于平均故障間隔時間
MTBF：Mean Time Between Failures，平均故障間隔時間
MTTR：Mean Time To Repair要尔，平均修復時間
減少修復時間的技術：良好的監(jiān)控+盡快回滾舍杜。使用監(jiān)控盡早發(fā)現(xiàn)生產(chǎn)中的問題，盡快回滾減少對客戶的影響赵辕。
