一、API 測試的基本步驟

通常來講,API 測試的基本步驟主要包括以下三大步驟：

創(chuàng)新互聯(lián)2013年開創(chuàng)至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務公司，擁有項目成都網(wǎng)站建設、網(wǎng)站制作網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元道縣做網(wǎng)站,已為上家服務,為道縣各地企業(yè)和個人服務,聯(lián)系電話:18982081108

1、準備測試數(shù)據(jù)；

2、通過通用的或自己開發(fā)的API測試工具發(fā)起對被測API的request；

3、驗證返回結(jié)果的response。

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

二、API復雜場景舉例

通過使用基礎(chǔ)的測試工具，可以做簡單場景的API測試；而項目進行過程中，為了解決實際的一些問題，我們會設計更加復雜的測試場景，下面列舉幾個實際項目中的典型場景。

場景一：API串聯(lián)調(diào)用

以協(xié)議支付為例，我們知道，三方公司接入網(wǎng)聯(lián)后，用協(xié)議支付取代代扣，而協(xié)議支付的流程中需要用戶輸入銀行返回的驗證碼完成綁卡。從接口層面上看，順序是先調(diào)用協(xié)議簽約API，返回狀態(tài)成功且獲取到短信驗證碼后，再使用此短信驗證碼作為輸入?yún)?shù)調(diào)用代扣API。協(xié)議簽約和代扣兩個API是順序調(diào)用，而且在兩次調(diào)用中間有獲取手機上的短信驗證碼，這些過程都需要通過程序自動化實現(xiàn)以提高效率。

場景二：API接口加密

為保證API接口安全，系統(tǒng)間和系統(tǒng)內(nèi)模塊間互相訪問需要進行加密處理，常用的加密方式有DES、AES、RSA、MD5等，各系統(tǒng)的加密方式并不一樣（接口調(diào)用方和接口提供方約定好即可），意味著API測試需要支持多種自動化加密方式程。某些系統(tǒng)還會返回加密的響應報文，也需要識別并解密。

場景三：異步API測試

異步API指請求發(fā)出后后收到一個同步響應，但并不是最終處理結(jié)果，最終結(jié)果通過回調(diào)或者主動查詢獲得。對于這樣的API，同步響應的驗證只是第一步，后續(xù)還得繼續(xù)驗證DB中的值、MQ中的值、以及異步回調(diào)是否成功等。對于異步回調(diào)，我們可以模擬回調(diào)地址來驗證成功與否；而對于主動查詢，我們就得通過查看DB中的狀態(tài)值來驗證了，但是查詢到結(jié)果的時間點不確定，幾分鐘到幾小時都有可能，這就得有一個定時DB查詢?nèi)蝿杖ヲ炞C。

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

APIA調(diào)用APIB且B不可用，此時如何測試APIA需要考慮。比如支付系統(tǒng)對三方支付通道、對銀行的依賴，并不是所有的三方都支持測試環(huán)境，解決此問題的核心思路是搭建MockServer，而且盡量做到通用性，我們開發(fā)了一套Mock系統(tǒng) -aMock，通過頁面錄入接口信息，保存在數(shù)據(jù)庫內(nèi)，通過Nginx訪問配置好的Mock接口，后臺統(tǒng)一處理請求信息，然后通過URL和報文特性去匹配特定的響應信息。

三、API測試平臺

我們的API測試平臺是要基于業(yè)務場景的，即要支持各業(yè)務的共性需求，又要針對不同業(yè)務的個性特點加以開發(fā)來豐富API測試能力；而且，對用例也要有很好的規(guī)劃，結(jié)果有清楚的展示，測試平臺架構(gòu)如下圖：

BIT：業(yè)務接口測試（BusinessInterfaceTest）

SUT：被測系統(tǒng)（SystemUnderTest）

TestCaseManagement：測試用例管理，包括從測試用例到測試用例集，再到測試任務的數(shù)據(jù)關(guān)系的建立和維護。測試用例是最小單位，測試用例集是從某一維度對用例進行的歸集，測試任務即測試執(zhí)行，可立即觸發(fā)也可定時執(zhí)行，只能執(zhí)行測試用例集。

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

Validator：接口響應字段和數(shù)據(jù)庫字段的驗證封裝。

RiskManagement：風控處理，因為會涉及支付真實資金，需要內(nèi)置風控規(guī)則來保證資金安全，風險可控。

Timer：定時任務服務，包括

• 串聯(lián)API用例中，前置用例的狀態(tài)判斷；

• 異步API的數(shù)據(jù)庫校驗；

• 超時API用例的失效狀態(tài)判斷；

• 定時執(zhí)行的任務計劃。

MockServer：用例依賴的外部系統(tǒng)Mock服務。

Portal：API測試平臺門戶網(wǎng)站，包括測試用例的錄入，維護，測試任務的執(zhí)行，結(jié)果查看，導出等都通過門戶進行操作。

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

目前API測試平臺上各項目維護用例總結(jié)1200多條，以回歸用例為主，且還在不斷增加中，隨著用例的不斷添加，平臺也歷經(jīng)了一系列優(yōu)化，下面就談談這個過程中的一些思考。

四、測試數(shù)據(jù)準備

對于大量API用例的執(zhí)行，需要數(shù)據(jù)驅(qū)動測試，也就是說可以將測試數(shù)據(jù)和測試代碼分離解耦，這樣便于測試數(shù)據(jù)的維護同時也保證了數(shù)據(jù)的準確性，用例設計格式是這樣

${accountName}
${accountNo}
${identNo}

幾個關(guān)鍵數(shù)據(jù)節(jié)點由DataProvider提供，為了增加測試覆蓋度，數(shù)據(jù)庫相似的測試數(shù)據(jù)有多條，比如多條四要素（銀行卡號、手機號、身份證號、姓名）數(shù)據(jù)，當大量用例需要讀取時，可采用緩存方式存儲并讀取到cList里面，通過循環(huán)遍歷，使每條測試數(shù)據(jù)都可以被均勻讀取，下面是替換關(guān)鍵數(shù)據(jù)節(jié)點的一段代碼，將cList數(shù)據(jù)依次賦給對應變量。

五、測試執(zhí)行的邏輯控制

很多情況下的測試是場景化API測試，涉及用例的順序調(diào)用。如下圖，“簽約-成功-kftn-協(xié)議”依賴于“簽約-成功-kftn短信”的執(zhí)行；在添加用例時配置好關(guān)聯(lián)關(guān)系。

執(zhí)行時，會根據(jù)用例屬性將此兩條依據(jù)有無前置條件劃分為兩類，分別存放于兩個list里，無前置條件的用例可以馬上執(zhí)行，有前置條件的用例，設置TestStatus為0，等待定時任務輪詢觸發(fā)執(zhí)行。分類執(zhí)行代碼如下圖

定時任務每分鐘執(zhí)行一次，下面一段是判斷前置API的執(zhí)行狀態(tài)，只有“0000”代表成功，當前API才能執(zhí)行，執(zhí)行時，需要讀取前置用例的結(jié)果數(shù)據(jù)并傳入；如果前置API失敗，則停止任務執(zhí)行，多條API用例順序執(zhí)行也是同樣的道理；即使有外部依賴的用例，比如短信驗證碼，我們也可以通過寫一段手機APP程序自動上傳短信驗證碼到服務器，然后觸發(fā)延遲獲取驗證碼，得到后通過DB記錄用例執(zhí)行的狀態(tài)和結(jié)果，并傳給下一個API使用，就完成了多用例的順序執(zhí)行。此外，測試任務的執(zhí)行封裝成restful接口，可以更加靈活地和目前團隊正在開發(fā)中的CICD系統(tǒng)結(jié)合一起。

六、測試結(jié)果的驗證

通過分析業(yè)務，API的結(jié)果校驗大致分為兩種類型，響應校驗和數(shù)據(jù)庫校驗。響應校驗是針對response報文字段的校驗，可精確匹配也可通過正則表達式模糊匹配；數(shù)據(jù)庫校驗是基于定時任務的，需要在用例里面根據(jù)約定格式設置校驗方法，比如下面的sql檢驗條件，會在準生產(chǎn)環(huán)境通過指定單號以及其他條件去查詢返回字段，并判斷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"}

用例狀態(tài)分為成功、失敗、處理中、超時四種狀態(tài)，分別通過配置相應SQL查詢條件去映射，成功和失敗是終態(tài)，處理中則是需要定時任務繼續(xù)查詢，超時，是我們內(nèi)部設定的一個狀態(tài)，目前是超過一個小時未返回終態(tài)設為超時，此API用例失效并報警，需要人工參與查看。所有這些規(guī)則都是在用例建立和編輯的時候添加的，如下圖，一條用例包括了響應校驗（值校驗、key校驗）和數(shù)據(jù)庫校驗，通過這種比較靈活的設計，基本能夠滿足復雜API測試場景。需要指出一點是，很多應用不允許外部測試平臺直接訪問數(shù)據(jù)庫，我們的解決辦法是寫一個數(shù)據(jù)查詢服務部署在系統(tǒng)環(huán)境中，只提供查詢功能，并且有加密驗證保證通訊雙方（測試平臺和數(shù)據(jù)查詢服務之間）可信。

通常來說，測試平臺或框架可以從某種層面上理解為工具鏈的串聯(lián)，開發(fā)此平臺的過程中，我們使用的技術(shù)棧有springmvc+herbinate做邏輯控制、amazingUI做用例管理、echart做結(jié)果展示，還使用Jenkins做任務調(diào)度等，用戶就是各業(yè)務線測試人員，他們不需要了解具體代碼的實現(xiàn)，但是需要對系統(tǒng)結(jié)構(gòu)以及用例規(guī)則有很好的理解，這樣才能設計出符合測試場景的用例。

任何測試平臺的設計還是要基于業(yè)務的，后續(xù)我們對API平臺的推進策略是，繼續(xù)增加場景化功能以支持更多業(yè)務類型的測試，比如清結(jié)算系統(tǒng)中日終、日間的跑批任務，對賬文件的數(shù)據(jù)檢驗等，增加大并發(fā)能力并和性能測試工具相結(jié)合。

作者：孫鷹

來源：宜信技術(shù)學院