08、緊跟時代步伐：微服務模式下API測試要怎麼做？
一、單體架構和微服務架構
1、單體架構的特點
1.1、靈活性差：每次進行改動，都需要進行打包釋出整個應用，由於所有程式碼都在一起，所以每次編譯打包都要花費很長時間。
自己補充說名：程式碼都在一起的時候每次打包釋出，相關的測試活動都會受到影響。
1.2、可擴充套件性差：在高併發場景下，無法以模組為單位靈活擴充套件容量，不利於應用的橫向擴充套件。
1.3、穩定性差：當單體應用中任何一個模組有問題時，都可能會造成應用整體的不可用，缺乏容錯機制。
1.4、可維護性差：隨著業務複雜的提升，程式碼的複雜性也是直線上升，當業務規模比較龐大時，整體專案的可維 護性會大打折扣。
2、微服務架構的特點
2.1、每個服務執行在獨立的程序中，開發採用的技術棧也是獨立的;
2.2、服務間採用輕量級通訊機制進行溝通，通常是基於HTTP協議的RESTful API;
2.3、每個服務都圍繞這具體的業務進行構建，並且能夠被獨立開發、獨立部署、獨立釋出;
2.4、對運維提出了非常高的要求，促進了CI/CD的發展與落地
自己補充說明：專案使用微服務架構後，進行CI/CD整合，在進行打包時每個服務相互依賴時，需要理清打 包順序。
二、微服務下的測試挑戰
1、過於龐大的測試用例數量
1.1、傳統API的測試策略：
- 根據被測API輸入引數的各種組合呼叫API，並驗證相關結果的正確性；
- 衡量上述測試過程的程式碼覆蓋率；
- 根據程式碼覆蓋率進一步找出遺漏的測試用例；
- 以程式碼覆蓋率達標作為API測試成功完成的標誌
1.2、當採用微服務架構時，原本的單體應用會被拆分成多個獨立模組，也就是很多個獨立的service，這樣原來的工作量就會增加很多，在網際網路現在的模式下，往往都是推行"敏捷"化，所以對測試發起的挑戰是巨大的，這時就會迫切需要找到一種既能保證API質量，又能減少測試用例數量的測試策略，(作者後面要分享的是：基於消費者契約的API測試)。【備註：對原文進行了簡化】
2、微服務之間的耦合關係
2.1、上面有提到契約測試，契約的本質就是Request和Response的組合，具體的表現形式往往是JSON檔案，此時我們就可以用該契約的JSON檔案作為Mock Service的依據，也就是在收到什麼Request的時候應該回復什麼Response。
補充：教程中的示例和圖解沒有就沒有這這裡記錄啦！
三、程式碼例項及文件中涉及的名詞解讀
1、程式碼例項：https://github.com/SpectoLabs/spring-cloud-contract-blog
1.1、例項說明：
基於Spring Boot實現了兩個微服務：訂閱服務(subscription-service)和賬戶服務(account-service)，其中訂閱服務會呼叫賬戶服務。
2、詳細程式碼解讀：https://specto.io/blog/2016/11/16/spring-cloud-contract/
3、名詞解讀
a、API Gateway 的元件，用於記錄所有 API 之間相互呼叫關係的日誌
評論摘選： api gateway一般是作為整個微服務的入口，做一些許可權校驗，路由功能，服務間的內部調 用不走api gateway。spring cloud的例子 zuul作為api gateway，load balancer是 ribbon。要去抓取呼叫記錄在被測服務記錄訪問日誌。這個作為audit log本來就是要記錄 的。我們的契約測試是呼叫放手寫在被呼叫服務，擁有者是呼叫方。以此來確保api的兼 容。
b、程式碼級覆蓋率統計工具：Java語言使用jacoco，
參考地址：https://www.jacoco.org/jacoco/trunk/index.html
https://cloud.tencent.com/developer/article/1038055
c、mock工具：
Mockito：官網： http://mockito.org
API文件：http://docs.mockito.googlecode.com/hg/org/mockito/Mockito.html
專案原始碼：https://github.com/mockito/mockito
介面測試Mock工具：Yapi:https://hellosean1025.github.io/yapi/
說明：教程來源極客時間--軟體測試52講，作者：茹炳晟
喜歡的朋友可以去訂閱學習，我這裡的僅作為學習記錄，跟著教程記錄主要內容