一、對於接口測試來說，項目測試用例的重複運行首先是表現在單個測試用例的獨立性方面的，也就是說，每一個測試用例的運行除了依賴被測對象和對應的數據庫環境外，是不依賴於其他任何測試用例的，並且這個測試用例執行完畢後，對系統來說，也是沒有任何痕跡的，這樣就保證了每個測試用例運行時，都在一個乾淨的環境中運行。
要實現測試用例的獨立性，就必須對被測系統的設計有詳細的瞭解，這樣，不會出現測試用例執行後遺漏數據，環境未改變，另外，還需要對測試用例進行詳細的設計。
另外，要保證測試用例的重複使用，還需要做到測試用例的及時更新，在這個方面，我們是做接口測試的人會維護對應的系統的接口測試用例，要保證，代碼每次更新，測試用例都必須全部執行通過。
接口測試用例的設計方法其實和功能測試用例的設計方法是類似的，因爲接口是需要滿足需求的，而接口測試所依賴的也是需求說明書，但是，因爲接口測試畢竟是通過代碼去測試代碼，所以，爲了保證覆蓋率，可能會使用到單元測試的方法，具體的測試用例設計，我考慮的如下，請參考，如果有錯誤，一起討論。
輸入參數測試：針對輸入的參數進行測試，也可以說是假定接口參數的不正確性進行的測試，確保接口對任意類型的輸入都做了相應的處理：輸入參數合法，輸入參數不合法，輸入參數爲空，輸入參數爲null，輸入參數超長。
功能測試：接口是否滿足了所提供的功能，相當於是正常情況測試，如果一個接口功能複雜時推薦對接口用例進行結構劃分，這樣子用例具有更好的可讀性和維護性。
邏輯測試：邏輯測試嚴格講應爲單元測試，單元測試應保持內部邏輯的正確性，可單元測試和接口測試界限並不是那麼清楚，所以我們也可以從給出的設計文檔中考慮內部邏輯錯誤的分支情況和異常； 異常情況測試：接口實現是否對異常情況都進行了處理，接口輸入參數雖然合法，但是在接口實現中，也會出現異常，因爲內部的異常不一定是輸入的數據造成的，而有可能是其他邏輯造成的，程序需要對任何的異常都進行處理。
二、接口測試作爲集成測試的一部分，通過直接調用被測試的接口來確定系統在功能性、可靠性、安全性和性能方面是否能達到預期，有些情況是功能測試無法覆蓋的，所以接口測試是非常必要的。
接口測試分爲兩種，一種是webservice接口，走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，測試時通過工具soapUI進行測試。使用情況比較少；另一種http api接口，走http傳輸協議，通過路徑來區分調用的方法，最常用的是get和post請求。
上面說過，get和post請求是通過路徑來區分的，get請求的請求參數都是寫在URL裏的，格式爲：http://url?param1¶m2。而post的請求一般都是寫在body裏的，可能是key-value格式，或者json串格式，也可能是上傳一個文件。。。那麼問題來了，get請求和post請求的區別在哪裏呢？我們百度時，大多數的答案是這樣的：
1、get請求可以在瀏覽器中請求到，post請求的測試需要藉助工具
2、get請求使用url和cookie傳參，post的數據放在body中
3、post比get更安全，因爲傳遞的參數在url上是看不到的
4、get請求的url會有限制，而post請求的數據可以非常大
5、一般get請求是來獲取數據，post請求是傳遞數據的
其實，對於現在飛速發展的互聯網來說，上面的說法已經不嚴謹了。首先，post請求的參數也可以寫在url裏，但是這種情況不多見；其次表面上看起來，post利用body傳參，比get的url傳參安全，但其實只要用抓包工具（fiddler，Charles等），post的參數也是一覽無餘；再次，現在的瀏覽器非常強大，可以輸入支持很長的URL，所以也不再有限制一說了。這麼說來，種種區別只有最後一條是最根本的了。
怎麼來測試接口呢？根據什麼來測呢？這就需要開發提供的接口文檔了，接口文檔和功能測試的需求說明書的功能是一樣的。包括：接口說明、調用的url，請求方式（get or post），請求參數、參數類型、請求參數說明，返回結果說明。有了接口文檔後，我們就可以設計用例了，一般接口測試的用例分爲以下幾種：
1、通過性驗證，說白了就是傳遞正確的參數，是否返回正常的結果
2、參數組合，因爲參數有必傳和非必傳，參數的類型和長度，以及傳遞時可能業務上的一些限制，所以在設計用例時，就要排列組合這些情況，保證所有情況都能覆蓋到
3、接口的安全性，這個又分爲幾種情況：
1)繞過驗證，比如提交訂單時，在傳遞商品價格參數時，修改商品價格，就要看後端有沒有驗證了。或者我支付時，抓個包將訂單金額一改，如果能以我改後的金額支付，那這個藉口就有問題了。
2）繞過身份驗證，就是某個功能只有有特殊權限的用戶才能操作，那我傳遞一個普通的用戶，是不是也能操作呢
3）參數是否加密，這個關係到一些賬戶的安全，比如我們在登錄一些網站時，它要將我們的登錄信息進行加密，如果不加密我們的信息就會暴露，危害性極大。
4) 密碼安全規則，設置密碼時複雜程度的校驗。
4、根據業務邏輯來設計用例
用例設計完了，用什麼來測試接口呢？我們可以藉助一些工具，比如postman和jmeter。postman使用比較簡單，可以在列表中選擇請求方式，在輸入框中輸入URL，如果是get請求，直接點擊send就可以看返回結果了。
三、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、爲接口增加版本號，方便清楚哪些接口本次有變更，易於維護用例