如何作好接口測試？

本文轉載：http://www.51testing.com/html/95/n-3718695.html

1、接口測試簡介

一、什麼是接口測試？
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等

二、爲何要作接口測試
a)互聯網的快速發展，公司內部系統或與外部系統的關聯愈來愈多，一個業務流程關聯多個後端系統，它們的關聯都是基於接口來實現，接口測試能夠將複雜的系統關聯進行簡化，只要作好每一個接口的測試就可以較好的保證系統質量。
b)單個系統的變動，是否會影響到關聯業務系統，比較難用常規的測試方面來覆蓋相關的應用系統（例如使用此接口的外部 系統有N個，不可能每一個作功能兼容性測試），但能夠經過對接口功能的覆蓋來驗證是否影響它人對接口的調用。
c)接口功能比較單一，可以比較好的進行測試覆蓋，也相對容易實現自動化持續集成，，能夠減小人工迴歸成本與時間，縮短測試周期。
d)接口相對於界面功能，會更底層一些，測試覆蓋會更容易（如業務在調用接口時作了判斷，當不知足條件時連接就不顯示，此時從界面沒法測試相關功能是否作好判斷，經過接口就比較容易）

三、接口測試範圍
a)業務功能（包括正常、異常場景是否實現）
b)業務規則（覆蓋度是否全面）
c)參數驗證（邊界、業務規則是否達到要求）
d)異常場景（重複提交、併發提交、事務中斷、多機環境、大數據量測試）
e)性能測試（響應時間、吞吐量、併發數、資源要求）
f)安全測試（權限驗證、SQL注入等）

四、接口測試的重點
一、檢查接口返回的數據是否與預期結果一致。
二、檢查接口的容錯性，假如傳遞數據的類型錯誤時是否能夠處理。
三、接口參數的邊界值。例如，傳遞的參數足夠大或爲負數時，接口是否能夠正常處理。
四、接口的性能，http請求接口大多與後端執行的SQL語句性能、算法等比較相關。
五、接口的安全性，外部調用的接口尤其重要。

2、作好接口測試的前提

一、系統化的接口文檔
傳統的接口文檔，通常採用word或wiki等系統來記錄，從單次使用上彷佛比較簡單，由於你們會更習慣這樣的操做，但這種形式存在比較大的問題：
a、接口文檔非標準化，沒法直接與接口測試工具接口使用
b、接口維護困難，接口有變化時比較難標識清楚，溝通成本很高
系統化接口文檔，例如rap（淘寶分源的一個系統），具有接口維護標準化、版本化管理、MOCK測試等功能；對標準化的接口內容作二次開發，能夠直接導出Soapui等工具使用的格式，直接導入工具中使用，有如下好處：
A、接口測試時再也不須要手工輸入相關字段，節省時間成本
B、版本化管理，可以清晰的知道哪些接口有變化
Rap參考 http://rapapi.org/org/index.do

二、標準化的接口規範
接口管理是作好接口測試很重要的前提，若是一個系統有哪些接口都不太清楚，測試就很難覆蓋到，接口管理建議採用如下方式：
A、按接口提供方爲單位進行首次劃分，按接口使用方進行二次劃分，再按業務模塊進行細分，分類原則根據內容多少進行優化，不須要固定，如自己接口較少就沒有必要分得過細，較多時就須要多劃分模塊
如：系統A，提供有 一、二、三、四、五、六、七、八、9 這9個接口，接口分別給B系統、C系統使用，其中一、2爲公用接口，三、四、5爲B專用，六、七、八、9爲C系統專用，劃分以下：

B、按接口連接URL作爲惟一，不一樣的接口參數作爲接口變量，接口有參數變動時在原來接口上進行維護，而不是新增長接口
C、爲接口增長版本號，方便清楚哪些接口本次有變動，易於維護用例

 

3、接口測試經常使用工具

工具名	類型	特色	使用建議
JMeter	開源	開源	我的以爲使用起來仍是比較麻煩，對JMeter很是熟悉的建議使用，新手不建議使用
JMeter	開源&商業	開源版本有功能限制，不能直接使用循環等、支持groovy語言	操做比較簡單，但對具備必定的流程的接口測試用例不是太方便維護，對於獨立的接口推薦使用
PostMan	免費	流利器插件，易用，功能相對簡單	相對比較簡單的接口
Loadrunner	免費	主要作性能測試使用，具有接口請求錄製自動生成腳本、添加判斷等功能	具備必定流程性的接口、及具有LR使用經驗的人使用

一、JMeter
JMeter是Apache組織開發的基於Java的壓力測試工具，可以將請求轉換爲腳原本實現，並容許使用正則表達式建立斷言來對請求返回結果進行判斷，具有接口測試功能和性能的能力。
參考：http://www.51testing.com/html/79/n-3708579.html
二、SOAPUI
SoapUI是一個完整的自動化測試解決方案。支持SOAP和REST的Web服務，JMS企業消息層，數據庫，豐富的互聯網應用，等等。而在SoapUI，你從它的直觀和強大的用戶界面這一切。對於自動化程度較高，SoapUI還提供了命令行工具，讓您運行的功能/負載測試和幾乎全部的任務調度程序，或做爲您的構建過程當中的一個組成部分MockServices集。
三、PostMan
Postman是一款功能強大的網頁調試與發送網頁HTTP請求的Chrome插件，具有Fiddler\httpwatch之類的工具調試請求的功能，同時具有接口管理功能，官網提高腳本保存同步功能，支持接口導入導出
http://blog.csdn.net/flowerspring/article/details/52774399
四、Loadrunner
HP公司的性能測試工具，使用C語言或JAVA語言編寫腳本，易學易用

4、接口自動化測試實例

RAP+SoapUI
一、接口文檔rap系統錄入

二、導出wadl格式文件

三、接口導入測試工具進行測試
打開soapui，新建project,右鍵添加WADL


確認導入後結果以下：

右鍵對應的項目生成測試用例

界面以下：

備註：這裏可選擇爲每個資源生成一個單獨的用例，也能夠選擇將全部請求生成到一個用例中，使用時建議，請求將多時選擇，較少時選擇
，以方便用例管理
確認後，將生成以下的測試用例集

接下來對每個用例進行完善，進行參數化、添加檢查點來判斷結果

注：
一、參數化方式有多種形式，支持直接維護參數列表、讀取參數文件、直接使用SQL語句查詢數據等。若是數據是比較固定的可使用直接維護參數列表；若是數據狀態之類的會發生變化，建議使用SQL語句查詢，這樣能保證參數的有效性
二、檢查點也支持多種形式，經常使用contains、Xpatch Match,支持本身編寫腳原本判斷
RAP+PostMan
PostMan支持導入功能，能夠直接導入
Postman Collection, Environment, data dump, curl command, or a RAML / WADL / Swagger(v1/v2) / Runscope file

將上面導入SOAPUI中的WADL文件導入，結果以下：

PostMan與soapui接合
Soapui 新版本支持直接導入PostMan Collection，以下圖

這樣你們也能夠將使用PostMan測試的記錄導入到Soapui中使用

5、持續集成接口測試

對接口測試而言，持續集成自動化是核心內容，經過自動化的手段纔能有效下降成本，提升接口測試的價值。若是使用LR、JMeter、SoapUI工具作自動化測試，工具自己支持命令行模式運行，能夠接合Jenkins 等自動化平臺，實現項目版本更新後的自動化迴歸測試
關於持續自動化迴歸測試的建議：
一、接口腳本開發時要注意參數的取值的可用性，不由於時間或數據狀態的變化引發腳本不能正常運行，下降腳本維護成本.
二、接口迴歸功能的覆蓋度控制，須要根據腳本的實際功能和重要性判斷自動化迴歸覆蓋度，迴歸內容越多腳本維護成本越高，通常應用接口不建議全功能覆蓋（畢竟接口有變化會作詳細測試，若是沒修改其它變動可能對其產生的影響通常不會影響其邏輯判斷）
三、接口腳本須要必定的自動化校驗能力，除請求http狀態的判斷外，還須要對核心內容的正常性作判斷（判斷內容可與數據庫內容匹配等方式，不建議用寫死的內容）。
四、持續性能測試，還須要作好相關的監控、性能指標的分析自動化，減小人工操做。