本文主要分為兩個部分：
第一部分：主要從問題出發，引入接口測試的相關内容并與前端測試進行簡單對比，總結兩者之前的差別與聯系。但該部分隻交代了怎麼做和如何做？并沒有解釋為什麼要做？
第二部分：主要介紹為什麼要做接口測試，并簡單總結接口持續內建和接口品質評估相關内容。
第一部分：
首先，在做接口測試的過程中，經常有後端開發會問：
- 後端接口都測試什麼？怎麼測的？
- 後端接口測試一遍 ，前端也測試一遍，是不是重複測試了？
于是，為了向開發解釋上述問題，普及基本的測試常識，特意梳理了接口測試的相關内容以及其與前端測試的差別，使開發團隊與測試團隊在測試這件上達成基本的共識，提高團隊協作效率，進而更好的保證産品品質。
然後，我們試着回答上面的問題：
問題1.1、後端接口都測試什麼？
--回答這個問題，我們可以從接口測試活動内容的角度下手，看一下面這張圖，基本反應了目前我們項目後端接口測試的主要内容：
問題1.2、接口的業務邏輯測試用例設計（路徑測試）？
--業務邏輯方面的用例設計與功能性用例設計不同，邏輯用例主要關注接口内的各種判斷對應的邏輯分支是否符合預期，這種用例不是針對某個具體的功能點，而是去驗證接口内部的各種處理邏輯。這類用例，往往需要以業務邏輯流程圖為依據進行設計。
舉個例子，畫出接口流程圖後有這樣的一個邏輯：
可以看到這一塊有兩個判斷，那麼 針對這一塊兒的處理邏輯，我們需要對不同的判斷分支都設計用例，以保證流程圖中涉及到的分支我們都有測試用例覆寫。圖中涉及到的不同的分支有：
1.abdf；
2.acg；
3.abdeg；
相應的，我們的用例就應該是：
1.userInfo != null && value(userGroup) != 0;
2.userInfo == null;
3.userInfo != null && value(userGroup) == 0;
業務邏輯的用例設計主要是以服務端接口内部的邏輯流程圖為基礎，針對流程圖中的判斷和分支進行用例設計，保證服務端接口的每一種邏輯下都有測試用例覆寫。設計盡可能少的用例，來保證各種業務場景下的資料是安全可操作的。
問題1.3、我們怎麼做接口測試？
--由于我們項目前後端調用主要是基于http協定的接口，是以測試接口時主要是通過工具或代碼模拟http請求的發送與接收。工具有很多如：postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
問題2、後端接口測試一遍 ，前端也測試一遍，是不是重複測試了？
--回答這個問題，我們可以直接對比接口測試和app端測試活動的内容，如下圖為app測試時需要覆寫或考慮内容：
從上面這兩張圖對比可以看出，兩個測試活動中相同的部分有功能測試、邊界分析測試和性能測試，其它部分由于各自特性或關注點不同需要進行特殊的測試，在此不做讨論。接下來我們針對以上三部分相同的内容再進行分析：
1、基本功能測試：
由于是針對基本業務功能進行測試，是以這部分是兩種測試重合度最高的一塊，開發同學通常所指的也主要是這部分的内容。
2、邊界分析測試：
在基本功能測試的基礎上考慮輸入輸出的邊界條件，這部分内容也會有重複的部分（比如業務規則的邊界）。但是，前端的輸入輸出很多時候都是提供固守的值讓使用者選擇（如下拉框），在這種情況下測試的邊界範圍就非常有限，但接口測試就不存在這方面的限制，相對來說接口可以覆寫的範圍更廣，同樣的，接口出現問題的機率也更高。
3、性能測試：
這個比較容易區分，雖然都需要做性能測試，但關注點确大不相同。App端性能主要關注與手機相關的特性，如手機cpu、記憶體、流量、fps等。而接口性能主要關注接口響應時間、并發、服務端資源的使用情況等。兩種測試時的政策和方法都有很大差別，是以這部分内容是需要分開單獨進行測試的，理論上來說這也是不同的部分。
綜論：
1、接口測試和app測試的活動有部分重複的内容，主要集中在業務功能測試方面。除此之外，針對各自特性的測試都不一樣，需要分别進行有針對性的測試，才能確定整個産品的品質。
2、接口測試可以關注于伺服器邏輯驗證，而UI測試可以關注于頁面展示邏輯及界面前端與伺服器內建驗證。
第二部分：
1、什麼是接口測試？
接口測試是測試系統元件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及内部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的互相邏輯依賴關系等。
2、為什麼要做接口測試?
a) 如今的系統複雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，接口測試可以提供這種情況下的解決方案。
b) 接口測試相對容易實作自動化持續內建，且相對UI自動化也比較穩定，可以減少人工回歸測試人力成本與時間，縮短測試周期，支援後端快速發版需求。接口持續內建是為什麼能低成本高收益的根源。
c) 現在很多系統前後端架構是分離的，從安全層面來說：
1、隻依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前面實在太容易）， 需要後端同樣進行控制，在這種情況下就需要從接口層面進行驗證。
2、前後端傳輸、日志列印等資訊是否加密傳輸也是需要驗證的，特别是涉及到使用者的隐私資訊，如身份證，銀行卡等。
3、接口測試持續內建：
對接口測試而言，持續內建自動化是核心内容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經實作了接口自動化，主要應用于回歸階段，後續還需要加強自動化的程度，包括但不限于下面的内容：
a) 流程方面：在回歸階段加強接口異常場景的覆寫度，并逐漸向系統測試，冒煙測試階段延伸，最終達到全流程自動化。
b) 結果展示：更加豐富的結果展示、趨勢分析，品質統計和分析等
c) 問題定位：報錯資訊、日志更精準，友善問題複現與定位。
d) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗。
e) 代碼覆寫率：不斷嘗試由目前的黑盒向白盒下探，提高代碼覆寫率。
f) 性能需求：完善性能測試體系，通過自動化的手段監控接口性能名額是否正常。
4、接口測試品質評估标準：
a) 業務功能覆寫是否完整
b) 業務規則覆寫是否完整
c) 參數驗證是否達到要求（邊界、業務規則）
d) 接口異常場景覆寫是否完整
e) 接口覆寫率是否達到要求
f) 代碼覆寫率是否達到要求
g) 性能名額是否滿足要求
h) 安全名額是否滿足要求（如：在請求中需要攜帶使用者的敏感資訊（比如電話号碼、身份證号碼、位址資訊等）時，敏感資訊一定是需要加密的，需要驗證對這些資料加密的生效性）