JMeter-Get Started

JMeter Test Components: A Comprehensive Guide

Download

Version: apache-jmeter-5.4.1

Download Link: https://jmeter.apache.org/download_jmeter.cgi

Common Structure of Test Cases

The following is the basic structure of a test case in JMeter. You can add different components to each node to organize the test case.

1. Test Plan
2. Thread Group
3. Logic Controller (Optional)
4. Sampler

Basic Theory:
Here are some basic theories that you need to keep in mind while working with JMeter test components:

• Sampler is the core of the test case, and all components depend on it for validation.
• All components are dependent on the directory for the scope of validity management. Components at or above the level of Sampler are valid for all Samplers at the current level. Components below the level of Sampler only take effect for the current Sampler.
• Controller only groups Sampler, but the parameters of components at the same level remain in effect.
• Proximity Principle: the same components or parameters throughout the test plan, which are closer, have the higher priority.
• Data between Thread Groups are independent of each other, except for some special cases and global variables.

Add-support

The following table summarizes the Add-support between all components:

	Test Plan	Thread Group	Logic Controller	Sampler
Thread Group	√
Logic Controller		√	√
Sampler		√	√
Configuration Element	√	√	√	√
Pre-processors	√	√	√	√
Post Processors	√	√	√	√
Assertions	√	√	√	√
Timers	√	√	√	√
Listeners	√	√	√	√

Understanding Basic Components of JMeter

Test Plan

Test Plan is similar to a simple test plan in software testing which consists of all steps that execute the script. The purpose of the test plan is to sequence and execute everything included in it from top to bottom or as per the defined sequence. A Test Plan can be simple with just ThreadGroup, Sampler, and Listener, or it can become complex as more elements like config elements, preprocessors, or controllers are added.

Thread Group

Thread Group is the starting point for all test plans, and all samplers and controllers must be placed under it. Each thread group can be considered a virtual user pool, where each thread represents a virtual user that performs the same batch of tasks simultaneously. Each thread is independent and does not affect others. During the execution of one thread, the variables of the current thread do not affect the variable value of other threads.

The Thread Group interface is shown below:

Action to be taken after a Sampler error

The following configuration items control whether the test will continue to be executed or not when an error is encountered:

• Continue: ignore errors and continue execution.
  1. Start Next Thread Loop: ignore the error, terminate the current thread loop, and execute the next loop.
  2. Stop Thread: stops executing the current thread without affecting the normal execution of other threads.
  3. Stop Test: stops the entire test after all currently executing threads have finished the current sampling.
  4. Stop Test Now: stops the entire test execution immediately, and currently executing samplers may be interrupted.
• Number of threads
  The number of concurrent users where each thread runs the test plan completely independently without interfering with each other. Multiple threads simulate concurrent access to the server.
• Ramp-up period
  Used to set the time required to start all threads. For example, if the number of threads is set to 10 and the ramp-up time is set to 100 seconds, JMeter will use 100 seconds to start and run 10 threads, and each thread will start 10 seconds after the previous thread was started. Setting a small ramp-up value and a large number of threads puts a lot of stress on the server at the beginning of the test.
• Loop count
  Sets the number of loops per thread in the thread group before ending.
• Delay thread creation until needed
  By default, all threads are created when the test starts. If this option is checked, threads are created only when they are needed.
• Specify thread lifetime
  The scheduler configuration can control the execution time of thread groups more flexibly:
  (1) Duration: controls the duration of the test, with the unit of seconds.
  (2) Startup delay: controls how long after the test will be delayed before startup, with the unit of seconds.

Logic Controller

The JMeter logic controller controls the execution logic of the components. Logic Controllers determine the order in which Samplers are processed. Therefore, the controller needs to be used together with the sampler. Except for the once-only controller, other logic controllers can be nested within each other.

The Logic Controllers in JMeter are mainly divided into two categories:

• Control the logical execution order of nodes during the execution of the test plan, such as loop controller, If controller, etc.

• Group the scripts in the test plan to facilitate JMeter to count the execution results and control the runtime of the scripts, such as throughput controller, transaction controller, etc.

Sampler

A sampler is a component in a thread group that sends requests to the server and receives response data. It simulates user operations and is the running unit of a load test.

HTTP Request Sampler

The HTTP Request sampler is used to send HTTP/HTTPS requests to a web server.

The HTTP Request sampler includes the following components:

1. Name and Comments: You can provide a name and optional comments for the sampler.
2. Protocol: The protocol used to send the request to the target server, which can be HTTP, HTTPS, or FILE. The default is HTTP.
3. Server name or IP address: The hostname or IP address of the target server to which the request is sent.
4. Port number: The port number that the web service is listening to. The default port is 80 for HTTP and 443 for HTTPS.
5. Request method: The method of sending the request, commonly including GET, POST, DELETE, PUT, TRACE, HEAD, OPTIONS, etc.
6. Path: The target URL path to request (excluding server address and port).
7. Content encoding: Applicable to several request methods of POST, PUT, PATCH and FILE, which controls the way of encoding the request content.
8. Advanced request options
   • Redirect Automatically: Redirection is not treated as separate requests and is not recorded by JMeter.
   • Follow Redirects: Each redirection is treated as a separate request and is recorded by JMeter.
   • Use KeepAlive: If checked, Connection: keep-alive will be added to the request header when JMeter communicates with the target server.
   • Use multipart/form-data for POST: If checked, requests will be sent by using multipart/form-data or application/x-www-form-urlencoded.
9. Parameters: This component uses parameter key-value pairs to generate request parameters and sends these request parameters in different ways depending on the request method. For example, for GET and DELETE requests, parameters are appended to the request URL.
10. Message body data: If you want to pass parameters in JSON format, you need to configure the Content-Type as application/json in the request header.
11. File upload: This component sends the file in the request. HTTP file upload behavior can be simulated using this component. For more information on file upload, refer to the article: https://nataliexselina.github.io/2021/11/21/JMeter-file-upload/

Other Important Components in JMeter

Assertions

JMeter offers various assertions, including Response Assertion, JSON Assertion, Size Assertion, Duration Assertion, and Beanshell Assertion. In this article, we will focus on JSON Assertion, which is commonly used.
JSON Assertion - used to assert the content of the response in JSON format

• Configuration Items:
  • Assert JSON Path exists
  • Additionally assert value: Check if you want to assert based on the value
  • Match as regular expression: Check if you want to assert based on - regular expressions
  • Expected Value
  • Expect null: Check if NULL is expected
  • Invert assertion
    

Listeners

View Results Tree

This component displays the result, request content, response time, response code and response content of each sampler in a tree structure. Viewing the information can assist in analyzing whether there is a problem. It provides a variety of viewing formats and filtering methods, and can also write the results to specified files for batch analysis and processing.

Configuration Element

Configuration Elements are used to provide support for static data configuration. They can be defined at the test plan level or at the thread group or sampler level, with different scopes for each level.

HTTPS Requests Default

This configuration element is useful for specifying default values for HTTPS requests. Whatever is specified in the HTTP Request Default configuration element is inherited by all HTTP requests.

HTTPS Cache Manager

This configuration element can clear the cache after each request.

HTTPS Cookie Manager

This configuration element can manage the cookie settings.

User Defined Variables

This configuration element helps JMeter to pick values from pre-defined variables.

CSV Data Set Config

This configuration element is used for performance testing.

JMeter Parameterization

Parameters are added in several locations:

• Test Plan (usually as global variables)

• User Defined Variables (can be added at the Test Plan, Thread Group, Logic Controller, and Sampler level)

• Pre-processors - User Variables (can be added at the Test Plan, Thread Group, Logic Controller, and Sampler level)

  There is a difference between User Defined Variables and User Variables:

  • User Defined Variables are global variables accessible by all thread groups, while User Variables are local variables accessed only by single thread groups.
  • The relationship between variables and values is 1:1 in User Defined Variables, while the relationship between variables and values is 1:N in User Variables.

• CSV Data Set Config: parameters are recorded in a txt file and called when the test case is executed.