In the previous article in this series, we introduced the open source testing tool JMeter and used a simple HTTP test as an example to get a glimpse of JMeter’s capabilities. In this article, we’ll take a closer look at JMeter’s rich components to help you build test scripts for complex scenarios.
The JMeter test scripts are presented as “trees” in the interface, and the saved JMX files themselves are in XML format. The JMeter script tree takes the Test Plan as its root node, and all Test components are included in the Test Plan. Test plans can be configured with custom variables called by components in the entire test plan, thread group running mode, library files used in tests, and so on.
Using multiple test components in your test plan allows you to build rich test scenarios. The test components in JMeter fall into the following categories: thread groups, samplers, logical controllers, listeners, configuration elements, assertions, timers, preprocessors, and postprocessors. The following sections describe each and explain the major components in detail.
Thread groups
The thread group component is the entry point to all test plans. All samplers and controllers must be placed under thread groups. A thread group can be regarded as a virtual user pool, where each thread can be regarded as a virtual user, and multiple virtual users perform the same batch of tasks at the same time. Each thread is isolated from each other. One thread does not operate on a variable that affects the value of another thread’s variable.
The interface of a thread group is shown below:
Action to perform after a sampler error
These configuration items control whether the execution policy tested when an error is encountered continues.
- Continue: Ignore errors and continue execution
- Start next process loop: ignore errors, the current loop terminates, and the next loop is executed.
- Stop thread: The current thread stops execution without affecting the normal execution of other threads.
- Stop test: The entire test is stopped after all currently executing threads have finished executing
- Stop the test immediately: The entire test stops execution immediately, and the currently executing sampler may be interrupted.
The number of threads
The number of threads is the number of concurrent users, and each thread will run the test plan completely independently of each other. Multiple threads were used in the test to simulate concurrent access to the server.
The ramp – up time
Ramp-up time Sets 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 get 10 threads up and running, each starting 10 seconds after the previous one.
If the ramp-up value is set to a very small value and the number of threads is set to a large value, the initial execution of the test will put a lot of strain on the server.
cycles
Sets the number of loops per thread in a thread group before completion.
Delay thread creation until needed
By default, all threads are created when the test starts. If this option is checked, threads are created when they are needed.
Thread group scheduler
The scheduler configuration provides more flexibility in controlling the timing of thread group execution
(1) Duration: Control the duration of test execution, in seconds.
(2) Start delay: Control how long after the test is started and executed, in seconds.
Second, the sampler
Sampler is used to simulate user operation, is to send requests to the server, the server response data operation unit. The sampler is a component contained within a thread group, so it must be added within the thread group. JMeter natively supports a number of different samplers, such as TCP sampler, HTTP request, FTP request, JDBC request, Java request, and so on, each of which makes a different type of request to the server based on the parameters set.
TCP sampler
The TCP sampler connects to a specified server over TCP/IP, sends a message to the server, and waits for the server to respond.
The interface is shown as follows:
The properties that can be set in the TCP sampler are:
1.TCPClient classname
Represents the implementation class that handles the request. Use the default org. Apache. Jmeter. Protocol. TCP. Sampler. TCPClientImpl, using plain text transmission. JMeter also built-in support BinaryTCPClientImpl and LengthPrefixedBinaryTCPClientImple, the former use hex message, on the basis of the latter in BinaryTCPClientImpl prefix to increase the length of the 2 bytes.
Can also through inheritance org. Apache. Jmeter. Protocol. TCP. The sampler. The TCPClient to provide a custom implementation class.
2. Set the target server
Server Name or IP and Port number specify the host name, IP address, and port number of the server application.
3. Connection options
- Re-use Connection: : If selected, the connection is always open, otherwise it is closed when data is read.
- Close connection: If selected, the connection will be closed after the TCP sampler has finished running.
- Set no delay: If selected, the Nagle algorithm is disabled, allowing small packets to be sent.
- SO_LINGER: Controls whether to wait for data transmission in the buffer to complete before closing the connection.
- End of line (EOL) byte value: The byte value used to determine the end of the line. If the specified value is greater than 127 or less than -128, the EOL check is skipped. For example, if the string returned from the server ends in carriage return, we can set this option to 10
4. Timeout:
- Connect Timeout: Indicates that the connection times out
- Response Timeout: Indicates that the Response times out
5. Text to send
Text of the request message
6. Login and configuration
Set the username and password to use for the connection
HTTP request sampler
The HTTP sampler sends HTTP/HTTPS requests to the Web server.
1. Name and comments
2. Request protocol
The protocol used to send requests to the target server. It can be HTTP, HTTPS, or FILE. The default is HTTP.
3. Domain name or IP address
The name or IP address of the server to which the request is sent.
4. The port number
The port number that the Web service listens on. The default HTTP port is 80 and HTTPS port is 443.
5. Request method
The methods used to send a request are GET, POST, DELETE, PUT, TRACE, HEAD, and OPTIONS.
Path of 6.
The destination URL path to request (excluding server address and port).
7. Content coding
This mode applies to POST, PUT, PATCH, and FILE requests and encodes request contents
8. More request options
- Automatic redirects: Redirects are not considered separate requests and are not logged by JMeter.
- Follow redirects: Each redirect is treated as a separate request and is logged by JMeter.
- Use KeepAlive: If selected, Connection: keep-alive will be added to the request header for communication between JMeter and the target server.
- Multipart /form-data for POST: If selected, multipart/form-data or Application/X-www-form-urlencoded will be used to send requests.
Parameters of 9.
JMeter will use parameter key-value pairs to generate request parameters and send them in different ways depending on the request method. For example: GET, DELETE requests, parameters are attached to the request URL.
10. Message body data
If you want to transmit parameters in JSON format, you need to set content-type to Application/JSON in the request header
11. Upload files
Sending a file in a request, usually HTTP file upload behavior can be simulated in this way.
Logical controller
The JMeter Logic controller controls the execution Logic of components. “Logic Controllers determine the order in which Samplers are processed,” JMeter explains. That is, the logic controller can control the execution order of the samplers, so the controller needs to be used with the samplers. Logical controllers can be nested with each other except for only one controller.
Logic controllers in JMeter fall into two main categories:
- Control logical execution sequence of nodes during test plan execution, such as loop controller, If controller, etc.
- Group the scripts in the test plan so that JMeter can count the execution results and perform runtime control of the scripts, such as throughput controller and transaction controller.
Transaction controller
Sometimes we want to count the overall response time of a set of related requests, which requires a transaction controller.
The transaction controller counts the elapsed time of sampler execution on all child nodes under the controller. If multiple samplers are defined under the transaction controller, the entire transaction will be successful only if all of them run successfully.
Add transaction controller as shown below:
The configuration items of the transaction controller are:
1.Generate parent sample
If selected, the transaction controller will be used as a parent sample of other samplers, otherwise it will only be used as a standalone sample.
For example, if the check box is not selected, the summary report is as follows:
If selected, the summary report is as follows:
2. Include duration of timer and pre-post processors in generated samle:
Specifies whether a timer is included or not. If selected, a delay will be added before and after the sampler runs.
Once only controller
A once-only controller is, as its name implies, a once-only controller, that is, a request under that controller is executed only once during a loop execution under a thread group. For tests that require a login, consider placing the login request in a once-only controller, because the login request only needs to be executed once to establish a session.
Add only one controller as shown below:
If we set the thread group loop number to 2 and look at the result tree after the run, we can see that only once the request “HTTP request 3” under the controller is executed only once and the other requests are executed twice
Four, the listener
Listeners are a series of components used for processing and visualization of test result data. View result trees, graphical results, aggregate reports, and so on are some of the listener components we use frequently.
View result tree
This component presents each sampler’s results, request content, response time, response code, response content, and other information in a tree structure. Viewing this information can help analyze whether there is a problem. It provides a variety of viewing formats and filtering methods, but also can write results to specified files for batch analysis processing.
Five, configuration components
Configuration components are used to provide support for static data configuration. It can be defined at the test plan level, or at the thread group or sampler level, defined at different levels and scoped differently. Configuration components mainly include user-defined variables, CSV data file Settings, TCP sampler configuration, HTTP Cookie manager and so on.
User-defined variables
By setting a series of variables, you can select variables randomly during performance testing. Variable names can be referenced in scope by ${variable name}.
In addition to the “user-defined variables” component, variables can also be defined in several components, such as test plans and HTTP requests:
For example: reference to a defined variable in an HTTP request:
The value of the variable is obtained:
CSV data file Settings
During performance testing, we often need some parameterized input parameters, such as the user name and password in the login operation. When the concurrency is high, the runtime data generation will be a heavy burden on the CPU and memory, and the CSV data file configuration can be used as a source of parameters required in this scenario.
The following describes some parameters in CSV data file Settings:
- Variable name: Defines the parameter names in the CSV file, which can be referenced in the script as ${variable name}
- Loop over end-of-file: if set to True, the CSV file is allowed to loop
- End of file stop thread encountered: if set to True, the thread stops after reading records in the CSV file
- Thread sharing mode: Sets the mode of sharing between threads and thread groups
Six, assertions
Assertions check that the interface returns as expected. Assertions are an important part of automated test scripts, so take them seriously.
Common JMeter assertions include Response Assertion, JSON Assertion, Size Assertion, Duration Assertion, and Beanshell Beanshell Assertion, etc. Here we only describe JSON assertions that are often used.
JSON assertion
Used to assert jSON-formatted response content.
Add JSON assertions to an HTTP sampler as shown below:
The JSON assertion configuration items are:
- Assert JSON Path exists: INDICATES the JSON expression to be asserted
- Additionally, this item is selected if you want to assert value based on the value
- Match as Regular expression: Select Match as regular expression
- Expected Value: Expected Value
- Expect NULL: Check if null is expected
- Invert Assertion: Reverse
Where the “root member object” in the JSON path is always referred to as $and can be provided via the “dot — notation” (. Bracket () or ‘bracket — notation’ ([]), such as $.message[0]. Name or $[‘message’][0][‘name’].
“$. Message” represents the message in the RESPONSE to the JSON object. “Additionally,” tick “assert value” indicates that the value of “message” should be judged. Expected Value: OK Indicates whether message is OK.
Run the script and see the result. You can see that the assertion passes
The assertion criteria are as follows: If the response result is not in JSON format, it fails. Json path fails to find elements. If the JSON path finds the element, no condition is set and passes; If the JSON path finds the element but does not match the condition, it fails. If the JSON path finds the element and the condition is met, pass. If the JSON path returns an array, it iterates to see if any of the elements match the criteria. If so, it passes, and if not, it fails. Go back to JSON Assertion, check Invert Assertion
Run the script and look at the result. You can see that the assertion failed
Vii. Timer
In performance testing, the pause time between access requests is called thought time. In practice, the pause time can be the time spent looking up content, reading content, etc., and timers are used to simulate this pause time. Among them:
- All timers in the same scope execute before the sampler.
- If you want the timer to apply only to one of the samplers, add the timer to the child node of that sampler.
JMeter timer includes: Constant Timer, Uniform Random Timer, Precise Throughput Timer, Constant Throughput Timer, Gaussian Random Timer, JSR223 Timer, Poisson Random Timer, Synchronizing Timer, and BeanShell scripting Timer.
Stationary timer
Fixed timer, that is, the interval between each request is set to a fixed value.
Add a fixed timer to a transaction controller as shown below:
After setting the thread delay to 100 and 1000 respectively, run the script
View the data in the table. 1 and 2 are the results when the interval is set to 100 ms, and 4 and 5 are the results when the interval is set to 1000 ms. It can be seen that the interval between 4 and 5 is significantly longer than that between 1 and 2
Constant throughput timer:
A constant throughput timer is used to control requests to be executed at a specified throughput.
Add a constant throughput timer to a transaction controller as shown below:
Set the target throughput to 120 and select “All active threads in current thread group (shared)” based on computational throughput
Run the script and view the result. You can see that the throughput is basically 2/ second (120/60).
8. Pre-processor and post-processor
The preprocessor performs operations prior to the sampler request, often used to modify parameters, set environment variables, or update variables not extracted from the response text before the sampler request runs.
Similarly, the post-processor performs some operations after the sampler request. Sometimes the server’s response data is needed for subsequent requests, and we need to process the response data. A post-processor is used, for example, when the JWT token in the response is obtained and used in subsequent requests for authentication.
These are the main test components of JMeter that you can try to use in real life. The next article will cover the use of MQTT plug-ins in JMeter.
Copyright: EMQ
Original link: www.emqx.com/zh/blog/int…
Technical support: If you have any questions about this article or EMQ related products, please visit askemq.com to ask questions. We will respond to you in time.
More technical dry goods, welcome to our official account [EMQ Chinese community].