The most detailed in the whole network, Jmeter interface test-realize dynamic association and actual combat arrangement, you have everything you want...

Contents: Guide

foreword

Business scenario:
The user enters the correct user name and password to log in to the system. If the login user has multiple companies, he needs to select the corresponding company to enter the system (if there is only one company, directly enter the system), and can browse company-related product information.

Implementation logic:
After the user successfully logs in, a token value will be obtained first, and an access_token will be provided synchronously for security reasons. Select a company when logging in and perform operations after entering the system, such as browsing products, will verify whether the token value and access_token value are normal.

If both are normal, the operation can be successful, but if the token value and access_token value are not passed or invalid, subsequent operations will fail.

The two interfaces are in the same thread group:
If the two interfaces are in the same thread group, it is relatively simple for JMeter to implement dynamic association, which can be done by adding the Http information header manager.

As shown in the figure below, when logging in to select a company, the corresponding token and access_token are not passed, resulting in the failure of the interface for selecting a company, and subsequent operations related to product browsing also fail.

Let's look at the content in the HTTP header manager, $token Get the token value under the login request$ , and get the corresponding token type and access_token value under the AccessToken request through {token_tpye $}$ $$$ ${$ $access_token$ $}$ $.$

After enabling the HTTP header manager, the execution can pass normally again.

If the login system and browsing products are not under the same thread group, how to realize the dynamic association of parameters?

When I learned this piece today, I summed up the general idea, and I hope everyone can correct me if I am deficient.

The two interfaces are not in the same thread group:
now the login system and the browsing product are not in the same thread group. If you follow the previous processing method and add an HTTP header manager to execute, you will still report a 401 error, as shown in the figure.

Solution ideas:
1. First extract the token and access_token values in the previous interface;
2. Set the extracted token and access_token as global variables;
3. At the same time, a Beanshell sampler is needed to execute a piece of java code;
4 , Here you need to use the function assistant __setProperty to set token and access_token as global variables, and the generated code

${
    
    __setProperty(Token,${
    
    token},)}

${
    
    __setProperty(Token_Type,${
    
    token_type},)}

${
    
    __setProperty(Access_Token,${
    
    access_token},)}

into the Beanshell sampler;

5. In the next interface, generate code through the function assistant __property

${
    
    __property(Token,,)}

${
    
    __property(Token_Type,,)}

${
    
    __property(Access_Token,,)}

6. In the next interface, get the token and access_token values of the response through the code generated in step 5 in the HTTP header manager.

Operation steps:
1. Set token, token_type, and access_token as global variables through the function assistant __setProperty, and put them into the BeanShell sampler;

2. Use the function assistant __property to generate callable Token, Token_Type, Access_Token expressions and corresponding names. In the next interface, call the corresponding values in the HTTP header manager.

So far, the interface has been debugged.

The following is the most complete software test engineer learning knowledge architecture system diagram in 2023 that I compiled