视频1 视频21 视频41 视频61 视频文章1 视频文章21 视频文章41 视频文章61 推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37 推荐39 推荐41 推荐43 推荐45 推荐47 推荐49 关键词1 关键词101 关键词201 关键词301 关键词401 关键词501 关键词601 关键词701 关键词801 关键词901 关键词1001 关键词1101 关键词1201 关键词1301 关键词1401 关键词1501 关键词1601 关键词1701 关键词1801 关键词1901 视频扩展1 视频扩展6 视频扩展11 视频扩展16 文章1 文章201 文章401 文章601 文章801 文章1001 资讯1 资讯501 资讯1001 资讯1501 标签1 标签501 标签1001 关键词1 关键词501 关键词1001 关键词1501 专题2001
使用PostMan进行自动化测试
2020-11-27 19:56:49 责编:小采
文档


PostMan的安装

貌似下载和使用PostMan必须要-.-
因为现在提供两种形态的App:

  1. chrome的插件 (已经快要被废弃了,推荐使用App)

  2. 的App

而且在使用时需要登录账号,我这边是直接登录的Google账号-。-貌似有其它方式,但是我并没有去尝试。

App版云盘地址(Mac版本,今天刚下载的6.0.10,需要的请自取):
链接:https://pan.baidu.com/s/18CDp... 密码:mrpf

下载完毕解压后直接运行即可,然后就是注册账号之类的,目测账号这一块主要是用于后续的小组分享需要(可以直接将你的调用记录分享给其他人)。

发送一个请求

这是PostMan最基础的一个用法,用来发送一个请求。
可以设置HeaderBody等信息。

Collections

我们可以将每次发送的请求进行保存,方便下次请求该接口时,直接调用即可,
如果保存请求的话,会被保存到一个Collections里去,类似一个集合。
PostMan提供了方法,能够一键运行整个Collections中所有的请求。

然后我们就可以在需要的时候,直接运行集合中所有的请求了。

保存请求记录的时候,在下边选择对应的Collection即可

开始API测试

测试脚本位置


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以及下层的文件夹中,我们可以直接编写针对这个目录下的所有请求的断言脚本。


这里的脚本会作用于目录下所有的请求。
这样我们就可以将一些通用性的断言挪到这里了,在每个请求的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设置:

设置完后我们就可以这样使用了:

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

environment

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

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

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

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

domain: https://api.github.com

一个简单的示例:

通过直接运行一个Collection,我们可以很直观的看到所有的接口验证情况。

参考资料

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

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

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

下载本文
显示全文
专题