• At the end of this article get the advanced guide to test development –

This article is intended for readers who have already mastered the basic usage of Postman, that is, they have a certain understanding of interface concepts and can use Postman to perform basic operations such as mock requests. Working environment and version:

  • Windows 7 (64-bit)
  • Postman (Chrome App V5.5.3)

The P.S. UI and the placement of some features will be slightly different from version to version, but not significantly so. Let’s start by thinking about what else needs to be done on basic mock requests to achieve automated interface testing. I can roughly summarize three questions (please leave more suggestions in the comments section) :

  1. How do I determine whether an interface request is successful?
  2. How do I perform batch and periodic interface tests?
  3. How to deal with the problem of interface dependence (for example, the interface for ordering goods must be logged in first)?

Therefore, the following is mainly divided into three parts to introduce how to solve these three problems. First of all, since it’s an automated test, we definitely need Postman or code to help us directly determine whether the results are as expected or not. So in the interface test, there are basically two ideas:

  1. Determine if the code returned by the request meets expectations
  2. Determine if the content returned by the request contains the expected content (keyword)

Let’s look at how Postman can be used to solve these problems:One of the most obvious things about Postman is that using Tests requires a certain level of programming language background, and JavaScript is currently supported. But the nice thing is that we don’t need to worry about the context or the runtime environment anymore, which means we just need to complete the code block of the resulting logic here. Postman also provides some common code templates in the SNIPPETS function area on the right side of the Tests panel, so it’s not a problem if you don’t know much about JavaScript. More on coding is covered below. The responseCode, responseBody, and tests variables can be used directly:

  • ResponseCode: contains the returned status information of the request (e.g. code).
  • ResponseBody: Data content (string type) requested by the interface to be returned.
  • Tests: is a form of key-value pair used to indicate whether our Test Results were successful or not, which is finally shown in Test Results.
  • Key: (e.g. Code 200) we can use as a description of the result.
  • Value: The value is a Boolean. True indicates that the test passes. False indicates that the test fails.

So the above code should be easy to understand, and with the data to return the results and the way to indicate their success, our “interface result judgment” problem is basically solved. Here are some examples:

  • ResponseTime: Indicates how long the request takes
  • Postman: You can do more, like
  • Get the header information for the returned data:

postman.getResponseHeader("")

  • Set global variables:

postman.setGlobalVariable("variable_key", "variable_value");See the official documentation for more. Postman has provided code templates for us in SNIPPETS for the most part. Here are a few that are relevant to judging results: Status code: code is 200 Response body: Contains string Response body: is equal to string Response body: JSON Value check Response time is less than 200ms JSON Value check Response time is less than 200ms JSON value check Response time is less than 200ms JSON value check Response time is less than 200ms JSON value check Response time is less than 200ms To batch test and manage interfaces, we need to store all of the interfaces to be tested in the same Collections, you can think of it as the same folder. Take a look at the steps in Postman:Through the above steps, we get a set of interfaces to be tested. To simplify the situation, the success condition of each interface on our side is judged by whether the code is 200 or not: When the above is ready, we can start to run the interfaces in batches to test:After clicking Run, a new page will open:

  • Environment: The Environment used to switch interfaces
  • Iteration: Sets the total number of times the interface should run.
  • Delay: Sets the interval between running interfaces, in milliseconds.
  • Data File: Upload test Data File (explained separately below)

We have seen how to run multiple interfaces multiple times, but the problem is that at this stage, the interface parameters are the same every time we run it, so it doesn’t matter if we run it 100 times or 1000 times. Let’s take a look at the interface we have written for the login function:Now login account and password parameters are written dead, that is, but we execute how many times, is to take this account to test. So what if you want to test for exceptions using other values for your account password parameter? (You can skip this section if you want to change it manually every time.) Here’s a quick look at how to use “variables” in Postman:

{{username}}, {{password}}, {{username}}, {{password}}, {{username}}, {{password}}. You can use the pre-Request Script panel to assign values to the Tests as follows: The scripts in the pre-Request Script are run before the request is executed, while the Tests scripts are executed after the request is completed. Therefore, we can use the Script to assign the first two variables in the pre-Request Script function area, such as: But using the pre-Request Script for assignment still doesn’t solve our problem, because no matter how many times we run it, we’re still testing with fixed (dead) data. Of course, since it is a scripting language, there will be more flexible usage, here will not be. Next, we’ll talk about Data File, which is used to upload test Data (files) to assign values to variables before running the collection. Let’s take the test data in CSV format as an example: The data format is similar to the table, the first line represents the corresponding variable name, and the following four lines represent the four groups of account and password data (two of which are correct data). After saving a file containing the above sample data with the suffix.csv, we start testing again to see the effect. After choosing 4 runs (for 4 sets of test data) and selecting the corresponding CSV file to run, we can see that our results are indeed as expected. The result of the interface Request run is two successes and two failures, that is, each run assigned with a different account password test data (in the latest version of the desktop client can see the specific situation of each Request, I won’t go into details here). When using Json, the format is as follows: Postman provides a monitor that will enable you to submit a test task and run it by a timer (for example, once per hour) as follows:After talking about interface result judgment and set batch testing, let’s take a look at the more complex case of dependency request problems, such as our shopping order interface requiring login before access. However, most of the dependency problem is essentially a problem of data transmission between interfaces. For example, when the login interface is called, an identifier is returned, assuming that it is token, so we can request the interface to place an order with token parameters. So, the question becomes:

  • Ensure the sequence of interface calls
  • The data returned by interface A is passed to subsequent interfaces B, C, and D

First, to clarify, the following interfaces all belong to the same collection by default. If you look at the results of our batch test, you will see that the interface is executed in the order (top to bottom) : Request1 -> Request2 -> Request3.So with this default order, we can put the interface that needs to be executed first, such as “login interface” first. Postman provides a function called postman.setNextrequest (” Enter the name of the interface you want to jump to “) that allows you to jump to the specified interface and continue executing. For example: In the Tests section of the Request1 interface, I can skip to the Tests section of the Request1 interface instead of running the Tests section of the Request2 interface.A few things to note here:

  1. Postman.setnextrequest () only works when running a collection test, that is, when we run the (Send) interface Request1 separately, the function does not work.

  2. After we run the collection test successfully from Request1 -> Request3, if there are interfaces behind the Request3, then the following interfaces continue to be executed in the default order, i.e. the interface in the figure Request4 will still be executed.

  3. The specified jump interface must belong to the same collection.

  4. The setNextRequest() function, no matter where it is called in the Tests script, is actually executed only at the end of the current script. For example, if we intercall the second line of the diagram with the first line, the second line will still be executed after the jump function is run.

So, using the setNextRequest() function, we can either conditionally skip unnecessary interfaces or build our own logic test. Before we talk about data transfer, let’s talk about the use of global variables and environment switches in Postman. The concept of global variables was briefly mentioned in the pre-request Script, which means that we can set global variables using Script code. We can see the effect of running the Script above: We can see that the username and password variables have been successfully saved, so we can use them in any interface using variable reference syntax such as {{username}}. In addition, Postman not only supports the way code sets global variables, it also supports visual operations:

After entering the corresponding interface, you can directly manage:Often, our interfaces are divided into test and online versions (or more), and the only difference between them may be the ULR, so global variables are not suitable to solve this problem. As you may have noticed, I have built several parameter “sets” for different environments in the figure above. Take a look:I created a host parameter in each environment, such as:Of course, our environment parameters can also be set by script. The function is as follows: Parameters in the environment “parameter set” are used in the same way as global variables, as shown in the figure {{host}}.With that in mind, let’s look at how to use Postman to solve interface tests with dependencies. Our interface Request1 is the login interface, and a successful login will return an access_token field as an identifier (implemented). Suppose the interface Request3 is an order placing interface that needs to carry the access_token returned by the login.

  1. Ensure that Request1 is run before Request3
  2. Add the value of access_token returned by Request1 to the environment variable “Parameter set”.
  3. Request3 references the value of access_token at request time
  4. The Request1 interface is guaranteed to take precedence in our directory
  5. The Tests code in Request1 looks like
  6. Use variable token in Request3:

Run the collection test and see that our results match our expectations, Request1 and Request3 pass the test, Request2 is skipped, and Request4 is still executed. The Done…

The original link

For more technical articles to share and free materials to collect click on: ‘qrcode.testing-studio.com/f?from=juej…

For more technical articles to share and free materials to pick up click on the link