Super detailed, detailed explanation of the three major modes of performance testing, experienced test veterans explain it all...

---

foreword

In performance testing, the business model, traffic model, and data model are crucial and must be built in the project, otherwise it is likely to cause a large gap between the test scenario and the actual situation, and the test results cannot provide sufficient information for performance analysis and optimization. Convincing support.

The three major models are illustrated by taking the scenario of placing an order in an e-commerce business as an example, as shown in the following figure:

business model

You can think of business models as business scenarios in functional testing. To build a business model in performance testing, we need to consider the following factors:

Whether the product inventory is sufficient;
whether the ordered product can participate in marketing activities;
whether the user who placed the order is a VIP member and has a member discount;
whether the user who placed the order has a coupon, and whether the coupon meets the preferential conditions of this order;
…

In fact, there is no difference between the business model and the business scenario analysis during functional testing. They are all for analyzing the business and services under test to ensure that the test scenarios and requirements are consistent.

If it is a more complex business and a wider range of testing requirements, factors such as traffic entry and risk control of online business may also be considered.

Of course, in actual work or projects, it is recommended to sort out the business and scenarios involved in stress testing by analyzing requirements, and draw a business model mind map, which facilitates subsequent work.

The mind map of the business model can be a tree diagram or something similar to the above picture, which is easy to understand.

traffic model

We all know that performance testing is performed based on an interface or a certain URL when performing stress testing. The essence is to simulate users in the production environment, construct requests to put pressure on the system under test, and verify whether the system performance meets business needs and whether there is a performance bottleneck.

The user operation scenarios in the production environment are very complex, so the request size and request path are also different.

The above picture is an example. When placing an order, some users used coupons, some users were not VIP members and could not enjoy discounts, and some products had no marketing activities. These factors require us to construct different requests according to different business scenarios when constructing requests.

The essence of the so-called traffic model is to configure requests according to the real ratio according to different business scenarios, which is also called business ratio.

You can also understand the traffic model as a pressure measurement model. The common pressure measurement models in the work are as follows:

Single-machine single-interface benchmark test
The most common benchmark test is to perform stress testing on login scenarios.

The pressure test of a single machine and a single interface can use gradient increment to observe the changes in performance and resource consumption as the number of requests increases.

Stand-alone hybrid link capacity test
The above figure is an example. The order service includes interfaces such as creating an order, canceling an order, order list, and order details.

The request size and request content of each interface are different. In stand-alone hybrid scenarios, most of the requests are increased through gradients to observe the performance of the service level. The purpose is to troubleshoot the bottleneck of upstream and downstream call dependencies.

Production environment full-link stress test scenario
For the full-link stress test of production clusters, a common case is the double 11 e-commerce promotion. There are many full-link stress test models for production, generally as follows:

Gradient pressurization: to detect the maximum throughput of the system in cluster mode (to avoid crushing services and causing accidents);
fixed concurrency: to verify the stability of the system under long-term load;
pulse concurrency: to detect the robustness of the system and verify the current limit fuse Correctness & availability of service protection measures;
Oversold verification: For e-commerce business, it is mainly aimed at some time-limited rush & flash sales scenarios (generally such scenarios will involve technologies such as distributed locks, caching, and data consistency) point; if you don’t play well, it is easy to cause customer complaints, capital losses, and even abnormal service downtime!);

Building a traffic model
This is a case of traffic model construction during a double 11 promotion in the actual work before, for reference only.

Business goal: on Double 11, the estimated average customer unit price is 500, and the single-day GMV is 1 billion, so the payment order volume is 1 billion/500=200W;

Technical indicators:

Assume that the daily payment order volume is 50W, the payment conversion rate is 40%, and the order payment QPS peak value is 200. It is estimated that the payment conversion rate during the big promotion is 60%, then it can be obtained: the peak order payment QPS of the big promotion is (200/40%) 60% (200W/50W) = 1200QPS. In order to leave a certain amount of redundancy, it is increased by 30%, that is, the QPS of order payment is estimated to be 1500;

The order payment link of the e-commerce shopping guide is: homepage → product details → create order → order payment → successful payment, which is a conversion logic similar to a funnel. Assuming that the conversion rate of home page → product details is 40%, product details → create order conversion rate is 40%, create order → order payment conversion rate is 40%, then it can be obtained: create order QPS is 1500/40%=3750, product details QPS is 3750/40%=9375, home page QPS is 9375/40%=23437;

According to the dependency call relationship between the core links, with the help of trace tracking, the QPS values ​​of all core applications and core links during the promotion period can be obtained.

It is recommended that after evaluating the traffic model, draw a traffic model diagram based on the business scenario and the call relationship between services, which will be more intuitive and facilitate work.

data model

After understanding the business model and traffic model, the data model is easy to understand.
The above figure is an example. When building a data model for an e-commerce order business, different types of data must be prepared according to the stress test frequency, stress test times, and stress test scenarios.

When preparing data, it is also necessary to consider the validity of the data, the magnitude of the data, the logical relationship of the combination of the data, and whether the data conforms to the data distribution of the production environment.

If the data used in the test process is inaccurate, the test results often have large deviations. Regarding the construction of the test data model, you can refer to the following points:

Data information	illustrate
limitation factor	User operation authority, number of data references, data expiration setting (number of times, absolute time)
The amount of data	What is the amount of data in the actual production environment, and how to replace it in the same amount in the performance test environment
type of data	Basic data, hot data, cache data, special data
data characteristics	Whether it can be reused, whether it is unique, self-incrementing, encryption, splicing, escaping, etc.
preparation method	copy real environment data, pre-embedded data, desensitized generated data

Basic data
is also called base data. The purpose of base data is to be consistent with online (at least the quantity distribution is consistent), combined with online growth rate, to confirm the magnitude and mode of pre-embedded data.

When it comes to the data that needs to be verified during stress testing, it needs to be carefully designed when laying the groundwork, including data size, quantity, and distribution.

Hot data
It is necessary to understand the implementation logic of the interface under test, and confirm the following information:
whether there are operations related to hot data: for example, all users spike the same product;
when different types of data processing logic are different, it is necessary to improve performance testing through test data diversification code coverage;

Cache data
To confirm whether there is a cache, the size of the cache.

Data related to flash sales are generally processed in a queue, and this type of data is put into the cache for processing to cope with high concurrency.

Another example is the token and other data required for user login. During stress testing, the structured data can be preheated to the cache in advance to avoid user service becoming a bottleneck during stress testing.

Building a data model
The most intuitive purpose of building a data model is to parameterize test data during stress testing.

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

1. From entry to mastery of Python programming

2. Interface automation project actual combat

3. Actual Combat of Web Automation Project

4. Actual Combat of App Automation Project

5. Resume of first-tier manufacturers

6. Test and develop DevOps system

7. Commonly used automated testing tools

Eight, JMeter performance test

9. Summary (little surprise at the end)

Life is like a marathon. To go further, patience and perseverance are indispensable. In the process of struggling all the way, we will encounter setbacks and failures, but as long as we persevere in pursuing our ideals and keep moving forward, we will be able to reap beauty and success. With confidence, enthusiasm and courage, strive to pursue your life goals!

Life is like a practice, accumulating experience, learning and growing every day. Only by overcoming challenges and difficulties can we surpass ourselves and achieve extraordinary achievements. Let us bravely face the challenges, work hard persistently, and create our own brilliant life!

Success is not a result, but a process, a manifestation of firm belief and continuous hard work every day. When difficulties and setbacks come, we need to have a calm and brave heart to bravely meet the challenges of life. Let us create an unyielding quality and a brilliant life on the way of striving hard!