I think in the meantime I will use the approach noted in the original SO
posted.

If I keep the user credentials and the user-specific test data to iterate
over in the same file, it will mean duplication of the credentials, and a
large number of files, but it should work easily without too much overhead.
The only downside is mixing the data, as well as the large number of test
data files.

Thanks for the ideas Martin and Stuart

On Tue, Feb 20, 2018 at 9:05 PM, Stuart Kenworthy <stuart.kenwor...@bjss.com
> wrote:

> Another alternative is a set-up script to load in the user specific
> variables as properties, that can then referenced based on userID later
> down the line.
>
> props.put("user1homepage","www.myserver.com/admin");
> props.put("user2homepage","www.myserver.com/accounts");
>
> then in your script reference it based on userId (or however you pass in
> the ID of your user) such as
>
> ${__P(${userId}homepage)}
>
> Where userId is user1, user2, etc.
>
> This means any thread can use any userId and will always use the correct
> data for that userId.
>
> -----Original Message-----
> From: Herbener, Martin - Division of School Technology Planning and
> Project Management [mailto:martin.herbe...@education.ky.gov]
> Sent: 19 February 2018 17:47
> To: JMeter Users List <user@jmeter.apache.org>
> Subject: RE: Login-specific test data
>
> Hi Andrew,
>
> May not be suitable depending on the rest of your scenario, but - what
> about putting all the input data needed by a given user in the same row of
> the CSV file?  That is, one row per user?
>
> martin
>
> -----Original Message-----
> From: Andrew Burton [mailto:andrewburtona...@gmail.com]
> Sent: Sunday, February 18, 2018 9:24 PM
> To: JMeter Users List <user@jmeter.apache.org>
> Subject: Login-specific test data
>
>  Hi list,
>
> I have a scenario where we authenticate a user into an application,
> however each user has visibility only to a subset of total data, so
> providing input data for entities needs to be tied to the user login
> somehow.
>
> As an analogy, user logging in as a "department manager" would only have
> visibility on the "employees" in his section.
>
> I thought about something similar to this: https://stackoverflow.
> com/questions/40634030/how-to-avoid-duplicate-usage-of-
> users-from-csv-file-in-jmeter - but that is tied to a login's place in the
> input file, which isn't necessarily guaranteed.
>
> Another option I considered might be having a hashmap of data keyed by the
> username it pertains to. So, for example, 1 user login key might have the
> value in the hashmap of an array list, which can be randomly selected from
> on each iteration.
>
> This starts to get a little complicated, so before I start, I wondered has
> anyone else had a similar use case? Curious to see other
> thoughts/strategies behind solving it.
>
> Regards
>
> Andrew
>
> The information included in this email and any files transmitted with it
> may contain information that is confidential and it must not be used by, or
> its contents or attachments copied or disclosed to, persons other than the
> intended addressee. If you have received this email in error, please notify
> BJSS. In the absence of written agreement to the contrary BJSS' relevant
> standard terms of contract for any work to be undertaken will apply. Please
> carry out virus or such other checks as you consider appropriate in respect
> of this email. BJSS does not accept responsibility for any adverse effect
> upon your system or data in relation to this email or any files transmitted
> with it. BJSS Limited, a company registered in England and Wales (Company
> Number 2777575), VAT Registration Number 613295452, Registered Office
> Address, First Floor, Coronet House, Queen Street, Leeds, LS1 2TW.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org
> For additional commands, e-mail: user-h...@jmeter.apache.org
>
  • ... Andrew Burton
    • ... Herbener, Martin - Division of School Technology Planning and Project Management
      • ... Stuart Kenworthy
        • ... Andrew Burton

Reply via email to