postman批量调用HTTP接口

借助postman批量调用HTTP接口

场景

  笔者在工作时遇到了一个应用场景，希望通过Postman去解决，问题是这样的

• 笔者开发的程序在页面上可以批量创建服务，但没有提供批量销毁服务
• 可以通过一个接口批量查询服务的信息，其中核心重要的是一个服务id。
• 该id是销毁服务接口的一个参数
• 笔者期待的是点击一次按钮，销毁所有服务

当时，笔者的同事主要负责批量创建服务和销毁服务的功能的验证，但页面仅有对单个服务的销毁，当时同事呢，就一个一个点击，吐槽者，崩溃着，还乐此不疲着，我当时在旁边就想着应该通过postman自动化该过程，提升效率，降低枯燥。

常用解决方式

通过文件迭代指定次数

postman实现参数化迭代

【Postman教程】使用Postman循环调用接口

但这些解决方式，笔者觉得不够优秀，因为是基于集合来进行的，而且还需要把所有的参数集中到一个文件中，文件也要自动产生，当然我们可以通过查询所有服务接口通过Tests标签添加保存所有变量到文件中，然后再结合集合迭代去使用。但感觉依然不够优雅，太繁琐。

sendRequest+变量

当时楼主想法是这样的，

• 首先通过Tests标签通过查询所有服务，获取所有的服务ID的集合，并将之存储在环境变量中。这个步骤很顺利
• 第二个步骤，就是要调用环境变量中的每一个服务id，进行批量销毁
  • 这个就让我犯了难了，因为销毁服务的接口是一个接口API，通过点击send只能发送一次，怎么环境变量serviceIds中保存的所有服务id都销毁呢？
  • 当时一开始是把所有的销毁操作放在了销毁单个服务接口的Tests标签下了，没有办法，因为必要点击一次send，所以{{service_id}}来模拟一个失败的请求，也不够优雅。

当时因为研究这个，笔者住在酒店里还失眠了，或许是不断思索的缘故吧，笔者想到，自己干嘛要把批量销毁服务的逻辑放置在销毁单个服务的Tests标签下，这样还是需要点击两次send，一次查询所有服务，一次销毁所有服务。不好。自己可以把所有的代码都放置在查询所有服务状态的Tests标签下，想及此，有种茅塞顿开，恍然大悟的感觉。

在这个过程中，读者需要了解如下的知识点

• sendRequest
• postman通过变量进行接口间交互
• Postman：脚本应用_pm对象
• 在Postman脚本中发送请求(pm.sendRequest)

其实在把批量销毁服务放置在T查询所有服务状态下之后，就不再需要中间存储环境变量了。不过这无所谓了。不再赘述各种缘由。

使用变量

// 构造一个注册请求
const regRequest = {
  url: 'http://115.28.108.130:5000/api/user/reg/',
  method: 'POST',
  header: 'Content-Type: application/json',  //注意要在Header中声明内容使用的类型
  body: {
    mode: 'raw',  // 使用raw(原始)格式
    raw: JSON.stringify({ name: '小小', password: '123456' }) //要将JSON对象转为文本发送
  }
};

//发送请求
pm.sendRequest(regRequest, function (err, res) {
  console.log(err ? err : res.json());  // 响应为JSON格式可以使用res.json()获取到JSON对象
});

总结

 在笔者离开嘉兴之前，再次去了办公现场，成功的验证了这个小功能，帮助同事能够从24次页面点击销毁等待转化为1次点击Send点击等待。效率有了显著的提升，工作体验也有了一定的提升。

  最近，笔者并不开心，是因为经历的一些事吧，还有就是这两周因为出差，学习的效率和劲头也有了很大的下降，昨天和大学同学聊天，同学说我就是太正经了，每天都是学习啊，工作啊，一点乐趣都没有，我愕然，反思自己，生活真的是一本无比复杂交错的事情，千头万绪，相互缠绕纠结，自己在这罗网中也没有什么更好的方法让自己守静守心，日子一天一天的度过，烦恼一天一天的增加，暖风迟日柳初含，顾影看身又自惭；何事明朝独惆怅，杏花时节在江南。还有其他乱七八糟的事情，情绪管理不佳，沟通能力不好，很烦。

  不写了，坐了一上午了，腰不舒服。

下载

• Postman 自动化测试

2021年4月24日周六11:24:26于AUX