How to move forward the performance testing work at the beginning of the new project?

I just took over a new project recently. At the very beginning, I asked for a performance test on this project, but the product manager couldn’t give me the performance requirements, just because this project is an e-commerce project, and there may be high concurrency and flash kill scenarios, so the product The manager asked us to do a performance test on this project, and because this project is a new project, everyone didn't pay attention to it.

How to move forward the performance testing work at the beginning of the new project?

After a while, when the leader asked how the performance test plan of this project was implemented, everyone was confused and didn't know what to do. Then the test team leader set his sights on me-the only test architect of the entire test team. At this time, I remembered that there are R&D architects, so I found a R&D architect to communicate the performance requirements of this project.

here comes the problem

Because at the beginning, the product manager could not give performance requirements. If you want to give a performance test plan at the beginning of the project, you must have corresponding performance requirements. But now this project has just started, and there are no product documents yet, so the product manager can't give performance requirements. You can only know the general product direction and the general functional modules, so at this time, you can only rely on architects and product managers to communicate together.

How did I solve the problem?

Since it is similar to an e-commerce APP, it is a project with separated front and back ends, so there are many competing products in the market that can be used for analysis, so I hosted a meeting "How to implement performance testing?" Participants: Product manager, project manager, R&D architect, and R&D team leader. However, during the course of this meeting, it was found that everyone was not very willing to discuss performance testing, but was more keen on product requirements and corresponding performance requirements, because without product requirements and performance requirements, there would be no performance testing step.

Here is one more point, in fact, we usually do performance testing in three situations in the project:

1. We need to have a thorough understanding of the current system, that is, the system performance, to see how much concurrency the current system can accommodate.
2. Put forward specific performance requirements, for example, I want to achieve 3000 people doing something at the same time, satisfy 1000 concurrency, and the system response does not exceed 2 seconds... 3. When the system
has performance problems, we need to conduct performance tests and problems Troubleshoot.

Looks like I found a lifeline

Because this is a new project, there will be no performance problems for the time being. The main thing is to have performance requirements before going to performance testing. However, no one can give this performance requirement, neither the product manager nor the project manager. Research and development can't even give it. So at this time, our focus is on discussing performance requirements. During the discussion at the meeting, we found that we are currently evaluating competing products, that is, competing product analysis, and found that competing apps need to meet at least 1000TPS, and the system response should not exceed 2 seconds.

found a new problem

After comprehensively comparing several competing apps, it is found that a certain competing app needs to meet the concurrency capability of 1000TPS in the first version, but how to design the concurrency capability of 1000TPS is another question at this time, and This performance requirement is also obtained through the analysis of competing products. It cannot be regarded as a real performance requirement, but only a temporary pseudo-requirement. At present, the focus of everyone's meeting discussion is how to design a performance architecture that can meet 1000TPS, and then gradually adjust and optimize the requirements when the product is actually launched and used in the future.

The first test version was completed on the basis of a performance architecture that meets 1000TPS, so that performance testers can test the system to see if the system can reach 1000 TPS. The purpose of the entire meeting has been achieved. The remaining focus is how to design an architecture that can meet the current 1000TPS business. Of course, this work is not done by a tester, nor is it done by a simple developer, but by a system architect.

So in the end, this task was handed over to the system architect. Of course, the test architect should also participate in it, but the current system architect can't give a specific architecture plan for a while; because, if a 1000TPS architecture plan is given, It is necessary to be able to design a specific architectural solution before typing the code.

Here comes the difficulty

Before typing the code, you can evaluate and give a set of specific architecture solutions, and evaluate the throughput of the solution, TPS is not less than 1000, this workload can only be done by system architects, after a period of time and system architects communication discovery. This matter can only be designed based on the architect's personal experience, various frameworks, middleware design, database cache, microservice architecture, table structure, load balancing strategy, and how much concurrency each middleware can satisfy.

test forward

These are all based on the personal experience of the architect. After all, the code has not been typed yet, and the code is only started after the entire architecture is designed! When developing and typing code, testers can design and carry out work related to performance testing! After the entire performance test environment is completed, we can actually perform specific performance tests! Then if we say that when the performance environment is settled, the code is almost completed, and the data is almost created, it is too late to start evaluating the performance solution at this time, so it must be done before typing the code. Evaluate the throughput TPS of the system.

Of course, this requires a high level of technical experience for architects. Most people can’t do it well. Only system architects can do it well, and even experienced system architects may not be able to guarantee the solution designed before typing the code. It can meet the performance evaluation at that time, so we still have to wait for the performance test to see the real results.

Practical case

Optical theory is useless, you have to learn to follow along, and you have to do it yourself, so that you can apply what you have learned to practice. At this time, you can learn from some actual combat cases.

If it is helpful to you, please like and collect it to give the author an encouragement. It is also convenient for you to quickly find it next time.

If you don’t understand, please consult the small card below. The blogger also hopes to learn and progress with like-minded testers

At the right age, choose the right position, and try to give full play to your own advantages.

My road of automated test development is inseparable from the plan of each stage along the way, because I like planning and summarizing,

Test and develop video tutorials, study notes and receive portals! ! !

Guess you like

Origin blog.csdn.net/m0_59868866/article/details/132351627