Please enable JavaScript.
Coggle requires JavaScript to display documents.
Jmeter - PS - 5 Configuring a Test plam (Structure a test (Test components…
Jmeter - PS - 5 Configuring a Test plam
Structure a test
Manually create a load test for a simple scenario
Test components are organized in a tree
Each component has a scope that specifies to what other components it can be applied or has access to (UsuallY THESe will be the elements at or under the components own level
Some components have fixed location in tree
(Ex: parent of thread group element must be a test plan)
Other elements like listener can be located anywhere in the tree (But location will determine the scope)
1.Explanation for all the components, except for test fragment and pre/post processor.
Rules of scoping
Order in which these components are executed
Test plan
Thread group
Configuration elements
Controllers and samplers
Timers
Assertions
Listeners
Execution order and rules
1.Test Plan
Top of the tree, root element of the test
Overall settings are specified
All other elements are contained
Open jmeter -> Test plan would have been already added
Can rename or modify description
Can define variables
Run thread groups consecutively (ie one at a time)
If selected and if there are more than one thread group, jmeter will execute them one after the other rather than in parallel
Teardown thread groups after shutdown of main threads
Threadgroups that run at the end fo the test, wont run if the stopped forcibly
Functional testing mode
Save information from the server responses to result files. these files can grow quickly, increasing the resources needed
to run the test and impacting Jmeter's perfromance, so activate this option only for a small test.
2 Thread groups
Entry point of a test
Controls the number of threads (users)
can have more than one thread groups
Each representing a test case
must be a child of a test plan
Create
Right click the test plan
Thread (Users)
setUp Thread Group
1 more item...
tearDown Thread Group
1 more item...
Default (thread group)
7 more items...
Configuration elements
There are many types of configuration, but in general they are used to set up default configurations and variables for later use by other components
In Jmeter configuration elements can be placed under any component
4 types
Elements that allow to define variables like CSV data set config, counter and random variable
Elements that allow us to define a configuration like JDBC connection, keystore configuration, login config element
Managers that allow us to manage configuration parameters like HTTP header manager, HTTP cookie manager, HTTP cache manager
Default configuration elements that allows us to define the full configurations for request types, for example, HTTP request defaults, FTP request defaults, Java request defauls,
Mostly used configuration elements
CSV data set config
is used to read the content of a comma-separated values file and turn it into variables.
HTTP Header manager
Allows us to add or override HTTP request headers
HTTP cookie manager
for each user it stores and send a cookie like a web browser
It allows you to manually add a cookie that will be shared by all users.
HTTP cache manager
is used to add caching functionality to HTTP request. Each user has its own cache. If the requested document has not changed since it was cached, the response body will be empty.
HTTP request defaults
User defined variables
Define a set of variables
These variables are processed once at the start of the test and are shared between old thread groups. You can reference the variables defined in the test plan component, but if two variables have the same name, the value is set to the last definition, reading from top to bottom.
Controllers and samplers
Controllers
are the children of thread group
2 types
Logic controllers
allows you to customize the logic to decide when to send requests
1 more item...
jmeter ->Many build in logic controllers
4 more items...
Can combine many logic controllers to simulate complex scenarios.
Example
2 more items...
Samplers
Tell jmeter to perform a request of certain type generating one or more results
5 Timers
Jmeter executes requests in sequence and without pauses
Timer allows you to introduce a delay between requests, specifically timers will introduce a delay before each sampler in their scope simulating the time the user takes to perform an action on a web page, and to avoid overwhelming the server with an unrealistic load.
In jmeter, timers can be added at any level of the tree, usually they are added as children of the samplers or controllers to which they apply. It's important to mention that timers are only processed in conjunction with a sampler. If there are no samplers in the scope of a timer, they will not be executed.
Ex: Add a time to thread group level [Right click the thread group -> Add -> Timer -> Uniform random timer]
Total delay is the sum of randome delay maximum and constant delay offset value
If you have more than one timer, Jmeter takes the sum of the timers and makes a pause for that amount of time before executing the sampler to which the timers supply.
Types
Constant timer
Allows us to have a pause for the same amount of time between requests
Uniform random timer, gaussian random timer, poisson random timer
Allow us to pause a request for a random amount of time.
Constant throughput timer, precise throughput timer
Introduce variable pauses in order to ensure a target throughput.
Assertions
Once the server response is received, probably you'll want to test if it contains some particular text.
Allow you to validate a response is as expected.
Jmeter comes with many types of assertion
Response assertion
That allows you to compare the response against the data it contains or it gathers.
JSON assertion
Allows you to perform validations of JSON documents.
Size and duration assertions
Test that each response was received within a given amount of time and a specific size
JSR223 and BeanShell assertion
Allow you to check the response using a scripting language
XPath assertion
tests an XML document against a DTD or a XPath expression,
XML and HTML assertions
that only test if XML and HTML documents are well formed
Assertions can be added at the thread group controller or sampler level and they will apply to all the samplers in their scope.
Ex: Response assertion to the transaction controller
Apply only to the home and book catalog requests.
Most assertions only apply to the main sample or request. Some will allow you to select if you want to apply the assertion to the main sample and or sub-samples
Validating sub-samples can be useful when retrieving all the embedded resource of a page and you want to validate if they have a certain size, for example. Also if a sub-sample assertion fails and the main sample is successful, the main sample will be set to a failed status. For now, let's keep things simple.
Assertions like XPath, XML, HTML are not really recommended because they consume a lot of resources.
Listeners
Jmeter collects information about the request it performs.
Listeners provide access to that information by listening to responses and aggregating metrics
Listeners can be added at any level, however they will collect information only from the elements at or below their level.
Types
View results tree
The most used listeners are view results tree, that shows a tree of all the responses received during the test,
Summary report
That creates a table and for each request in the test if provides many statistics
Aggregate report
Similar to summary report, but it use more memory.
Ex, two listeners under test plan element (1. view results tree, 2. summary report), all listeners can write data to a file. can configure which fields to save in either xml or csv format. or can also load an xml or csv file to read previous results and display them.
Important points
All listeners save the same data, the only difference is the way the data is presented
Listeners can use a lot of memory, exspecially if there are a lot of responses.
Execution Order and Rules
Components or elements of a test plan can be classified into two categories
Ordered (like controllers and samplers), that are executed in the order they appear in the test
Ordered Elements Example
1 more item...
Hierarchical (like all other elements) that are executed according to their scope
Response assertion 1 applied to the home sampler
Response assertion 2 applied to the samplers of transaction controller (catalog and book detail)
Execution order
Home -----> Response Assertion 1
Catalog -----> Response Assertion 2
Book Detail -----> Response Assertion 2
Assertions work with server responses, so samplers, which represent server requests, have to be executed before assertions
Configuration elements
Pre processors
Timers
Logic controllers
Post processors
Assertions
Listeners
Post - processors, assertions, listeners are not executed if there is no server response.
Timers, assertions, pre and post processors are only executed if there is a samplers to which they can be applied
Configuration elements, there are two rules to remember
User defined variables is processed at the start of a test, no matter where it is placed.
Configuration element inside a tree branch has higher precedence than another element of the same type in outer branch
1 more item...
As a general rule, configuration default elements are merged, managers are not, they are replaced by elements with high precedence.
1 more item...
General rule
Elements are rearranged according to the order of execution
Outer elements are executed before inner elements of the same type
Some elements are executed before or after each sampler in their scope (Example timers or samplers)
1 more item...
Example 1
1 more item...
Example 2
1 more item...
Example 3
1 more item...
Example 4
1 more item...
HTTP Request Defaults (Configuration)
Uniform Random timer (Timer)
Home Request (Sampler)
Response Assertion (Assertion)
View Results Tree (Listener)
Summary Report (Listener)
... process repeated for other requests
9 Running the test
