is one of the most advanced JMeter built-in components. It supports Java syntax and extends it with scripting features like loose types, commands, and method closures. If your test case is uncommon and implementation via embedded JMeter components becomes tricky or even impossible, BeanShell can be an excellent option to achieve your objectives.
BeanShell entities in JMeter have access to both internal JMeter APIs and any external classes that are loaded into the JMeter classpath (be sure to drop necessary jars into /lib/ext folder of your JMeter installation and place all necessary “import” statements at the top of your BeanShell scripts).
JMeter provides the following BeanShell-enabled components:
- Beanshell Sampler – A standalone sampler
- Beanshell PreProcessor – A pre-processor to another sampler that is executed before the sampler and can be used for prerequisite setup (i.e. to generate some input).
- Beanshell PostProcessor – A post-processor that is executed after the sampler and can be used for recovery or clean-up.
- Beanshell Assertion – An advanced assertion with full access to JMeter API. Java conditional logic can be used to set the assertion result.
- __Beanshell Function – A JMeter Function that allows execution of custom BeanShell code during a sampler run.
Changing JMeter Variables on the Fly
Assume you have a user-defined variable called "continue" with the value of "true" somewhere in the While loop. You can set it to "false" with this simple command:
Convert JMeter Variable to a JMeter Property
Given a variable "some_variable" you must cast JMeter Property with the same name to use, (such as in another thread group).
Passing Cookies between Thread Groups
Assuming the HTTP Cookie Manager
is enabled, the following code can convert JMeter cookies into JMeter properties.
After all cookie information is stored as a JMeter property, you can reconstruct cookies in another thread group.
Stopping the Test in Case of Failure
Imagine you have a 48-hour SOAK test scheduled to run over the weekend that explicitly depends on a CSV data set config element that requires source CSV files to be present. You tested it with one user and one loop on your developer machine, and it worked fine. However, when you upload it to your production environment and run headless, JMeter fails to locate the CSV file and all 48 hours are wasted. To avoid this situation, use the following check in the very first BeanShell Sampler:
All of the Above + BlazeMeter
This example demonstrates a simple BeanShell use case with BlazeMeter under the following TestPlan structure:
- Thread Group (1 user, 1 second ramp-up, forever)
- While Controller with empty condition (forever)
- Counter (start – 1, increment – 1, reference name – counter)
- HTTP request (server name – example.com)
The BeanShell post-processor tests if the HTTP sampler response contains the example domain. If it doesn’t, the test will fail and stop immediately. If it does, the test will stop after the third iteration. In both cases, something is appended to the jmeter.log.
JMETER PRE-DEFINED BEANSHELL VARIABLES
The next section contains the most important and most frequently used JMeter API classes exposed to BeanShell components. If you look at the bottom of BeanShell sampler component, you’ll see following:
“The following variables are defined for the script:
SampleResult, ResponseCode, ResponseMessage, IsSuccess, Label, FileName, ctx, vars, props, log”
ResponseCode is a java.lang.String that stands for sampler response code. Here is a sample use-case:
ResponseMessage is a java.lang.String that represents a response message. The sample use case is the same as the one for the ResponseCode.
IsSuccess is a java.lang.Boolean that reflects whether sampler succeeded. If it’s set to true, sampler is considered “passed.” Otherwise, it will be marked as “failed.”
Label is java.lang.String that represents sampler label. It can be get or set as a usual String and will be listed in the test results as a sampler label.
FileName is a java.lang.String that contains a BeanShell script file name (what is entered in “Script file” stanza of the BeanShell Sampler).
ctx is the most powerful variable exposed to BeanShell. It represents the org.apache.jmeter.threads.JMeterContext class, which is virtually JMeter itself. It provides read/write access to the underlying JMeter engine, samplers, and their results as well as variables/properties.
vars (JMeter variables) is the most frequently used component. It’s an instance of the org.apache.jmeter.threads.JMeterVariables class and provides read/write access to current variables, is capable of enumerating/changing existing variables, creating new ones, and obtaining nested properties. All JMeter variables are Java strings. If you need to put something else to a JMeter variable, you’ll need to cast it to string first. The following code snippet demonstrates how to save previous sampler response data into a JMeter variable.
Basically, this is the same as “vars,” but it exposes JMeter properties instead. See JavaDoc on java.util.Properties and JMeter documentation on JMeter properties for more information. The primary distinction between props and vars is that props have a “global” scope, whereas the scope of “vars” is limited to the current thread group.
log represents the org.apache.log.Logger class and can be used to append a message into jmeter.log file. See JavaDoc on logger for more details. The following is the sample use case:
DEBUGGING OF BEANSHELL SCRIPTS
As BeanShell is executed within the Rhino engine, there is no other option to see what’s wrong, apart from inspecting jmeter.log file for something like:
Error invoking bsh method
and using System.out.println(“something”) or log.info(“something”) to determine where the script fails.