不用寫程式碼，也能做好介面測試

隔壁王書發表於2018-10-10

本文你將瞭解到

1、介面測試基本概念，包含什麼是介面，什麼是介面測試，為什麼要做介面測試 2、介面測試用例設計 3、怎樣不用寫程式碼，也能快速的根據開發的API文件完成介面自動化測試指令碼

注：如果你對介面基本概念和介面測試用例已熟悉，可以直接跳過，其實看一遍也無防，就當作溫故知新了。

適合本文人群

1、之前學習介面測試從入門到放棄的初級測試工程師

2、想快速完成介面測試指令碼編寫的測試工程師（強烈推薦）

3、因某種原因（比如公司沒有專職測試人員），需要自己寫介面測試指令碼的開發人員（強烈推薦）

一、介面測試基本概念

首先了解被測試物件：介面

介面是指外部系統與系統之間以及內部各子系統之間的互動點。

包括外部介面、內部介面，內部介面又包括：上層服務與下層服務介面（比如serivce層呼叫DAO層介面）、同級介面（比如使用者註冊，會先呼叫查詢使用者資訊的介面，檢視該使用者是否已經註冊）。

不管是內部介面還是外部介面，一般是以API形式出現，通常在規範的API介面文件中，應該包含：介面描述、介面URL、請求方式、請求引數、引數型別、引數含義說明、取值限制、是否必填、返回引數、成功與失敗示例等。

然後瞭解對介面進行的測試活動：介面測試

廣義的理解介面測試就是，對模組或系統間介面進行測試；

狹義的理解介面測試就是，對介面的入參、介面處理邏輯、設計的返回內容進行測試。

介面測試形式：單個介面測試（包含效能測試）和通過介面呼叫進行場景測試。

介面測試原理：通過工具或自己擼程式碼，模擬客戶端（根據測試用例定義請求引數）向伺服器端請求訪問介面，檢查伺服器端返回內容是否與預期值一致。

介面測試流程（僅指迭代中的流程）：需求評審 -> 介面定義 -> 用例設計 -> 指令碼編寫 -> 執行指令碼 -> 結果分析

最後瞭解做介面測試的意義，即：為什麼要做介面測試

簡單來說就是，降低測試成本，提高開發效率。

充分來說就是:

1、介面測試相對容易實現自動化持續整合。

2、介面測試能讓測試提早介入，發現潛在問題；保證介面質量，提高前後端聯調開發效率。

3、介面測試進行安全驗證比較容易：前後端是否統一校驗和敏感資訊列印（介面返回內容中的敏感資訊）是否加密過。

二、介面測試用例設計

這裡只說單個介面測試用例設計，場景介面測試用例設計和UI功能的場景測試用例一樣，只是通過呼叫介面來實現而已。

設計介面測試用例，主要從介面入參、介面處理邏輯、介面返回引數等3個方面入手：

1、設計介面入參測試用例，常見引數型別有：數值、字串、陣列或連結串列、結構體

針對這些型別入參，通常我們通過等價類方法和邊界值方法去設計測試用例

等價類方法：關注取值為範圍內、取值為範圍外的情況；通常會出現取值在範圍外時，介面沒有正確返回錯誤資訊的問題。

邊界值方法：關注取值範圍的邊界值、入參的資料型別邊界值；通常會出現資料型別邊界值溢位問題，比如int型別資料的最大值和最小值時。

為了補充用例，還要考慮特殊值的情況，比如0、空、null、負數、非特定型別值和重複值等；通常會出現介面沒有正確處理邏輯導致異常退出的問題。

2、設計介面處理邏輯測試用例，主要是驗證前後端是否統一校驗

針對介面處理邏輯，通過從以角度分析：

約束條件分析，常見的約束條件：數值限制、狀態限制（登陸狀態）、關係限制（繫結了某種關係）、許可權限制（會員、非會員等）。

操作物件分析，比如專案ID為PJ000屬於使用者A的，訪問這個專案的介面，需要傳專案ID，使用者B傳參時，使用PJ000這的ID時，檢查是否應該不能訪問這個專案。

狀態轉換分析，比如優惠券已使用，是否通過介面仍能使用等情況。

時序分析，比如不按流程順序執行，是否出現資料異常情況。

3、設計介面返回引數測試用例

針對介面處理邏輯，通過從以下角度分析：

返回結果分析，覆蓋所有返回碼。

介面超時分析，介面超時通常會出現，未進行超時處理，導致流程阻塞或超時後，又收到介面返回，導致邏輯出錯。

三、不用寫程式碼，也能做好介面測試：No Code, Still API Test

不用寫程式碼，也能做好介面測試，當然需要藉助神器，才能完成這項工作，這個神器叫做：eolinker，官網 www.eolinker.com

在用eolinker之前，我是用jmeter做介面測試的，用jmeter之前是用python requests，覺得jmeter效率更高，效率高體現在：

1、測試不需要寫程式碼，大家知道測試用程式碼寫測試指令碼跟開發寫產品程式碼一樣，需要編寫-除錯-測試-維護，對於測試來講，需要消耗太多時間和精力，除非公司有專人做測試開發。

2、UI模式，填空就可以，很簡單，最多就是用Beanshell寫少量的函式呼叫或斷言

做介面測試只是用到eolinker的自動化測試功能模組，其他功能去官網註冊賬號後，自行了解，這裡只說下eoLinker 自動化測試功能模組的特點，也是我選用的理由：

1、開發的API文件編寫和測試的介面測試指令碼編寫，可以都在eolinker上進行，所以寫測試指令碼時，可以直接從eolinker的API文件功能模組中，匯入API介面，寫測試指令碼只需新增斷言，和要傳的引數即可。

2、支援UI和Code兩個編寫模式，就是說可以通過UI填空方式完成測試指令碼設計，也可以通過寫JS程式碼，完成測試指令碼設計，官方有教程。

3、呼叫之前介面的返回引數內容，作當前介面的請求引數，eolinker提供了關聯功能，只要點點點就可以完成，比Jmeter還要便捷。

4、還提供比較高階的程式碼注入功能，可以在請求介面前，做一些前置處理，比如請求引數值加密等，也可以把返回內容進行後置處理，比如把介面的返回內容中某個欄位值，設成全域性變數

5、測試結果斷言提供4種方式：Json校驗、XML校驗、完全匹配、正則匹配，用的最多是Json校驗，如果想校驗某個欄位內容，不需寫正則，只要直接要校驗的欄位名就可以了。

6、可以定時執行測試用例，執行完後，傳送測試報告到指定人員郵箱中。

編寫介面測試用例指令碼工作流程：開發編寫API介面文件 -> 匯入開發的API介面，測試根據編寫好的測試用例，編寫測試用例

拿eolinker的一個“新增介面專案介面”測試為例，做以下工作：

1、編寫新增名為“新增介面專案”和“查詢專案列表”API介面文件

2、匯入API介面，編寫“新增專案成功”測試用例：

a. 新增專案，校驗返回碼。

b. 呼叫“查詢專案列表介面”，檢查專案是否成功新增。（像這種新增介面，我以前校驗，用過連線資料庫，然後查表內容，發現執行指令碼的時候，速度有點慢，後來改用呼叫查詢列表介面的方法校驗）

3、執行測試指令碼，檢視測試報告。

Pre 準備

介面1：新增介面專案介面

新增介面專案介面的請求頭

新增介面專案介面的返回內容

介面2：查詢專案列表介面

查詢專案列表介面的請求頭

查詢專案列表介面的返回內容

從上面得到2個介面API文件資訊：

注：實際專案中是有一份開發寫好的API文件，可能是Word上，可能是RAP上，也有可能是在eolinker上，我在這裡只是為了舉例，通過F12取了2個介面的資訊（如下面），寫了2個不完整的API文件作為本文的操作示例。

介面1：新增介面專案介面

介面URL：www.eolinker.com/apiManageme…

請求方法：POST

請求引數：

companyHashKey projectName projectVersion:1.0 projectType:0

返回內容： {"type":"project","statusCode":"000000","projectHashKey":"Nr2PNlf82c6a7995d30286e041944fd40e4c01d58b3edeb"}

介面2：查詢專案列表介面

介面URL：www.eolinker.com/apiManageme…

請求方法：POST

請求引數：companyHashKey

返回內容： {"type":"project","itemNum":4,"statusCode":"000000","projectList":[{"projectHashKey":"83uUHhud0519435001f268f0871eee88090cc68dc00cac7","projectName":"demo_project","projectType":0,"projectDesc":"","projectUpdateTime":"2018-10-08 18:26:57","projectVersion":"1.0","userType":0,"permission":{"userType":0,"endTime":"2099-01-01","isExpire":0}}]}