簡介
經常聽別人說介面測試，介面測試自動化，但是你對介面，有多少了解和認識，知道什麼是介面嗎？它是用來做什麼的，測試時候要注意什麼？坦白的說，筆者之前也不是很清楚。接下來先看一下介面的定義。
定義
介面泛指實體把自己提供給外界的一種抽象化物（可以為另一實體），用以由內部操作分離出外部溝通方法，使其能被內部修改而不影響外界其他實體與其互動的方式。
人類與電腦等資訊機器或人類與程式之間的介面稱為使用者介面。電腦等資訊機器硬體元件間的介面叫硬體介面。電腦等資訊機器軟體元件間的介面叫軟體介面。
在計算機中，介面是計算機系統中兩個獨立的部件進行資訊交換的共享邊界。這種交換可以發生在計算機軟、硬體，外部裝置或進行操作的人之間，也可以是它們的結合。
介面的優勢
一、規範性
介面就是規範，在整個系統設計中，涉及到很多層，為了使各個層之間呼叫透明話，你只需要知道介面，按照這個介面做你具體做的事情，就可以融合到整個系統中了。
生活中的例子很多，例如：插頭、插座，有標準的規範告訴你插頭應該是幾個腳，插座是幾個孔等等，做插頭、插座的公司就是根據這個規範來做插頭、插座，而不需要做完一個插頭就跑遍全世界去試用一下這個插頭做的對不對。
二、擴充套件性
在專案開發過程中，由於客戶的需求經常變化，如果不採用介面，那麼我們必須不停改寫現有的業務程式碼。改寫程式碼可能產生新的BUG，而且改寫程式碼還會影響到呼叫該業務的類，可能全都需要修改，影響系統本身的穩定性。到最後，可能會出現程式碼凌亂，不易讀懂，
後接手的人無法讀懂程式碼，系統的維護工作越來越重，最終可能導致專案失敗。
三、介面在專案就是一個業務邏輯，面向介面程式設計就是先把客戶的業務提取出來，作為介面。業務具體實現透過該介面的實現類來完成。當客戶需求變化時，只需編寫該業務邏輯的新的實現類，不需要改寫現有程式碼，減少對系統的影響。從而讓專案具有更大的擴充套件性。
常見的介面型別
介面是指外部系統與系統之間以及內部各子系統之間的互動點。包括外部介面、內部介面，內部介面又包括：上層服務與下層服務介面、同級介面。
常見web介面：一類是http協議的介面，另一類是web service介面（如soup、rmi、rpc協議）。本文主要介紹http請求介面。
常見的http請求方式包括：get（查）、post（增），除此之外還有put（改）、delete（刪）等。日常工作中見到的最多的是get和post兩種。
GET：GET可以說是最常見的了，它本質就是傳送一個請求來取得 上的某一資源。資源透過一組HTTP頭和呈現據（如HTML文字，或者圖片或者影片等）返回給客戶端。GET請求中，永遠不會包含呈現資料。
POST：向伺服器提交資料。這個方法用途廣泛，幾乎目前所有的提交操作都是靠這個完成。它用來向指定資源提交資料進行處理請求（例如：提交表單和上傳檔案），資料包被包含在請求體中，post請求可能導致新的資源的建立或者已有的資源的修改。
PUT：這個方法比較少見。HTML表單也不支援這個。本質上來講， PUT和POST極為相似，都是向伺服器傳送資料，但它們之間有一個重要區別，PUT通常指定了資源的存放位置，而POST則沒有，POST的資料存放位置由伺服器自己決定。客戶端向伺服器傳送的資料取代指定文件的內容。
舉個例子：如一個用於提交博文的URL，/addBlog。如果用PUT，則提交的URL會是像這樣的”/addBlog/ ”，其中abc123就是這個博文的地址。而如果用POST，則這個地址會在提交後由伺服器告知客戶端。目前大部分部落格都是這樣的。顯然，PUT和POST用途是不一樣的。具體用哪個還取決於當前的業務場景。
DELETE：刪除某一個資源。基本上這個也很少見，不過還是有一些地方比如 的S3雲服務裡面就用的這個方法來刪除資源。
1）get型介面
格式：請求數引數寫在網址後面，用"?"連線，多個引數之間用"&"連線。如：這是一個豆瓣查詢圖書資訊的開發api，q=''，單引號裡就是查詢的引數，如查詢《小王子》這本書的資訊，則q='小王子'，使用postman工具來試驗一下，如下圖：
場景：get型介面用於獲取資訊，多用於查詢資料，如列表查詢功能，點選查詢按鈕就呼叫一個get介面，然後把資訊返回出來
特點：1）請求資料量小，2）引數暴露於url地址中，故存在安全隱患
2）post型介面
說明：向指定資源位置提交資料（如提交表單、上傳檔案）來進行請求，post請求可能會導致新資源的建立
場景：如註冊、上傳、發帖等功能，如使用者在豆瓣網站對某本書進行收藏、寫筆記、發表評論
特點：請求資料量大，安全性高
如豆瓣的發表評論的開放api，見下圖：
3）put型介面
說明：put請求用於向指定資源位置上傳最新內容
場景：如使用者在豆瓣網站修改對某本書的收藏、修改某篇筆記或修改評論
如豆瓣的修改評論的開放api，見下圖：
4）delete型介面
說明：請求伺服器刪除請求裡url所標識的資源
場景：如使用者在豆瓣網站取消對某本書的收藏、刪除某篇筆記或刪除評論
如豆瓣的刪除評論的開放api，見下圖：
不常見的介面型別（瞭解即可）
不常見的http請求方式包括：head、connect、options和trace。
head：HEAD和GET本質是一樣的，區別在於HEAD不含有呈現資料，而僅僅是HTTP頭資訊。換句話說，就是返回響應中沒有具體內容，只獲取報頭。有的人可能覺得這個方法沒什麼用，其實不是這樣的。想象一個業務情景：欲判斷某個資源是否存在，我們通常使用GET，但這裡用HEAD則意義更加明確。
connect：HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。
options：這個方法很有趣，但極少使用。它用於獲取當前URL所支援的方法。若請求成功，則它會在HTTP頭中包含一個名為“Allow”的頭，值是所支援的方法，如“GET, POST”。允許客戶端檢視伺服器的效能。
trace：回顯伺服器收到的請求，主要用於測試和診斷。
附錄（get和post的區別）
這個問題，面試中經常被提到。簡單來說，可以從三個方面去回到這個區別:方式、大小、安全
1）.方式
方式指的是引數的傳入方式，GET方法一般是指獲取伺服器上的資料，引數直接跟著URL後邊，直接可以放到瀏覽器位址列裡，例如登入就是採用GET方法。而POST方法是指客戶端給伺服器上提交表單資料，所以POST是透過表單提交的，例如你網頁上的新使用者的註冊、調查問卷和答題就是採用POST方法。
2）.大小
上面已經知道GET是直接在瀏覽器位址列輸入，由於瀏覽器有限制，一般整個URL的長度可以很長，但是不能超過2049KB的大小限制，而這個POST就沒有大小限制。
3）.安全性
由於GET的引數是在瀏覽器位址列直接拼接，暴露在網際網路中，肯定不安全。POST是透過表單資料提交，相對比GET方法更安全。