qileilove

18.7.7 BeanShell PreProcessor

The BeanShell PreProcessor allows arbitrary code to be applied before taking a sample.

For full details on using BeanShell, please see the BeanShell website.

The test element supports the ThreadListener and TestListener methods. These should be defined in the initialisation file. See the file BeanShellListeners.bshrc for example definitions.

Control Panel

Parameters

Before invoking the script, some variables are set up in the BeanShell interpreter:

• log - (Logger) - can be used to write to the log file
• ctx - ( JMeterContext ) - gives access to the context
• vars - ( JMeterVariables ) - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject("OBJ1",new Object());
• props - (JMeterProperties - class java.util.Properties) - e.g. props.get("START.HMS"); props.put("PROP1","1234");
• prev - ( SampleResult ) - gives access to the previous SampleResult (if any)
• sampler - (Sampler)- gives access to the current sampler

For details of all the methods available on each of the above variables, please check the Javadoc

If the property beanshell.preprocessor.init is defined, this is used to load an initialisation file, which can be used to define methods etc for use in the BeanShell script.

18.7.8 BSF PreProcessor

The BSF PreProcessor allows BSF script code to be applied before taking a sample.

Control Panel

Parameters

The script (or file) is processed using the BSFEngine.exec() method, which does not return a value.

The following BSF variables are set up for use by the script:

• log - (Logger) - can be used to write to the log file
• Label - the String Label
• Filename - the script file name (if any)
• Parameters - the parameters (as a String)
• args[] - the parameters as a String array (split on whitespace)
• ctx - ( JMeterContext ) - gives access to the context
• vars - ( JMeterVariables ) - gives read/write access to variables: vars.get(key); vars.put(key,val); vars.putObject("OBJ1",new Object()); vars.getObject("OBJ2");
• props - (JMeterProperties - class java.util.Properties) - e.g. props.get("START.HMS"); props.put("PROP1","1234");
• sampler - (Sampler)- gives access to the current sampler
• OUT - System.out - e.g. OUT.println("message")

For details of all the methods available on each of the above variables, please check the Javadoc

18.7.3 HTML Parameter Mask (DEPRECATED)

The HTML Parameter Mask is used to generate unique values for HTML arguments. By specifying the name of the parameter, a value prefix and suffix, and counter parameters, this modifier will generate values of the form " name=prefixcountersuffix ". Any HTTP Request that it modifies, it will replace any parameter with the same name or add the appropriate parameter to the requests list of arguments.

As an example, the username for a login script could be modified to send a series of values such as: 
user_1 
user_2 
user_3 
user_4, etc.

Control Panel

Parameters

18.7.2 HTTP URL Re-writing Modifier

This modifier works similarly to the HTML Link Parser, except it has a specific purpose for which it is easier to use than the HTML Link Parser, and more efficient. For web applications that use URL Re-writing to store session ids instead of cookies, this element can be attached at the ThreadGroup level, much like the HTTP Cookie Manager . Simply give it the name of the session id parameter, and it will find it on the page and add the argument to every request of that ThreadGroup.

Alternatively, this modifier can be attached to select requests and it will modify only them. Clever users will even determine that this modifier can be used to grab values that elude the HTML Link Parser .

Control Panel

Parameters

18.7.1 HTML Link Parser

This modifier parses HTML response from the server and extracts links and forms. A URL test sample that passes through this modifier will be examined to see if it "matches" any of the links or forms extracted from the immediately previous response. It would then replace the values in the URL test sample with appropriate values from the matching link or form. Perl-type regular expressions are used to find matches.

Control Panel

Spidering Example

Consider a simple example: let's say you wanted JMeter to "spider" through your site, hitting link after link parsed from the HTML returned from your server (this is not actually the most useful thing to do, but it serves as a good example). You would create a Simple Controller , and add the "HTML Link Parser" to it. Then, create an HTTP Request, and set the domain to ".*", and the path likewise. This will cause your test sample to match with any link found on the returned pages. If you wanted to restrict the spidering to a particular domain, then change the domain value to the one you want. Then, only links to that domain will be followed.

Poll Example

A more useful example: given a web polling application, you might have a page with several poll options as radio buttons for the user to select. Let's say the values of the poll options are very dynamic - maybe user generated. If you wanted JMeter to test the poll, you could either create test samples with hardcoded values chosen, or you could let the HTML Link Parser parse the form, and insert a random poll option into your URL test sample. To do this, follow the above example, except, when configuring your Web Test controller's URL options, be sure to choose "POST" as the method. Put in hard-coded values for the domain, path, and any additional form parameters. Then, for the actual radio button parameter, put in the name (let's say it's called "poll_choice"), and then ".*" for the value of that parameter. When the modifier examines this URL test sample, it will find that it "matches" the poll form (and it shouldn't match any other form, given that you've specified all the other aspects of the URL test sample), and it will replace your form parameters with the matching parameters from the form. Since the regular expression ".*" will match with anything, the modifier will probably have a list of radio buttons to choose from. It will choose at random, and replace the value in your URL test sample. Each time through the test, a new random value will be chosen.

Figure 18 - Online Poll Example

18.7.9 JDBC PreProcessor

The JDBC PreProcessor enables you to run some SQL statement just before a sample runs. This can be useful if your JDBC Sample requires some data to be in DataBase and you cannot compute this in a setup Thread group. For details, see JDBC Request .

See the following Test plan:

See Also:

• Test Plan using JDBC Pre/Post Processor

In the linked test plan,"Create Price Cut-Off" JDBC PreProcessor calls a stored procedure to create a Price Cut-Off in Database, this one will be used by "Calculate Price cut off".

Create Price Cut-Off Preprocessor

18.4.14 User Defined Variables

The User Defined Variables element lets you define an initial set of variables , just as in the Test Plan . Note that all the UDV elements in a test plan - no matter where they are - are processed at the start. So you cannot reference variables which are defined as part of a test run, e.g. in a Post-Processor.

UDVs should not be used with functions that generate different results each time they are called. Only the result of the first function call will be saved in the variable. However, UDVs can be used with functions such as __P(), for example:

HOST      ${__P(host,localhost)}   

For defining variables during a test run, see User Parameters . UDVs are processed in the order they appear in the Plan, from top to bottom.

For simplicity, it is suggested that UDVs are placed only at the start of a Thread Group (or perhaps under the Test Plan itself).

Once the Test Plan and all UDVs have been processed, the resulting set of variables is copied to each thread to provide the initial set of variables.

If a runtime element such as a User Parameters Pre-Processor or Regular Expression Extractor defines a variable with the same name as one of the UDV variables, then this will replace the initial value, and all other test elements in the thread will see the updated value.

Control Panel

Parameters

18.7.5 User Parameters

Allows the user to specify values for User Variables specific to individual threads.

User Variables can also be specified in the Test Plan but not specific to individual threads. This panel allows you to specify a series of values for any User Variable. For each thread, the variable will be assigned one of the values from the series in sequence. If there are more threads than values, the values get re-used. For example, this can be used to assign a distinct user id to be used by each thread. User variables can be referenced in any field of any jMeter Component.

The variable is specified by clicking the Add Variable button in the bottom of the panel and filling in the Variable name in the 'Name:' column. To add a new value to the series, click the 'Add User' button and fill in the desired value in the newly added column.

Values can be accessed in any test component in the same thread group, using the function syntax : ${variable}.

See also the CSV Data Set Config element, which is more suitable for large numbers of parameters

Control Panel

Parameters