首頁 > 軟體

使用postman進行介面自動化測試

2022-06-02 22:01:19

我們先思考一下,如果需要達到自動化介面測試的效果,那麼我們在基本的模擬請求上還需要做哪些呢?

以下我粗略概括為 3 個問題(歡迎更多補充與建議):

  • 如何判斷介面是否請求成功
  • 如何進行介面批次、定期測試
  • 如何處理依賴介面問題(比如商品下單的介面必須要求先登入)

所以,接下來就主要分為 3 個部分進行介紹,以分別解決這 3 個問題。

一、介面結果判斷

首先,既然是自動化測試,那麼我們肯定需要工具 (Postman) 或者程式碼能幫我們直接判斷結果是否符合預期。那麼在介面測試上,大體就兩個思路:

  • 判斷請求返回的 code 是否符合預期
  • 判斷請求返回的內容中是否包含預期的內容(關鍵字)

接下來我們看看如何利用 Postman 來解決上述的問題:

1、功能區

在 Postman 中相關的功能在非常顯眼的地方,Tests 功能的使用需要我們有一定的程式語言基礎,目前支援的指令碼語言即為 JavaScript 。

Postman 還為我們提供了一些常用的程式碼模板,在 Tests 面板右邊的 SNIPPETS 功能區中。

2、指令碼相關

先看上圖的程式碼部分,我們可以發現 responseCode 、 responseBody 和 tests 三個變數(可直接使用) :

  • pm.response.code:包含請求的返回的狀態資訊(如:code)
  • pm.response.text(): 為介面請求返回的資料內容(型別為字串)
  • pm.test: 為鍵值對形式,用於表示我們的測試結果成功與否,最終展示在 Test Results 中。
  • key :(如:code 200)我們可以用來當做結果的一個描述
  • value:其值為布林型,ture 表示測試通過, false 表示測試失敗。

所以上述程式碼應該不難理解了,而有了返回結果的資料以及表示結果成功與否的方式,那麼我們“介面結果判斷”的問題也就基本解決了。

另外還有幾個比較常用的:

  • 請求所耗時長 :pm.response.responseTime :
  • 獲取返回資料的頭部資訊:pm.response.to.have.header("”)
  • 設定全域性變數:pm.globals.set("variable_key", "variable_value");
  • 獲取環境變數:pm.environment.get("variable_key");

3、程式碼模板

Postman 在 SNIPPETS 功能區中為我們提供的程式碼模板已經能解決大部分情況了,以下先挑幾個跟結果判斷相關的進行講解:

Status code : Code is 200

pm.test("響應狀態程式碼為200", function () {
 pm.response.to.have.status(200);
});

Response body: Contains string

pm.test("響應主體包含正確的字串", function () {
    pm.expect(pm.response.text()).to.include("有我在的話");
});

Response body: is equal to string

pm.test("響應主體內容完全符合", function () {
    pm.response.to.have.body("主體內容");
});

Response body: JSON value check

pm.test("響應主體內容數值正確", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.value).to.eql(100);
});

響應頭Content-Type 時候存在

pm.test("響應頭Content-Type是存在的", function () {
    pm.response.to.have.header("Content-Type");
});

Response time is less than 200ms

pm.test("響應時間小於200ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(200);
});

為JSON資料使用TinyValidator

var schema = {
 "items": {
 "type": "boolean"
 }
};
var data1 = [true, false];
var data2 = [true, 123];

pm.test('Schema is valid', function() {
  pm.expect(tv4.validate(data1, schema)).to.be.true;
  pm.expect(tv4.validate(data2, schema)).to.be.true;
});

解碼base64編碼資料

var intermediate,
    base64Content, // assume this has a base64 encoded value
    rawContent = base64Content.slice('data:application/octet-stream;base64,'.length);

intermediate = CryptoJS.enc.Base64.parse(base64content); // CryptoJS is an inbuilt object, documented here: https://www.npmjs.com/package/crypto-js
pm.test('Contents are valid', function() {
  pm.expect(CryptoJS.enc.Utf8.stringify(intermediate)).to.be.true; // a check for non-emptiness
});

傳送非同步請求(此函數可作為預請求和測試指令碼使用)

pm.sendRequest("https://postman-echo.com/get", function (err, response) {
    console.log(response.json());
});

將XML主體轉換為JSON物件

var jsonObject = xml2Json(responseBody);

以上介紹的這些基本已經足夠完成對單一介面的測試了,但我們知道如果沒有批次、定時任務, 那麼這些都將毫無意義,繼續…

二、集合(批次)測試

想要進行介面的批次測試、管理,那麼我們需要將待測試的介面全部都儲存到同一個集合(Collections)中,你可以認為就是儲存到同一個資料夾中。先看看 Postman中的操作步驟:

通過以上步驟,我們得到一個待測的介面集合,為了簡化情況,我這邊每個介面成功與否的條件都是用 code 是否為 200 來判斷:

pm.test("響應狀態程式碼為200", function () {
 pm.response.to.have.status(200);
});

1、批次執行

以上準備就緒後,我們就可以開始批次執行介面進行測試了:

點選Run 後,會新開啟一個頁面:

  • Environment :用於切換介面執行的環境。
  • Iteration :用於設定介面一共要執行的次數。
  • Delay : 設定每次執行介面之間的時間間隔,單位為毫秒。
  • Data File : 上傳測試資料檔案。

2、變化的引數資料

我們已經瞭解了,如何讓多個介面迴圈執行多次,但是現在有個問題,按目前這個步驟,每次執行時介面的引數都是一樣的,那麼就算我們執行個100次、1000次意義也不大。

1、使用變數

如下圖:

參照一個變數的語法:{{變數名}}, 圖中可以看到,我們密碼欄位的引數值都設定為變數{{pw}} 。修改完直接點選執行 Send當然是不行的,因為目前這個變數還未被賦值,不過我們可以在 Pre-request Script 面板中進行賦值操作。

2、Pre-request Script

Pre-request Script 與 Tests 類似,區別在於:Pre-request Script 中的指令碼是在執行請求之前執行,而Tests 中的指令碼則是在請求完成之後執行。

所以,我們可以在 Pre-request Script 功能區中用指令碼先個上面兩個變數進行賦值,如:

//設定全域性變數
postman.setGlobalVariable("pw", 「123456」.toString(CryptoJS.enc.Hex).toUpperCase());

但是用 Pre-request Script 進行賦值操作仍然不能解決我們的問題,因為按照這種寫法,不論執行多少次其實都還是用固定(寫死)的資料進行測試。

3、測試資料集

接下來我們講講 “Data File” , 在執行集合前的這個選項就是用來上傳測試資料(檔案)以賦值給相應變數的。我們先以 CSV 格式的測試資料為例:

pw
123456
222222
123456
444444

資料格式類似表格,第一行表示對應的變數名,下面 4 行表示 4 組賬號密碼資料(其中兩組為正確資料) ,我們儲存一份內容為上述範例資料字尾名為.csv 的檔案後,再次開始測試看看效果,我們選擇執行次數為 4 (對應 4 組測試資料)、選擇對應的 CSV 檔案執行後,可以看到我們的結果確實如我們的預期。介面 Request執行的結果為兩次成功兩次失敗,也就是每一次執行都賦值了不同的賬號密碼的測試資料 (在最新的桌面使用者端版本中可以看到每次具體的請求情況,這邊就不再細說了)。

如果使用 Json 檔案的話,那麼格式如下:

[
  {
    "pw": "123456"
  },
  {
    "pw": "222222"
  },
  {
    "pw": "123456"
  },
  {
    "pw": "444444"
  }
]

3、定期任務

Postman 提供了一個 Monitors (監視器)功能,支援我們提交一個測試任務,按照設定的定時器進行執行,如每小時測試一次,具體操作如下:

三、請求依賴問題

講完介面結果判斷和集合批次測試後,我們再來看看比較複雜的情況,即依賴請求問題,比如我們的購物下訂單介面要求必須先登入後才可存取。但大部分依賴問題其實本質上就是一個介面間資料傳遞的問題,比如呼叫登入介面後返回一個標識,假設為 token ,那麼我們請求下訂單介面時只要一起攜帶 token 引數進行請求即可。所以,問題變為:

  • 保證介面呼叫順序
  • 將介面A返回的資料傳遞給後續的介面B、C、D

1、介面執行順序

首先,說明一下,接下來說的介面都是預設屬於同一個集合 (Collections) 中的。

還是以我們上文中建立好介面集合為例,如果你有注意我們執行批次測試的結果,就會發現介面的執行順序其實就是按照這邊目錄中的順序(從上到下),即:

Request1 -> Request2 -> Request3

所以有了這個預設的執行順序後,那麼我們便可以把需要優先執行的介面放前面即可,比如把“登入介面”放在第一個。也可以在測試時拖動介面順序,調整介面執行順序。

2、資料傳遞

在講資料傳遞前,先聊聊 Postman 中全域性變數、環境切換的使用。

1、全域性變數

全域性變數的概念其實我們在上文中講 Pre-request Script 時有簡單提到,也就是說我們可以通過指令碼程式碼來設定全域性變數,我們可以看看執行上文的指令碼後的效果:

我們可以看到執行後, pw兩個變數已經被成功儲存下來,那麼我們在任意介面中便都可以通過變數參照的語法如:{{pw}} 來使用它們。

另外,Postman 不僅支援程式碼設定全域性變數的方式,它還支援視覺化操作:

進入對應介面後,便可直接進行管理:

2、多環境區分與切換

通常情況下,我們的介面都會分為測試版本和線上版本(或者更多),而他們的區別可能僅是 ULR 不同,那麼全域性變數便不大合適解決這個問題。

3、變數的建立

可能你已經注意到,上圖中我已經建有幾個不同環境的變數“集合”了,再看一下:

我在每個環境中都建立了一個 host 變數,如:

當然,我們的環境引數也可以通過指令碼的方式來進行設定,函數為:

//注意,該引數只新增到你當前選擇的環境的「引數集」中
postman.setEnvironmentVariable("variable_key", "variable_value");

4、使用與切換

環境“引數集” 中的引數使用方式和全域性變數一致,如圖中 {{host}} ,不同環境的切換見下圖:

3、解決依賴問題

掌握以上的預備知識後,我們開始看看如何用 Postman 解決存在依賴關係的介面測試。

1、假設場景

我們的介面 Request1 為登入介面,登入成功將會返回一個 access_token 欄位作為標識(已實現)。那麼假設介面 Request3 為一個下訂單的介面,需要攜帶登入返回的 access_token 才能正常存取。

2、思路

  • 保證 Request1 在 Request3 之前被執行
  • 將 Request1 返回的 access_token 的值新增到環境變數"引數集"中。
  • Request3 在請求時參照 access_token 的值

將返回值存在 “全域性變數” 或者 “環境變數” 中,視具體業務情況而定,該例中 access_token 的值是與環境有關的,所以這裡選擇使用環境變數集儲存。

3、Postman 中的操作

我們目錄中已保證 Request1 介面優先執行,

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")
}

在介面Request3 中使用變數 token : 

我這邊是將 token 放在頭部資訊中, 具體使用方式時介面引數規則而定。

4、執行並檢視結果

執行集合測試,可以看到我們結果符合我們的預期,Request1Request3 通過測試,Request2 被跳過,Request4 仍被執行。

到此這篇關於使用postman進行介面自動化測試的文章就介紹到這了。希望對大家的學習有所幫助,也希望大家多多支援it145.com。


IT145.com E-mail:sddin#qq.com