Detailed explanation of what indicators are required for performance testing?

1.1 New online projects

1. Indicators are goal-oriented

1) Capacity verification - the maximum processing capacity of the system under certain software and hardware conditions, providing capacity models/estimates for operation and maintenance

2) Stability verification

3) Have specific expected indicators (1 to 3 years of future planning)

Note: Baseline performance needs to be controlled in advance (focus on response time under no pressure conditions)

2. Business model

1) Refer to historical projects or other projects in the same industry

2) Comprehensive evaluation of business products

Note: After the system goes online, it can be observed for a period of time and tested according to a relatively standard business model.

At the same time, I have also prepared a software testing video tutorial for everyone (including interviews, interfaces, automation, performance testing, etc.), which is below. If you need it, you can watch it directly, or you can directly click on the small card at the end of the article to get the information document for free.

Where to watch software testing video tutorials:

Byte boss teaches you how to master automated testing (interface automation/APP automation/Web automation/performance testing) within 15 days, including practical project practice

1.2 Online system

1.Acquisition method based on historical data analysis    

1) Please ask operation and maintenance students to help check;

2) Obtain through existing monitoring platforms and other channels

2. Version iteration (according to original expectations)

1.3 Performance requirement indicators

1.3.1 TPS conversion method:

1. The commonly used 80/20 principle (80% of transactions are completed within 20% of the time);

2. Based on the number of concurrent users: TPS = number of concurrent users/response time - not particularly recommended, and there is no particularly correct reasoning, because the number of concurrent users itself is a controversial point

1.3.2 Response time definition method:

1. Baseline 200ms, load 1s (the interface involved needs to be ≤1s/3s when TPS indicators are met)
Industry definition: 1357 principle, 1s is excellent, 3s is good, 5s is pass, and 7s is unqualified. As users have higher and higher requirements for "fastness", general requests that exceed 3 seconds cannot be accepted.

2. Attached is a response time process chart

1.3.3 User number conversion method - not recommended
 

  • Concurrent users: the total number of users who make requests to the service at the same time
  • Online users: all users who are accessing the system (not necessarily performing operations)
  • System users: The rated number of users in the system or the number of registered users

The concept of the number of concurrent users is often vague. The so-called official reasoning or experience is not very accurate. This has a lot to do with the properties of the system itself. The following conversion methods are for reference only.

1. Number of people online: Calculation of the peak number of concurrent users C^=C+3*root C

1) The average number of concurrent users is C = nL/T

2) Peak number of concurrent users C' = C + 3*root C

C is the average number of concurrent users, C' is the peak number of concurrent users, n is the number of login sessions, L is the average length of login sessions, and T is the length of time for value examination.

2. Calculate according to TPS: the formula is C = (Think time + 1)*TPS

Number of concurrent users = TPS * response time

3. The 80/20 principle: (total number of users/statistical time)*impact factor (generally 3) to estimate concurrency.

For example, take the subway as an example. There are 50,000 passengers every day. The morning peak is from 7 to 9 o'clock every day, and the evening peak is from 6 to 7 o'clock. According to the 8/2 principle, 80% of passengers will take the subway during the peak period. Then the number of people arriving at the subway ticket gate per second is 50000*80%/(3*60*60)=3.7, about 4 people/S. Taking into account factors such as security checks and entrance closures, the actual number of people accumulated at the ticket gate must be larger than this It needs to be larger. Assuming that it takes 3 seconds for each person to enter the station, the actual concurrency should be 4 people/s*3s=12. Of course, the impact factor can be increased according to the actual situation!

4. Calculated based on the number of system users:

Number of concurrent users = 5% to 12% of the maximum number of online users in the system

Summarize

PS: Here is a collection of self-study tutorials for software testing. It should be helpful to friends who are developing in the testing industry. If you need it, you can dd me. In addition to basic introductory resources, bloggers also collect a lot of advanced automation resources. From theory to practice, only by integrating knowledge and action can you truly master it. The full set of content has been packaged on the network disk, and the total content is close to 500 G.

☑ 240 episodes - a complete set of video courses from zero to mastery
☑ [Courseware + Source Code] - complete supporting tutorials
☑ 18 sets - source code of practical testing projects
☑ 37 sets - testing tool software package
☑ 268 - real interview questions
☑ 200 templates - Interview resume template, test plan template, software test report template, test analysis template, test plan template, performance test report, performance test report, performance test script case template (complete information)

These materials should be the most comprehensive and complete preparation warehouse for friends who do [software testing]. This warehouse has also accompanied me through the most difficult journey. I hope it can also help you! Everything must be done early, especially in the technical industry, where technical skills must be improved.

Guess you like

Origin blog.csdn.net/huace3852/article/details/132879911