>You got it, load testing database driven web applications.
>" But I'm not quite grasping the implications of this,

usually in a load test you ignore the browser performance characteristics -
i.e you care about how much time it takes for your server to respond given a
load , rather than how long it takes for the page to render on the browser
(because this is not dependent on the load - other than the time it takes
for the browser to actually get the page/resources). So broadly speaking ,
the fact that Jmeter doesnt do javascript isnt a big deal for load test. The
main interactions are HTTP interactions and Jmeter can do that reasonably
well. so javascript that for e.g. selects a radio button out to Post value X
for parameter Y .

It might matter when
a. You want a set of functional tests which you can run concurrently instead
of two separate set of tests. In this case some of your functionality test
might include exercising the javascript which isnt possible using JMeter
b. You need to parameterise quite a few area and the javascript framework
under question doesnt easily lend itself to parameterisation(perhaps it
calculates values dynamically , mangles field names, encodes values) , which
means you might have to replicate parts of the javascript logic in JMeter
c. You have managers who demand the exact page response times and they
include browser render times/ javascript execution times etc as part of the
same report.or they want Jmeter to behave like the latest version of
loadrunner with AJAX support.

>how likely is it that my test is actually doing what I think it is,
 The vast majority of web applications aren't well behaved HTTP
applications. They do not return HTTP error codes when things fail,
preferring to return a status of 200 with a custom error message.
Use Assertions to verify that every page has some data that you expect it
does. For e.g. if after login you say welcome , username! - then check that
the page does indeed have that by adding a response assertion. if you place
an order and you expect an Order number in the response check that. if you
have a standard error message that shows when things go wrong  check that
your pages dont have that in the response. etc etc.

Or if you expect your test to have inserted 100 rows then check your
database does indeed have 100 rows at the end of the test.
The most common cause of failure of record and replay tests is that some
data is variable and you need to parameterise your tests correctly.

regards
deepak



On Fri, Oct 21, 2011 at 8:36 AM, CHARLES BAKER <chba...@clemson.edu> wrote:

> Hello to the JMeter users. Firstly does anyone hang out in #jmeter on
> irc.freenode.net? I joined, but I only see two others there and they are
> so far unresponsive.
>
> Secondly, I've been out of the web development and testing game for quite a
> long time now, but started a new job and guess what my first task is? You
> got it, load testing database driven web applications.
>
> I've read through the JMeter User's Manual and understand that "...JMeter
> does not execute Javascript found in HTML pages." But I'm not quite grasping
> the implications of this, particularly when testing a Javascript heavy web
> application like BlackBoard.
>
> I used the HTTP Proxy to record a session in blackboard as a test. When I
> run the test it appears that the recorded actions are working, I see
> rc="200" in the results and no rc="500", rc="404" or similar return codes
> and only the occasional rc="302". Given that and the non-execution of
> Javascript constraint, how likely is it that my test is actually doing what
> I think it is, i.e. selecting radio buttons and going to the next page,
> etc.?
>
> If there is some other manual which I should go and apply RTFM to, feel
> free to point me to it and tell me to RTFM. Thanks.
>
> --
> Charles H. Baker, Systems Programmer II CCIT/CSO
> Don't see me in my cubicle? Try AIM: rascharles GTalk:
> chba...@g.clemson.edu
> chba...@clemson.edu | o: 864.656.8069 | gv: 864.990.1297
> Freedom of choice is more to be treasured than any possession earth can
> give.
> David O. McKay
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
>
>

Reply via email to