閱讀目錄
1.1 什么是接口測試 1.2 接口測試的必要性 1.3 接口測試流程 1.4 接口文檔 1.5 接口測試用例設計 1.6 接口測試用例模板
2.1 Postman簡介 2.2 Postman主頁 2.3 Postman 發送請求 2.4 Postman 授權 2.5 Cookie設置 2.6 Postman變量 2.7 Postman斷言 2.8 postman運行collection 2.9 Postman數據驅動 2.10 構建工作流
1.接口測試簡介
測試人員通常所說的“接口測試”是針對系統各組件之間接口的一種測試，它屬於功能測試。接口能測出普通界面操作難以發現的問題。如，我們都知道系統是由前端后端組成，一些數據在前端做了校驗，后端同樣也需要校驗才能保證安全，界面操作顯然只能檢查到前端校驗這一層，只有直接面對前后端之間的該接口才能檢驗出后端是否也做了校驗。
• 可以發現很多頁面操作發現不了的問題 • 檢查系統的異常處理能力
• 檢查系統的安全性、穩定性 • 前端隨便變，接口測好了，后端不用變
• 需求評審，熟悉業務和需求 • 開發提供接口文檔
• 編寫接口測試用例 • 用例評審
• 提測后開始測試 • 提交測試報告
接口文檔是接口測試的參照，至少包括：
• 接口說明 • 調用url
• 請求方法（get\post ……） • 請求參數、參數類型、請求參數說明
• 返回參數說明
• 通過性驗證：首先保證接口好用，按文檔正常傳入，查看是否可以返回正確的結果。
• 參數組合： 按接口文檔中對參數的要求進行有目的的組合，比如必填未填是否通過，標志類參數值的切換是否能對應正確的功能等。（這部分很關鍵）
• 接口安全：
1）繞過正常值驗證。
2）繞過身份授權驗證。
3）參數是否加密，加密規則是否容易破解。
4）密碼安全規則，密碼的復雜程度校驗。
• 異常驗證：不按照接口文檔上的要求輸入參數，來驗證接口對異常情況的反應。
1、項目 測試針對哪個項目
2、模塊 哪個功能模塊
3、用例id
4、接口名稱
5、用例標題 測試用途概括
6、請求方式 GET/POST
7、請求url URL地址
8、請求參數
9、前置條件 執行當前請求依賴的條件，不滿足就不能正確執行
10、結果驗證 預期結果
11、請求報文 可以不寫
12、返回報文 一定要寫，這里應該是你請求返回的真實結果
13、測試結果 通過/失敗
14、測試人員
2. Postman
Postman功能：
• 主要用於模擬網絡請求包 • 快速創建請求
• 回放、管理請求 • 快速設置網絡代理
Postman 的優點：
• 支持各種的請求類型: get、post、put、patch、delete 等
• 支持在線存儲數據，通過賬號就可以進行遷移數據
• 很方便的支持請求 header 和請求參數的設置
• 支持不同的認證機制，包括 Basic Auth，Digest Auth，OAuth 1.0，OAuth 2.0 等
• 響應數據是自動按照語法格式高亮的，包括 HTML，JSON 和 XML
Postman下載安裝：
• 下載地址：https://www.getpostman.com/apps
• 官方文檔：https://www.getpostman.com/docs/v6/
• Postman Api文檔：https://docs.postman-echo.com/
安裝好之后啟動程序，進入主界面。准備開始使用 Postman.
postman主頁如下：
各個功能區的使用如下：
- 快捷區： 快捷區提供常用的操作入口，包括運行收藏夾的一組測試數據，導入別人共享的收藏夾測試數據（Import from file, Import from folder, Import from link等），或新建請求、收藏夾、環境變量等。
- 側邊欄： 包括搜索欄， Request 請求的歷史記錄和收藏夾管理。
- 功能區： Request 請求設置，查看 Response 響應結果和測試結果，可以將請求保存到收藏夾。
- 設置區：設置和管理環境變量和全局變量。
案例1：使用Postman發送一個Post請求，POST 請求使用body 將參數傳遞給服務器。body為application/x-www-form-urlencoded類型，參數分別為param1=zxw和param2=888 請求 URL 如下：https://postman-echo.com/post
Postman Body 數據類型說明：
• form-data multipart/form-data 是 Web 表單用於傳輸數據的默認編碼。這模擬了在網站上填寫表單並提交它。表單數據編輯器允許我們為數據設置鍵-值對。我們也可以為文件設置一個鍵，文件本身作為值進行設置。
• x-www-form-urlencoded 該編碼與 URL 參數中使用的編碼相同。我們只需輸入鍵-值對，Postman 會正確編碼鍵和值。請注意，我們無法通過此編碼模式上傳文件。表單數據和 urlencoded 之間可能存在一些差異，因此請務必首先檢查 API 的編碼實現，確定是否可以使用這種方式發送請求。
• raw 請求可以包含任何內容。除了替換環境變量之外，Postman 不觸碰在編輯器中輸入的字符串。無論你在編輯區輸入什么內容，都會隨請求一起發送到服務器。編輯器允許我們設置格式類型以及使用原始主體發送的正確請求頭。我們也可以手動設置 Content-Type 標題，這將覆蓋 Postman 定義的設置。
• binary 二進制數據可讓我們發送 Postman 中無法輸入的內容，例如圖像，音頻或視頻文件
Postman常用請求總結：
HTTP GET 請求方法用於從服務器檢索數據。使用“Query String Parameters”將參數傳遞給服務器。
HTTP POST 請求方法旨在將數據傳輸到服務器，返回的數據取決於服務器的實現。 POST 請求可以使用 Query String Parameters 以及 body 將參數傳遞給服務器。
HTTP PUT 請求主要是從客戶端向服務器傳送的數據取代指定的文檔的內容。PUT 請求可以使用 Query String Parameters 以及 body 請求體將參數傳遞給服務器。
HTTP DELETE 方法用於刪除服務器上的資源，DELETE 請求可以使用 Query String Parameters 以及 body 請求體將參數傳遞給服務器。
很多時候，出於安全考慮我們的接口並不希望對外公開。這個時候就需要使用授權(Authorization)機制，授權過程驗證您是否具有訪問服務器所需數據的權限。 當您發送請求時，您通常必須包含參數，以確保請求具有訪問和返回所需數據的權限。 Postman 提供授權類型，可以輕松地在 Postman 本地應用程序中處理身份驗證協議。Postman 支持的授權協議類型如下：
• No Auth • Bearer Token
• Basic auth • Digest Auth
• OAuth 1.0 • OAuth 2.0
• Hawk Authentication • AWS Signature
• NTLM Authentication [Beta]
2.4.1 Basic Auth
Basic Auth是一種比較簡單的授權類型，需要經過驗證的用戶名和密碼才能訪問數據資源。這就需要我們輸入用戶名和對應的密碼。具體操作如下圖所示：
由於“Basic auth”使用明文傳遞，目前基本很少使用了。
2.4.2 Digest auth
Digest auth 是一個簡單的認證機制，最初是為 HTTP 協議開發的，因此也常叫做 HTTP 摘要。其身份驗證機制非常簡單，它采用哈希加密方法，以避免用明文傳輸用戶的口令。摘要認證就是要核實參與通信的兩方都知道雙方共享的一個口令。（在“Digest Auth”流程中，客戶端向服務器發送請求，服務器返回客戶端的nonce和realm值；客戶端對用戶名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合后進行MD5運算，把計算得到的摘要信息發送給服務端。服務器然后發回客戶端請求的數據。通過哈希算法對通信雙方身份的認證十分常見，它的好處就是不必把具備密碼的信息對外傳輸，只需將這些密碼信息加入一個對方給定的隨機值計算哈希值，最后將哈希值傳給對方，對方就可以認證你的身份。Digest思想同樣采如此，用了一種nonce隨機數字符串，雙方約好對哪些信息進行哈希運算即可完成雙方身份的驗證。Digest模式避免了密碼在網絡上明文傳輸，提高了安全性，但它仍然存在缺點，例如認證報文被攻擊者攔截到攻擊者可以獲取到資源。）
具體過程如下：
客戶端用戶向Server端發送請求，當 server 想要查證用戶的身份，它產生一個摘要盤問（digest challenge），並發送給用戶。典型的摘要盤問如下：
Digest realm="iptel.org", qop="auth,auth-int",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5
用戶使用這些參數，來產生正確的摘要回答，並發送給 server。摘要盤問中的各個參數，其意義如下：
realm（領域）：該參數是強制的，在全部的盤問中都必須有，目的是鑒別SIP（Session Initiation Protocol，會話初始協議）消息中的機密。在SIP實際應用中，它通常設置為SIP代理服務器所負責的域名。
nonce（現時）：這是由服務器規定的數據字符串，在服務器每次產生一個摘要盤問時，這個參數都是不一樣的。"現時"一般是由一些數據通過MD5雜湊運算（Hash函數，把任意長度的輸入消息串變化成固定長度的輸出串的一種函數）構造的。這種數據通常包含時間標識和服務器的機密短語。從而確保每一個"現時"都有一個有限的生命期（即過了設置的時間后會失效，且以后再也不會使用失效值），並且是獨一無二的 （即不論什么其他的 server 都不能產生一個同樣的“現時”）
algorithm（算法）：這是用來計算的算法。當前僅僅支持 MD5 算法。
qop（保護的質量）：這個參數規定 server 支持哪種保護方案。client 能夠從列表中選擇一個。值 auth 表示僅僅進行身份查驗， auth-int 表示進行查驗外，另一些完整性保護。須要看更具體的描寫敘述，請參閱 RFC2617。
opaque（不透明體）：此參數是一個不透明的（不讓外人知道其意義）數據字符串，在盤問中發送給用戶。在摘要響應中，用戶會將這個數據字符串發送回給服務器，使得服務器能夠是無狀態的。若需要在盤問和響應之間維持一些狀態，用該參數傳送狀態給客戶端，此后當摘要響應回來時，再讀取這個狀態
案例2：
請求 URL：https://postman-echo.com/digest-auth，用戶名: postman，密碼: password，
摘牌配置信息如下：Digest username="postman", realm="Users", nonce="ni1LiL0O37PRRhofWdCLmwFsnEtH1lew", uri="/digest-auth",response="254679099562cf07df9b6f5d8d15db44", opaque=""
• Hawk Auth ID: dh37fgj492je
• Hawk Auth Key: werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn
• Algorithm: sha256
2.4.4 OAuth 1.0
OAuth（開放授權）是一個開放標准，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片，視頻，聯系人列表），而無需將用戶名和密碼提供給第三方應用
案例4：
請求 URL 如下：https://postman-echo.com/oauth1，請求方式為 GET，Add authorization data to 設置為：Request Headers
參數配置為：
• Consumer Key: RKCGzna7bv9YD57c
• Consumer Secret: D+EdQ-gs$-%@2Nu7
cookie 是存儲在瀏覽器中的小片段信息，每次請求后都將其發送回服務器，以便在請求之間存儲有用的信息。比如很多網站登錄界面都有保留賬號密碼，以便下次登錄。Cookie 是由服務端生成，存儲在響應頭中，返回給客戶端，客戶端會將 cookie 存儲下來，在客戶端再次發送請求時，user-agent 會自動獲取本地存儲的 cookie，將 cookie 信息存儲在請求頭中，並發送給服務端。postman 可以設置、獲取、刪除 Cookie。
Set Cookies：在 Send 按鈕下方點擊 Cookies 文字菜單，然后可以設置 Cookie。
Get Cookies：Cookie 獲取比較簡單，直接獲取 Response Headers 里面的 set-cookie 值即可，或者在主界面下方 Cookie 菜單欄里面也可以查看。
Delete Cookies：點擊 Cookies 文字菜單,然后可以根據需求去清除對應的 Cookie。
Postman 提供了變量設置，共有 4 種變量類型。
• 本地變量(LocalVariable )
• 全局變量(Global Variable)
• 環境變量(Environment Variable)
• 數據變量(Data Variable)
優先級從高到低
Data ---- > Local ---- > Enviroment ---- > Global
2.6.1 環境變量
環境變量指在不同環境，同一個變量值隨着環境不同而變化，如當在測試環境時，host 值為: dev.postman.com ,當切換到生產環境時，host 值變為：postman-echo.com 。
環境變量設置： 在 postman 界面點擊右上角眼睛圖標，即可開始設置環境變量和全局變量。環境變量設置過程如下圖所示：我們可以設置兩種環境 dev 和 release,dev 是開發測試環境；release 是正式的生產環境。host 環境變量，根據不同的環境值不一樣。
變量引用格式為{{varname}},如下圖所示：
2.6.2 本地變量
本地變量主要是針對單個 URL 請求設置的變量，作用域只是局限在請求范圍內。如請求 URL 如下，設置兩個本地變量（user,passwd）作為參數。請求方式為 POST
從上圖中我們可以看到變量設置的格式為{{variable_name}}
變量設置好之后需要賦值，在 Pre-request-Script 里面編寫如下代碼：
pm.variables.set("user","51zxw");
pm.variables.set("passwd","66666");
點擊 send 執行之后的返回值如下圖，可以看到我們定義的變量已經發送。
2.6.3 全局變量
全局變量是指在所有的環境里面，變量值都是一樣的，全局變量的作用域是所有請求。全局變量設置有兩種方式：
• 點擊界面里設置
• 在腳本里設置
1）界面設置
點擊眼睛圖標后，在 Global 選項菜單點擊 Edit 菜單即可設置全局變量。全局變量的引用格式和環境變量一樣。注意：當環境變量和全局變量名稱一樣時，切換到某個環境時，環境變量會覆蓋全局變量。
2）腳本設置
使用如下腳本可以設置全局變量：variable_key 表示變量名稱， variable_value 表示變量值。
pm.globals.set("variable_key", "variable_value");
案例5：
在實際接口測試過程中，接口經常會有關聯。比如需要取上一個接口的某個返回值，然后作為參數傳遞到下一個接口作為參數。假設我們要獲取 A 接口返回的 userid 值作為 B 接口的請求參數，A接口的返回值如下圖：
根據返回值我們需要從返回值中提取 userid 值。在 Tests標簽欄下編寫如下腳本獲取 userid 值
B 接口請求 URL 如下：請求方式為 GET
postman-echo.com/get?userid={{userid}}
先執行 A 接口的，然后在執行 B 接口，此時 B 接口通過全局變量 userid 可以獲得 A 接口的返回值。
2.6.4 數據變量
數據變量是通過導入外部數據文件（json 文件或者 csv 文件），來獲取變量數據。我們可以創建一個如下內容的 json
文件：
[{ "username": "jack", "passwd": "6666" },{ "username": "Bob", "passwd": "5555" }, { "username": "Marry", "passwd": "8888" }]
要在Postman中使用數據變量，同樣需要遵循與環境或全局變量相同的語法。在后面的文章中，我們再細說如何使用數據變量。
一般來說執行完測試，我們需要對測試結果來進行校驗，判斷結果是是否符合我們的預期，也就是斷言。在接口測試中一般會根據響應狀態碼或者響應返回的數據來進行斷言。Postman 提供一個測試沙箱（Postman Sandbox）， 測試沙箱是一個 JavaScript 執行環境，可以通過 JS 腳本來編寫 pre-request Script 和 test Script。
• pre-request Script（預置腳本）可以用來修改一些默認參數，在請求發送之前執行。有點類似於 unittest里面的 setUp()方法。
• test Script（測試腳本）當接收到響應之后，再執行測試腳本。
常用斷言整理：
1.）判斷請求返回的狀態碼為200，200就是請求狀態正常。
tests["判斷返回的狀態為200"] = responseCode.code === 200;
2.）判斷請求返回的時間小於200ms，一般認證正常的請求應該在200ms之下。
tests["判斷請求返回的時間小於200ms"]= responseTime < 200;
3.）獲取json數據，驗證返回響應中的字段值
以下面的返回數據為例（之后的斷言也是以這個返回為例）：
"status": 1, "res": [ { "id": 39, "from": “東方”, "to": “南方” }, { "id": 38, "from": “西北”, "to": “東南”, }
a. 先獲取到返回的json數據：
var responBody = JSON.parse(responseBody);
b. 斷言status返回的值為1
tests["判斷返回的status返回為1"] = responseBody.status === 1;
c. 斷言res下第一個元素中from的值為東方
tests[“res中第一個元素中from的值正確”] = responseBody.res[0].from === "東方"；
d. 判斷數據返回類型是什么。我大概整理一下幾種類型的：number 、string 、object 、array 、boolean 、undefind。
tests["判斷res下第一個元素中id的返回元素為number"] = typeof(responseBody.res[0].id) === "number";
如果需要判斷其他的類型就可以用同樣的方法更換最后的類型就可以了。
e. 判斷返回數據中是否存在某個元素。這個雖然到現在一直沒用得上，但是也是一個基礎的斷言語句
還是以上面的返回數據為例子，判斷返回元素中是否有status
tests["判斷返回的元素中帶有status"] = responseBody.has("status");
當我們想批量測試某個集合里面的各個 API 時，可以使用 Collection Runner 來批量運行 API，同時可以進行環境變量、迭代執行次數、延遲時間等設置。如下圖所示：
有時我們針對一個接口需要測試很多不同的參數，如果每次一個個的去修改參數值來進行測試這樣效率肯定會比較低下。因此我們需要每次迭代執行傳入不同的參數進行測試，那么需要導入外部數據文件進行參數化，也就是所謂的數據驅動
數據導入如下圖所示，data 選擇之前我們創建的 json 數據文件：data.json，文件類型選擇 application/json ，json 數據內容如下：
[{ "username": "jack", "passwd": "6666" },{ "username": "Bob", "passwd": "5555" }, { "username": "Marry", "passwd": "8888" }]
請求之前延遲時間最好設置為 1000~3000，避免過於頻繁請求被禁。
點擊 Preview 按鈕可以預覽導入的數據。
在使用“Collection Runner”的時候，集合中的請求執行順序就是請求在 Collection 中的顯示排列順序。但是，有的時候我們不希望請求按照這樣的方式去執行，可能是執行完第一個請求，再去執行第五個請求，然后再去執行第二個請求這樣的方式；那么在“Collection Runner”中如何去構建不同的執行順序呢？
最直接的方法就是直接在集合里面拖動調整順序，但是每次去拖動也比較麻煩，特別是當請求比較多的時候。這個時候最高效的方法就是通過腳本設置。設置方法如下：
在第一個請求:Request1 的Tests中添加如下代碼：
postman.setNextRequest('Request 3') 則表示下一個請求為執行請求名稱為 Request3 的請求。
>>>>>>>待續