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）單層到黑白盒多層的自動化測試體系，從全面黑盒自動化測試到對系統的不同層次進行自動化測試。
在實際公司中開發人員一般不做單元測試， 所以為了更早的接入項目就需要完成接口測試。