Server stability test method in software testing

Server stability is the most important. If you cannot guarantee the stability of your business, high performance is useless.

Regular server manufacturers will wake up to test the operation stability of products at different temperatures and humidity. It is important to consider redundancy functions, such as data redundancy, Nic honor, power redundancy, Fan redundancy, and so on.

Some testing methods are mainly divided into the following types:

Stress testing:It is known that the number of users in the system's peak periods is used to verify that the transaction response time of each transaction meets the customer's requirements under the maximum number of concurrent transactions (converted by the number of peak periods. Whether the performance indicators of the system are still within the normal value under such pressure. Whether the system will cause adverse reactions due to such stress (such as downtime and application exception suspension ).

Ramp Up Incremental Design:If the number of concurrent users is 75, the number of registered users is 1500, and the value ranges from 5% to 7%. Generally, the pressurization design is carried out by loading 5 persons every 15 s. This value is mainly used to test the performance of the pressurization machine. It is recommended to run it several times. The actual loading mode is measured by transaction pass rate and error rate.

Ramp Up incremental design goals: Find the bottleneck position of the incremental pressurization system and seize the performance inflection point. Generally, we often use the hits CTR and throughput, CPU, and memory usage for Comprehensive Judgment. Number of users during peak hours, such as morning logon, exit after work, and message system at salary sending.

Another extreme simulation method can be regarded as the system extreme operation indicator that clicks transaction operations at the same time under peak pressure. The pressurization method remains unchanged. Set the same set point name (for example, lr_rendzvous ("same") in each script transaction point.) In the scenario design, use the transaction point collection policy. This parameter is based on the number of vusers that are running at the same time.

Stability test:It is known that the number of users in the system peak hours, the frequency of various transaction operations, and so on. Design a comprehensive test scenario. During the test, each scenario runs according to a certain number of people, simulating the user's usage for several years. It also monitors whether the system performance indicators can maintain normal values under such pressure during testing. Whether the Transaction Response time fluctuates or increases as the test time increases. Whether the system will encounter exceptions such as downtime and application suspension during the test period.

According to the above test, the number of concurrent users in the stability test has been determined for the performance inflection point in each transaction condition. Estimate the number of concurrent users based on the actual testing server (performance of three parties: Press, application server, and data server.

Scenario Design Philosophy:

From the design significance of the stability test scenario, we should consider the following situations:

For the same scenario, the following uses the document attachment upload as an example to briefly analyze the Scenario Design Philosophy:

1) scenario 1: concurrent users with performance inflection points in a stress testing environment are designed to test the performance indicators of servers under extreme stress testing.

2) Scenario 2: determine the number of concurrent users based on the CPU, memory, and other indicators in the stress testing environment and select 50% of the maximum stress that the server can withstand.

Test method: 1) Ramp Up-load all vusers simultaneously

2) Duration-run indefinitely

3) In sechedule, select initalize all vusers before run.

Fault tolerance test:By simulating abnormal conditions (such as sudden server power failure, network disconnection, and insufficient disk space ), verify that the system has an automatic processing mechanism to ensure normal operation or recovery of the system in the event of such circumstances. If ha (automatic Disaster Recovery System) exists, additional tests can be conducted for these automatic protection systems. Verify whether it can effectively trigger protection measures.

Troubleshooting test:Based on the original cases or experience, the system verifies and tests the modules that have encountered problems or suspected hidden risks in the system. Verify that these modules have the same performance issue. For example, the memory leakage problem of the upload attachment module, the optimization of the address module, and the impact of enabling Tivoli performance monitoring on the performance of the OA system.

The evaluation test is used to obtain the key performance indicators of the system. The main objective is to obtain performance indicators (such as the transaction response time and the maximum number of concurrent users) in a specific stress scenario by testing the expected test results ).

Evaluate transaction time: A test activity to obtain the response time of a transaction under a specific pressure. Obtain the response time of a transaction under this pressure by simulating the pressure values of known customer peaks or the expected pressure values.

Evaluate the maximum number of concurrent users of a transaction: to obtain the maximum number of concurrent users that a transaction can withstand in a specific system environment. Evaluate the maximum number of concurrent users that a firm can afford by simulating the real environment or directly using the real environment. The standard threshold value must be pre-defined (such as response time, CPU usage, memory usage, click-through rate peak, and throughput peak ).

Maximum number of concurrent users in the evaluation system: The test activity to obtain the maximum number of concurrent users that the entire system can afford. By analyzing the usage ratio and frequency of the main modules of the project in advance, the ratio of each transaction in the integrated scenario is defined, and the number of concurrent users of each transaction is allocated in a ratio manner. Simulate the real environment or directly use the real environment to evaluate the maximum number of concurrent users that the system can afford in this environment. Pre-defined standard threshold values (such as response time, CPU usage, memory usage, click-through rate peak, and throughput peak ). The value standard is based on the barrel rule (the transaction with the smallest number of concurrencies is the number of concurrencies of the entire system ).

Evaluate the impact of different database data volumes on performance: Compare the test results for different database data volumes, and analyze the impact of data volumes on transaction performance. You can determine in advance the potential risks of a system running for a long time, or when some module customers require a large amount of data.

The problem locating test has found performance problems or suspected performance problems in the system through the above tests or the user's actual operations. Reproduce the problem or define the problem in the response test scenario. If possible, you can directly find out the cause of performance problemsCodeOr module.

This type of test mainly tests script scenarios with problems, and adds discovery and detection tools, such as enabling Tivoli performance monitoring, enabling heapdump output, and Linux Resource Monitoring commands. In addition, manual testing is supported during the scenario.