The most detailed in the whole network, performance test scene model analysis, performance test from 0 to 1...

---

foreword

For performance testing, requirements analysis is the most important thing—if the analysis is not in place, the scene will not conform to the reality, and the work will be useless;
tools + monitoring do not have much learning cost;
the real performance requirements are the key factors that affect the final test results;

I believe that many students who do performance testing have encountered the following problems:
the requirements are not clear, and sometimes there are even pseudo-requirements such as "we have an XXX interface, please press it for me";

Unclear requirements make it impossible to conduct a detailed and complete analysis of test points & test scenarios. The final test results are far from the actual required results, and cannot provide accurate reference for bottleneck positioning and online capacity planning;

There is no positive and effective feedback mechanism for the work results, and if something goes wrong, you even need to take the blame for such a painful thing;
…

Of course, in actual work, there will be many other problems. The important thing is: how do we analyze the reasons behind the problem, and then find a way to solve the problem!

Regarding scene modeling, we mainly start from the following three aspects:

Business scene

In the requirements stage before the test starts, we must sort out the research clearly. What is the scope and purpose of our test?

For example, some e-commerce projects are mainly social e-commerce + identification, risk control business necessary for social networking, logistics and warehousing business inherent in e-commerce, basic news and push services, and promotional activities necessary for Double Eleven. During the Double Eleven promotion period, these are the core business links.

In terms of transaction business, the transaction business link will include the following core business links:

Among them, the homepage may include the screen opening page, login homepage, promotion page, personal homepage, etc.; products may include product details, product lists, product collections, etc.; and orders, shopping carts, payments, searches, etc. are strongly dependent on transactions. business.

According to the subdivided business functions contained in different business links, and combined with the type of system architecture (microservices may be highly cohesive and decoupled according to business attributes), the priority and importance of different functions are divided.

In this way, we can get a relatively clear business scenario in the requirements stage, and then start the next step.

link scene

After completing the confirmation of the test scope and sorting out the business scenarios, the next step is to split from requirements → test points (for this point, the initial idea is to merge with the stress test scenario, but think carefully, as an independent scene is better).

In the link scene construction process, the most important thing is to consider the following three points:

1. Task dismantling
Task dismantling is the same as the literal meaning. According to the sorted out business scenarios, different operation processes are divided from the user's point of view, and then the task list of different business links is sorted out;

2. Task scheduling
According to the split business link, analyze and sort out its prerequisites (environment preparation, service joint debugging), cross-departmental cooperation (operation launch, channel drainage), resource investment (development, operation and maintenance, testing) , Delivery output (version, API documentation, log service, monitoring).

Then, according to the time node, estimate the construction period and reverse it. The working hours are estimated to be days/persons, which can fluctuate by about half a day, but the delivery time and plan must be clarified (such as the backup plan for each team delivering too late or insufficient resources) .

3. Weight division
You see, according to the above gameplay, there must be a lot of things sorted out. But in many cases, the delivery of output will always be delayed, the resource input will always be less, and there is basically no plan.

For this kind of problem, as a performance test, how to do it? The answer has already been mentioned above, divide the weight and priority, and within the scope of limited time and resource investment, give priority to ensuring the test coverage of the core and important links!

After all, there are many bottom-line solutions, such as traffic limit, service downgrade or even circuit breaker (these methods are all lossy, but in order to ensure that the service will not hang up at that time, these are acceptable).

PS: Some details are limited to confidentiality and security rules, so I can’t introduce them in detail, but grasp the key points and practice according to the ideas introduced above, and there will always be a method suitable for your team.

Pressure test scenario

Previously, we confirmed the test scope, business scenarios, and business links, divided the priorities and weights, and made some plans and task scheduling. However, the test plan and specific test scenarios will be implemented in the end.

For example, for different business scenarios, what testing strategies should we adopt, how to test, when to start, expected results and acceptance criteria, etc.

Here, I suggest that before outputting the final test plan, draw a mind map and quickly review it with development, operation and maintenance, and even architecture children's shoes, first reach a consensus on the general direction, and then enter the test plan to perform stress testing.

You can refer to the following stress test ideas to design specific test scenarios:

For specific practices, it is recommended to implement them in a targeted manner according to the characteristics of their respective teams.

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)

There is no dress rehearsal in life, every experience is a performance of carpe gratification. Devote yourself to the pursuit of your ideals and goals, and keep working hard, and you will gain more success and happiness.

Don't let your life be arranged, go explore the bigger world. Manage every day with your heart, actively face every challenge, and bravely climb the peak, you will become the most dazzling existence.

In your firm belief and unremitting efforts, every small progress is a harvest. Don't give up, don't stop, don't forget why you started. Success belongs to those who never say never.