In the previous article segmented random practice – Simulation of online flow, the implementation of segmented simulation was shared. The application of this method in practical work can carry out more refined simulation of online flow.

Today I will share an application of a service module in real work. This module was chosen for two reasons: most are GET interfaces; The parameters are simple and most of them are single parameters.

Combing model

Module model

For the PI interface of the whole service, you can analyze the logs in a certain period of time to obtain the proportion of the request traffic of each interface. Or through statistical services. That’s also available. A traffic scale model for the entire interface.

Here, I saved the traffic ratio in a map, and the data is as follows:

    public static final Map<String, Integer> urlsQps = new HashMap<String, Integer>() {{
        put(a, 9502);
        put(b, 6445);
        put(c, 1228);
        put(d, 973);
        put(e, 827);
        put(f, 546);
        put(g, 132);
        put(h, 113);
        put(i, 47);
        put(j, 1);
    }};
Copy the code

So we’ve done a simple scaling here, dividing all the values by the ratio of the smallest. In the future, the interfaces will be divided into different levels according to the traffic order of magnitude, and the interfaces of different levels will be simulated respectively. For interfaces with low daily traffic (temporarily less than 5QPS), the fixed QPS is 20 times the daily traffic as the basic background traffic.

Interface model

Then, collect statistics on interface parameters. You can obtain the ratio of each parameter using log statistics (even for GET interfaces).

Put the data in a map as follows:

    public static final String BS = "* * * *";
    public static final List<String> BS_ARGS = SourceCode.randomMem(new HashMap<String, Integer>() {{
        put("aaa".3);
        put("bbb".2);
        put("ccc".2);
        put("ddd".1);
        put("eee".3);
        put("fff".1);
    }});
Copy the code

The calculation method is the same as above. All parameters are not exhausted here for two main reasons. One is that interface parameters are distributed in a concentrated way, and a small number (the first 10 or 20) can achieve the goal. One is that some interface parameters are composite, and if too many are exhausted, they are not suitable for the current business framework and can be made into configuration files later.

practice

The interface traffic is shared first, and then the service traffic, because the two are dependent.

The interface flow

The framework provides support to encapsulate an interface as a method that exposes relevant parameters, such as:

    /** * get information *@param instId
     * @return* /
    JSONObject bs(String Id = random(MApi.BS_ARGS)) {
        String url = MApi.BS
        def params = getParams()
        params.instId = instId
        def response = getGetResponse(url, params)
        print(response)
        response
    }
Copy the code

By means of random method, parameters in MApi#BS_ARGS can be transmitted to method M#bs(java.lang.string) in proportion to value to achieve the purpose of quantification and simulation of online traffic.

Module flow

The interface is first encapsulated according to the project framework, and then the interface request is made based on the contents of the configuration file MApi#urls.

The implementation is as follows:

/ * * * all quantitative simulation interface * /
    public void all(a) {
        def url = random(MApi.urls)
        if (url == MApi.a) {
            a()
        } else if (url == MApi.b) {
            b()
        } else if (url == MApi.c) {
            c()
        } else if (url == MApi.d) {
            d()
        } else if (url == MApi.e) {
            e()
        } else if (url == MApi.f) {
            f()
        }

    }
Copy the code

The random method is still used. At first, I was worried about the performance problem. After testing, random performance is ok with millions of QPS, what is needed here is thread safety, and multiple threads can use the same MAP #urls.

Have Fun ~ Tester!

  • FunTester test framework architecture diagram
  • JMeter Chinese Operation Manual with a sense of time
  • 140 interview questions (UI, Linux, MySQL, API, security)
  • Graphic HTTP brain map
  • Share a Fiddler study bag
  • JVM command brain map for testing
  • The Definitive Guide to Java Performance
  • There is no data to drive automated tests
  • HTTP asynchronous connection pooling and multithreading practices
  • Bind mobile phone number performance test
  • Discussion on assembly point and multi-stage synchronization in performance testing
  • How to become a Full stack automation engineer
  • LT browser – responsive web testing tool
  • Simplify test cases