The introduction

With the development of Internet technology and the popularity of computers, all walks of life in the society have entered the digital era. But with that comes a growing number of users and a growing amount of data. From the first tens of thousands, hundreds of thousands. Until now, all kinds of second kill activities, opening activities and other e-commerce promotional activities have brought hundreds of millions of levels of pressure, which is a huge challenge for the current system. The performance test is to simulate these real business scenarios, test the load capacity of the system, locate the corresponding problems and provide corresponding solutions, and finally make the system meet the actual business scenarios.

Let me share my understanding of the performance testing process and what to look out for.

1. Access to performance test interface documents

1. System architecture design documents (system infrastructure diagram, business architecture diagram, data flow diagram)

2. Non-functional requirements document (performance test metrics such as PV, number of users, TPS, concurrency, response time, system peak CPU, memory consumption…… Etc.)

3. Resource action resolution table (apply for pressure test environment, including hardware configuration and quantity information)

4. Test Scenario (Core business)

Two, prepare the system environment:

1. Production environment

  • In the production environment, the measurement accuracy is higher, but the test data such as logs generated during the test must be deleted. At the same time, the integrity of data deletion must be ensured. The construction of basic data refers to the subsequent data volume.

During the pressure measurement in the production environment, try to select the low peak period to avoid the impact on the production business

2. Test environment

  • The risk is controllable, but the environment construction is more complex, and the cost of scale and production is the highest. The ideal ratio is test: production = 1:2 or test: production 1:4.

(The ratio here is the total number of architectures or hardware configurations, but the infrastructure cannot be changed)

  • However, when the actual conditions are not met, independent deployment test cluster and database sharing can also be used in the production part for testing. If the pressure test environment is set up, basic data needs to be imported from production desensitization after the environment is set up. Generally, the stock data is three years, at least 5W pieces of data should be prepared for test case data query transactions, each piece of data should not be repeated, and three years of business volume should be prepared for NAS storage data

(If the archiving time is less than three years, the archiving time is required.)

Test plan

  • Keep the test plan as brief as possible and identify who is responsible for each task. Divide tasks in a clear manner according to the entire performance test process.

In general, a project with continuous iteration takes one week as the project cycle, with one week as the end time, moving forward. The duration of a new project is generally two to three weeks, depending on the time.

Iv. Test plan

  • Through the information obtained in the early interface document, prepare the test plan, including the background, purpose, indicators, test scope, system architecture of the test… And so on.

When testing the scheme, not simple registration information is finished, but also need to understand the overall architecture of the system, core business processes and so on. Only in this way can you be comfortable and fearless in the face of possible performance problems or other problems.

5. Test execution

1. Test scripts

  • There are two kinds of tests. One is to record scripts, which are mainly for business systems. The other is interface scripting, which is written according to the interface documentation provided by the developer.

Part of the script has nothing to say, and active communication with r & D, the script is finished.

2. Perform the scenario

  • Scenarios are classified into baseline, single, mixed, extreme, and stability scenarios.

When executing, the business side focuses on three points: transaction success rate, TPS, and response time. In the system, pay attention to the following points: CPU consumption, memory consumption, network I/O, disk I/O, and Swap If an indicator fails to meet the requirements, the system traces the link from front to back. For example: F5>Nginx cluster >F5> Microservice cluster >Redis>Mysql check whether F5 performance bottleneck, and then check Nginx configuration… Wait, go through every level, make sure there’s nothing missing.

Test report

  • After the completion of the test, according to the test results, sort out the corresponding test report.

Test scope, test metrics, actual metrics, resource consumption, performance bottlenecks, tuning records, and more.