One of the concept [Pressure Test] From Visual Studio .NET design Distributed Application Reliability Test: refers to how to simulate huge workloads to see how the application performs operations in the case of peak usage. After the pressure test is performed for each individual component, the entire application with all the components and support services should be stressed. Centralized test begins with the most basic functional test. You need to know the coded path and user program, understand what the user tries to do and determine the user to use your application. The test script should run the application based on the expected usage. For example, if your application displays a web page, and 99% of customers just search the site, only 1% of customers will truly purchase, which makes the test script that provides pressure testing for search and other browsing features. Of course, it is also possible to test the shopping cart, but the expected use hints that the search test should account for a significant weight in the test. Conceptual II [Pressure Test] From .NET Application Performance Test: Pressure Test Use how the system will run in the case where the maximum load is surpassed. The goal of the pressure test is to discover the defects of the application under high load conditions (BUG). Includes: Synchronization Issues, RACE CONDitions, And Memory Leaks (Memory Leak). Pressure test allows you to identify the weaknesses of the program and how to run under the limit load. Three [Pressure Test] The pressure test is mainly to find changes in the performance of the software system under one (arbitrary). By changing the application's input to apply a growing load (concurrent, loop operation, multi-user) and measure changes in these different inputs, it is usually the concept: the pressure test is currently The maximum load that can be affected by the system in the hardware environment and helps to find the system bottleneck. In fact, this test can also be referred to as load testing, but load tests typically describe a particular type of pressure test - increasing the number of users to perform pressure testing applications. There may be more than the above three of the above-described three definitions. I compare the first concept, and the pressure test should refer to how to simulate huge workloads to see how the application performs operations in the case of peak usage. Extended, its pressure test should be shorter, followed by simulating huge workloads, and the pressure test is to achieve the use of the application. Continue to these three points, transition to load testing for the first point for a long time; for the second point, the pressure applied to the application is overload, so it is constantly pressurized; Make the application of the application to the peak, if the application crashes or the application crashes or the error rate, this peak is for a certain moment, but also for a critical pressure, transition into scene settings The statement is the maximum number of concurrent users that can support. The purpose of the test is defined in the most recent test is to understand the pressure that the AUT (measured application) is generally able to bear, and can withstand the user access (capacity), which supports how many users can access a function at the same time. Select the five functions of the user as the content of this test as the content of this test, including login. The probably demand is like this. Next, my AUT login said how to use loadrunner and jmeter to achieve the purpose of the scene to achieve the test.
(Note: The detection of the server is not the focus of this test. This test mainly collects the number of concurrent access users and the number of error users.) First is the requirements for scripts: 1. Recording scripts (note all scripts should be recorded to Action Middle), custom transaction, transaction starts from the script submitted by the username and password; 2, add a set point before defining the transaction; That is; 4, parameterized login user's identity; second is the requirements for scene settings: 1, because we don't know how many user access is critical, so it is necessary to change the number of users multiple times during the test; 2. It is recommended to modify the runtime settings, optimize access to the server; 3. Plan settings, load 10 users after each x time (set according to total users), continue to run without more than 5 minutes (set as needed); 4, set strategy, when the number of users in the run reaches the collection point; 5, pay attention to a few times: 1) Server response timeout; 2) The time used in the transaction iteration; 3) Collection points Wait for timeout; 4) The interval set in the plan. In my test, the transaction is not more than 30 seconds. By modifying the script to reach a minute, the server responds timeout, the combination point waits for timeout, the interval set in the plan is set for 2 minutes. . Such a scene starts running the user's number of steps growth, and the newly added users in each rising point will send the server with the user who has already run. Through multiple operations and comparison of the number of users and error users in the test results, the number of users who can get the maximum concurrent access to the function can be obtained according to the defined error rate. The requirements for networks, clients, etc. are excluded in the above test. In the actual test, you must first guarantee that these resources are sufficient. Using JMeter can also achieve the test of the scene described above, and more convenient. Welcome to contact me MSN: WyingQuan At Hotmail Dot COM author BLOG:
http://blog.9cbs.neet/wyingquan/
