LoadRunner脚本中的乱码问题以及解决办法
相信有不少人在使用LoadRunner的过程中都遇到过这样的问题:在录制下来的脚本的中文信息出现了乱码。关于乱码问题,可能大家在网上也能搜到不少相关的解决办法,我在这里就不多说了,大家自己去试验一下吧,到底哪个办法有效也就只有谁用谁知道了!我这里只举一个自己遇到的实际例子来说这个问题,也许不是解决这个问题的唯一办法,但至少也是其中的一个吧。    被测系统采用Ajax技术,通过录制下来的脚本看起来像下面的样子(省略函数其它部分,下同):   
 web_custom_request("CALL-H001I",     
  "EncType=text/xml; charset=UTF-8",       
 "BodyBinary=CALLH001I1040浣忔埧01鏆傛棤鍙风爜<PAPERGRantorgan>1110000001000000.00A110102641122043#1闇嶈景榫""""x99"        "10001鍘﹂棬100A1442000050031"r"n"        "",        LAST);   
 从上面脚本的黑体部分可以看出,LoadRunner服务器提交的请求body部分,输入的中文字段被变成了诸如浣忔埧这样的乱码。遇到这样的情况,相信大多数人和我最开始一样,只能
不加理会,直接点击回放,然后我们很高兴地发现,脚本回放成功了!这些乱码是可以被LR识别的,而且到应用系统中查看运行的结果,也没有问题,显示的是正确的中文。但是且慢!先不要高兴得太早,我们很快就会意识到:如果这个字段我们是需要进行参数化的怎么办?我们应该如何造出这种乱码的字呢?   
首先,我们直接用正常的字去参数化,这里只举其中的一个例子来说明,比如这个字段,我们用参数值汽车直接在脚本中替换浣忔埧,脚本回放失败。然后就想到会不会是所有的中文字段都需要用才行呢?于是把所有的乱码都用简体字替换,脚本回放还是失败。 
 
 通过以上的两点试验,说明直接参数化的方法是行不通的,我们必须另办法。在LoadRunner中,为我们提供了一个字符串编码转换的函数lr_convert_string_encoding,用法如下:    int lr_convert_string_encoding ( const char *sourceString, const char *fromEncoding, const char *toEncoding, const char *paramName);    该函数有4个参数,含义如下:    sourceString:被转换的源字符串。    fromEncoding:转换前的字符编码。     
toEncoding:要转换成为的字符编码。     
paramName:转换后的目标字符串。     
在本例中可以看到,我们需要把字符编码转换为UTF-8格式,因此用法如下:    lr_convert_string_encoding("汽车",LR_ENC_SYSTEM_LOCALE,LR_ENC_UTF8,"str");    这样一来,就成功地完成了字符串的编码转换。此时我们就可以对"汽车"这个参数进行参数化,参数化的方法很简单,地球人都知道!于是最终的脚本编码看起来像这样:    lr_convert_string_encoding("lr_eval_string("{name}"),LR_ENC_SYSTEM_LOCALE,LR_ENC_UTF8,"str");   
完整的示例代码如下:    char string[5000];    char tmp[10];    lr_convert_string_encoding(lr_eval_string("{name}"),LR_ENC_SYSTEM_LOCALE,LR_ENC_UTF8,"str");    strcpy(tmp,lr_eval_string("{str}"));                                 
 sprintf(string,"BodyBinary=CALLH001I1040%s01鏆傛棤鍙风爜1110000001000000.00A110102641122043#1闇嶈景榫""x9910001鍘﹂棬100A1442000050031"r"n",tmp);    web_custom_request("CALL-H001I",       
 "EncType=text/xml; charset=UTF-8",        string,        LAST);
1 介绍

LoadRunner性能测试过程中其中最重要的一个环节是VUG的脚本开发,在脚本开发过程中一项很重的技术就是脚本的参数化,那么什么是参数化如何进行参数化,使我们需要掌握的。所谓的参数化就是需要将脚本中静态的值通过某种操作转换为动态的值,可以将原来的一个值由一组数据来代替,一次来满足测试脚本访问的多元化,比如我们可以将用户名和密码进行参数化,这样就可以模拟多个注册用户的登陆访问行为;同样的如果我们将其中的某些信息参数化后,可以模拟不同的业务行为等等。在本个专题中我们来帮助大家解决以下的问题:

1 参数化的基本过程及其在过程中需要注意的事项参数化的定义参数的创建通过数据库方式创建参数的过程通过数据文件创建参数的过程

2 File类型参数化的选择方式通过这部分我们可以清楚地指导在File参数类型中参数是如何
进行选择的,不同的选择方式和不同的更新方式如何配合。

3 File类型中Unique参数选择类型的详解通过这篇文章我们可以清楚地了解在File类型中Unique参数选择方式是如何分配参数如何对参数进行选择的。

2 参数化的基本过程及其在过程中需要注意的事项

以下这篇文章介绍了LR参数化的过程方法,以及在每个步骤中具体的实施步骤,写得很不错:

www.ltesting/html/18/n-156918.html

3 File类型参数化的选择方式

以下这篇文章通过一个实验很好的给大家解释File的参数类型如何选择,以及选择和在不同
的迭代过程中如何进行参数的选择:

www.ltesting/html/16/n-156916.html

4 File类型中Unique参数选择类型的详解

以下这篇文章是测试时代14期的一个学生——周春梅写得原创,此篇文章详细的介绍了在File类型参数中Unique中如何进行参数的选择,以及在不同情况下参数的选取情况,详细参见以下文章:

www.ltesting/html/17/n-156917.html

5 编者语

 LR脚本中参数化过程是一个很重要的过程,在实际的性能测试过程中应用很多,通过上述
的这些文章我们可以对LR中的参数化功能有很好的理解,通过这个专题可以掌握LR的参数化过程和执行参数化的方法。
  错误预防和恢复
参数默认是用{}括起来的,但也可以指定用<>
NTLM或用户登录验证
web_set_user("X\\Y", "Z", "A:80");
在域与X上的用户名为Y的用户,使用密码Z来登录到A:80。在windows基本验证的时候这个脚本被默认录制下来,但如果web服务器需要更安全NTLM或更深层次的验证,需要手动的添加这个函数到脚本中。对于NTML验证,用户名必须在域名之后,并且以\分割。使用\等符号,需要使用\\,前面的\用来做转义用,否则会出现警告提示。
 
在论坛中也看到了一些朋友讨论windows弹出登录框的操作LR无法录制到,导致回放出错,
一般出错信息多为Error -26547: Authentication required, please use web_set_user, e.g. web_set_user("domain\\user", "password", "host:port");  [MsgId: MERR-26547]”,其实这种情况错误信息已经很明显的给你提示了,需要往脚本中添加web_set_user函数即可。
 
2  IP欺骗(略)
3  验证检查点
通常脚本录制完后需要手动添加些脚本来来确保预期的操作确实进行了正确的响应(如在操作之后后验证显示的一段文本或者图片)。这些检查可以使用正则表达式。
Web虚拟用户脚本中不会录制到检查点,需要手动添加或者使用VuGen的用户接口来添加函数代码。
最常用的检查点函数是web_reg_find。这个注册函数会查脚本中下一个操作如web_url后产生的一段文本。它是从返回的缓冲区扫描而不是在接收的页面中查。这是比web_find更高效的一个函数。
可以使用下面的代码来验证文本出现的次数:
web_reg_find("Text=ABC", "SaveCount=abc_count", LAST);
web_url("Step", "URL=...", LAST);
if (strcmp(lr_eval_string("{abc_count}"), "0") == 0)
软件乱码怎么办lr_output_message("not found");

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。