宜信支付結算系統API自動化測試實踐

API 測試的基本步驟

一般來說,API 測試的基本步驟主要包括如下三大步驟：

一、準備測試數據；

二、經過通用的或本身開發的API測試工具發起對被測API的request；

三、驗證返回結果的response。

經常使用的API測試工具備命令行工具cURL、圖形界面工具Postman或SoapUI，支持API性能測試的JMeter等。

API複雜場景舉例

經過使用基礎的測試工具，能夠作簡單場景的API測試；而項目進行過程當中，爲了解決實際的一些問題，咱們會設計更加複雜的測試場景，下面列舉幾個實際項目中的典型場景。

場景一：API串聯調用

以協議支付爲例，咱們知道，三方公司接入網聯後，用協議支付取代代扣，而協議支付的流程中須要用戶輸入銀行返回的驗證碼完成綁卡。從接口層面上看，順序是先調用協議簽約API，返回狀態成功且獲取到短信驗證碼後，再使用此短信驗證碼做爲輸入參數調用代扣API。協議簽約和代扣兩個API是順序調用，並且在兩次調用中間有獲取手機上的短信驗證碼，這些過程都須要經過程序自動化實現以提升效率。

場景二：API接口加密

爲保證API接口安全，系統間和系統內模塊間互相訪問須要進行加密處理，經常使用的加密方式有DES、AES、RSA、MD5等，各系統的加密方式並不同（接口調用方和接口提供方約定好便可），意味着API測試須要支持多種自動化加密方式程。某些系統還會返回加密的響應報文，也須要識別並解密。

場景三：異步API測試

異步API指請求發出後後收到一個同步響應，但並非最終處理結果，最終結果經過回調或者主動查詢得到。對於這樣的API，同步響應的驗證只是第一步，後續還得繼續驗證DB中的值、MQ中的值、以及異步回調是否成功等。對於異步回調，咱們能夠模擬回調地址來驗證成功與否；而對於主動查詢，咱們就得經過查看DB中的狀態值來驗證了，可是查詢到結果的時間點不肯定，幾分鐘到幾小時都有可能，這就得有一個定時DB查詢任務去驗證。

場景四：API測試中的外部依賴

APIA調用APIB且B不可用，此時如何測試APIA須要考慮。好比支付系統對三方支付通道、對銀行的依賴，並非全部的三方都支持測試環境，解決此問題的核心思路是搭建MockServer，並且儘可能作到通用性，咱們開發了一套Mock系統 -aMock，經過頁面錄入接口信息，保存在數據庫內，經過Nginx訪問配置好的Mock接口，後臺統一處理請求信息，而後經過URL和報文特性去匹配特定的響應信息。

API測試平臺

咱們的API測試平臺是要基於業務場景的，即要支持各業務的共性需求，又要針對不一樣業務的個性特色加以開發來豐富API測試能力；並且，對用例也要有很好的規劃，結果有清楚的展現，測試平臺架構以下圖：

 

BIT：業務接口測試（BusinessInterfaceTest）

SUT：被測系統（SystemUnderTest）

TestCaseManagement：測試用例管理，包括從測試用例到測試用例集，再到測試任務的數據關係的創建和維護。測試用例是最小單位，測試用例集是從某一維度對用例進行的歸集，測試任務即測試執行，可當即觸發也可定時執行，只能執行測試用例集。

Util：工具類封裝，主要提供數據加解密，數據類型轉換，配置文件讀寫，數據字典的緩存服務等。

Validator：接口響應字段和數據庫字段的驗證封裝。

RiskManagement：風控處理，由於會涉及支付真實資金，須要內置風控規則來保證資金安全，風險可控。

Timer：定時任務服務，包括

1）串聯API用例中，前置用例的狀態判斷；

2）異步API的數據庫校驗；

3）超時API用例的失效狀態判斷；

4）定時執行的任務計劃。

MockServer：用例依賴的外部系統Mock服務。

Portal：API測試平臺門戶網站，包括測試用例的錄入，維護，測試任務的執行，結果查看，導出等都經過門戶進行操做。

DB：存儲測試用例數據以及相應的測試任務、測試報告數據，還有項目配置等。

目前API測試平臺上各項目維護用例總結1200多條，以迴歸用例爲主，且還在不斷增長中，隨着用例的不斷添加，平臺也歷經了一系列優化，下面就談談這個過程當中的一些思考。

測試數據準備

對於大量API用例的執行，須要數據驅動測試，也就是說能夠將測試數據和測試代碼分離解耦，這樣便於測試數據的維護同時也保證了數據的準確性，用例設計格式是這樣

<accountName>${accountName}</accountName>

<accountNo>${accountNo}</accountNo>

<identNo>${identNo}</identNo>

幾個關鍵數據節點由DataProvider提供，爲了增長測試覆蓋度，數據庫類似的測試數據有多條，好比多條四要素（銀行卡號、手機號、身份證號、姓名）數據，當大量用例須要讀取時，可採用緩存方式存儲並讀取到cList裏面，經過循環遍歷，使每條測試數據均可以被均勻讀取，下面是替換關鍵數據節點的一段代碼，將cList數據依次賦給對應變量。

 

測試執行的邏輯控制

不少狀況下的測試是場景化API測試，涉及用例的順序調用。以下圖，「簽約-成功-kftn-協議」依賴於「簽約-成功-kftn短信」的執行；在添加用例時配置好關聯關係。

 

執行時，會根據用例屬性將此兩條依據有無前置條件劃分爲兩類，分別存放於兩個list裏，無前置條件的用例能夠立刻執行，有前置條件的用例，設置TestStatus爲0，等待定時任務輪詢觸發執行。分類執行代碼以下圖

 

定時任務每分鐘執行一次，下面一段是判斷前置API的執行狀態，只有「0000」表明成功，當前API才能執行，執行時，須要讀取前置用例的結果數據並傳入；若是前置API失敗，則中止任務執行，多條API用例順序執行也是一樣的道理；即便有外部依賴的用例，好比短信驗證碼，咱們也能夠經過寫一段手機APP程序自動上傳短信驗證碼到服務器，而後觸發延遲獲取驗證碼，獲得後經過DB記錄用例執行的狀態和結果，並傳給下一個API使用，就完成了多用例的順序執行。此外，測試任務的執行封裝成restful接口，能夠更加靈活地和目前團隊正在開發中的CICD系統結合一塊兒。

 

測試結果的驗證

經過分析業務，API的結果校驗大體分爲兩種類型，響應校驗和數據庫校驗。響應校驗是針對response報文字段的校驗，可精確匹配也可經過正則表達式模糊匹配；數據庫校驗是基於定時任務的，須要在用例裏面根據約定格式設置校驗方法，好比下面的sql檢驗條件，會在準生產環境經過指定單號以及其餘條件去查詢返回字段，並判斷status是否爲7，從而判斷用例是否成功。

PreOnline.3|,|SELECTtb.outer_batch_no,tb.status,bs.send_statusFROM

bs_outpay.trans_batchtbleft joinbs_outpay.es_business_sendbsontb.business_batch_no=bs.entity_uuidandbs.entity_status<>2 WHEREtb.outer_batch_noin (?) order bytb.CREATED_TIMEDESC|,|{"status":"7"}

用例狀態分爲成功、失敗、處理中、超時四種狀態，分別經過配置相應SQL查詢條件去映射，成功和失敗是終態，處理中則是須要定時任務繼續查詢，超時，是咱們內部設定的一個狀態，目前是超過一個小時未返回終態設爲超時，此API用例失效並報警，須要人工參與查看。全部這些規則都是在用例創建和編輯的時候添加的，以下圖，一條用例包括了響應校驗（值校驗、key校驗）和數據庫校驗，經過這種比較靈活的設計，基本可以知足複雜API測試場景。須要指出一點是，不少應用不容許外部測試平臺直接訪問數據庫，咱們的解決辦法是寫一個數據查詢服務部署在系統環境中，只提供查詢功能，而且有加密驗證保證通信雙方（測試平臺和數據查詢服務之間）可信。

 

一般來講，測試平臺或框架能夠從某種層面上理解爲工具鏈的串聯，開發此平臺的過程當中，咱們使用的技術棧有springmvc+herbinate作邏輯控制、amazingUI作用例管理、echart作結果展現，還使用Jenkins作任務調度等，用戶就是各業務線測試人員，他們不須要了解具體代碼的實現，可是須要對系統結構以及用例規則有很好的理解，這樣才能設計出符合測試場景的用例。

任何測試平臺的設計仍是要基於業務的，後續咱們對API平臺的推動策略是，繼續增長場景化功能以支持更多業務類型的測試，好比清結算系統中日終、日間的跑批任務，對帳文件的數據檢驗等，增長大併發能力並和性能測試工具相結合。

-END-

做者：孫鷹 來源：宜信技術學院：http://college.creditease.cn/#/index