jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Shetty <shet...@gmail.com>
Subject Re: Dynamically enable/disable HTTP Request Defaults parameters
Date Fri, 03 Aug 2012 02:57:35 GMT
>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 <stephenash@gmail.com> 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 <shettyd@gmail.com> 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 <stephenash@gmail.com>
> 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: user-unsubscribe@jmeter.apache.org
> >> For additional commands, e-mail: user-help@jmeter.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
> For additional commands, e-mail: user-help@jmeter.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message