本文適合已經掌握 Postman
基本用法的讀者,即對接口相關概念有一定了解、已經會使用 Postman
進行模擬請求等基本操作。
工作環境與版本:
-
Window 7(64位)
-
Postman (Chrome App v5.5.3)
P.S. 不同版本頁面 UI 和部分功能位置會有點不同,不過影響不大。
首先我們來思考一下,如果要達到自動化接口測試效果,在基本的模擬請求上還需要做哪些呢?
我粗略概括爲 3 個問題(歡迎在評論區留言更多補充建議):
1. 如何判斷接口是否請求成功?
2. 如何進行接口批量、定期測試?
3. 如何處理依賴接口問題(比如商品下單的接口必須要求先登錄)?
所以,接下來就主要分爲 3 個部分,介紹如何解決這 3 個問題。
接口結果判斷
首先,既然是自動化測試,那麼我們肯定需要通過工具 Postman
或者代碼,幫我們直接判斷結果是否符合預期。那麼在接口測試上,大體就兩個思路:
1. 判斷請求返回的 code
是否符合預期
2. 判斷請求返回的內容中是否包含預期的內容(關鍵字)
接下來我們看看如何利用 Postman
來解決上述的問題:
在 Postman
中相關的功能在非常顯眼的地方,Tests
功能的使用需要我們有一定的編程語言基礎,目前支持的腳本語言即爲 JavaScript
。但比較好的一點是,我們不需要再去考慮上下文問題以及運行環境的問題 ,也就是說我們只需要在這邊完成結果邏輯判斷的代碼塊即可。
而 Postman
還爲我們提供了一些常用的代碼模板,在 Tests
面板右邊的 SNIPPETS
功能區中,所以對 JavaScript
不大瞭解問題也不大。代碼編寫相關將在下文進行具體介紹。
先看上圖的代碼部分,我們可以發現 responseCode
、 responseBody
和 tests
三個變量(可直接使用) :
-
responseCode
:包含請求的返回的狀態信息(如:code)。 -
responseBody
:爲接口請求放回的數據內容(類型爲字符串)。 -
tests
:爲鍵值對形式,用於表示我們的測試結果是成功與否,最終展示在Test Results
中。 -
key :(如:code 200)我們可以用來當做結果的一個描述。
-
value:其值爲布爾型,
ture
表示測試通過,false
表示測試失敗。
所以上述代碼應該不難理解了,而有了返回結果的數據以及表示結果成功與否的方式,那麼我們“接口結果判斷”的問題也就基本解決了。
另外還有幾個比較常用的:
-
responseTime
:請求所耗時長 -
postman
:可以做的比較多,比如 -
獲取返回數據的頭部信息:
`postman.getResponseHeader("")` -
設置全局變量:
`postman.setGlobalVariable("variable_key", "variable_value");`
更多功能可以查看官方文檔。
Postman
在 SNIPPETS
功能區中爲我們提供的代碼模板已經能解決大部分情況了,以下先挑幾個跟結果判斷相關的進行講解:
Status code : Code is 200
//根據返回的 Code 判斷請求情況
tests["Status code is 200"] = responseCode.code === 200;
Response body: Contains string
//判斷返回的內容中是否存在“關鍵字”。(tests 的 key 可修改,將不再強調)
tests["Body matches string"] = responseBody.has("這裏可以改爲你要判斷的關鍵字內容");
//如上文提到的:
//判斷結果中是否存在 access_token 關鍵字
tests["has access_token"] = responseBody.has("access_token");
Response body: is equal to string
//判斷返回內容是否跟預期完全相等。
tests["Body is correct"] = responseBody === "這裏可以改爲你的預期內容";
Response body: JSON value check
//上文提到,responseBody 爲字符串類型,支持轉爲 Json 格式
var jsonData = JSON.parse(responseBody);
tests["Your test name"] = jsonData.value === 100;
Response time is less than 200ms
//判斷請求時長是否小於200ms ,具體時長按情況自定義
tests["Response time is less than 200ms"] = responseTime < 200;
以上介紹的這些基本已經足夠完成對單一接口的測試了,但我們知道如果沒有批量、定時任務, 那麼這些都將毫無意義,所以繼續 …
集合(批量)測試
想要進行接口的批量測試、管理,那麼我們需要將待測試的接口全部都保存到同一個集合(Collections)
中,你可以認爲就是保存到同一個文件夾中。先看看 Postman
中的操作步驟:
通過以上步驟,我們得到一個待測的接口集合,爲了簡化情況,我這邊每個接口成功與否的條件都是用 code
是否爲 200 來判斷:
tests["Status code is 200"] = responseCode.code === 200;
以上準備就緒後,我們就可以開始批量運行接口進行測試了:
點擊Run
後,會新打開一個頁面:
-
Environment
:用於切換接口運行的環境,這裏先不管,後面再講 -
Iteration
:用於設置接口一共要運行的次數。 -
Delay
: 設置每次運行接口之間的時間間隔,單位爲毫秒。 -
Data File
: 上傳測試數據文件 (下文單獨講)
我們已經瞭解了,如何讓多個接口循環運行多次,但是現在有個問題,按目前這個步驟,每次運行時接口的參數都是一樣的,那麼就算我們運行個100次、1000次意義也不大。
先看看我們寫好的一個登錄功能的接口:
使用變量
現在登錄的賬號和密碼參數都是寫死的,也就是不過我們執行多少次,都是拿這個賬號去測試。那麼如果想要測試賬號密碼參數使用其它值有沒有異常怎麼辦呢?( 想要每次都手動改的可以跳過這部分 /手動滑稽)這裏我們先簡單講一下在 Postman
中使用如何“變量”,如下圖:
引用一個變量的語法:{{變量名}}, 圖中可以看到,我們將賬戶和密碼字段的參數值都設置爲變量:{{username}} 、{{password}}
。修改完直接點擊運行 (Send)
當然是不行的,因爲目前這兩個變量還未被賦值,不過我們可以在 Pre-request Script
面板中進行賦值操作:
Pre-request Script
Pre-request Script
與 Tests
類似,區別在於:Pre-request Script
中的腳本是在執行請求之前運行,而Tests
中的腳本則是在請求完成之後執行。所以,我們可以在 Pre-request Script
功能區中用腳本先個上面兩個變量進行賦值,如:
//設置全局變量
postman.setGlobalVariable("username", "test1");
postman.setGlobalVariable("password", "123456");
但是用 Pre-request Script
進行賦值操作仍然不能解決我們的問題,因爲按照這種寫法,不論運行多少次其實都還是用固定(寫死)的數據進行測試。當然既然是腳本語言,也會有更靈活的用法,這邊先不將。
測試數據集
接下來我們講講 Data File
, 在運行集合前的這個選項就是用來上傳測試數據(文件)以賦值給相應變量的。我們先以 CSV
格式的測試數據爲例:
username,password
test1,123456
test2,222222
test3,123456
test4,444444
數據格式類似表格,第一行表示對應的變量名,下面 4 行表示 4 組賬號密碼數據(其中兩組爲正確數據) ,我們保存一份內容爲上述示例數據後綴名爲.csv
的文件後,再次開始測試看看效果,我們選擇運行次數爲 4 (對應 4 組測試數據)、選擇對應的 CSV
文件運行後,可以看到我們的結果確實如我們的預期。接口 Request
運行的結果爲兩次成功兩次失敗,也就是每一次運行都賦值了不同的賬號密碼的測試數據 (在最新的桌面客戶端版本中可以看到每次具體的請求情況,這邊就不再細說了)。
如果使用 Json
文件的話,那麼格式如下:
[
{
"username": "test1",
"password": "123456"
},
{
"username": "test2",
"password": "222222"
},
{
"username": "test3",
"password": "123456"
},
{
"username": "test4",
"password": "444444"
}
]
Postman
提供了一個 Monitors
(監視器)功能,支持我們提交一個測試任務,按照設置的定時器進行運行,如每小時測試一次,具體操作如下:
請求依賴問題
講完接口結果判斷和集合批量測試後,我們再來看看比較複雜的情況,即依賴請求問題,比如我們的購物下訂單接口要求必須先登錄後纔可訪問。但大部分依賴問題其實本質上就是一個接口間數據傳遞的問題,比如調用登錄接口後返回一個標識,假設爲 token
,那麼我們請求下訂單接口時只要一起攜帶 token
參數進行請求即可。所以,問題變爲:
-
保證接口調用順序
-
將接口A返回的數據傳遞給後續的接口B、C、D
首先,說明一下,接下來說的接口都是默認屬於同一個集合 (Collections)
中的。
還是以我們上文中創建好接口集合爲例,如果你有注意我們執行批量測試的結果,就會發現接口的執行順序其實就是按照這邊目錄中的順序(從上到下),即: Request1 -> Request2 -> Request3
。
這邊接口名字可能有點誤導性,所以再強調一下:按目錄中從上到下的順序執行 (與字典排序無關)
所以有了這個默認的執行順序後,那麼我們便可以把需要優先執行的接口放前面即可,比如把“登錄接口”放在第一個。
自定義執行順序
當然,如果只有默認的一個執行順序的話,通常沒法滿足我們複雜的業務需求,所以 Postman
爲我們提供了一個函數:postman.setNextRequest("填寫你要跳轉的接口名")
,支持我們跳轉到指定接口繼續執行,舉個例子:
我們在運行完 Request1
接口成功後,不需要再運行 Request2
而是直接跳至 Request3
,那麼我可以在 Request1
接口的 Tests
功能區中執行跳轉代碼,如:
這裏需要注意幾點:
1. postman.setNextRequest()
只在運行集合測試的時候生效,也就是說我們單獨運行 (Send)
接口Request1
時,函數是不起作用的。
2. 當我們運行集合測試成功從 Request1 -> Request3
後,如果 Request3
後面還有接口,那麼後面的接口仍然繼續按默認順序執行,即圖中的接口 Request4
仍會被執行。
3. 指定的跳轉接口必須屬於同一個集合中。
4. setNextRequest()
函數不管在 Tests
腳本中何處被調用,它都只在當前腳本最後才被真正執行。比如我們將圖中的第二行與第一行互調後,那麼在運行跳轉函數後第二行代碼仍會被執行。
所以,利用 setNextRequest()
函數,我們便可以按照條件跳過不必要的接口,或者建立我們自己的一個邏輯測試。
在講數據傳遞前,先聊聊 Postman
中全局變量、環境切換的使用。
全局變量
全局變量的概念其實我們在上文中講 Pre-request Script
時有簡單提到,也就是說我們可以通過腳本代碼來設置全局變量,我們可以看看運行上文的腳本後的效果:
我們可以看到運行後,username
和 password
兩個變量已經被成功保存下來,那麼我們在任意接口中便都可以通過變量引用的語法如:{{username}}
來使用它們。
另外,Postman
不僅支持代碼設置全局變量的方式,它還支持可視化操作:
進入對應界面後,便可直接進行管理:
多環境區分與切換
通常情況下,我們的接口都會分爲測試版本和線上版本(或者更多),而他們的區別可能僅是 ULR
不同,那麼全局變量便不大合適解決這個問題。
參數的創建
可能你已經注意到,上圖中我已經建有幾個不同環境的參數“集合”了,再看一下:
我在每個環境中都創建了一個 host
參數,如:
當然,我們的環境參數也可以通過腳本的方式來進行設置,函數爲:
//注意,該參數只添加到你當前選擇的環境的“參數集”中
postman.setEnvironmentVariable("variable_key", "variable_value");
使用與切換
環境“參數集” 中的參數使用方式和全局變量一致,如圖中 {{host}}
,不同環境的切換見下圖:
掌握以上的預備知識後,我們開始看看如何用 Postman
解決存在依賴關係的接口測試。
假設場景
我們的接口 Request1
爲登錄接口,登錄成功將會返回一個 access_token
字段作爲標識(已實現)。那麼假設接口 Request3
爲一個下訂單的接口,需要攜帶登錄返回的 access_token
才能正常訪問。
思路
1. 保證 Request1
在 Request3
之前被運行
2. 將 Request1
返回的 access_token
的值添加到環境變量"參數集"中。
3. Request3
在請求時引用 access_token
的值
將返回值存在 “全局變量” 或者 “環境變量” 中,視具體業務情況而定,該例中
access_token
的值是與環境有關的,所以這裏選擇使用環境變量集存儲。
Postman 中的操作
1. 我們目錄中已保證 Request1
接口優先執行
2. Request1
中 Tests
的代碼情況:
if(responseCode.code === 200 && responseBody.has("access_token")){
//如果 code 爲 200, 並且返回的數據中存在 access_token 關鍵字,則認爲登錄成功
tests["login"] = true;
//將返回的內容轉爲 json 格式,並且取到 access_token 內容,添加到環境變量中
var jsonData = JSON.parse(responseBody);
//access_token的取值方式視具體的 json 數據結構而定
postman.setEnvironmentVariable("token",jsonData.result.access_token);
//跳轉到 Request3 接口
postman.setNextRequest("Request3")
}else{
tests["login"] = false;
//登錄失敗,可以選擇跳轉到對應失敗後的處理接口進行測試
//postman.setNextRequest("Other Request")
}
3. 在接口 Request3
中使用變量 token
:
> 我這邊是將 `token` 放在頭部信息中, 具體使用方式時接口參數規則而定。
運行並查看結果
運行集合測試,可以看到我們結果符合我們的預期,Request1
和 Request3
通過測試,Request2
被跳過,Request4
仍被執行。Done…
原文鏈接:
https://blog.csdn.net/cai_iac/article/details/81030619
搜索微信公衆號:TestingStudio 霍格沃茲的乾貨都很硬核