介面就是有特定輸入和特定輸出的一套邏輯處理單元，而它不用知道自身的內部實現邏輯，也可以叫做介面的黑盒處理邏輯
由於服務物件不同，介面又可以分為兩種
系統內部呼叫的介面
內部介面的實際場景
購物流程，從登入系統，到加入購物車，再到支付訂單，這一長串的流程中，都是通過系統內部介面來完成的
外部系統對外提供的介面
外部介面的實際場景
你在購物後點選付款時，頁面會跳轉到支付系統，等你完成支付流程後，再跳轉回訂單頁，在這樣的流程中，都會涉及系統對外的介面，還比如說付款工程的支付介面、配送過程的物流介面等等
其實就是一種契約，遵循這樣一種形式：在開發前期，我們約定介面會接收什麼資料；在處理完成後，它又會返回什麼資料
介面測試，其實就是驗證介面內部處理邏輯是否正確；我們既要保證單介面的正確性，也要保證介面的業務邏輯正確性，主要體現在兩方面：
簡單來說
這兩種情況都是要驗證的，都屬於正向測試
從它對專案的影響來說，介面測試直接測試後端服務，更加接近伺服器上執行的**程式，也更能發現影響範圍廣泛的 bug。
隨著中颱化、服務化的發展，一套服務支援多種終端，例如 android 端、ios 端、web 端等，這些服務都是由一套後端服務支援的。
如果在web端發現乙個介面問題，影響的只是web端使用者，倘若乙個服務宕掉，影響的就不止是web端，還有android 端、ios 端
分層測試可以看到現在流行的模型更多偏向於介面測試
在質量保障過程中，我們的測試工程師會不斷增大介面測試的測試深度和測試廣度，往下逐漸覆蓋一些公共介面的單元測試內容，往上則逐漸覆蓋應該由 ui 層保障的業務邏輯測試，這麼做的主要目的，就是為了更好地完成質量保障工作，交付乙個可靠的、高質量的專案。
所以，從介面測試這一環節開始，測試工程師就變成了質量保障工作的主要推動者，介面測試也變得愈發重要。
其實無論是哪一種形式的介面，它們都是通過某一種傳輸協議，在 client 端和 server 端之間來完成資料傳遞的。
假如測試的是 web 端**，那麼 client 端就是瀏覽器，server 端就是 web 服務，那麼瀏覽器和 web 服務之間，就是通過 http 協議傳輸的；
結論：介面測試其實就是模擬呼叫方，比如 client 端，通過介面通訊來檢測被測介面的正確性和容錯性
單介面測試的重點，其實就是保證該介面的正確性和健壯性。也就是說，你既要保證這個介面可以按照需求，正確處理傳入的引數，給出正確的返回；也可以按照需求，正確的拒絕傳入非正確的引數，給出正確的拒絕性返回。
總結：需要有足夠的用例保證介面能正確處理各種正常情況和異常情況
主要是保障通過多個介面的串聯操作可以完成原來需求中提出的業務邏輯
總結：重點在於業務流程是否能跑通
拓展：我們更需要關心業務流和資料流的關係，並不需要再過度關心如何用業務流的方法覆蓋更多的**邏輯異常
在大部分的測試場景中，我們都需要序列多個介面，才能完成乙個完整的業務邏輯；多個介面之間並不是隨意組合的，而是按照業務邏輯、通過資料傳遞來完成的。所以要完成整體業務邏輯的介面測試，需要理清每個流程的資料流程，而資料流程驅動了業務流處理
分層測試中為什麼在單元測試和介面測試之間要加入一層介面測試的主要原因之一。
這也是為什麼現在很多人在提倡將測試模型由原來的金字塔形往菱形轉變的依據之一了。
介面測試的執行方式、設計思維都和業務測試不完全一致，它們既有交集又有差異。
交集部分是它們都會涉及到業務邏輯測試，但是介面測試更加關注有資料流驅動的業務流程，而不再著眼於**異常、**邊界等，這些邊界問題在介面測試過程中已經由單介面測試完成了。
介面測試在單介面測試的設計思維上也更加貼近於**的單元測試，但它還是站在 client 端的角度來完成測試；而介面測試的業務邏輯測試更加靠近手工業務測試，但卻更加聚焦於業務邏輯本身，不再將一些非法業務異常放到該部分進行測試。
在測試手段上，介面測試算是技術驅動和業務驅動雙管齊下的工作（介面測試卻是業務驅動為主的工作）
因此，你需要借助一定的工具來完成它。這個工具既有可能是成熟的工具，也有可能是你自己寫的**，因此，測試技術會在介面測試階段，變得和業務知識一樣重要。
cookie 中傳遞的引數很多都是用來確認使用者身份、鑑定角色許可權等需要的引數。
cookie 內容是完成介面測試必須要模擬並傳遞的一些資訊，因此，我們必須要盡可能完善它，使它成為介面測試的必要輸入條件之一。
一般來說，當你測試乙個介面的時候，你可以將介面的資訊弄成乙個表
被標註為白色背景的部分，是這次訪問的基本資訊；
被標註為黃色背景的部分，是訪問的頭資訊，同時也是我們已知的內容，因為欄位&值都是統一的
被標註為紅色背景的部分，就是 cookie 資訊，是我們未知的內容（針對cookie的各項引數我們需要向開發詢問他們的含義）
要知道引數的含義是拿來幹嘛的，也要知道這個引數的賦值是從**來的，是從其他頁面的返回值中得到的？還是 js 生成的？如果是其他頁面或者介面返回的，那麼，是哪乙個介面返回的哪個字段？這樣，當你開始做介面測試的時候，你就知道去**拿到這個引數的賦值了。
是指這個引數在這個介面中是做什麼用的，它在哪乙個訪問週期裡是一直存在的，它是否導致了業務邏輯分支等。比如說，這個引數是用來驗證使用者許可權嗎？它的驗證演算法是什麼？之所以要搞清楚這些內容，是為了你在做介面測試的時候，可以設計更小的引數組合來覆蓋更多的業務邏輯，這是測試用例去除冗餘的乙個很好的方法。
針對介面返回的 json，你要搞清楚在返回值中，每乙個 json 的 key 所對應的含義，這樣，當你需要和這個介面產生互動的時候，就可以快速地拿到對應引數的含義，完成業務邏輯上下文的引數串聯了。
JMeter介面測試實戰 介面分析
假設測試乙個建立使用者介面，資訊如下 名稱說明 請求位址 user create 請求方法 post 許可權必須是admin角色的使用者登入，才能建立使用者 協議json 請求引數 name 不能為空，不能重複，長度4 20的字母或數字組合 role 不能為空，且必須為admin 或 normal ...
jmeter介面測試實戰 2018 09 19
我告訴自己 放開一切，好好工作，好好昇華自己 不要想太多，專注於做一件事情 1 檢視分析介面文件，整理介面案例。2 準備介面入引數據，可以儲存成csv檔案，供後續使用。3 http請求預設值 如需要 http cookie管理器 如需要 http請求 斷言 斷言結果檢視器 結果檢視樹 如上是最簡單的...
測試 介面測試
最近，做了一系列的介面測試。首先，梳理一下我的疑惑。1 展示文案較多。內容多 形式多 條件分支多。2 需要測試的客戶端多。包括web介面 android介面 iphone介面。3 賬號型別多。根據角色，不同的角色是不一樣的。4 系統支援定製。定製的的細節可以精確到，乙個 中的哪行展示，那列不展示。5...