隨行付微服務(wù)測試之接口測試和契約測試

背景

日常開(kāi)發(fā)過(guò)程中，項目的接口通常由服務(wù)提供方約定和提供，微服務(wù)模式下接口被多個(gè)消費者調用更是常態(tài)，那么提供方接口的變更如何快速、高效、無(wú)遺漏的通知給消費者呢？另外，當一個(gè)service同時(shí)被多個(gè)使用者調用，如何保證對service的修改可以讓其它所有使用者造成的影響都能被感知到？這些問(wèn)題契約測試可以給你答案。另外，微服務(wù)模式下，接口測試是非常重要的測試手段，它在實(shí)際的項目中幫助驗證微服務(wù)之間的協(xié)同和交互，大幅降低測試成本和提高測試效率方面提供了很大幫助，可以說(shuō)接口測試是業(yè)務(wù)功能測試前置的助推器。因此，這里對這兩種測試手段進(jìn)行介紹。

接口測試和契約測試所處的階段

在實(shí)際的工作中，結合隨行付的實(shí)際情況我們對自動(dòng)化測試金字塔原理進(jìn)行了定制，加入契約自動(dòng)化測試內容，形成如下新版自動(dòng)化測試金字塔結構。

由圖可知，一個(gè)項目的測試過(guò)程，從項目推進(jìn)的維度，首先進(jìn)行單元測試，其次接口自動(dòng)化測試、契約測試，最后UI自動(dòng)化測試和手工測試。

微服務(wù)模式下如何開(kāi)展接口測試

接口測試屬于集成測試范疇，他是單元測試的擴展和延續。它主要的關(guān)注點(diǎn)是內部接口功能實(shí)現是否完整，比如說(shuō)內部邏輯是不是正常，異常處理是不是正確。它是單元測試和契約測試的過(guò)渡階段，它是項目單個(gè)代碼邏輯最終串聯(lián)形成有價(jià)值業(yè)務(wù)邏輯的橋梁。因此，其作用舉足輕重。隨行付開(kāi)展接口測試，采用的思路是規范和方法先行，其次是工具選擇、人員培訓，然后是實(shí)施和過(guò)程優(yōu)化，最后常態(tài)化持續提效和質(zhì)量保證的過(guò)程。

接口測試規范化要求

接口測試的質(zhì)量保證和測試過(guò)程的流程化需要通過(guò)規范和方法進(jìn)行指導和約束。我們定制了如下要求（部分內容）：

1.需求存在新增接口或者接口變更時(shí)，要求進(jìn)行新增接口測試案例的編寫(xiě)或存量接口案例的維護；

2.需求涉及到的存量接口需要進(jìn)行回歸測試；

3.接口測試覆蓋率要求達到100%；

4.需求測試結束前至少進(jìn)行一輪接口回歸測試，且回歸通過(guò)率達到100%

測試流程規范涉及從需求提出、腳本編寫(xiě)、執行到測試報告的各個(gè)過(guò)程。

1.接口文檔。接口文檔是接口測試案例設計的依據，接口文檔的全面性和準確性決定了接口測試范圍的全面性和接口測試結果的正確性、有效性。隨行付采用swagger進(jìn)行接口文檔管理。

2.接口用例設計。根據接口文檔設計接口測試案例，接口測試案例通過(guò)接口測試平臺進(jìn)行編寫(xiě)，且需要滿(mǎn)足不重不漏原則。

3.接口用例評審。根據項目實(shí)際情況，接口測試案例編寫(xiě)完成后，需組織相關(guān)干系人進(jìn)行案例評審，記錄并發(fā)送會(huì )議紀要。

4.接口用例執行。需求測試結束前接口測試案例至少在測試環(huán)境中執行了一次回歸測試，要求案例執行通過(guò)率達到100%

5.缺陷管理和測試報告。

6.腳本納入回歸體系，定時(shí)回歸，持續保障接口的質(zhì)量，以及接口質(zhì)量的持續和及時(shí)反饋。

腳本命名規范和編寫(xiě)規范如下（部分內容）：

1.接口命名要求：采用“接口名稱(chēng)_接口描述”進(jìn)行命名，用于定義唯一接口。

2.方法命名要求：采用“方法名_描述”進(jìn)行命名，用于定義唯一方法。

3.案例命名要求：采用“序號_場(chǎng)景操作_期望結果”進(jìn)行命名，用于定義唯一案例。

4.【強制】每個(gè)接口測試案例都必須包含至少一個(gè)斷言；

5.【強制】對于json格式的報文，接口入參和斷言響應的預期值需要使用嚴格的json格式；

6.【強制】swagger腳本導入到接口測試平臺時(shí)，需要導入.json文件，且文件內容為無(wú)BOM的UTF-8編碼；

7.【強制】數據初始化和斷言的sql必須帶where條件，且能唯一定位到期望的數據；

8.【強制】數據庫回退的sql必須帶where條件，且能唯一定位到需要回退的數據；

9.【強制】影響公共表（如：T_BAP_CDE_BNK表）或者其他組數據庫表（如：資金組）的sql，在數據初始化、回退、接口影響的數據回退、斷言回退時(shí)必須嚴格審查；

10.【強制】數據庫斷言sql中的where條件的主鍵組合需要放到前面，用于斷言失敗時(shí)快速定位問(wèn)題；

接口測試用例設計要求

為了保證接口的質(zhì)量，需要進(jìn)行全面的接口測試，因此在涉及接口測試用例時(shí)需要依賴(lài)方法，因此我們總結了接口測試用例的設計要求，如下圖所示。

接口測試工具

接口測試過(guò)程提效、測試過(guò)程自動(dòng)化需要依賴(lài)自動(dòng)化測試工具，武器不好很難打勝仗。經(jīng)過(guò)調研，市面上很多接口自動(dòng)化測試工具均無(wú)法滿(mǎn)足所有的測試要求，因此我們自研了接口自動(dòng)化測試平臺。自動(dòng)化測試平臺具有如下能力：

1.案例自動(dòng)生成。http/https接口案例自動(dòng)化生成和導入。

2.測試過(guò)程集中可視化管理。通過(guò)將自動(dòng)化測試過(guò)程web化實(shí)現了自動(dòng)化測試計劃、自動(dòng)化測試用例編寫(xiě)、自動(dòng)化測試用例執行、自動(dòng)化測試用例管理和自動(dòng)化測試報告管理各個(gè)過(guò)程的可視化。

3.模擬性能場(chǎng)景。自動(dòng)化測試實(shí)現了通過(guò)接口案例模擬性能測試場(chǎng)景的能力。通過(guò)使用平臺中提供的接口案例，進(jìn)行并行執行模擬性能場(chǎng)景。

4.多協(xié)議多報文類(lèi)型支持。支持http/https協(xié)議、dubbo協(xié)議、socket協(xié)議、rabbitMQ協(xié)議等協(xié)議的自動(dòng)化測試，并支持對協(xié)議的擴展。同時(shí)支持xml、json、sop、8583等多種報文類(lèi)型以及報文類(lèi)型的擴展。

5.測試資產(chǎn)有效積累。

6.自動(dòng)化調度執行和郵件發(fā)送。自動(dòng)化測試執行通過(guò)定時(shí)對案例進(jìn)行調度執行，可對指定的構建版本對應的案例進(jìn)行自動(dòng)化的分批、定時(shí)調度執行并郵件發(fā)送測試報告。

7.系統質(zhì)量的可視化反饋。通過(guò)對自動(dòng)化案例的執行結果統計，分析出系統的質(zhì)量趨勢，做到系統質(zhì)量的持續化反饋。通過(guò)根因分析，統計系統問(wèn)題的根本原因的比例，更有針對性的解決質(zhì)量問(wèn)題。

通過(guò)接口測試持續運行1年多的持續運營(yíng)，隨行付核心業(yè)務(wù)接口基本實(shí)現接口測試用例全覆蓋，且均納入到定期回歸過(guò)程，持續為接口的質(zhì)量保駕護航。

微服務(wù)模式下如何開(kāi)展契約測試

契約測試的價(jià)值

契約測試分兩種類(lèi)型，一種是消費者驅動(dòng)，一種是提供者驅動(dòng)。其中最常用的，是消費者驅動(dòng)的契約測試（Consumer-Driven Contract Test，簡(jiǎn)稱(chēng) CDC）。核心思想是從消費者業(yè)務(wù)實(shí)現的角度出發(fā)，由消費者端定義需要的數據格式以及交互細節，生成一份契約文件。然后生產(chǎn)者根據契約文件來(lái)實(shí)現自己的邏輯，并在持續集成環(huán)境中持續驗證該實(shí)現結果是否正確。對于基于Restful API的微服務(wù)來(lái)說(shuō)，它的契約就是指 API 的請求和響應的規則。 如下圖所示：

對于請求，包括請求 URL 及參數，請求頭，請求內容等；

對于響應，包括狀態(tài)碼，響應頭，響應內容等。

對于元數據，指對消費者與提供者間一次協(xié)作過(guò)程的描述。譬如消費者/提供者的名稱(chēng)、上下文及場(chǎng)景描述等。

那么契約測試能給微服務(wù)帶來(lái)什么價(jià)值呢？文章開(kāi)頭已經(jīng)提到了契約測試的一部分價(jià)值，即接口變更快速通知，servise修改的快速感知。除此之外，它還帶來(lái)下列價(jià)值：

1.降低服務(wù)集成的難度。把服務(wù)集成這個(gè)過(guò)程分解成了更細的單元測試和接口測試，它從消費者的需求為出發(fā)點(diǎn)，把消費者的需求作為測試用例驅動(dòng)實(shí)現一份契約，然后驗證提供者端的功能。

2.開(kāi)發(fā)并行，提高開(kāi)發(fā)效率。契約隔離了消費者和提供者，雙方可以并行開(kāi)展工作，開(kāi)發(fā)過(guò)程中就利用契約進(jìn)行預集成測試，不用等到聯(lián)調再來(lái)集成調通接口，一旦成熟，在保證質(zhì)量的前提下，聯(lián)調的成本可以減低到幾乎為0。

3.確保變動(dòng)的安全性和準確性。只要有變化，契約測試即可第一時(shí)間發(fā)現，保證安全和對接的準確性。

4.作為Mock server為消費者提供Mock服務(wù)。集成測試為服務(wù)者提供

微服務(wù)下如何開(kāi)展契約測試

隨行付采用在Spring Cloud Contract開(kāi)展契約測試。其核心流程包括2步：

1.對消費者的業(yè)務(wù)邏輯進(jìn)行驗證時(shí)，先對其期望的響應做模擬提供者（Mock）；并將請求（消費者）-響應（基于模擬提供者）的協(xié)作過(guò)程，記錄為契約；

2.通過(guò)契約，對提供者進(jìn)行回放，保證提供者所提供的內容滿(mǎn)足消費者的期望。

下面用一個(gè)簡(jiǎn)單的例子說(shuō)明設計契約測試的方法。這個(gè)例子中，一個(gè)微服務(wù)提供了一個(gè)包含三個(gè)字段（“IP”、“name”和“password”）的資源，供三個(gè)消費者微服務(wù)使用。這三個(gè)微服務(wù)分別使用這個(gè)資源中的不同部分。消費者 A 使用其中的 IP 和 name 這兩個(gè)字段。因此，測試腳本中將只驗證來(lái)自提供者的資源中是否正確包含這兩個(gè)字段，而不需要驗證 password 字段。消費者 B 使用 IP 和 password 字段，而不需要驗證 name 字段。消費者 C 則需要確認資源中包含了所有這三個(gè)字段?，F在，如果提供者需要將 name 分為姓（first name）和名（last name），那么就需要去掉原有的 name 字段，加入新的 first name 字段和 last name 字段。這時(shí)執行契約測試，就會(huì )發(fā)現消費者 A 和 C 的測試用例就會(huì )失敗。測試用例 B 則不受影響。這意味著(zhù)消費者 A 和 C 服務(wù)的代碼需要修改，以兼容更新之后的提供者。修改之后，還需要對契約內容進(jìn)行更新。

下面以一個(gè)例子介紹如何使用Spring Cloud Contract開(kāi)展契約測試的。

Spring Cloud Contract契約是用基于Groovy的DSL定義的，下面是一個(gè)契約測試的代碼段

服務(wù)方-server (HTTP) / producer (Messaging) 端增加Spring Cloud Contract Verifier的gralde插件，它用于解析契約文件生成測試。生成測試的命令。

下面是自動(dòng)生成的測試腳本

這個(gè)一個(gè)標準的JUnit測試,用RestAssured來(lái)啟動(dòng)Spring的webApplicationContext。

調用方-在服務(wù)方通過(guò)命令生成Stub服務(wù)的Jar包

Spring Cloud Contract Stub Runner在集成測試中通過(guò)運行WireMock實(shí)例或者消息路由模擬真實(shí)的服務(wù)。 因此在運行之前，需要將依賴(lài)加入到gralde中,當然可以把他加到私服倉庫中。

對于調用方,Spring Cloud Contract提供了Stub Runner來(lái)簡(jiǎn)化Stub的使用?，F在可以使用@AutoConfigureStubRunner注解.為了Spring Cloud Contract Stub Runner運行stubs注解中增加了group-id和artifact-id，舉例如下：

注解AutoConfigureStubRunner，里面設置了下載Stub Jar包的私庫地址以及包的完整 ID，最后的6565就是指定Stub運行的本地端口。測試的時(shí)候訪(fǎng)問(wèn)Stub端口，就會(huì )根據契約返回內容。

由于隨行付微服務(wù)是基于spring cloud技術(shù)棧，因此采用spring cloud contract進(jìn)行微服務(wù)下的契約測試使得測試過(guò)程更流暢，更順利，同時(shí)Spring Cloud Contract和SpringBoot以及 Junit的集成更簡(jiǎn)單方便。相信隨著(zhù)spring cloud contract版本的優(yōu)化，契約測試可以做的更好。

總結

在微服務(wù)模式下，服務(wù)間的調用關(guān)系復雜，接口測試和契約測試是保證服務(wù)提高質(zhì)量的重要手段，因此要充分利用。

原文轉自：http://www.uml.org.cn/test/201812201.asp