Re: JMeter variables and the beginnings of a JMeter scripting languag e

[Scott Eade <se...@backstagetech.com.au>]

Mike,

Interesting thread.

I would just like to add changes along these lines would solve a problem
that I have.

As outlined below the Default Config can supply the domain name and port to
use throughout the test unless overridden for specific test elements.  My
application is servlet based and I happen to deploy it under a number of
different servlet prefixes.  It would thus be convenient for me to be able
to define a HTTP Request Path prefix that I can then optionally use in my
test elements.

Cheers,

Scott
-- 
Scott Eade
Backstage Technologies Pty. Ltd.

> From: "Stover, Michael" <Mi...@usa.xerox.com>
> Reply-To: "JMeter Developers List" <jm...@jakarta.apache.org>
> Date: Wed, 10 Jul 2002 15:25:07 -0400
> To: "'jmeter-dev@jakarta.apache.org'" <jm...@jakarta.apache.org>
> Subject: JMeter variables and the beginnings of a JMeter scripting languag e
> 
> Recently I've noticed increased interest in making JMeter react more
> dynamically during test runs.  This seems only natural.  The HTML Link
> Parser provides some support, but really only seems to wet the appetite for
> more powerful options.
> 
> So, I'm starting on a more general solution and thought some of you might
> want to give some input.
> 
> I would like to allow users to embed simple reference elements as values in
> config and sampler objects, and then have a separate place where the value
> of these referenced elements would be specified.   Currently, people use a
> Default Config Object to set universal values such as DOMAIN and PORT.  I
> think a reference replacement system might be more intuitive than the
> current overlay system.  Rather than leaving the DOMAIN field blank and
> supplying a Default Config in the correct place in the tree, one would
> instead insert a reference - such as ${my_domain} - which would be replaced
> when the test is compiled.  Elsewhere, a table of all reference +
> replacement values would allow the user to change all such values in one
> location.  
> 
> This has many advantages over the current situation - it's generic, meaning
> one can use this system for any protocol.  Currently, there is an HTTP
> Defaults, and FTP Defaults, etc.
> It allows all such elements to have one centralized home which should be
> easier to manage.
> 
> For such user-defined values, this is simple.  I've taken the variable style
> from Ant - ${var-name} - because I like it.  Much preferable to XML IMO.  A
> bit more explicit than a Perl style as well.  Thoughts on this format would
> be much appreciated.  Anything simpler than what I've come up with that does
> the job.
> 
> Certain built-in values would be equally simple:
> ${__threadNumber}
> ${__threadName}
> ${__timestamp}
> ${__counter(0,100,1)}
> ${__xmlFile(c:\jmeter\bin\users.xml,username)}
> ${__literal[[${ant-variable}]]}
> 
> Well, some are not so simple, but I'm hoping you get the idea.
> ${__threadNumber} is replaced by the current thread's number.  I'm using
> "__" to indicate a built-in value as opposed to a user-defined variable
> name.
> 
> ${__counter(0,100,1)} - for those familiar with the HTTP Parameter Mask,
> this might look familiar.  The first number gives the starting point, then
> the end point, and the last is the increment.  I think it's another way of
> getting the same effect.  By embedding this variable into an argument name
> or value, you can get a similar effect:
> 
> NAME        PARAMETER
> username    user${__counter(0,100,1)}
> 
> This would create arguments in the following manner:
> username=user0
> username=user1
> username=user2
> etc...
> 
> Similarly, I see ${__xmlFile(c:\jmeter\bin\users.xml,username)} as a
> replacement for the User Parameter Modifier, though some complications have
> to be worked out.
> 
> And ${__literal[[Anything at all]]} allows a user to use values that might
> otherwise conflict with this system.  Although, that should be very rare,
> because variables not found in the table would be passed on as is.
> 
> This is getting long, but I've implemented a more complex built-in variable
> that allows users to scrape values from responses using regular expressions.
> Right now, it takes the following form:
> 
> ${__responseVariable(REGULAR_EXPRESSION,prefix$1sometext$2suffix,[ALL|#|RAND
> |0.###],[between])}
> 
> Take it slow.  From the beginning, "__" indicates a built-in variable.
> "responseVariable" is the name used to find the correct Java class to
> execute.  Then there are parentheses with arguments - just like the
> __counter(0,100,1) example above.  There are 4 possible arguments, but only
> the first 2 are required (thus the square brackets showing optional args).
> 
> The first argument is a regular expression, Perl style.  This regular
> expression will be applied to the response data received from the previous
> request.  
> 
> The second argument provides a template for generating the string that will
> be substituted for this whole mess at run time.  The variables ($1,$2) refer
> to regular expression groups (see Perl docs for more info).
> 
> The next argument indicates which match, or matches, to use - if your
> regular expression finds more than one match in the data.  ALL means use
> all.  A number (starting from 1) indicates which value by it's order in the
> response.  Thus, if you find 5 successful matches, a number of "3" means to
> use the third match.  RAND means pick one at random.  A float value is also
> a possible value.
> 
> The fourth argument is a static string to go between matched values if ALL
> was chosen as the third argument value.
> 
> Somewhat complex, though I envision a dialog allowing users to input these
> arguments in a friendly manner and then generating this string for them.
> 
> -Mike
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>