I'm not sure I'm understanding well what you're proposing: the Once Only
Controller is used in order to log in only once that username? How does it
works?

In another subject, I'm willing to know how useful are all the HTTP request
self-generated, I mean, how important are those requests recorded by the
HTTP proxy server that are not a consequence of user action. I'm asking
this, because when I executed my test plan, I'd had 17k hits on the
webserver on two hours, because each request on the test plan is considered
as a hit, but when manually executing the same actions hits weren't more
than 15 (test plan has over 60 requests, like images and stuff, and I don't
know if those requests are really that important).


Michael McDonnell wrote:
> 
> I do the same thing in my testing for my company
> 
> 
> Here's my set up:
> 
> Test Plan
>     -Thread Group
>         -HTTP Cookie Manager
>         -CSV Configuration
>             Defines USERNAME,PASSWORD
>         -HTTP Request Defaults
>         -Once Only Controller
>             -Http Request to Login.jsp
>                 Passes ${USERNAME} and ${PASSWORD} through POST
>         -Do other things after I'm logged in in a loop.
> 
> Hopefully this helps you.
> 
> On Thu, Apr 9, 2009 at 8:37 AM, santiagoloso <[email protected]>
> wrote:
> 
>>
>> I've resolved this problem by using the Login Configuration Element.
>> Now I have a new problem and it's that the application I'm testing does
>> not
>> allow the same user to log in simultaneously more than once.
>>
>> So, when I select 1 thread group and infinite loop there's no problem.
>> When
>> I select n users and 1 loop, using n different usernames, there's no
>> problem, but when I select n thread groups, n loops and I have n
>> usernames
>> (using csv data config element, that provides usernames to the Login
>> Config
>> Element), some of the samples (the most significative) returns a negative
>> response code (500).
>>
>> I've thought about creating separate Thread Groups, using a different
>> username for each Thread Group. But there are some concepts I'm not quite
>> sure about: when I'm remote testing, using 5 different computers, each
>> Thread Group will be repeated on each machine, so, I'll be in the same
>> place
>> again (since I'll have the same username on 5 different machines, and
>> response code will be 500 again).
>>
>> I've thought about this once more and may be, if I use csv files to
>> provide
>> usernames to each thread group (different file for different Thread
>> Groups),
>> since each csv file will be local on each machine, then all the users can
>> be
>> different.
>>
>> Any better idea?
>>
>> Thanks a lot for your help,
>>
>> Santiago
>>
>> Michael McDonnell wrote:
>> >
>> > Are you checking the actual response using the tree to see if your page
>> > reflect the log in correctly?
>> >
>> > You need to run in GUI mode to check that.
>> >
>> > On Wed, Apr 8, 2009 at 12:34 PM, santiagoloso
>> > <[email protected]>wrote:
>> >
>> >>
>> >> Yeap, I'm passing them. Results for ALL the samples are positive (on
>> the
>> >> whole test plan). But the logs on the DB says anonymous instead.
>> >>
>> >>
>> >> Michael McDonnell wrote:
>> >> >
>> >> > Are you passing in the username/password variables when you POST the
>> >> login
>> >> > form?
>> >> >
>> >> > On Wed, Apr 8, 2009 at 12:14 PM, santiagoloso
>> >> > <[email protected]>wrote:
>> >> >
>> >> >>
>> >> >> Hi everyone, I'm working on Test Plan for an application that
>> requires
>> >> >> username and password. Due to some permissions thing only some of
>> the
>> >> >> users
>> >> >> loaded on the DB are allowed to use this feature I'll be testing.
>> >> >>
>> >> >> Said that, I've configured a CSV file with usernames and passwords
>> >> (all
>> >> >> allowed to use this feature I'm testing) and setted the thread
>> group
>> >> to
>> >> >> log
>> >> >> in to the website, and then perform the required steps to get into
>> the
>> >> >> feature and operate over it.
>> >> >>
>> >> >> After executing THOUSANDS of times, and checked results, when I ask
>> >> for
>> >> >> information, the required information is retrieved (analyzed using
>> >> View
>> >> >> Results in Tree Listener). It's not really important data veracity,
>> so
>> >> >> I'm
>> >> >> not using assertions, just need the performance.
>> >> >>
>> >> >> Well, my doubt comes this way: when taking a look at db logs,
>> servers
>> >> >> been
>> >> >> hitted a lot of times, but always by an anonymous user (not by the
>> >> >> usernames
>> >> >> and passwords that are sent within the test plan).
>> >> >>
>> >> >> My deduction power tells me that the first steps (those executed
>> >> before
>> >> >> the
>> >> >> log in) must be anonymous, but, from that step and all that follow,
>> >> >> username
>> >> >> on db logs should be the one inserted on each iteration (csv file
>> >> brings
>> >> >> multiple username/password combinations, all valid).
>> >> >>
>> >> >> Am I wrong? What am I missing?
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> http://www.nabble.com/Is-this-working-or-not--tp22956547p22956547.html
>> >> >> Sent from the JMeter - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: [email protected]
>> >> >> For additional commands, e-mail:
>> [email protected]
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Is-this-working-or-not--tp22956547p22956898.html
>> >> Sent from the JMeter - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [email protected]
>> >> For additional commands, e-mail: [email protected]
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Is-this-working-or-not--tp22956547p22972288.html
>> Sent from the JMeter - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Is-this-working-or-not--tp22956547p23021624.html
Sent from the JMeter - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to