How to write performance test scripts with JMeter

JMeter is probably the most widely used performance testing tool. How to write performance test scripts with JMeter?

1. Script making principles

When we write code, we usually have code specifications. For example, when writing java, there are java specifications, when writing python, there are python development specifications, and when doing tests, there are also test specifications. Then when we write JMeter, we also have JMeter script principles. What are the principles of making JMeter scripts?

The recommended specifications are:

• There can only be one Test Plan in a script. In the tree structure displayed by JMeter scripts in the client interface, the test plan is the root node, and there can only be one root node.
• There must be at least one thread group in the test plan. JMeter executes pressure tests from thread groups, so there must be at least one thread group in the test plan, and JMeter supports multiple thread groups.
• At least one sampler is required. If there is no sampler in the script, it is an empty script, which cannot simulate user requests and has no execution meaning.
• Every sampler must have assertions. Without assertions, it is impossible to judge whether the request is successful, let alone judge the validity of the pressure test.
• At least one listener is required. When executing a script without a command line, you need to view the execution results, and you need listeners such as aggregation reports; if you execute the script using the command line, you can generate a result file. The listener is used to display the execution results, and the execution results are used to analyze system performance.
• Disable viewing the result tree when not debugging. Viewing the result tree is generally used to debug scripts, but if it is used during stress testing, a large number of request return data will consume the resources of the stress testing machine, which may lead to a decrease in the performance of the stress machine.
• Reduce the use of unnecessary plugins. JMeter plug-ins are very rich, but improper use will affect the performance of JMeter itself, which will cause the pressure machine itself to become a pressure measurement bottleneck. For example, using a monitoring plug-in, a large number of server resource collection will affect the disk IO of the pressure test machine and consume other resources of the pressure test machine .

Following these rules allows us to develop good habits and avoid unnecessary mistakes.

Two, write Http script

1. Add HTTP request

2. Understand the configuration information

Description of HTTP request information (take JMeter 5.1 as an example).

As shown below:

• Web server: specify the protocol, the host address and port number of the HTTP request, do not need to add " http://", JMeter will add it automatically, the default port number of the general web service is 80, if the address you visit contains other port numbers in For this filling, the protocol fills in httpor according to the actual situation of the target address https.
• Client implementation:HttpClient4 There are two options of and in the implementation Java. HTTPClient4It can be regarded as a browser without an interface, through which resources of the Http protocol can be efficiently accessed; Javathe option is to use netthe tool classes in the package provided by the JDK to access.
• Method: There are 8 options in the drop-down list, the commonly used ones are POST and GET. GET is to connect the parameters in the browser address bar when submitting the request, and the length is limited (within 1 MB); POST submitting the request has no length limit, and users generally cannot see the submitted content, which is relatively safe. Other related options Please refer to the HTTP protocol yourself.
• Path: The access link with the host address part removed.
• Content encoding: The character encoding format, the default is iso8859, generally written UTF-8as , of course, you can also confirm with the developer.
• Automatic redirection: Automatic redirection can automatically turn to the final target page, but JMeter does not record the content of the redirection process. After checking this item, [follow redirection] will be invalid and cannot be associated.
• Follow redirection: The default option for HTTP requests, when the response codeis Yes 3xx, automatically jump to the target address. Different from automatic redirection, JMeter will record all request responses during the redirection process, and you can see the content returned by the server in the view result tree. If you choose this, you can associate the response content.
• Use KeepAlive: The default option for HTTP requests, corresponding to HTTPthe response cast Connection:keep-Alive.
• Use multipart/form-data for POST: This attribute is bound to the method POST, and it is generally used when uploading files.
• Header Compatible with Browsers: Browser Compatibility Mode, if you select [Use POST] multipart/form-data, it is recommended to also check this option.
• Send parameters together with the request: fill in the parameter and value area to be sent, the parameter item is filled in the form of key and value, the message body data is filled in in JSON format, the file upload item needs to fill in the file name, parameter name and MIME type, if If you don't know the MIME type, you can ask the developer or use a packet capture tool to check.

After filling in the above options, the HTTP single interface is almost ready. Here are three sample diagrams for GET, POST, and file upload for reference.

• GET request + parameters

• POST request + message body data

• POST request + file upload

3. Response assertion

In the scripting principle, it is mentioned that each request must have a response assertion, because if we do not judge the interface return, we cannot judge the validity of the request, so we cannot evaluate the authenticity of the performance test, so each request must To have a response assertion. Next we look at response assertions.

The assertion is to obtain the server response data, and then match the response data according to the assertion rules; if the match is normal, no prompt will be given, if the match is not found, JMeter will conclude that the request failed, and we will debug the script later You will see that the request name in the view result tree is in red font. There are many assertion components, and the response assertion I mentioned here can basically meet more than 80% of the assertion requirements.

First, we add an assertion, right click on the request name -> Add -> Assertion -> Response assertion:

Let's talk about the meaning of some parameters in the response assertion:

• Name and Comment: You can set it at will, and finally have business meaning.
• Apply to: application range, there are 4 options
  • Main sample and sub-samples: Matches include the current parent sampler and overrides the sub-samplers
  • Main sample only: The matching range is the current parent sampler
  • Sub-sample only: match only sub-samplers
  • JMeter Variable: Supports JMeter variable values ​​for matching
• Test field: Match different parts of the response data, there are 7 options.
  • Response text: the returned text content
  • Response code : the returned response code, for example, if the http request returns code [200], it means success
  • Response information: the response information returned, for example, the server returns [sucess] or [0000000], etc.
  • Response header: Returns the header information in the response
  • Request header: request header information
  • URL Sample: Matching URL Links
  • document (text): make a matching assertion on the content of the document
  • Ignore status: A request has multiple response assertions. When the first response assertion fails, ignore this assertion and proceed to the next assertion. If the next assertion succeeds, the request can be determined to be successful.
  • Request data: data that matches the request

4. Debug script

After writing the script, the next step is to debug the script. JMeter usually debugs the script by combining the view result tree, and you can see the server's return information from the view result tree component. Viewing the result tree will display every request of the sampler. If there are a large number of requests, it is recommended to turn it off during the stress test, otherwise it will consume more resources of the stress tester.

The component of viewing the result tree is generally only used to debug scripts. Here, it is also possible to view the parameters of the result tree under popular science.

• Name: custom content, the default is to view the result tree, it can be empty.
• Note: It is empty by default, it can be empty, and you can customize the content.
• All data is written into a file: the result can be saved, here is a path address.
• Text drop-down list: Displays the form list of the request content. This drop-down list includes Text, Xpath Tester, JSON, etc.
• Sampler Results: Displays the sampler results, the information here is similar to what is displayed on the browser.
• Request: display the content of the request form, and different samplers have different display formats.
• Response data: Display server response data, divided into Response Body and Response headers, provide query function, and can also distinguish case query and regular expression query.