What is a load scenario?
Table of Contents
Beginner - This article is part of a series.
What is a test scenario? #
A test scenario is the representation of one or more business flows or critical flows that will be executed concurrently on the target infrastructure by one or more virtual users. When it is a single flow, it will be executed equally for all virtual users, but when it involves a larger number of flows, a load model must be generated in order to make the test as close to reality as possible.
What is a business flow or critical flow? #
A business flow or critical flow consists of one or more business transactions or transactions. Business flows are also known as business processes, and critical flows are also known as critical processes. To avoid confusion due to the large number of paronyms, we will refer to them from here on as flow and/or transaction.
What is a load model? #
The load model is the distribution, based on percentages or the number of iterations, that virtual users will execute for each of the flows. Let’s suppose we have a web application for an airline with the following flows:
- Flight search
- Flight purchase
- Itinerary query
If we didn’t have a load model, the percentages would most likely be distributed equally across the three flows, but by digging deeper into the application and performing some analysis on the logs, we adjusted the model to the following distribution:
- Flight search - 70%
- Flight purchase - 15%
- Itinerary query - 15%
In this way, we would be adjusting the load model so that the scenario execution is as close as possible to what our application experiences in production.
What is a transaction? #
It is the representation of one or more test cases. This is where we can link the functional world with the non-functional world, since test cases are a functional deliverable and we can use them to generate transactions. For example, to make a credit card payment, multiple test cases are needed to reproduce the arrival, authentication, menu selection, account selection, form completion, and finally, the payment submission. Here we could assume that each test case could generate a transaction; however, this process requires analysis to evaluate whether there are any ramifications that we could encapsulate.
We can also define a transaction as the grouping of one or more requests; these requests could be HTTP requests.
Conclusion #
It is advisable to use test cases to generate transactions, which in turn will help us produce flows. The load model defines the distribution of virtual users who will execute each flow in the test scenario. It is worth mentioning that test cases may vary depending on the type of data used, but the result should be the same. If the result is not the same, we run the risk of not correctly labeling transactions and incorrectly measuring response times.