JMeter User Guide--turn

JMeter User Guide

This article focuses on the status of the JMeter tools in the test and some of them are difficult to understand or unclear in the handbook, readers can understand these concepts through this article, and then according to their own needs to consult the specific use of JMeter components to complete the test work.

　1. Introduction

JMeter is a software for testing the C/S application of the desktop test (and not suitable for B/s structure, because it is difficult to simulate the user's action on the browser, if the need to test the application of B/s structure, you can choose selenium such tools), mainly used to complete functional testing, Stress testing, performance testing and other work.

The advantages of JMeter compared to other test software are as follows:

• It can help testers to easily simulate the environment in which multiple users access the server simultaneously (via thread Group), which can detect many problems that cannot be exposed in a single-threaded environment.
• A wide range of applications, almost all you can think of C/s application it can provide the corresponding support. JMeter has customized some of the application-specific test scenarios, such as testing the HTTP server, testing the database, testing the Java program, and so on. In addition, even if the jmeter does not provide a test environment for the current application, the user can customize it in the same way as yesterday BeanShell.
• Provides a rich logic controller that allows testers to easily write some relatively complex test logic.
• Provides a comprehensive set of variable mechanisms and configuration mechanisms to help testers reduce the burden of writing use cases and reduce duplication of effort.
• Provides a powerful monitoring build to help testers easily get test results statistics.

Disadvantages of JMeter:

• It is difficult to test for "correctness". Although JMeter provides an assertion mechanism, it is common for our tests to simulate multi-user operations, so that a user's response from a request is unpredictable (such as reading and writing a database table at the same time, although we can have each impersonated user store the information written in a common area, However, there may still be problems, because the time of the database writes and the time to write to the public area are not guaranteed to be synchronized, so it would be cumbersome to verify the correctness of the application by JMeter. Often we just use assertions to check for simpler and more important information, such as return codes.
• There is no good BeanShell testing mechanism. In JMeter, BeanShell is a very important part, because JMeter custom test scenarios are often somewhat out of the way with our applications, and you need to use BeanShell to accomplish some of the things JMeter can't do. However, BeanShell is also needed to ensure correctness, and jmeter does not provide good support for BeanShell testing.
• Through the above analysis, it can be found that jmeter is more suitable to find out the problems of the tested system in the concurrency environment.

　　2. Basic structure of the JMeter test case

The basic structure of the JMeter test case is a tree structure similar to Windows Explorer, where each node in the tree is represented by an element, so a complete jmeter test case is actually made up of one element, and the test execution process actually is the process by which these elements are executed. In general, JMeter will traverse these elements in a depth-first way, while for elements of the same layer, JMeter will execute from top to bottom.

There are many kinds of elements in the jmeter, and each element has a specific meaning in the tree structure, in order to facilitate understanding, these elements from the structural nature of the three main categories:

The first class is the control element, which usually appears at the side of the tree structure, which is used to control the execution of the first layer of the element (note, not all of its elements), such as controlling their sequencing, or executing or not executing which. With this type of element we can easily dynamically control the execution of test cases, which are similar to the if-else, switch, while and other logical control statements that become languages.

The second class is an action-based element, which is the element that actually initiates the test request, usually at the bottom of the tree structure, where each action element represents a request-response process, and their order of execution is usually managed by the controlled element.

The third category is the configuration element, which can only be used as a leaf node in a tree structure, and is applied to its scope (the rule of scope is as follows: If the configuration element is under a control element, it is scoped to all descendants under the control element; If the configuration element is under an action element, It has a certain effect on all action elements that have a scope of only this action element. These effects vary depending on the type of element, such as changing the parameters of the element, delaying the request time, adding some action before and after the request, and listening to the request and its corresponding. In addition, if an action element is affected by more than one of the same configuration elements, the effect of these configuration elements will be merge,merge depending on the function type of the element (see section 3rd).

　　3. Elements in the JMeter

Functionally speaking, the elements of JMeter are divided into eight categories and two special elements. These elements are described here from the use of the context, as to what the specific function of each element will need to see the help of JMeter (the method is to click on the unknown element, and then select the Assistance menu under the "Assist" option).

• The Test plan element: A control-type element. Can exist only at the root node of a tree structure. It represents the entire test scenario, where testers can set up some global content, such as globals (note that global variables are Thread local, see section 4th), classpath configuration (if you want to call your own Java class in JMeter), and so on.
• The Thread group element: A control-type element. Can exist only under the test plan element. It represents a group of users who behave similarly, and usually we put the action of a class of users under the same thread group, so that we can simulate many of these users. Here you can configure the number of impersonated users (number of threads), number of cycles, execution time, and so on.
• Logic controller: A control element. Can exist in any seat under the thread group. It is used to control the execution of its underlying elements, and JMeter provides many elements of the logic controller type that allow us to implement basic logic in testing.
• Config element: the configuration elements. These elements are used to change the configuration of all action elements within their scope, and the use of such elements can reduce duplication of effort in the writing of test cases, such as allowing an HTTP request defaults element to configure the host address and port number of HTTP requests in all use cases. This eliminates the need to make such a configuration in each action element. This value is used when the merge occurs, if only one of the config element elements in a domain has a value, and if a field has multiple config element elements that have values, the config closest to the action element is used The value of element elements (closest to the configuration element under the Action element node).
• Timer: a configuration element. If you want to control how often requests are issued, you should defer these requests using a timer. When the merge occurs, the time of all the timer is added.
• Pre Processor: Configuration element. Used to modify all affected action elements according to certain conditions. When the merge occurs, the pre processor will be executed sequentially, farthest from the action element.
• Post Processor: Same as pre Processor, just after the action element is used to extract the required information from the response.
• Assertions: configuration element. Used to assert the result of an action element within its affected range, such as the ability to assert a return code for some HTTP requests, and the system will log the error if it does not pass. When the merge occurs, all assertion will be judged.
• Listener: Configuration element. Used to listen for all the action elements in its affected range, the test result data is mainly generated by such elements, so they are very useful. When the merge occurs, all listener monitoring actions are performed.
• Sampler: Action-type element. Represents a request-response process, which is the initiator of the action in the test case and the primary element of the test case. JMeter many kinds of action elements according to different applications, if the user feels still not enough to use even BeanShell sampler to write their own actions.

4. Variables in the JMeter

Sometimes we want to send thousands of random requests, or want the content of this request to depend on the previous requests, then we need to use the variables in JMeter (note that variable is not the property), so that you can use variables to configure each request, This makes it possible for the same sampler to make different requests each time.

When using variables, it is important to note that the variables in JMeter are thread independent (thread Local), that is, although we have defined n variables, there is a mirror of the n variables in each thread, and they are independent and non-interfering with each other.

When we want to use variables, we first need to create the required variables. There are many ways to create variables in JMeter, one way is to define global variables through test plan (for all thread Group, which is thread independent), or through the user Defined in config element element to define local variables for different thread groups (note that the variables defined in the User Defined element are used for the entire thread group, regardless of where the element is placed, it is a very special configuration element), and when we apply the This variable is also created when an assignment of a variable that is not created (as described later in the assignment). In fact, JMeter's source code uses map to implement the variables, so these properties are not difficult to understand.

When we want to refer to a variable somewhere, we can get the value of the variable by ${the syntax of the variable name}. Note that if the variable is not defined, then the equation is treated as a normal string.

There are many ways to modify a variable's value, either by BeanShell or by some specific element in JMeter (for example, CSV Date Config Element), or by using the JMeter function to define a variable (how to do that, See the following section).

Normally if we want to make a different request in each loop, we can put the possible request content in a file and have the CSV Date Config element get the corresponding value from it and give it to the variable, or through the BeanShell Sampler uses the script to customize the value of the variable (note that you cannot use the BeanShell preprocessor in the pre processor to customize the variable, and the pre processor is used to modify the domain in the request, which occurs after the request is created. That is, if we define a variable in BeanShell preprocessor and then write it in the request domain, the result is that JMeter first sees a variable that is not assigned, and then treats the ${variable name} as a string and then executes BeanShell Preprocessor. This is where many people are prone to make mistakes, or you can use the pre processor to directly modify the domain in the request, and you can write a jmeter function in the request domain to generate the desired value directly.

In some applications, we want the content of the next request to depend on the previous request. Then we can extract the useful information from the response via post processor and assign it to a variable for the next use.

5. properties in JMeter

There are property concepts in jmeter, and they usually have two uses: First they represent the configuration information for JMeter (there are bin/in the JMeter directory. Jmeter.properties); second, they can be used as memcache to enable communication between threads (the get and put methods of properties are thread-safe). Property acquisition, definition, modification is generally done through the JMeter function, of course, can also be through the powerful BeanShell.

Often when we want to have some kind of dependency between multiple threads, we can use the property, but that's not much, because most of the users we simulate are independent of each other, and they shouldn't know what others are doing.

In addition, we can configure some constants in the Jmeter.properties file to be used at any time in the test

　6. Functions in the JMeter

Sometimes we need to perform some simple operations (such as generating a random number) and do not want to write BeanShell code, so consider using some of the functions built into JMeter. These functions are typically formatted with the ${__ function name (parameter 1, Parameter 2 ...)}, and they have two ways to return their execution results: one is to return directly, that is to say JMeter will replace the function's string with the return result of the functions after executing the function (for example, assuming ${__ Method ()} returns to world, so if we write Hello ${__method} in the field, the actual result is Hello world. The other is when a variable is specified by a parameter (usually the last one), jmeter the execution result into that variable. Depending on the function, the JMeter provides a powerful function builder (the Function Helper dialog option in the Options menu), which lists all the methods and possible functions, and has handy help documentation, and The generator can be used by the user to generate the required functions.

It is necessary to emphasize again jmeter the process of reading a field (any space that can fill in the content): when JMeter reads a string in a field, it first checks to see if there is a match ${...} The string, if any, to parse the ${recursively ...} Until the string in parentheses no longer contains parentheses. Then parse this ${...} whether it is a function or variable, and if so overwrite the original ${with its result ...} string until the entire string has been parsed. For example, when you enter Hello ${__method (${num},2)} In the input field, and the value of the NUM variable is 1, the string is first converted to Hello ${__method}, and then because the value of ${__method is world, The content in this field will eventually be Hello world.

After mastering the above content, we can basically apply the functions and variables in JMeter, and what the reader needs to do is to look at the manuals to see what functions the functions provide. (Note that some functions cannot be placed in special domains, such as ${__threadnum} can not be placed in the variable definition of test plan or in the variable definition field in user Defined element, the reason is very clear in the manual)

　7. The BeanShell in JMeter

In most cases, the functionality provided by JMeter is not enough for us to use, and there may be some more complex logic in our test cases that are not implemented by simple functions, Then we have to use the powerful BeanShell (JMeter has some elements specifically for adding BeanShell scripts, such as BeanShell Sampler, in different places in the test). Unfortunately, JMeter's manual does not describe how BeanShell is used, but instead pushes all the responsibilities to BeanShell's website, and BeanShell's website does have a complete BeanShell user manual, But we don't want to learn a scripting language for testing, so here are some simple applications for BeanShell, and if you don't feel enough, then look at more complex applications.

　　7.1 BeanShell Get started quickly

BeanShell is a Java-oriented scripting language, so if you want to use him without BeanShell at all, write Java code directly. The only thing to note is that BeanShell supports variables of a type, that is, without specifying a variable type, as long as he is assigned a value, BeanShell knows the type of the variable. Regardless of where the type variable is used, the subsequent code can access the variable, which is different from the strongly typed Russian variable. For example:

View Plaincopy to Clipboardprint? Arbitrary code block { y = 2; Untyped variable assigned int x = 1; Typed Variable assigned } print (y); 2 print (x); error! X is undefined. Arbitrary code block { y = 2; Untyped variable assigned int x = 1; Typed Variable assigned } print (y); 2 print (x); error! X is undefined.

　7.2 JMeter built-in variables

JMeter has built-in variables in its BeanShell that allow users to interact with JMeter, the main variables and how to use them as follows (JMeter document does not explain this part in detail, This will also indicate which of the classes they correspond to in Javadoc):

• VARs: This variable actually refers to the local variable container in the JMeter thread (which is essentially map), so you can access the variables in the jmeter through the put and get methods. This variable is the most useful of all built-in variables, and it is a bridge between test cases and BeanShell interactions. Corresponds to Org.apache.jmeter.threads.JMeterVariables
• Props: This variable refers to the configuration information for JMeter, which is used in a similar way to VARs, but can only be put in a string type value, not an object. Corresponds to Java.util.Properties.
• CTX: This variable refers to the context of the current thread, and in theory we can control almost everything related to the current thread, but this requires the user to be very familiar with JMeter's source code. Corresponds to Org.apache.jmeter.threads.JMeterContext.

　　7.3 Using Java classes in BeanShell

Sometimes we want to send a few requests, and the content of these requests is implemented by a Java class, then we need to let JMeter call this Java class, and the only way is through BeanShell.

In order to be able to load the Java class, we first need to add the class Path of the custom Java class in the test plan, then we can import the Java class in BeanShell and finally put the obtained content into the VARs variable. This allows you to get information about the variable in a way that is ${...}.

For example, a COM.LINHAO.A class was created under the/root/java folder, and the class has a method hello () returns a "Hello World" string, so if you want to use the string returned by this method in the request, do the following:

First add classpath to/root/java under test plan

Then add a BeanShell sampler before the request and write the following code:

View Plaincopy to Clipboardprint? Import COM.LINHAO.A; Vars.put ("word", A.hello ()); Import COM.LINHAO.A; Vars.put ("word", A.hello ());

Finally, write ${word} where you want to use the string, so that eventually the field will be replaced with the Hello World

　　Commissioning of BeanShell under 7.4 jmeter

BeanShell is also code, there may be errors, and JMeter is also a graphical interface of the program (there are command-line mode, but not the same as in the design use case phase), so many times the use Case designer is not able to determine whether certain variables in BeanShell are correct. An easy way to do this is to use BeanShell to create a dialog box and then display the value of the variable you want to detect in the dialog box. The code is as follows:

View Plaincopy to Clipboardprint? JFrame. Frame. = new JFrame (a); A is a variable to being checked Frame.setvisible (TRUE); JFrame. Frame. = new JFrame (a); A is a variable to being checked Frame.setvisible (TRUE);

This allows you to know the value of variable a when the test is executed here.

Although BeanShell is very powerful, it is a scripting language after all, so if the generation logic of test parameters is complex, then the main logic should be placed in the Java class, and then let BeanShell to invoke, BeanShell only to handle some of the simpler operations

8 , the common functions of jmeter use are introduced

"_random" function

Function: This function is to randomly read data substitution parameters from a number segment, and can take advantage of a test script that requires multiple data records to be added and that some fields need to be unique, the randomly generated parameter is a number

Function: can be used to implement parameterized HTTP request sent parameters, so that the JMeter run time parameterized parameters in each thread to go to a different random number. It is convenient to use this function if a parameter cannot be stored in the database each time the request is sent.

Use:

1. Click "Options" in JMeter, select "Function Assistant Dialog" (or use the shortcut key "Ctrl+f") and select "_random" in the drop-down box "Select a feature".

2. Configure the "_random" function, the first parameter is "a range of minimum", that is, the minimum value of the random number to be taken, we set to 1, the second parameter is "a range of maximum", that is, the maximum number of random numbers to be taken, we set to 100; the third argument is "function name". That is, to store the values used in other ways in the test plan, we set it to Random. After setting the above three parameters, click the "Generate" button, this will generate a string "${__random (1,100,random)}" in the bottom of the dialog box, in the script we write, find the parameter to replace, the value of the previous generated string is OK, Then each time it runs, this parameter becomes a random number between 1 and 100.

　　"_counter" function

Function: This function is a counter, used to count the number of functions used, it starts from 1, each call this function will automatically add 1, it has two parameters, the first parameter is a Boolean, can only be set to "true" or "FALSE", if true, then each user has its own counter, It can be used to count how many times each thread has executed the song. If it is false, use the global counter to count how many times the test runs together. The second argument is the function name

Format: ${__counter (False,test)}

Use: We copy the parameters generated by the "_counter" function to a parameter, if true, each thread is counted, the maximum number is the number of loops, and if false, all threads are counted together, the maximum number is the number of threads multiplied by the number of loops

　　"_time" function

Function: JMeter the runtime takes the current time to the variable, using this function, you can add a parameter to the function, and then use the parameter as a query condition query, and then as an assertion, which can make the assertion more accurate, because the time of the real-life changes, the use of this method, it is important to note that To add a global user parameter first, there is a description in the assertion operation.

Format: ${__time (Mmddmmss,test)}

Use: Add jmeter time function, select Options--function assistant, and select the __time function, as shown in:

Enter a value of "Mmddhhmmss" in "Ormat String for SimpleDateFormat (optional)", indicating the day of the month and seconds.

Then, click Generate, and the time parameter is generated.

　　"_intsum" function

Function: Used to calculate the and of multiple integers, can be calculated as a positive integer and a negative integer, and it has n parameters, at least 3 parameters, up to unlimited. The last argument is the function name, and the other arguments above are the integers to be summed. This function displays only 3 parameters in the Function dialog box, if you want to calculate multiple integers, you can add the parameters, but the last parameter must be the function name. The added arguments are followed by the function name, which requires us to manually put the function Name argument to the last one.

Format: ${__intsum (1,100,test)}

stringFromFile

1. Function: ${_stringfromfile (filename. dat)}

2. The format of the external file must be. dat

3. The default read location is/bin, you can also set the file storage path, such as: ${_stringfromfile (E:user.dat)}, from the E-drive to read the data in the User.dat file

4. Every time you read a line in a file

5. If I have multiple user files and want to read them together, the filenames are User1 user2. Function write: ${_stringfromfile (user#.dat,,1,2)}, read User1 and User2 files from the default directory

6. If a file wants to read multiple times, it can be written as: ${_stringfromfile (User.dat,,, 2)},user1 file read 2 times (source www.iocblog.net)

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

JMeter User Guide--turn