star 404(接口测试利器Postman)

今天给各位分享star 404的知识，其中也会对接口测试利器Postman进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

在上一篇《接口测试利器Postman-基础篇》中，我们介绍了Postman工具的主要功能和一些基本用法。其实Postman作为目前使用最为广泛的接口测试工具，除了能提供交互良好的UI界面以及完成基本的http协议的鉴权、header、body等的设置以及请求提交和响应解析这些基本功能外，它还提供了非常丰富的测试辅助能力。本篇我们就来为大家详细介绍postman的脚本进阶功能。

在接口测试工具中，变量对于接口消息的重用和灵活匹配意义重大，作为一个专业的接口测试工具，对变量的支持是必须具备的。

而Postman就提供了丰富的变量支持，在Postman中定义了5种不同作用范围的变量类型，在变量的使用和管理上更加地灵活和有针对性。下图是官方给出的不同类型变量的作用范围

从外向内作用域逐渐变小，同时生效优先级越高，也就是当存在同一变量名时，内层变量类型的变量会优先生效。下面我们结合实例来具体说明一下这些变量类型的作用范围：

global变量即全局变量，是作用范围最大的一种变量类型。设置好global变量后，可以在Postman工具中所有可以使用变量的地方生效。

下面在Postman工具中看一下global变量的设置：在工具右上角打开环境管理界面：

此例中，我们设置一个global变量name，取值为1。在Postman中，使用双花括号表示变量，形如{{variable}}。以GithubAPI为例，比如我们获取用户名为变量name取值的用户信息。

https://api.github.com/users/{{name}}

url中输入双花括号后会自动联想出我们需要的变量类型。

发送请求后，检查Postman响应区，可以看到我们获取了username为1的用户信息。

"node_id":"MDQ6VXNlcjE4MjU3OTg=",

"avatar_url":"https://avatars2.githubusercontent.com/u/1825798?v=4",

"gravatar_id":"",

"url":"https://api.github.com/users/1",

"html_url":"https://github.com/1",

"followers_url":"https://api.github.com/users/1/followers",

"following_url":"https://api.github.com/users/1/following{/other_user}",

"gists_url":"https://api.github.com/users/1/gists{/gist_id}",

"starred_url":"https://api.github.com/users/1/starred{/owner}{/repo}",

"subscriptions_url":"https://api.github.com/users/1/subscriptions",

"organizations_url":"https://api.github.com/users/1/orgs",

"repos_url":"https://api.github.com/users/1/repos",

"events_url":"https://api.github.com/users/1/events{/privacy}",

"received_events_url":"https://api.github.com/users/1/received_events",

"type":"User",

"name":"Michael",

"location":"SanFrancisco,CA",

"email":"mbalaban1989@gmail.com",

"created_at":"2012-06-07T06:10:07Z",

"updated_at":"2019-01-17T08:29:21Z"

再来看另一个变量类型Collection变量。首先了解下Collection的概念。Collection是Postman中组织接口的一个集合单位，Postman中也主要以Collection为配置存储的一个基本单位。我们可以把Collection看作软件测试中测试用例集的概念。

Collection变量就是作用域在Collection上的变量类型，这种变量只会在设置变量的Collection上生效。设置方法：选择EditCollection

在variable页中添加Collection变量，本例中我们在Github这个Collection添加一个同样命名为name的变量

将上例中获取用户的接口保存到Github这个Collection中（我们可以在Collection下再创建一层子目录，注意目录是不支持设置目录级别的变量的，Collection变量在子目录下的接口依然会生效），我们再提交一下这个接口

此时可以看到，我们设置的Collection变量已经生效，获取到的是name为2的用户信息。注意此时我们还设置了一个name为1的global变量，可以看到Collection变量的优先级高于global变量。

环境是Postman中的一个非常有用的概念。做过软件测试的同学都了解，我们在实际工作中会接触到不同的软件环境。对应于我们被测试系统的不同运行场景。比如一般互联网企业在研发中会存在以下的一些不同环境：

不同的环境在接入途径、网络拓扑、访问权限以及硬件配置上往往都有较大区别。Postman中引入Environment这个概念，通过Environment变量来管理一组环境配置，便于我们来方便地在不同环境间进行切换。

在环境管理界面中，可以添加环境，以及该环境对应的相关变量。本例我们添加一个GitChat环境，并且设置一个name=3的环境变量。

设置完环境后，我们再刚才的获取用户接口界面上，选择对应的GitChat环境，再重新提交请求。可以看到环境变量已经生效，获取了name为3的用户信息，同样可以看到，此时环境变量的优先级比Collection又要更高。

另一种Postman中的变量类型是data变量，data变量只能在PostmanRunner中使用，也就是会在Runner运行时才生效，data变量可以提供多组测试数据供接口测试时调用，为Postman提供接口批量数据验证能力。要使用data变量，打开PostmanRunner，如下图，选择data变量定义文件加载data变量文件。

data变量支持json或者txt/csv数据格式，json定义格式如下，

"name":"user1"

"name":"user2"

"name":"user3"

在runner界面上可以通过preview查看运行时不同迭代所加载的变量取值，如下：

如本例，点击Runvariables会执行3次不同的迭代，通过PostmanConsole查看运行日志，可以看到每次均使用了data变量中定义的对应变量值。同样，虽然我们选择environment，但可以看到data变量在runner运行时优先级更高。

Local变量在Postman官方文档中并没有给出明确的定义。一般可以理解成Postman脚本中支持的JS变量，它的作用域只会在脚本中生效，此时Postman界面引用的{{variable}}并不会取到local变量值。脚本中直接引用的变量名会取local变量，其他数据类型则通过Postman对应的取值语句来获取。

比如我们在Pre-Request中定义以下脚本并执行：

在Console中查看结果如下，可以比较清楚地看到每次执行在预执行脚本中不同变量的当前取值

通过以上实例，我们可以看到，Postman针对不同的接口作用范围支持了丰富的变量类型，使我们在应用变量功能的时候可以更加的灵活

除了支持丰富的变量功能，Postman还支持强大的脚本功能，测试人员在进行接口测试时，可以通过脚本来动态地对接口测试逻辑进行定制，再结合变量，就可以实现一些复杂的场景。

Postman的脚本功能是基于Node.js语言，Node.js成熟的语法和丰富的扩展库给Postman提供了巨大的灵活性和强力的扩展能力。

在Postman中，测试脚本可以在接口发送之前和收到响应之后执行，分别对应Pre-requestScript和TestScript，如下图：

比如我们前文介绍变量时的实例，其实就是一个pre-request脚本

除了接口本身可以设置pre-request和TestScript，我们在编辑Collection和Collection下的folder时，可以看到Collection和Folder也都支持设置pre-request和test脚本。那这几种脚本的执行优先级或者说顺序是如何的呢？下图就是这几个不同位置脚本的调用执行顺序：

对TestNG或者Junit等测试框架有所了解的同学，应该知道这些测试框架也有类似的运行时概念，也就是Setup和teardown方法，而且也有case、class、suite这样的层次。不过这些不同层次的方法都是成对出现的，即case的setup和teardown在case执行前和结束后会执行。而Postman的Script执行顺序和这个稍有差别，是按层级顺序排列，而不是成对出现的。大家参照图片注意理解下差异。

大家也可以自己验证下这个执行顺序，分别在Collection、folder以及folder下的请求中定义相关脚本，如：

可见Postman对不同脚本的执行顺序和前文所述一致。

Pre-request脚本，顾名思义，其实就是在接口消息发送前，可以进行一些预处理动作，类似于Junit或TestNG等测试框架中的Setup方法。利用Pre-Script脚本，我们就可以在发送接口请求前来完成一些需要动态处理的动作，比如调整变量取值，或者对一些动态参数进行一些特殊处理。

下面我们就以GitHubAPI中的一个实例来看下Pre-Script脚本的主要作用。（关于GitHubAPI的一些具体说明，大家可以先看下我在上一篇Chat《玩转Postman：基础篇》中的介绍）

GitHubAPI中一个经常使用到的接口是查询接口

根据GitHubAPI官网的定义说明，查询repositories的接口定义如下：

其中参数q是主要的查询参数，具体定义参见https://help.github.com/articles/searching-for-repositories/

比如我们要查询包含在指定日期2018-11-11后创建且包含关键字automation的repository信息。

可知GitHub上存在这样的repo数量有七千多个。

在这个例子中，因为查询条件包含一个日期参数，而实际测试工作场景中，很多时候我们希望日期是动态生成的，比如根据当前日期取一年以前作为查询参数值，这时我们就需要对参数进行一些预处理，这就是Pre-Script的用武之地了。

这时我们可以首先设置一个环境变量created，再在pre-script脚本中动态预处理这个日期，来完成日期动态设置的目的。

pm.environment.set("created",getCreated(newDate(),-1));

获取"YYYY-MM-DD"格式的日期

第二个入参为年份偏移量，负数为向前偏移

functiongetCreated(date,yearOffset){

varyear=date.getFullYear()+yearOffset;

varcurrentDate=year+seperator1+month+seperator1+day;

在Postman中执行如图，获取当前日期一年以来创建的repositories信息。

在Pre-Script中，主要是围绕Postman的变量来进行预处理，所以主要使用的就是Postman的变量域的一些封装方法。

Postman的Test脚本是Postman另一个值得称道的特色功能，在Test脚本中，Postman封装了很多丰富的校验逻辑，并结合JS脚本本身语言的灵活性，给测试人员对接口的判断、校验和响应处理带来极大的便利性。

下面我们重点介绍下Test脚本中封装一些主要的校验方法。

对接口响应状态码的校验，是接口测试校验的常用手段。关于状态码的详细说明也可参见我的上一篇Chat《玩转Postman：基础篇》，下面看一个Postman中进行接口校验码校验的代码:

pm.test("判断返回成功状态码",function(){

pm.response.to.have.status(200);

或者也可以使用第三方校验库chaijs的expect方法来进行校验。Chaijs对常用的校验方式按照行为驱动开发（BDD）的描述方式进行了封装，使校验判断的代码编写方便了很多。

pm.test("expect方法判断返回成功",function(){

pm.expect(pm.response.code).to.equal(200)

再或者我们还可以直接使用Postman对返回状态码的封装方法来进行判断

pm.test("Postman封装方法判断返回成功",function(){

Postman中直接封装了常见的返回状态校验方法：

校验状态码429的访问频次限制错误

除了对于返回码的校验，我们还会经常校验的一个响应指标是响应时间。Postman对于响应时间的校验也非常简单

pm.test("响应时间小于1s",function(){

pm.expect(pm.response.responseTime).to.be.below(1000);

对接口返回内容的校验是我们判断业务逻辑正确性与否的必要手段。响应的消息头或者消息体内容我们可以通过pm.response.header或者pm.response.text、pm.response.json来获取。在相应的校验代码中我们就可以根据获取到的内容来进一步判断响应的正确性

pm.test("校验消息头Content-Type",function(){

pm.expect(postman.getResponseHeader("Content-Type")).to.include("application/json")

pm.test("校验消息体返回数量大于1000",function(){

varjsonData=pm.response.json();

pm.expect(jsonData.total_count).to.gt(1000)

在Postman中执行以上校验，可以在Response的TestResults中看到校验结果

在接口测试中，经常出现的一种情况是：我们需要从另一个接口的响应中获取某些值作为当前测试接口的输入来使用。结合Postman的Pre-Script脚本和Test脚本以及变量功能，我们可以方便地完成内容获取和参数传递的场景。

从Junit5这个repo的接口信息中，获取该repo的创建时间，再查询在这个时间之后创建的所有包含Junit5字样的repo信息，判断repo数量是否超过1000

在方法一中我们利用环境变量来传递参数，这种方法需要依赖runner执行器对接口的执行顺序来保证GetRepo接口在SearchRepo接口之前执行。

我们也可以利用Postman提供的请求发送方法pm.sendRequest在SearchRepo的pre-Script脚本中直接完成前置请求的发送和参数获取。

pm.sendRequest('https://api.github.com/repos/junit-team/junit5',function(err,res){

pm.environment.set("created",res.json().created_at);

此时不需要利用runner执行器，直接执行SearchRepo接口，也可得到同样的结果

Postman作为一个接口测试工具而不是专业的代码编辑IDE，并没有提供脚本的复用以及代码片、模块定义之类的功能。但借助Postman强大的变量和js语法的良好支持，我们可以变通地实现代码复用。

我们可以将一些常用的代码片段保存到global变量中，在需要使用的时候，直接调用这个global变量即可。

比如上面判断返回repo数量是否超过1000这段校验代码：

pm.test("判断返回成功状态码",function(){

pm.response.to.have.status(200);

pm.test("校验消息体返回数量大于1000",function(){

varjsonData=pm.response.json();

pm.expect(jsonData.total_count).to.gt(1000)

我们将它设置在global变量checkRepoCount中，在需要调用的地方，以如下代码代替即可：

Postman为便于接口脚本的编写，内建支持了丰富的第三方库，官方文档中列出了详细清单

除了前面提到的BDD校验库chai,下面我们再结合第三方时间处理库moment来完成一个相对复杂的场景案例实现：

1.获取最近6个月包含有Junit5字样且Star数>1的repo信息

2.判断返回repo数量是否>0,结果显示到TestResult

3.如果数量>0,获取star数最多的repo信息

4.判断自己是否已经star过这个repo

5.如果没有star过，执行star操作

/search/repositories?q=junit5+stars:>1+created:>{{created}}&sort=stars

在查询repo接口的Pre-Script脚本中引入事件处理库moment，可以看到moment库相比js本身的date方法，对日期的处理更加方法灵活，利用subtract方法可简单获取半年前的日期，无需考虑日期补零、跨年等判断，代码如下：

varm=require("moment")

//利用moment库获取六个月前日期

letcreateDate=m(m.now()).subtract(6,"months").format("YYYY-MM-DD")

pm.environment.set("created",createDate);

在查询repo接口的Test脚本中编写校验和后续逻辑代码：

letcount=pm.response.json().total_count

pm.test("覆盖条件repo数量为"+count,function(){

//保存repo的owner和repo名称，查询条件为按star排序，所以index为0的repo即star数最多

varrepoName=pm.response.json().items[0].name

varowner=pm.response.json().items[0].owner.login

pm.test("当前star数最多的repo是【"+pm.response.json().items[0].full_name+"】",function(){

//需要定义请求信息，指定header和执行方法。不指定的话直接在SendRequest中使用默认为GET方法，不携带Header

url:"https://api.github.com/user/starred/"+owner+"/"+repoName,

//接口需要经过鉴权，代码中不能使用Postman界面设置，将鉴权信息携带在header中

header:'Authorization:Bearer84fb9e0706bab75f1d4b6f4e3586683d8c4605af'

pm.sendRequest(getStarReq,function(err,res){

letstared=pm.test("当前repo已star",function(){

url:"https://api.github.com/user/starred/"+owner+"/"+repoName,

//接口需要经过鉴权，代码中不能使用Postman界面设置，将鉴权信息携带在header中

header:'Authorization:Bearer84fb9e0706bab75f1d4b6f4e3586683d8c4605af'

pm.sendRequest(starRequest,function(starErr,starRes){

pm.test("已star成功",function(){

pm.expect(starRes.code).to.equal(204)

pm.expect(res.code).to.equal(204)

以上就是关于Postman的脚本进阶使用的介绍。简单总结一下：

所以Postman通过丰富的变量以及强大的js脚本支持，可以非常灵活地帮助我们更好地完成接口测试中一些复杂的场景。

star 404和接口测试利器Postman的问题分享结束啦，以上的文章解决了您的问题吗？欢迎您下次再来哦！