1. 基本功能介绍
网上有很多介绍基本功能文章,大家可以自己找来看看,下面是我觉得比较好的一篇
搬运:http://bayescafe.com/tools/use-postman-to-test-api-automatically.html
2.Postman工作原理
在使用一款工具前,了解它的工作原理才能让你更快更有效的上手。我们知道对于一个API来说,输入的请求(Request)包括URL、method、Request Cookies、Request Headers和Request Body;收到请求后,API会回复响应(Response),包括Response Headers和Response Body。我们之所以可以用Postman作为我们的API自动化测试工具,是因为它能很好的模拟并向API发送Request,接收API发回的Response,并通过写在Test中的JS函数来对Response做断言。当然,Postman还有环境变量、Pre-request Script等更高级的功能,不过只要有了这些最基本功能就可以成为一个合格的API测试工具了。
3.常用功能详解
3.1 Request部分
Request部分用于组合Request的各部分并向API发送。
3.1.1请求URL
不管发送任何请求,确定要填写的URL是第一件事,尤其是当你习惯复制一个类似的用例改写成新用例的时候,很容易忽略URL是否完全一致,有时候出了问题排查半天发现原来少了一级URL……
有些URL中会自带请求参数(一般都是key=value的形式),点击URL后面的Params按钮可以打开参数编辑器,Postman会自动将网址分成键-值对两部分。
注意:如果没有为URL指定协议,Postman会自动将http://添加到URL的开头。
3.1.2 请求方法
根据不同的API操作需要使用不同的请求方法,Postman有很齐全的方法类型。同时,不同的请求方法也会影响Request Body的编辑区,比如选择GET方法时,Body区会处于无法编辑状态。
3.1.3 Authorization
Authorization(鉴权信息)其实是Headers的一部分,但由于这个参数的形式多变且非常重要,Postman将其独立出来方便用户进行设置。当在postman中选择Authorization的类型的时候,可以看到一共有10个类型,这里简单介绍一下常见类型,以后用到某种的时候可以再详细了解:可参考https://www.jianshu.com/p/8bb80594d126
a Inherit auth from parent (从父类继承身份验证)
当用户在一个集合内添加文件夹时,这个新添加的文件夹会默认使用Inherit auth from parent,即这个子文件夹内的每个Authorization类型都与父类的一致。比如在下图中,我在块网关中的Authorization类型是Bearer Token,则test_add中的所有请求将使用Bearer Token。
b. No Auth
如果不需要授权参数发送请求时,使用“No Auth”
c. Bearer Token
Bearer Token是安全令牌。任何带有Bearer Token的用户都可以使用它来访问数据资源,而无需使用加密密钥。
d. Basic Auth
Basic Auth是一种授权类型,需要验证用户名和密码才能访问数据资源
3.1.4 请求Headers
在Headers区域可以以键值对的形式来设置请求头内容,包括发送内容格式,要求返回消息语言等等。如果设置了Authorization,在发送请求时也会将鉴权信息自动填入Headers中
3.1.5 请求Cookies
在Postman的Native App中,我们可以通过Cookie管理器管理每个域名对应的Cookie。(我目前接触到的内部产品中还没有需要使用Cookie的部分)。
3.1.6 请求Body
Request的主要内容在Body的输入区中编辑。在输入区上方有四个选项,根据请求体类型有不同的输入UI:
a.form-data
Web表单用于传输数据的默认编码,一般模拟网站上填写表单并提交时使用这个选项。
b. x-www-form-urlencoded
该编码与URL参数中使用的编码相同。
c. raw
RAW请求可以包含任何内容,Pstman只会替换其中的环境变量而不会改变其中的编辑内容。
d. binary
二进制数据可让我们发送Postman中无法输入的内容,例如图像,音频或视频文件。
3.2 Script部分
在Postman中,Script部分被放在最前面和最后执行,可以完成预处理和断言的功能,顺序如下:
Pre-request Script → Request → Response→ Tests
3.2.1 Pre-request Script
前置请求脚本中的代码段会在Request发送前执行,一般会在需要设置Request内容包含动态/随机值时使用。Postmna中给出了几种常用模板,可以根据实际情况改写模板内容,如下图中的代码段会在Request发送前向环境变量中新增一个名为random_number的参数,它的值是0~1之间的随机数:
pm.environment.set('random_number', Math.random());
3.2.2 Tests
相较于Pre-request Script,Tests的应用场景更常见,建议每个用例中都在Tests至少添加一条函数作为断言。像之前介绍的,Tests中的代码段会在收到Response后执行,并根据Response的内容与之前的预期值作比较。Postman在Tests中给出的常用模板更多,下面举例几种常见的用法:
a. 判断返回码
用如下函数判断返回的状态码是否正常,一般成功消息的返回码是200
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});
b. 判断Response消息体中是否包含预期字符串
用如下函数判断Response Body中是否含有字符串"object already exists"
pm.test("Body matches string", function () {
pm.expect(pm.response.text()).to.include("object already exists");
});
c. 添加环境变量
先定义变量获取body中返回的所有参数,再把返回参数中的token设置为环境变量Authorization。
var jsonData =JSON.parse(responseBody);
postman.setEnvironmentVariable("Authorization",jsonData.data.token);
注意:JS代码段中不能直接引用环境变量,需要时可以先定义变量并用pm.environment.get()方法获取环境变量,然后引用该变量。
断言结果会在Response部分展示出来:
3.3 环境变量
在编辑Request和Script各部分时,我们常常会发现某些固定值需要使用许多次,一旦这些值需要发生变化时可能需要修改每一个用例。最常见的是URL中的IP值,几乎会出现在一个Collection中的每个用例中。我们可以将这样的值以键值对的形式在环境变量中定义,并在需要使用时直接引用环境变量的key值。这样,后续发生变化时,我们只需要直接修改环境变量中的值即可。
添加环境变量:
引用环境变量只需要用{{变量名}}替换原来的值就可以了,当鼠标移动到变量上方时会显示当前的变量值。
与代码中的变量相同,Postman中的环境变量也有作用域的概念。一般建议为一组Collection设置一组环境作用域变量,如果有需要的话可以在查看环境变量界面编辑全局变量,全局变量默认对所有用例都生效。
切换环境变量:
查看环境变量:
3.4 Response部分
API响应由正文,响应头和状态码组成。Postman将响应体和响应头放在不同的标签中显示;API调用所需时间、API响应状态码显示在选项卡旁边。如下图所示:
3.5 执行用例
编辑好每个用例后,可以统一执行一个Collection中的用例:
在弹出的窗口左侧可以选择执行的环境变量、设置每条用例前的延时时间等操作,右侧是之前的测试结果。
完成测试后会生成测试报告,包括每个用例中每个断言是否执行成功:
3.6 导出用例
当需要将用例共享给其他人时,可以将Collection和环境变量导出,其他人导入后就可以正常使用。
导出Collection:
导出环境变量: