1、介面的概念
介面又叫API，全稱application programming interface：應用程式介面（規範），也就是我們經常會聽說Web介面，APP介面。
詳細說明：
APP是一種基於C/S架構的應用程式，如抖音、微信等。完整的體驗是基於APP客戶端和後臺雲服務端共同作用的結果。
客戶端和服務端的資料傳遞，也就是指客戶端向服務端傳送請求，服務端響應客戶端的過程。
這一系列的通訊都是基於web協議通訊構成的，在利用web協議通訊的時候，企業內通常都會規定客戶端和服務端的資料交換格式，這種格式可以是企業內部規定的，也可以是使用webservice國際通用標準，這樣一來客戶端和服務端就使用同一套標準進行介面間的通訊。
同樣的道理，web介面也是如此，web應用通常是B/S架構，客戶端是我們熟悉的瀏覽器。
總結概括：介面就是客戶端與服務端之間的標準，或者是共同遵守的一套資料互動的規範。（一般由專案負責人/架構師來制定介面）
總結：介面是連線客戶端和服務端之間的橋樑，規定了客戶端和服務端之間資料交換的格式。
2、為什麼要使用介面
在專案中未採用介面時：
- 研發標準不統一，團隊磨合難度高。
- 研發週期長。
- 可擴充套件性差。
在專案中使用介面的優點：
- 統一設計標準。
- 擴充套件性靈活。
- 前後端開發相對獨立，前後端都可以使用自己熟悉的技術。
3、介面文件介紹
介面規範以介面文件的形式進行體現，我們做介面測試也是依據介面文件進行測試。
在專案開發中，web專案的前後端分離開發，APP開發，需要由前後端工程師共同定義介面，編寫介面文件，之後大家都根據這個介面文件進行開發，到專案結束前都要一直維護。
介面文件基本形式如下：
| 名稱 | 新增釋出會 |
|---|---|
| 描述 | 新增釋出會 |
| URL | http://127.0.0.1:8000/api/add_event/ |
| 呼叫方式 | POST |
| 請求引數 | eid # 釋出會 idname # 釋出會標題 limit # 限制人數 status # 狀態 address # 地址 start_time # 釋出會時間 |
| 返回值 | {'status':200,'message':'add event success'} |
| 狀態碼 | 每一個狀態碼要有一條用例。{'status':10021,message':'parameter error'} {'status':10022,message':'event id already exists'} {'status':10023,'message':'event name already exists'} {'status':200,'message':'add event success'} |
| 說明 | 說明引數傳入方式，簽名校驗方式，加密方式等等。 |
4、介面文件要素
一般情況下，開發前就有相應的介面文件，介面文件的形式有很多種，以excel表格或者Word文件或者使用介面管理工具（如swagger等）輸出，介面文件包含以下主要的內容：
（1）介面名稱
| 介面詳情 | 說明 |
|---|---|
| 介面名稱 | 新增釋出會 |
| 介面描述 | 呼叫該接介面會建立一個釋出會 |
（2）介面URL
| 名稱 | 說明 |
|---|---|
| 請求協議 | http或者https |
| 介面URL | 127.0.0.1:8000/api/add_event/ |
| 請求方式 | 新增(post) 修改(put) 刪除(delete) 獲取(get)等 |
提示：介面URL也可以形成URI的形式，就是把伺服器地址省略掉，例如：/api/add_event/
（3）請求引數
| 欄位 | 說明 | 型別 | 是否必填 | 備註 |
|---|---|---|---|---|
| eid | 釋出會 | Number | 是 | 預設：10001 |
| idname | 釋出會標題 | String | 是 | 預設：填寫釋出會標題 |
| start_time | 釋出會時間 | Date | 是 | 格式：2018-02-06 10:30:00 |
提示：一般資料型別為
String、Number、Object、Array、Date幾種型別。
（4）返回值
例如：{'status':200,'message':'add event success'}，還可以有其他所需欄位。
| 欄位 | 說明 | 型別 | 是否必須返回 | 備註 |
|---|---|---|---|---|
| code | 介面狀態碼 | Number | 是 | 成功：200 失敗：其他狀態碼 |
| message | 介面資訊 | String | 是 | 成功：sucess 失敗：提示資訊 |
提示：
正常請求引數返回值（必有）。
錯誤請求引數返回值（看公司要求）。
5、分層的自動化測試
測試金字塔的概念由敏捷大師Mike Cohn在他的Successding with Agile一書中首次提出。
他的基本觀點是：我們應該有更多低階別的單元測試，而不僅僅是通過使用者介面執行高層的端對端的測試。
如下圖所示：
Martin Fowler大師在測試金字塔模型的基礎上提出分層自動化測試的概念。
在自動化測試之前加了一個分層的概念，有別於傳統自動化測試。
那麼什麼是傳統的自動化測試？為何要提倡分層自動化測試的思想呢？
所謂傳統的自動化測試我們可以理解為，基於產品UI層的自動化測試，它是將黑盒功能測試轉化為，由程式或工具執行的一種自動化測試。
在目前的大多數研發組織當中，都存在開發與測試團隊割裂（部門牆）。
如果公司採用傳統的自動化測試，這可能導致兩個惡果：
- 一是UI自動化測試維護成本相對較高，因為UI是非常易變的；
- 二是測試團隊規模的急劇膨脹。
分層自動化測試倡導的是從黑盒（UI）單層到黑白盒多層的自動化測試體系，從全面黑盒自動化測試到對系統的不同層次進行自動化測試。
在實際公司中開發人員一般不做單元測試， 所以為了更早的接入專案就需要完成介面測試。