Hi Steve,
Great work and I do have some comments as a fellow Jmeter user.
I agree with Lesson #5 'Jmeter UDV User Defined Variable Tips and Help
<http://coreplex.blogspot.com/2008/10/jmeter-udv-user-defined-variable-tips.html>'
but with Lesson #6 under the same subject I have the following different
way of overcoming this which might be worth a mention.
This might just be me but I view User defined Variables and User
Parameters as two operators with the same goal of setting variables ie.
it all falls under one umbrella in the end. User defined Variables can
only be set at the start of a thread so they are good for initialising
variables and User Parameters can be used at run time to overwrite
variables that user defined variables initialised or even just never
existed. User parameters have an annoying property that they are only
pre-processors and their scope of where the variable extends to ie. the
parent being run and and its siblings and all children of the parent.
Perhaps in the future these could be put anywhere with a bit of dev and
the scoping rules be extended with the checking of a new checkbox
setting in the operator.
This brings up the same Lesson #5 problem ie. we're limited to setting
the variables in certain places as opposed to building logical steps of
variable manipulation but I've been hacking my way around it by using
the simple logic controller. If I need to overwrite a variable value
runtime and I've already used a User Parameter pre processor in the test
plan I setup a simple logic controller to group the variables scope for
the following operators to use the variable and apply a pre processing
User Parameter under the Simple Logic Controller as the first operator
to make the variable adjustment. Then the operators to follow which use
that overwritten value are also children of the simple logic controller
and have access to the modified variable value set in the User Parameter.
The most common situation I have is I've essentially caused by my
'functioning up' to use a coding term, operators in a simple logic
controller to perform a discreet series of actions eg. log in. Login
becomes a module for use in any other test plan because many tests might
want to log in in the same way BUT I don't necessarily want to copy and
paste the same log in operators all over the place because God forbid
the way logging into my application might change once day and I'd have a
hell of a lot of operators to update. So that's why I function up my
operators now what problem does this pose me come using them ....
Log in steps could be simplified to get login page contents; send
username and password where user name and password are variables. Then
from other test plans I call the login function at the start of my test
plan using the module operator. That all works great until the variable
name storing, lets say username is different to the one which my
functioned up login module is expecting. In this case I find myself
having to apply my 'add another simple logic controller hack to copy
variable value from username variable name 1 to username variable name
2. The extra downside is I get another simple logic controller being
listed in my list of modules I can call which just starts to confuse
things as there is no reason I would ever want to call that module from
anywhere else. I usually call the grouping simple logic controller
'ignore' as a flag to myself to know that controller is there just to
get around the trickiness with variables as opposed to functioning up a
set of operators.
Anyway, I guess I'm just showing how I view variables and how I get
around the Lesson #5 problem you listed & lesson #6. Maybe what I'm
doing is good and maybe bad. It's just something to ponder I guess.
Chad
Steve Kapinos wrote:
I finally got around to dumping my experiences and gotchas with jmeter
together. They are mostly around handling variables vs properties vs
user parameters. Hopefully people will stumble upon them in future
searches for their needs
http://coreplex.blogspot.com/search/label/jmeter
we've been able to build a fully automated recurring test suite using
jmeter.. with what now seems like really basic scripts, but it was a
long way getting there. We now how our CI platform running NANT scripts
that deploy newly built installers, run the installshield installer, run
a suite of jmeter tests, process the logs, and visualize the results
using gnuplot. All automatically each night :)
If anyone spots any errors, please feel free to comment.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Anthony Chadszinow
MySource Classic Lead Developer
Squiz
92 Jarrett St Leichhardt, Sydney NSW, Australia 2040
t: 13000 SQUIZ ( Support )
t: 8507 9900 / 1300 130 661
f: 8507 9988
e: [EMAIL PROTECTED]
w: www.matrix.squiz.net
w: www.squiz.net
Sydney | Melbourne | Canberra | Hobart | Wellington | London
Open Source - Own it - Squiz.net
----------------------------------------------------
IMPORTANT:This email (and any attachments) is commercial-in-confidence and
or may be legally privileged and must not be forwarded, copied or shared
without express permission from Squiz. If you are not the intended
recipient, you may not legally copy, disclose or use the contents in any way
and you should
contact [EMAIL PROTECTED] immediately and destroy this message and any
attachments. Thank you.
