這就需要開發提供的介面文件了，介面文件和功能測試的需求說明書的功能是一樣的。包括：介面說明、呼叫的url，請求方式（get or post），請求引數、引數型別、請求引數說明，返回結果說明。有了介面文件後，我們就可以設計用例了，一般介面測試的用例分為以下幾種：
1、通過性驗證，說白了就是傳遞正確的引數，是否返回正常的結果
2、引數組合，因為引數有必傳和非必傳，引數的型別和長度，以及傳遞時可能業務上的一些限制，所以在設計用例時，就要排列組合這些情況，保證所有情況都能覆蓋到
3、介面的安全性，這個又分為幾種情況：
1)繞過驗證，比如提交訂單時，在傳遞商品**引數時，修改商品**，就要看後端有沒有驗證了。或者我支付時，抓個包將訂單金額一改，如果能以我改後的金額支付，那這個藉口就有問題了。
2）繞過身份驗證，就是某個功能只有有特殊許可權的使用者才能操作，那我傳遞乙個普通的使用者，是不是也能操作呢
3）引數是否加密，這個關係到一些賬戶的安全，比如我們在登入一些**時，它要將我們的登入資訊進行加密，如果不加密我們的資訊就會暴露，危害性極大。
4) 密碼安全規則，設定密碼時複雜程度的校驗。
4、根據業務邏輯來設計用例
介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。介面測試大體分為兩類：模組介面測試和web介面測試。
web介面測試
web介面測試又可分為兩類：伺服器介面測試和外部介面測試。
伺服器介面測試：是測試瀏覽器與伺服器的介面。使用者輸入的資料是輸入到的前端頁面上，怎樣把這些資料傳遞的後台的呢？通過http協議的get與post請求來實現前後端的資料傳遞。這也可認為是介面測試。
外部介面測試：這個很典型的例子就是第三方支付，比如在我們應用中在充流量時，交話費時，都會呼叫第三方支付介面。
主要測試要點如下：
請求是否正確，預設請求成功是200，如果請求錯誤也能返回404、500等。
檢查返回資料的正確性與格式；json是一種非常常見的格式。
介面的安全性，一般web都不會暴露在網上任意被呼叫，需要做一些限制，比如鑑權或認證。
介面的效能，這直接影響使用者的使用體驗。
測試用例
正面測試用例：
負面測試用例：
驗證點：
介面測試用例的設計
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）對於搜尋介面，應該把每個引數單獨作為搜尋條件來確認搜尋結果是否正確，然後再確認多條件輸入後的結果。
介面測試怎麼做
通用介面api規範 保持冪等。也即多次呼叫，應該產生一致的結果，例如轉賬1元，因為呼叫失敗或者超時重試的時候，最終結果還應該是轉賬1元，而非呼叫兩次變成轉賬2元。介面的實現應該盡量避免阻塞，可以使用非同步方式提公升效能。介面應該包括能夠區分不同情況的異常，而非丟擲寬泛的exception，不能吞掉異...
介面測試怎麼做的？
1 拿到介面文件熟悉 服務端開發人員把介面文件寫出來，我們就可以拿過來熟悉 1 每個介面對應要實現的功能是什麼。2 伺服器的位址 埠 介面位址 3 請求方式，請求引數有哪些 4 響應資料 1 響應的字段個數是否足夠 可以看需求文件中對應的功能需要顯示的個數，只能多不能少 2 正確和錯誤的響應碼 er...
WebSocket介面怎麼做測試
如果遇見了乙個全新的協議，怎麼從零開始，完成介面測試？以 websocket 為例。websocket 協議在2008年誕生，2011年成為國際標準。現在所有瀏覽器都已經支援了。websocket 的最大特點就是，伺服器可以主動向客戶端推送資訊，客戶端也可以主動向伺服器傳送資訊，是真正的雙向平等對話...