接口測試的總結文檔
第一部分：主要從問題出發，引入接口測試的相關內容並與前端測試進行簡單對比，總結兩者之前的區別與聯系。但該部分只交代了怎么做和如何做？並沒有解釋為什么要做？
第二部分：主要介紹為什么要做接口測試，並簡單總結接口持續集成和接口質量評估相關內容。
第一部分：
首先，在做接口測試的過程中，經常有后端開發會問：
后端接口都測試什么？怎么測的？
后端接口測試一遍 ，前端也測試一遍，是不是重復測試了？
於是，為了向開發解釋上述問題，普及基本的測試常識，特意梳理了接口測試的相關內容以及其與前端測試的區別，使開發團隊與測試團隊在測試這件上達成基本的共識，提高團隊協作效率，從而更好的保證產品質量。
然后，我們試着回答上面的問題：
問題1.1、后端接口都測試什么？
--回答這個問題，我們可以從接口測試活動內容的角度下手，看一下面這張圖，基本反應了當前我們項目后端接口測試的主要內容：
問題1.2、我們怎么做接口測試？
--由於我們項目前后端調用主要是基於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) 安全指標是否滿足要求
接口測試用例設計
一、 用例設計過程：
羅馬不是一天建成的，用例不是一次完成的；書寫測試用例本身和完善代碼一樣，也是一個循序漸進的過程。
首先，必須熟讀需求說明書和接口設計文檔，了解每個接口具體的使用場景，明白軟件的性能指標。
其次，設計接口測試用例：開始在編碼階段，測試人員根據需求說明書和接口設計文檔設計接口測試用例。
然后，code review：開發完成編碼后，在時間充裕的條件下，要進行 code review，一方面是檢查開發的代碼功能邏輯是否正確，另一方面通過review開發的代碼來補充接口測試用例。
最后，完成用例后，隨着對系統了解的增多，不斷提高用例精度，對測試用例需要進行定期review，一旦測試需求發生變化，測試用例必須重新維護。
二、接口測試用例構思結構：
階段一：開發在編碼，測試拿到需求文檔和接口設計文檔：
1、基本功能測試（業務測試）：
根據需求文檔和接口設計文檔的轉譯，需要清楚業務流程規則和每個接口的使用場景方式，設計符合業務邏輯和接口使用場景的用例。
2、邊界分析測試：
在基本功能的基礎上，開始考慮接口輸入輸出參數的影響。主要采用等價類划分、邊界值分析方法等。
l 覆蓋所有的必選參數
l 組合可選參數
l 參數有無、或為null
l 參數的順序、個數、類型
l 參數類型數值大小、輸入的數值的范圍
l 參數字串長短，Null-max-max+1
l 參數包含特殊字符
3、參數組合測試：
在邊界分析的基礎上，考慮輸入條件的各種組合、輸入條件之間的相互制約關系。主要使用因果圖法進行用例設計。
4、異常情況測試：
接口實現是否對異常情況都進行了處理，接口輸入參數雖然合法，但是在接口實現中，也會出現異常，因為內部的異常不一定是輸入的數據造成的，而有可能是其他邏輯造成的，程序需要對任何異常都進行處理，比如：某個接口需要先登錄獲取 sesssion，如果直接調用該接口應該給出相應提示。
5、冪等級測試：
簡單說就時針對連續重復提交的情況的進行測試，特別是涉及到交易金額的場景，需要驗證軟件是如何處理的。
6、並發測試：
兩個以上用戶同時操作使用同一場景時，可能引導爭奪資源，死鎖等現象。
7、事務性測試：
一個業務流程包含多個操作步驟，如果某個操作失敗，那么整個操作需要回滾。或者調用前一個步驟的逆向接口進行操作取消。
8、大數據量時測試
數據庫里數據量較大時（百萬級），測試對DB進行增刪改查操作的效率。
9、環境異常測試
關聯系統出現宕機、超時或者無響應的狀態時，接口返回提示正確，業務邏輯正確，不可存在事務性不一致的情況
階段二：開發完成編碼，測試時間充裕的條件下，需要對開發的代碼進行code review
1、 review開發的代碼實際業務邏輯是否正確
2、隱含條件測試：
進行code review，檢查代碼中是否有隱含的默認條件。例如：F項目中的getRecommendArticleList接口，代碼中默認查詢返回4條記錄（如下圖），但在接口文檔中並未提到，如果不review code而開發也不告訴我們的話，這種情況肯定會漏測。
3、SQL測試：
針對需要進行數據庫操作的接口，查看相關sql，對sql的正確性進行驗證。如下圖，一般sql的過濾條件都會比開發告訴我們的要多，所以查看sql進行驗證是最保險的方式，特別需要設計組合條件的場景進行驗證：
三、測試過程驗證點：
1、接口返回數據
a) 返回json數據的層次關系是否與文檔一致
b) 數值類型數據: 特別是金額，負數、小數轉為json輸出是否正確
c) 接口返回數據與接口文檔一致
d) 接口返回數據和數據庫一致
e) 接口返回數據符合業務邏輯（比如轉賬功能，從一個賬戶扣款，另一個要增加相應金額）
f) 對於列表，應該根據請求參數，也應該驗證列表的長度是否與期望值一致
g) 負面測試用例，應驗證ERROR INFO是否與實際相匹配
2、數據庫
a) 接口傳入數據與插入DB的數據一致性：
b) 前端某個操作涉及后台DB多張表時，每張表都要檢驗數據正確性。
3、安全層面：
a) 后端接口返回給前端的數據包含敏感信息（如：姓名、身份證號、卡號、手機號、加密后的密碼等）時，不能明文傳輸，需要加密。
b) 后台打日志要求對於敏感信息不能打出，或者進行加星號脫敏后打出，具體有：
1） 身份證號，用戶密碼（含加密后），用戶手機號碼，用戶姓名，銀行卡號
2） 身份證號碼脫敏字段為生日時，生日在日志中不能打出
4、性能層面：
a) 接口響應時間： 接口處理數據的時間也是測試需要關注的一個點。牽扯到內部就是算法與代碼的優化
b) 接口數據包大小：接口傳遞的數據包大小也需要關注，特別是返回給前端的接口，要把不同接口數據包大小需要做限制。
c) 並發承載能力：多用戶並發時接口可以承載合同中的並發量。