區分概念
測試：我想了解下接口，你能給我講講這個系統中的幾個重要接口嗎？
JAVA開發：這里面有幾百個接口，都很重要的，你想看哪一個？
測試工程師：~這~~~
很明顯，這兩個初級工程師對接口的理解，顯然出現了偏差，JAVA工程師理解的接口是指JAVA中的interface,而測試工程師所理解的接口，是指多系統間進行數據交互、通信的接口。為了讓大家不出現理解偏差，我們今天來統一口徑，了解一下什么是測試行業通用的接口測試。
我眼中的接口測試
某百科：
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
通俗的講，接口是指系統模塊與模塊或系統與系統間進行交互。如下圖所示：
再舉個實際的栗子：
有一個新聞客戶端：
在手機上打開新聞客戶端按住屏幕往下拉時，頁面會刷新，會有新的新聞展示出來，這就是一個請求獲取數據的接口。服務端返回：
客戶端根據返回值，進行渲染，然后展示給用戶。
所以對於新手而言，接口測試就是要做到如下兩個基本點：
1、保證服務端有響應，有返回值
2、保證返回值的正確性，如果newsId與title匹配不上，則表示接口返回錯誤
接口的類型
由於通信協議太多，以后我們把最常用http協議的接口作為主要例子。
目前我們所說的接口中，用的最多的是RPC，webservice，restful的接口。但現在流行的是基於HTTP協議的rest風格的接口，為什么只強調rest風格的接口呢？在這里介紹一下rest 接口，rest接口在使用過程中不受調用客戶端語言的限制，在網絡傳輸過程中不需要傳遞強類型的對象，僅僅通過網絡傳遞字符串，也就是說rest是一組約束條件和原則，大家都遵守這些條件與原則，於是乎，交互的數據就具有通用可解析的特點了。更通俗點說，rest風格的接口就是指返回值是json串的接口。現在restful風格類型的接口已經越來越成為互聯網行業通用的接口表現形式。
到底什么是接口測試
通過上面的概念的理解，我們大致可以知道了，接口測試一般就是指基於HTTP協議的返回值是JSON串的測試(也有可能是一個字符串\XML)，那其本質就是客戶端發送一個request給服務端，服務端響應后返回一個response，然后我們分析response是不是符合預期，這即是接口測試。大家先這么理解吧。
接口測試的前景
由於接口傳輸的主要是數據，數據的准確性、安全性應該是被首先保障的。所以，一般的接口測試比UI功能測試 優先級要高一些。
由於接口只是單純的數據交互，無界面，與傳統的UI測試相比，更接近底層一些，更容易發現底層的問題，且難度相對UI測試要低很多，所以接口測試號稱測試界的“短平快”，更加符合現在敏捷開發，快速迭代的開發模式。
同時在自動化方面接口自動化測試也是最容易看到成效的，更容易獲得你老大的支持喲。
接口的生命周期
其中測試人員一直貫穿到整個生命周期，具體是這樣的：
測試人員都是全能的，職責幾乎貫穿了整個接口生命周期。那到底從哪里開始測試呢？可能100個人有100個自己的理解。
自然是越早開始越好，現在測試人員的價值早不是以前找多少個BUG。在“專注、極致、口碑、快”的今天，能幫開發越快迭代的測試才越值錢。
該怎么辦呢？
當接口定義完以后，就進入了開發設計階段，這時候，后台接口開發人員需要設計數據庫表等方面的工作，提供出這個接口最快得兩三天左右，但終端可能立刻就需要這個接口的數據從而進行下面的功能的開發，前端開發人員不可能等着。OK，機會來了，測試人員就可以介入了，說的沒錯，就是測試人員提供mock，使接口能夠正確的返回，從而使前端開發能夠接着往下進行。
測試界的軍規，缺陷發現越晚，代價就越高。
就讓咱們開始吧
我們先分析一下接口請求的過程：
接口開發語言很多，比如php/python/java，甭管 PHP是不是世界上最好的語言，它們的接口請求的過程都是如上圖所示，所以，既然我們要mock，只能是在”執行方法/函數並將數據返回終端”這一環節來操作了，我們可以提供一個方法，將終端所需要的數據寫死在方法體中，並返回給終端，這樣，終端就能夠拿到的數據並進行下面的開發。
比如這樣一個接口定義：
路徑：/api/v1/getUserInfo
請求方式：GET
請求參數：userid=1
返回正確值：
{ "redCode": 200,
"redMsg": "success",
"data": {
"id": 1,
"name": "zhangsan",
"age": 18}}
返回異常值：
{
"redCode": 201,
"redMsg": "data null",
"data": {}
}
可以設計兩組請求參數userid=1和userid=2提供給終端，在mock的方法體中這樣寫：
當接口開發完畢后，撤下我們的MOCK類，依據MOCK類，完善自動化測試腳本，並對已開發完的接口進行自動化測試。
優點
承上啟下，承接終端，啟發服務端，使之平滑過渡。
測試數據已體現在MOCK類中
最重要的一點：更接近底層，利於我們更好的去了解接口
缺點
需要編碼能力教強
從流程上大家還不是足夠的熟悉系統容易漏測
接口到底在測什么
在寫接口測試腳本時，對於接口返回值的斷言，有的同學偏向於連接數據庫，取值並將數據進行加工后與接口返回值進行比較，以達到運態期望值的目的，個人認為這是一種不正確的方式，理由如下：
1
數據加工的過程，就是接口業務邏輯實現的過程，就算測試通過了，你也無法保證你的代碼沒有BUG。如果提前寫好期望，可以最大限度的避免這個問題。
2
一個穩定的接口，其輸入與輸出都是穩定的，根本不需要所謂的動態期望值，我們只需要給出參數，將返回值我們事先設定好的寫死的數據進行斷言即可。
3
如果你真想把控開發業務邏輯的過程，到不如去做白盒測試與單元測試，這樣的收益更大。
接口測試在每個人眼中的不同
百曉生的接口測試系列也到了尾聲了，陸續收到一些反饋，大家都認為接口測試是一種相對比較簡單且回報率要相對高些的一種測試手段，特別是在互聯網+的浪潮之下。大家蜂擁而至后，發現接口測試其實並不簡單，也會有心力憔悴的感覺，似乎又回到了UI自動化的怪圈。針對這種情況，百曉生也是急大家之所急，跟很多測試界大牛交流了這些問題，經過整理，希望能對大家有些幫助。
A君：
Q：你所理解的接口測試？
A：接口測試本身不難，難的是監控。
Q：監控是指監控哪方面？
A：主要2個方面，性能和功能。性能主要是看接口的響應時間，指定告警閥值，告警策略。例如，10分鍾內，平均響應時間超過某個值。這里的性能是劈開並發。功能主要看接口在灌入正確參數，異常參數的一些返回值，也就是業務邏輯的檢查。
Q：那這個監控是指接口測試腳本的執行了？
A：是的，接口測試腳本調試完成后，就可以丟到執行中心去執行了，也就是監控。
Q：驗證是如何做的？也就是期望值是如何產生的？
A：你測試一個接口，連期望值都不知道，怎么測？所以，期望值你是知道的。
Q：期望值，有的人是從數據庫取值，然后與返回值進行比對，有的是直接寫死，然后與返回值比對，你們采用的是哪種方式？
A：我們不是寫死的，測試接口的數據大多數是動態生成，也就是說通過調用其他接口來准備你待測接口的數據， 在接口自動化的過程中，不操作數據庫。
Q：通過調用其他接口來准備你待測接口的數據，舉個例子說明一下？
A：有些場景，譬如接口B依賴接口A的返回，你在測試接口B的時候，就應該先調用接口A，拿到返回作為接口B的測試輸入， 而不是直接從數據庫拿一個A數據，或者寫死一個數據。
Q：如果這個接口不依賴任何，其期望值是不是寫死就好一些？
A：有些返回里面永恆不變的，寫死沒問題，有些東西要變的，寫死就不行了，變的情況一般使用通配來檢查。也就是說，返回值里，可能分兩部分：變化的，與不變的。那我們也可以分兩部分來檢查，變化的，通配檢查，不變的，可以寫死的進行檢查。
Q：執行中心統一定時多長時間運行一次？
A：這個看你的用例規模，執行引擎的數量，如果你的資源不夠，非要1分鍾執行一次，那肯定跪。
Q：接口平台會起到什么作用？
A：平台只是提供一些用例編寫，維護的便利，執行策略等常規配置，至於沒有平台，你照樣可以完成這些事情。
B君：
Q：你們如何做的接口測試？
A：很簡單，用EXCEL來維護用例與數據，寫個執行引摯就可以了。
Q：驗證時，有去查數據庫嗎？
A：分情況而言，一般不去驗證數據庫。
Q：腳本寫完后，如何實施？比如是丟在線上進行不間斷的跑？
A：構建的時候觸發，構建完成->觸發任務->通過。每天也會有BVT測試。
。。。。。。
交流至此，不知道對大家有沒有啟發，也希望大家從迷惑中走出來，真正讓自動化給我們帶來生產上的效益，而不是成為我們去面試 談薪水時的噱頭而已。