接口測試作什麼

1、

對於接口測試來講，項目測試用例的重複運行首先是表如今單個測試用例的獨立性方面的，也就是說，每個測試用例的運行除了依賴被測對象和對應的數據庫環境外，是不依賴於其餘任何測試用例的，而且這個測試用例執行完畢後，對系統來講，也是沒有任何痕跡的，這樣就保證了每一個測試用例運行時，都在一個乾淨的環境中運行。要實現測試用例的獨立性，就必須對被測系統的設計有詳細的瞭解，這樣，不會出現測試用例執行後遺漏數據，環境未改變，另外，還須要對測試用例進行詳細的設計。另外，要保證測試用例的重複使用，還須要作到測試用例的及時更新，在這個方面，咱們是作接口測試的人會維護對應的系統的接口測試用例，要保證，代碼每次更新，測試用例都必須所有執行經過。

接口測試用例的設計方法其實和功能測試用例的設計方法是相似的，由於接口是須要知足需求的，而接口測試所依賴的也是需求說明書，可是，由於接口測試畢竟是經過代碼去測試代碼，因此，爲了保證覆蓋率，可能會使用到單元測試的方法，具體的測試用例設計，我考慮的以下，請參考，若是有錯誤，一塊兒討論。

輸入參數測試：針對輸入的參數進行測試，也能夠說是假定接口參數的不正確性進行的測試，確保接口對任意類型的輸入都作了相應的處理：輸入參數合法，輸入參數不合法，輸入參數爲空，輸入參數爲null，輸入參數超長。

功能測試：接口是否知足了所提供的功能，至關因而正常狀況測試，若是一個接口功能複雜時推薦對接口用例進行結構劃分，這樣子用例具備更好的可讀性和維護性。

邏輯測試：邏輯測試嚴格講應爲單元測試，單元測試應保持內部邏輯的正確性，可單元測試和接口測試界限並非那麼清楚，因此咱們也能夠從給出的設計文檔中考慮內部邏輯錯誤的分支狀況和異常； 異常狀況測試：接口實現是否對異常狀況都進行了處理，接口輸入參數雖然合法，可是在接口實現中，也會出現異常，由於內部的異常不必定是輸入的數據形成的，而有多是其餘邏輯形成的，程序須要對任何的異常都進行處理。

 

2、
接口測試做爲集成測試的一部分，經過直接調用被測試的接口來肯定系統在功能性、可靠性、安全性和性能方面是否能達到預期，有些狀況是功能測試沒法覆蓋的，因此接口測試是很是必要的。
　　接口測試分爲兩種，一種是webservice接口，走soap協議經過http傳輸，請求報文和返回報文都是xml格式的，測試時經過工具soapUI進行測試。使用狀況比較少；另外一種http api接口，走http傳輸協議，經過路徑來區分調用的方法，最經常使用的是get和post請求。
　　上面說過，get和post請求是經過路徑來區分的，get請求的請求參數都是寫在URL裏的，格式爲：http://url?param1&param2。而post的請求通常都是寫在body裏的，多是key-value格式，或者json串格式，也多是上傳一個文件。。。那麼問題來了，get請求和post請求的區別在哪裏呢？咱們百度時，大多數的答案是這樣的：
　　一、get請求能夠在瀏覽器中請求到，post請求的測試須要藉助工具
　　二、get請求使用url和cookie傳參，post的數據放在body中
　　三、post比get更安全，由於傳遞的參數在url上是看不到的
　　四、get請求的url會有限制，而post請求的數據能夠很是大
　　五、通常get請求是來獲取數據，post請求是傳遞數據的
　　其實，對於如今飛速發展的互聯網來講，上面的說法已經不嚴謹了。首先，post請求的參數也能夠寫在url裏，可是這種狀況很少見；其次表面上看起來，post利用body傳參，比get的url傳參安全，但其實只要用抓包工具（fiddler，Charles等），post的參數也是盡收眼底；再次，如今的瀏覽器很是強大，能夠輸入支持很長的URL，因此也再也不有限制一說了。這麼說來，種種區別只有最後一條是最根本的了。
　　怎麼來測試接口呢？根據什麼來測呢？這就須要開發提供的接口文檔了，接口文檔和功能測試的需求說明書的功能是同樣的。包括：接口說明、調用的url，請求方式（get or post），請求參數、參數類型、請求參數說明，返回結果說明。有了接口文檔後，咱們就能夠設計用例了，通常接口測試的用例分爲如下幾種：
　　一、經過性驗證，說白了就是傳遞正確的參數，是否返回正常的結果
　　二、參數組合，由於參數有必傳和非必傳，參數的類型和長度，以及傳遞時可能業務上的一些限制，因此在設計用例時，就要排列組合這些狀況，保證全部狀況都能覆蓋到
　　三、接口的安全性，這個又分爲幾種狀況：
　　1)繞過驗證，好比提交訂單時，在傳遞商品價格參數時，修改商品價格，就要看後端有沒有驗證了。或者我支付時，抓個包將訂單金額一改，若是能以我改後的金額支付，那這個藉口就有問題了。
　　2）繞過身份驗證，就是某個功能只有有特殊權限的用戶才能操做，那我傳遞一個普通的用戶，是否是也能操做呢
　　3）參數是否加密，這個關係到一些帳戶的安全，好比咱們在登陸一些網站時，它要將咱們的登陸信息進行加密，若是不加密咱們的信息就會暴露，危害性極大。
　　4) 密碼安全規則，設置密碼時複雜程度的校驗。
　　四、根據業務邏輯來設計用例
　　用例設計完了，用什麼來測試接口呢？咱們能夠藉助一些工具，好比postman和jmeter。postman使用比較簡單，能夠在列表中選擇請求方式，在輸入框中輸入URL，若是是get請求，直接點擊send就能夠看返回結果了。


3、

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

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

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

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

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

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

原文：https://www.cnblogs.com/ailiailan/p/8652749.html