Take a look at this code snippet I found for the login page.

<script type="text/javascript">
// activate login feature if script is activated and browser is supported
if ($.browser.msie && $.browser.version < 8) {
$('#browser-redirection').css('display', '');
} else {
$('.script-checking').css('display', '');
$('#warnings').css('display', 'none');
}
</script>

So my understanding is that the login feature is not getting activated at
all as JMeter does not run javascript.
Is that correct?
Is there any way for me to simulate a user logging in with this situation?





On Tue, Jun 11, 2013 at 5:10 PM, Deepak Shetty <shet...@gmail.com> wrote:

> >. If the recorded requests have the same problems as your test plan did,
> which is fairly common when you have dynamic data and is not a good
> indicator.
>
>
>
> On Tue, Jun 11, 2013 at 1:52 PM, Robin D. Wilson <rwils...@gmail.com>
> wrote:
>
> > If you use the Proxy setup, you can then just 'replay' the previous
> > requests and see if they have the same problem as you were
> > having. Basically, disable your test requests, and copy/paste the ones
> > from the Proxy recording in their place. Run the test using
> > the recorded requests, and watch the Tree Listener for the responses from
> > the server. If the recorded requests have the same
> > problems as your test plan did, then you will definitely need to discuss
> > with your developers (maybe it's just a bug in their
> > code?). If the recorded proxy script works normally, then you have a
> > problem in your JMeter test plan setup - and you can use the
> > proxy requests to figure out what is missing from your test plan.
> >
> > --
> > Robin D. Wilson
> > Sr. Director of Web Development
> > KingsIsle Entertainment, Inc.
> > VOICE: 512-777-1861
> > http://www.kingsisle.com
> >
> >
> > -----Original Message-----
> > From: nmq [mailto:nmq0...@gmail.com]
> > Sent: Tuesday, June 11, 2013 3:31 PM
> > To: JMeter Users List
> > Subject: Re: Login failed - javascript
> >
> > I meant they're encoding the request using javascript. Should I have a
> > talk with the developers?
> > Problem is they're offshore *sigh*.
> >
> >
> > On Tue, Jun 11, 2013 at 4:27 PM, nmq <nmq0...@gmail.com> wrote:
> >
> > > Hi Deepak
> > >
> > > Thanks for all that info. I installed fiddler quickly.
> > >
> > > This is what I got in request header:
> > > /UpdateCheck.aspx?isBeta=True HTTP/1.1 which I don't think is
> > > significant OR I could be wrong. Correct me if I am.
> > > It also says "response is encoded and may need to be decoded before
> > > inspection" when I clicked on Inspectors tab. Do you think this might
> > > be the problem? They're encoding the password using javascript? If
> > > yes, what can I do to bypass this?
> > >
> > >
> > > Hey Robin, I've done all of that. I used a tool called badboy to
> > > capture the script, so didn't need to use the proxy. I've tried both
> > > Firefox and Chrome strings for the user-agent in HTTP Header Manager.
> > > Everything was working fine before they deployed the current build
> > yesterday.
> > >
> > >
> > > Regards
> > > Sam
> > >
> > >
> > >
> > > On Tue, Jun 11, 2013 at 4:18 PM, Robin D. Wilson <rwils...@gmail.com
> > >wrote:
> > >
> > >> First, this isn't really a "limitation" of JMeter, it is an artifact
> > >> of the way web sites work. Keep in mind, JMeter is designed to test
> > >> the 'server' part of the web system, but web systems include the
> > >> 'browser' in the application logic (often times incorporating a lot
> > >> of logic in the JavaScript code that runs in the browser, or in other
> > >> coding systems such as Flash and Silverlight). You could call that a
> > >> 'limitation' of JMeter, but that would be like saying that a chainsaw
> > >> is limited because it can't be used as a good hammer.
> > >>
> > >> There are a couple of ways this is measured, depending on the site in
> > >> question. If it is coming from the server, it is probably looking at
> > >> a header in the request to figure out if you have JavaScript enabled.
> > >> Add an "HTTP Header Manager" element to your test plan, and set a
> > >> User-Agent value...
> > >>
> > >> We use the following User-Agent value:
> > >>
> > >>         User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT
> > >> 6.1; WOW64; Trident/5.0)
> > >>
> > >> This essentially tells the server that you are making requests with
> > >> the
> > >> IE9.0 browser (which supports JavaScript by default). (NOTE:
> > >> we use this because it is still our most popular browser (actually,
> > >> that's not quite true - it is the most common version of the most
> > >> popular browser 'type' (IE)) - for users hitting our sites.)
> > >>
> > >> But if you have a different user population, you might prefer to use
> > >> Chrome or Firefox or Safari as your 'standard test' User-Agent.
> > >> You can look up their User-Agent strings here:
> > >>
> > >>         http://www.useragentstring.com/pages/useragentstring.php
> > >>
> > >> If the HTTP Header Manager + User-Agent value configuration doesn't
> > >> work, you will need to figure out how the server is determining that
> > >> the browser supports JavaScript, and mimic that with your test. It is
> > >> usually easier to setup the 'HTTP Proxy Server', and just collect a
> > >> session from your browser than it is to try to figure it out manually
> > >> though.
> > >>
> > >> To setup the proxy and capture a session:
> > >>
> > >> 1) Create a new Test Plan.
> > >> 2) Right-Click on "Workbench" and select:
> > >>
> > >>         Add->Non-Test Elements->HTTP Proxy Server
> > >>
> > >> 3) Make sure "Capture HTTP Headers" is checked
> > >> 4) Click "Start" on the HTTP Proxy Server configuration page (at the
> > >> bottom of the page)
> > >> 5) In your browser, set your Proxy Server address to "localhost", and
> > >> use the port specified in your HTTP Proxy Server configuration
> > >> (default is 8080).
> > >> 6) Visit your site, and perform some functions you want in your test.
> > >>
> > >> These should start to record your requests in the test plan, below
> > >> the workbench section. You can click on one of the requests and see
> > >> what the "HTTP Header Manager" looks like, and use that as your
> > >> default HTTP Header Manager for your tests. You can also see what
> > >> sort of interactions are taking place between the browser and the
> > >> server - some of which may be under-the-covers (hidden from the user)
> > >> and allowing the server to figure out whether the site supports
> > >> JavaScript.
> > >>
> > >> --
> > >> Robin D. Wilson
> > >> Sr. Director of Web Development
> > >> KingsIsle Entertainment, Inc.
> > >> VOICE: 512-777-1861
> > >> http://www.kingsisle.com
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: nmq [mailto:nmq0...@gmail.com]
> > >> Sent: Tuesday, June 11, 2013 2:41 PM
> > >> To: JMeter Users List
> > >> Subject: Login failed - javascript
> > >>
> > >> Hi everyone
> > >>
> > >> I have run into an issue running my basic login script for the AUT.
> > >> It was working fine till we got a new build this week.
> > >>
> > >> Now, I have been a functional tester my whole career. My company
> > >> wanted me to do some performance test for them and I figured why the
> > >> heck not. I'll learn along the way, so basically I'm a newbie in this
> > >> area.
> > >>
> > >> Since JMeter is an open-source (translated: free of cost) tool that
> > >> is supposedly powerful, we decided to use it (stupidly, without
> > >> finding out its limitations). I've invested quite some time in
> > >> learning the tool so I'm not ready to give up or switch to another.
> > >> I'm also not a programmer and don't have much info on java or
> > javascript.
> > >>
> > >> Anyways, getting back to the point..... I looked at the response in
> > >> ResultsTree in HTML format and this is the message I'm getting on the
> > >> Login
> > >> page:
> > >>
> > >> "This website requires JavaScript
> > >> Please activate JavaScript and press F5"
> > >>
> > >> HELP!!
> > >>
> > >> Regards
> > >> Sam
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> > >> For additional commands, e-mail: user-h...@jmeter.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> > For additional commands, e-mail: user-h...@jmeter.apache.org
> >
> >
>

Reply via email to