介面是有協議的，它規範了軟體之間進行資料互動時所應該遵循的規矩，介面的請求方法、報文格式（包括請求報文及返回報文）都必須按照協議所規定的規範來，如果不守規矩，則軟體之間就無法進行互動。
常見的介面協議有：
本質是基於某種協議（大協議，可模擬於憲法），按照介面文件（小協議，可模擬於各個法，如刑法、民法等）的規定傳送乙個請求給伺服器，伺服器返回乙個響應資料，然後對響應資料進行分析，判斷它是否符合我們的預期，從而驗證功能是否正確。
介面自動化就是用**或工具實現介面自動發起請求、自動驗證返回結果、自動生成測試報告的功能。
先來了解一下缺陷遺漏率是怎麼計算的 缺陷遺漏率 = 線上bug/bug總數*100%對於這個公式我是這樣理解的，線上出現的問題，就是我們的測試用例中包含但是沒有測試出來的。但是我們都知道測試是無法窮盡的，不可能列舉出所有的測試場景。那怎麼能保證我們測試用例就完全能測出所有問題，那麼我們可以換個方式考慮，即在滿足產品當前使用者量下的測試力度下（針對不同的質量要求衡量測試力度），所設計的測試用例可以百分之百覆蓋當前質量要求。這樣去理解我們的缺陷遺漏率，包含測試用例設計上都會明確了。
關於介面自動化降低缺陷遺漏率的優勢：高效、穩定、無誤差。為什麼這麼說呢，我們每次上線前都會進行回歸測試。測試的內容少還好，如果回歸功能很多，及時參照測試用例也很難保證在人工執行的時候沒有誤差，而且出現頻繁回歸的情況也屢見不鮮，導致回歸時間很長，甚至無法保證全部功能回歸。但是介面自動化回歸可以非常完美的規避以上問題，只要前期介面用例和環境搭建完成就不會出現遺漏，也不會出現誤操作導致資料或者環境的原因引發的問題，並且執行效率很高。
所以為何要做介面自動化其中之一就是降低缺陷遺漏率。
特定問題：什麼問題？——自動化測試
約束邊界：為什麼約束？——明確測試範圍和目的
解決方案：用什麼方案解決問題？——程式語言+工具+其他
構成工具的元件：哪些元件？——用例、指令碼、資料、日誌、報告、通知
特點是什麼？—— 靈活性、可擴充套件性、高內聚低耦合
配置檔案。用於配置一些**中需要用到的重要資訊。如：各個包的路徑、登入的使用者名稱密碼、資料庫配置、日誌配置等。
測試資料。用於存放自動化測試中需要用到的測試資料。一般結合資料驅動來使用。
第三方類。用於存放可能會用到的第三方類。如：用於生成html測試報告的htmltestrunnernew.py。
日誌。用於存放**中記錄的日誌，一般是錯誤日誌。
報告。測試用例執行成功後生成的測試報告。
測試用例。即測試**。
介面測試 介面自動化測試
1 介面自動化到底關注哪些點？a.關注函式 類 方法 所提供的介面的可靠性 b.關注介面之間銜接的可靠性 c.關注介面引數的校驗 2 介面有哪幾種型別？a.http協議中 get post put delete input方法 b.目前自動化工具提供的有get和post兩種方法 3 用介面實現自動化...
介面測試自動化
前端介面向後端傳送api介面 api 可以理解為資料傳輸的通道 後端把 http請求的響應返回給前端 介面測試的工作流程 準備階段 拿到開發的介面文件 了解每個介面的引數及含義 了解被測試系統的業務流程 編寫介面測試用例 執行階段 測試用例 測試場景執行 測試資料 系統資料收集 分析階段 資料彙總 ...
UI自動化測試 介面測試等自動化測試策略
今天跟大家介紹ui測試 介面測試 單元測試主要內容，以及每種測試花費時間討論。ui測試 selenium ui測試是最接近軟體真實使用者使用行為的測試型別。通常是模擬真實使用者使用軟體的行為，即模擬使用者在軟體介面上的各種操作，並驗證這些操作對應的結果是否正確。介面測試 api測試 api測試，主要...