[轉]postman 使用

轉自: https://www.cnblogs.com/yunman/p/7884537.html

前言:

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

接口請求流程


一、get請求

GET請求:點擊Params,輸入參數及value,可輸入多個,即時顯示在URL鏈接上,所以,GET請求的請求頭與請求參數如在接口文檔中無特別聲明時,可以不填。

get請求示例

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

get響應示例

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

狀態碼與響應碼不一致


二、POST請求

1、POST請求一:表單提交

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

表單提交示例

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

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

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

2、POST請求二:json提交

先看下圖json提交示例:

json提交示例

上圖中,當我們選擇了JSON(application/json)時,postman同樣幫我們自動設置了Content-Type,可以自行的去查看Headers.

3、post請求三:xml提交

先看下圖XML提交示例:

XML提交示例

上圖中,當我們選擇了XML(text/xml)時,postman同樣幫我們自動設置了Content-Type,可以自行的去查看Headers.

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

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

POST請求的參數

自行設置Content-Type

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

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

二進制文件提交

Body下,選擇binary,在這裏你可以發送視頻、音頻、文本等文件。


三、postman斷言

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

Tests

這個”Tests”就是我們需要處理斷言的地方,postman很人性化的幫我們把斷言所用的函數全給準備好了:

SNIPPETS


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

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

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

3、解析響應正文,並判斷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中還有很多的函數提供給我們,努力學習吧~~~


四、管理用例---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個條件:

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

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’]來獲取對應的值。


五、設置環境變量

有時需要在不同的環境下跑相同的測試,此時可以通過設置環境變量來動態選擇。點擊右上角的設置按鈕-Manage Environments:

Manage Environments

填寫該環境的名稱:如測試環境,並在key和value中填寫需要的鍵值。

add1

add2

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

引用key

建立多個環境時,key通常都是相同的,只是value不同。創建好所有環境後,在跑用例的時候在右上角下拉列表選擇需要的環境就可以了。

選擇環境變量


六、身份驗證Authentication

顯示browser cookies,需要開啓Interceptor。點擊右上角的Interceptor 進行安裝,並開啓:

Interceptor

身份驗證Authentication:

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

1、Basic Auth

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

Basic Auth

2、Digest Auth

要比Basic Auth複雜的多。使用當前填寫的值生成authorization header。所以在生成header之前要確保設置的正確性。如果當前的header已經存在,postman會移除之前的header。

3、OAuth 1.0

postman的OAuth helper讓你簽署支持OAuth

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

4、OAuth 2.0

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



postman竟然如此之強大!我們還有什麼理由去拒絕?介紹完之後,可能新的問題又來了,如何與jenkins結合實現持續集成?

所以,產生了個newman,是個命令行運行postman請求的工具,建議大家自行去研究下,因爲那確實就只是個命令行的工具而已!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章