You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Mohyt <sr...@gmail.com> on 2011/09/26 15:40:13 UTC
Load Testing of GWT Application
Hi everybody
I am new to JMeter. I wanted to do some functional testing of my GWT
application using JMeter.
Does it support GWT testing? For example I would like to write a script that
might check if the login module of my GWT application is doing good or not.
Please let me know if we have some sort of documentation specific to GWT
testing with JMeter.
Thanks a million.
--
Mohyt
--
View this message in context: http://jmeter.512774.n5.nabble.com/Load-Testing-of-GWT-Application-tp4841382p4841382.html
Sent from the JMeter - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Load Testing of GWT Application
Posted by Frank Cohen <fr...@pushtotest.com>.
PushToTest TestMaker (http://www.pushtotest.com/products) is free, open source, supports GWT in a variety of ways. -Frank
On Sep 26, 2011, at 7:58 AM, Bruce Ide wrote:
> GWT is intensely javascript-centric and Jmeter does not run Javascript as a
> browser would. This means that you can't exactly test the user interface.
>
> What you CAN do, and I've done this a few times so far, is test the
> client-server communication that originates out of that user interface. For
> this, the recording controller works reasonably well. So you can send the
> string the login GUI would send back to the server and validate that the
> response was one you expected. You just can't verify that you actually get a
> login screen.
>
> This is actually pretty helpful. You can quickly verify that there were no
> regressions in the server code, and dramatically lighten the load on your
> manual testers. In some iterations you might not need to call on manual
> testers at all.
>
> The GWT app I was testing uses GWT RPC to communicate with the back end. So
> some stuff happens on the client (Lets say the user is presented with a
> login screen) and then after the action has been completed data is squirted
> back to the server to validate that user. The recording controller sends the
> httprequest back as one big delimited string, but you can mostly see the
> values that you need to parameterize with Jmeter variables.
>
> There's one cryptographic signature toward the start of the string that's
> not intuitive. It seems to be there to prevent cross-site scripting and it
> changes every time you (or at least every time we) rebuild the app. This
> string must be replaced every time you deploy, or your test will no longer
> work correctly.
>
> To get this string, which is called the "Strong Name", you have to go to the
> directory where your application is deployed. In this directory are a number
> of .gwt files, each of which starts with the cryptographic signature you're
> interested in. If you search for the name of the function you're attempting
> to call in your jmeter test (Let's say "login",) one of the files will have
> the function name in it. The filename of this file before the ".gwt" part is
> the GWT strong name you need to replace that parameter with, in your string.
>
> I apologize if I didn't explain that very well, I haven't had my coffee yet.
> If it didn't make sense to you, I'll try to dig up some additional
> information about it from my research on the subject for you.
>
> --
> Bruce Ide
> FlyingRhenquest@gmail.com
---
Frank Cohen
PushToTest, the Open Source Test (OST) Company
fcohen@pushtotest.com
http://www.pushtotest.com
Phone: (408) 364-5508
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Load Testing of GWT Application
Posted by Bruce Ide <fl...@gmail.com>.
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
FlyingRhenquest@gmail.com
Re: Load Testing of GWT Application
Posted by Mohyt <sr...@gmail.com>.
Hi Bruce,
Thanks for reply,
I only understand the few points but not the whole scenario . Will you
please explain me some steps for Login Module testing ??
Thanks & Regards
--
Mohit
On Mon, Sep 26, 2011 at 8:29 PM, Bruce Ide [via JMeter] <
ml-node+s512774n4841679h43@n5.nabble.com> wrote:
> GWT is intensely javascript-centric and Jmeter does not run Javascript as a
>
> browser would. This means that you can't exactly test the user interface.
>
> What you CAN do, and I've done this a few times so far, is test the
> client-server communication that originates out of that user interface. For
>
> this, the recording controller works reasonably well. So you can send the
> string the login GUI would send back to the server and validate that the
> response was one you expected. You just can't verify that you actually get
> a
> login screen.
>
> This is actually pretty helpful. You can quickly verify that there were no
> regressions in the server code, and dramatically lighten the load on your
> manual testers. In some iterations you might not need to call on manual
> testers at all.
>
> The GWT app I was testing uses GWT RPC to communicate with the back end. So
>
> some stuff happens on the client (Lets say the user is presented with a
> login screen) and then after the action has been completed data is squirted
>
> back to the server to validate that user. The recording controller sends
> the
> httprequest back as one big delimited string, but you can mostly see the
> values that you need to parameterize with Jmeter variables.
>
> There's one cryptographic signature toward the start of the string that's
> not intuitive. It seems to be there to prevent cross-site scripting and it
> changes every time you (or at least every time we) rebuild the app. This
> string must be replaced every time you deploy, or your test will no longer
> work correctly.
>
> To get this string, which is called the "Strong Name", you have to go to
> the
> directory where your application is deployed. In this directory are a
> number
> of .gwt files, each of which starts with the cryptographic signature you're
>
> interested in. If you search for the name of the function you're attempting
>
> to call in your jmeter test (Let's say "login",) one of the files will have
>
> the function name in it. The filename of this file before the ".gwt" part
> is
> the GWT strong name you need to replace that parameter with, in your
> string.
>
> I apologize if I didn't explain that very well, I haven't had my coffee
> yet.
> If it didn't make sense to you, I'll try to dig up some additional
> information about it from my research on the subject for you.
>
> --
> Bruce Ide
> [hidden email] <http://user/SendEmail.jtp?type=node&node=4841679&i=0>
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://jmeter.512774.n5.nabble.com/Load-Testing-of-GWT-Application-tp4841382p4841679.html
> To unsubscribe from Load Testing of GWT Application, click here<http://jmeter.512774.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4841382&code=c3JpdmFzdGF2YW1vaGl0OTFAZ21haWwuY29tfDQ4NDEzODJ8LTY3NzA0MzgxNg==>.
>
>
--
View this message in context: http://jmeter.512774.n5.nabble.com/Load-Testing-of-GWT-Application-tp4841382p4844086.html
Sent from the JMeter - User mailing list archive at Nabble.com.
Re: Load Testing of GWT Application
Posted by Bruce Ide <fl...@gmail.com>.
GWT is intensely javascript-centric and Jmeter does not run Javascript as a
browser would. This means that you can't exactly test the user interface.
What you CAN do, and I've done this a few times so far, is test the
client-server communication that originates out of that user interface. For
this, the recording controller works reasonably well. So you can send the
string the login GUI would send back to the server and validate that the
response was one you expected. You just can't verify that you actually get a
login screen.
This is actually pretty helpful. You can quickly verify that there were no
regressions in the server code, and dramatically lighten the load on your
manual testers. In some iterations you might not need to call on manual
testers at all.
The GWT app I was testing uses GWT RPC to communicate with the back end. So
some stuff happens on the client (Lets say the user is presented with a
login screen) and then after the action has been completed data is squirted
back to the server to validate that user. The recording controller sends the
httprequest back as one big delimited string, but you can mostly see the
values that you need to parameterize with Jmeter variables.
There's one cryptographic signature toward the start of the string that's
not intuitive. It seems to be there to prevent cross-site scripting and it
changes every time you (or at least every time we) rebuild the app. This
string must be replaced every time you deploy, or your test will no longer
work correctly.
To get this string, which is called the "Strong Name", you have to go to the
directory where your application is deployed. In this directory are a number
of .gwt files, each of which starts with the cryptographic signature you're
interested in. If you search for the name of the function you're attempting
to call in your jmeter test (Let's say "login",) one of the files will have
the function name in it. The filename of this file before the ".gwt" part is
the GWT strong name you need to replace that parameter with, in your string.
I apologize if I didn't explain that very well, I haven't had my coffee yet.
If it didn't make sense to you, I'll try to dig up some additional
information about it from my research on the subject for you.
--
Bruce Ide
FlyingRhenquest@gmail.com
Re: Load Testing of GWT Application
Posted by Philippe Mouawad <p....@ubik-ingenierie.com>.
Hello,
The real complexity exists if your application uses GWT-RPC, if it's using
JSON then JMeter will do the job.
If your login page is not the first page AND you application uses GWT RPC,
then you will need either a plugin to JMeter that handles the serialization
or use another tool.
My Company (UBIK-INGENIERIE) distributes a commercial GWT Plugin for Apache
JMeter.
You can easily record, variabilize and replay GWT and GWT RPC based
application with standard knowledge of Apache JMeter Proxy.
See:
http://www.ubik-ingenierie.com/-Solutions-
http://www.ubik-ingenierie.com/ubikwiki/index.php?title=Load_Testing
Regards
Philippe M.
-----
Philippe M.
http://www.ubik-ingenierie.com
--
View this message in context: http://jmeter.512774.n5.nabble.com/Load-Testing-of-GWT-Application-tp4841382p5714150.html
Sent from the JMeter - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@jmeter.apache.org
For additional commands, e-mail: user-help@jmeter.apache.org