Postman使用詳解

前言：

Postman是一款功能強大的網頁調試與發送網頁HTTP請求的Chrome插件。

接口請求流程

---

1、get請求

GET請求：點擊Params，輸入參數及value，可輸入多個，即時顯示在URL連接上，因此，GET請求的請求頭與請求參數如在接口文檔中無特別聲明時，能夠不填。

get請求示例

GET響應：右上角顯示響應HTTP狀態碼、請求的耗時。

get響應示例

需特別注意的是注意區別HTTP狀態碼與響應正文中的狀態碼，只有HTTP狀態碼是200時，才表明這個接口請求是正確的，這個是HTTP協議定義的，而響應正文的狀態碼，是程序員自已定義的，能夠是200，也能夠定義爲其它值，是爲了讓接口使用者去區分正常數據與異常數據。

狀態碼與響應碼不一致

---

2、POST請求

一、POST請求一：表單提交

先看下圖POST表單提交示例：

表單提交示例

上圖示例中設置了請求方法，請求URL，請求參數，但沒有設置請求頭。有一個要明確的點是，請求頭中的Content-Type與請求參數的格式之間是有關聯關係的。

Content-Type與請求參數的格式之間的關聯

當選擇x-www-form-urlencoded的參數方式後，postman自動的幫咱們設置了Content-Type，因此不須要咱們人工干預，這就是使用一款流行工具的好處，把一些基礎點都幫咱們處理了。

二、POST請求二：json提交

先看下圖json提交示例：

json提交示例

上圖中，當咱們選擇了JSON(application/json)時，postman一樣幫咱們自動設置了Content-Type，能夠自行的去查看Headers.

三、post請求三：xml提交

先看下圖XML提交示例：

XML提交示例

上圖中，當咱們選擇了XML(text/xml)時，postman一樣幫咱們自動設置了Content-Type，能夠自行的去查看Headers.

四、post請求四：自行設置Content-Type

HTTP的POST請求的參數，都是放在請求正文中的，只是根據Content-Type來判斷請求正文的格式，那麼咱們一樣能夠在表單提交時，選擇raw，而後自行設置Content-Type爲application/x-www-form-urlencoded。

POST請求的參數

自行設置Content-Type

五、POST請求五：二進制文件提交

先看下圖二進制文件示例：

二進制文件提交

Body下，選擇binary，在這裏你能夠發送視頻、音頻、文本等文件。

---

3、postman斷言

一個完整的接口測試，包括：請求->獲取響應正文->斷言，咱們已經知道了請求與獲取響應正文，下面來介紹如何用postman進行斷言。

Tests

這個」Tests」就是咱們須要處理斷言的地方，postman很人性化的幫咱們把斷言所用的函數全給準備好了：

SNIPPETS

---

舉例說明：首先設置一個斷言場景，根據斷言場景來舉例說明Postman斷言如何使用。

一、判斷HTTP返回狀態碼爲200

二、判斷響應正文中是否包含："statusCode":200

三、解析響應正文，並判斷statusCode的值是200，message的值是」Success」

---

---

第一步：在SNIPPETS中，往下拉，有一項」Status code:Code is 200」，這個就是爲場景中的第 1 條準備的，判斷HTTP返回狀態碼是否爲200。點擊這一項，能夠看到在其左邊，斷言代碼自動添加，見下圖：

Status code

解釋一下這句代碼的意思：

tests["Status code is 200"]中的tests是一個內置對象，tests["Status code is 200"]是指爲這個斷言起個名稱叫」Status code is 200」，這個名稱能夠自行修改。

responseCode.code === 200中的responseCode是內置對象，responseCode對象中有個屬性是code，是指HTTP狀態碼的code，判斷code是否爲200.

綜合起來，這句代碼的意思是：名稱爲」Status code is 200」的斷言中，判斷responseCode對象的code屬性值（HTTP狀態碼）是否爲200。

---

第二步：一樣在SNIPPETS中，找到一項」Response body:Contains string」，這個就是爲場景中的第2條準備的，判斷響應正文中的字段。點擊後，在其左邊，斷言代碼自動添加，見下圖：

Contains string1

其中咱們須要修改想要在響應報文中找到的內容：

tests["Body matches string"] = responseBody.has('"statusCode":200');    //對照第2條場景：判斷響應正文中是否包含："statusCode":200

Contains string2

---

第三步：咱們須要解析JSON串了，因此，在SNIPPETS中找到」Response body:JSON value check」並點擊，在其左邊，斷言代碼自動添加，見下圖：

JSON value check1

咱們能夠看出，這裏面實際上是JS代碼，jsonData變量實際上是解析完JSON後的對象，在JS中，一個JSON對象獲取其屬性的值，直接是用jsonData.value，因而，咱們把代碼給修改一下，來判斷第3條場景：

tests["response statusCode"] = jsonData.statusCode === 200;  //判斷statusCode的值是200

tests["response message"] = jsonData.message === 'Success';  //判斷message的值是」Success」

JSON value check2

---

這樣一來，咱們能夠看到一共有Tests的斷言4個，點擊Send，發送請求，在響應區內能夠看到以下圖：表示斷言所有經過。

---

以上，SNIPPETS中還有不少的函數提供給咱們,努力學習吧~~~

---

4、管理用例---Collections

Collections集合：也就是將多個接口請求能夠放在一塊兒，並管理起來。什麼樣的接口請求能夠放在同一個collection裏？

在這裏告訴你們能夠這樣：一個工程一個Collection，這樣方便查找及統一處理數據。

第一步：建立Collections

點擊上圖中的帶+號的圖標，輸入Name:」demo」，Description:」demo for Collections」，點擊Create按鈕即建立成功一個Collections.

Create Collections

第二步，在Collections裏添加請求

在右側準備好接口請求的全部數據，並驗證後，點擊save按鈕。

save按鈕

選擇Collection及填寫好Request name、Request description後，點擊右下角的save to collection按鈕，則該請求被添加到Collection中。

save request

添加成功後，可在左側列表中，collection中查看剛剛添加的請求。

第三步：Collection精細化---Folder

隨着放入Collection的請求愈來愈多，混亂就又出現了，在找一個請求時，要找半天，因而將collection中的請求分門類別就很重要了，因而，在collection中就能夠添加Folder了，將相同場景的請求放入同一個Folder中，因而就實現了模塊化的管理了。

點擊下圖中的Add Folder後，便可建立Folder。

Add Folder按鈕位置

添加上Folder name，即模塊名稱後，點擊Create，建立成功一個Folder。

add Folder

接下來，只須要把相同場景的請求拖入相同的Folder便可，這樣就實現了模塊化的管理了。模塊化之後的結構：

模塊化的管理結構

第四步：運行Collection

將工程模塊化的用例管理起來後，藉着這個管理起來的東風，也能夠將工程模塊化的用例執行起來，即一次執行一整個collection裏的用例，或者執行一個collection裏的某一個Folder裏的用例。

點擊下圖中的Run：

run

下圖中的」Choose collection or folder」，若是選擇demo，表示運行demo這一整個collection的用例，若是選擇GET，即只運行demo下的GET模塊下的用例。

Environment，即運行環境，是開發環境仍是測試環境，需事先配置，你們能夠下去自已嘗試一下。

Iterations，即重複運行次數。會將選擇好的collection中folder重複運行。

Delay，間隔時間。用例與用例間的間隔時間。

Data，外部數據加載，即用例的參數化，能夠與Iterations結合起來用，實現參數化，也就是數據驅動。

Run Demo，點擊運行，運行完成後，便可得出一個簡易的聚合報告。

第五步：Collection運行參數化

在Iterations重複運行時，若是某個用例但願每次運行時，使用不一樣的數據，那麼應該知足以下2個條件：

一、腳本中要用到數據的地方參數化，即用一個變量來代替，每次運行時，從新獲取當前的運行數據。

二、須要有一個數據池，這個數據池裏的數據條數，要與重複運行的次數相同。

---

Postman的runner給咱們提供了Iterations的輸入項，也提供了Data的文件選擇項，也就是意味着數據池是一個外部文件。

若是Iterations裏的值爲2，那麼，這個外部文件裏也應該有兩條數據，postman但願咱們這個外部文件裏的數據是一個json（固然也能夠是其它

數據格式）.

爲了表示兩條數據，這個json應該是一個list結構(以下圖)，同時，因爲腳本要用到數據的地方須要參數化，須要變量，因此，每一條數據應該就是一個map，map的key對應腳本中的變量。

外部文件裏的數據

上圖中表示提供了一個msg的變量，每次運行對應不一樣的值，預示着在腳本中能夠用到msg這個變量，那在腳本中如何用？

使用變量

如上圖斷言中用data.msg，其中data是個內置對象，即表明每一次運行的那個map數據，因此，能夠用data.msg來獲取每次運行的對應的值，固然，因爲是個map，也能夠用data[‘msg’]來獲取對應的值。

---

5、設置環境變量

有時須要在不一樣的環境下跑相同的測試，此時能夠經過設置環境變量來動態選擇。點擊右上角的設置按鈕-Manage Environments：

Manage Environments

填寫該環境的名稱：如測試環境，並在key和value中填寫須要的鍵值。

add1

add2

使用這些鍵值的時候只須要加上兩個花括號引用key，例如： {{url_base}}/admin/offer/

引用key

創建多個環境時，key一般都是相同的，只是value不一樣。建立好全部環境後，在跑用例的時候在右上角下拉列表選擇須要的環境就能夠了。

選擇環境變量

---

6、身份驗證Authentication

顯示browser cookies，須要開啓Interceptor。點擊右上角的Interceptor 進行安裝，並開啓：

Interceptor

身份驗證Authentication：

postman有一個helpers能夠幫助咱們簡化一些重複和複雜的任務。當前的一套helpers能夠幫助你解決一些authentication protocols的問題。

一、Basic Auth

填寫用戶名和密碼，點擊update request後，headers中自動添加Authorization。圖中用戶名和密碼均使用的key變量：

Basic Auth

二、Digest Auth

要比Basic Auth複雜的多。使用當前填寫的值生成authorization header。因此在生成header以前要確保設置的正確性。若是當前的header已經存在，postman會移除以前的header。

三、OAuth 1.0

postman的OAuth helper讓你簽署支持OAuth

1.0基於身份驗證的請求。OAuth不用獲取access token,你須要去API提供者獲取的。OAuth 1.0能夠在header或者查詢參數中設置value。

四、OAuth 2.0

postman支持得到OAuth 2.0 token並添加到requests中。

---

---

postman居然如此之強大！咱們還有什麼理由去拒絕？介紹完以後，可能新的問題又來了，如何與jenkins結合實現持續集成？

因此，產生了個newman，是個命令行運行postman請求的工具，建議你們自行去研究下，由於那確實就只是個命令行的工具而已！