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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
