Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is the stress testing method for Web website". In the daily operation, I believe that many people have doubts about what the stress testing method for Web website is. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "what is the stress testing method for Web website?" Next, please follow the editor to study!

Web website stress testing tutorial

Traditional testing methods include some form of simple unit testing, usually performed by developers. Designing these tests requires internal knowledge of the software, and these tests are almost always aimed at very small, specific parts of the product. These types of tests are ideal for simple Web services that interact with other code components with little or no interaction.

Functional verification (Functional Verification) is also a testing process in which designers who have limited knowledge of the product source code are tested to confirm the core functions of the product or service. This test is designed to prove that this core function conforms to a specification. For example, does my online auction show the correct bid entered? Has my insurance brokerage system found a quotation for *? If these tests fail, it usually means that a basic problem with the product has been detected (which can usually be fixed directly). This test is also suitable for simple Web services, allowing you to check that the service is performing its functions correctly.

System testing (System Test) is usually completed in the functional verification phase, after the verification of the core functions. It tends to look for problems with the entire system as a whole-figuring out how Web services work as part of the system and how Web services interact with each other. Because system testing takes place near the end of the development life cycle, it is usually not given enough time to complete. Because of the tight release schedule and the backwardness of each important stage of development, the system testing phase is often ignored, and some rare errors that can usually be found can not be detected. Even if such errors are found, it is too late to determine the cause of the errors and try to fix them. Therefore, when looking for code errors, the system test application must be designed as efficiently as possible. System testing usually consists of three parts, which are:

Performance (Performance): this involves the process of determining relevant product statistics. For example, how many messages are there per second? How many users can a service accept at the same time?

Case (Scenario): this is the process of recreating the exact configuration required by the customer. Therefore, any problems found in the case can be detected before the customer uses the product.

Stress (or workload balancing): it is different from the other two parts because it is designed to overload the software by applying large workloads. If stress testing can be performed effectively by maintaining high-intensity use of the product (but not beyond the limits determined by performance statistics), it can often find many hidden errors that cannot be detected with any of the other techniques mentioned above (and these errors are often the most difficult to fix).

In terms of detecting code errors, it is the stress test that can prove the efficiency of the three system test components. However, because this process is often confused with other elements of the system or functional testing, the methods involved in this process have not been properly addressed or implemented.

Mistakes under pressure

With stress testing, you will hopefully find many errors that are more difficult to find with other testing methods. There are two types of errors:

Memory leak (Memory leak): an extremely difficult phenomenon to detect. Memory leaks often occur in released products for a simple reason that it is difficult to design test cases to detect them. With simple functional testing, memory leaks are almost impossible to find, because the tests do not use the product enough before it is completed. Memory leaks usually require operations to be repeated a very large number of times to make memory consumption noticeable. Although it is more difficult for Java programs to introduce memory leak errors than other programming languages, as long as the program maintains a reference to the object, the object may still be instantiated and the memory it occupies will never be freed.

Concurrency and synchronization (Concurrency and Synchronization): stress testing excels at finding concurrency problems because it applies many different code paths and timing conditions in any test life cycle. The general rule is that the longer the stress test runs, the more code path combinations and timing conditions are involved and applied. Of course, it does make these problems difficult to reproduce (errors can occur in five minutes or five days). Deadlocks, thread leaks, and any general synchronization problems can only be detected during the stress test phase. These types of problems are difficult to find by performing unit tests. The developer does not always consider that his or her code will interact with code elsewhere that may not have been written when the unit test is executed.

Existing stress testing tools

A number of available tools that claim to be able to stress test products are currently under development. The tools that are widely used are those for Web services. However, many of these tools are simple HTML/SOAP generators that simulate many client connections and therefore generate a high load on the Web server (this is useful for finding problems with Web servers, but not so useful for finding problems with Web services). These tools are useful for basic stress testing, but they often simply extend the functional verification phase to perform the same functional tasks repeatedly. If enough time and resources are available, more effective testing can be achieved by creating a custom-built stress test system. Because designers of stress systems usually know more about the products and Web services to be tested, they will be able to ensure which specific areas of code the stress system can be used for.

Design pressure application

When you design stress test systems that attempt to stress test Web services, you want them to run code in a particular way. These styles go beyond functional verification to find out whether the Web service being tested can not only do what we think it can, but also continue to function properly under some intense pressure. The stress test must apply four basic conditions to the Web service. These conditions are applied to many established pressure systems. An effective stress test system will apply the following key conditions:

Repetition: perhaps the most obvious and easy-to-understand stress condition is test repetition. In other words, the repetition of a test is to perform an operation or function over and over again, such as repeatedly calling a Web service. Functional verification tests can be used to determine whether an operation can be performed properly. The stress test will determine whether an operation can be performed properly and whether it can continue to be normal each time it is performed. This is very important to infer whether a product is suitable for a certain production situation. Customers usually reuse the product, so stress tests should find code errors before the customer. Many of the simplest stress systems implement only this condition, but simply extending the functional verification test to repeat multiple times does not constitute an effective stress test. When used in conjunction with some of the following principles, repetition can reveal many hidden code errors.

Concurrency: concurrency is the act of performing multiple operations at the same time. In other words, multiple tests are performed at the same time, such as invoking many Web services on the same server at the same time. This principle does not necessarily apply to all products (such as stateless services), but most software has a co-release or multithreaded behavior element, which can only be measured by executing multiple code examples. Functional or unit tests are rarely combined with any concurrent design. The stress system must go beyond functional testing and traverse multiple code paths at the same time. How to do this depends on the specific product. For example, a Web service stress test needs to simulate multiple clients at a time. Web services (or any multithreaded code) typically access some shared data between multiple thread instances. Increased complexity due to additional aspects of programming usually means that the code has many errors caused by concurrency. Because introducing concurrency means that code in one thread may be interrupted by code in other threads, errors are found only when an instruction set is executed in a specific order, such as with specific timing conditions. By combining this primitive principle with the principle of repetition, you can apply many code paths and timing conditions.

Order of magnitude (Magnitude): another condition that the pressure system should be applied to the product takes into account the load in each operation. The stress test can repeat an operation, but the operation itself should also add as much burden to the product as possible. For example, a Web service allows a client to enter a message, and you can use this single operation intensively by simulating a client that enters an extremely long message. In other words, you increase the order of magnitude of this operation. This order of magnitude is always application-specific, but it can be determined by looking for values that can be measured and modified by the user-for example, the size of the data, the length of the delay, the transfer of the amount of money, the speed of input, changes in input, and so on. Individual high-intensity operations may not find code errors on their own (or only functional defects), but when combined with other stress principles, you will increase your chances of finding problems.

Random variation: * at a point, any stress system is more or less random. If you randomly use the numerous variations described in the previous stress principles, you will be able to apply many different code paths each time the test runs. Here are a few examples of how to change a test during the test life cycle. When using repetition, you can change the interval between repetitive operations, the number of repeats, or the order of Web services that are repeated before restarting or reconnecting the service. With concurrency, you can change the number of Web services executed together, the number of Web services running at the same time, or you can change your decision about whether to run many different services or run many of the same instances. The order of magnitude is probably the easiest to change-variables that appear in the application can be changed each time the test is repeated (for example, sending messages of various sizes or numeric input values). If the test is completely random, some systems use random variations based on a fixed random seed because it is difficult to consistently reproduce errors under pressure. In this way, with the same seed, there is a better chance of repeating the mistake.

A stress test usually combines the above principles and runs for as long as possible. The longer the test is allowed to execute, the more code paths you can traverse and the more errors you find. Of course, once an error is found, it must be diagnosed and fixed. Because a code error can show itself many days after the stress test runs, the system must ensure that all available debugging information is generated when an error occurs-otherwise it may take as much time to reproduce the error.

At this point, the study on "what is the method of stress testing for Web websites" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.