【接口基礎】
1.接口測試概念
1.1 基礎概念
接口的定義：接口英文“interface”，表示某個對象和外界交互的部分。
1.2接口的分類：
①用戶UI接口，表示提供給用戶操作的界面，是應用和用戶交互的部分。
主要分爲圖形化界面用戶接口（英文簡稱GUI）和命令行接口（英文簡稱Comand UI），
廣義的手工功能測試，就是操作UI界面，調用UI接口，查看服務器返回給頁面展示的結果。【常用】
②消息交互接口，diameter、radius等電信鑑權網關；
或者基於SOAP的web service等股價查詢接口；或基於REST的後臺服務器接口。【常用】
或者Rest API等阿里雲對象存儲服務OSS API接口。
這些接口，需要開發一定的測試工具，來模擬收發相應信息和響應數據。
③編程語言開發接口，主要需要編寫代碼調用接口開發包裏面編程庫的接口函數和對象的方法。
④其他接口，也是需要開發接口測試工具，纔可以測試。
比如對賬系統，提供了文件接口，直接把文件放在一個固定的ftp服務器上給別的系統取用。
比如數據服務系統，數據庫、緩存、消息隊列等服務公司，提供對外接口如Socket、共享內存、管道等。
1.3 常用的web API接口。
①以前的主流接口：SOAP協議接口，指定WSDL語言描述web service，用基於XML的SOAP協議來封裝消息，用HTTP協議傳輸消息。（已慢慢被淘汰，和被下面REST接口方式替代）
-優點：清晰沒有歧義，可以用軟件工具定義一個接口，自動生成相應的代碼。
-缺點：概念特別複雜，開發人員需要花較長時間理解它，應用到項目，交流門檻較高。
②目前的主流接口：REST接口(representational state transfer），僅僅表示描述了一種網絡應用軟件的架構風格，並不是一種具體的軟件架構的設計規範，凡是具有該風格特效的架構，都可以成爲REST ful的軟件架構。
-舉例說明：
比如長方形餐桌/上班穿正裝，就是包含了具體要求的一種基礎SOAP的web service的接口設計規範；
比如歐式餐桌/上班穿舒服點，就是一種抽象滿足REST架構設計風格的web服務接口。
③Rest接口規範：
-客服端和服務器結構
-連接協議具有無狀態特性：確保系統的橫向拓展能力
-能夠利用Cache機制增進性能
-層次化的系統
1.4前端設計規範：
-每個資源必須有對於的標誌（URI），服務請求中標記要操作的資源的URI.
-所謂資源，就是系統中任意一個可操作的對象。比如：一個P2P理財系統，用戶、用戶的積分、用戶的標的、用戶的統計等等，都是資源。
解釋：客戶端訪問服務器資源時，服務請求用URI標記資源，比如：http://api.example.com/users/12
表示的訪問id爲12的用戶的信息。
-通過對所標記資源的請求，返回HTML、XML、SVG、JSON、PNG等各種格式的資源文件。
解釋：客服端通過HTTP請求的Accept頭告訴服務端，它要什麼格式的資源。
-爲了達到無狀態請求的特性，請求必須包含足夠的信息描述，以便精準找到資源。
解釋：HTTP請求的方法（GET查看/POST添加/PUT更新/DELETE刪除等）來描述這條消息需要完成什麼樣的操作，比如增加、刪除、查看、修改資源等。
2.接口測試方法
①工具：通過postman、jmeter等接口測試工具，進行web服務接口的測試。
②腳本：通過已封裝好的編程語言的一些庫，搭配自動化測試框架，進行接口自動化測試。
③流程：先模擬構建HTTP請求消息，再解析收到的HTTP響應消息。
④區別：是否繞過前端的判斷邏輯。
web 測試主要是通過瀏覽器測試整個產品功能，包含前端判斷和接口規範；
web API測試主要是繞過瀏覽器和前端判斷，直接對web API的接口規範進行測試。
3.HTTP協議簡介
①HTTP應用：爲何要了解http協議，因爲幾乎所有的REST ful系統和SOAP Web Service 都是基於HTTP協議傳輸消息。
②HTTP協議：全稱應用層超文本傳輸協議，比普通文本傳輸協議厲害的地方就是“超”字，表示是“超哥”，可以傳輸超級多種類型的信息資源。
③HTTP版本號：0.9、1.0、1.1（目前最熱門）、2.0.
④HTTP請求的組成：
請求行（必要）：請求方法、url地址、協議版本號，必須以<CR><LF>結尾。
請求頭（必要，一般爲多個）：請求的其他信息，包括host、content-type、length等，必須以<CR><LF>結尾。
請求體（get非必要，post必要）：消息體中保存了提交給後臺的具體每一個字段的數據信息。
⑤HTTP響應的組成：
狀態行（必填）：版本號、狀態碼。必須以<CR><LF>作爲結尾。
響應頭（必填，一般爲多個）：date、type、encoding等。必須以<CR><LF>作爲結尾。
空行：用戶分隔響應頭和響應體。空行也必須用<CR><LF>結尾，而無其他空格。
消息體：支持HTTP、png等各種格式的資源返回。
狀態代碼：
1**消息：請求已經被服務器接收，繼續處理。
2**成功：請求已經被服務器接收、理解、並接受。
3**重定向：需要後續操作纔可以完成這一完整請求。
4**請求錯誤：請求中含有詞語錯誤或者無法執行。
5**服務器錯誤：服務器在處理某個正確請求時發生錯誤。
請求的方法：
get：向指定的資源發出“顯示”請求，使用get方法多用在讀取數據，無法修改和新增後臺數據。
post：向指定資源“提交”數據請求，請求服務器對錶單、文件進行“修改、新增”等操作，數據詳情被包含在請求的請求體中。這個請求可能會創建新的資源和修改已存在的資源。
put：向指定資源位置上傳並“更新”其最新的內容。目前常用於”更新資源“的操作。
delete：請求服務器刪除請求Request，指定的URI所標識的資源。
head？：與get請求一樣，向服務器發出“顯示”請求，不過區別在於，head請求返回的響應，不傳回資源的請求體本文部分的內容。好處在於，可以不必傳輸全部內容的情況下，就可以“獲取”其中關於該資源不可修改的的元信息和元數據。
4.postman的入門
4.1 工具的應用：目前大部分系統都是部分遵循了REST的風格規範，也可簡稱爲REST full系統。
REST full系統，主要是基於HTTP的CRUD？（增刪查改）的操作，分別使用了HTTP協議的POST、GET、UPDATE、DELETE方法的請求。
4.2 工具的組成：
①頂部Headerbar工具欄。
②左邊的sidebar請求側邊欄：主要分爲History歷史標籤（默認）和Collections集合標籤（便於管理）。
③右邊的Request Builder請求構建和解析欄：主要用於管理API請求詳情的，模擬HTTP請求的構建和查看服務器響應內容解析的。
4.3 流程：
我們輸入url地址，選擇Method（請求方法）和Headers（請求頭）和消息體，點擊發送。
Postman就發出請求給百度網站服務器，百度網站服務器隨後接到請求就響應了這個請求，給我們返回響應信息。Postman接收到響應信息後，顯示出消息的結構，展示給我們看。
4.4 拆解URL：
http://www.baidu.com/?action=list_course&pagenum=1&pagesize=20
?後面的內容，專業術語叫“query string“。
&分隔符，表示每一個單獨的參數。
/請求行裏面的url地址如果是“/”，表示根目錄
4.5 注意事項：
①參數轉義處理：如果參數中帶有特殊字符，比如&、空格、百分號等，鼠標移動到參數值，右鍵選擇“encodeURIcomponent”，替換成相應的轉義字符。
②content-type（必填項，請求域）：請求頭裏面的該字段，表示發送請求的消息體的類型，接口參數填寫時需要根據type類型，選擇在哪個模塊（form-data、x-www-urlencoded、raw-jason或者raw-XML、binary）下填寫參數。
③生成測試用例文檔：選擇左側請求的folder目錄，寫好備註，點擊右鍵，選中“publish docs”，生成文檔。
4.6 接口用例。
測試方法：等價類、邊界值、條件組合、錯誤猜測等方法。
模塊名稱：比如添加課程
Case編號：TestCase_001
測試步驟：
1.使用postman工具，調用創建課程API接口，新增一門課程，課程名稱不存在。
2.使用postman工具，調用列出課程API，查看最新課程列表。
預期結果：
1.返回創建成功，code：0，massage：創建成功。
2.返回結果包含新贈的課程信息。
執行測試時：
1.調用查看課程清單API，查看老的課程列表。
2.調用創建課程API，新增一門課程。
3.再次調用查看課程清單API，查看新的課程列表。
Case課程：TestCase_002
測試步驟：同上。修改條件（課程名稱已存在）
預期結果：
1.返回創建失敗，消息體內容爲{”recode“：2，”reason“：”同名課程已經存在“}
2.返回結果中，沒有步驟1新增的課程信息。
4.7 測試環境和變量。
定義：{{變量名稱}}，變量就是一個字符串標識符，用來對於一個多次出現的值。
分爲：全局變量和部分變量。
場景：
比如測試環境的服務器地址、端口號，內外測不一致，可以單獨設置一個變量當前環境使用。