最近在測試過程中使用LoadRunner錄制Socket協議腳本，在data.ws中，中文參數顯示為亂碼，直接影響到參數化等操作，導致壓力測試無法繼續下去。本文對錄制腳本的亂碼問題進行了相關調研。
使用LoadRunner錄制的腳本如下：
通過在網上搜索資源，查詢到幾種解決方案如下：
■ 方法一：通過字符串編碼轉換的函數修改腳本中的亂碼；
通過一個字符串編碼轉換的函數lr_convert_string_encoding
在LoadRunner中，為我們提供了一個字符串編碼轉換的函數lr_convert_string_encoding，它可以把字符編碼轉換為UTF-8格式。
測試組人員通過對比發現，這個函數是在錄制的腳本中出現亂碼時使用的，例如：
web_custom_request("CALL-H001I",
"EncType=text/xml; charset=UTF-8",
"BodyBinary=CALLH001I1040浣忔埧01
鏆傛棤鍙風爜1
11000000
1000000.00A110102641122043#1闇嶈景榫"
"""x99"
"10001鍘﹂棬100 |
但本次遇到的問題是在錄制結束后，data.ws文件的中文參數顯示為亂碼。問題仍然得不到解決。
■ 方法二：錄制選項中的Support charset選中UTF-8再重新錄制
這種方法是在錄制前，將錄制選項的Support charset選中UTF-8后進行錄制，這種方法主要適用于WEB頁面錄制時的場景。在錄制使用Socket協議時，錄制選項中沒有Support charset，導致問題也不能解決。
■ 方法三：更改服務器操作系統的語言
將操作系統語言修改為英語，重啟機器后，重新錄制腳本，亂碼問題即可解決。
但實際情況是，將操作系統語言改為英語后，重啟機器，重新錄制腳本，亂碼只是變換了一種形式而已（且文件名稱或目錄中有中文時會顯示成“？？”），問題仍然無法解決。
■ 最終解決方法
網上也有資料說這個問題無法解決(汗!!!)，因為錄制Socket協議是LoadRunner直接監控TCP這一層的數據流，任何數據，雖然在最頂層應用層時是可見數據，但是一旦到了TCP層，均被封包成二進制。
所以呢，看來要用LoadRunner來測試Socket，還是得通過手寫腳本的方式來實現。方法呢，其實很簡單。看下一篇吧！