JMeter---Components in the test plan

1. Thread Group

A thread group component is the starting point for any test plan. All components in a test plan must be under a thread group. As the name implies, thread group components control the number of threads that are used when JMeter executes your test plan. The control of the thread group allows you to:

• Set the number of threads
• Set ramp-up Period
• Set the number of times the test will be executed

Each thread will run the test plan completely independently, with no interference. Multiple threads are used to mimic concurrent access to the server.

Ramp-up period indicates the time JMeter used to reach the full selection of threads. If 10 threads are selected and ramp-up period is 100 seconds, JMeter will use 100 seconds to get 10 threads up and running. Each thread will start after 10 (100/10) seconds after the previous thread started. If there are 30 threads and the ramp-up period is 120 seconds, then the successive threads are 4 seconds apart.

Ramp-up takes long enough to avoid generating too much load at the start of the test, and there is a short enough time for the last thread to run before the first thread ends. (unless you want to do that)

Start ramp-up = number of threads + required number of adjustments

By default, the thread group is configured as an indeterminate loop to execute the components underneath it. In addition, you can set the number of times a thread group loops before it ends. If the number is set to 1, then jmeter only executes the test plan once before stopping.

1. Version 9 introduces a test run line scheduler, click the checkbox below the Thread Group panel to display two additional fields, and you can enter the start and end times of a run. When the test starts, if the scheduler is set, JMeter waits until the start time. At the end of each cycle, JMeter will check to see if the end time is reached, and if so, stop running, or the test continues until the repeat limit is reached.

In addition, the user can also set the "duration" and "Start delay" two parameters. It is important to note that the "Start delay" invalidates the "Start time" and that "duration" invalidates the "End time".

2.Controller

The jmeter has two types of controllers: Samplers and logic controllers.

The sampler instructs JMeter to send a request to a server. For example, if you want JMeter to send an HTTP request, add an HTTP requestor. You can add one or more configuration components to a sampler to customize the request. See the sampler for more information.

Logic controllers allow you to customize when JMeter send requests. For example, you can add an alternating (Interleave) logical controller to rotate between two HTTP request samplers. See the logical Controller for more information.

2. 1 Sampling device

The sampler instructs JMeter to send a request to the server. JMeter currently has the following samplers:

• FTP request
• HTTP request
• JDBC Request
• Java Object request
• LDAP request
• SOAP/XML-RPC Request
• Web Service (SOAP) requests (Alpha Code)

Each sampler has several properties that can be set. You can add one or more configuration components to the sampler to further control the sampler. In addition, JMeter sends requests in the order that you add samplers to the tree.

If you want to send multiple requests to a server of the same type (for example: HTTP requests). Consider using a default configuration element (Defaults configuration element). Each controller has one or more default components (see below).

Remember to add a listener to the thread group to view and/or store the request results to disk.

If you want JMeter to do basic validation on the requested reply, add an assertion to the request controller. For example, when you stress test a Web application, the server returns a successful "HTTP reply" code, but the page may have errors or missing content. You can add assertions to check for certain HTML tags, generic error strings, and so on. JMeter allows you to create these assertions using regular expressions.

2. 2 Logic Controller

Logic controllers allow you to customize when JMeter send requests. The logical controller may wrap the following sub-components: Sampler (Request), configuration element, other logic controller. The logical controller is able to change the order of requests in its child components. They can modify the request themselves, make the JMeter repeat the request, and so on.

To understand the impact of a logical controller on a test plan, assume the following test tree:

This test first executes the login request, which is executed only once during the entire test. Repeated execution of the following will skip it. This is due to the use of the controller only once.

Once logged in, the sampler then loads the search page (imagine a web app where a user logs in and then opens the search page to search for information.) This is just a simple sampler request and is not filtered with any logic controller.

After loading the search page, we wanted to search, in fact, we wanted to do two different searches. However, we want to reload the search page between each search. We can use four simple HTTP request components (Load search page, search ' A ', load search page, search ' B '). Alternatively, using an alternating controller, it passes a sub-request to this test at a time. By the order in which the sub-elements are arranged. Alternating 2 sub-requests can be a bit overqualified, but if you have 8 or 20 sub-requests, it's easy to use it.

Note that the HTTP Mezhin request is in the alternate controller. Imagine that "search a" and "Search B" share the same directory information (a canonical HTTP request includes domain, port, method, protocol, path, parameters, and some other optional options) This makes sense-two search requests, Use the same background search engine (we can say that it's a servlet or a CGI script). Rather than configuring two HTTP samplers that use the same path information, we are able to extract the information to a single configuration component. When the alternate controller passes the request from "search a" to "search B", it fills in the value of the HTTP Mezhin request configuration component in the blank value. So we put the requested path through the information and put the information in the configuration element. In this case, just take advantage of a little bit of it and later will discuss it again.

The next element of the tree is another HTTP Mezhin request, which is placed in the thread group alone this time. The thread group has a built-in logic controller, which can be used to configure components exactly as described above. It will fill in an empty space to pass any request. It is especially useful when testing the site to empty all of your HTTP sampler domain values, placing those messages in the HTTP Mezhin request element, and then adding them to the thread group. By doing this, you can test your app on a different server by simply changing a value in your test plan. Otherwise, you have to modify each value once per sampler.

The last component is the HTTP cookie manager. You should add a cookie manager to all site tests, otherwise jmeter will ignore cookies. By adding it to the thread group layer, we can ensure that all HTTP requests can share the same cookie.

You can add multiple logical controllers to achieve a variety of different results. See the built-in logic control list.

JMeter---Components in the test plan