LoadRunner回放腳本常見問題及解決方法

loadrunner回放腳本常見問題及解決方法

LoadRunner超時錯誤：在錄製Web協議腳本回放時超時情況經常出現，產生錯誤的原因也有很多，解決的方法也不同。

錯誤現象1：Action.c(16): Error -27728: Step download timeout (120 seconds) has expired when downloading non-resource(s)。

錯誤分析：對於HTTP協議，默認的超時時間是120秒（可以在LoadRunner中修改），客戶端發送一個請求到伺服器端，如果超過120秒伺服器端還沒有返回結果，則出現超時錯誤。

解決辦法：首先在運行環境中對超時進行設置，默認的超時時間可以設置長一些，再設置多次迭代運行，如果還有超時現象，需要在「Runtime Setting」>「Internet Protocol：Preferences」>「Advanced」區域中設置一個「winlnet replay instead of sockets」選項，再回放是否成功。

錯誤現象2：Action.c(81):Continuing after Error -27498: Timed out while processing URL=http://172.18.20.70:7001/

workflow/bjtel/leasedline/ querystat/ subOrderQuery.do

錯誤分析：這種錯誤常常是因為並發壓力過大，伺服器端太繁忙，無法及時響應客戶端的請求而造成的，所以這個錯誤是正常現象，是壓力過大造成的。

如果壓力很小就出現這個問題，可能是腳本某個地方有錯誤，要仔細查看腳本，提示的錯誤信息會定位某個具體問題發生的位置。

解決辦法：例如上面的錯誤現象問題定位在某個URL上，需要再次運行一下場景，同時在其他機器上訪問此URL。如果不能訪問或時間過長，可能是伺服器或者此應用不能支撐如此之大的負載。分析一下伺服器，最好對其性能進行優化。

如果再次運行場景後還有超時現象，就要在各種圖形中分析一下原因，例如可以查看是否伺服器、DNS、網路等方面存在問題。

最後，增加一下運行時的超時設置，在「Run-Time Settings」>「Internet Protocol:Preferences」中，單擊「options」，增加「HTTP-request connect timeout」或者「HTTP-request receive」的值。

2．LoadRunner腳本中出現亂碼：在錄製Web協議腳本時出現中文亂碼，在回放腳本時會使回放停止在亂碼位置，腳本無法運行。

錯誤現象：某個鏈接或者圖片名稱為中文亂碼，腳本運行無法通過。

錯誤分析：腳本錄製可能採用的是URL-based scrīpt方式，如果程序定義的字符集合採用的是國際標準，腳本就會出現亂碼現象。

解決辦法：重新錄製腳本，在錄製腳本前，打開錄製選項配置對話框進行設置，在「Recording Options」的「Advanced」選項里先將「Surport Charset」選中，然後選中支持「UTF-8」的選項。

3．LoadRunner HTTP伺服器狀態代碼：在錄製Web協議腳本回放

腳本的過程中，會出現HTTP伺服器狀態代碼，例

如常見的頁面-404錯誤提示、-500錯誤提示。

錯誤現象1：-404 Not Found伺服器沒有找到與請求URI相符的資源，但還可以繼續運行直到結束。

錯誤分析：此處與請求URI相符的資源在錄製腳本時已經被提交過一次，回放時不可再重複提交同樣的資源，而需要更改提交資源的內容，每次回放一次腳本都要改變提交的數據，保證模擬實際環境，造成一定的負載壓力。

解決辦法：在出現錯誤的位置進行腳本關聯，在必要時插入相應的函數。

錯誤現象2：-500 InternalServerError伺服器內部錯誤，腳本運行停止。

錯誤分析：伺服器碰到了意外情況，使其無法繼續回應請求。

解決辦法：出現此錯誤是致命的，說明問題很嚴重，需要從問題的出現位置進行檢查，此時需要此程序的開發人員配合來解決，而且產生的原因根據實際情況來定，測試人員無法單獨解決問題，而且應該儘快解決，以便於後面的測試。

4．LoadRunner請求無法找到：在錄製Web協議腳本回放腳本的過程中，會出現請求無法找到的現象，而導致腳本運行停止。

錯誤現象：Action.c(41): Error -27979: Requested form. not found [MsgId: MERR-27979] Action.c(41): web_submit_form. highest severity level was "ERROR",0 body bytes, 0 header bytes [MsgId: MMSG-27178]" 這時在tree view中看不到此組件的相關URL。

錯誤分析：所選擇的錄製腳本模式不正確，通常情況下，基於瀏覽器的Web應用會使用「HTML-based scrīpt」模式來錄製腳本；而沒有基於瀏覽器的Web應用、Web應用中包含了與伺服器進行交互的JavaApplet、基於瀏覽器的應用中包含了向伺服器進行通信的Javascrīpt/VBscrīpt代碼、基於瀏覽器的應用中使用HTTPS安全協議，這時則使用「URL-based scrīpt」模式進行錄製。

解決辦法：打開錄製選項配置對話框進行設置，在「Recording Options」的「Internet Protocol」選項里的「Recording」中選擇「Recording Level」為「HTML-based scrīpt」，單擊「HTML Advanced」，選擇「scrīpt Type」為「A scrīpt containing explicit」。然後再選擇使用「URL-based scrīpt」模式來錄製腳本。

5．LoadRunner不執行檢查方法：在錄製Web協議腳本中添加了檢查方法Web_find，但是在腳本回放的過程中並沒有執行。

錯誤現象：在腳本中插入函數Web_find，在腳本中設置文本以及圖像的檢查點，但是在回放過程中並沒有對設置的檢查點進行檢查，即Web_find失效。

錯誤分析：由於檢查功能會消耗一定的資源，因此LoadRunner默認關閉了對文本以及

圖像的檢查，所以在設置檢查點後，需要開啟檢查功能。

解決辦法：打開運行環境設置對話

框進行設置，在「Run-time Settings」的「Internet Protocol」選項里的「Perference」中勾選「Check」下的「Enable Image and text check」選項。

6．LoadRunner回放Web Services協議腳本錯誤：LoadRunner 8.0版本在錄製Web Services協議的腳本時正常，但在回放時會出現錯誤，提示停止腳本運行。

錯誤現象：利用LoadRunner 8.0版本來錄製Web Services協議的腳本沒有任何錯誤提示，回放腳本時會出現如下錯誤提示「Error：server returned an incorrectly formatted SOAP response」。

錯誤分析：出現此錯誤的原因是LoadRunner8.0在錄製Web Services協議的腳本時存在一個缺陷：如果伺服器的操作系統是中文的，VuGen會自動將WSDL文件的頭改為<?xml version="1.0"encoding="zh_cn" ?>，所以才會有此錯誤提示。

解決辦法：下載兩個補丁，分別為「LR80WebServicesFPI_setup.exe」和「lrunner_web_ services_patch_1.exe」安裝上即可。

一、Step download timeout (120 seconds)

這是一個經常會遇到的問題，解決得辦法走以下步驟：

1、修改run time setting中的請求超時時間，增加到600s,其中有三項的參數可以一次都修改了，HTTP-request connect timeout，HTTP-request receieve timeout，Step download timeout，分別建議修改為600、600、5000。run time setting設置完了後記住還需要在control組件的option的run time setting中設置相應的參數。

2、辦法一不能解決的情況下，解決辦法如下：

設置runt time setting中的internet protocol-preferences中的advaced區域有一個winlnet replay instead of sockets選項，選項後再回放就成功了。切記此法只對windows系統起作用，此法來自zee的資料。

二、問題描述Connection reset by peer.

這個問題不多遇見，一般是由於下載的速度慢，導致超時，所以，需要調整一下超時時間。

解決辦法：Run-time setting窗口中的『Internet Protocol』－『Preferences』設置set advanced options（設置高級選項），重新設置一下「HTTP-request connect timeout（sec），可以稍微設大一些」。

三、問題描述connection refused

這個的錯誤的原因比較複雜，也可能很簡單也可能需要查看好幾個地方，解決起來不同的操作系統方式也不同。

1、首先檢查是不是連接weblogic服務過大部分被拒絕，需要監控weblogic的連接等待情況，此時需要增加acceptBacklog，每次增加25%來提高看是否解決，同時還需要增加連接池和調整執行線程數，（連接池數*Statement Cache Size）的值應該小於等於oracle資料庫連接數最大值。

2、如果方法一操作後

沒有變化，此時需要去查看伺服器操作系統中是否對連接數做了限制，AIX下可以直接vi文件limits修改其中的連接限制數、埠數，還有tcp連接等待時間間隔大 小，wiodows類似，只不過windows修改註冊表，具體修改註冊表中有TcpTimedWaitDelay和MaxUserPort項，鍵值[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters]。因為負載生成器的性能太好，發數據包特別快，伺服器也響應特別快，從而導致負載生成器的機器的埠在沒有timeout之前就全部佔滿了。在全部佔滿後，就會出現上面的錯誤。執行netstat–na命令，可以看到打開了很多埠。所以就調整TCP的time out。即在最後一個埠還沒有用到時，前面已經有埠在釋放了。

1,這裡的TcpTimedWaitDelay默認值應該中是30s，所以這裡，把這個值調小為5s（按需要調整）。

2,也可以把MaxUserPort調大（如果這個值不是最大值的話）。

四、問題描述open many files

問題一般都在壓力較大的時候出現，由於伺服器或者應用中間件本身對於打開的文件數有最大值限制造成，解決辦法：

1、修改操作系統的文件數限制，aix下面修改limits下的nofiles限制條件，增大或者設置為沒有限制，盡量對涉及到的伺服器都作修改。

2、方法一解決不了情況下再去查看應用伺服器weblogic的commonEnv.sh文件，修改其中的nofiles文件max-nofiles數增大，應該就可以通過了，具體就是查找到nofiles方法，修改其中else條件的執行體，把文件打開數調大。修改前記住備份此文件，防止修改出錯。

3、linux上可以通過ulimit–HSn 4096來修改文件打開數限制，也可以通過ulimit -a來查看。

4、linux上可以通過lsof -p pid | wc -l來查看進程打開的句柄數。

五、問題描述has shut down the connection prematurely

一般是在訪問應用伺服器時出現，大用戶量和小用戶量均會出現。

來自網上的解釋：

1>應用訪問死掉

小用戶時：程序上的問題。程序上存在資料庫的問題

2>應用服務沒有死

應用服務參數設置問題

例如：

在許多客戶端連接Weblogic應用伺服器被拒絕，而在伺服器端沒有錯誤顯示，則有可能是Weblogic中的server元素的AcceptBacklog屬性值設得過低。如果連接時收到connection refused消息，說明應提高該值，每次增加25％

Java連接池的大小設置，或JVM的設置等

3>資料庫的連接

在應用服務的性能參數可能太小了

資料庫啟動的最大連接數（跟硬體的內存有關）

以上信息有一定的參考價值，實際情況可以參考此類調試。

如果是以上所說的小用戶時：程序上的問題。程序上存在資料庫的問題，那就必須

採用更加專業的工具來抓取出現問題的程序，主要是程序中執行效率很低的sql語句，weblogic可以採用introscope定位，期間可以注意觀察一下jvm的垃圾回收情況看是否正常，我在實踐中並發500用戶和600用戶

時曾出現過jvm鋸齒型的變化，上升下降都很快，這應該是不太正常的。

實際測試中，可以用telent站點看看是否可以連接進去，可以通過修改連接池中的連接數和適當增加應用內存值，問題可以解決。

六、問題描述Failed to connect to server

這個問題一般是客戶端鏈接到服務失敗，原因有兩個客戶端連接限制（也就是壓力負載機器），一個網路延遲嚴重，解決辦法：

1、修改負載機器註冊表中的TcpTimedWaitDelay減小延時和MaxUserPort增加埠數。註：這將增加機器的負荷。

2、檢查網路延遲情況，看問題出在什麼環節。

建議為了減少這種情況，辦法一最好測試前就完成了，保證乾淨的網路環境，每個負載機器的壓力測試用戶數不易過大，盡量平均每台負載器的用戶數，這樣以上問題出現的概率就很小了。

七、問題描述Overlapped transmission of request to ... WSA_IO_PENDING

這個問題，解決方法：

1、方法一，在腳本前加入web_set_sockets_option("OVERLAPPED_SEND", "0")，禁用TTFB細分，問題即可解決，但是TTFB細分圖將不能再使用，附圖。

2、方法二，可以通過增加連接池和應用系統的內存，每次增加25%。

八、問題描述Deleted the current transaction ... since response time is not accurate

這個問題不多遇見，一般出現在壓力機器上發生ping值為負數（AMD雙核CPU），可以重新啟動pc機或者打補丁，附圖。

九、問題描述HTTP Status-Code=500 (Internal Server Error) for

應用服務掛掉，重新啟動應用服務。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！