結合工作實際和學習,梳理一下
一、
對於接口測試來說,項目測試用例的重復運行首先是表現在單個測試用例的獨立性方面的,也就是說,每一個測試用例的運行除了依賴被測對象和對應的數據庫環境外,是不依賴於其他任何測試用例的,並且這個測試用例執行完畢后,對系統來說,也是沒有任何痕跡的,這樣就保證了每個測試用例運行時,都在一個干凈的環境中運行。要實現測試用例的獨立性,就必須對被測系統的設計有詳細的了解,這樣,不會出現測試用例執行后遺漏數據,環境未改變,另外,還需要對測試用例進行詳細的設計。另外,要保證測試用例的重復使用,還需要做到測試用例的及時更新,在這個方面,我們是做接口測試的人會維護對應的系統的接口測試用例,要保證,代碼每次更新,測試用例都必須全部執行通過。
接口測試用例的設計方法其實和功能測試用例的設計方法是類似的,因為接口是需要滿足需求的,而接口測試所依賴的也是需求說明書,但是,因為接口測試畢竟是通過代碼去測試代碼,所以,為了保證覆蓋率,可能會使用到單元測試的方法,具體的測試用例設計,我考慮的如下,請參考,如果有錯誤,一起討論。
輸入參數測試:針對輸入的參數進行測試,也可以說是假定接口參數的不正確性進行的測試,確保接口對任意類型的輸入都做了相應的處理:輸入參數合法,輸入參數不合法,輸入參數為空,輸入參數為null,輸入參數超長。
功能測試:接口是否滿足了所提供的功能,相當於是正常情況測試,如果一個接口功能復雜時推薦對接口用例進行結構划分,這樣子用例具有更好的可讀性和維護性。
邏輯測試:邏輯測試嚴格講應為單元測試,單元測試應保持內部邏輯的正確性,可單元測試和接口測試界限並不是那么清楚,所以我們也可以從給出的設計文檔中考慮內部邏輯錯誤的分支情況和異常; 異常情況測試:接口實現是否對異常情況都進行了處理,接口輸入參數雖然合法,但是在接口實現中,也會出現異常,因為內部的異常不一定是輸入的數據造成的,而有可能是其他邏輯造成的,程序需要對任何的異常都進行處理。
二、
三、
1、什么是接口測試?
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換,傳遞和控制管理過程,以及系統間的相互邏輯依賴關系等
2、為什么要做接口測試
a)互聯網的快速發展,公司內部系統或與外部系統的關聯越來越多,一個業務流程關聯多個后端系統,它們的關聯都是基於接口來實現,接口測試可以將復雜的系統關聯進行簡化,只要做好每個接口的測試就能夠較好的保證系統質量。
b)單個系統的變更,是否會影響到關聯業務系統,比較難用常規的測試方面來覆蓋相關的應用系統(例如使用此接口的外部 系統有N個,不可能每個做功能兼容性測試),但可以通過對接口功能的覆蓋來驗證是否影響它人對接口的調用。
c)接口功能比較單一,能夠比較好的進行測試覆蓋,也相對容易實現自動化持續集成,,可以減少人工回歸成本與時間,縮短測試周期。
d)接口相對於界面功能,會更底層一些,測試覆蓋會更容易(如業務在調用接口時做了判斷,當不滿足條件時鏈接就不顯示,此時從界面無法測試相關功能是否做好判斷,通過接口就比較容易)
3、接口測試范圍
a)業務功能(包括正常、異常場景是否實現)
b)業務規則(覆蓋度是否全面)
c)參數驗證(邊界、業務規則是否達到要求)
d)異常場景(重復提交、並發提交、事務中斷、多機環境、大數據量測試)
e)性能測試(響應時間、吞吐量、並發數、資源要求)
f)安全測試(權限驗證、SQL注入等)
4、接口測試的重點
1、檢查接口返回的數據是否與預期結果一致。
2、檢查接口的容錯性,假如傳遞數據的類型錯誤時是否可以處理。
3、接口參數的邊界值。例如,傳遞的參數足夠大或為負數時,接口是否可以正常處理。
4、接口的性能,http請求接口大多與后端執行的SQL語句性能、算法等比較相關。
5、接口的安全性,外部調用的接口尤為重要。
做好接口測試的前提
1、系統化的接口文檔
傳統的接口文檔,一般采用word或wiki等系統來記錄,從單次使用上似乎比較簡單,因為大家會更習慣這樣的操作,但這種形式存在比較大的問題:
a、接口文檔非標准化,無法直接與接口測試工具接口使用
b、接口維護困難,接口有變化時比較難標識清楚,溝通成本很高
系統化接口文檔,例如rap(淘寶分源的一個系統),具備接口維護標准化、版本化管理、MOCK測試等功能;對標准化的接口內容做二次開發,可以直接導出Soapui等工具使用的格式,直接導入工具中使用,有以下好處:
A、接口測試時不再需要手工輸入相關字段,節省時間成本
B、版本化管理,能夠清晰的知道哪些接口有變化
Rap參考 http://rapapi.org/org/index.do
2、標准化的接口規范
接口管理是做好接口測試很重要的前提,如果一個系統有哪些接口都不太清楚,測試就很難覆蓋到,接口管理建議采用以下方式:
A、按接口提供方為單位進行首次划分,按接口使用方進行二次划分,再按業務模塊進行細分,分類原則根據內容多少進行優化,不需要固定,如本身接口較少就沒有必要分得過細,較多時就需要多划分模塊
如:系統A,提供有 1、2、3、4、5、6、7、8、9 這9個接口,接口分別給B系統、C系統使用,其中1、2為公用接口,3、4、5為B專用,6、7、8、9為C系統專用,划分如下:
B、按接口鏈接URL做為唯一,不同的接口參數做為接口變量,接口有參數變更時在原來接口上進行維護,而不是新增加接口
C、為接口增加版本號,方便清楚哪些接口本次有變更,易於維護用例
參考:
https://blog.csdn.net/u012062310/article/details/72475904
https://www.cnblogs.com/yu2000/p/7053089.html