Load test (computer)

from Wikipedia, the free encyclopedia

A load test ( loan translation from Load Testing) is understood to be a software test that usually generates a very high load on the system to be tested and examines its behavior. A simulation can be used for this. the goal is

  1. the detection of errors not found in the functionally oriented system test / integration test,
  2. Meeting non-functional requirements, such as B. required response times as well as quantity processing to be demonstrated for productive operation .
  3. Check the dimensioning of the hardware equipment.

The load test is therefore after the functional test, i. H. the (sub) system must be in a functionally stable state in order to be able to be tested for load handling at all.

Expressions

The burden can be that functions are executed very quickly one after the other, or that parallel activities are carried out by virtual users ( multiuser , vUser). As a rule, work is carried out directly on the protocol level ( network protocol ).

A basic distinction can be made between (1) performance measurements and (2) load tests. Performance measurements repeat selected test cases or individual processes from the system test under a base load: this means that individual functions are checked for their performance properties, i. H. all users carry out the same process, which tests the scalability for the individual function (s). One speaks in this context of transactions. Load tests in the narrower sense test entire process chains and the process mix for performance, i. H. the links between the individual processes; They simulate concrete processes from actual operation and represent a step towards achieving operational suitability that should not be underestimated. Here, too, scalability is of decisive importance, but now for the entire process mix. Deadlocks in database access, which are otherwise difficult to test, are a common error .

If the system is consciously stressed beyond the defined load limit, it is referred to as a stress test . The load (number of virtual users) should be increased step-by-step beyond the defined load limit.

The following questions are examined:

  • How does the response time change depending on the load?
  • Can the system still work acceptably even under high load?
  • Does the system show undefined behavior (e.g. crash)?
  • Is there any data inconsistency ?
  • Does the system go back to normal after the overload has decreased?

In contrast, the used low-load testing , which is intentionally operated with a low intensity, the investigation of the interaction behavior of the virtual user and the signal produced by them message traffic on the system.

A load test over a longer period of time (e.g. 48–72 hours) is called a continuous load test ; it is primarily used to detect memory leaks .

The most destructive form of load test is the fail-over test . It is about checking the system behavior under load in the event of failure of system components. Ideally, this is used to check emergency scenarios, such as B. the timely connection of additional resources to prevent a total system failure.

execution

Generation of the test data

The test behavior is usually defined using a script language . Many tools allow recording via a web browser, similar to a macro in Excel. This is mostly done via a proxy, which translates the requests etc. into the script language. An important criterion here is the user friendliness when creating the test, but also the variability and the supported protocols (HTTP, HTTPS etc.). So-called test data generators are also used, especially in areas where the quantity of data is more important than its precise content . These are programs that generate a large amount of data according to a predetermined pattern, the exact size of the data amount can usually be configured. A frequent application here is the speed measurement of databases.

Test run

In the test run, the recorded behavior (possibly supplemented by random elements or counter-dependent variables) is executed concurrently in any number (virtual users) using the created script, thus putting the application under load. An important criterion here is the maximum load that can be generated, as well as the hardware requirements associated with it.

The possibility of distributing the load generation over several computers, which some tools offer, is also useful. This can minimize the influence of the network capacity and the hardware limitations of the load-generating computer. Recently, some commercial tools have been integrating the option of integrating additional load generators in a cloud .

The tool collects as much data as possible during the test run. Basically, this happens directly on the side of the load-generating application (response times, error codes, etc.). Some tools also offer additional options for monitoring certain web / database servers (e.g. IIS, Apache, MSSQL) or application servers (Tomcat, etc.) in order to directly identify relationships (e.g. high response time vs. database access). analyze. The data acquisition can, however, also take place in a modularized manner (auxiliary programs e.g. on the server of the application to be tested). It is crucial that as many options as possible for collecting different data are offered.

evaluation

Certain key figures (e.g. response time vs. time, timeouts vs. number of users, etc.) are usually available in log files or time-dependent graphs for evaluation . Good (mostly commercial) tools also offer options, e.g. B. using (auto) correlation functions to analyze the dependencies in behavior (e.g. high response time vs. calling up a specific page, etc.).

Norms

As an orientation for planning a load and performance test, DIN 66273 is a suitable starting point. This is contained in the international standard ISO 14756 and standardizes terms as well as measurement and evaluation methods for the performance of complex IT systems.

For the instrumentation of applications for performance and response time measurement, the Application Response Measurement (ARM) standard was adopted within the Open Group . This standard defines a programming interface for the programming languages C and Java .

Software tools

So-called load test tools are available for carrying out load tests. A load server is generally installed to generate the load on the system under test. You can either create the load test tools yourself, or you can use standard software that offers a wealth of functions and evaluation options.

Web links

literature

  • Röhrle, Jörg: A rule-based test data generator for rapid prototyping of database applications , Hamburg: Kovač, 1995
  • Stefan Asböck: Load Testing for eConfidence . Segue Software Deutschland GmbH, Hamburg 2001.
  • Mike Loukides, Gian-Paolo Musumeci: System Performance Tuning . 2nd Edition. O'Reilly & Associates, Sebastopol 2002.
  • Harry Sneed , Manfred Baumgartner, Richard Seidl : The System Test - From Requirements to Quality Proof . 3. Edition. Carl Hanser Verlag , 2011, ISBN 978-3-446-42692-4 .
  • Richard Seidl, Manfred Baumgartner, Thomas Bucsics: Basic knowledge of test automation - concepts, methods and techniques . 1st edition. dpunkt.verlag, 2011, ISBN 978-3-89864-724-3 .