使用Postman测试API

Postman1是一个用于测试API的Chrome APP2

Postman在后端开发人员中已经很普及了,基本上是必备了。(什么?你说你只用curl?你说你自己写脚本测试?再见!)。但我发现很多人只把它当成一次性的工具,每次使用时都填入URL、参数,运行后再观察结果。其实Postman现在已经有一系列的工具方便你更有效率的进行API测试。

本文主要涉及Postman的环境变量、全局变量以及测试相关的话题。

新版本

如果你的Postman还是下面左边的图标,那么你该升级啦。目前在Chrome商店里存在两个版本的Postman,你应该使用新的2(右边的图标)。 postman-icon

API管理

我们可以把API的配置存储起来,并为其命名添加描述分组。这是比较基础的功能了,就不赘述了。

环境变量

很多时候,我们在开发时会有多个部署位置,比如一个用于测试(可能在线上也可能在本地,当然也可能都有),一个用于生产。通常的流程是先使用测试部署进行开发调试测试,再到生产部署上进行。对于同一个API,仅仅是URL略有不同,那么我们需要存储多条API么,或者是只存储一个在使用的时候改一下URL?这也太蠢了吧,这时我们需要用的是环境变量。

环境变量-wide 注意红色方框中双花括号包起来的{{saleschat}},这是一个环境变量。蓝色方框的部分可以管理环境变量。

在这个例子里,我设置了两个环境变量组,一个叫local用于本地测试,一个online用于线上测试,其中都包含一个名为saleschat的环境变量,分别是本地及线上的测试地址。这样,如果我想在本地及线上的测试进行切换时,只需要切换环境变量组就可以了。

全局变量

考虑这样一个场景,通过一个API获取一个token用于后续API的调用,那么我们是不是要每次都把获取的token拷贝到要使用的API里去呢。用全局变量可以极大的简化这一流程。

全局变量-wide 注意在API设置的选项卡中有Pre-request Script和Tests两项,它们可以接受代码片断,并分别在请求发出前和请求发出后执行。

在上面的图中,我在Tests选项卡下写了两行代码(javascript),把API调用的结果(json)中的token字段存储到全局变量token中。然后我们就可以这样来使用它了: 使用全局变量-wide 在这个例子中,所有的API调用都需要带上一个Authorization的header,其内容为Bearer token,那么我们只需要使用全局变量{{token}}来引用它就可以了,再也不用复制粘贴了。

测试

想验证结果是否正确,你可以查看API调用的输出,并自行判断。唉呀,结果好长,眼要花了。

Postman提供的测试功能能拯救你的眼睛和时间。

上一节我们提到,API设置中的Pre-request Script和Tests,可以分别在API调用前和调用后执行脚本。对于调用前脚本,通常可以清除或设置一些环境变量/全局变量来对API调用进行控制。而调用后脚本,上一节的例子可以看到,我们可以读取调用结果,并控制全局变量(环境变量当然也可以),在这里更重要的功能是对结果进行判断,也就是测试。 测试-wide 上图中的代码是很简单的,它包含两个互斥的测试用于演示,当tests["xxx"]的值为true时,测试通过,为false时测试失败。调用结果的Tests选项卡里很清晰的展示了测试的结果。

好了,写好你的测试逻辑,API的返回值再复杂也是小菜一碟啦。

等等,Postman还有更多功能,如果你有一组API,都写了测试脚本,不需要一个个的运行,点击右上角的Runner,可以对一组API进行测试。 Runner-wide 如上图所示,选择要测试的API组、环境变量组、运行次数、运行延时,点击开始测试,它会按顺序调用所有API并展示测试结果。

需要注意的是,所有测试代码都是运行在沙盒中,可以用到的包和工具见参考资料3

参考