LoadRunner性能測試系統學習教程：工具介紹（下）

LoadRunner內部結構

LoadRunner主要經過控制內部程序的調度來控制整個性能測試過程，LoadRunner內部結構圖以下圖所示。該圖詳細地描述了LoadRunner執行過程當中內部程序是如何調度的及內部各程序之間的關係。

從LoadRunner內部結構的層次來分析LoadRunner性能測試的過程。
1.首先準備好待測試的應用服務器和待測試的系統。
2.LoadRunner中多線程驅動進程mdrv.exe和r3vuser.exe模擬產生壓力，其中r3vuser.exe仿真應用程序的客戶端，如IE瀏覽器。它執行了如下三個主要的操做：
①cci（C語言編譯器）創建ci文件，而後使用被測系統的協議來執行。
②經過Windows批處理腳本啓動mdrv.exe程序從而啓動LoadRunner的運行。mdrv能自動中止加載Vuser，由於它們與Vuser和Windows負載發生器上的CPU監視器之間互相通訊。
③在Windows機器上，對於每個基於Java的Vuser都有一個獨立的JVM，注意UNIX平臺不支持JavaVuser。
3.虛擬用戶在負載發生器端的計算機上使用代理做爲服務或進程時，按照組啓動方式啓動虛擬用戶，用戶組是多個Vuser組成的邏輯集合，在Vuser發生器上運行相同的腳本。
4.每一個負載發生器（LoadGenerator）都維護着一個以qtp爲後綴名的執行日誌。
5.日誌服務啓動後，代理會根據用戶組進行隔離，在結果文件中爲每一個虛擬用戶創建一個順序文件。
6.在執行過程當中，這些文件會在「視圖」→「顯示」輸出窗口中顯示出來。
7在預先設置延時上，Controller上運行的Scheduler指導代理（經過Windows54345端口或UNIX上的動態端口）初始化場景會話；控制器（wlrun.exe）在發送請求時發送一份場景的拷貝。
8.代理是由每個負載發生器上的RemoteAgentDispatcher進程（8.0叫RemoteCommandLauncher（RCL））啓動的。
9.每一個代理根據場景（.lrs）定義文件來決定哪一個虛擬用戶組和腳本須要在主機上運行，這就是說控制器能夠從DOS批處理文件（.batch）中啓動。
10.控制器經過使用Windows操做系統根目錄文件夾裏的參數值來啓動，由於LoadRunner被設計成在一個機器上而且一次只能運行一個控制器實例，因此須要使用Windows文件夾。
爲了在幾個應用之間快速的切換，Controller工做以後會保存在LoadRunner的ini文件中，而後使用記事原本製做一個批處理文件，在執行wlrun以前拷貝應用程序的指定版本的ini文件。
11.在Vuser中定義的每一個虛擬用戶進行的操做都是LoadRunner的VuGen.exe生成的，當這個程序啓動後，它在Windows文件夾下存儲了comparamui.ini文件來保存[LastTablesUsed]下文件的歷史，而[ParamDialogDates]項是由「插入」→「新參數」→「數據」來指定。
12.在運行期間，執行結果存儲在一個結果文件夾中。
在結果中設置「爲每個設定執行自動建立結果目錄」，這樣LoadRunner會在每次啓動一個場景以後自動產生一個遞增的結果名。
例如，結果名稱Res1會自動增加到Res12或是Res11-1，錯誤信息會寫到MicrosoftAccess數據庫文件output.mdb中。
13.在每個結果文件夾中，程序自動建立一個Log文件夾，在這個文件夾中包含每一個組的日誌文件，運行結束以後，在Controller中查看日誌文件，點擊按鈕而後在組中點擊右鍵，選擇「查看Vuser日誌」。
14.場景運行的時候，監視器在本地維護每一個主機的計數器。
15.場景運行結束後，進程處理.eve和.lrr結果文件而且在結果文件夾下建立一個臨時的.mdb（M）數據庫。在處理大數據量的結果時，爲了防止錯誤發生，一般使用（MicrosoftAccess）數據庫文件。
16.分析模塊（8,320Kanalysisu.exe）使用.mdb數據庫中的數據來產生分析圖表和報告。
17.每次設定運行後的LoadRunner結果文件result_name.lrr（也稱爲分析器文檔文件），由分析程序來讀取並顯示百分位圖表。
18.默認狀況下，LRReport文件夾被建立在本地分析機器的MyDocuments文件夾下用來存儲分析會話文件。
19.可使用HTML格式產生報告。
20.結果文件格式是由.tem模板文件控制的。
負載測試的結果可使用Web瀏覽器來瀏覽了。
以上就是LoadRunnerr測試的所有過程。

LoadRunner11.0特性

LoadRunner當前最新版本爲11.0版本，在11.0版本中主要新增瞭如下功能：
新增協議：
AjaxTruClient
協議用於基於JavaScript的現代應用程序（包括Ajax，用於模擬Web瀏覽器中的用戶活動）的高級協議。在MozillaFirefox中以交互方式開發腳本。

Silverlight
協議模擬傳輸及用戶活動的基於Silverlight的應用程序的新協議。容許經過自動導入和配置應用程序所使用的WSDL文件生成高級別腳本。

JavaoverHTTP
協議用於錄製基於Java的應用程序和小程序的一種新協議。該協議使用Web函數生成Java語言腳本。該協議與其餘Java協議的不一樣之處在於：它能夠錄製和回放經過HTTP進行Java遠程調用。

Citrix
協議現可支持CitrixOnlinePlugin11.2和12.0兩個版本，而且增長了對CitrixXenAppServer5.0的支持。

OracleNCA-NCAJava
協議對象屬性現可支持在腳本中自動建立和註冊客戶端Java對象和OracleNCA服務器之間通訊的查詢應答表。

SAPGUI
協議增長了對SAPGUIforWindowsClient7.20版的支持。

ServiceTest-LoadRunnerController
協議能夠運行在HPServiceTest11.00中建立的腳本。HPServiceTest11.00是用於建立和運行SOA（service-orientedarchitecture面向服務體系結構）和無頭技術的自動化測試的HP解決方案。有關爲負載測試場景建立ServiceTest腳本的詳細信息，請參閱ServiceTest文檔。
新增功能：
.數據格式擴展(DataFormatExtensionDFE)：
加強了Web(HTTP/HTML)協議系列的數據格式功能。容許將原始HTTP流量轉換爲可維護的結構化XML格式，並啓用XPATH關聯。

CorrelationStudio：
加強了Web(HTTP/HTML)自動關聯機制，可在代碼生成期間所建立的快照數據（包括經過DFE格式化的數據）中更普遍地搜索可能的關聯。

快照視圖：
Web(HTTP/HTML)協議步驟的新快照視圖，容許以原始格式和DFE生成的格式查看完整的HTTP流量。

VuGen-HPALMIntegration：
加強了與HP應用程序生命週期管理平臺的集成，該平臺還爲QualityCenter和PerformanceCenter版本提供支持。

SLA（ServiceLevelAgreements）定義：
在新的版本中擴展了SAL的使用，能夠在更多的測試狀況下使用SAL定義。

Windows支持：
增長了對Windows7和WindowsServer2008的支持。

Analysis報告：
加強的Analysis報告可更好地自定義。Analysis數據可導出爲各類格式，包括Word、Excel、PDF和HTML。利用新的報告模板，能夠保存報告定義並生成基於模板的報告。

LoadRunner性能測試步驟

LoadRunner雖然只是一個性能測試工具，但使用它進行性能測試時也有其自身的一個流程。性能測試過程分爲四個階段：【設計】、【構建】、【執行】和【分析/診斷/調節】。具體的工做流程如圖

圖中多出系統性能調優的過程，由於進行性能測試的目的是找到系統性能的瓶頸，進而幫助開發工程師對系統性能進行調優，若是不能給開發工程師提出性能調優的有效建議，那麼性能測試是作得不夠成功的。實際上項目進行測試過程也是這樣，性能調優是一個循環的過程，通常狀況下須要經歷屢次測試才能達到目標能力。

四個階段的任務以下： 1.設計階段定義待測試的業務流程、業務的平均處理量、業務處理量的最高峯值、組合業務流程、系統的總體用戶和響應時間目標。 2.構建階段涉及設置和配置測試系統及基礎設施、使用自動化性能測試解決方案構建測試腳本和負載方案。 3.執行階段性包括運行負載方案和測量系統性能。 4.分析、診斷和調節階段主要測量系統性能並使負載測試進入下一級別，重點查找問題緣由以幫助開發工程師迅速解決問題，並實時調節系統參數以提升性能。 下面對這四個階段進行詳細的描述： 1．設計階段 設計階段是性能測試團隊與業務領域的經理合做以收集性能要求的主要業務響應時間。能夠將須要關注的問題分爲四個方面：業務需求、技術需求、系統要求和團隊要求。業務要求需經過業務分析師或最終用戶收集。一個全面的業務要求應該考慮如下問題： 應用程序狀況：建立系統使用演示，讓性能測試團隊從總體上了解應用程序如何被使用。 業務流程列表：建立關鍵業務流程列表，以使用反映最終用戶在系統上執行的活動。 業務流程列表：建立Word文檔，以便詳細記錄每一個業務流程的正確步驟。 交易列表：彙編業務流程中須要負載測量（如「登陸」或「轉移資金」等）的關鍵活動的列表。 業務流程圖：建立業務流程圖，以便描繪業務流程的分支狀況。 技術要求應該經過系統管理員和數據庫管理員（DBA）進行收集並確認。這些人員多是企業開發組或運營部門的成員，或同時隸屬這兩個部門，一個全面的技術要求應該考慮如下問題： 環境預排工做：與系統或基礎設施團隊開展測試架構的預排工做。 系統範圍會議：舉行會議來討論系統的哪些部分應該排除在測試流程以外，並達成一致看法。 生產圖：建立生產基礎設備的圖表，以標記出從QA遷移到生產過程當中可能影響性能的因素。 收集系統的要求相當重要，這些是管控負載測試流程經過/未經過狀態的系統高級目標，這些一般與來自業務的經理合做而達成一致的，一個全面的系統要求應該考慮如下問題： 系統在正常和高峯期必須支持的用戶數量爲多少？ 系統每秒必須處理的交易量是多少？經常使用的一種估算方法爲80～20原理法。 對於全部的關鍵業務交易，可接受的最低和最高的響應時間是多少？ 用戶社區如何鏈接到系統？ 生產中須要承載的系統工做量如何？交易組合如何？ 最後是團隊要求階段，須要肯定性能測試團隊成員。提早收集完整的業務、技術、系統和團隊要求，是有效和成功地進行負載測試的基礎。 2．構建階段 在構建階段，須要將設計階段所肯定的業務流程和工做量轉變爲可用來推進可重複、真實負載的自動化組件。能夠從兩個方面來關注：自動化設置和環境設置。 自動化設置包括一系列由性能工程師執行的序列任務： 第一：製做腳本：將存檔的業務流程記錄到自動化腳本中。 第二：交易：插入計時器來產生業務所須要的邏輯計時。 第三：參數化：用數據池來代替全部的輸入數據（如登陸用戶名和密碼），以便每一個虛擬用戶使用惟一的數據訪問應用程序。 第四：方案：經過爲不一樣的用戶組分配不一樣的腳本、鏈接和用戶行爲來建立生產工做量。 第五：監視：肯定要監視哪些負載服務器或機器。 環境設置包括組裝硬件、軟件和數據，這些都是執行成功及真實負載測試所必需的，這可能要與系統人員、DBA、操做人員和業務團隊協做。環境設置中最重要的是準備數據，數據來源有兩種方式：一是歷史數據；二是建立數據。 歷史數據便是將真實存在的數據，只須要從數據庫抽取出來便可。 建立數據是測試過程當中經過一些方法生成批量數據，製做數據的方法一般包括：Ultraedit結合Excel製做數據、數據庫、Shell編程和Java編程等。全部建立的數據都應該知足數據模型的要求，不然數據在調用過程當中會產生錯誤。 構建階段的最終結果是獲得一套自動化的方案，可在配置好的可用環境中隨意執行。 3．執行階段 在剛剛接觸性能測試的人員，經常誤認爲執行只是一個單一事件，而事實上，它是一個多步驟的流程，包括多種類型的性能測試。每種類型的測試所提供的信息對於瞭解發佈應用程序的業務風險都是必不可少的。 常見的幾類負載測試以下： 基線測試：用於驗證系統及其周圍的環境是否在合理的技術參數下運行。性能測試僅運行5到10名用戶來對最終用戶交易性能進行基線測試，這些測試應該在性能測試流程的開始和結束時執行，以測量絕對響應時間的提升量。 性能測試：可模擬環境中的負載，從而提供有關係統可處理多少用戶的信息，這些測試應該模擬平均和高峯時的生產用量，它們應該使用真實的用戶行爲（如思考時間）、調制解調器模擬和多個瀏覽器類型，以得到最高的準備度，應該運行全部的監視程序和診斷程序，以便於工做最大限度地瞭解系統的性能下降和瓶頸。 基準測試：用於在理想的狀況下測量和比較每種機器類型、環境或應用程序版本的性能，這些測試是系統進行了可擴展測試後運行的，旨在瞭解不一樣架構的性能影響。 滲入測試：其目的在於長時間在負載下運行系統，從而檢驗系統的性能情況。 峯值測試：其目的在於模擬一段時間內系統上的峯值負載，以使幫助演示應用程序和底層硬件是否可以在合理的時間內處理高負荷。 4．分析、診斷、調節階段 在完成負載測試的設計、構建和執行階段後，項目將進入分析、診斷和調節階段，這些階段是實時和反覆進行的，負載測試解決方案應該提供有關最終用戶、系統級別和代碼性能數據的全面信息，同時查找致使性能下降的可能緣由，這些信息能使你肯定是否已經達到性能目標。 在監控、分析、診斷和調節過程當中能夠獲取大量的信息： 監控：性能測試過程當中的監控可顯示基礎設備每一個層上所發生的一切，同時會更清晰地提供有關測試中數據庫服務器、Web服務器、應用程序服務器、單個應用程序或流程的信息。監控可快速獲取有價值的信息，例如應用程序服務器的處理器（CPU）只能支持150名用戶併發，遠低於目標值。 分析：完成負載測試後，可將各類指標（如虛擬用戶、CPU或服務器CPU）關聯起來，以獲取有關應用程序行爲不斷的其它信息。 診斷：高效的性能測試解決方案應該向性能工程師提供有關層、組件、SQL語句是如何影響負載條件業務流程總體性能的單個統一視圖，性能工程師應該可以看到由最終用戶交易所接觸到的全部組件，而後肯定各組件使用的處理時間，以及調用的次數。有了這些信息，就能夠針對Web服務器、應用程序和數據服務器瓶頸進行調優。 許多企業都在應用程序部署前、中和後三個階段進行自動化性能測試。有些自動化性能測試解決方案可系統地識別並分離基礎實施性能瓶頸，而後經過修改系統配置設定來解決它們，經過反覆解決基礎設施瓶頸，能夠不斷改進配置。