What is the performance test plan?

 

In the previous chapter, we analyzed the performance requirements, learned the test objects, and understood the test requirements. Then, we need to prepare a detailed plan, to plan and guide performance testing. To make your performance test plan clearer, we will describe it in the test plan format.

 

I. Introduction

 

The introduction section does not need to be described too much. It is nothing more than the background of the project, the reason for the performance test, and the scope of the performance test, almost all project documents are beginning to briefly describe the project.

 

Ii. Performance Testing Requirements

 

Tested objects and pressure points

The objects to be tested are obtained through analysis and system data collection instead of just being imagined. Take down several typical pressure points

Login: For general systems, logon is a prerequisite for the user's operating system. If the user cannot log on, other functions will be useless. For example, in online games, when a new server is opened, the player breaks his head and only logs on.

Query: Queries consume system and database resources. The search engine's query function is typical. If you enter the content in the input box, you will not get the result for a long time. I think a search engine called "Internet portal" will not exist.

Transaction: For some e-commerce systems, the transaction process performance requirements are very high, if the transaction process consumes users for a long time. I 'd rather go to the supermarket to buy things. Of course, in addition to the transaction speed, the transaction success rate is also very high. Otherwise, the loss is immeasurable.

The tested system should be the most important and basic function and the most frequently used function.

 

General performance requirements include:

System capacity: The maximum number of user registrations allowed by the system.

Number of shards: Number of users simultaneously accessing the system.

Concurrency: The number of concurrent operations at the same time. A system should have a combination of concurrent operations (generally, users with the permission to perform operations ).

Maximum number of users and optimal number of users: The maximum number of concurrent users allowed by the system, and the number of concurrent users allowed by the system in the optimal state.

Response time: The time interval from when the user submits an operation to get a response.

Throughput: TPS processed by the system per second

Stress is a key factor in performance testing. performance is the performance under the maximum pressure that the system design meets. The number of concurrent threads should not be less than the peak value of the system's normal operation, and the total data volume should not be less than the data volume of the system's normal operation for three months.

When describing the number of concurrent users, there is always a corresponding time limit. In essence, the system performance indicators should use the number of requests processed by the system per unit time and the description of the request response time. The number of requests that can be processed per unit of time is the system's service throughput. You can use the following formula to convert the number of virtual concurrent users: (actual number of users × number of real user requests)/(total Request Response Time + total real user thinking time) = (number of virtual users × number of requests per user)/(total Request Response Time + Total virtual user thinking time) = throughput.

 

Iii. Test Environment

 

The test environment mainly refers to the software and hardware environment and network environment.

I believe that performance testing should be conducted in an independent environment without external interference. This ensures that the testing data is independent and effective. If you perform stress tests on a website that has been launched, the data you get is not independent because other retail investors are also visiting the system during stress tests.

Software environment:

The software environment here mainly refers to the project running environment, such as the operating system, middleware, and database used.

Hardware environment:

The hardware environment includes not only the internal components of the host,CPU, Memory, disk, motherboard, network card, etc., transmission medium and router should also be taken into account,

Network Environment:

In addition to testing machines and system servers in a LAN, the network environment should ensure the independence of the network. If other machines consume vro resources during performance testing. The router will also affect the transmission speed of the database.

 

 

4. Data Preparation

 

In many cases, we need to prepare test data. For example, if the system does not allow repeated logins of the same user, legal user data must be generated. Sometimes you need to query and test the system. Only when there is a certain amount of data in the system can you verify the real performance of the system. A database contains two pieces of data and 20 million pieces of data. The same query operation has completely different pressure on the system.

You can use the following methods to analyze the data required by the system:

Historical data analysis helps you determine the data magnitude. Start with historical data to find out the peak data volume.

Start with other similar or identical systems and analyze the data to find out the peak data volume.

When there is no history or the relevant system can be referenced, it is necessary to estimate the system performance data, including the system capacity, concurrency and other data. After the estimation, it will be reviewed or revised by the relevant personnel, tests are conducted based on the agreed performance indicators.

............

The test data should be the same as the actual data. If we can obtain data from the real system for three months, we can perform performance tests on this basis.

We can wish you a tool to complete data generation, such as a database data generation tool and a file generation tool.

 

5. Test Tools

 

We have discussed how to analyze the requirements. After the requirements are determined, we can consider what tools are introduced to suit the performance requirements.

Of course, when introducing a tool, you should consider the cost of the tool in addition to whether the tool can meet the requirements. This does not only mean the cost of purchasing the tool, but also the cost of learning the tool by testers.

The selection of test tools will be described in a separate chapter later.

If the performance testing tool you choose is not powerful enough, you may need other auxiliary tools. IfJmeterExploitationBadboyRecording scripts to improve the efficiency of script development. Performance counters may also be required to record the performance of software and hardware during stress testing. For example, monitoring serverCPUMemory counters, monitoring tools for recording middleware logs, and monitoring tools for monitoring database performance.

 

6. Test Strategy

 

For a specific business system, users generally access the system in different periods of the day. In different time periods, the frequency of using the business system varies, while the system is busy to varying degrees. Under certain conditions, users may access a Business System in a short period of time. For example, for the document processing subsystem, a large number of users may view and process a document in a short period of time. The "worst case considerations" principle should be used for performance testing ". That is to say, the user should test the functions of the system when the user uses the business system most frequently and puts the maximum pressure on the system, and determine whether the functions and pages can meet the performance requirements, whether the system response time is too long.

On the other hand, the verification of system performance must be "comprehensive coverage ". Although the usage frequency of various functions in the system is not the same, the usage frequency of some functions is relatively low than that of other functions, but these functions cannot be ignored during performance testing and optimization, you cannot select the most common functions when preparing test cases. For example, all users may access my notification list. However, only 5% of users use the system settings module to find information about a user. However, during testing, we cannot ignore the test of this function because the user information function is used less frequently. Therefore, during the system performance test, the user access ratio should be reasonably allocated for different services.

In terms of testing strategies, we should also consider the performance of the same system in different hardware environments. In this way, the hardware configuration can reach the optimal state when the system meets the requirements. It is also a waste of increasing hardware to meet your needs. Besides, adding hardware does not solve all performance problems.

 

 

VII. manpower and schedule

 

The last article is to arrange manpower and time according to the project progress and scale. For large-scale performance testing, pre-project demand research, Environment deployment, tool purchase or development, personnel's learning and use of testing tools, and performance testing, analyze and optimize later data. Personnel are required. If necessary, professional System Engineers, database engineers, software development engineers, network engineers, and performance testing engineers are involved. Not a single performance tester can do it all.

I have heard that the bestXPerformance testing requires the performance testing teams of more than a dozen cities in several countries to synchronize time. It takes several months to prepare for the preliminary work. How to synchronize performance control tests. Summarize and analyze the subsequent test data. Is a very complex process. This example remains to be verified. I would like to explain that for performance testing of large projects, personnel and schedule are also crucial.

 

----------------------

According to different projects, we should consider not only the above content, but also the content listed in this section is the basic consideration.