在postman中,我们在一个collection中,可以根据模块、流程,来创建我们的测试用例集;如果想要整体的把所有流程全部跑一遍,就需要直接运行整个测试用例集合。
点击测试集合collection的三角符号,点击run,此时postman会打开一个新的界面,单独运行这个测试用例集。
在这里有一些复杂的配置项,需要更改默认值,会用到的就是:interactions(运行次数),看你需要运行多少次。
然后就是右边是用例的执行顺序,可以拖动改变。
这里的测试结果,是根据我们每个用例里的断言判断的,如果没有断言,并且能正常运行,也是成功状态。
这个文章我本来是想命名为“使用postman进行性能测试”的,但是我在测试运行用例时,发现根本不是这么回事儿,postman运行接口不能作为性能测试。
下面讲讲我研究postman性能的过程。
我是按照性能测试的想法,想看看用postman到底能跑到多少的并发。所以我1000次的运行次数,运行同一个接口。
变量有:电脑配置、postman的运行CPU占用率、总共运行时间;然后算出来每秒运行次数和平均响应时间。
测试一:
次数:1000次
时间:4分16秒
平均并发数:4次/秒
平均响应时间:200ms左右
cpu占用:25%
测试二:
次数:1000次
时间:3分40秒
平均并发数:4.5次/秒
平均响应时间:200ms左右
cpu占用:10%
测试三:
次数:1000次
占用30%
时间:3分25秒
测试四:
次数:1000次
加入了时间判断断言
占用30%
时间:3分50秒
相应时间小于200ms:98.6%
结果我发现了,不管电脑本身配置高低、postman的每次“并发”测试结果:都是4次-5次每秒。这让我明白了,限制接口运行速度的只有单个接口单次的响应时间。
当然我还有一个小发现,那就是postman本身的运行效率。在postman设置每个接口运行间隔为0的情况下。我在Tests中加入了这些代码,并且在环境中也加入了time字段,默认值为0.
pm.test("Response time is less than 200ms", function () {
pm.expect(pm.response.responseTime).to.be.below(200);
});
var time_now = pm.response.responseTime;
var time_base = pm.environment.get("time");
var time_all = parseInt(time_now) + parseInt(time_base);
pm.environment.set("time", time_all);
因为postman没有所有接口时间的统计(或者说我没找到),为了统计所有接口运行花费的总时间,我将每次接口响应时间加起来,最终运行完成后总时间就记录到了环境变量中(运行配置里要勾选:keep variable values).
最终结果是:
postman运行1000次接口,通过外部计时器计时,总共为4分钟,而通过本身响应时间统计,总共运行时间为3分钟.
对比接口本身的响应时间,两者差了一分钟,那我就理解postman本身也需要时间切换接口的发送,而且断言判断也需要时间,所以从时间角度看:这次postman的运行效率就是75%.