LoadRunner性能測試實例
一、簡介
性能測試，是通過自動化的測試工具模擬正常、峯值以及異常負載等的情況下，對系統的各項性能指標進行測試。
測試工具：LoadRunner(收費)、Jmeter（開源）、QaLoad ……
1）LR介紹
LoadRunner，是現在使用相對最爲廣泛的性能測試工具。它通過模擬上千萬用戶，來實施併發負載及實時性能監測的方式來確認和查找系統瓶頸。LoadRunner是一種適用於各種體系架構的自動負載測試工具，用來測試系統性能。
LR由三部分組成：
1.VuGen(虛擬用戶生成器)用於捕獲最終用戶業務流程和創建自動性能測試腳本 (也稱爲虛擬用戶腳本)。
2.Controller (控制器)用於組織、驅動、管理和監控負載測試。
3.Analysis (分析器)有助於您查看、分析和比較性能結果。
2） 測試要求：tesklink: http://localhost/testlink/login.php
1、 測試系統支持100個併發同時登錄
2、 登錄功能響應時間不超過5秒
3、 CPU使用率不超過80%
4、 內存使用率不超過75%
二、用VuGen錄製腳本；
（1）按業務流程正確錄製腳本
（2）增強腳本：
1）參數化
2）添加事務
3）集合點
4）檢查點
5）關聯 web_reg_save_param
web_reg_save_param
函數進行關聯
6）Running-times Settings
log的設置方式 ： Always send messages（這種方式會一直打印輸出日誌，不僅在錯誤時）；
standard log——記錄所有的請求反饋的日誌，包括successful和fail的日誌。
Extended log——可提供擴展的日誌信息，包括：
Parameter subsititution——日誌中打印所有中使用的參數值
Data returned by server——日誌中打印每個客戶端請求服務器返回的數據值
Advanced trace——日誌中打印所有的消息信息和函數執行信息
通常我們選擇「Parameter subsititution」.
6）編譯；Replay
三、運行腳本，進行負載測試；
1）Design界面
（1）scenario script
Scenario Schedule
2）Run界面
（1）Available Graphs 選擇監控項；
（2）Start Scenario
四、Analysis報告分析
Mercury Loadrunner Analysis 中最常用的5 種資源.
1. Vuser
2. Transactions
3. Web Resources
4. Web Page Breakdown
5. System Resources
1）首先查看Summary Report
Transaction Summary(事務摘要)：瞭解平均響應時間Average單位爲秒。。。。。
2)分析集合點(查看集合點與平均事務響應時間的比較圖)
圖中較深顏色的是平均響應時間,淺色的爲集合點,當Vuser 在集合點持續了1分後平均響應時間呈現最大值,可見用戶的併發對系統的性能是一個很大的考驗
3）Average Transaction Response Time 和Running Vuser 兩個數據圖
從圖中可以看到Vuser_init_Transaction(系統登錄)對系統無任何的影響,Vuser 達到15 個的時候平均事務響應時間纔有明顯的升高,也就是說系統達到最優性能的時候允許14 個用戶同時處理事務,Vuser 達到30 後1 分,系統響應時間最大,那麼這個最大響應時間是要推遲1 分鐘纔出現的,在系統穩定之後事務響應時間開始下降說明這個時候有些用戶已經執行完了操作.同時也可以看出要想將事務響應時間控制在10S 內.Vuser 數量最多不能超過2 個.看來是很難滿足用戶的需求了.
4）Transaction Response Time(Percentile)
圖中畫圈的地方表示10%的事務的響應時間是在80S 左右.80S 對於用戶來說不是一個很小的數字,而且只有10%的事務。
Transaction Response Time(Distribution)-事務響應時間(分佈)
顯示在方案中執行事務所用時間的分佈.如果定義了可接受的最小和最大事務性能時間,可以通過此圖確定服務器性能是否在可接受範圍內.
5） 判斷應用程序的問題
如果系統由於應用程序代碼效率低下或者系統結構設計有缺陷而導致大量的上下文切換(context switches/sec顯示的上下文切換次數太高)那麼就會佔用大量的系統資源,如果系統的吞吐量降低並且CPU的使用率很高,並且此現象發生時切換水平在15000以上,那麼意味着上下文切換次數過高.
從圖的整體看.context switches/sec變化不大,throughout曲線的斜率較高,並且此時的contextswitches/sec已經超過了15000.程序還是需要進一步優化.
6）. 判斷CPU瓶頸
如果processor queue length顯示的隊列長度保持不變(>=2)個並且處理器的利用率%Processortime超過90%,那麼很可能存在處理器瓶頸.如果發現processor queue length顯示的隊列長度超過2,而處理器的利用率卻一直很低,或許更應該去解決處理器阻塞問題,這裏處理器一般不是瓶頸.
%processor time平均值大於95,processor queue length大於2.可以確定CPU瓶頸.此時的CPU已經不能滿足程序需要.急需擴展.
7）. 判斷內存泄露問題
內存問題主要檢查應用程序是否存在內存泄漏,如果發生了內存泄漏,process\private bytes計數器和process\working set 計數器的值往往會升高,同時avaiable bytes的值會降低.內存泄漏應該通過一個長時間的,用來研究分析所有內存都耗盡時,應用程序反應情況的測試來檢驗.
圖中可以看到該程序並不存在內存泄露的問題.內存泄露問題經常出現在服務長時間運轉的時候,由於部分程序對內存沒有釋放,而將內存慢慢耗盡.也是提醒大家對系統穩定性測試的關注.