軟件Web測試中容易被忽略的Charset問題

        軟件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、確保你很清楚被測產品的客戶端與服務器如何交互的，并保持清晰的思路，最好在腳本制作前先整理一下你的思路，確保不會象我一樣的糊涂。

原文轉自：http://www.kjueaiud.com