LR常見問題整理

1.LoadRunner錄製腳本時爲何不彈出IE瀏覽器?

　　當一臺主機上安裝多個瀏覽器時，LoadRunner錄製腳本常常遇到不能打開瀏覽器的狀況，能夠用下面的方法來解決。

　　
LR11 沒法彈出ie瀏覽器，或者ie已中止工做問題的解決方法彙總 .
1）系統屬性，高級選項卡下，性能裏面，單擊設置按鈕，修改數據執行保護爲「只爲關鍵windows程序和服務啓用數據執行保護」，而後，重啓； 上述方法我採用了第一個，重啓後問題解決。

2）若果被測試系統在本機上，訪問地址爲：http://127.0.0.1：端口/程序名稱，須要將URL改成：http://localhost：端口/程序名稱，這樣就能夠產生腳本了。這個現象我也以爲很奇怪，不知道到底爲何？可是，改爲（http://localhost：端口/程序名稱）的確能夠產生腳本了，呵呵！

3）lr自己的穩定性，再加上在系統中安裝軟件時有可能會將其註冊表修改掉，尤爲是安裝dotnet2005的時候，致使lr錄製腳本時不能彈出IE頁面。其實單就這個問題來看，主要是LR的註冊信息被修改，沒法找到IE路徑。如何從新註冊LR呢？關閉loadrunner和IE，在lr的安裝目錄（例如D:\Program Files\Mercury\LoadRunner\bin）下，單擊register_vugen.bat文件，而後重啓loadrunner，嘗試錄製。
4）IE->工具->internet選項->高級 ,把"啓用第三方瀏覽器擴展"前面的勾取消掉,再"肯定".重啓一次IE也許能夠解決；

5）若是實在被逼無奈。請重裝系統，重裝loadrunner。

　　2.錄製Web腳本時，生成的腳本中存在亂碼該如何解決?

　　錄製腳本前，打開錄製選項配置對話框Record-Options，進入到Advanced標籤，先勾選「Support charset」，而後選擇中支持UTF-8。再次錄製，就不會出現中文亂碼問題了。

　　3.HTML-based script與URL-based script的腳本有什麼區別?

　　使用「HTML-based script」的模式錄製腳本，VuGen爲用戶的每一個HTML操做生成單獨的步驟，這種腳本看上去比較直觀;使用「URL-based script」模式錄製腳本時，VuGen能夠捕獲全部做爲用戶操做結果而發送到服務器的HTTP請求，而後爲用戶的每一個請求分別生成對應方法。

　　一般，基於瀏覽器的Web應用會使用「HTML-based script」模式來錄製腳本;而沒有基於瀏覽器的Web應用、Web應用中包含了與服務器進行交互的Java Applet、基於瀏覽器的應用中包含了向服務器進行通訊的JavaScript/VBScript代碼、基於瀏覽器的應用中使用了HTTPS安全協議，這時使用「URL-based script」模式進行錄製。

　　4.爲何腳本中添加了檢查方法Web-find，可是腳本回放時卻沒有執行?

　　因爲檢查點功能會耗費必定的資源，所以LoadRunner默認關閉了對文本及圖像的檢查。要想開啓檢查功能，必須修改運行時的配置Run-time Setting。

　　進入「Run-time Setting」對話框，依次進入「Internet Protocol→Preferences」，勾選Checks下的「Enable Image and text check」選項便可。

　　檢查執行結果時推薦使用web_reg_find方法。

　　5.運行時的Pacing設置主要影響什麼?

　　Pacing主要用來設置重複迭代腳本的間隔時間。共有三種方法：上次迭代結束後馬上開始、上次迭代結束後等待固定時間、按固定或隨機的時間間隔開始執行新的迭代。

　　根據實際須要設置迭代便可。一般，沒有時間間隔會產生更大的壓力。

　　6.運行時設置Log標籤中，若是沒有勾選「Enable logging」，則手工消息能夠發送嗎?

　　Enable logging選項僅影響自動日誌記錄和經過lr_log_message發送的消息。即便沒有勾選，虛擬用戶腳本中若是使用lr_message、lr_output_message、lr_error_message,仍然會記錄其發出的消息。

　　7.LoadRunner 8.0版本的VuGen在錄製Web Services協議的腳本時一切正常，而回放時報出錯誤提示「Error：server returned an incorrectly formatted SOAP response」。這時說明緣由引發的?

　　形成這種狀況的主要緣由是LoadRunner 8.0的VuGen在錄製Web Service協議的腳本時存在一個缺陷：若是服務器的操做系統是中文的，VuGen會自動將WSDL文件的頭改成，所以會有上面的錯誤提示。

　　解決方法：把「LR80WebservicesFPI_setup.exe」和「lrunner_web_sevices_path_1.exe」兩個補丁打上便可解決。

　　8.VuGen支持Netscape的客戶證書嗎?

　　不支持。目前的VuGen 8.0版本中僅支持Internet Explorer的客戶端證書。錄製腳本時能夠先從Netscape中導出所需的證書，而後將其導入到Internet Explorer中，並確保以相同的順序導出和導入這些證書。並且，在每臺將要錄製或運行須要證書的Web Vuser腳本的計算機上都要重複執行前面的過程。

　　9.VuGen會修改錄製瀏覽器中的代理服務器設置嗎?

　　會修改。在開始錄製基於瀏覽器的Web Vuser腳本時，VuGen首先會啓動指定的瀏覽器。而後，VuGen會指示瀏覽器訪問VuGen代理服務器。爲此，VuGen會修改錄製瀏覽器上的代理服務器設置。默認狀況下，VuGen會當即將代理服務器設置更改成Localhost:7777。錄製以後，VuGen會將原始代理服務器設置還原到該錄製瀏覽器中。所以，在VuGen進行錄製的過程當中，不能夠更改代理服務器設置，不然將沒法正常進行。

　　10.在LoadRunner腳本如何輸出當前系統時間?

　　LoadRunner提供了char *ctime(const time_t *time)函數，調用參數爲一個Long型的整數指針，用於存放返回時間的數值表示。

　　調用語句與返回值以下示例：

　　typedef long time_t;

　　Action()

　　{

　　time_t t;

　　lr_message(「Time in seconds since 1/1/70: %ld\n」,time(&t));

　　lr_message(「System time and date: %s」,ctime(&t));

　　}

　　輸出結果爲：

　　Time in seconds since 1/1/70: 1185329968

　　System time and date:Wed Jul 25 10:19:28 2007

　　11.一些Web虛擬用戶腳本錄製後馬上回放沒有任何問題，可是當設置迭代次數大於1時，若是進行回放則只能成功迭代一次。爲何從第二次迭代開始發生錯誤?

　　這種現象可能是因爲在「Run-time Setting」的「Browse Emulation」的設置中，勾選了「Simulate a new user on each iteration」及其下面的選項「Clear cache on each iteration」這兩個選項的含義是每次迭代時模擬一個新的用戶及每次迭代時清除緩存。

　　因爲腳本迭代時，init和end只能執行一次，若是每次迭代都模擬一個新的用戶並清除緩存，則用戶登陸信息將一併清除，所以迭代時可能會發生錯誤。

　　12.虛擬客戶腳本「Run-time Setting」中的線程和進程運行方式的區別?

　　若是選擇「Run Vuser as a process」，則場景運行時會爲每個虛擬用戶建立一個進程;選擇「Run Vuser as a thread」則將每一個虛擬用戶做爲一個線程來運行，在任務管理器中只看到一個mmdrv.exe，這種方式的運行效率更高，能形成更大的壓力，時默認選項。

　　另外，若是啓用了IP欺騙功能，則先在Controller中選中Tools菜單下的「Expert Mode」，而後將Tools菜單下的「Options>General」標籤頁中的IP地址分配方式也設置爲與Vuser運行方式一致，同爲線程或進程方式。

　　13.在Controller中運行Web相關測試場景時，常常會有不少超時錯誤提示，如何處理這類問題?

　　這主要有腳本的默認超時設置引發。當回放Web腳本時，有時候因爲服務器響應時間較長，會產生超時的錯誤。這時須要修改腳本的運行時配置。

　　進入「Run-time Setting」對話框後，依次進入「Internet Protocol→Preference」。而後點擊「Options…」按鈕，進入高級設置對話框，能夠修改各種超時設置的默認值。

　　14.爲何Windows系統中的CPU、內存等資源仍然充足，可是模擬的用戶數量卻上不去?

　　在Windows計算機的標準設置下，操做系統的默認限制只能使用幾百個Vuser，這個限制與CPU或內存無關，主要是操做系統自己規定了默認的最大線程數所致使。要想突破Windows這個限制，須修改Windows註冊表。以Windows XP Professional爲例。

　　(1)打開註冊表後，進入註冊表項HKEY_LOCAL_MACHINE中的下列關鍵字：System\CurrentControlSet\Control\Session Manager\SubSystems。

　　(2)找到Windows關鍵字，Windows關鍵字以下所示：

　　%SystemRoot%\system32\csrss.exe bjectDirectory=\Windows

　　SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1

　　ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2

　　ProfileControl=Off MaxRequestThreads=16

　　SharedSection=1024,3072,512關鍵字的格式爲xxxx,yyyy,zzz。其中，xxxx定義了系統範圍堆的最大值(以KB爲單位)，yyyy定義每一個桌面堆得大小。

　　(3)將yyyy的設置從3072更改成8192(即8MB)，增長SharedSection參數值。

　　經過對註冊表的更改，系統將容許運行更多的線程，於是能夠在計算機上運行更多的Vuser。這意味着可以模擬的最大併發用戶數量將不受Windows操做系統的限制，而只受硬件和內部可伸縮性限制的約束。

 

15. 錄製腳本爲空
　
　　LR錄製是客戶端與服務器的數據交互，只有在有交互的時候才能夠錄製到腳本。
　
　　1）交互方式不同，經過客戶端的server進行交互，在scrīpt中選擇最後一個track processes created as COM local servers [選擇scrīpt裏的最後一個選項]. 2. 非客戶端與服務器的交互的一種操做，在頁面上點前進或後退，若是頁面是從緩存中取出來的，那麼也就沒有和服務器數據交互，因此也錄製的爲空腳本。 [windows註冊表中禁用緩存]. 3. 協議選擇錯誤，b/s不必定走http協議，還多是https（http+ssl）。 [最基礎的錯誤].錄製出錯。
　
　　2） 選擇internet裏選項裏的鏈接裏的局域網設置的代理不能選，由於LR在錄製的時候會動態選擇。
　
　　3） 網頁裏的惡意代碼，檢測的時候響應LR錄製腳本[用工具檢測惡意代碼，而後卸載惡意代碼，eg：Ad_Aweare].

　　4）防病毒軟件和防火牆，在錄製時暫時關閉。
　
　　5） 由於LR自身緣由報錯或者有些腳本不能錄製下來[錄製是最好選用scrīpt view，此時會報錯，但能寫下腳本，是由於LR沒法解析，能夠手工修改，而tree view 就直接中止了。
　
　16.　Loadrunner不支持默認的瀏覽器
　
　　有時候，咱們上網的時候，不當心會將某個瀏覽器設置爲默認的瀏覽器，而咱們不知道，這個時候，咱們用loadrunner進行錄製的時候，會提示loadrunner不支持系統設置的默認的瀏覽器，所以，須要咱們從新選擇瀏覽器，咱們能夠利用Reconding optiom中的Browser選項設置支持的瀏覽器，咱們還能夠利用下面的方法，將IE設置爲默認的瀏覽器，由於loadrunner是支持IE的。設置方法以下：
　
　　在IE「工具（T）」菜單→「Interner選項」→「程序」選項卡里，確保「檢查Internet Explorer是否爲默認的瀏覽器」選項打上√。而後在你啓動IE時，若是IE非默認瀏覽器就會出現提示窗是否把IE設置爲默認。

 

 

1、Step download timeout (120 seconds)

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

一、修改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中設置相應的參數。

二、辦法一不能解決的狀況下，解決辦法以下：

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




2、問題描述Connection reset by peer.

這個問題很少碰見，通常是因爲下載的速度慢，致使超時，因此，須要調整一下超時時間。

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



3、問題描述connection refused

這個的錯誤的緣由比較複雜，也可能很簡單也可能須要查看好幾個地方，解決起來不一樣的操做系統方式也不一樣。

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

二、若是方法一操做後沒有變化，此時須要去查看服務器操做系統中是否對鏈接數作了限制，AIX下能夠直接vi文件limits修改其中的鏈接限制數、端口數，還有tcp鏈接等待時間間隔大小，wiodows相似，只不過windows修改註冊表，具體修改註冊表中有TcpTimedWaitDelay和MaxUserPort項，鍵值在[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\]。由於負載生成器的性能太好，發數據包特別快，服務器也響應特別快，從而致使負載生成器的機器的端口在沒有timeout以前就所有佔滿了。在所有佔滿後，就會出現上面的錯誤。執行netstat –na命令，能夠看到打開了不少端口。因此就調整TCP的time out。即在最後一個端口尚未用到時，前面已經有端口在釋放了。

1,這裏的TcpTimedWaitDelay默認值應該中是30s，因此這裏，把這個值調小爲5s（按須要調整）。
2,也能夠把MaxUserPort調大（若是這個值不是最大值的話）。




4、問題描述open many files

問題通常都在壓力較大的時候出現，因爲服務器或者應用中間件自己對於打開的文件數有最大值限制形成，解決辦法：

一、修改操做系統的文件數限制，aix下面修改limits下的nofiles限制條件，增大或者設置爲沒有限制，儘可能對涉及到的服務器都做修改。

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

三、linux上能夠經過ulimit –HSn 4096來修改文件打開數限制，也能夠經過ulimit -a 來查看。

四、linux上能夠經過lsof -p pid | wc -l 來查看進程打開的句柄數。




5、問題描述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 站點看看是否能夠鏈接進去，能夠經過修改鏈接池中的鏈接數和適當增長應用內存值，問題能夠解決。




6、問題描述Failed to connect to server

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

一、修改負載機器註冊表中的TcpTimedWaitDelay減少延時和MaxUserPort增長端口數。注：這將增長機器的負荷。

二、檢查網絡延遲狀況，看問題出在什麼環節。

建議爲了減小這種狀況，辦法一最好測試前就完成了，保證乾淨的網絡環境，每一個負載機器的壓力測試用戶數不易過大，儘可能平均每臺負載器的用戶數，這樣以上問題出現的機率就很小了。



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

這個問題，解決方法：

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



二、方法二，能夠經過增長鏈接池和應用系統的內存，每次增長25%。

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

這個問題很少碰見，通常出如今壓力機器上發生ping值爲負數（AMD雙核CPU），能夠從新啓動pc機或者打補丁，附圖。



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

一、應用服務當掉，從新啓動應用服務。

二、當應用系統處於的可用內存處於閥值如下時，出現HTTP Status-Code=500的機率很是高，此時只要增長應用系統的內存，問題便可解決。



10、問題描述Failed to transmit data to network: [10057]Socket is not connected

這個錯誤是由網絡緣由形成的，PC1和PC2上面都裝了相同的loadrunner 9.0，且以相同數量的虛擬用戶數運行相同的業務（機器上的其餘條件都相同），PC1上面有少部分用戶報錯，PC2上的用戶所有執行經過。




11、問題描述 Error -27257: Pending web_reg_save_param/reg_find/create_html_param[_ex] request(s) detected and reset at the end of iteration number 1
解決方法：web_reg_save_param位置放錯了，應該放到請求頁面前面。
12、問題描述 經過Controler調用遠程代理時報錯，Error: CCI security error:You are running under secure mode and the function system is not allowed in this mode.
解決方法：在代理開啓的時候，去掉勾選防火牆選項。

1．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 script方式，若是程序定義的字符集合採用的是國際標準，腳本就會出現亂碼現象。

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

3．LoadRunner HTTP服務器狀態代碼：在錄製Web協議腳本回放腳本的過程當中，會出現HTTP服務器狀態代碼，例如常見的頁面-404錯誤提示、-500錯誤提示。

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

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

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

錯誤現象2：-500 Internal Server Error服務器內部錯誤，腳本運行中止。

錯誤分析：服務器碰到了意外狀況，使其沒法繼續迴應請求。

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

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 script」模式來錄製腳本；而沒有基於瀏覽器的Web應用、Web應用中包含了與服務器進行交互的Java Applet、基於瀏覽器的應用中包含了向服務器進行通訊的JavaScript/VBScript代碼、基於瀏覽器的應用中使用HTTPS安全協議，這時則使用「URL-based script」模式進行錄製。

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

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」安裝上便可。

1. error:missing newline in d:\loadrunner\name.dat

場景執行時報error:missing newline in d:\loadrunner\name.dat

第二次執行不報

兩個解決辦法：

第一：若是參數不是不少的話，不要打開記事本去編輯參數，就直接在LR提供的參數的表格中進行編輯便可。

第二：若是參數不少超過100條的話。在記事本中編輯好了以後，記着在最後一個參數後打個回車，讓鼠標的光標移動到下一行。

2.load generator is currently running the maximum number of vuser of this type

使用的是loadrunner8.0，有10000個用戶的web的license，global的有10個。

在測試的時候發現running vuser到達1000之後就不能再提升，後面的vuser就會出錯。錯誤是「The load generator is currently running the maximum number of vuser of this type」.

已經能夠排除是load generator機器自己資源的問題。由於換了性能比較強的酷睿2仍是一樣的問題，CPU和memory都有空閒。

解決辦法:

在load generator中有一個Vuser limits tab，能夠設置running user的最大數目。 即設置 load generator----Details------Vuser limits ----Other Vusers 的最大參數

3.LoadRunner 常見問題：

（1）sofeware caused connction：這種狀況，通常是腳本有問題，或者loadrunner有問題。解決方法：從新啓動機器，或者從新錄製腳本，估計是loadrunner的bug。

（2）cannot connect to server:沒法鏈接到服務器。這種狀況是服務器的配置有問題，服務器沒法承受過多的併發鏈接了。須要優化服務器的配置，

如操做系統採用windows 2003 server，

優化tomcat配置：maxThreads="500" minSpareThreads="400" maxSpareThreads="450"。可是tomcat 最多支持500個併發訪問

優化apache配置：

ThreadsPerChild 1900

MaxRequestsPerChild 10000

其餘的錯誤如：

Action.c(10): Error -27791: Server has shut down the connection prematurely

HTTP Status-Code=503 (Service Temporarily Unavailable)

通常都是因爲服務器配置不夠好引發的，按照問題（2）處理，若是仍舊不行，須要優化硬件和調整程序了。

Apache問題：

（1） File does not exist: C:/Apache/htdocs/favicon.ico：

這個問題是apache，htdocs目錄沒有favicon.ico文件引發的，該文件是網站的圖標，僅在firefox,myIE等瀏覽器出現。

（2） 圖片沒法顯示：

配置apache後，卻沒法顯示圖片。

解決方法：把程序的圖片，按照程序結構copy到apache的htdocs目錄下。

（3） 沒法處理請求：

當咱們輸入 ***.do 命令後，apache確返回錯誤信息，而鏈接tomcat卻沒有問題。緣由是沒有把.do命令轉發給tomcat處理。解決方法以下：

在apache配置文件中配置以下內容：

DocumentRoot "C:/Apache/htdocs"

JkMount .jsp loadbalancer

JkMount .do loadbalancer

四、Step download timeout (120 seconds)

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

　　一、 修改run time setting中的請求超時時間，增長到600s,其中有三項的參數能夠一次都修改了，HTTP-request connect timeout，HTTP-request receieve timeout，Step download timeout，分別建議修改成600、600、5000；run time setting設置完了後記住還須要在controler組件的option的run time setting中設置相應的參數；

　　二、 辦法一不能解決的狀況下，解決辦法以下：

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

五、問題描述Connection reset by peer　　這個問題很少碰見，通常是因爲下載的速度慢，致使超時，因此，須要調整一下超時時間。

　　解決辦法：Run-time setting窗口中的‘Internet Protocol’－‘Preferences’設置set advanced options（設置高級選項），從新設置一下「HTTP-request connect timeout（sec），能夠稍微設大一些」；

六、問題描述connection refused　　這個的錯誤的緣由比較複雜，也可能很簡單也可能須要查看好幾個地方，解決起來不一樣的操做系統方式也不一樣；

　　一、首先檢查是否是鏈接weblogic服務過大部分被拒絕，須要監控weblogic的鏈接等待狀況，此時須要增長acceptBacklog，每次增長 25%來提升看是否解決，同時還須要增長鏈接池和調整執行線程數，（鏈接池數*Statement Cache Size）的值應該小於等於oracle數據庫鏈接數最大值；

　　二、若是方法一操做後沒有變化，此時須要去查看服務器操做系統中是否對鏈接數作了限制，AIX下能夠直接vi文件limits修改其中的鏈接限制數，還有 tcp鏈接等待時間間隔大小，wiodows相似，只不過wendows修改註冊表，具體修改方法查手冊，註冊表中有TcpDelayTime項；

七、問題描述open many files

　　問題通常都在壓力較大的時候出現，因爲服務器或者應用中間件自己對於打開的文件數有最大值限制形成，解決辦法：

　　一、修改操做系統的文件數限制，aix下面修改limits下的nofiles限制條件，增大或者設置爲沒有限制，儘可能對涉及到的服務器都做修改；

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

八、問題描述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鋸齒型的變化，上升降低都很快，這應該是不太正常的；

九、問題描述Failed to connect to server

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

　　一、 修改負載機器的tcpdelaytime註冊表鍵值，改小；

　　二、 檢查網絡延遲狀況，看問題出在什麼環節；

　　建議爲了減小這種狀況，辦法一最好測試前就完成了，保證乾淨的網絡環境，每一個負載機器的壓力測試用戶數不易過大，儘可能平均每臺負載器的用戶數，這樣以上問題出現的機率就很小了。

10．LoadRunner HTTP服務器狀態代碼：在錄製Web協議腳本回放腳本的過程當中，會出現HTTP服務器狀態代碼，例如常見的頁面-404錯誤提示、-500錯誤提示。

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

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

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

　　錯誤現象2：-500 Internal Server Error服務器內部錯誤，腳本運行中止。

　　錯誤分析：服務器碰到了意外狀況，使其沒法繼續迴應請求。

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

11．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 script」模式來錄製腳本；而沒有基於瀏覽器的Web應用、Web應用中包含了與服務器進行交互的Java Applet、基於瀏覽器的應用中包含了向服務器進行通訊的JavaScript/VBScript代碼、基於瀏覽器的應用中使用HTTPS安全協議，這時則使用「URL-based script」模式進行錄製。

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

12．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」安裝上便可。

　1.LoadRunner錄製腳本時爲何不彈出IE瀏覽器？
　　當一臺主機上安裝多個瀏覽器時，LoadRunner錄製腳本常常遇到不能打開瀏覽器的狀況，能夠用下面的方法來解決。

　　啓動瀏覽器，打開Internet選項對話框，切換到高級標籤，去掉"啓用第三方瀏覽器擴展（須要重啓動）"的勾選，而後再次運行VuGen便可解決問題

　　還有就是點擊「個人電腦－》屬性－》高級－》性能設置－》數據執行保護－》選擇「僅爲基本WINDOWS程序和服務啓用DEP」

　　提示：一般安裝Firefox等瀏覽器後，都會勾選上面得選項，致使不能正常錄製。所以建議運行LoadRunner得主機上保持一個乾淨的測試環境。

　　2.錄製Web腳本時，生成的腳本中存在亂碼該如何解決？

　　錄製腳本前，打開錄製選項配置對話框Record-Options，進入到Advanced標籤，先勾選"Support charset"，而後選擇中支持UTF-8。再次錄製，就不會出現中文亂碼問題了。

　　3.HTML-based script與URL-based script的腳本有什麼區別？

　　使用"HTML-based script"的模式錄製腳本，VuGen爲用戶的每一個HTML操做生成單獨的步驟，這種腳本看上去比較直觀；使用"URL-based script"模式錄製腳本時，VuGen能夠捕獲全部做爲用戶操做結果而發送到服務器的HTTP請求，而後爲用戶的每一個請求分別生成對應方法。

　　一般，基於瀏覽器的Web應用會使用"HTML-based script"模式來錄製腳本；而沒有基於瀏覽器的Web應用、Web應用中包含了與服務器進行交互的Java Applet、基於瀏覽器的應用中包含了向服務器進行通訊的JavaScript/VBScript代碼、基於瀏覽器的應用中使用了HTTPS安全協議，這時使用"URL-based script"模式進行錄製。

　　4.爲何腳本中添加了檢查方法Web-find，可是腳本回放時卻沒有執行？

　　因爲檢查點功能會耗費必定的資源，所以LoadRunner默認關閉了對文本及圖像的檢查。要想開啓檢查功能，必須修改運行時的配置Run-time Setting。

　　進入"Run-time Setting"對話框，依次進入"Internet Protocol→Preferences"，勾選Checks下的"Enable Image and text check"選項便可。

　　檢查執行結果時推薦使用web_reg_find方法。

　　5.運行時的Pacing設置主要影響什麼？

　　Pacing主要用來設置重複迭代腳本的間隔時間。共有三種方法：上次迭代結束後馬上開始、上次迭代結束後等待固定時間、按固定或隨機的時間間隔開始執行新的迭代。

　　根據實際須要設置迭代便可。一般，沒有時間間隔會產生更大的壓力。

　　6.運行時設置Log標籤中，若是沒有勾選"Enable logging"，則手工消息能夠發送嗎？

　　Enable logging選項僅影響自動日誌記錄和經過lr_log_message發送的消息。即便沒有勾選，虛擬用戶腳本中若是使用lr_message、lr_output_message、lr_error_message,仍然會記錄其發出的消息。

　　7.LoadRunner 8.0版本的VuGen在錄製Web Services協議的腳本時一切正常，而回放時報出錯誤提示"Error：server returned an incorrectly formatted SOAP response"。這時說明緣由引發的？

　　形成這種狀況的主要緣由是LoadRunner 8.0的VuGen在錄製Web Service協議的腳本時存在一個缺陷：若是服務器的操做系統是中文的，VuGen會自動將WSDL文件的頭改成<?xml version="1.0" encoding="zh_cn"?>，所以會有上面的錯誤提示。

　　解決方法：把"LR80WebservicesFPI_setup.exe"和"lrunner_web_sevices_path_1.exe"兩個補丁打上便可解決。

　　8.VuGen支持Netscape的客戶證書嗎？

　　不支持。目前的VuGen 8.0版本中僅支持Internet Explorer的客戶端證書。錄製腳本時能夠先從Netscape中導出所需的證書，而後將其導入到Internet Explorer中，並確保以相同的順序導出和導入這些證書。並且，在每臺將要錄製或運行須要證書的Web Vuser腳本的計算機上都要重複執行前面的過程。

　　9.VuGen會修改錄製瀏覽器中的代理服務器設置嗎？

　　會修改。在開始錄製基於瀏覽器的Web Vuser腳本時，VuGen首先會啓動指定的瀏覽器。而後，VuGen會指示瀏覽器訪問VuGen代理服務器。爲此，VuGen會修改錄製瀏覽器上的代理服務器設置。默認狀況下，VuGen會當即將代理服務器設置更改成Localhost:7777。錄製以後，VuGen會將原始代理服務器設置還原到該錄製瀏覽器中。所以，在VuGen進行錄製的過程當中，不能夠更改代理服務器設置，不然將沒法正常進行。

10.在LoadRunner腳本如何輸出當前系統時間？

　　LoadRunner提供了char *ctime(const time_t *time)函數，調用參數爲一個Long型的整數指針，用於存放返回時間的數值表示。

　　調用語句與返回值以下示例：

typedef long time_t;
Action()
{
time_t t;
lr_message("Time in seconds since 1/1/70: %ld\n",time(&t));
lr_message("System time and date: %s",ctime(&t));
}

　　輸出結果爲：

Time in seconds since 1/1/70: 1185329968
System time and date:Wed Jul 25 10:19:28 2007

　　11.一些Web虛擬用戶腳本錄製後馬上回放沒有任何問題，可是當設置迭代次數大於1時，若是進行回放則只能成功迭代一次。爲何從第二次迭代開始發生錯誤？

　　這種現象可能是因爲在"Run-time Setting"的"Browse Emulation"的設置中，勾選了"Simulate a new user on each iteration"及其下面的選項"Clear cache on each iteration"這兩個選項的含義是每次迭代時模擬一個新的用戶及每次迭代時清除緩存。

　　因爲腳本迭代時，init和end只能執行一次，若是每次迭代都模擬一個新的用戶並清除緩存，則用戶登陸信息將一併清除，所以迭代時可能會發生錯誤。

　　12.虛擬客戶腳本"Run-time Setting"中的線程和進程運行方式的區別？

　　若是選擇"Run Vuser as a process"，則場景運行時會爲每個虛擬用戶建立一個進程；選擇"Run Vuser as a thread"則將每一個虛擬用戶做爲一個線程來運行，在任務管理器中只看到一個mmdrv.exe，這種方式的運行效率更高，能形成更大的壓力，時默認選項。

　　另外，若是啓用了IP欺騙功能，則先在Controller中選中Tools菜單下的"Expert Mode"，而後將Tools菜單下的"Options>General"標籤頁中的IP地址分配方式也設置爲與Vuser運行方式一致，同爲線程或進程方式。

　　13.在Controller中運行Web相關測試場景時，常常會有不少超時錯誤提示，如何處理這類問題？

　　這主要有腳本的默認超時設置引發。當回放Web腳本時，有時候因爲服務器響應時間較長，會產生超時的錯誤。這時須要修改腳本的運行時配置。

　　進入"Run-time Setting"對話框後，依次進入"Internet Protocol→Preference"。而後點擊"Options…"按鈕，進入高級設置對話框，能夠修改各種超時設置的默認值。

　　14.爲何Windows系統中的CPU、內存等資源仍然充足，可是模擬的用戶數量卻上不去？

　　在Windows計算機的標準設置下，操做系統的默認限制只能使用幾百個Vuser，這個限制與CPU或內存無關，主要是操做系統自己規定了默認的最大線程數所致使。要想突破Windows這個限制，須修改Windows註冊表。以Windows XP Professional爲例。

　　（1）打開註冊表後，進入註冊表項HKEY_LOCAL_MACHINE中的下列關鍵字：

System\CurrentControlSet\Control\Session Manager\SubSystems

　　（2）找到Windows關鍵字，Windows關鍵字以下所示：

%SystemRoot%\system32\csrss.exe bjectDirectory=\Windows
SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1
ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2
ProfileControl=Off MaxRequestThreads=16
SharedSection=1024,3072,512

　　關鍵字的格式爲xxxx,yyyy,zzz。其中，xxxx定義了系統範圍堆的最大值（以KB爲單位），yyyy定義每一個桌面堆得大小。

　　（3）將yyyy的設置從3072更改成8192（即8MB），增長SharedSection參數值。

　　經過對註冊表的更改，系統將容許運行更多的線程，於是能夠在計算機上運行更多的Vuser。這意味着可以模擬的最大併發用戶數量將不受Windows操做系統的限制，而只受硬件和內部可伸縮性限制的約束。
15.Controller中設置了用戶併發數量，可是運行時爲什麼初始化的用戶數量少於實際數量？

　　主要時設置問題。在Tools→options→Run-time setting中能夠設置每次最多初始化的虛擬用戶。若是須要100個併發用戶，則將該值設置爲大於100的數值。另外，注意LoadRunner相關協議License的更新，確保使用的License可以容許所須要的併發用戶數量。

　　16.如何讓場景的用戶執行發生錯誤繼續運行，以保證不間斷進行壓力測試？

　　用VuGen打開虛擬用戶腳本後，進入"Run-time Settings"對話框後，依次進入"General→Miscellaneous"，能夠看到Miscellaneous設置中關於"Error Handling"的配置。勾選"Continue on error"便可讓虛擬用戶發生錯誤繼續運行。

　　17.爲何.NET虛擬用戶有時不能在遠程主機執行？

　　主要時LoadRunner的版本問題。根據筆者的經驗，若是是Microsoft Visual Studio 2005開發的虛擬用戶，同時LoadRunner客戶端的版本低於8.1，執行Controller的主機將會發生錯誤。

　　所以要想正確的運行Microsoft Visual Studio 2005開發的.NET虛擬用戶，客戶端最好裝8.1以上的版本，Controller的主機則安裝8.0和8.1兩個版本都可。此外，產生壓力的 LoadRunner客戶端上預先應該安裝.NET運行環境，若是Microsoft Visual Studio 2005開發的是.NET虛擬用戶，則應該安裝Microsoft .NET Framework SDK v2.0。

　　18.測試分析結果中會統計Action時間，而實際上可能並不需要這些數據，如何只顯示本身定義的用戶事務？

　　進入腳本的運行時設置，依次進入General→Miscellaneous。默認狀況下，自動事務配置"Automatic Transactions"下有兩個選項：第一個是把腳本的Action部分定義爲一個事務；第二個時把腳本的每一部分定義爲一個事務。去掉這兩個勾選後，測試結果將會只顯示本身定義的用戶事務。

　　19.測試結果中，Summary和平均事務響應時間圖裏的各個事務的最大值、平均值、最小值爲何顯示不同？

　　主要是受採樣時間的影響。Summary裏的事務平均響應時間是根據整個場景執行過程獲得的數據計算所得，最大值與最小值也是從整個場景中獲得的。平均事務響應時間圖主要時按照LoadRunner分析出來的採樣頻率來獲取事務響應時間的最大值與最小值，而後計算平均值。

　　能夠經過"Set Granularity"來修改平均事務響應時間圖的採樣頻率。若是把"Granularity"設爲場景執行時間，則統計結果將會一致。

　　20.統計結果中的總點擊量Total Hits時用戶的鼠標點擊次數嗎？

　　Total Hits不時按照用戶的鼠標點擊次數來計算的，而是按照各個虛擬客戶端向後臺發起的總的請求數來進行統計的。例如在向服務器請求的一個頁面中，若是該頁面包含5個圖片，用戶只要單擊鼠標就能夠訪問該頁面，而單個虛擬用戶在LoadRunner訪問的點擊量爲1+5=6次。

　　21.有些Web測試結果分析圖（例如每秒返回頁面數）在測試結果分析圖中沒法看到，如何進行配置？

　　用VuGen打開虛擬用戶腳本後，進入"Run-time Settings"對話框後，依次進入"Internet Protocol>Preference"，能夠看到一些Web性能圖配置。

　　勾選上面得選項後，Controller將會在測試執行過程當中生成數據，而後可在Analysis中查看相應的性能結果分析圖。