Automated testing using PostMan

I have been upgrading an old project recently. The first step is to upgrade the node version from 4.x to 8.x. I am worried that problems may arise in the upgrade, so I need to upgrade the service Interface for verification;
If you manually enter various URLs, human flesh check, one or two is fine, the entire service. . Having dozens of interfaces is a waste of time -.-;
Because it is a pure interface service project, we plan to conduct a wave of automated testing for the corresponding API;
So we started looking for the corresponding tools. Suddenly I discovered that the PostMan I usually use seems to support writing test cases -.-, so I followed the documentation and read it;
I was very excited all afternoon. I used ## before. #PostMan is limited to modifying Header and adding Body to send requests. I have never considered using PostMan for testing. After using it for an afternoon, I feel that the New World.

Installation of PostMan

It seems that downloading and using

PostMan must be done through the firewall-.-Because two forms of App are now available:

1. chrome plug-in (already almost abandoned, it is recommended to use an independent App)

2. Independent App

And you need to log in to your account when using it. I log in directly with my

Google account-. -There seems to be other ways, but I didn't try them.

Independent App version cloud disk address (

Mac version, 6.0.10 just downloaded today, please get it yourself if you need it): Link: https://pan.baidu. com/s/18CDp... Password:
mrpf

After downloading and decompressing, you can run it directly, and then register an account. The visual account number is mainly used for follow-up. Required for group sharing (you can directly share your call records with others).

Send a request

This is the most basic usage of

PostMan, used to send a request. You can set
Header, Body and other information.

Collections

We can save each request sent so that the next time we request the interface, we can call it directly,

If you save the request, it will be saved in a
Collections, similar to a collection.
PostMan provides a method to run all requests in the entire Collections with one click.

Then we can directly run all the requests in the collection when needed.

When saving the request record, select the corresponding

Collection below

Start API test

Test script location

##PostMan
Test script written for the request, At this location, the JavaScript syntax is used, and on the right are some preconfigured code snippets. And we can write a script in Pre-request Script
to execute before sending the request. Some simple syntax

PostMan

also provides an assertion to help with some verification. <pre class="brush:php;toolbar:false">tests['Status code is 200'] = responseCode.code === 200 tests['Data length &gt;= 10'] = JSON.parse(responseBody).data.length &gt;= 10</pre> Assigned a value of

true

means passing, false means failure. The direct assignment of tests
is relatively limited. If you perform some other asynchronous operations in the script, you need to use pm.test. <pre class='brush:php;toolbar:false;'>setTimeout(() =&gt; { pm.test(&quot;test check&quot;, function () { pm.expect(false).to.be.true }) })</pre> Only the above

tests

assignment +pm.test/pm.expect can meet our needs, and the rest are just above this It's just syntactic sugar. Various syntax examples
Send a request in the test script

We can send some new requests based on the result after getting a

API

return result , and then add assertions. <pre class='brush:php;toolbar:false;'>let responseJSON = JSON.parse(responseBody) // 获取关注的第一个用户，并请求他的用户信息 pm.sendRequest(responseJSON[0].url, function (err, response) { let responseJSON = response.json() pm.test(&amp;#39;has email&amp;#39;, function () { pm.expect(responseJSON.email).is.be.true // 如果用户email不存在，断言则会失败 }) });</pre>If we have some dynamic interfaces to test, we can try this writing method.

The first-level interface returns

List
The second-level interface obtains the corresponding information based on the ID
of List. <h3 id="如何处理大量重复的断言逻辑">如何处理大量重复的断言逻辑</h3> <p>针对单个API，去编写对应的断言脚本，这个是没有什么问题的。<br>但是如果是针对一个项目的所有<code>API去编写，类似于判断statusCode这样的断言就会显得很溶于，所以PostMan也考虑到了这点。
在我们创建的Collection以及下层的文件夹中，我们可以直接编写针对这个目录下的所有请求的断言脚本。


这里的脚本会作用于目录下所有的请求。
这样我们就可以将一些通用性的断言挪到这里了，在每个请求的Tests下编写针对性的断言脚本。

变量的使用

PostMan提供了两种变量使用，一个是global，一个是environment。

global

代码操作的方式：

pm.globals.set("variable_key", "variable_value") // set variable
pm.globals.get("variable_key") // get variable
pm.globals.unset("variable_key") // remove variable

通过GUI设置：

设置完后我们就可以这样使用了：

基本上在所有的可输入的地方，我们都能够使用这些变量。

environment

环境变量，这个是权重比global要高一些的变量，是针对某些环境来进行设置的值。
操作方式类似。

在使用代码操作的方式时，只需将globals替换为environment即可。
在发起一个请求，或者一键发送所有请求时，我们可以勾选对应的环境，来使用不同的变量。

在针对大量API测试时，拿environment来设置一个domain将是一个不错的选择。
这样在请求中我们只需这样写即可：

{{domain}}/res1
{{domain}}/res2

domain: https://api.github.com

一个简单的示例：

通过直接运行一个Collection，我们可以很直观的看到所有的接口验证情况。

参考资料

https://www.getpostman.com/do...

之前使用PostMan，最多就是模拟一下POST请求，最近刚好碰到类似的需求，发现原来PostMan还可以做的更多。
这篇只是使用PostMan进行API测试的最基础操作，还有一些功能目前我并没有用到，例如集成测试、生成API文档之类的。

接口相当于是获取和操作服务资源的方式，肯定属于产品的核心。
所以测试是必须的，在交付QA同学之前，自己进行一遍测试，想必一定能节省一部分的时间。

相关推荐：

chrome插件postman安装问题_html/css_WEB-ITnose

The above is the detailed content of Automated testing using PostMan. For more information, please follow other related articles on the PHP Chinese website!