LoadRunner测试Tuxedo协议-CRM系统.docxVIP

Loadrunner测试crm系统 沈希-2011.6.12 普通电话业务 录制脚本 用loadrunner录制两个业务操作一样的脚本，关键的步骤做好注释，具体可参见下面的步骤注释（录制的协议选择tuxedo）： init动作：登录系统； action动作：进入销售门户-选择客户名称点击查询-点击订购-选择普通电话-选择客户证件-验证通过-受理页面进行选址（输入地址ID，方便后续的参数化）-创建客户缴费方式-添加普通电话受理开始事务-点击受理页面的【确定】按钮-待弹出受理成功，是否打印回执窗口时添加普通电话受理结束事务； end动作：关闭受理窗口-注销账户-退出系统； 分析业务中需要关联的参数 【选择客户证件-验证通过】后会弹出受理页面，右上角有预先生成好的订单编码，下拉订单编码，可选择业务号码及订单号，这三个号码其实都是预先生成的，如果不注意，会以为只生成了一个号码；很显然这三个号码是需要关联的，因为录制时产生的订单号是1****1，回放脚本，服务器生成的订单号比如是1****2，而你提交的还是1****1，自然是不能受理成功的； 参数化操作 录制脚本时记录上面三个订单号码，然后在录制好的脚本中的replay.vdf文件中输入三个号码，可以找到其位置； 记录每个号码所对应的buffer，比如下图 那么订单编码200TZ110607968169对应的buffer即84 在脚本action中，输入buffer 84，定位到这行注释，在该注释下面写入获取参数函数lrt_save32_fld_val((FBFR32*)data_6, id=167772666, 0, plan_id);函数各参数的具体意思：(FBFR32*)data_6：获取data6数据包中返回的参数； id=1677772666：要抓取的参数id，该id可到replay中去查找，如上图订单编码的id是167772666 ；0：如果这个id有多个，0就代表去第一个，1就代表取第二个，以此类推； 为什么这个要抓取data_6里面的参数呢？先见录制的原始代码 data_5，是客户端向服务器发包的数据包，里面 都是发给服务器的具体数据，而服务器返回的数据则都存在了data_6中。根据上面的业务分析，所以要抓data_6中的参数； 抓取参数后，加一个打印函数，调试脚本时可见抓取的参数是否正确，代码如下： lr_output_message(返回值:%s,lr_eval_string({plan_id}));【plan_id】则是要打印的参数； 最后替换脚本action中【200TZ110607968169】为｛plan_id｝，订单编码的参数化既完成； 其它两个参数同理去抓取； 调试脚本 调试脚本前，需设置脚本运行的环境变量，具体如下：在vuser_init中，开头加入 lrt_set_env_list(env_allow_array); //添加或修改环境变量的值 lrt_tuxputenv(TUXDIR=D:\\NGCRM\\tuxedo8.1); //TUXDIR的路径设置为本地运行tuxedo的绝对路径 lrt_tuxputenv(WSNADDR=//132.121.150.23:4888); //访问服务的地址，需要带端口 调试脚本-运行-运行后，发现脚本没有任何报错，且日志输出的三个打印的参数也没有问题，OK，肯定还有隐蔽的地方需要参数化，请见下面操作； 这时需要用到之前录制的两个脚本，首先，打开录制好的第一份脚本，然后利用LR提供的对比功能 来对比脚本，找到需要参数化的参数。既打开第二份脚本 我们可以发现，在三个订单编码前有各有一个数据，每次返回是不一样的，其中有条数据是 可见，是上面的5201014865和下面的GZ20000005201014865是有关联的，另外，在脚本action中，搜索5201014865，有多处引用该值，都是提交给服务器的，同样，另外，两个值也一样，所以按照上面参数化方法再参数化这三个参数，即可，最后，完整的代码截图如下 OK，完成这6个参数后，我们再调试脚本，看其是否可以完成业务，结果回放成功，去前台业务查询已经生成订单，多回放几次，则产生相应次数的订单，至此CRM的普通电话的性能测试脚本已完成，后续，需要参数化地址ID，其方法很简单，不阐述； 如果参数化完成后，回放过程中日志报“Error：C interpreter run time error: Action.c(***):Error –memory violation : Exception Access_Violation received” 十有八九不是内存的问题，而是你参数化的位置不对，一般真正需要参数化的地方就在这段buffer前后，而这参数