[Original] stress testing-Concepts clarification and how to test

Concept 1 [stress testing] design a distributed application reliability test from Visual Studio. NET: simulates a huge workload to see how an application performs operations during peak usage. Stress testing should be performed on each individual component, and the entire application with all its components and support services should be conducted. Centralized testing starts with the most basic functional testing. You need to know the encoding path and user solution, understand what the user is trying to do, and determine all the ways the user uses your application. The test script should run the application as expected. For example, if your application displays a web page and 99% of customers only search for the site, only 1% of customers will actually purchase the site, this makes it meaningful to provide a test script for stress testing on search and other browsing functions. Of course, the shopping cart should also be tested, but the expected use of the implied search test should take a large proportion in the test.
Concept 2 stress testing comes from. NET application performance testing: stress testing is used to evaluate how the system will run when the maximum load is exceeded. The goal of stress testing is to discover application defects (bugs) under high load conditions ). Including synchronization issues, race conditions, and memory leaks ). Stress Testing allows you to identify program vulnerabilities and how programs run under extreme loads.
Concept 3 stress testing: stress testing is mainly used to detect changes in the performance of a software system under any conditions. By changing the input of an application, you can apply increasing loads (concurrency, cyclic operations, and multiple users) to the application and measure performance changes during these different inputs, that is, the general concept: stress testing examines the maximum load that the system can bear in the current software and hardware environment and helps identify the bottleneck of the system. In fact, this test can also be called a load test, but a load test usually describes a specific type of stress test-increase the number of users to perform a stress test on the application.
There may be more than three definitions of the term stress testing described on the Internet.
I agree with the first concept. stress testing should be to simulate a huge workload to see how an application performs operations during peak usage. Extended, stress testing should be a short period of time, followed by simulating a huge workload, and re-stress testing is to make the use of applications peak. Continuing to supplement these three points, the stress testing for the first point is transformed into a load test; for the second point, the pressure on the application is overloaded, so we need to constantly pressurize the application. The third point is to make the application use peak. If the limit is exceeded, the application will crash or the error rate will surge. This peak is for a certain time point, it is also for a critical stress. The change to Scenario setting means the maximum number of concurrent users that can be supported.
In a recent test, the purpose of the test was defined as: to understand the pressure that Aut (tested applications) typically can withstand, while at the same time being able to withstand user traffic (capacity ), the maximum number of users allowed to access a function at the same time. In the AUT, select the five most frequently used features as the content for this test, including logon. This is probably the requirement.
Next, I will talk about how to use LoadRunner and jmeter to set the scenario for testing. (Note: Server Detection is not the focus of this test. This test mainly collects the number of concurrent users and the number of users with errors)
First, the requirements for the script:
1. Recording the script (note that all the scripts should be recorded in the Action). The custom transaction starts before the script that submits the user name and password;
2. Add a collection point before defining the script for the transaction;
3. Add a checkpoint to the script to display the logon user ID on the logon success page;
4. parameterized Login User identity;
Second, the requirements for scenario settings:
1. because we do not know in advance how many user accesses will be critical, we need to change the number of users multiple times during the test;
2. We recommend that you modify the runtime settings to optimize access to the server;
3. Set the plan to load 10 users after each X time (based on the total number of users). After the plan is fully loaded, it will continue to run for no more than 5 minutes (as needed );
4. Set the policy to release when 100% of the number of running users reaches the set point;
5. Notes: 1) Server Response timeout; 2) time used for Logon transaction iteration; 3) Time-out period for collection point; 4) the interval set in the plan. In my test, the transaction runs for no more than 30 seconds. By modifying the script, it runs for about one minute, the server response timeout time, combined point wait timeout time, and scheduled interval are set to 2 minutes.
In this way, the number of running users increases progressively after the scenario starts to run. In addition, new users at each rising point will access the server concurrently with the running users.
By running multiple times and comparing the number of running users in the test results with the number of wrong users, you can get the maximum number of concurrent users of this function based on the acceptable error rate defined.
In the above test, the requirements for networks and clients are exclusive. In actual tests, we must first ensure that these resources are sufficient.
Jmeter can also be used to test the scenario described above and is more convenient.
Contact me MSN: wyingquan at Hotmail dot com