Three major models of performance testing knowledge

That is, the three major models are business model, traffic model and data model.

How to evaluate and build.

Inperformance testing work, business model, traffic model and data model are crucial and must be built in the project, otherwise It is likely that there will be a big gap between the test scenario and the actual situation, and the test results will not provide sufficiently convincing support for performance analysis and optimization.

In order to make it easier for everyone to understand the three major models, I will take the scenario of placing an order in an e-commerce business as an example, as shown below:

business model

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

  1. Whether the product inventory is sufficient;
  2. Whether the ordered products can participate in marketing activities;
  3. Whether the user placing the order is a VIP member and there is a member discount;
  4. Whether the user who placed the order has a coupon, and whether the coupon meets the preferential conditions of this order;
  5. ............

 

In fact, there is no difference between the business model and the business scenario analysis during functional testing. They are all designed to analyze 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 the traffic entrance and risk control of the online business may also need to be considered.

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

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

traffic model

We all know that when performance testing is performed and stress testing is performed, it is based on an interface or a certain URL. 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 are performance bottlenecks.

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

Taking the above picture as an example, some users used coupons when placing orders, some users are not VIP members and cannot enjoy discounts, and some products have 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 real proportions according to different business scenarios, which is also called business ratio.

You can also understand the flow model as a pressure testing model. Common pressure testing models in work include the following:

Single machine single interface benchmark test

The most common benchmark test is to perform stress testing on login scenarios.

For stress testing of a single machine and a single interface, you can use gradient increments to observe changes in performance & resource consumption as requests increase.

Single machine hybrid link capacity test

Taking the above figure as an example, the order service includes interfaces such as creating orders, canceling orders, order lists, order details, etc.

The request size and request content of each interface are different. In stand-alone hybrid scenarios, most of the time, service-level performance is observed through gradient increase of requests, with the purpose of troubleshooting bottlenecks in upstream and downstream call dependencies.

Full-link stress testing scenario in production environment

For full-link stress testing of production clusters, a common case is the Double 11 e-commerce promotion. There are many full-link stress testing models, generally including the following:

  • Gradient pressurization: In order to detect the maximum throughput of the system in cluster mode (to avoid overwhelming the service and causing accidents);
  • Fixed concurrency: Verify the stability of the system under long-term load;
  • Pulse concurrency: detect the robustness of the system and verify the correctness & availability of service protection measures such as current limiting and fuses;
  • Oversold verification: For e-commerce businesses, it is mainly aimed at some limited-time rush & flash sale scenarios (generally, this scenario will involve technical points such as distributed locks, caching, and data consistency; if not done well, it is easy to cause Customer complaints, capital losses, or even abnormal service downtime!);

Build traffic model

The following is a case of traffic model construction during a Double 11 promotion in my actual work, for reference only.

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

Technical indicators:

  1. Assume that the daily payment order volume is 50W, the payment conversion rate is 40%, and the peak order payment QPS is 200. It is estimated that the payment conversion rate during the big promotion is 60%, then we can get: the peak order payment QPS for the big promotion is (200/40%) * 60% * (200W/50W) = 1200QPS. In order to leave some redundancy space, the increase is 30%, that is, the QPS for order payment is estimated to be 1,500;
  2. The order payment link of the e-commerce shopping guide is: home page → product details → create order → order payment → payment successful. This is a conversion logic similar to a funnel. Assume that the conversion rate of home page → product details is 40%, the conversion rate of product details → create order is 40%, and the conversion rate of create order → order payment is 40%, then we can get: Create order QPS is 1500/40%=3750, product details QPS is 3750/40%=9375, QPS on the homepage is 9375/40%=23437;
  3. According to the dependency call relationship between 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 calling relationship between services. This will be more intuitive and facilitate work.

data model

After understanding the business model and traffic model, the data model is easy to understand.

Taking the above figure as an example, when building a data model for e-commerce ordering business, different types of data must be prepared based on the stress test duration, number of stress tests, and stress test scenarios.

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

If the data used in the testing process is inaccurate, the test results will often deviate greatly. Regarding the construction of test data model, please refer to the following points:

Data information

illustrate

limitation factor

User operation permissions, data reference times, data expiration settings (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 performance test environment?

type of data

Basic data, hotspot data, cached data, special data

Data characteristics

Whether it can be reused, whether it is unique, auto-increment, encryption, splicing, escaping, etc.

preparation method

Copy real environment data, pre-embedded background data, and desensitized generated data

 

Basic data

Also known as base data, the purpose of base data is to be consistent with online (at least the quantity distribution is consistent), and combined with the online growth rate, confirm the magnitude and method of 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

You need to understand the implementation logic of the interface under test and confirm the following information:

  • Are there operations related to hot data: for example, all users can instantly sell the same product;
  • When the processing logic of different types of data is different, it is necessary to improve the performance test code coverage through test data diversification;

cache data

To confirm whether there is a cache, cache size.

Flash sale-related data is generally processed in a queue, and this type of data is placed in 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 constructed data can be preheated to the cache in advance to avoid user services becoming a bottleneck during stress testing.

Build data model

The most intuitive purpose of building a data model is to parameterize test data during stress testing. The general construction steps are as follows:

  1. Build business models;
  2. Build a traffic model (stress testing model);
  3. List the test data and corresponding relationships required by the business and traffic models;
  4. Take the prepared parameterized data out of the database to generate corresponding different parameterized data files;
  5. Set the corresponding data matching relationship in the stress test script to ensure that the business model, traffic model and data model match, and simulate real production scenarios;

Thank you to everyone who reads my article carefully. There is always a courtesy. Although it is not a very valuable thing, if you can use it, you can take it directly:


 

These materials should be the most comprehensive and complete preparation warehouse for [software testing] friends, and this warehouse also accompanies Thousands of test engineers have gone through the most difficult journey, and I hope it can help you!Friends in need can click on the small card below to receive it 

おすすめ

転載: blog.csdn.net/kk_lzvvkpj/article/details/134886077