请教一个VUserID的问题？

Athenst

起因：

由于参数化的过程中需要取【必须唯一】的值，
所以测试方案中决定使用迭代次数（InterationNumber）＋（VUserID），拼成一个值，
形成唯一的ID，作为执行标志。

问题：
在一台压力机上产生的（InterationNumber）＋（VUserID）是唯一值。
但是当在Controll中添加了一台客户端压力机后，发现两台机器上产生的（InterationNumber）＋（VUserID）值是一样的；这样就违背了脚本中参数唯一的要求。

求助：如何解决该问题？

Athenst

sdlkfj1

有没有办法让两台压力机上跑的VUser，有着不同的ID呢？

jut984907

VUser参数华，也唯一

Athenst

把VuserID参数化之后，又回到最初的问题了～～

目前就是要彻底抛弃参数化，而通过VUserID＋ItrationNumber来生成参数～～

rickyzhu

把load generator机器的IP也拼上。不就可以了，或者加上一个随机数。

Zee

为什么不用参数化的方式？理由？

Athenst

多谢RichZhu，呵呵，＋IP的方式比较好，目前已经得到解决～

To Zee，为什么不用参数化的原因有3个：

1、这次做的疲劳测试的参数非常多，计划在N（N>10）张大表分别生成20W条记录，然后进行多表数据关联；导致参数文件非常大，读取时严重影响效率；

2、测试参数要求满足唯一性、随机性要求，并且用户的技术经理不同意我们使用设置参数时把“Select Next Row”属性设为“Unique”，场景设置时把“Allocate values for each user”属性设置一个值的建议；

3、我是被逼的～

Zee

"并且用户的技术经理不同意我们使用设置参数时把“Select Next Row”属性设为“Unique”，场景设置时把“Allocate values for each user”属性设置一个值的建议；"

这个是因为什么？挺有意思。是不是有确切的理由？

Athenst

是的，对方认为LR中这样设置，
“1、不可靠，2、不能适用于用户数逐步递增的情况”

由于这次来做测试时老大希望能“满足用户的所有要求”，在加上任务分析时认为脚本改造的工作量应该不是很大，所以答应下来。

sdlkfj1

Zee

sdlkfj3 sdlkfj3

ppent

呵呵，有些事情已经超出了测试技术的范畴了。

rickyzhu

呵呵，有的时候技术不是问题。
是管理的问题，流程的问题。

说白了，是人的问题。嘻嘻