今天继续进行一个更综合的脚本制作,录制设置、进行录制、脚本修改,一切都轻车熟路,进行得很顺利。经过近一个小时的对比和修改,OK,脚本大功告成,终于可以小试牛刀了,嘿嘿。
    运行,replay log一切正常(窃喜,小样,还不轻松搞定),看看服务器log,晕,一堆错误,这在直接操作时是不会的,估计脚本有问题,replay log看来是信不过的了(因为我没做另外的判断处理)。找了监控工具来查看请求和响应到底是怎么回事。哦,NULL_POINT_ERROR,空指针错误。没办法,慢慢排查咯。
    直接界面操作并监控请求和响应,再用脚本回放一下,对比,奇怪,没什么问题啊,所有的请求都很对,但怎么偏偏返回就出错了呢?折腾了半天没找出头绪,郁闷!没办法,找开发的同事帮忙吧。debuging...一会同事告诉我,请求的参数在服务器的解析中有乱码!shit,我在监控工具中看到的明明是正常的啊!!!再次分析,终于发现,原来http头一点不同,被我忽略了,那就是charset。通过web_add_auto_header("Content-Type","application/x-www-form-urlencoded;charset=UTF-8");在所有请求中自动添加上charset,回放,哈哈,过了!我举起了拳头,如同奥运会的世界冠军夺冠的那一刻。
    但是,事实证明,通往伟大的成功之路充满了坎坷,接着,我又受到了另一个打击。脚本后半部分运行中又出现了问题。比较奇怪的是这个方法请求前面都已经运行通过了,这次只是传输的参数不同,结果就错误了。这个就不再详细描述解决过程了,问题就是这个portlet中有两个报表,报表ID需要关联,结果前面的报表通过关联获取了正确的ID,然后执行第二个报表,当我再次刷新第一个报表的时候用的确是第二个报表的ID,这就导致了该错误。唉,都是关联惹得祸。
   
    总结:
    1、如果你自己没有进行错误判断,那么LR replaylog是信不过,因为除了HTTP级别的错误,服务器内部报错测试工具是无法发现的,最好自己处理。
    2、关注charset,或者说是HTTP Header的问题,这通常都会被我们所忽视。当你发现你的测试脚本的请求都很正常,但无法得到正确的响应时,请留意这一点。在LoadRunner HTTP协议中几个有用的选项一文中描述了录制设置方法。
    3、确保你很清楚被测产品的客户端与服务器如何交互的,并保持清晰的思路,最好在脚本制作前先整理一下你的思路,确保不会象我一样的糊涂。:)