background

In the testing, there will often be simulated user login, get the user token and then request the interface.

This simulated user login will be divided into two types, one is a single user, the other is a multi-user.

In daily automated testing, there may be n use cases for one user to meet most scenarios.

If it’s under a stress test scenario, it might be a little monotonous and not fit for some real business scenarios.

In the case of a single user, there is not much difference from our regular multi-interface dependency tests.

So this is mainly about the case where multiple users generate multiple tokens.

Let’s take a look at a specific example.

Scene: the interface

In this case, there are only two interfaces, one is to log in to get the token, the other is to have the token to request.

Below are the interface definitions

Login interface

Request:

POST http://localhost:8532/MultiToken/Login
Content-Type: application/json

{
	"UserName":"catcherwong-1",
	"Password":"123"
}
Copy the code

Response:

{"code":0."msg":"ok"."data":"catcherwong-1-token"}
Copy the code

Business interface

Request:

GET http://localhost:8532//MultiToken/do? account=xxxContent-Type: application/json
token: catcherwong-1-token
Copy the code

Response:

{"code":0."msg":"ok"."data":"catcherwong-1-token"}
Copy the code

Login Interface Processing

The login interface is pre-requested, so we typically choose to place it in the setUp thread group.

We need to prepare a CSV file to store the user name and password for login.

The next step is to configure the CSV, defining two variables account and PWD

Then configure the HTTP request for login:

Since the token will be used later, the token will be extracted first, and JSON Extractor is used here.

Here we begin to pay attention to ！！！！

Since we will have multiple users logging in, this extract operation assigns the token to the access_token variable each time and is an override operation.

In other words, for each user logged in, the access_token value is the token of the last user logged in.

Another way to think about it is that every time it overwrites, you can simply store the tokens in a place where the business interface can fetch them.

If there is no user login step and the token is given directly, then we can put the token into a CSV file and let JMeter recycle the token inside.

After extracting the token, write the token to a CSV file.

To do this, you need to add a post-processing to the login interface.

String p1 = System.getProperty("user.dir");
String p2 = System.getProperty("file.separator");
String p3 = "user_token.csv";
String path = p1 + p2 + p3;

FileWriter fileWriter = new FileWriter(new File(path), true);
BufferedWriter writer = new BufferedWriter(fileWriter);
writer.append(vars.get("accout") +","+vars.get("access_token") +"\n");
writer.close();
fileWriter.close();
Copy the code

This code writes the username and the extracted access_token into a CSV file in the JMeter directory.

Here is the file path to do processing, can be adapted to all operating systems. It won’t appear that you specify a Windows path and then put it under Linux and it won’t work.

The most important one is to change the setUp thread group properties to change the number of loops to 3. Because there are three users in the previous CSV file, it triggers three logins.

Business interface processing

The business interface is placed in a normal thread group, separate from the setUp thread group.

As mentioned earlier, you will have a CSV file after logging in, so the first thing to do here is configure the CSV.

The screenshot above uses ${__P(user.dir,)}${__P(file.separator,)}user_token.csv as the file path. This is fine with Jmeter in the local environment, but not with some cloud services, such as Ali Cloud PTS.

You can ignore the preceding path and simply fill in user_toke. CSV. The two paths are the same, one absolute path and the other relative path.

Then it’s time to configure the HTTP request

PS: Don’t forget to configure the request header as well, so we won’t take screenshots here.

The token request header of the token request is different each time. This is as expected.

However, you will find that the data generated in the CSV file is repeated, and the data generated last time is not automatically cleaned up. If the tokens generated last time expired, then use those expired tokens to cool off.

There is also a need to add a tearDown thread group to delete the file each time the script finishes running.

String p1 = System.getProperty("user.dir");
String p2 = System.getProperty("file.separator");
String p3 = "user_token.csv";
String path = p1 + p2 + p3;

log.info("Ready to delete file :" + path);

File file = new File(path);
if(! file.exists()) { log.info("Failed to delete file :" + path + "It doesn't exist!);
} else {
  file.delete();
}
Copy the code

At this point, running scripts is basically no problem.

Write in the last

In fact, there are many scenarios in which multiple users obtain multiple tokens and then use them. This article briefly explains a scheme Lao Huang is using. If you have better suggestions, please kindly communicate with us.

Lao Huang put JMeter series content on Github, convenient for everyone to check and test.

Github.com/catcherwong…

Follow my public account “Bucai Old Huang” and share with you what huang sees and hears in the first time.