Record one-time test practices

1. Test Object

This time I tested some HTTP interfaces and several webpages.

 

2. Test Strategy

2.1 Benchmark Test: calculate the average response time 100 times in a single call cycle of each interface

2.2 performance test: a single interface call is based on 50 concurrent users, and is gradually pressurized until the estimated actual load is 300 concurrent users. Observe the test index changes.

2.3 stress test: a single interface call is based on 50 concurrent users, and is gradually pressurized until the error rate is too high or the server resource usage is too high. Observe the test indicator changes.

2.4 load test: it is estimated that the actual load is 300 concurrent users. Based on this, the test lasts for about 5 minutes. Check whether the test indicators are up to standard.

2.5 stability test: the actual load is estimated to be 300 concurrent users. On this basis, the test lasts for about 60 minutes. Check whether the test indicators are up to standard, and focus on the error rate.

2.6 fatigue test: the actual load is estimated to be 300 concurrent users. On this basis, the test lasts for about 240 minutes. Check whether the test indicators are up to standard, and focus on the error rate.

2.7 combined test: different interfaces are used for the 2.2-2.5 test at the same time (that is, the test is performed for different modules of the system at the same time)

2.8 others: use different IP addresses for pressurization to test Server Load balancer performance.

Above, only 2.2, 2.3, 2.4, 2.8

 

3. Test Indicators

Test the response time and error rate. At the same time, a dedicated person monitors the usage of server hardware resources and tomcat application servers.

Computing and monitoring throughput (the test tool automatically calculates the throughput during test execution (number of requests processed per second), and the server monitors the server throughput during test execution in the software industry)

 

In this actual test, there is a large gap between the estimated throughput distance, the error rate exceeds expectations, and the test data preparation has certain problems.

 

4. Test Tools

Jmeter is selected this time because it is cheap and flexible.

You must set the language to English. The default Chinese translation is incomplete.

 

5. Writing and debugging test scripts

5.1 recording interfaces and webpages in advance. Assertions must be added for each interface or webpage to be tested. Jquery assertions and regular expression assertions are mostly used for assertions.

5.2 focus on testing data preparation.

5.3 The Local Web application is used to provide data. jmeter obtains the data and sends it to the server. (this time, it is found that the data generated by the local application is repeated during high concurrency, leading to unnecessary error rates)

5.4 test result listener: assertion results, Summary Report, aggregate report, result tree, result table

5.5 when calling an interface, you can use other methods such as web pages and databases to confirm that the interface is successfully called. Check whether the interface call is effective and whether it is as effective as the web page.

6. test execution

6.1 one computer pressurized-concurrent users. If you need more computers, you need to add them.

6.2 pressurize with different IP addresses to test the Server Load balancer effect.

6.3 Data Center Test to eliminate Internet network latency

6.4 data backup and restoration to eliminate data changes caused by performance tests

6.5 Production Environment Testing (the system is not online), excluding the impact of the testing environment

 

7. Test report

7.1 intercept the result of the jmeter listener.

 

8. Optimization

The test results are not satisfactory. The server has powerful hardware and almost no load, but the application itself has Java errors. And found that the interface call results are incorrect, affecting the web page bug.

Test again after development, repair, and optimization.

 

Record one-time test practices