关于loadrunner的vugen的内在机制的一些讨论和疑问
首先还是贴出脚本，是使用html协议录制的vuser_init()
{
........
//下面是对登录界面的登录数据提交。出于安全考虑，采用了scas。这里要注意的是lt，它是使用服务器分配的值，在提交登录数据的时候提交给服务器进行确认的。这个值是服务器随机产生的，也就是说，这个值应该做关联。
web_submit_data("login",
"Action=http://192.168.0.3/SCAS/login?service=http%3A%2F%2F192.168.0.3%2Fdocexchange%2Fwebforms%2Findex.jsp",
"Method=POST",
"RecContentType=text/html",
"Referer=http://192.168.0.3/SCAS/login?service=http%3A%2F%2F192.168.0.3%2Fdocexchange%2Fwebforms%2Findex.jsp",
"Snapshot=t2.inf",
"Mode=HTML",
ITEMDATA,
"Name=username", "Value=no1", ENDITEM,
"Name=password", "Value=111111", ENDITEM,
"Name=lt", "Value=LT-762-04MIletGofhEX6K8bcqH", ENDITEM,
"Name=x", "Value=0", ENDITEM,
"Name=y", "Value=0", ENDITEM,
LAST);
//根据提交的数据和lt的值，服务器会分配不同的ticket，因此ticket的值应该做关联。
web_url("index.jsp",
"URL=http://192.168.0.3/docexchange/webforms/index.jsp?ticket=ST-94-KeDhvFUFCInvCirAcMKp",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Snapshot=t3.inf",
"Mode=HTML",
LAST);
问题首先是关联引起的，我采用的是录制后回放脚本后，关联脚本。关联函数：
//关联lt 的值为WCSParam_Diff1，就是前一个粗体部分
web_reg_save_param( "WCSParam_Diff1", "LB= value=\"", "RB=\"", "Ord=2", "Search=Body", "RelFrameId=1", LAST );
//关联ticket的值为WCSParam_Diff2，就是后一个粗体部分
web_reg_save_param( "WCSParam_Diff2", "LB=ticket=", "RB=\"", "Ord=2", "Search=Body", "RelFrameId=1", LAST );
和开发人员交流知道：1、html语言的赋值语句赋的值都是字符，虽然在程序中可以写为 value=abcdef。但是在提交给服务器的时候实际上是 value=”abcdef“。因此，lt的左边界是value= ”，右边界是双引号。这也是为什么有人手动关联html语言的时候，出现不能匹配的原因之一。
2、关于scas：lt的值是应用程序请求服务器，服务器分配给应用程序的一个随机值，在提交登录数据的时候，应用程序把这个随机值和登录数据再提交回服务器，验证登录数据的正确性。根据登录数据和lt分配的随机值，会产生相应的ticket的值，也就是说ticket的值是与lt的值相适应的。
做法：1、修改WCSParam_Diff1的关联函数，把左边界的约束改为："LB= value="，也就是说左边界只有 value=，回放提示错误出现在WCSParam_Diff2上：Error -26377: No match found for the requested parameter "WCSParam_Diff2". Check whether the requested boundaries exist in the response data. Also, if the data you want to save exceeds 256 bytes, use web_set_max_html_param_len to increase the parameter size
。初步看很奇怪，但是我试图解释：WCSParam_Diff1左边界少了一个双引号，匹配的值由LT-762-04MIletGofhEX6K8bcqH变成了“LT-762-04MIletGofhEX6K8bcqH，由此引起了ticket的变化，所以，WCSParam_Diff2不匹配。但问题接着提出来了：ticket的值是根据WCSParam_Diff1生成的，WCSParam_Diff1变化了，服务器分配为i给ticket的值只能随之变化，但不应该是不匹配和长度不足的错误消息吧。由此很想了解lr关联的内在机制，是怎样进行关联的。
做法2 ：既然ticket的值WCSParam_Diff2是与WCSParam_Diff1的值相适应的，那么取消WCSParam_Diff1的关联，应该在lt的位置提示错误吧，结果不是，回放错误仍然和上面的错误提示一样： Error -26377: No match found for the requested parameter "WCSParam_Diff2". Check whether the requested boundaries exist in the response data. Also, if the data you want to save exceeds 256 bytes, use web_set_max_html_param_len to increase the parameter size。
由此想清楚vugen的回放机制：vugen回放是根据脚本提供的代码信息回放的吗？答案应该是肯定的，但是:脚本提供了lt提交的随机值：LT-762-04MIletGofhEX6K8bcqH，服务器应该能产生相应的ticket值，绝不会出现参数不匹配的错误。还有，既然lt是随机的，那么更改其中的一两个字母，应该不会出现什么问题。 但实际结果是出现上述WCSParam_Diff2不匹配一样的错误。由此，可以怀疑一点：vugen是完全根据脚本代码信息回放的么？深入一点，在congtroller中运行脚本，特别是进行联机负载测试的时候，是不是负载pc也是完全根据脚本代码信息运行的？
前面提出了我的一点疑惑和看法，很希望有人能解答。很有可能在对scas和关联的机制上，我理解有偏差。因为，我还是相信 联机负载测试，特别是做负载的pc是根据脚本信息运行的。
[ Last edited by wghong on 2004-11-5 at 20:31 ] 你所用的 web_submit_data和web_url函数都是lr中上下文无关的API。你在录制时修改了record mode吧，默认的mode是上下文相关的，也就是提供关联机制的。
要使用机制，使用上下文相关的API吧，试试。 没有修改过，我用的是默认的设置。刚才重新按照sunshinelius所述，进行了脚本录制，结果还是一样的，不应该是sunshinelius的所说的错误。
[ Last edited by wghong on 2004-11-7 at 11:33 ] 你在record option中，选中html-based script，高级选项中，选中"a script descrb ing user actions" 这个模式 就是选中的那个，sunshinelius，不是你说的那个原因。因为两个关联由于scas，每次的值是有关系的，因而这两个关联的匹配不是完全独立的。 只是一个建议啦。你可以采用上下文相关的方式试试。你按我所说的那种方法不可能录到web_submit_data这个函数的，应该是web_submit_form这个函数。就是你提交表单的那个操作。
我使用过上下文无关的机制，发生过你类似的问题，所以才建议你使用上下文相关的机制。 sunshinelius，我先谢谢你的帮助。但是，我尝试了你所说的两个模式，录制到的都是
web_submit_data这个函数，我确认了是你按照你所说的做的。另外，我也确认了开发人员处的源代码：这里确实是将登陆信息作为一个form提交给服务器的，所以，我也很纳闷 。另外，关于你说的A script descriping user actions 模式和 a script containing explicit URLs only 模式分别能使lr的函数调用上下文无关和相关的API是怎么一回事呢？我对这个也不明白，能讲讲吗？ 我觉得如果改为" lb＝value＝"的话，不应该是下面的这种情况：
匹配的值由LT-762-04MIletGofhEX6K8bcqH变成了“LT-762-04MIletGofhEX6K8bcqH
因为缺少转义符'\'系统不可能认出”，我认为正是因为多了个”，所以系统不能取到正确的边界值，造成WCSParam_Diff1每次取得值，格式都在关联的时候发生变化，导致WCSParam_Diff2不能匹配。
个人觉得vugen在第一次回放的时候可能是直接把it的值抛给服务器，然后验证取道的ticket值是否匹配，以验证关联是否正确，这时候可能还没涉及到回放，而仅仅是验证语法，否则，vugen怎么才知道我是要把那些数字做关联呢？如果回放仅仅是回放教本，那么关联这个作用也就没有必要了 Originally posted by suliang at 2004-11-8 04:18 PM:
我觉得如果改为" lb＝value＝"的话，不应该是下面的这种情况：
匹配的值由LT-762-04MIletGofhEX6K8bcqH变成了“LT-762-04MIletGofhEX6K8bcqH
因为缺少转义符'\'系统不可能认出”，我认为正是因为多了 ...
改为" lb＝value＝"后的关联的值可以在”关联结果“栏看到的，使用左边界" lb＝value＝\""和" lb＝value＝"所看到的值，并没有在格式上有很大差别。几乎可以说位数和格式都是相同的 上下文无关API：http请求不依赖于上次请求的成功与否
上下文相关API：本次请求依赖于上次请求的返回结果
lr中的http API大概就是这两种。 sunshinelius，谢谢。
但是A script descriping user actions 模式和 a script containing explicit URLs only 模式这两种模式只是在录制脚本时录制脚本的内容的不同，我想，并没有与上下文无关API和上下文相关API的必然的联系。也许是可能我没有很好的理解。
那在我的脚本里面，肯定是用的 上下文相关API。
刚才又仔细问了开发人员scas的机制：lt由服务器分给，保存在本地cookie中，登录时，提交lt给服务器验证;服务器根据用户名和lt产生ticket令牌。lt，ticket的值不是固定格式 甚至连长度都不是相同。故ticket的值不仅与 lt 相关，还与用户登录的用户名相关。因此，当用户名作了参数化以后，也会引起ticket 处作的关联不匹配。
头大了，只能姑且认为：引入了scas机制，程序变得不可用lr测试。不过，还是希望有人能帮忙解决。
[ Last edited by wghong on 2004-11-9 at 11:45 ] 有人解决这个问题吗？
页:
[1]
