案例實踐：零基礎完成Loadrunner壓力測試，十分鐘教會你

摘要：最近筆主帶著兩位新入職的同事進行了公司新平臺的壓力測試，工具選擇的當然是Loadrunner，小筆發現有很多剛入門Loadrunner的小白都會遇到很多相似的問題，但是這些問題並不能在各大搜尋網站上得到完善的解決。因此，小筆選中了51testing這個流量給力認可度高的專業測試平臺給各位loadrunner新手提拱一份參考，希望能夠幫助到有需要的朋友。 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

在如今的大資料時代，軟體、測試、自動化測試都在扮演者不可或缺的重要角色，我們開發一個平臺要求的已經不僅僅是功能要正確，更要考慮的是隨著訪問量的增加給客戶帶來的壓力體驗。

OK，引文部分已經完成，下面我們一起走進Loadrunner的壓力測試吧。

跟著小筆一起動手來完成此次的壓力測試吧！一個完整的壓力測試三部曲：

1.指令碼錄製->2. 場景設計->3. 結果分析

場景介紹：此處我們選擇最具有代表意義的多使用者併發登入系統，我們測試150個使用者併發登入平臺A的時候給系統增加的壓力情況。

測試背景： Windows Server 2008+Loadrunner11+IE8

1．錄製指令碼（Virtual User Generator）

安裝好Loadrunner後（安裝比較容易，在此暫且省略），開啟Virtual User Generator進行指令碼錄製，錄製時相關設定：

Step 1、Catalog選擇'Web(HTTP/HTML)'，點選[Create] 按鈕。

Step 2、[URL Address]的值輸入需要測試系統的地址，點選[OK]按鈕。

Step3、開始進行登入系統的指令碼錄製，一般情況下，我們在錄製的過程中需要切分action，不同的操作放在相對應的action裡，此處因為操作簡單，我們暫且不去細分。

Step4、生成指令碼

Step5、最佳化指令碼：新增集合點，事務，思考時間。

事務：定義一個action的範圍，以便對此action進行某種操作。比如對該action進行計時操作。

語句：lr_start_transaction("login");

集合點：正如字面意思，等待所有的事務集合到一起進行的操作，用來執行負載測試。要實現此操作，可以同步 Vuser 以便恰好在同一時刻執行任務。透過建立集合點，可以配置多個 Vuser 同時執行某個操作。當某個 Vuser 到達該集合點時，將進行等待，直到參與該集合的全部 Vuser 都到達。指定數量的 Vuser 均到達後，釋放所有這些 Vuser。

語句：lr_rendezvous("login");

思考時間：思考時間即等待時間，是一種延遲操作，很好理解。

語句：lr_think_time(5);

2．場景設計（Controller）

Step1、開啟 controller，新增上面最佳化好的指令碼，設定場景模式。（此處命名為testLogin）設定場景如下：

Step2、點選【Start Scenario】執行指令碼，結果如下：

Step 3、點選紫色框中按鈕，生成測試結果報告。

2．結果分析（Analysis）

Analysis 可以說是Loadrunner壓力測試的重點和難點，所以對於新手而言 analysis不是測試的結束，而是開始。因此，對於各項測試結果我們要做出準確的理解和判斷。在本次的實踐中，我們做的是一個比較簡單的場景，那麼針對此場景的各項結果如下：

【測試報告分析摘要】，這裡顯示了實際測試過程中，總體的測試結果。我們可以選擇更過的圖來分析系統的負載情況。

【Running Vuser】結果分析：Vuser是併發測試選取的虛擬使用者，從下圖中可以看出，Vuser是每5秒增加5個，在02:20秒的時候達到了頂峰值150，持續執行了一分鐘後，逐漸退出系統。

【Hits per Second】結果分析：每秒提交的HTTP請求數量，在本場景中執行的時間比較短，因此結果不是很明顯，建議大家此處可以放寬執行時間，這樣得到的結果比較準確。

【Throughput】結果分析：吞吐量是指返回的應用層資料的值，吞吐量單位是以位元組數為準，表示Vuser在任何給定的某一秒上從伺服器獲得的資料量。藉助此圖我們可以依據伺服器吞吐量來評估Vuser產生的負載量。該資料越小說明系統的頻寬依賴就越小，透過這個資料可以確定是不是網路出現了瓶頸。

【Tansaction summary】結果分析：事務概要說明，統計執行的事務數量，比如在本次場景中，login和exist這兩個事務的值都是855次。同事也監控了事務的Pass數和Fail數，瞭解負載的事務完成情況。透過的事務數越多，說明系統的處理能力越強；失敗的事務數越小說明系統越可靠。這個比較容易理解，不多闡述。

【Average Transaction Response Time】- 事務響應時間結果分析：這裡需要注意的一個問題是因為在Transaction Response Times裡面是場景執行時記錄的響應時間的最大值最小值與平均值，而Average Transaction Response Time 是按照取樣率每隔幾秒鐘取一個值畫出來的圖，然後根據圖來記錄最大值最小值和平均值，在報告中也可以看到，Average Transaction Response Time中寫的是圖最大值、圖小值和圖平均值。如果將取樣率設定小一些，這兩個值就會比較接。所以，抽象率是關鍵。那麼下圖現實的結果可以看出，login這個action最大值是14.978，最小值是2.134，平均值是7.869；exist最小值是0.02，最大值0.214，平均值是0.078 。這些時間是可以接受的壓力響應的時間。

本次測試過程中常見問題彙總：

之所以加上問題彙總是因為筆主覺得大家在做壓力測試的時候，這類問題的出現率很高，所以，在此稍微總結一下。

問題1：averager esponse time響應時間過長？（與實際偏差甚大完全不合理）

解決方法：導致此問題的原因很多，但是我們可以從以下幾類去分析：1、是否在指令碼中新增了多長時間的思考時間。2、事務和集合點的先後順序是否正確，正確的順序是把集合點放在事務前面，反之則也會增加事務響應時間的值。3、網速問題，網速一般不會造成太大的偏大，但是不排除併發量很大的情況下造成的延誤。

問題2：LoadRunner超時錯誤

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

問題3：LoadRunner指令碼中出現亂碼

解決方法：重新錄製指令碼，在錄製指令碼前，開啟錄製選項配置對話方塊進行設定，在“Recording Options”的“Advanced”選項裡先將“Surport Charset”選中，然後選中支援“UTF-8”的選項。

問題4：在錄製過程中IE頁面上，某些控制元件顯示有問題，導致錄製不了。

解決方法：一般情況下，將被測系統的URL加入到可信任站點即可解決此類問題。

問題5：Error -27796：Failed to connect to server‘XXXX’

這個問題可以說是經常遇到但是不易被解決的難題，我們大致可以這樣去排查

（1）檢查run time setting中的請求超時時間Preferences中點選Options‘HTTPrequest connect timeout’，‘HTTP-request receieve timeout’，‘Step download timeout’，檢視其值是否為1000、1000、10000；run time setting設定完了後記住還需要在control元件的option的run time setting 中設定相應的引數；

（2）Browser Emulation中的Download non-HTML resources選項去掉，點選OK即可如果還不能解決的話，繼續嘗試第3種方法

（3）設定runt time setting中的internet protocol-preferences中的advaced區域有一個winlnet replay instead of sockets選項，選項後再回放就成功了。如果實在不行的話就試試重啟 方法吧，因為有些問題的確可能是因為工具問題，網路問題，機子問題等等。

總結：用Loadrunner進行壓力測試難免會遇到各種問題，細心排查總能一一解決，所以筆者想對剛剛踏入這一行業的朋友說，不急不燥認真去思考，問題總能被解決。希望此篇文章對大家有所幫助，任何問題都可以留言喔。

最後：

可以到我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的影片學習教程免費分享！其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！