首頁 > web前端 > js教程 > 使用PostMan進行自動化測試

使用PostMan進行自動化測試

不言
發布: 2018-04-03 09:14:53
原創
5802 人瀏覽過
最近在進行一個舊專案的升級,第一步是先將node版本從4.x升級到8.x,擔心升級會出現問題,所以需要將服務的介面進行驗證;
如果手動輸入各種URL,人肉check,一個兩個還行,整個服務。 。大幾十個接口,未免太浪費時間了-.-;
因為是一個純接口服務的項目,所以打算針對對應的API進行一波自動化測試;
所以就開始尋找對應的工具,突然發現,平常使用的PostMan看似也是支援寫入測試案例的-.-,所以就照著文檔懟了一波;
一下午的時間,很是激動,之前使用PostMan僅限於修改Header,添加Body發送請求,從來沒有考慮過拿PostMan來進行測試,一下午的使用,感覺發現了新大陸。

PostMan的安裝

看起來像下載和使用PostMan必須翻牆-.-
因為現在提供兩種形態的App:

  1. chrome的外掛程式(已經快要被廢棄了,推薦使用獨立App)

  2. 獨立的App

而且使用時需要登入帳號,我這邊是直接登入的Google帳號-。 -貌似有其它方式,但是我並沒有去嘗試。

獨立App版雲端硬碟位址(Mac版本,今天剛下載的6.0.10,需要的請自取):
連結:https://pan.baidu. com/s/18CDp...  密碼:mrpf

下載完畢解壓縮後直接運作即可,然後就是註冊帳號之類的,目測帳號這一塊主要是用於後續的小組分享需要(可以直接將你的呼叫記錄分享給其他人)。

發送一個請求

這是PostMan最基礎的用法,用來傳送一個請求。
可以設定HeaderBody等資訊。
使用PostMan進行自動化測試

Collections

我們可以將每次發送的請求進行儲存,方便下次請求該介面時,直接呼叫即可,
如果儲存請求的話,會被保存到一個Collections裡去,類似一個集合。
PostMan提供了方法,能夠一鍵運行整個Collections中所有的請求。
使用PostMan進行自動化測試
使用PostMan進行自動化測試

然後我們就可以在需要的時候,直接執行集合中所有的請求了。
使用PostMan進行自動化測試

儲存要求記錄的時候,在下邊選擇對應的Collection即可
使用PostMan進行自動化測試

開始API測試

測試腳本位置

使用PostMan進行自動化測試
#PostMan針對請求所寫的測試腳本,在這個位置,採用的是JavaScript語法,右邊是一些預先配置的程式碼片段。
以及我們可以在Pre-request Script中編寫腳本,用於在發送請求之前執行。

一些簡單的語法

PostMan也提供了一個斷言,來幫助做一些驗證。

tests['Status code is 200'] = responseCode.code === 200

tests['Data length >= 10'] = JSON.parse(responseBody).data.length >= 10
登入後複製

賦值為true即表示通過,false為失敗。
tests的直接賦值作用比較局限,如果在腳本中進行一些其他非同步操作,則需要用到pm.test了。

setTimeout(() => {
  pm.test("test check", function () {
    pm.expect(false).to.be.true
  })
})
登入後複製

只用上邊的tests賦值+pm.test/pm.expect已經能夠滿足我們的需求了,其餘的一些只是在這之上的文法糖而已。
各種語法範例

在測試腳本中發送請求

我們可以在拿到一個API傳回結果後,根據該結果發送一些新的請求,然後添加斷言。

let responseJSON = JSON.parse(responseBody)

// 获取关注的第一个用户,并请求他的用户信息
pm.sendRequest(responseJSON[0].url, function (err, response) {
  let responseJSON = response.json()

  pm.test('has email', function () {
    pm.expect(responseJSON.email).is.be.true // 如果用户email不存在,断言则会失败
  })
});
登入後複製

如果我們有一些動態介面要進行測試,可以嘗試這種寫法。
一級介面傳回List
二級介面根據ListID進行取得對應資訊。

如何处理大量重复的断言逻辑

针对单个API,去编写对应的断言脚本,这个是没有什么问题的。
但是如果是针对一个项目的所有API去编写,类似于判断statusCode这样的断言就会显得很溶于,所以PostMan也考虑到了这点。
在我们创建的Collection以及下层的文件夹中,我们可以直接编写针对这个目录下的所有请求的断言脚本。
使用PostMan進行自動化測試
使用PostMan進行自動化測試
这里的脚本会作用于目录下所有的请求。
这样我们就可以将一些通用性的断言挪到这里了,在每个请求的Tests下编写针对性的断言脚本。

变量的使用

PostMan提供了两种变量使用,一个是global,一个是environment

global

代码操作的方式:

pm.globals.set("variable_key", "variable_value") // set variable
pm.globals.get("variable_key") // get variable
pm.globals.unset("variable_key") // remove variable
登入後複製

通过GUI设置:
使用PostMan進行自動化測試
使用PostMan進行自動化測試

设置完后我们就可以这样使用了:
使用PostMan進行自動化測試

基本上在所有的可输入的地方,我们都能够使用这些变量。

environment

环境变量,这个是权重比global要高一些的变量,是针对某些环境来进行设置的值。
操作方式类似。

在使用代码操作的方式时,只需将globals替换为environment即可。
在发起一个请求,或者一键发送所有请求时,我们可以勾选对应的环境,来使用不同的变量。
使用PostMan進行自動化測試

在针对大量API测试时,拿environment来设置一个domain将是一个不错的选择。
这样在请求中我们只需这样写即可:

{{domain}}/res1
{{domain}}/res2

domain: https://api.github.com
登入後複製

一个简单的示例:

通过直接运行一个Collection,我们可以很直观的看到所有的接口验证情况。
使用PostMan進行自動化測試
使用PostMan進行自動化測試

参考资料

https://www.getpostman.com/do...

之前使用PostMan,最多就是模拟一下POST请求,最近刚好碰到类似的需求,发现原来PostMan还可以做的更多。
这篇只是使用PostMan进行API测试的最基础操作,还有一些功能目前我并没有用到,例如集成测试、生成API文档之类的。

接口相当于是获取和操作服务资源的方式,肯定属于产品的核心。
所以测试是必须的,在交付QA同学之前,自己进行一遍测试,想必一定能节省一部分的时间。

相关推荐:

chrome插件postman安装问题_html/css_WEB-ITnose

以上是使用PostMan進行自動化測試的詳細內容。更多資訊請關注PHP中文網其他相關文章!

相關標籤:
來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
作者最新文章
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板