Load model | Performance testing

The load model describes at a logical level how the test object will be loaded and how the performance will be measured.


A load model is a description of the various expected levels of load on an IT system, which is the basis for specifying and executing performance tests.

The load model is comparable with the logical test design and consists of the following parts:

  • Performance requirement(s)
    The requirements are inventoried and, if necessary, detailed. A requirement in terms of the number of simultaneous users, for example, is inexact as a result of a variable pace of working, also because it is not known how often a user carries out a transaction. Therefore, extra information is required, preferably the number of transactions/hits per unit of time.
  • Test object
    On the basis of the requirements and the risk estimate, the tester decides on the test object (e.g. the complete application(chain) or perhaps just an individual database or application server). This has a direct impact on the required test environment(s).
  • Load to be generated
    The eventual aim of a load model is to generate a representative load on the system. This load consists of a specified number of users, who each carry out certain tasks/transactions. The tester differentiates various types of transactions (e.g. search task, filling a shopping cart, making a purchase) and various types of user behavior (seekers, buyers). ubsequently, the frequency with which the transactions are being carried out is determined and the number of users required for a specific time period.


Number of transactions per hour:

  • Transaction 1: 500 × home page
  • Transaction 2: 50 × search / browse task
  • Transaction 3: 20 × filling shopping cart
  • Transaction 4: 10 × making purchase

For the generation of this load, it could be decided to use 500 unique users (some of whom will therefore perform very few actions), but it is also possible to have only 50 active users (for e.g. search tasks and making selections and ordering now and then) while 50 other users do nothing other than repeatedly open and close the home page, which will result in the desired number of transactions per hour.

  • The test environment to be used is determined based on the defined test object and the load to be generated
  • Indicators, the parts to be measured, such as processor usage, memory usage, disk usage and network traffic
  • Description of required initial situation. The initial situation that is required in order to be able to perform the test. Usually, this should be representative of the production situation regarding scope
  • Graphic reproduction of the test object architecture. Although optional, this makes the testing clearer and more accessible.

Particularly when choosing the test object, determining which transactions will make up part of the test and defining the test environment, the balance between risks and representativeness on the one hand and time and money on the other plays an important part. With this, the costs of the tools required to simulate large numbers of users and perform measurements should not be underestimated.