This document will help you learn about NBomber core abstractions in more detail. The whole API is mainly built around these building blocks:
Step and Scenario play the most important role in building real-world simulations. A Step helps you to define only your test function. A Scenario is helping you to organize steps into test flow with different load simulations (concurrency control).
You can think of a Step like a function which execution time will be measured.
All steps within one scenario always execute sequentially. Every step runs in isolated a lightweight thread (Task<'T>) provided by a Scenario.
In case of step exception or returning Response.Fail() the execution will be restarted from zero step.
The same step can be hosted in several concurrent scenarios.
Every step after executing can return a response as an input parameter for the next step.
NBomber provides a way to set the size of a response for later usage for statistics related to data transfering.
Also, you can set even your own latency if you know that you need to correct the final value (it could be useful for PUSH scenarios when your response is buffered, meaning that you receive it earlier than NBomber function was invoked).
You also can return a fail.
Simulate a pause behavior.
In case if you don't want to include some step into statistics you can use doNotTrack = true.
Please read this page
Every step is running in a separated lightweight thread (Task<'T>) and has its own context.
It's a very useful abstraction which contains all related step's information.
Scenario helps to organize steps into sequential flow with different load simulations (concurrency control).
Technically speaking Scenario represents a lightweight thread (Task<'T>) of execution and NBomber allows to create many copies of such scenario to simulate parallel execution. Scenarios always run in parallel.
When it comes to load simulation, systems behave in 2 different ways:
- Closed systems, where you keep a constant number of concurrent clients and they waiting on a response before sending a new request. A good example will be a database with 20 concurrent clients that constantly repeat sending query then wait for a response and do it again. Under the big load, requests will be queued and this queue will not grow since we have a finite number of clients. Usually, in real-world scenarios systems with persisted connections (RabbitMq, Kafka, WebSockets, Databases) are tested as closed systems.
- Open systems, where you keep arrival rate of new clients requests without waitng on responses. The good example could be some popular website like Amazon. Under the load new clients arrive even though applications have trouble serving them. Usually, in real-world scenarios systems that use stateless protocols like HTTP are tested as open systems.
Make sure to use the proper load model that matches the load of your system. You can mix open and closed model if your use case requires it.
Initializes scenario. You can use it to for example to prepare your target system.
Another popular use case is to parse your custom settings.
You can read more about configuration on this page
Cleans scenario's resources.
Use warm-up for warming up NBomber itself and target system. Warm-up will just simply start a scenario with a specified duration.
Scenario context is available on init and clean phase.
Mainly NBomberRunner is responsible for registering and running scenarios under Test Suite. Also it provides configuration points related to infrastructure, reporting, loading plugins.
NBomber runner API
Data feed helps you to inject dynamic data into your test. It could be very valuable when you want to simulate different users which send different queries. Feed represents a data source stream that you attach to your step and then NBomber iterates over this stream taking some feed's item and setting it to Step.Context.FeedItem public property.