LoadRunner的Oracle(2-tier)协议脚本排错实例

Wig4A)KX$i$?gu3C0F0   客户方在对一个C/S系统进行测试的时候,使用Oracle(2-tier)协议进行录制,回放脚本时候出错.于是到现场进行脚本排错.因为是隔了很长时间才记录这次排错过程,具体的脚本和错误信息都没有保存,所以记录过程中可能会少些原始脚本和错误的信息.

   1.查看录制的脚本,发现使用该协议是可以录制产生数据库各种操作的脚本,说明协议选择是正确的.

   2.回放时出现一个错误,具体错误信息忘记了.然后就开始从头到尾的分析脚本,因为是第一次接触Oracle(2-tier)这种协议的LR脚本，分析脚本就只能靠帮助以及根据以前的数据库知识经验了。 仔细分析了在出错语句和之前的几个语句。 发现出错语句lrd_ora8_stmt(OraStm1, 。。。)这个函数的第一个参数在前面没有找到定义的地方，然后再看其他执行ＳＱＬ语句的流程，执行这个语句前都需要来分配和初始化LRDDBI Handle.在错误语句前加上lrd_ora8_handle_alloc（）对OraStm1声明,回放脚本,错误消失,问题解决.

u"RV R*ifg s w0  3.被测系统的某个属性需要进行修改,在LR脚本中把该数据进行了参数化.参数使用顺序取值,回放迭代多次,脚本没有报错,但实际上该参数化的属性值只有在第一次回放的时候进行了修改,之后的迭代没有对系统起作用.

~(n2e K;o]x4O8R0  4.分析该操作是SQL语句的更新操作,于是对执行的SQL语句部分进行检查分析.通过和客户沟通以及参考技术文档找到了数据库表和显示界面中各属性的对应关系.然后查看该更新的SQL语句发现,LR录制的SQL更新语句中使用了很多数据库字段为查询条件,除了使用唯一确定该条记录的ID外,还把被修改的字段也作为了查询条件,很明显这样第一次执行的时候是可以执行成功的.但再执行的时候由于该字段内容已经被更新,这样也就找不到以原来更新前的内容为查询条件的记录了. 删除WHERE语句中以被更新内容为条件的这个条件,再次运行LR迭代.脚本成功修改了被测系统的数据.这样所有错误都排除了.

gs];A:Q]/e x0  当然之后就是按照客户要求对该系统进行了性能测试,这个过程没有遇到什么问题,就不多说了.