?我們先思考一下，如果需要達(dá)到自動化接口測試的效果，那么我們在基本的模擬請求上還需要做哪些呢？

以下我粗略概括為 3 個(gè)問題（歡迎更多補(bǔ)充與建議）：

• 如何判斷接口是否請求成功
• 如何進(jìn)行接口批量、定期測試
• 如何處理依賴接口問題（比如商品下單的接口必須要求先登錄）

所以，接下來就主要分為 3 個(gè)部分進(jìn)行介紹，以分別解決這 3 個(gè)問題。

一、接口結(jié)果判斷

首先，既然是自動化測試，那么我們肯定需要工具 (Postman) 或者代碼能幫我們直接判斷結(jié)果是否符合預(yù)期。那么在接口測試上，大體就兩個(gè)思路：

• 判斷請求返回的 code 是否符合預(yù)期
• 判斷請求返回的內(nèi)容中是否包含預(yù)期的內(nèi)容（關(guān)鍵字）

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

1、功能區(qū)

在 Postman 中相關(guān)的功能在非常顯眼的地方，Tests 功能的使用需要我們有一定的編程語言基礎(chǔ)，目前支持的腳本語言即為 JavaScript 。

Postman 還為我們提供了一些常用的代碼模板，在 Tests 面板右邊的 SNIPPETS 功能區(qū)中。

2、腳本相關(guān)

先看上圖的代碼部分，我們可以發(fā)現(xiàn) responseCode 、 responseBody 和 tests 三個(gè)變量（可直接使用） ：

• pm.response.code：包含請求的返回的狀態(tài)信息(如：code)
• pm.response.text()： 為接口請求返回的數(shù)據(jù)內(nèi)容（類型為字符串）
• pm.test： 為鍵值對形式，用于表示我們的測試結(jié)果成功與否，最終展示在 Test Results 中。
• key ：（如：code 200）我們可以用來當(dāng)做結(jié)果的一個(gè)描述
• value：其值為布爾型，ture 表示測試通過， false 表示測試失敗。

所以上述代碼應(yīng)該不難理解了，而有了返回結(jié)果的數(shù)據(jù)以及表示結(jié)果成功與否的方式，那么我們“接口結(jié)果判斷”的問題也就基本解決了。

另外還有幾個(gè)比較常用的：

• 請求所耗時(shí)長 :pm.response.responseTime ：
• 獲取返回?cái)?shù)據(jù)的頭部信息：pm.response.to.have.header("”)
• 設(shè)置全局變量：pm.globals.set("variable_key", "variable_value");
• 獲取環(huán)境變量:pm.environment.get("variable_key");

3、代碼模板

Postman 在 SNIPPETS 功能區(qū)中為我們提供的代碼模板已經(jīng)能解決大部分情況了，以下先挑幾個(gè)跟結(jié)果判斷相關(guān)的進(jìn)行講解：

Status code : Code is 200

pm.test("響應(yīng)狀態(tài)代碼為200", function () {
 pm.response.to.have.status(200);
});

Response body: Contains string

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

Response body: is equal to string

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

Response body: JSON value check

pm.test("響應(yīng)主體內(nèi)容數(shù)值正確", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.value).to.eql(100);
});

響應(yīng)頭Content-Type 時(shí)候存在

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

Response time is less than 200ms

pm.test("響應(yīng)時(shí)間小于200ms", function () {
    pm.expect(pm.response.responseTime).to.be.below(200);
});

為JSON數(shù)據(jù)使用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編碼數(shù)據(jù)

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

發(fā)送異步請求(此函數(shù)可作為預(yù)請求和測試腳本使用)

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

將XML主體轉(zhuǎn)換為JSON對象

var jsonObject = xml2Json(responseBody);

以上介紹的這些基本已經(jīng)足夠完成對單一接口的測試了，但我們知道如果沒有批量、定時(shí)任務(wù), 那么這些都將毫無意義，繼續(xù)…

二、集合(批量)測試

想要進(jìn)行接口的批量測試、管理，那么我們需要將待測試的接口全部都保存到同一個(gè)集合（Collections）中，你可以認(rèn)為就是保存到同一個(gè)文件夾中。先看看 Postman中的操作步驟：

通過以上步驟，我們得到一個(gè)待測的接口集合，為了簡化情況，我這邊每個(gè)接口成功與否的條件都是用 code 是否為 200 來判斷：

pm.test("響應(yīng)狀態(tài)代碼為200", function () {
 pm.response.to.have.status(200);
});

1、批量執(zhí)行

以上準(zhǔn)備就緒后，我們就可以開始批量運(yùn)行接口進(jìn)行測試了：

點(diǎn)擊Run 后，會新打開一個(gè)頁面：

• Environment ：用于切換接口運(yùn)行的環(huán)境。
• Iteration ：用于設(shè)置接口一共要運(yùn)行的次數(shù)。
• Delay : 設(shè)置每次運(yùn)行接口之間的時(shí)間間隔，單位為毫秒。
• Data File : 上傳測試數(shù)據(jù)文件。

2、變化的參數(shù)數(shù)據(jù)

我們已經(jīng)了解了，如何讓多個(gè)接口循環(huán)運(yùn)行多次，但是現(xiàn)在有個(gè)問題，按目前這個(gè)步驟，每次運(yùn)行時(shí)接口的參數(shù)都是一樣的，那么就算我們運(yùn)行個(gè)100次、1000次意義也不大。

1、使用變量

如下圖：

引用一個(gè)變量的語法：{{變量名}}， 圖中可以看到，我們密碼字段的參數(shù)值都設(shè)置為變量{{pw}} 。修改完直接點(diǎn)擊運(yùn)行 Send當(dāng)然是不行的，因?yàn)槟壳斑@個(gè)變量還未被賦值，不過我們可以在 Pre-request Script 面板中進(jìn)行賦值操作。

2、Pre-request Script

Pre-request Script 與 Tests 類似，區(qū)別在于：Pre-request Script 中的腳本是在執(zhí)行請求之前運(yùn)行，而Tests 中的腳本則是在請求完成之后執(zhí)行。

所以，我們可以在 Pre-request Script 功能區(qū)中用腳本先個(gè)上面兩個(gè)變量進(jìn)行賦值，如:

//設(shè)置全局變量
postman.setGlobalVariable("pw", “123456”.toString(CryptoJS.enc.Hex).toUpperCase());

但是用 Pre-request Script 進(jìn)行賦值操作仍然不能解決我們的問題，因?yàn)榘凑者@種寫法，不論運(yùn)行多少次其實(shí)都還是用固定（寫死）的數(shù)據(jù)進(jìn)行測試。

3、測試數(shù)據(jù)集

接下來我們講講 “Data File” , 在運(yùn)行集合前的這個(gè)選項(xiàng)就是用來上傳測試數(shù)據(jù)（文件）以賦值給相應(yīng)變量的。我們先以 CSV 格式的測試數(shù)據(jù)為例：

pw
123456
222222
123456
444444

數(shù)據(jù)格式類似表格，第一行表示對應(yīng)的變量名，下面 4 行表示 4 組賬號密碼數(shù)據(jù)（其中兩組為正確數(shù)據(jù)） ，我們保存一份內(nèi)容為上述示例數(shù)據(jù)后綴名為.csv 的文件后，再次開始測試看看效果，我們選擇運(yùn)行次數(shù)為 4 （對應(yīng) 4 組測試數(shù)據(jù)）、選擇對應(yīng)的 CSV 文件運(yùn)行后，可以看到我們的結(jié)果確實(shí)如我們的預(yù)期。接口 Request運(yùn)行的結(jié)果為兩次成功兩次失敗，也就是每一次運(yùn)行都賦值了不同的賬號密碼的測試數(shù)據(jù) （在最新的桌面客戶端版本中可以看到每次具體的請求情況，這邊就不再細(xì)說了）。

如果使用 Json 文件的話，那么格式如下：

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

3、定期任務(wù)

Postman 提供了一個(gè) Monitors (監(jiān)視器)功能，支持我們提交一個(gè)測試任務(wù)，按照設(shè)置的定時(shí)器進(jìn)行運(yùn)行，如每小時(shí)測試一次，具體操作如下：

三、請求依賴問題

講完接口結(jié)果判斷和集合批量測試后，我們再來看看比較復(fù)雜的情況，即依賴請求問題，比如我們的購物下訂單接口要求必須先登錄后才可訪問。但大部分依賴問題其實(shí)本質(zhì)上就是一個(gè)接口間數(shù)據(jù)傳遞的問題，比如調(diào)用登錄接口后返回一個(gè)標(biāo)識，假設(shè)為 token ，那么我們請求下訂單接口時(shí)只要一起攜帶 token 參數(shù)進(jìn)行請求即可。所以，問題變?yōu)椋?/p>

• 保證接口調(diào)用順序
• 將接口A返回的數(shù)據(jù)傳遞給后續(xù)的接口B、C、D

1、接口執(zhí)行順序

首先，說明一下，接下來說的接口都是默認(rèn)屬于同一個(gè)集合 (Collections) 中的。

還是以我們上文中創(chuàng)建好接口集合為例，如果你有注意我們執(zhí)行批量測試的結(jié)果，就會發(fā)現(xiàn)接口的執(zhí)行順序其實(shí)就是按照這邊目錄中的順序（從上到下），即：

Request1 -> Request2 -> Request3。

所以有了這個(gè)默認(rèn)的執(zhí)行順序后，那么我們便可以把需要優(yōu)先執(zhí)行的接口放前面即可，比如把“登錄接口”放在第一個(gè)。也可以在測試時(shí)拖動接口順序，調(diào)整接口執(zhí)行順序。

2、數(shù)據(jù)傳遞

在講數(shù)據(jù)傳遞前，先聊聊 Postman 中全局變量、環(huán)境切換的使用。

1、全局變量

全局變量的概念其實(shí)我們在上文中講 Pre-request Script 時(shí)有簡單提到，也就是說我們可以通過腳本代碼來設(shè)置全局變量，我們可以看看運(yùn)行上文的腳本后的效果：

我們可以看到運(yùn)行后， pw兩個(gè)變量已經(jīng)被成功保存下來，那么我們在任意接口中便都可以通過變量引用的語法如：{{pw}} 來使用它們。

另外，Postman 不僅支持代碼設(shè)置全局變量的方式，它還支持可視化操作：

進(jìn)入對應(yīng)界面后，便可直接進(jìn)行管理：

2、多環(huán)境區(qū)分與切換

通常情況下，我們的接口都會分為測試版本和線上版本（或者更多），而他們的區(qū)別可能僅是 ULR 不同，那么全局變量便不大合適解決這個(gè)問題。

3、變量的創(chuàng)建

可能你已經(jīng)注意到，上圖中我已經(jīng)建有幾個(gè)不同環(huán)境的變量“集合”了，再看一下：

我在每個(gè)環(huán)境中都創(chuàng)建了一個(gè) host 變量，如：

當(dāng)然，我們的環(huán)境參數(shù)也可以通過腳本的方式來進(jìn)行設(shè)置，函數(shù)為：

//注意，該參數(shù)只添加到你當(dāng)前選擇的環(huán)境的“參數(shù)集”中
postman.setEnvironmentVariable("variable_key", "variable_value");

4、使用與切換

環(huán)境“參數(shù)集” 中的參數(shù)使用方式和全局變量一致，如圖中 {{host}} ，不同環(huán)境的切換見下圖：

3、解決依賴問題

掌握以上的預(yù)備知識后，我們開始看看如何用 Postman 解決存在依賴關(guān)系的接口測試。

1、假設(shè)場景

我們的接口 Request1 為登錄接口，登錄成功將會返回一個(gè) access_token 字段作為標(biāo)識（已實(shí)現(xiàn)）。那么假設(shè)接口 Request3 為一個(gè)下訂單的接口，需要攜帶登錄返回的 access_token 才能正常訪問。

2、思路

• 保證 Request1 在 Request3 之前被運(yùn)行
• 將 Request1 返回的 access_token 的值添加到環(huán)境變量"參數(shù)集"中。
• Request3 在請求時(shí)引用 access_token 的值

將返回值存在 “全局變量” 或者 “環(huán)境變量” 中，視具體業(yè)務(wù)情況而定，該例中 access_token 的值是與環(huán)境有關(guān)的，所以這里選擇使用環(huán)境變量集存儲。

3、Postman 中的操作

我們目錄中已保證 Request1 接口優(yōu)先執(zhí)行,

Request1 中 Tests 的代碼情況

if(responseCode.code === 200 && responseBody.has("access_token")){
    //如果 code 為 200， 并且返回的數(shù)據(jù)中存在 access_token 關(guān)鍵字，則認(rèn)為登錄成功
    tests["login"] = true;
    
    //將返回的內(nèi)容轉(zhuǎn)為 json 格式，并且取到 access_token 內(nèi)容，添加到環(huán)境變量中
    var jsonData = JSON.parse(responseBody);
    //access_token的取值方式視具體的 json 數(shù)據(jù)結(jié)構(gòu)而定
    postman.setEnvironmentVariable("token",jsonData.result.access_token);  

    //跳轉(zhuǎn)到 Request3 接口
    postman.setNextRequest("Request3")
    
}else{
    tests["login"] = false;
    
    //登錄失敗，可以選擇跳轉(zhuǎn)到對應(yīng)失敗后的處理接口進(jìn)行測試
    //postman.setNextRequest("Other Request")
}

在接口Request3 中使用變量 token : 

我這邊是將 token 放在頭部信息中， 具體使用方式時(shí)接口參數(shù)規(guī)則而定。

4、運(yùn)行并查看結(jié)果

運(yùn)行集合測試，可以看到我們結(jié)果符合我們的預(yù)期，Request1 和 Request3 通過測試，Request2 被跳過，Request4 仍被執(zhí)行。

到此這篇關(guān)于使用postman進(jìn)行接口自動化測試的文章就介紹到這了。希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論