腳本錄制及優(yōu)化 loadrunner

1、添加文本檢查點(diǎn)-搜索web_reg_find("Fail=NotFound", "Search=Body", "SaveCount=CHECK","Text=Don't forget to sign off whenn""you're done",LAST);文本檢查判定語(yǔ)句if (atoi(lr_eval_string("para_count")>0) /驗(yàn)證是否找到了頁(yè)面上的要檢查的字符串lr_output_message("we find

2、 the string!");elselr_output_message("sorry,don't find the string!");用戶(hù)名的日志輸出：Lr_log_message(“用戶(hù)名：%s”，lr_eval_string(“username”)；腳本校驗(yàn)檢查點(diǎn)數(shù)據(jù)分析：SD 標(biāo)準(zhǔn)偏差值Transaction 場(chǎng)景Init 初始化Scale 比例Additional 額外的Granularity 間隔尺寸Filters 篩選throughout 吞吐量Transaction summary 事務(wù)摘要性能測(cè)試遞增1、 創(chuàng)建場(chǎng)景分析：?jiǎn)枺菏聞?wù)相應(yīng)時(shí)間

3、 先緩慢上升 再平衡 再下降 說(shuō)明什么？答：緩慢上升 說(shuō)明事務(wù)響應(yīng)時(shí)間變長(zhǎng) 說(shuō)明系統(tǒng)處理能力在下降 再平衡 并發(fā)用戶(hù)數(shù)已經(jīng)飽和再下降 并發(fā)用戶(hù)數(shù)下降了如果系統(tǒng)沒(méi)有此類(lèi)機(jī)制 則響應(yīng)時(shí)間不斷上升 直至宕機(jī)Java 創(chuàng)建對(duì)象的時(shí)候 不釋放內(nèi)存 創(chuàng)建太多會(huì)導(dǎo)致該問(wèn)題問(wèn)：業(yè)務(wù)失敗情況 但是其他的都正常答：數(shù)據(jù)庫(kù)可能被鎖住，數(shù)據(jù)庫(kù)有互斥性，需要修改數(shù)據(jù)庫(kù)系統(tǒng)要求1、 支持同時(shí)多少個(gè)并發(fā)登錄？2、 登錄響應(yīng)時(shí)間不超過(guò)3秒3、 CPU使用率不應(yīng)超過(guò)80%4、 內(nèi)存使用率不應(yīng)超過(guò)75%關(guān)鍵指標(biāo)分析：Transactions per Second 針對(duì)場(chǎng)景運(yùn)行過(guò)程中的每個(gè)時(shí)間點(diǎn)取樣一次，顯示在

4、這個(gè)時(shí)間點(diǎn)上的每個(gè)事務(wù)的通過(guò)、失敗、停止的個(gè)數(shù)我還在 Analysis 里面找了一下，發(fā)現(xiàn)圖表的時(shí)間顯示粒度也是可以設(shè)置的。具體方法為：在圖表上點(diǎn)擊右鍵 -> 選擇“ Set Granularity ”或者直接按Ctrl+G 。我試著把時(shí)間粒度調(diào)成以毫秒為單位，結(jié)果LoadRunner 提示當(dāng)前不支持以毫秒為顯示粒度，由此我推斷LoadRunner 對(duì)于 Transactions perSecond 這張圖，最小的取樣粒度為1 秒LoadRunner

5、 模塊VuGen 腳本工具 腳本開(kāi)發(fā)完畢之后 放入 console 進(jìn)行模擬環(huán)境 再用監(jiān)視工具M(jìn)onitor 再用analysis分析Console+Monitor = controller通過(guò)每秒鐘處理的頁(yè)面度 每秒處理字節(jié)度設(shè)計(jì)過(guò)程：分析并發(fā)用戶(hù)數(shù)、分析場(chǎng)景、計(jì)劃場(chǎng)景及操作劃分、每個(gè)場(chǎng)景的交易/點(diǎn)擊率、時(shí)間。測(cè)試目的：9:00-10:00 有120W用戶(hù) 在一個(gè)峰值的時(shí)候 會(huì)產(chǎn)生多少交易/點(diǎn)擊 交易持續(xù)多長(zhǎng)時(shí)間測(cè)試數(shù)據(jù)：N秒鐘處理的并發(fā)用戶(hù)數(shù)，及產(chǎn)生的交易量?？疵總€(gè)并發(fā)量在并發(fā)下的響應(yīng)時(shí)間。1、 制定性能測(cè)試目標(biāo)2、 業(yè)務(wù)需求轉(zhuǎn)換成性能測(cè)試需求3、 設(shè)計(jì)測(cè)試場(chǎng)景，根據(jù)不同場(chǎng)景進(jìn)行手工用例設(shè)

6、計(jì)4、 通過(guò)用例使用到的協(xié)議，對(duì)壓力進(jìn)行模擬5、 參照設(shè)計(jì)規(guī)劃進(jìn)行設(shè)計(jì)實(shí)施，設(shè)置場(chǎng)景及負(fù)載對(duì)系統(tǒng)進(jìn)行試壓6、 試壓完畢后對(duì)系統(tǒng)性能分析，監(jiān)控的時(shí)間軸與壓力傳遞的時(shí)間軸匹配7、 對(duì)運(yùn)行測(cè)試用例進(jìn)行分析，分析出性能瓶頸Louadrunner 是截獲網(wǎng)絡(luò)通信，將你選擇的通信協(xié)議截獲之后放入腳本中相當(dāng)于一個(gè)病毒，所以要測(cè)試 需要關(guān)閉所有防火墻和殺毒軟件事務(wù)插入之間不能計(jì)入響應(yīng)等待時(shí)間，否則誤差過(guò)大腳本關(guān)聯(lián)Session ID 一個(gè)人模擬出多用戶(hù) 服務(wù)器如何進(jìn)行判斷服務(wù)器會(huì)返回給一個(gè)單獨(dú)的序號(hào)，而回放 無(wú)法響應(yīng) 因?yàn)閟essionID 過(guò)期了解決問(wèn)題的辦法 ： session 關(guān)聯(lián)自動(dòng)關(guān)聯(lián)：自動(dòng)corr

7、elation處理只能針對(duì)使用HTTP協(xié)議、部分client/server協(xié)議的腳本，針對(duì)Socket協(xié)議 腳本不能使用自動(dòng)correlation關(guān)聯(lián)correlation原理：LR 內(nèi)置了部分常用應(yīng)用服務(wù)器和框架產(chǎn)生的特征字符串，通過(guò)在腳本中搜索特征字符串進(jìn)行替換處理關(guān)聯(lián)correlation操作：enable correlation during recording錄制完成后 通過(guò)“Vuser”“Scan Correlation”1.將loadrunner菜單欄的TOOLS->Recording Options->Enable correlation during record

8、ing,設(shè)置為選擇2.開(kāi)始錄制，錄制過(guò)程中l(wèi)oadrunner會(huì)自動(dòng)關(guān)聯(lián)，以下是錄制首頁(yè)登錄時(shí)驗(yàn)證碼關(guān)聯(lián)的部分腳本查找session 關(guān)聯(lián)視頻Error分析！Log_in.c(10): Continuing after Error -27796: Failed to connect to server ":1080": 10061 Connection refused分析：查看應(yīng)用程序是否運(yùn)轉(zhuǎn)正常，服務(wù)器的連接數(shù)配置問(wèn)題，每次提高25%再進(jìn)行測(cè)試Spring 控制的最大連接數(shù)太低Log_in.c(62): Continuing after Error -2

9、6374: The above "not found" error(s) may be explained by header and body byte counts being 0 and 0, respectively.結(jié)果分析！1、代表90%的用戶(hù) 代表 網(wǎng)頁(yè)平均相應(yīng)時(shí)間 HTTP200 代表返回正常2、代表 通過(guò)的事務(wù)數(shù)越多則系統(tǒng)處理能力越強(qiáng)，失敗事務(wù)數(shù)少則系統(tǒng)越穩(wěn)定3、Average Throughput (bytes/second):23,241核心數(shù)據(jù)之一：時(shí)間越小說(shuō)明處理速度越快，事務(wù)的相應(yīng)時(shí)間不應(yīng)超過(guò)用戶(hù)的最大接受范圍。否則會(huì)出現(xiàn)系統(tǒng)響應(yīng)過(guò)慢。4、 tr

10、ansaction per second關(guān)鍵數(shù)據(jù)之一，代表系統(tǒng)在同一時(shí)間內(nèi)能處理業(yè)務(wù)的最大能力，數(shù)據(jù)值越高，則能力越強(qiáng)，但最高值不代表最大處理能力，TPS受負(fù)載影響，也會(huì)隨負(fù)載增加而增加 當(dāng)系統(tǒng)進(jìn)入繁忙期之后TPS會(huì)有所下降5、 transaction performance summary代表事務(wù)的平均時(shí)間 最大之間 最小時(shí)間 柱狀圖的落差越小 說(shuō)明響應(yīng)時(shí)間的波動(dòng)越小，落差大說(shuō)明系統(tǒng)不夠穩(wěn)定。6、 transaction response time under load 該圖線條越穩(wěn)定說(shuō)明 系統(tǒng)越穩(wěn)定7、 transaction response time（percentile）事務(wù)響應(yīng)時(shí)間

11、的百分比可分析出各部分事務(wù)的響應(yīng)規(guī)律，越平穩(wěn)說(shuō)明相應(yīng)時(shí)間越小8、 transaction response time（distribution）響應(yīng)時(shí)間越小的分類(lèi)下的事務(wù)越多越好9、10、11/橫軸時(shí)間 縱軸事務(wù)，說(shuō)明走完所有流程用戶(hù)只需要4秒鐘12、顯示 web_page_breakdown web page diagnostics全部顯示出所有事務(wù)占用時(shí)間，分析出最占用時(shí)間的事務(wù)%processor time(processor_total):器消耗的處理器時(shí)間數(shù)量.如果服務(wù)器專(zhuān)用于sql server 可接受的最大上限是80% -85 %.也就是常見(jiàn)的CPU 使用率.Availiable

12、 bytes(memory):用物理內(nèi)存數(shù). 如果Available Mbytes的值很小（4 MB 或更?。?，則說(shuō)明計(jì)算機(jī)上總的內(nèi)存可能不足，或某程序沒(méi)有釋放內(nèi)存。%DPC time(processor_total):越低越好。在多處理器系統(tǒng)中，如果這個(gè)值大于50%并且Processor:% Processor Time非常高，加入一個(gè)網(wǎng)卡可能會(huì)提高性能，提供的網(wǎng)絡(luò)已經(jīng)不飽和。判斷應(yīng)用問(wèn)題Processer timeThoughtout Context switches/sec 上下文切換目前 無(wú)法查看 windows resource 圖形 需要付費(fèi)測(cè)試報(bào)告樣板1、 測(cè)試結(jié)果展示針對(duì)每個(gè)流程進(jìn)行單獨(dú)測(cè)試或者整體測(cè)試的分塊典型用例并發(fā)數(shù)平均響應(yīng)時(shí)間成功失敗出錯(cuò)信息訪問(wèn)首頁(yè)1000.6551000無(wú)2001.07120003001.5223000系統(tǒng)登錄1001.8591000無(wú)2003.8252000無(wú)