Common Mistakes in Performance Testing

Common Mistakes in performance testing are selected from web performance testing practices

Supporting Performance Testing courses:

1. Get started with LoadRunner performance testing and virtual user development BASICS (click to enter)

2. LoadRunner controller usage BASICS (click to enter)

See the following performance test case:

A new version of a company's OA products will be released soon. To check the system performance, test engineer a is arranged to perform the performance test task. A's practice is as follows:

1. Find a PC with a CPU clock speed of 1 GB and memory of 512 MB ,......;

2. Build a test environment on the PC: Install system software such as Oracle9i and WebLogic;

3. Install loadrunner7.8 on your work machine;

4. Then, the system recorded login and announcement publishing functions;

5. set 30, 50, 100, and 500 concurrent users;

6. Finally, it is concluded that the system can only run about 80 concurrent users .......

Undoubtedly there are many unreasonable aspects in the above practice, such as too few test content and too low configuration of the test server. In practical work, although performance testing is becoming more and more important to software testers, developers and users for its unique position in testing, whether it is testers or developers, there are still misunderstandings in terms of understanding.

Misunderstanding 1: Improve the hardware configuration to Improve the Performance. Therefore, performance testing is not important.

This is what we learned when the system was not large in the past. In the DOS era and in the early days when Windows operating systems became popular, the software scale was generally small, while hardware updates were changing with each passing day. The software performance was generally not a major problem because you only needed to upgrade the hardware, it is easy to solve the performance problem.

Now, with the expansion of software, improving hardware configuration is only a basic means to solve performance problems. If the software has performance problems, more resources may not be enough, such as memory leakage. As time increases, the memory will eventually be exhausted, leading to system crash.

Therefore, if you have high requirements on the performance of the software, this means not only to provide performance from the hardware aspect, but also to improve the performance from the database, Webserver, operating system configuration and other aspects, at the same time, the developed software system must also be optimized to comprehensively improve performance.

Misunderstanding 2: After all other tests are completed, you can test the performance test.

This is a very common phenomenon at present, such as the previous a Jun, which is not aware of the importance of performance testing. The most serious consequence of this approach is that if the performance problem is caused by the software system itself, it may not be able to cure the performance problem. For example, an architecture design error may mean that the software system will be deprecated.

Of course, this does not mean that all performance tests should be carried out as soon as possible, and the start time of performance tests should be determined by the software features. For questions about how to develop performance testing strategies, see "programmer" 2005 and 11 "sub-health of treatment software".

Misunderstanding 3: The performance test is independent of the function test.

Function Testing can detect performance problems, and performance testing can also detect functional problems. Performance testing and functional testing are closely linked, one of the reasons is that many performance problems are caused by functional defects of the software. If the application system is not fully functional or the code execution efficiency is low, some performance problems may occur. Functional testing usually takes place prior to performance testing or synchronization. Software functional improvement can ensure that performance testing is conducted more smoothly.

Misunderstanding 4: Performance testing is a user concurrency test.

When talking about performance testing, many people (especially developers and some project implementers) will think of concurrent user testing and think that performance testing is"Test the concurrency of multiple users". Strictly speaking, Performance Testing focuses on user concurrency testing. The actual performance test also contains many content, such as strength test and big data test.

Misunderstanding 5: Perform a performance test in the development environment.

Most of the time, after the software development is complete, performance tests will be conducted to take a look at the performance of the software. In fact, most development environments cannot reflect too many performance problems due to poor hardware conditions.

Therefore, performance testing should be carried out in a high-configuration user production environment as much as possible. However, there are two exceptions: one is to discover some functional problems, for example, to discover some defects of concurrent algorithms; there are also good hardware resources or laboratories as the development environment.

Misunderstanding 6: The system has a bottleneck and cannot be used.

The system found the bottleneck, which is indeed a worrying thing. But it doesn't matter. Many bottlenecks can be ignored. The main purpose of identifying bottlenecks is to grasp the system features and provide a basis for improving and expanding the system. Therefore, we can leave about 30% of the system's expansion space in terms of performance.

For example, if 1000 concurrent users discover a System Bottleneck and the maximum number of concurrent users is about 500, this performance problem is completely unnecessary, if 550 or 600 concurrent users have performance problems, the system performance should be adjusted seriously.

Misunderstanding 7: Unrealistic performance indicators.

This is mainly due to the lack of understanding of software application requirements. In many cases, especially when users propose many unrealistic performance indicators, such as OA Systems for 500 users, some user owners may propose to meet the performance goal of 100 or even 500 concurrent users, but the actual number of concurrent users will not exceed 50. This problem can be solved only by communicating with users.

All of the above are common mistakes made by relevant personnel in routine performance testing. These ideas are only true under extremely special circumstances. I hope that you can avoid similar situations in your future work after understanding these common Performance Testing errors.