Author: Zi Jin

Review & proofread: Fengyun, Yufu

Editing & Typesetting: Wen Yan

Customer stories

Full-link pressure test is known as the “nuclear weapon” to greatly promote the preparation for war. If you have paid attention to the technical summary related to Alibaba Double 11 before, you will be familiar with “full-link pressure test”, and the appearance rate of this word is almost 100%. From the stability value of double 11, it is not unreasonable to use “nuclear weapons” to describe the full-link pressure measurement.

In a well-known e-commerce promotion, the e-commerce platform also wants to use the full link pressure test to eliminate risks in advance for their own promotion. But he ran into several difficulties:

  1. Full-link pressure testing is an activity that requires the participation of multiple actors: business side, testing, operation and maintenance, R&D, and database. However, it takes a long time to accumulate a mature organizational system like Ali, which can powerfully promote various roles.

  2. Full-link pressure measurement often involves the transformation of the framework: however, the business of the e-commerce platform is complex, so it is not realistic to comb out the structure and transform the business.

So this well-known e-commerce platform, what can be done within a week, without business transformation, without changing business deployment, can use the full link pressure test?

In the following content, we will start with the principle of full link pressure measurement, and introduce the “Agile version” full link pressure measurement based on the same principle, so that the well-known e-commerce platform can use the full link pressure solution in 2 weeks.

Full-link pressure measurement

First of all, let’s take a look at ali’s full-link pressure measurement, what problem it solves:

In fact, the problem solved by the full link pressure measurement is: on-line pressure measurement. On-line pressure measurement, the fastest and most direct detection of on-line problems. However, there is a problem of data contamination with on-line pressure measurement: how to distinguish the pressure data from the real data is a crucial point in pressure measurement. So what did Ali do? Let’s take a look at the picture below:

Ali’s full-link manometer has a mature and complex system: manometer combing, construction, preparation and delivery. However, this system needs to be built over a long period of time for a cloud user. So how do we get users to enjoy this technology quickly and quickly?

Here, PTS precipitates the entire process to provide standardized output to users on the cloud. Users can directly enjoy a complete set of full-link pressure measurement system, and can also customize the pressure measurement effect according to their own needs in the key steps of pressure measurement, such as scene combing, request construction, pressure measurement environment, pressure measurement and so on.

Scene comb

Service scenario, that is, the input request of the pressure test. This is the first and most important step of the manometry. The most common is to sort out and summarize the URLS related to the business. For example, here is a summary of common scenarios:

However, this is not enough. When several urls are summarized into a scenario, the ratio and time interval between urls also affect the business scenario. Take a common scenario as an example: a user’s order may contain 10 users’ login, each user browses 4 products on average, each product is browsed 5 reviews on average, and the last user buys a product at 10 o ‘clock when the promotion starts.

The relationships and time points between these urls require personnel with rich business knowledge to sort out clearly. To this end, PTS provides the service side traffic recording function so that users can easily record traffic and obtain the ratio of different dimensions:

As shown in the figure above, users can clearly get the proportion relationship between urls, the time behavior between user urls, and so on. Based on this combed out data model, users can tailor on this basis.

Test data construction

Next, it’s time to construct user data. This step involves the most roles and is the most tedious. The entire data construction consists of three steps, as shown below:

The first is data discovery. Typically, all tables involved in the business can be obtained and analyzed by human business combing. PTS eliminates this worry by connecting with DMS to provide table structure preview, which allows testers to easily see the structure associated with the scene, greatly improving efficiency.

If it is still too complicated, PTS will provide data recording tools. After installing the Agent, all tables involved in the service will be recorded completely:

With these tools, testers can easily obtain table information associated with a scenario without the assistance of a DBA.

Data closure

With these tables and data closures analyzed on top of them, we can start making pressure data. In general, there are three ways to make a shadow table:

  1. Shadow library – Full shadow library mapping. The advantage of this method is simple, but the disadvantage is that it consumes more resources.

  2. Shadow table – Associates the names of tables in table closures with certain rules. The advantage of this method is to save resources, but the disadvantage is that the tables need to be fully combed and corresponded.

  3. Instead of creating a new table, the shadow data is greatly offset in the same table. This will be covered in a later Agile edition.

These three methods can be combined as required.

Data import/scrambling

With these prerequisites in mind, we can use DMS for data import and data production.

Here, we have completed the two most complex steps in the whole link pressure survey: pressure scene sorting, pressure survey data production.

Next, we processed these two elements into pressure measurement data through data processing.

The data processing

At this point, we do the last step on the pressure survey data, data processing. That is, we make the final adjustment and processing of business scenarios and pressure measurement data according to our business model:

At this point, we can see that the manometry requests for the full link manometry have been formed. Next, we can begin to design the behavior of the pressure flow in the pressure object.

The test environment

Pressure measurement can be carried out in simulation environment, on-line environment. Different circumstances, data selection, data production have different considerations. As shown below:

Simply put, the test environment focuses on individual components: microservices, interfaces, protocols (SQL, Redis), etc.; Pre-delivery environments (usually VPC environments) focus on link integration. The production environment is the closest to the real world. Here, we are only talking about the online production environment.

Traditional full-link pressure measurement

The following figure simply explains the operation mode of traditional full-link pressure measurement;

As we can see, traditional full-link pressure measurement mainly distinguishes pressure flow from real flow through flow marking. To achieve this, it is necessary to ensure that the pressure gauge can be transmitted through layers. When the traffic reaches the layer of “write”, the deployed agent decides the behavior of “write” according to the pressure gauge. Is it to write to the real database? Or should I write the shadow region? The principle is very simple, but the implementation of the time will still encounter many difficulties. Among them, the main issues involved are:

  1. If the framework used by the application is not standard, it needs to be adapted.

  2. The process of promoting agent development and installation is complex.

  3. The coverage of verifying agent is complex.

Agile version of the full link pressure measurement

If we don’t want to transform the business, and we don’t want to mount agents, how can we do that?

Let’s look at how sampling works. In the test, there is usually a means, that is, by selecting a few specific real user data to test, to verify the correctness of the program; If we change the real user data into fake users, the following key conditions must be met: Fake users and the service data and related data of fake users in this business scenario can be identified.

For example, we simulate a fake user to buy a fake commodity. The user and commodity here can have a specific feature. The browsing record and purchase record generated by this fake user have the user’S ID in the performance of the database. Under this premise, we can distinguish dirty data from real data;

This pressure measurement, need to check out the following two points:

  1. Find out the complete data table involved in the business – refer to the PTS SQL recording feature in the previous chapter;

  2. Making shadow data – Unlike traditional full-link manometry, we chose the third method, which is to make a large shift in a table, instead of making a shadow table or shadow library. After the pressure test, the database was inspected and cleaned according to the characteristics of shadow data.

This method is based on the user has a clear understanding of the business, the produced pressure test data has obvious pressure label (much larger than the normal data offset), all involved in the write pressure test, with these offsets; In this way, all the data from the pressure survey can be identified. After the pressure test, according to the data characteristics, to clean the pressure test data;

Traffic engine selection

In order to better simulate the user’s behavior, we often use custom pressure survey area. But it is not practical to deploy pressure engines all over the country; PTS can easily allow users to select the region to initiate, as shown in the following figure:

conclusion

PTS, combined with more than 10 years of Ali full-link pressure testing experience, enables Ali Cloud users to enjoy a full set of standard full-link pressure testing as if they were enjoying a full Chinese banquet, or choose the most suitable method according to their own needs.

In addition, PTS has recently made “agile” pricing optimizations. For more options, click here