Introduction to JMeter Test Components-Internet of Things Concurrent Test Actual Combat 02

In , the last article of this series, , we introduced the open source testing tool JMeter, and took a simple HTTP test as an example to get a glimpse of JMeter's capabilities. In this article, we will further introduce the rich components of JMeter to help you build test scripts for complex scenarios.

JMeter test scripts are presented in the form of a "tree" in the interface, and the saved test script jmx file itself is also in xml format. The JMeter script tree has a test plan (Test Plan) as the root node, and all test components will be included in the test plan. The test plan can be configured with custom variables called by the components in the entire test plan, thread group operating mode, library files used in the test, etc.

By using multiple test components in the test plan, you can build rich test scenarios. The test components in JMeter roughly fall into the following categories: thread groups, samplers, logic controllers, listeners, configuration elements, assertions, timers, pre-processors, and post-processors. The following sections will be introduced separately and the main components will be explained in detail.

One, thread group

The thread group component is the entry point for all test plans. All samplers and controllers must be placed under the thread group. A thread group can be regarded as a virtual user pool, in which each thread can be understood as a virtual user, and multiple virtual users perform the same batch of tasks at the same time. Each thread is isolated and does not affect each other. During the execution of a thread, the manipulated variable will not affect the variable value of other threads.

The interface of the thread group is as follows:

The following data can be set in the thread group interface to control the thread group:

Action to be performed after sampler error

These configuration items control whether the "execution strategy of testing when an error is encountered" will continue to execute.

• Continue: Ignore the error and continue execution
• Start the next process loop: Ignore the error, the current loop of the thread is terminated, and the next loop is executed.
• Stop thread: The current thread stops executing, and does not affect the normal execution of other threads.
• Stop the test: the entire test will stop after all currently executing threads have finished executing
• Stop the test immediately: The entire test will stop execution immediately, and the currently executing sampler may be interrupted.

Threads

The number of threads is also the number of concurrent users, and each thread will run the test plan completely independently without interfering with each other. Multiple threads are used in the test to mimic concurrent access to the server.

ramp-up time

The ramp-up time is used to set the time required to start all threads. For example: the number of threads is set to 10, and the ramp-up time is set to 100 seconds, then JMeter will use 100 seconds to start and run 10 threads, and each thread will start 10 seconds after the previous thread starts.

If the ramp-up value is set to a small value and the number of threads is set to a large value, it will put a lot of pressure on the server when the test is first executed.

Cycles

Set the number of times each thread loops in the thread group before the end.

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 can more flexibly control the execution time of the thread group

(1) Duration: Control the duration of test execution, in seconds.

(2) Start-up delay: control how long the test will start execution, in seconds.

2. Sampler

The sampler is used to simulate user operations. It is an operating unit that sends requests to the server and receives server response data. The sampler is a component contained in the thread group, so it must be added in the thread group. JMeter natively supports a variety of different samplers, such as TCP samplers, HTTP requests, FTP requests, JDBC requests, Java requests, etc. Each different type of sampler sends different types of requests to the server according to the set parameters.

TCP sampler

The TCP sampler connects to the specified server through TCP/IP, sends a message to the server after the connection is successful, and then waits for the server to reply.

The interface is shown in the figure:

The attributes that can be set in the TCP sampler are:

1.TCPClient classname

Represents the implementation class that handles the request. By default, org.apache.jmeter.protocol.tcp.sampler.TCPClientImpl is used, and ordinary text is used for transmission. In addition, JMeter also has built-in support for BinaryTCPClientImpl and LengthPrefixedBinaryTCPClientImple. The former uses hexadecimal messages, and the latter adds a 2-byte length prefix on the basis of BinaryTCPClientImpl.

You can also provide a custom implementation class by inheriting org.apache.jmeter.protocol.tcp.sampler.TCPClient.

2. Target server settings

"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 checked, this connection will always be open, otherwise it will be closed after reading the data.
• Close connection: If checked, this connection will be closed after the TCP sampler has finished running.
• Set no delay: If checked, the Nagle algorithm will be disabled, allowing small data packets to be sent.
• SO_LINGER: Used to control whether to wait for the data in the buffer to be sent 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 will be skipped. For example, the string returned by the server ends with a carriage return, then we can set this option to 10

4. Timeout time:

• Connect Timeout: connection timeout
• Response Timeout: Response timeout

5. Text to be sent

The text of the message requested to be sent

6. Login configuration

Set the username and password for connection

HTTP request sampler

The HTTP sampler sends HTTP/HTTPS requests to the web server.

1. Name and comment

2. Request protocol

The protocol used when sending a request to the target server can be HTTP, HTTPS or FILE, and 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. Port number

The port number that the web service monitors. The default port for HTTP is 80, and the default port for HTTPS is 443.

5. Request method

The method of sending request, commonly used GET, POST, DELETE, PUT, TRACE, HEAD, OPTIONS, etc.

6. Path

The target URL path to be requested (not including server address and port).

7. Content coding

It is suitable for POST, PUT, PATCH and FILE request methods, and the method of encoding the request content

8. More request options

• Automatic redirection: Redirection will not be treated as a separate request and will not be recorded by JMeter.
• Follow redirection: Each redirection is regarded as a separate request and will be recorded by JMeter.
• Use KeepAlive: If checked, Connection: keep-alive will be added to the request header when communicating between JMeter and the target server.
• Use multipart/form-data for POST: If checked, multipart/form-data or application/x-www-form-urlencoded will be used to send the request.

9. Parameters

JMeter will use parameter key-value pairs to generate request parameters, and send these request parameters in different ways according to the request method. For example: GET, DELETE request, the parameters will be appended to the request URL.

10. Message body data

If you want to transmit parameters in JSON format, you need to configure the Content-Type as application/json in the request header

11. File upload

Sending files in the request, usually HTTP file upload behavior can be simulated in this way.

Three, logic controller

The JMeter logic controller can control the execution logic of the component. The JMeter official website explains: "Logic Controllers determine the order in which Samplers are processed". In other words, the logic controller can control the execution sequence of the samplers, so the controller needs to be used with the samplers. Except for the one-time controller, other logic controllers can be nested with each other.

The logic controllers in JMeter are mainly divided into two categories:

• Control the logical execution sequence of nodes during the execution of the test plan, such as: loop controller, If controller, etc.;
• Group the scripts in the test plan, facilitate JMeter to count the execution results, and perform runtime control of the scripts, such as: throughput controller, transaction controller.

Transaction controller

Sometimes we want to count the overall response time of a group of related requests. In this case, we need to use the transaction controller.

The transaction controller will make statistics on the execution time of the samplers of all the child nodes under the controller. If multiple samplers are defined under the transaction controller, the entire transaction can be considered as successful when all the samplers run successfully.

Add the transaction controller as shown below:

The configuration items of the transaction controller are:

1.Generate parent sample

If selected, the transaction controller will serve as the parent sample of other samplers, otherwise the transaction controller will only serve as an independent sample.

For example, the summary report when unchecked is as follows:

The summary report when checked is as follows:

2.include duration of timer and pre-post processors in generated samle：

Specify whether to include a timer. If checked, a delay will be added before and after the sampler runs.

Only once controller

Only once controller, as the name implies, is a controller that executes only once, that is, the request to the controller is executed only once during the loop execution under the thread group. For tests that require login, consider placing the login request in the once-only controller, because the login request only needs to be executed once to establish a session.

Add the controller only once as shown in the figure below:

If we set the number of thread group cycles to 2, and check the result tree after running, we can see that the request "HTTP Request 3" under the controller was executed only once, and other requests were executed twice

Fourth, the listener

Listener is a series of components used to process and visualize test result data. View the results tree, graphical results, aggregate reports, etc. are all listener components that we often use.

View the result tree

This component displays the results, request content, response time, response code, response content and other information of each sampler in a tree structure. Viewing these information can assist in analyzing whether there are problems. It provides a variety of viewing formats and screening methods, and the results can also be written into a specified file for batch analysis and processing.

Five, configuration components

The configuration element is used to provide support for static data configuration. It can be defined under the test plan level, or under the thread group or sampler level. It can be defined at different levels with different scopes. The configuration elements mainly include user-defined variables, CSV data file settings, TCP sampler configuration, HTTP Cookie manager, etc.

User-defined variables

By setting a series of variables, the purpose of random selection of variables in the performance test process is achieved. The variable name can be quoted in the scope, and the variable can be quoted by way of ${variable name}.

In addition to the "user-defined variable" component, variables can also be defined in multiple components such as test plans and HTTP requests:

For example: a defined variable is referenced in the HTTP request:

Check the execution result, you can see that the value of the variable is indeed obtained:

CSV data file settings

In the process of performance testing, we often need some parameterized input parameters, such as the user name and password in the login operation. When the amount of concurrency is relatively large, the data generated at runtime will put a greater burden on the CPU and memory, and the CSV data file configuration can be used as the source of parameters required in this scenario.

The description of some parameters in the CSV data file setting is as follows:

• Variable name: Define the parameter name in the CSV file. After the definition, it can be referenced in the script in the way of ${variable name}
• Recycle again when the end of file is encountered: if set to True, it is allowed to cycle the value of the CSV file
• Stop the thread when it encounters the end of the file: if it is set to True, it will stop running after reading the records in the CSV file
• Thread sharing mode: set the sharing mode between threads and thread groups

Six, assertion

Assertion is to check whether the return of the interface meets expectations. Assertions are an important part of automated test scripts, so they must be taken seriously.

JMeter commonly used assertions mainly include Response Assertion, JSON Assertion, Size Assertion, Duration Assertion, Beanshell Assertion, etc. Here we only introduce the frequently used ones The JSON assertion.

JSON assertion

Used to make an assertion on the response content in JSON format.

The following figure adds a JSON assertion on an HTTP sampler:

The JSON assertion configuration items are:

• Assert JSON Path exists: JSON expression that needs to be asserted
• Additionally assert value: If you want to assert based on the value, please check
• Match as regular expression: If you want to assert based on regular expression, please check
• Expected Value: Expected value
• Expect null: check if the expectation is null
• Invert assertion: Invert

The "root member object" in the JSON path is always called $ , which can be expressed in two different styles: "dot–notation" (. No.) or "bracket–notation" ([] No.), such as $.message[0].name Or $['message'][0]['name'] .

Below to request http://www.kuaidi100.com/query an example, where $.message represents the response json object message , check Additionally assert value expressed according message to the determination value, Expected value is ok showing determination message value whether It is ok .

Run the script and view the results, you can see that the assertion is passed

The judgment conditions of the assertion mainly include: if the response result is not in json format, it fails; if the json path cannot find the element, it fails; if the json path finds the element, and the condition is not set, pass; if the json path finds the element but does not meet the conditions, Failed; if the json path finds the element and it meets the conditions, it passes; if the json path returns an array, iteratively judges whether there are elements that meet the conditions, pass if it has, and fail if it doesn't. Go back to "JSON Assertion" and check Invert assertion

Run the script and view the results, you can see that the assertion failed

Seven, timer

In performance testing, the pause time between access requests is called thinking time. In actual operation, the pause time can be the time spent in content search, reading, etc., and the timer is used to simulate this pause time. in:

• All timers in the same scope are executed before the sampler.
• If you want the timer to be applied to only one of the samplers, add the timer to the child node of the sampler.

JMeter timers mainly include: Constant Timer, Uniform Random Timer, Precise Throughput Timer, Constant Throughput Timer, Gaussian Random Timer (Gaussian Random Timer), JSR223 timer (JSR223 Timer), Poisson Random Timer (Poisson Random Timer), synchronization timer (Synchronizing Timer), BeanShell scripting timer (BeanShell Timer).

Fixed timer

Fixed timer, that is, configure the interval time between each request to a fixed value.

The following figure adds a fixed timer to a transaction controller:

After configuring the thread delay to 100 and 1000 respectively, run the script

Check the data in the table results, where 1 and 2 are the running results when configured as 100 milliseconds, and 4 and 5 are the running results when configured as 1000 milliseconds. You can see that the interval between 4 and 5 is significantly longer than the interval between 1 and 2. long time

Constant throughput timer:

The constant throughput timer is used to control the request to be executed according to the specified throughput.

The following figure adds a constant throughput timer to a transaction controller:

Configure the target throughput as 120 (note that the unit is minutes), and select "all active threads in the current thread group (shared)" based on the calculated throughput

Run the script and check the results, you can see that the throughput is basically maintained at 2/sec (120/60)

8. Pre-processor and post-processor

The preprocessor is to perform some operations before the sampler requests, and is often used to modify parameters, set environment variables, or update variables that are not extracted from the response text before the sampler requests to run.

Similarly, the post processor performs some operations after the sampler requests. Sometimes the response data of the server needs to be used in subsequent requests, and we need to process the response data. For example, to get the jwt token in the response and use it in subsequent requests for authentication, then the post processor will be used.

The above is an introduction to the main test components of JMeter, you can try to use it in actual combat. In the next article, we will explain the use of the MQTT plug-in in JMeter.