Charset problems that are easily overlooked in Web Testing

Today, we continue to make a more comprehensive script, recording settings, recording, and Script Modification. Everything went smoothly. After nearly an hour of comparison and modification, OK, the script is done, and you can finally try it out, hey.
Run and replay log everything is normal (Xixi, a small sample, not easily done), look at the server log, dizzy, a bunch of errors, this will not be done directly, it is estimated that there is a problem with the script. the replay log seems to be untrustworthy (because I did not make another judgment ). I found a monitoring tool to check what happened to the request and response. Oh, NULL_POINT_ERROR, null pointer error. No way. troubleshoot it slowly.
Directly operate on the interface, monitor the request and response, and play back the response using the script. The comparison is strange. There is no problem. All the requests are right, but how does one return an error? I had no clue after a long time, so I was depressed! No way. Ask a developer for help. Debuging... my colleague will tell me that the request parameters are garbled during Server Parsing! Shit, what I see in the monitoring tool is clearly normal !!! After further analysis, I finally found that the original http header was a little different and I ignored it, that is, charset. Via web_add_auto_header ("Content-Type", "application/x-www-form-urlencoded; charset = UTF-8"); add charset in all requests, play back, haha, over! I raised my fist, just like the moment when the Olympic world champion won the championship.
However, it turns out that the road to great success is full of ups and downs, and I was hit by another blow. The second half of the script is running again. The strange thing is that the method request has been run before. This time, the transmission parameters are different and the result is incorrect. This will not describe the solution in detail. The problem is that there are two reports in this portlet, and the report ID needs to be associated. The report in front of the result obtains the correct ID through association, and then runs the second report, when I refresh the first report again, the ID of the second report is used, which leads to the error. Alas, Association is a curse.

Summary:
1. If you do not judge the error yourself, the LR replaylog is untrustworthy. Except for HTTP-level errors, the internal server error testing tool cannot be found. You are advised to handle the error by yourself.
2. Pay attention to charset or HTTP Header, which is usually ignored by us. Pay attention to this when you find that all your test script requests are normal but cannot get the correct response. The recording setting method is described in several useful options in the LoadRunner HTTP protocol.
3. Make sure that you have a clear idea of how the client and server of the product to be tested interact, and maintain a clear idea. It is best to sort out your ideas before making the script, make sure you are not confused like me. :)