Web测试中容易被忽略的Charset问题

今天继续进行一个更综合的脚本制作，录制设置、进行录制、脚本修改，一切都轻车熟路，进行得很顺利。经过近一个小时的对比和修改，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、确保你很清楚被测产品的客户端与服务器如何交互的，并保持清晰的思路，最好在脚本制作前先整理一下你的思路，确保不会象我一样的糊涂。：）