I set my tests up by using the http proxy controller to record the traffic
between the client (Firefox) and the server. Setting this up is documented
here: http://www.jajakarta.org/jmeter/1.7/en/user_manual/proxy_server.html
So lets say I want to test the login process. I'd set my recording
controller up, configure firefox to use jmeter as its proxy and then log in
to the web page. This creates some test nodes in your test.
GWT applications only generate traffic when they want to talk to the server,
so you'll probably only get one http request when you log in. It will
probably download a bunch of .js files and maybe some images but you don't
really need those and can just disable the requests for them. Look through
the nodes to see if you can find a request for "login" or "loginRequest" or
something like that. That'll be the request you're interested in.
In that request will probably be a long string, delimited by "|". The 4th or
5th parameter will be a long hex string, proably 30-40 characters. That'll
be the strong name, which you'll have to get every time the app is deployed.
For the time being you can leave it alone, though.
Look through that string and you should find the username and password
you're using. You can parameterize these with variables -- ${user_name} and
${password} for example.
To get the strong names I log in to the server the code is deployed on with
the SSH Sampler (Which I believe you have to download and install
separately.) I have it log on to the server the code is deployed to and use
the command "cd ${deployDirectory} && grep LoginCommand *.gwt.rpc". This
finds the login command in those files. If the login command your proxy
session reveals is something other than LoginCommand, you'll need to change
its name to that.
I process the output of the ssh sampler with a regular expression extractory
with the regular expression of "(\w+)\.". use the reference name
"logincommand_strongname". You can then replace the hex string in your
request with "${logincommand_strongname}" so that deploys don't mess your
test up. All this strong name processing has to take place before you
attempt to log in to the webap. I keep mine in a separately included module
that acquires the strong names for all the functions I use in the webapp.
Once you get your login test recoded, play it back and make sure it works.
Then you can tinker with it.
--
Bruce Ide
flyingrhenqu...@gmail.com
