Automated testing of Postman interface in one minute

Summary

I have a side job (free, but the point is fate, after all, I don’t have enough time), and I happen to be instructing some graduated programmers to find jobs. I found that the difference in ability is reflected in the hard work acquired, and the gap in professional development is formed in cognition. At the same time, the latest software testing resources (video tutorials, PDF documents, interview questions) in the last two months are also organized.

Friends who need this information can add my public account [Sad Spicy Bar] to receive it.

This article is suitable for readers who have mastered the basic usage of Postman, that is, have a certain understanding of interface related concepts, and already use Postman for basic operations such as simulation requests.

Working environment and version:

Window 7 (64 bit)
Postman （Chrome App v5.5.3）

PS different versions of the page UI and the location of some functions will be a bit different, but the impact is not big.

First of all, let's think about it, if we want to achieve the effect of automated interface testing, what else needs to be done in the basic simulation request?

I roughly summarized into 3 questions (please leave a message in the comment area for more supplementary suggestions):

How to judge whether the interface request is successful?
How to perform batch and regular testing of interfaces?
How to deal with the problem of relying on the interface (for example, the interface for placing an order must require login first)?

Therefore, the following is mainly divided into 3 parts, introducing how to solve these 3 problems.

1 Interface result judgment

First of all, since it is an automated test, then we definitely need to use the tool Postman or code to help us directly determine whether the results meet expectations. Then in interface testing, there are roughly two ideas:

Determine whether the code returned by the request meets expectations
Determine whether the content returned by the request contains the expected content (keyword)

Next we look at how to use Postman to solve the above problems:

1.1 Functional area

Related functions in Postman are very conspicuous. The use of Tests requires us to have a certain programming language foundation. The currently supported scripting language is JavaScript. But the better point is that we don't need to consider the context and operating environment. That is to say, we only need to complete the code block of the result logic judgment here.

And Postman also provides us with some commonly used code templates, in the SNIPPETS functional area on the right side of the Tests panel, so it is not a big problem if you don't know much about JavaScript. Code writing will be described in detail below.

1.2 Script related

Looking at the code part of the figure above, we can find three variables: responseCode, responseBody and tests (can be used directly):

responseCode: Contains the returned status information of the request (such as code).
responseBody: The data content returned for the interface request (type is string).
tests: in the form of key-value pairs, used to indicate whether our test results are successful or not, and are finally displayed in Test Results.
key: (eg code 200) we can use it as a description of the result.
value: The value is Boolean, true means the test passed, false means the test failed.

So the above code should not be difficult to understand, and with the data of the returned result and the way to indicate the success or failure of the result, then the problem of our "interface result judgment" is basically solved.

There are also several more commonly used ones:

responseTime: the length of time the request took
postman: You can do more, such as

Get the header information of the returned data:
postman.getResponseHeader("")
set global variables:
postman.setGlobalVariable("variable_key", "variable_value");

1.3 Code template

The code templates provided by Postman in the SNIPPETS functional area have been able to solve most of the situations. Here are a few explanations related to the result judgment:

Status code : Code is 200

//Judging the request status according to the returned Code tests["Status code is 200"] = responseCode.code
=== 200;

Response body: Contains string

//Determine whether there is a "keyword" in the returned content. (The key of tests can be modified and will not be emphasized again) tests["Body matches
string"] = responseBody.has("This can be changed to the content of the keyword you want to judge"); //As mentioned above:
// Determine whether there is access_token keyword tests["has access_token"] =
responseBody.has("access_token");

Response body: is equal to string

//Determine whether the returned content is exactly the same as expected. tests["Body is correct"] = responseBody ===
"This can be changed to your expected content";

Response body: JSON value check

//As mentioned above, responseBody is a string type and supports conversion to Json format var jsonData =
JSON.parse(responseBody); tests["Your test name"] = jsonData.value ===
100;

Response time is less than 200ms

//Determine whether the request duration is less than 200ms, and customize tests according to the specific duration["Response time is less than
200ms"] = responseTime <200;

The above introduction is basically enough to complete the test of a single interface, but we know that if there is no batch, timing task, then these will be meaningless, so continue...

2 Set (batch) test

If you want to perform batch testing and management of interfaces, then we need to save all the interfaces to be tested in the same collection (Collections), you can think of saving them in the same folder. First look at the steps in Postman:

Through the above steps, we get a set of interfaces to be tested. In order to simplify the situation, the condition for the success or failure of each interface on my side is to judge whether the code is 200:

tests[“Status code is 200”] = responseCode.code === 200;

2.1 Batch execution

After the above is ready, we can start to run the interface in batches for testing:

After clicking Run, a new page will open:

Environment: Used to switch the environment in which the interface runs, don't care here, and talk about it later
Iteration: used to set the total number of times the interface will run.
Delay: Set the time interval between each operation of the interface, in milliseconds.
Data File: Upload test data file (described separately below)

2.2 Changing parameter data

We have already understood how to make multiple interfaces run multiple times in a loop, but now there is a problem. According to the current step, the interface parameters are the same every time it runs, so even if we run it 100 times or 1000 times, it means Not big.

Let's take a look at the login function interface we have written:

Use variables

Now the login account and password parameters are hard-coded, that is, the account is used to test how many times we execute. So what if you want to test whether the account password parameter uses other values abnormally? (If you want to manually change it every time, you can skip this part/manually funny) Here we briefly talk about how to use "variables" in Postman, as shown below:

The syntax for referencing a variable: { {variable name}}, as you can see in the figure, we set the parameter values of the account and password fields as variables: { {username}}, { {password}}. After the modification, it is not possible to click Send directly, because the two variables have not been assigned yet, but we can perform assignment operations in the Pre-request Script panel:

Pre-request Script

Pre-request Script is similar to Tests. The difference is that the script in Pre-request Script is executed before the request is executed, while the script in Tests is executed after the request is completed. Therefore, we can use the script to assign values to the above two variables in the Pre-request Script function area, such as:

//Set global variables postman.setGlobalVariable("username", "test1");
postman.setGlobalVariable("password", "123456");

But using Pre-request Script for assignment operation still can't solve our problem, because according to this writing method, no matter how many times it is run, it is actually tested with fixed (hard-coded) data. Of course, since it is a scripting language, there will be more flexible usages, so I won't do it here.

Test data set

Next, we will talk about Data File. This option before running the collection is used to upload test data (files) to assign values to the corresponding variables. Let's take the test data in CSV format as an example:

username,password
test1,123456
test2,222222
test3,123456
test4,444444

The data format is similar to a table. The first row represents the corresponding variable name, and the following 4 rows represent 4 sets of account and password data (two of which are correct data). After we save a file with the above sample data suffix named .csv, Start the test again to see the effect. After we select the number of runs to 4 (corresponding to 4 sets of test data) and select the corresponding CSV file to run, we can see that our results are indeed as we expected. The result of the interface Request operation is two successes and two failures, that is, the test data with different account passwords assigned to each operation (in the latest desktop client version, you can see each specific request, here is I won't go into details anymore).

If you use Json files, the format is as follows:

[
  {
    "username": "test1",
    "password": "123456"
  },
  {
    "username": "test2",
    "password": "222222"
  },
  {
    "username": "test3",
    "password": "123456"
  },
  {
    "username": "test4",
    "password": "444444"
  }
]

2.3 Periodic tasks

Postman provides a Monitors function, which supports us to submit a test task and run it according to the set timer, such as once an hour, the specific operations are as follows:

3 Request dependency problem

After talking about the judgment of the interface result and the collective batch test, let's take a look at the more complicated situation, that is, the problem of relying on the request. For example, our shopping order interface requires login before being accessible. But most of the dependency problems are essentially data transfer problems between interfaces. For example, after calling the login interface, an identifier is returned. If it is a token, then we only need to carry the token parameter when requesting the order interface. So, the question becomes:

Ensure interface call order
Pass the data returned by interface A to subsequent interfaces B, C, D

3.1 Interface execution sequence

First of all, let me explain that all the interfaces mentioned below belong to the same collection by default.

Take the example of the interface collection we created above. If you pay attention to the results of our batch testing, you will find that the execution order of the interfaces is actually in the order in this directory (from top to bottom), namely: Request1- > Request2 -> Request3.

The name of the interface here may be a bit misleading, so I want to emphasize it again: execute in the order from top to bottom in the directory (it has nothing to do with dictionary sorting).
So with this default execution order, then we can prioritize the interfaces that need to be executed Just put it in front, for example, put the "login interface" first.

3.1.2 Custom execution order

Of course, if there is only a default execution order, it is usually unable to meet our complex business needs, so Postman provides us with a function: postman.setNextRequest ("fill in the name of the interface you want to jump to") to support us to jump Continue execution to the specified interface, for example:

After successfully running the Request1 interface, we don’t need to run Request2 again but jump directly to Request3. Then I can execute the jump code in the Tests function area of the Request1 interface, such as:

A few things to note here:

postman.setNextRequest() only takes effect when running a set test, which means that when we run the (Send) interface Request1 alone, the function does not work.
When we run the collection test successfully from Request1 -> Request3, if there are interfaces after Request3, then the following interfaces will continue to be executed in the default order, that is, the interface Request4 in the figure will still be executed.
The specified jump interface must belong to the same set.
No matter where the setNextRequest() function is called in the Tests script, it will only be executed at the end of the current script. For example, after we intermodulate the second line and the first line in the figure, the second line of code will still be executed after running the jump function.

Therefore, using the setNextRequest() function, we can skip unnecessary interfaces according to the conditions, or create our own logic test.

3.2 Data transfer

Before talking about data transfer, let's talk about the use of global variables and environment switching in Postman.

3.2.1 Global variables

The concept of global variables is actually briefly mentioned when we talked about Pre-request Script above, that is to say, we can set global variables through script code, we can see the effect of running the above script:

We can see that after running, the username and password variables have been successfully saved, so we can use them in any interface through variable reference syntax such as: { {username}}.

In addition, Postman not only supports the way the code sets global variables, it also supports visual operations:

After entering the corresponding interface, you can directly manage:

3.2.2 Multi-environment differentiation and switching

Under normal circumstances, our interface will be divided into test version and online version (or more), and their difference may only be different in ULR, then global variables are not suitable to solve this problem.

Creation of parameters

You may have noticed that in the above picture, I have already built several parameter "sets" for different environments. Let's take a look:

I created a host parameter in each environment, such as:

Of course, our environment parameters can also be set by means of scripts, the function is:

//Note that this parameter is only added to the "parameter set" of your currently selected environment
postman.setEnvironmentVariable("variable_key", "variable_value");

Use and switch

The parameters in the environment "parameter set" are used in the same way as global variables, as shown in the figure { {host}}, the switch between different environments is shown in the figure below:

3.3 Solve dependency problems

After mastering the above prerequisite knowledge, we began to see how to use Postman to solve interface tests that have dependencies.

What-if scenario

Our interface Request1 is the login interface, and a successful login will return an access_token field as an identifier (implemented). Then suppose that the interface Request3 is an interface to place an order, and it needs to carry the access_token returned by login to access it normally.

Ideas

Ensure that Request1 is run before Request3
Add the value of access_token returned by Request1 to the environment variable "Parameter Set".
Request3 refers to the value of access_token when requesting

The return value is stored in "global variables" or "environment variables", depending on the specific business situation. In this example,
the value of access_token is related to the environment, so here we choose to use environment variable set storage.

Operations in Postman

Our catalog has guaranteed the priority execution of the Request1 interface
The code of Tests in Request1:

if(responseCode.code === 200 && responseBody.has("access_token")){
    
    
    //如果 code 为 200， 并且返回的数据中存在 access_token 关键字，则认为登录成功
    tests["login"] = true;

    //将返回的内容转为 json 格式，并且取到 access_token 内容，添加到环境变量中
    var jsonData = JSON.parse(responseBody);
    //access_token的取值方式视具体的 json 数据结构而定
    postman.setEnvironmentVariable("token",jsonData.result.access_token);  

    //跳转到 Request3 接口
    postman.setNextRequest("Request3")

}else{
    
    
    tests["login"] = false;

    //登录失败，可以选择跳转到对应失败后的处理接口进行测试
    //postman.setNextRequest("Other Request")
}

Use variable token in interface Request3:

I am here is to tokenput the header information, the interface parameters rules specific use may be.

Run and view results

Running the set test, we can see that our results meet our expectations, Request1 and Request3 pass the test, Request2 is skipped, and Request4 is still executed. Done...

Finally: benefits

In the technology industry, you must improve your technical skills and enrich your practical experience in automation projects. This will be very helpful for your career planning in the next few years and the depth of your testing technology.

In the interview season of Golden 9th and Silver 10th, job-hopping season, organizing interview questions has become my habit for many years! The following is my collection and sorting in recent years, the whole is organized around [software testing], the main content includes: python automation test exclusive video, Python automation details, a full set of interview questions and other knowledge content.

Don't be ashamed of getting an 8k salary, don't be complacent just because you get a salary of more than 20k, don't be complacent just because you get a 30-45 salary. Life is not to earn that little salary, what you need is to open a career.

May you and I meet and you will find something! Welcome to follow the WeChat public account: [Sad Spicy Article] Receive a 216-page software test engineer interview book for free. And the corresponding video learning tutorials are free to share!

Good article recommendation:

Talking about starting from a small company to a big factory, what did I do right?

Does it make sense for ordinary people to learn Python automation?

What kind of person is suitable for software testing?