On 25 September 2012 00:15, David Luu <[email protected]> wrote: > Hi, > > Just ran into this today. My test has 2 thread groups, which perform near > identical functions with slight differences. So they each have their own > User Defined Variables within thread group and both share some global user > defined variables defined under the test plan root as such: > > Test Plan (w/ some global user defined vars) > * thread group 1 > ** user defined vars for thread group 1 > * thread group 2 > ** user defined vars for thread group 2 > > The user defined vars for both thread groups have same variable names but > different values. I also placed a results tree listener on each thread > group and noticed the following: > > thread group 1 takes its user defined variable values from thread group 2's > version, make its tests fail. > > Did I misunderstand the scoping functionality of JMeter or did I uncover a > bug? I had assumed JMeter scoping allows using variables of same name w/o > collision issues as long as they're in different scopes.
UDVs are configuration elements; as such they apply at the start. See the first paragraph here: http://jmeter.apache.org/usermanual/component_reference.html#User_Defined_Variables If you want to define per-thread variables, use a Pre-Processor such as http://jmeter.apache.org/usermanual/component_reference.html#User_Parameters > If my assumption is wrong, then collision issue apply to other variable > areas as well like regular expression extractors where I'll have to change > variable names if I have identical extractors in 2 thread groups? > > Whether I misunderstood or not, seems like from the issue here, JMeter > processes & interprets variables sequentially in test plan from top down > and so the value of the variable (if defined in more than 1 thread group) > will be the one that was defined last in the test plan (i.e. last thread > group defining the variable). > > I"m using JMeter 2.5. > > Regards, > David --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
