11.1 接口
11.1.1 接口概述
定義：接口就是API（Application Programming Interface，應用程序接口），是一個軟件或服務對外提供的接口，別人只要調用這接口，而內部如何實現，不需要關心。你只要按照要求進行接口調用即可。
外部系統與系統之間以及內部各子系統之間的交互點。包括外部接口、內部接口。
舉例：
假設物流中“貨物”是數據，存放貨物的“總倉庫”是數據庫，“店鋪”是我們的網站、App。頁面上顯示的內容、數字，以及用戶的操作請求和結果都是需要不停搬運的“貨物”——數據，則負責調配分配打包的中轉站就是API，快遞小哥直接從中轉站取貨就好。
作用：對于軟件提供商來說，留出API，讓別的應用程序來調用，軟件才能發揮最大的價值，才能更有生命力。（同時別人也看不見代碼，不傷害商業機密。）
對于應用開發者來說，有了開放的API，就可以直接調用多家公司做好的功能來做自己的應用，不需要所有的事情都自己操刀，節省精力。
11.1.2 接口的表現形式
客戶端要先操作服務端資源，首先要找到服務端提供的接口，然后才能向服務端發送資源請求，那么何為服務端接口呢？其實就是一個地址（URL），比如：
http://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1
采用的協議(http:)：一般來講網址中第一個“:”前面的就是該網址所采用的協議。這里的HTTP就是個協議 。HTTPS是HTTP的安全版本，HTTPS在HTTP的基礎對傳輸的數據進行了加密和簽名，以保證數據傳輸的安全性。我們平常打開兩頁的時候會看到網址前面都有一個HTTP或HTTPS，這就是告訴你，你在向服務器發送此請求的過程中要遵循的協議是HTTP或HTTPS (也就是規則)。
服務器地址(//www.qubaobei.com)：以雙斜杠“//”開頭，后面跟的就是這個服務器的地址，專業術語叫域名。
請求資源路徑(/ios/cf/dish_list.php) ：表示你要請求的資源在該服務器下/ios/cf/dish_list.php的路徑下。
參數（?stage_id=1&limit=20&page=1）：參數可以找到具體內容，和路徑之間使用“?”隔開，參數之間使用“&”隔開。參數是以鍵值對的形式表現出來的。
把此URLhttp://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1稱為食品模塊個接口， 也稱為接口地址。
11.2 接口文檔
接口文檔展示
11.2.1 封皮
封面最好是本公司規定的封面，有logo，內容標題，版本號，公司名稱，文檔產生
日期。（錯誤地方在于，文檔的標題要和頁眉中的標題一致）
11.2.2 修訂歷史
表格形式較好些。包括：
版本，修訂說明，修訂日期，修訂人，審核時間，審核人。
11.2.3 接口信息
接口調用方式，是post方式還是get方式，接口地址，別人需要線上的哪個地址就寫哪個。（自己提前測試好線上的這個接口，是否有其他問題，千萬別犯低級的錯誤，尤其是某個字母寫錯）
11.2.4 功能描述
一定要清晰的描述接口功能。（不要遺漏一些細節，比如接口獲取的信息不包括哪些，哪些要寫明白）
11.2.5 接口參數說明
每個參數都要和實際中調用的一樣，包括大小寫；參數的含義言簡意賅的說明；格式是string 還是int 還是long等格式（例如參數為@RequestParam("appKey") StringappKey, @RequestParam("randomId") Integer randomId）；說明部分，說明參數值是需要哪個公司提供，并詳細說明參數怎么生成的，例如時間戳，是哪個時間段的；參數是否必填，一些參數是必須要有的，有些是可選參數，一定要注意寫清晰。
11.2.6 返回值說明
1、有一個模板返回值，并說明每個返回參數的意義。
2、提供一個真實的調用接口，真實的返回值。
注：現實工作中，對接口有疑問要及時跟同事交流。
11.3 接口測試的概念
11.3.1 概念
測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。
11.3.2? 接口測試本質
實質就是數據的傳輸和接受，傳輸的是接口地址中的參數，接受的是文本字符串，然后對比文本字符串是否正確。
11.4 接口測試的目的和原理
11.4.1 目的
測試接口的正確性和穩定性。
11.4.2 原理
接口測試的原理是通過測試程序模擬客戶端向服務器發送請求報文，服務器接收請求報文后對相應的報文做出處理然后再把應答報文發送給客戶端，客戶端接收應答報文這一個過程。
11.5 常用接口測試工具
11.5.1 典型商業工具：
LoadRunner（LR）：一款商業性能測試工具，用來做接口測試，很好很強大 ，但是配置比較麻煩。
SoapUI：開源測試工具，通過soap/http來檢查、調用、實現Web Service的功能/負載/符合性測試；該工具既可作為一個單獨的接口測試工具使用，也可利用插件集成到Eclipse，maven2.X，Netbeans 和intellij中使用。? ? 了解就可以了，基本已經不用了。
11.5.2 典型開源工具
Jmeter ：一款開源的接口測試工具，操作簡單，方便，既有jdbc request操作數據庫數據，也有http request和soap request應對測試
13.5.3 擴展插件
postman：谷歌瀏覽器的擴展工具，主要用來做接口測試，谷歌商店中選中安裝，界面同poster差別不大，界面簡潔。
13.6 接口測試應該測什么
13.6.1 單一接口
單一接口功能的測試主要測試返回的數據結構是否和接口文檔給出的一致，接口的正常功能是否完成，接口的參數檢查測試，接口的異常測試。
13.6.2 組合接口
定義：組合接口測試主要是通過組合多個單一接口，來測試一個業務場景
案例：測試購物網站的一個下單的功能，那么因為在下單之前還有一些流程，所以要測試一個場景。
測試：搜索商品 --> 選中商品 --> 添加進購物車 --> 提交訂單 -->支付
（提交訂單時還涉及到地址的選取等）
注：涉及到如果使用從cookie或者session在本例中的區別：如果使用cookie加入購物車，那么換一臺電腦購物車里的商品就不存在了，但如果使用的是session，購物車里面的東西就一直存在，即：cookie是本機作用的，session不止于本機作用。
13.6.3 結構檢查
（1）檢查返回值的結構是否正確，如是json類型還是xml類型的數據
（2）字段名稱是否正確等
XML和JSON都使用結構化方法來標記數據
13.7 接口測試內容
13.7.1 功能邏輯
通過查數據庫或緩存等驗證數據是否處理正確。
通過其他輔助途徑進行驗證
13.7.2 異常測試
接口測試中主要測試接口正常邏輯，但僅邏輯測試不能保證數據的安全及程序接口在異常情況下的邏輯處理的正確性。
13.7.3 路徑測試
當被測接口的實現方法中，判斷邏輯復雜分支多，且判斷中又調用了其他的接口，此時必須要進行路徑覆蓋測試。
13.7.4 其他異常場景
研發的項目，有些項目是底層使用的系統，根據項目特點，可能會存在特殊的異常場景。
例如： 支付的異步操作，支付消息重試等
11.8 測試案例
11.8.1 get請求
11.8.2 post請求
13.9 接口測試用例模板
