API 測試的基本步驟
通常來講,API 測試的基本步驟主要包括以下三大步驟:
1、準備測試資料;
2、通過通用的或自己開發的API測試工具發起對被測API的request;
3、驗證返回結果的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-