微服務測試是很有挑戰性的，為什么這樣說呢？原因有以下幾點：

結果不穩定， 分布式系統，服務之間的通信都是通過網絡調用，然而在網絡上傳送，都會面臨網絡延時、超時、帶寬等因素，容易導致不穩定的測試結果。

驗證成本高，為了驗證多個服務協作后的功能正確與否，需要為每個服務搭建基礎設施(包括數據庫、緩存等)，并執行部署、配置等步驟，以確保服務能正確運行。

反饋周期長， 相比單體應用而言，微服務架構下，可獨立部署的單元多，因此集成測試的反饋周期比之前會更長，定位問題的時間就會更久。

溝通成本高， 微服務常由不同團隊開發并維護，當服務頻繁進行改動和版本升級的時候，很容易導致不兼容，加大團隊之間的溝通成本。

測試金字塔

測試金字塔很好的幫助我們在制定測試策略的時候，區分不同層次測試關注點，同時，一般來說，測試顆粒度越粗，越脆弱，執行的時間越長，維護成本也越高。

不得不說的契約測試

在微服務中，不得不聊聊消費者契約測試，

契約，一種定義在Consumer與Provider之間的交互方式

消費者驅動的契約測試

契約是Consumer和Provider團隊之間達成的交互協議，更多的看中的是請求和響應的Payload結構(Schema)，由服務消費者構建并生成contract，然后將contact上傳到Pact broker or server; 對應的服務提供者，需要在Pipeline中，有一個task進行契約的驗證，保證契約不會被破壞。

契約測試的好處

測試分層，Consumer和Provider分別測試。

測試前移，為Consumer提供Mock，不需要真實的集成環境，穩定性高。

反饋周期短，單元測試級別，測試運行快，毫米級。

溝通成本底

為服務消費者提供了信心，更為服務提供者提供了更大的價值(通過與不同消費者約定的契約，可以保證服務安全的升級變遷，不會破壞之前已有的功能)

契約測試的應用場景

一個服務需要被多個消費者使用，每個消費者的訴求并不完全一樣(一對一的場景，沒有太大意義)。

服務消費者與服務提供者由不同的團隊開發維護。

服務消費者與服務提供者，一定要對契約達成一致，并一直保持這種約束(如果有一方沒有遵守，比如提供者根本不將契約驗證集成到流水線中，那么就沒有任何意義)，契約的不符合預期的變化應當會造成測試的失敗。

應該關注

檢查Consumer構建的請求是否匹配到了對應的Contract

檢查Provider的響應是否滿足Consumer的需要

不應該關注

Provider的業務邏輯是否正確

Consumer的處理響應的邏輯

可參考的工具： Pact, Spring Cloud Contract等

不得不說的集成測試

集成測試驗證服務或者組件之間的連通性和交互以檢查接口缺陷，集成測試旨在通過集成不同的Downstream服務，來覆蓋基本的成功和錯誤的場景，在我們項目中，選用REST Assured作為集成測試工具，使用非常方便:

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@AutoConfigureRestDocs
public class UserDocumentationTests {
    @LocalServerPort
    private int port;
    @Autowired
    private RequestSpecification documentationSpec;

    @Test
    public void listUsers() {
        given(this.documentationSpec).filter(document("list-users")).when()
                .port(this.port).get("/").then().assertThat().statusCode(is(200));
    }
}

當downstream服務非常不穩定的時候，我們會通過wiremock作為proxy對請求和響應進行錄制，使用wiremock做測試替身，隔離外部調用，避免多服務間的復雜情況(網絡，其他團隊服務可用性等)，并以可重復的方式模擬任何場景(超時，Down機，SSL驗證失敗，丟失HTTP頭，請求響應不匹配等)，運行穩定，且反饋周期短。

以上就是動力節點小編介紹的"不得不說的微服務測試"，希望對大家有幫助，想了解更多可查看Java教程。動力節點在線學習教程，針對沒有任何Java基礎的讀者學習,讓你從入門到精通,主要介紹了一些Java基礎的核心知識，讓同學們更好更方便的學習和了解Java編程，感興趣的同學可以關注一下。