Element _ Software Test in JMeter test plan

Reprint: http://www.51testing.com/html/10/n-3725610.html
Elements of the         test plan (elements of a test plans) This section describes the different parts of the test plan. 　 　The minimum test will include a test plan, a thread group, and one or more samplers. 1. Test plan the test Plan object has a checkbox called "Functional Testing," which, if selected, causes JMeter to record data for each sample returned from the server. If you select a file in the test listener, the data is written to the file. This is useful if you are performing a small run to ensure that the JMeter configuration is correct and that your server is returning the expected results. As a result, the files will grow rapidly and the performance of the JMeter will be affected. 　　If you are conducting a stress test (off by default), this option should be turned off. 　　This option does not make any difference if you do not record data to a file. 　　 You can also use the configuration button of the Listener (listener) to determine which fields to save. 2. The thread group thread group element is the starting point for any test plan. All controllers and samplers must be under the thread group. Other elements, such as listeners, can be placed directly under the test plan, in which case they will apply to all thread groups. As the name suggests, the thread group element controls the number of threads that JMeter uses to execute tests. Control for thread group allow: · Set the number of threads: Set Thread Count  set The ramp-up period: Set transition  set the "Times of the" to execute the TE ST: Set the number of times to execute a test each thread will execute the test plan completely independently of the other test threads. 　　Multiple threads are used to simulate concurrent connections to server applications. This transitional period tells JMeter how long it will take to "accelerate" to the total number of threads selected. If you use 10 threads and the transition period is 100 seconds, then JMeter will take 100 seconds to start all 10 threads and run. After the previous thread starts, each thread will start with 10 (100/10) seconds. 　　If there are 30 threads and a rise period of 120 seconds, each successive thread will be delayed by 4 seconds. It will take long enough to avoid the workload being too large at the start of the test, short enough, and the last thread to run before the first thread completes (unless someone expects it to happen). 　　Starting with the number of threads added, adjust up or down as needed. By default, the thread groupis configured to loop through its elements once. The thread group also provides a scheduler. Click the check box at the bottom of the thread Group panel to enable/disable additional fields in which you can enter test duration, startup latency, start and end times for the run. You can configure duration (in seconds) and start delay (seconds) to control the duration of each thread group and the number of seconds to start. When the test is started, JMeter waits for the thread group to start and the duration (in seconds) to run the configuration before the start delay (seconds). 　　Note that these two options overwrite the start and end times. or (although not very flexible), you can use the other two field start and end times. When the test begins, JMeter will wait as necessary until the start time is reached. 　　 At the end of each loop, JMeter checks to see if the end time has been reached and, if so, stops running, or the test continues until the iteration limit is reached. 3, the controller (controllers) JMeter has two kinds of controllers: Sampler and logic controller. 　　The processing of these drive tests. The sampler tells JMeter to send the request to the server. For example, if you want to jmeter send an HTTP request to add an HTTP request sampler. You can also customize the request by adding one or more configuration elements to the sampler. 　　For more information, see: Sampler. The logic controller lets you customize JMeter decide what logic to use when sending a request. For example, you can add a staggered logic controller between two HTTP request samplers. 　 　For more information, see: Logical Controller. 3.1, Sampler (samplers) Sampler told JMeter to send a request to the server and wait for a response. They are processed according to the order in which they appear in the tree. 　　The controller can be used to modify the number of repetitions of the sampler. 　　The JMeter Sampler includes:  ftp request  http request (also available for soap or rest Webservice) &NBSP;JDBC request  java Object Request &NBSP;JMS request  junit Test Request &NBSP;LDAP request   Mail request   operating system process request &NBSP;TCP request each sampler has several properties that can be set. 　　You can customize the sampler by adding one or more configuration elements to the test plan. If you want to send multiple requests of the same type, such as HTTP requests, to the same server, consider using the default configuration element. Each controller has one or more defaults elements (see below).　　Remember to add a listener to the test plan to view and/or store the results of the request to disk. If you are interested in having JMeter perform a basic validation of your request's response, add an assertion to sampler. For example, when a stress test Web application, the server may return a successful "HTTP response" code, but the page may have errors, or it may be missing parts. You can add assertions to check for certain HTML tags, common error strings, and so on. 　 　JMeter allows the use of regular expressions to create these assertions. 3.2. The logical controller (Logic controllers) logic controller lets you customize the logic that jmeter determines when it wants to send a request. The logical controller can change the order of requests from child elements. 　　They can modify the request themselves, causing JMeter to repeat the request, and so on. To understand the impact of a logical controller on a test plan, consider the following test tree: test plan   thread group   only one controller logon request (one HTTP request) · Load Search page (http sampler) · Alternate controller Search "A" (HTTP Sampler) search "B" (HTTP sampler) HTTP request default (configuration component)  http default request (Configuration component)  cookie Manager (configuration symbol) The first thing about this test is that you log in The request will be executed only for the first time. The subsequent iterations will skip it. 　　This is due to the effect of once only Controller (one controller only). After logging in, the next sampler loads the search page (imagine a Web application that a user logs in to, and then goes to the search page to search). 　　This is just a simple request, not filtered by any logical controller. After loading the search page, we are going to search. In fact, we want to do two different kinds of searches. However, we want to reload the search page itself between each search. We can do this with 4 simple HTTP request elements (load search, search "A", load Search, search "B"). Instead, we use the Interleave controller controller to pass a child request each time through a test. It keeps the sort (that is, it does not randomly pass one, but "remembers" the location of its child elements). 　　Inserting two child requests may be overused, but there may be 8 or 20 child requests. Note that the HTTP Request defaults belongs to Interleave Controller. Suppose "search A" and "Search B" share the same path information (HTTP request specification includes domain, port, method, protocol, pathand parameters, as well as other optional options). This is meaningful-both are search requests and hit the same back-end search engine (such as servlet or Cgil-script). Instead of using the same information to configure two HTTP samplers in the Path field, we can abstract this information into a single configuration element. When the Interleave controller passes a request from search A or search B, it fills in white space from the value of the HTTP default request configuration element. Therefore, we leave the path fields of these requests blank and place the information in the configuration element. 　　In this case, this is a small benefit at best, but it shows this feature. The next element in the tree is another HTTP default request, which is added to the thread group itself. The thread group has a built-in logical controller, so it uses this configuration element, as described above. It fills in any requested space that passes. In a Web test, it is useful to leave the field fields in all HTTP sampler elements blank, instead, put the information in the HTTP default request element and add it to the thread group. By doing this, you can test your application on different servers by changing one of the fields in your test plan. 　　Otherwise, you must edit each sampler. The last element is the HTTP cookie manager. All Web tests should add a cookie manager-otherwise jmeter will ignore cookies. 　　Adding it through the thread group level ensures that all HTTP requests will share the same cookie. Logical controllers can be combined to achieve a variety of results. 　　 See the built-in Logical controller list (built-in Logic controllers.). The 3.2.3, test fragment (test fragments) test fragment element is a special type of controller that exists in the test plan tree at the same level as the thread group element. 　　It differs from the thread group because it is not executed unless referenced by the module controller or the containing controller. 　 　This element is used purely for code reuse in test plans. 4, listeners (Listeners) when the JMeter is run, the listener provides access to the information jmeter the test case. The result of the diagram is that the listener paints the response time on the diagram. The view result tree listener displays detailed information about the sampler request and response, and can display the basic HTML and XML representations of the response. 　　Other listeners provide summary information or aggregation information. In addition, listeners can direct data directly to a file for later use. Each listener in the JMeter provides a field indicating the file to store the data. There is also a configuration button that can be used to choose which fields to save and whether to use CSV or XML format. 　　Note that all listeners hold the same data; the only difference is how the data is rendered on the screen. You can add listeners anywhere in the test, including directly under the test plan. 　　They collect data only from their level or below their level of elements. 　　 JMeter here are the listeners. 5, Timer (timers) By default, JMeter threads execute samplers sequentially without pausing. We recommend that you specify a delay by adding an available timer to the thread group. 　　If you do not add a delay, JMeter can overwhelm the server by making too many requests in a short period of time. 　　The timer will cause the jmeter to delay a certain amount of time within the range of each sampler. If you choose to add more than one timer to the thread group, JMeter will use the sum of the timers and pause the time before executing the samplers applied by the timer. 　　Timers can be added as samplers or as child elements of the controller to limit the application's samplers. 　　 To provide a separate location in your test plan, you can use the test action sampler. 6, assertion (assertions) assertion allows you to assert that the server you are testing is returning results. 　　By using assertions, you can basically determine whether the results returned by your program are the values you expect. 　　For example, you can assert that the return result of a query will contain some specific text, that a particular text can be a regular expression in the Perl language, or it can be a part of the return result, or the entire return value. You can add assertions to any sampler (sampler), for example, you can add an assertion to an "HTTP request" to check the text "</HTML >." JMeter then checks whether the text ' </HTML > ' exists in the HTTP response. 　　If JMeter cannot find the text, it is marked as a request failure. 　　Note: The assertion applies to all samplers, but to limit the assertion to a specific sampler, add the assertion as a child element of the sampler. 　　 To view the assertion results, add an "assertion result" to the thread group, and the assertion that the failure will now be in the tree view and the table listener, and will be counted to the error rate of the summary, summary report. 7, Configuration components (Configuration Elements) a configuration element and sampler close cooperation. 　　Although it does not send a request (except for the HTTP (S) test script logger), it can add or modify requests. A configuration component can only be accessed from the tree branch of the drop element, for example, if you put an "HTTP cookie Manager" in a simple controller, only in a simple controller, CThe Ookie Manager can access the HTTP request controller (see Figure 1). 　　The cookie Manager can access the HTTP request "Page 1" and "Page 2" instead of "Page 3". In addition, the configuration components in the tree branch have precedence over the same elements in the parent branch. For example, we define two HTTP request Defaults symbols: HTTP request defaults 1 and HTTP request Defaults 2, because we put the HTTP request default value of 2 on a loop controller. Therefore, only "page 2" can access it. 　　 Other HTTP requests will use the HTTP request default value of 2 because we put it into the thread group (the "parent" of all other branches). Figure 1 The test plan shows the accessibility of the configuration component note: There is a difference between "User defined variables" in the configuration component and other components. It is processed at the beginning of the test, regardless of where we put it. 　　 For simplicity, it is recommended that it be placed at the beginning of the thread group. 8. The predecessor processor (Pre-processor Elements) preprocessor performs some action before executing the Sampler (sampler) request. If a preprocessor is attached to a sampler component, it is executed before the sampler component is run. 　 　A preprocessor is typically used to modify the settings of a sampling request before running, or to update a variable that is not extracted from the response text. 9, after the processor (Post-processor Elements) after the sampler request completes, after the processor performs some operations. If a post processor is attached to a sampler component, it will be executed after the sampler component is run. The post processor is typically used to process response data, usually from which the value is extracted.