@Deepak, Can you please explain how to use beanshell preprocessor to capture values from java script?
On Fri, Aug 3, 2012 at 8:27 AM, Deepak Shetty <[email protected]> wrote: > >I would rather not have to duplicate the pre-processors over and over > again. > If you create the pre processor under the thread group then it applies to > all samplers (just like the defaults element) > > On Thu, Aug 2, 2012 at 6:55 PM, Stephen Ash <[email protected]> wrote: > > > @Deepak > > Thanks for the suggestion. I tried it out, and that method did work. > > Since there can be many samplers in the test, I would rather not have > > to duplicate the pre-processors over and over again. Hence wanting to > > get it working in the Defaults element. > > > > @Oliver > > That is a clever way of handling it. I hadn't thought of constructing > > the whole optional part of the query string. Yes, the parameters can > > be more than just Boolean values (probably a bad example), so I worked > > off your suggestion and got things working. What I ended up doing is > > kinda strange, and looks ugly, bug it keeps all the optional > > parameters in one place. > > > > Inside the Test Plan element, I set up a variable > > optionalParameters=${__P(optionalParameters, false)} and also a > > variable that was verboseLogs=${__P(verboseLogs, true)}. Inside my > > HTTP Request Defaults was where the cool stuff happens. I added a > > parameter with the name being ${__BeanShell( if ( > > vars.get("optionalParameters").toString().equalsIgnoreCase("true") ) > > return "verboseLogs"; )} and the value being ${__BeanShell( if ( > > vars.get("optionalParameters").toString().equalsIgnoreCase("true") ) > > return vars.get("verboseLogs"); )}. Basically if > > optionalParameters=true, then make a parameter > > verboseLogs=${verboseLogs}. Otherwise, both sides will be an empty > > string and JMeter will ignore it. > > > > What I like about keeping that in the HTTP Request Defaults is that I > > can leverage the encode logic from JMeter (instead of recreating it > > outside and passing it into the script). I also get to use these > > optional variables in multipart/form POST requests without any other > > changes. It seems excessive to have to check the ${optionalParameters} > > value over and over, but I guess it works, so I should be happy! > > > > Thanks! > > > > On Thu, Aug 2, 2012 at 4:28 PM, Deepak Shetty <[email protected]> wrote: > > > Hi > > >>Is there a way to modify that test element dynamically during the test > > > execution? > > > A beanShell preprocessor can access the HTTPSampler - and should be > able > > to > > > remove arguments on the fly (but I havent tested it) - and how you > > identify > > > what it is to be removed is upto you > > > Alternately don't use request defaults and use the preprocessor to add > > > arguments dynamically (and how you determine what to add is your code) > > .e.g > > > > > > http://theworkaholic.blogspot.com/2010/03/dynamic-parameters-in-jmeter.html > > > > > > regards > > > deepak > > > > > > On Thu, Aug 2, 2012 at 4:01 PM, Stephen Ash <[email protected]> > > wrote: > > > > > >> In the following test plan example, the HTTP Request Defaults element > > >> is applied to all HTTP Samplers. Is there a way to modify that test > > >> element dynamically during the test execution? > > >> > > >> The use case is that each of the /foo, /bar, /baz requests can take an > > >> optional request parameter. So both GET /foo and GET > > >> /foo?verboseLogs=true would be valid requests. I was looking for a way > > >> to pass in a property (-JoptionalParameters=true) to JMeter in order > > >> turn on or off those arguments. > > >> > > >> Test Plan > > >> - HTTP Request Defaults > > >> - Thread Group > > >> -- HTTP Sampler (GET /foo) > > >> -- HTTP Sampler (GET /bar) > > >> -- HTTP Sampler (GET /baz) > > >> > > >> A couple of things that I have tried so far without luck: > > >> - Move the HTTP Request Defaults into the Thread Group and then > > >> surround with an If Controller. This causes the HTTP Requests Defaults > > >> to only be in the context of the If Controller now, and not propagated > > >> up the If Controller's parent. > > >> - Adding a BeanShell pre-processor to the Test Plan or Thread Group > > >> that will get the ThreadGroup from the current context and add a new > > >> Debug Sampler Element (would swap with ConfigTestElement later). That > > >> probably won't work in general since the structure of the test is > > >> already defined and not re-evaluated when I add the Test Element. > > >> > > >> Some things that will work, but I would like to avoid since they are > > >> not as sustainable: > > >> - Split into two separate scripts/thread groups, one with and one > > >> without the optional parameters. > > >> - Pass in another JMeter property for the parameter's key. The HTTP > > >> Requests Default would have an argument where name=${verboseKey} and > > >> value=${verboseValue}. If I wanted the parameter, I would have to set > > >> verboseKey="verboseLogs=" and verboseValue="true". This becomes hard > > >> to manage with many parameters. > > >> > > >> Any other ideas to try would be appreciated. > > >> > > >> Thanks. > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > >> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- madhu kk
