利用Postman实现简单的自动化测试

时间：2024-03-14 22:10:34

1. 关于tests[]断言

 对于系统整套接口的测试最好是建立系统相关的Collection，便于以后测试，测试脚本采用的是JavaScript语法编写，脚本主要写的位置在Pre-request Script和Tests两个栏目中，Pre-request Script主要用于在请求发送之前执行，Tests用于请求发送之后执行，在Postman中也提供了一些简单的断言，比如：

// 判断返回的状态码是否为200
tests["Status code is 200"] = responseCode.code === 200;

// 判断返回的内容中是否存在指定关键字
tests["Body matches string"] = responseBody.has("关键字");

// 判断返回内容是否跟预期完全相等。
tests["Body is correct"] = responseBody === "预期的内容";

// responseBody为字符串类型，支持转为 Json 格式
var jsonData = JSON.parse(responseBody);
tests["Your test name"] = jsonData.value === 100;

// 判断请求时长是否小于200ms ,具体时长按情况自定义
tests["Response time is less than 200ms"] = responseTime < 200;

上述test命令的语法基本是：

test["类似于函数名字"] = 一个判断条件

函数名字可以随缘嘛，只要见名知意就行了(比如上面判断状态码是否为200就是Status code is 200)，判断条件可以是各种形式，比如数值、字符串的相等可以用===、响应体中包含关键字可以用responseBody.has("关键字")函数、以及>、<等等，只要最后返回的是一个布尔值即可，为true即表示通过，false为失败，tests的直接赋值作用比较局限，如果在脚本中进行一些其他异步操作，则需要用到pm.test了，比如：

pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

一般使用test赋值和pm.test/pm.expect已经可以满足基本的测试需求了。也可以在测试请求拿到结果后再根据这些结果发送新的新的请求，然后添加断言，如：

// 将JSON响应体转成json
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，二级接口根据List的ID进行获取对应信息。

2. 关于变量global和environment

 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

上述是使用脚本的方式设置global变量，这一点在Account中很实用，用户在登录后可以直接利用pm.globals.set("variable_key", "variable_value")的方式将cookie设置到全局变量中，这样后续的操作就可以利用这个cookie获取到用户的状态是登录的状态。变量设置完，可以在测试的URL中使用{{..}}双括号的形式包裹global变量来使用。

 environment变量的权重要比global变量更高一些，针对某些环境来进行设置，操作方式和上述类似（也是用双花括号的形式包裹变量即可），在发起请求(一个或多个)时，可以勾选对应的环境来使用不同的变量，environment变量可以使用的位置如下：

  • URL
  • URL params
  • Header values
  • form-data/url-encoded values
  • Raw body content
  • Helper fields

在对大量API测试时，使用environment设置domain和context-path是比较推荐的，比如：

// 在环境管理中配置一个domain变量，值为https://api.github.com
domain: https://api.github.com

// 使用双括号的形式在URL中引用环境变量
{{domain}}/res1
{{domain}}/res2

具体设置环境变量时可以这么干：

postman.setEnvironmentVariable("variable_key","variable_value");

postman内部也提供了三种随机数的生成方式（未测试通过）：

  • {{$guid}}：添加一个V4风格GUID；
  • {{$timestamp}}：将当前的时间戳，精确到秒；
  • {{$randomInt}}：添加0和1000之间的随机整数；

3. Run Collection

 在自动化测试过程中，通常是通过 Run Collection 的方式一次跑大量的API，Collection 建好后直接点击左上方的Runner按钮，即可进入界面，对其中的几个参数做一些说面：

利用Postman实现简单的自动化测试
上述界面的参数依据实际情况进行设置即可。

关于接口的执行顺序

 默认情况下，接口是按照我们编写的顺序执行的，即接口在前面的就先执行，在后面就后执行，如果想手动指定接口的执行顺序，可以在接口的Tests一栏中使用setNextRequest函数指定下一个要运行的接口，如：

# 当前接口运行完毕后就会继续运行Request2接口，而不管位置上在它下一个的接口
postman.setNextRequest("Request2");

4. 变量解析

 在通过postman中在RequestBody中放List，遇到JSON解析问题，原来是要往里面塞一个List<Long> feedbackIds，后来在postman中直接这么放的：

{
	"feedbackIds":[
		1194812025388864,
		1195607949901632
	]
}

然后出现下面的解析异常：

"exepct '[', but {, pos 1, json : {\n\t\"feedbackIds\":[\n\t\t1194812025388864,\n\t\t1195607949901632\n\t]\n}"

在JSON解析的时候，后端是要的一个List，而前端传过来的确实一个对象(这一块感觉说不太清楚，应该都有这种感觉)，最终直接通过最简单的方式传入得以解决(传入[xx, xx, ..]的形式)，直接将传入的数据改写为：

[
  1194812025388864,
  1195607949901632
]

 很多情况下，API返会给前端的数据都是封装成下面的JSON格式：

{
  "code": string,
  "message": string,
  "data": T
}

在此时断言responseBody中的具体JSON内容时，比如返回的内容为：

{
    "code": "invitee.not.reach",
    "message": "The Invitee not reach."
}

那在断言的时候先转JSON再取其中的内容进行判断：

// 转成json
var jsonData = JSON.parse(responseBody);
// 取json中具体需要断言的key做判断
tests["check qualification"] = jsonData.message === "The Invitee not reach."

除此外，postman还可以断言 response 的头部信息，如：

// 断言响应头中是否有Content-Type
tests["Content-Type is present"] = responseHeaders.hasOwnProperty("Content-Type");


// 获取Content-Type的值
var ct = postman.getResponseHeader("Content-Type");
// 判断Content-Type的类型是否相符
tests["Content-Type is image/gif;charset=UTF-8"] = postman.getResponseHeader("Content-Type") === "image/gif;charset=UTF-8";

// 判断Cookie的值，cookie一般都是很多cookie一起，中间以分号间隔
var cookied = postman.getResponseHeader("set-cookie");
// 将多个cookie字符串切割为一个个单个的cookie
cookies = cookied.split(";");
// 将该接口写入的cookie中的最后一个设置为postman全局环境变量，从而影响后面接口的测试
postman.setEnvironmentVariable("Cookie",cookies[0]);

// 如果知道了cookie的名字，想直接取这个cookie的值
var cuk_yk = postman.getResponseCookie("cuk_yk").value;

【注意】

上述流程中在获取整个cookie时使用的是postman.getResponseHeader("set-cookie")这个函数，如果这个接口在后台逻辑内部有设置cookie的行为，第一次使用postman测试该接口时postman.getResponseHeader("set-cookie")函数可以获取到设置的cookie的头字段set-cookie，但是一旦这个运行过该接口后cookie被写进去了，没有清cookie运行第二次的时候，postman发现该cookie存在就不会去设置对应的cookie，接口响应体中也不会出现set-cookie头字段，所以最终获取的cookied为null，从而也导致cookied.split(";")函数出现TypeError: Cannot read property 'split' of undefined，因为获取的cookied变量为null，没法调用该函数，很多人会使用(cookied || "").split(";")方式处理来避免这个错误，其中(cookied || "")其实类似于三目运算的过程，如果cookied不为null结果就为cookied，否则结果为一个空串。

5. 具体操作

 这里只记录我遇到的一些不太注意的东西，常规操作自行百度，有下面一些：

关于环境变量

 在创建环境时，我以为只有在Run Collection时才能使用，然后为了在测试单个接口时，在每个接口的Pre-requestScript中都用脚本写了domain和context-path：

pm.environment.set("domain","http://www.xxxx.com");
pm.environment.set("contextpath","/api");

但实际根本不需要，在配置好环境变量后，在下图的红色框中选用即可：

利用Postman实现简单的自动化测试

关于调试或postman输出、打印

 postman在写测试脚本的时候也是可以进行简单打印调试的，只是之前没有用过，但不是常规意义上打端点进行debug，而是利用console.log()函数将变量进行输出，关键是输出你最起码有个类似于控制台的地儿啊，这玩意找了大半天，调出postman控制台的操作流程如下：顶部菜单栏View–> Show Postman Console，或者直接快捷键Ctrl+Alt+C，这样在脚本使用console.log()就可以将需要查看的变量显示出来了。

相关文章