業務穩定為啥要測接口？
為了回歸。而且接口有個好處，定位問題簡單，一出問題基本都是服務端的問題，而且肯定是和這個接口相關的代碼，不用花時間再去抓包->分析（->撕逼）
對于page的接口測試，測試點如何設計？
第一頁、中間頁、最後一頁，那麼如何擷取到的頁數就是最後一頁？讓開發協助寫擷取最後一頁的接口，測試來調用。
接口測試是否成功的校驗點是？
（1）從reponse中是否包含指定内容開始。
（2）擴充到資料庫的校驗
接口測試的用例驗證點（容錯性驗證）？
ADD/MOD（添加/修改）:
（1）字段邊界值，最大最小字元，為空以及格式校驗
（2）重複送出相同的參數
（3）權限校驗
（4）業務邏輯
DEL:（删除）
（1）删除不存在的
（2）删除無權限删除的
（3）删除後再添加相同的
（4）重複删除
LST:（清單）
（1）為空時擷取
（2）數量大時擷取
（3）分頁
（4）擷取無權限擷取的
接口測試的本質？
通過測試參數的排列組合驗證傳回值/資料庫變更是否符合預期，進而确定接口相關代碼是否正确。
接口測試的優點？
（1）簡單（對于開發基礎比較好的同學來說）
（2）穩定（成功率高，很少出現ui自動化的各種狀況）
（3）效率（1個接口下的100條用例幾秒可執行完成）
（4）可信（ui自動化測試報告天天執行，一堆fail，由于各種環境問題、相容等問題導緻排查測試報錯的原因較麻煩）
（5）時間（用例編寫時間短，相對來說複用性高）
簡單的一個接口測試（用例編寫、開始執行）的步驟？
（1）開始編寫前置條件、入參、傳回參數、預期結果等測試相關的資訊
（2）運用工具去執行測試用例或者執行自己寫的腳本
（3）校驗傳回結果是否正确
接口測試是什麼？
接口測試是功能測試不可或缺的一部分，抛開了前段的邏輯和限制對于伺服器的功能進行了完整的測試，一個好的功能測試人員應該充分了解所測系統有多少個接口，接口的核心參數和響應，完成對接口代碼的走讀，接口有沒有白名單，防刷，内部接口和外部接口等。
接口測試的作用是什麼？
從接口測發起的測試彌補了界面測試的遺漏點，能将接口測試納入功能測試的一部分，測試的完整性得到了很大的提高，界面測試起碼遺漏了如下的資訊：
（1）伺服器端接口參數校驗
（2）接口是否存在安全漏洞或者邏輯漏洞，實時性，防刷
（3）接口是否存在越權的可能
接口測試注意點？
【第一步：看】
（1）、看接口的請求參數構造是否合理
（2）、看所傳參數有無敏感參數需要加密傳輸。比如說使用者userid、password等資料如果不使用https進行通信，最好使用加密的方式進行傳輸，這也是業界通用的标準，并且入庫也需是加密的
（3）、看所測服務的代碼。第一看對于傳入參數的校驗部分，第二是看整體邏輯處理部分。舉個例子，大家在測試過程中經過會遇到如圖五所示，有多個必填或者選填項、輸入條件特别多、每個輸入條件都需要做校驗。有些測試人員會對此類問題用正交的方式一項一項測試，這類效率太慢。個人認為效率最高的方式為對于接口參數的校驗，以靜态測試為主，review代碼的過濾條件，頁面控件實際輸入測試為輔助。很多的輸入界面，其中判空處理是必須的。開發代碼中常用的一個判空函數是if（xxx.isempty（））。首先界面類查找是否有控件對象未使用該函數，若未使用肯定存在bug；其次即使使用這個函數也是有bug，該函數并未完全滿足需求。這個函數漏掉了輸入空格的情況,正确的做法是if（xxx.trimme().isempty（））。那麼如果在全工程内，搜尋isempty,對比發現bug，最後可以選擇一個輸入項進行測試，通過後所有輸入控間判空測試均告完畢。
（4）、看接口的傳回體是否傳回一些不必要的敏感資訊，傳回格式是否合理
【第二步：改】
（1）請求體中參數的正常修改。正常修改就是通用的邊界值方法，如極大值、極小值、極長值、null、空。未對這些值做校驗的後果可大可小。小的方面僅僅是伺服器throw一個統一的錯誤提示，如網絡錯誤等。中等一點的為前端頁面會傳回如圖六形式的内部錯誤，這種錯誤會洩露一些敏感資訊。嚴重的後果可能就是影響現有或者後續業務，使得業務往不可控的方向進行。
（2）與業務強相關的參數修改。
（3）請求消息體中的字段修改。有些人習慣在cookie中傳輸大量的資訊，也是值得關注的測試點。
接口測試的主要關注點？
（1）業務邏輯（業務邏輯覆寫）
（2）響應結構
（3）資料格式
（4）資料正确性（依據來源：查資料庫與伺服器和接口傳回值比較）
測試的原則？
（1）基礎配置，如域名，環境配置等，單獨檔案配置，友善不同環境測試，腳本維護
（2）明确接口實作什麼樣的功能，實際需要什麼樣的功能。是否一緻
（3）接口測試資料太多，用資料驅動模式更有層次，且易維護
（4）要衆多用例中選出冒煙測試用例及可用于性能測試的用例
（5）先單接口測試，在多接口測試
（6）測試完成後，需要清理髒資料
為什麼選擇JMeter做為接口測試的技術方案？
（1） 基于配置實作接口測試的自動化，免代碼開發
（2）豐富的斷言能力支援，傳回值校驗，資料庫比對校驗
（3） 比較好的支援流程控制
（4） 比較完善的結果監聽
（5）和Jenkins易于內建，內建後支援接口性能趨勢的檢視能力
（6）非标準協定或者對接方有特殊安全處理的情況可以使用JavaSample的方式處理
接口測試的流程？
類似于功能測試，需求讨論--評審需求—确定需求—産出接口定義—根據需求文檔及接口定義設計測試用例（測試用例主要從業務場景，功能以及異常測試幾個方面考慮）—評審用例—執行測試
需求的頻繁變化，做接口測試的測試人員應該如何應對？
個人覺得此在于團隊開發的流程，團隊之間的溝通和測試人員的警覺性。
在開發階段，需求的變更是一件極為頻繁和正常的事情，對于此點團隊中的任何一個人都應該正确的心态來面對，團隊需要規範的開發流程，良好的溝通方式，測試人員更需要及時跟進軟體進度，和開發人員并進齊行，同時，測試與開發需要相對獨立的工作環境，總結而言為知己知彼，亦敵亦友。
接口測試的原理？
通過測試程式模拟用戶端向伺服器發送請求封包，伺服器接收請求封包後對相應的封包做出處理然後再把應答封包發送給用戶端，用戶端接收應答封包這一過程（request→response）
接口測試的範圍？
（1）、新增接口的測試；
（2）、新增業務功能接口測試；
（3）、整個伺服器的接口測試，所需測試接口一次增多，在測試時間足夠的條件下，當然需要對所有接口進行測試用例的設計，如果測試較短的情況下，則應該首先根據使用者的典型操作對測試接口進行優先級劃分，對調用平凡接口需要優先進行測試。
接口測試政策？
（1）、接口設計檢查（整數型資料位數、浮點型資料精度、字元串資料範圍值)
（2）、接口依賴關系檢查
（3）、接口輸入/ 輸出驗證
3.1 、條件判斷接口
3.1.1、條件判斷的驗證：要對判斷條件進行驗證，則需要知道接口是根據哪些輸入項來進行判斷的
3.1.2、異常資料的響應：對于密碼重置接口，使用者ID不存在、不合法，郵箱輸入格式錯誤、使用者郵箱資訊不存在或未激活就是測試時需要考慮的異常場景，設計這類輸入值，并且檢查接口傳回的響應碼，響應碼的正确才能保證用戶端根據異常情況來顯示相應的提示資訊。
3.2、資料查詢接口
除了像條件判斷接口之外根據請求參數設計合法/不合法/正常/異常測試值之外，還需要結合資料庫來對查詢結果進行驗證。
3.2.1、是否根據 正确的關聯資料表進行查詢
3.2.2、驗證查詢結果是否從資料表中正确項中擷取，涉及到多表聯合查詢時，不同表中的相同項設計不同測試資料來進行驗證。
3.2.3、修改查詢結果在資料表中對應項中的資料，使其為空值或用戶端相應項的範圍值的最大和最小值，檢視接口輸出是否正确。
3.3、邏輯運算接口
後端接口都測試什麼？
回答這個問題，我們可以從接口測試活動内容的角度下手，看一下面這張圖，基本反應了目前我們項目後端接口測試的主要内容：
後端接口測試一遍 ，前端也測試一遍，是不是重複測試了？
回答這個問題，我們可以直接對比接口測試和app端測試活動的内容，如下圖為app測試時需要覆寫或考慮内容：
接口測試持續內建：
對接口測試而言，持續內建自動化是核心内容，通過持自動化的手段我們才能做到低成本高收益。目前我們已經實作了接口自動化，主要應用于回歸階段，後續還需要加強自動化的程度，包括但不限于下面的内容：
a) 流程方面：在回歸階段加強接口異常場景的覆寫度，并逐漸向系統測試，冒煙測試階段延伸，最終達到全流程自動化。
b) 結果展示：更加豐富的結果展示、趨勢分析，品質統計和分析等
c) 問題定位：報錯資訊、日志更精準，友善問題複現與定位。
d) 結果校驗：加強自動化校驗能力，如資料庫資訊校驗。
e) 代碼覆寫率：不斷嘗試由目前的黑盒向白盒下探，提高代碼覆寫率。
f) 性能需求：完善性能測試體系，通過自動化的手段監控接口性能名額是否正常。
接口測試品質評估标準：
a) 業務功能覆寫是否完整
b) 業務規則覆寫是否完整
c) 參數驗證是否達到要求（邊界、業務規則）
d) 接口異常場景覆寫是否完整
e) 接口覆寫率是否達到要求
f) 代碼覆寫率是否達到要求
g) 性能名額是否滿足要求
h) 安全名額是否滿足要求