loadrunner整體使用篇

• 爲何要進行性能測試呢？  有些問題是隻有在大併發或者壓力測試下才會暴露出來的，在日常的公司內部測試中，感受一切都是正常的，可是把服務放到生產線上，例如某個時刻忽然有不少的用戶要向咱們的服務發送請求，這時候就考驗到咱們的服務是否會死鎖，內存泄漏，可否在一個可接受的範圍內響應，會不會crash，可否處理全部的請求（或者容許損失必定量的請求，好比1%內）等。爲了避免給用戶糟糕的體驗，因此咱們須要在服務上生產線以前就要作好性能測試，但要作好性能測試，除了編寫正確的性能腳本外，也須要分析不少因素的（主要有3大塊：負載機、網絡、被測系統），因此我但願本身能從日常中的點滴開始積累然經驗後不斷擴展。 在性能測試開始以前，是要保證你所要測試的場景中所涉及到的功能測試都已經能跑通，要否則到時候你會崩潰的QAQ
• 要作一個完整的性能測試要有哪些步驟？

–      1. 虛擬用戶腳本編寫（模擬用戶實際操做）

–      2. 場景設計&運行（例如要5000個用戶同時登陸到會議室）

–      3. 分析結果報告

• 如何選擇性能測試工具？

–      1.  只選對的，不選貴的。個人意識是根據本身所測的服務器對外提供了什麼協議類型的API來進行相應的選擇，好比我所處的平臺新服務器對外提供了HTTP協議的API和基於SessionManager的TCP協議的API。關於HTTP協議的壓測工具卻是有不少的，你們本身百度下，可是關於能測TCP協議的壓測工具，我知道的而且會使用的並很少，只知道能夠用能支持socket協議的壓測工具來實現

–      2. 選的測試工具能按本身但願的步驟來編寫虛擬用戶腳本（而不是根據測試工具提供的錄製步驟來完成虛擬用戶腳本）

–      3. 有良好的場景設計功能

–      4. 有易於查看的輸出報告

–      5. 有中文文檔以及google或者百度等上能搜索到較多的疑問解答

         綜上所述，我選擇了Loadruner做爲我平臺服務器初期的性能測試工具，並且loadrunner提供類C語言的腳本編寫（咱們在大學都應該學過C/C++，有必定的基礎能幫助咱們更快的熟悉腳本編寫）。可是因爲loadrunner不易於擴展，是商用工具，要想無償使用只能用loadrunner11版本的破解版，loadrunner11是很早以前的版本，對於一些新功能是沒法支持的（例如：咱們開發提供了一個SDK的DLL，在LR11中沒法加載運行，但在LR12中能夠加載運行）。總之工具只是幫助咱們完成任務的，要想更好的完成任務，咱們就須要不斷的探索更多的解決辦法（之後我會分享其餘的開源性能測試工具或者如何本身編寫一個適合咱們被測系統的壓測代碼）

 

• Loadrunner的使用     

–      下圖顯示的是LR的3個主要組件，其中Virtual User Generrator是用來編寫虛擬用戶腳本的

–      Controller是用來設計場景的

–      Analysis是用來分析運行數據，生成結果報告的

–      結合我實際工做中的項目來演示如何使用這3個組件的

 

Virtual User Generator

         因爲咱們要本身來設計腳本執行的流程順序，暫時使用不到loadrunner提供的錄製功能，因此打開Virtual User Generator,點擊New Script而後選擇一個通用的協議，例如Web(HTTP/HTML)後點擊Create按鈕，通過這些步驟後，就爲咱們提供了一個初步的編寫腳本用的模版了

 

•       Virtual User Generator

 

–      虛擬用戶腳本的設計是要考慮到典型場景的，例如一個會議室登陸多個用戶、多個會議室登陸多個用戶等等，接下來的demo將是針對一個會議室登陸多個用戶的場景的。先上圖再逐一分解

 

–      與最初建立的模版相比，發現上圖左邊的工程區裏面多了cJSON.h和JsonDemo.dll2個文件，因爲LR支持加載純C編譯的DLL，因此咱們就能夠像使用python那樣import XX包進來，而後直接使用其中的方法來幫助咱們編寫腳本，關於cJSON.h和JsonDemo.dll2個文件這2個文件的做用，將在接下來的腳本分析中說明吧

 

先上2張我實際寫的項目腳本，爲下面的解析提供依據：

Login_CreateGroup腳本：

 

• Virtual User Generator

–      如何找到純C的源程序，而後編譯成dll，最後導入到loadrunner中爲咱們所用？就拿剛剛的JsonDemo.dll來講明吧

–      1. 登陸到Json的官網（www.json.org），找到C的源碼而後下載

–      2. 打開Visual Stutio，New一個空的project，選擇Visual C++下的Win32 Console Application，而後把Application Type選擇爲DLL

–      3. 右鍵點擊Header Files，Add一個Existing Item…把剛剛下載的C的源碼裏面的cJSON.h添加進來，一樣右鍵點擊Source Files， Add一個Existing Item…把剛剛下載的C的源碼裏面的cJSON.cpp添加進來

–      4. Build Solution生成DLL（編譯過程當中若是有安全提示的話，能夠在command line中輸入/D 「_CRT_SECURE_NO_WARNINGS」 來解決）

 

platfrom_room腳本：

 

• Controller

–      虛擬用戶腳本已經編寫好了， 可是虛擬用戶腳本只是表明一個用戶的某種行爲，要想實現併發操做，那就是要模擬不少用戶（例如2000個用戶）的相同操做。

–      在真正的實際設計場景前，有幾個概念須要理解下，什麼是「系統用戶數」、「在線用戶數」、「併發用戶數」？舉一個例子來講明下， 假設有一個綜合性的網站，用戶只有在註冊後登陸系統纔可以享有新聞、論壇、博客、免費信箱等服務內容，經過數據庫統計知道了系統的用戶數量爲4000人，4000即爲「系統用戶數」；經過操做日誌能夠知道，系統最高峯時有500個用戶同時在線，這裏「在線用戶數」即爲500；這500個用戶的需求確定是確定是不盡相同的， 有的人喜歡看新聞、有的人喜歡寫博客、收發郵件等。假設70%的人在看新聞，10%的人什麼也不幹，剩下的20%的人寫博客（收發郵件或者不停的跳轉頁面），那麼真正對服務器形成壓力的就是這500人中的20%（100人）。那麼如何估算「併發用戶數」？

–      （1）C=nL/T      (2) C1=C+3 √3

–      在公式（1）中，C是平均的併發用戶數；n是login session的數量；L是login session的平均長度；T是考察的時間段長度。

–      在公式（2）中，C1是併發用戶數的峯值，C就是公式（1）中的獲得的平均的併發用戶數。該公式的得出是假設用戶的login session產生符合泊松分佈而估算獲得的

–      下面給出一個實例來說述公式的應用。假設有一個OA系統，該系統有3000個用戶，平均天天有大約400個用戶要訪問系統，對一個典型用戶來講，一天以內用戶從登陸到退出系統的平均時間爲4h，在一天以內，用戶只在8小時以內使用該系統。帶入公式（1）獲得C=400*4/8=200，那麼C1=200+3* √200=242

–      除了上述方法外，還有一種更爲普遍但精度比較差的根據經驗的方法，相應的經驗公式爲：C=n/10和C1=r*C。一般用訪問系統用戶最大數量的10%做爲平均的併發用戶數量；併發用戶數的最大數量能夠經過在併發數上乘以一個調整因子r獲得，一般r的取值爲2~3。

–      固然在我實際測試過程當中的話，我是根據負責人要求的來進行併發測試，好比我主管說服務器要支持5000的併發請求，那麼我就按照5000來設計了，等服務上線後，我會查看日誌、數據庫而後運用上面的公式再來分析每一個階段實際的併發用戶數。

 

• Controller

–      1. 打開Controller，會出現一個「New Scenario」對話框，把剛剛編寫好的」Login_CreateGroup」和」platform_room」這2個腳本添加到「Scripts in Scenario」。爲何要添加2個腳本，而不是在一個腳本中把咱們要操做的步驟所有編寫好呢？ 這就有點像寫代碼，咱們會把一些常常要用的且能共用的弄成一個庫，那樣誰要用的時候就直接引入這個庫，會提升效率。因此在設計我平臺服務器的性能腳本時候，我就儘可能把每一個接口都各自編寫成腳本，而後在場景設計中就把這些腳本進行組合。

–      2. 這裏介紹下「Schedule by」中的2個重要選項「Scenario」和「Group」,Scenario(場景)：當你按場景進行計劃時候，Controller將會同時運行全部參與場景的Vuser組，也就是說，定義的場景運行計劃同時應用與全部Vuser組，而Controller將每一個操做按比例應用與全部Vuser；Group（組）：當你按Vuser組進行計劃時，參與場景的每一個Vuser組按其本身單獨的計劃運行，也就是說，對於每一個Vuser組，你能夠指定什麼時候開始運行Vuser組，更直白一點的說，就是當Vuser組和Vuser組之間有依賴關係的時候，就用Group方式。

–      3. 接下來就說說我設計的場景，根據業務我須要先登陸驗證（會返回token），建立分組（會返回groupid），而後請求分配服務地址和登陸會議室，因此呢，我只須要登陸和建立分組一次，就能拿到後續登陸會議室須要的token和grouip，因而我只要運行腳本「Login_CreateGroup」一次，而後再運行腳本「platform_room」不少次就能實現「一個會議室同時登陸不少人」的場景，並且這裏須要注意的一點是，這2個腳本是有依賴關係的，「Login_CreateGroup」是要在「platform_room」前面先執行完後，「platform_room」才能執行的。對應到Controller裏面的設置以下圖：

 

 

 

 

 

• Controller

–      4. 場景設計完了， 接下來就能夠執行了， 可是咱們性能測試不僅僅只是給被測系統加壓， 咱們還要關注整個測試過程當中產生的數據， 而後選出咱們所關心的數據，爲進一步分析定位問題提供幫助。因此呢， 在開始RUN以前，咱們先添加一下本身關心的，要監控的數據，下圖是我監控的一些數據：

 

 

• Controller

–      5. 接下來就能夠RUN了， 在Running過程當中可能會遇到一個問題就是loadrunner卡在那邊不動了， 而後後面的case都失敗了， 經過觀察監控的「Windows Resources」發現某一時段內CPU達到100%了，究其緣由發現是由於設置太多的Vusers了（好比5000），這時候負載機由於自身的資源條件限制而引發的，爲了解決這一問題，咱們能夠採用loadrunner的分佈式加壓來解決。

–      什麼是分佈式加壓呢？ 分佈式加壓其實就是用另一臺負載機來幫助咱們實現必定量的Vusers，那麼咱們就須要在另外一臺負載機上安裝loadrunner11軟件，而後在本地負載機的Controller的Load Generators裏Add另外一臺負載機的Name（能夠填寫IP地址，好比192.168.6.173），而後點擊connect按鈕，查看status是否變爲Ready狀態，最後就能夠在不一樣的虛擬用戶組指定不一樣的負載機來幫助咱們完成性能測試了。

–      具體操做步驟能夠參考網上的資料：http://blog.csdn.net/wuyepiaoxue789/article/details/51799657

         場景運行完成之後， 不表明咱們的性能測試結束， 相反，這纔是性能測試的開始，由於接下來，咱們須要對運行數據進行分析，找出性能瓶頸，而後調優或者提交BUG。

 

• Analysis

–      在介紹Analysis的使用以前， 下面將針對一些經常使用的監控資源進行說明。

• 我大體將監控分爲3類
• ①負載機的系統監控與被測系統監控（通常包括CPU使用率、內存、磁盤IO等）
• ②服務器處理能力的指標監控（通常包括吞吐量、每秒事物數、各個事物的響應時間、每秒單擊數等）
• ③網絡監控（根據經驗，就是查看對比先後流量，ping服務器等）

–      CPU利用率（% Processor Time）：指處理器執行非閒置線程時間的百分比。這個計數器設計成用來做爲處理器活動的主要指示器。它經過在每一個時間間隔中衡量處理器用於執行閒置處理線程的時間，而且用100%減去該值得出。可將其視爲範例間隔用於作有用工做的百分比。根據應用系統狀況，在80%±5%範圍內波動爲宜。太低，則服務器CPU利用率不高；太高，則CPU可能成爲系統的處理瓶頸。

–      可用物理內存（ Available MBytes ）：當這個數值變小時，Windows開始頻繁地調用磁盤頁面文件。若是這個數值很小，例如小於5 MB，系統會將大部分時間消耗在操做頁面文件上。通常要保留10%的可用內存。最低不能<4M，此值太小多是內存不足或內存泄漏。

–      磁盤IO（% Disk Time）：指所選磁盤驅動器忙於爲讀或寫入請求提供服務所用的時間的百分比。正常值<10，此值過大表示耗費太多時間來訪問磁盤，可考慮增長內存、更換更快的硬盤、優化讀寫數據的算法。若數值持續超過80 (此時處理器及網絡鏈接並無飽和)，則多是內存泄漏。

–      事務平均響應時間:（ Average Transaciton Response Time ）：隨着測試時間的變化，系統處理事務的速度開始逐漸變慢，這說明應用系統隨着投產時間的變化，總體性能將會有降低的趨勢。好<2s、良好2~5s、差6~10s

–      吞吐量（ Throughput ）:能夠依據服務器的吞吐量來評估虛擬用戶產生的負載量，以及看出服務器在流量方面的處理能力以及是否存在瓶頸。

–      每秒點擊次數（ Hits per Second ）:經過對查看「每秒點擊次數」，能夠判斷系統是否穩定。系統點擊率降低一般代表服務器的響應速度在變慢，需進一步分析，發現系統瓶頸所在。

虛擬用戶數（Running Vusers）: 這個主要用於與其餘監控數據結合來分析問題的。

 

• Analysis
• 執行結果分析過程

–      場景執行完成之後，須要對運行過程當中收集的數據信息進行分析，從而來了解系統性能表現能力，肯定系統性能瓶頸。在Loadrunner Controller中，經過單擊【Results】>【Analyze Results】菜單項，啓動Loadrunner Analysis應用，若是左側的Graphs中沒有出現你想要的圖，就點擊工具條按鈕「Add New Graph…」，把關心的圖加入進來，以下圖：

 

 

• Analysis
• 合併圖的應用

–      有時候看單一的圖，很難看出圖與圖之間的關聯，因此這時候，咱們能夠採用合併圖來進行有機的結合。合併圖的方法就是先選擇一張合併圖，而後在圖的空白處單擊鼠標右鍵選擇【Merge Graphs…】選項，接着選擇被合併圖（能夠選擇合併圖類型、能夠更改標題），以下圖：

 

• Analysis
• 合併圖的應用

         合併圖共提供了3種方式：疊加（Overlay）、平鋪（Tile）和關聯（Correlate），下面針對這3種合併方式作一下簡單的介紹。

         （1）疊加方式：使得兩個圖使用相同橫軸的圖的排列方式。合併圖的左側縱軸顯示當前圖的值，右側縱軸顯示被合併圖的值。

         （2）平鋪方式：兩個圖一個位於另外一個之上，合併圖在下方，而被合併圖在上方，使得兩個圖共同使用一個橫軸，兩個圖分別使用擱置的縱軸

         （3）關聯方式：使得合併圖的縱軸將變成合並圖的橫軸，被合併圖的縱軸將變成合並圖的縱軸。