這就需要開發提供的接口文檔了，接口文檔和功能測試的需求說明書的功能是一樣的。包括：接口說明、調用的url，請求方式（get or post），請求參數、參數類型、請求參數說明，返回結果說明。有了接口文檔后，我們就可以設計用例了，一般接口測試的用例分為以下幾種：

1、通過性驗證，說白了就是傳遞正確的參數，是否返回正常的結果

2、參數組合，因為參數有必傳和非必傳，參數的類型和長度，以及傳遞時可能業務上的一些限制，所以在設計用例時，就要排列組合這些情況，保證所有情況都能覆蓋到

3、接口的安全性，這個又分為幾種情況：

1）繞過驗證，比如提交訂單時，在傳遞商品價格參數時，修改商品價格，就要看后端有沒有驗證了。或者我支付時，抓個包將訂單金額一改，如果能以我改后的金額支付，那這個借口就有問題了。

2）繞過身份驗證，就是某個功能只有有特殊權限的用戶才能操作，那我傳遞一個普通的用戶，是不是也能操作呢

3）參數是否加密，這個關系到一些賬戶的安全，比如我們在登錄一些網站時，它要將我們的登錄信息進行加密，如果不加密我們的信息就會暴露，危害性極大。

4） 密碼安全規則，設置密碼時復雜程度的校驗。

4、根據業務邏輯來設計用例

接口測試是測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。接口測試大體分為兩類：模塊接口測試和web接口測試。

WEB接口測試

web接口測試又可分為兩類：服務器接口測試和外部接口測試。

服務器接口測試：是測試瀏覽器與服務器的接口。用戶輸入的數據是輸入到的前端頁面上，怎樣把這些數據傳遞的后臺的呢？通過http協議的get與post請求來實現前后端的數據傳遞。這也可認為是接口測試。

外部接口測試：這個很典型的例子就是第三方支付，比如在我們應用中在充流量時，交話費時，都會調用第三方支付接口。

主要測試要點如下：

請求是否正確，默認請求成功是200，如果請求錯誤也能返回404、500等。

檢查返回數據的正確性與格式；json是一種非常常見的格式。

接口的安全性，一般web都不會暴露在網上任意被調用，需要做一些限制，比如鑒權或認證。

接口的性能，這直接影響用戶的使用體驗。

測試用例

正面測試用例：

覆蓋所有的必選參數

組合可選參數

參數邊界值

如果參數的取值范圍是枚舉變量，需要覆蓋所有枚舉值

還應考慮實際業務應用場景，去設計輸入參數的組合。（這些用例可用來測試功能，作為SMOKE用例。也可將來用于壓力測試模擬實際業務場 景，但要注意保證用例的獨立性，因為壓力測試是多線程的。比如我們測試ACCOUNT 創建接口，NAME是不能重的，在寫測試用例時，給NAME賦值時可以加一個時間戳， 這樣用例在多線程并發測試時也不會有問題）

負面測試用例：

空數據

包含特殊的字符

越界的數據

錯誤的數據

驗證點：

status code （正常情況下，所有請求都應該返回200）

響應信息數據結構（目前大多數情況下，返回信息都是JSON， 我們應該驗證相應的結構當數據信息發生改變時）

驗證結點的類型

驗證結點的值 （主要是針對固定的值或者值遵循某些規則，我們能知道預期的結果的）

對于列表，應該根據請求參數，也應該驗證列表的長度是否與期望值一致

負面測試用例，應驗證ERROR INFO是否與實際相匹配

接口測試用例的設計

1.1接口文檔的特點

接口文檔，顧名思義就是對接口說明的文檔。好的接口文檔包含了對接口URL，參數以及輸出內容的說明，我們參照接口文檔就能編寫出一個個的測試用例。而且接口文檔詳細的話，測試用例編寫簡單，不會遺漏。

如果一個接口文檔沒有寫清楚，你從文檔中分不出哪些參數是必需的，哪些是非必須的，而且沒有參數的取值說明，返回值的結構等信息的話，測試人員是無法 編寫相應的測試用例的。但是由于開發人員不愿意寫文檔，所以很多接口文檔相對來說比較簡單，模糊不清，這對我們做接口自動化測試是很大的阻礙。

1.2 接口文檔的結構

接口文檔可以包含很多信息，有的愿意寫就可以多寫的，不太愿意寫的話，就寫的信息相對來說會少點兒。不過，下面幾項內容必須有，這是我們使用接口中和測試接口的依據：

（1）接口名稱。標識各個接口的簡單說明，如登錄接口，獲取項目詳情接口等。

（2）接口URL。接口的調用地址，在測試環境下前面的域名可能不一樣，不過接口名是不會變的。

（3）調用方式。接口的調用方式：Post/Get方式，決定了如何調用接口及傳遞參數。

（4） 參數。接口需要傳遞的參數，參數需要增加些說明：

（a） 參數值類型說明：參數值要說明一下，只支持字母，數據，特殊字符或是字母數據混搭。

（b）參數長度說明：參數接收最大多少個的字符串，或是最大是多少的數值等。

（c） 參數取值范圍：像枚舉型的參數，只接收什么范圍內的數據，如1-5等。

（d）參數的配合說明：有些參數需要配合起作用的，如：offset和count參數。

（e） 參數是必需的還是非必需的。

（5）返回值。接口的返回值說明需要包含正確和錯誤的情況，正確的情況下有哪兒數據，錯誤的情況下會有什么提示？

（6）其他的一些說明。上面的說明是通用的，還有其他的一些說明，如必須是登錄狀態調用，或是版本號等說明，在某些情況下也需要說明一下。

1.3 接口文檔缺失的的解決方法

（1）完全沒有接口文檔。這個情況是最麻煩的，我們要找開發人員來商量 ，最好能補個接口文檔，如果實在來不及那就給個調用接口的實例。實例中會有接口地址，參數等信息，我們去測試環境中調用一下，就能看到返回結果的情況。

（2）接口文檔信息不全。信息不全這個最常見，像參數說明缺少啊，沒有說明哪些是必需的參數，哪些是非必需的，或是沒有說明取值范圍等。此時我們能問開發就問開發，如果不太方便，就要做嘗試：一般非必需的參數不會做容錯的判斷，必需的參數檢測的方面比較全面。

（3）文檔不是最新的。接口的后續的工作中被修改或是優化過，我們按接口文檔上的說明去調用，返回和預期的不一樣。通知開發更新文檔，然后用最新的文檔再去修改測試用例。

這個接口文檔需要和接口開發人員做好約定，開發新接口時要把接口信息寫清楚，如果更新原來的接口，要及時更新接口文檔。同時在寫接口自動化測試用例的時候，要多和開發人員溝通，過程中溝通到底的一些關鍵信息整理為文檔留存。

2.接口測試用例設計

2.1 設計思路（策略）

1）優先級–針對所有接口

a、暴露在外面的接口，因為通常該接口會給第三方調用；

b、供系統內部調用的核心功能接口；

c、供系統內部調用非核心功能接口；

2）優先級–針對單個接口

a、正向用例優先測試，逆向用例次之（通常情況，非絕對）；

b、是否滿足前提條件 》 是否攜帶默認參值參數 》 參數是否必填 》 參數之間是否存在關聯 》 參數數據類型限制 》 參數數據類型自身的數據范圍值限制

3）設計分析：通常，設計接口測試用例需要考慮以下幾個方面：

a、是否滿足前提條件

有些接口需要滿足前置條件，才可成功獲取數據。常見的，需要登陸Token。

逆向用例：針對是否滿足前置條件（假設為n個條件），設計0~n條用例

b、是否攜帶默認值參數

正向用例：帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的“常規”值，其它不填寫，設計1條用例；

c、業務規則、功能需求

這里根據實際情況，結合接口參數說明，可能需要設計n條正向用例和逆向用例

d、參數是否必填

逆向用例：針對每個必填參數，都設計1條參數值為空的逆向用例

e、參數之間是否存在關聯

有些參數彼此之間存在相互制約的關系

逆向用例：根據實際情況，可能需要設計0~n條用例

f、參數數據類型限制

逆向用例：針對每個參數都設計1條參數值類型不符的逆向用例

g、參數數據類型自身的數據范圍值限制

正向用例：針對所有參數，設計1條每個參數的參數值在數據范圍內為最大值的正向用例

逆向用例：針對每個參數（假設n個），設計n條每個參數的參數值都超出數據范圍最大值的逆向用例

針對每個參數（假設n個），設計n條每個參數的參數值都小于數據范圍最小值的逆向用例

以上幾個方面考慮全的話，基本可以做到如下幾個方面的覆蓋：

主流程測試用例：正常的主流程功能校驗；

分支流測試用例：正常的分支流功能校驗。

異常流測試用例：異常容錯校驗

4） 測試用例基本上都包括以下五部分（根據項目情況進行增減）：

a.前置條件

b.輸入參數

c.執行步驟

d.校驗點

e.期望值

2.2 關注點

1）接口中所有的入參都要寫測試用例。

2）每個入參的每個錯誤類型都要準備一個異常用例。如必須參數缺省、參數類型錯誤、參數范圍錯誤、參數超過最大位數、參數沒有達到最小指定位數、參數的無效值（有效狀態外）、參數的小數點超過規定長度、參數含有非法字、參數含有違禁字、參數的關聯性檢查（如所在省、市，所在地不匹配）等等。

3）對于正常系的用例，要把所有入參的各種合法的有效值都執行到。所有入參的最大位可以用一個測試用例執行掉。所有可缺省的參數不要（只輸入必須參數）的測試用例也要做一個。

4）對于搜索接口，應該把每個參數單獨作為搜索條件來確認搜索結果是否正確，然后再確認多條件輸入后的結果。