loadrunner other

客戶端環境配置： 

a、IE瀏覽器配置推薦(IE9)

   瀏覽器是用來錄腳本，我本人習慣用IE8，IE9和火狐也能夠，IE9選擇32位的，就是win7系統有兩個IE9，選擇32的，x86

b、退出360等各類管家軟件

   360軟件管家會影響腳本的錄製

c、保證網絡正常

d、保證LR正常

 

單獨提交如何編寫腳本，把詳細過程以及注意事項都寫出來：

a、分析協議

  協議能夠理解爲一個約定，就是對數據包發送格式的統一約定，若是你按約定來就能識別你，也能發成功，若是你不按約定來就不認你，當前最主流的協議是WEB(HTTP/HTML)，只有選對了協議才能正常的錄製腳本，協議選擇不對錄製的腳本可能爲空

b、錄製腳本

  使用LoadRunner性能測試工具錄製腳本 

c、優化腳本(去掉無用的東西)

  有時錄製的腳本里有一些無用的東西，要把這些東西刪掉

d、強化腳本

  能夠在腳本里插入事務，檢查點，參數化，加入一些判斷條件等，讓腳本更健壯

e、調試腳本(屢次迭代經過才行)

  腳本強化完以後還要對腳本進行調試，必定要屢次迭代運行腳本

 

場景設計策略：

a、快增加

   秒殺使用快增加策略，瞬間用戶數就上來了

b、慢增加

  適用於全部場景

c、用戶數執行完中止場景

  這種場景用的比較少

 

通常狀況下場景設計的步驟以下：

---添加腳本

---添加壓力機

---設置run time setting

---設置Schedule

 

性能測試場景類型：

單場景(某個頁面、某個接口的單點性能)：用的比較多，登陸，達到開發的要求，還要壓出極限值，避免上線之後背鍋

混合場景：多個業務混合在一塊兒，如發帖，回帖等，排除數據庫死鎖或線程死鎖

穩定性場景：N*12，長時間跑看是否有內存泄漏，24小時只容許有一次full gc

 

Controller裏Global Schedule設置，按照下圖的配置便可：

選擇組模式能夠跑多個腳本的時候設置時間間隔，第一個腳本選擇Start immediately after the scenario begins，第二個腳本是在上一個場景開始後多長時間開始，能夠設置時間

百分比模式集合點置灰，並且百分比模式不能添加虛擬用戶，虛擬用戶組模式能夠看到集合點，能夠添加vuser

遞增模式：能找到最佳用戶數和最大併發數

多一次跳轉，多一次請求損耗，多入口也會影響性能

 

壓力時間：在線監控系統

 

監控用戶最高的那個時間段，有這個數據是最好的，若是沒人提供這個，建議壓15-20分鐘

壓力機：增長壓力的機器，能夠指定多個壓力機對系統進行加壓

 

添加壓力機的通常步驟：

a、保證要聯合的機器上裝了LR agent，並啓用了(狀態欄那裏會有一個小衛星)

b、本地系統的RPC服務開啓(改成自動)

c、請從你的Controller的機子上登陸下要聯合的機子

d、關閉防火牆+殺毒+360等，擁有權限，並在同一個網段內

 

A地點壓B地點(機房)的機器，要求很大的併發，選擇壓力機的原則是在機房選擇壓力機，能避免帶寬瓶頸

 

Loadrunner工做原理：

LoadRunner啓動之後，在任務欄會有一個Agent進程，經過Agent進程，監視各類協議的Client與Server端的通信，使用自帶的一套C語言函數將錄製下來的用戶操做轉化爲腳本，LoadRunner調用這些腳本向服務器發出請求，並接收服務器的響應，至於服務器內部如何處理，它並不關心

 

EXTRARES中的圖片是放在靜態服務器上的，對測試的影響不是很大，靜態文件浪費帶寬，真正有瓶頸的是動態的，若是你是想作系統的性能預估，那麼能夠保留EXTRARES中的內容，可是若是這裏的內容是與系統毫無關係的建議刪除掉

 

html錄製的腳本比較簡潔直觀，每一個錄製出來的請求只包含web_submit_data，web_url這兩個函數，能把隱藏域中的數據抓出來，很是容易理解和維護, 在回放時，html腳本積極地解析返回的信息來得到要下載的資源，缺點是腳本回放須要更多的cpu和內存，web_url的請求方式是GET請求方式，拿頁面數據的，web_submit_data函數是提交數據的，是POST請求方式，web_submit_data()函數能把隱藏域中的數據抓出來，而web_submit_form()不能

接口類型

HTTP接口：經過GET或POST來獲取數據，在數據處理上效率比較高，get請求的body裏爲空，post請求參數值能夠放在ITEMDATA裏，也能夠放在Body裏

webservice接口：經過soap協議來獲取數據，比起HTTP來講能處理更加複雜的數據類型，對於移動、電信使用webservice接口

 

緩存產生的緣由：經過緩存讀取數據要比從磁盤讀取快，工人如cpu，車間如內存，倉庫如磁盤，車間越大越好

 

sprintf函數的做用是把格式化的數據寫入某個字符串中而後打印出來

lr_save_string("192.168.0.99","ip")函數的用法是把第一個值保存到第二個裏

API (Application Programming Interface)，就是接口

web_add_header("name","value")請求頭函數，把值塞到屬性裏

 

lr_output_message(lr_eval_string("{Param_qqCheckOnlineResult}"))

lr_eval_string函數主要是返回腳本的一個參數當前的值，以lr_eval_string("{title_count}")爲例，取出title_count的值，lr_eval_string函數通常和文本檢查點配合使用，查詢文本檢查點查詢到的文本次數，經過atoi(lr_eval_string("{title_count}"))這樣的方式和0進行比較，lr_eval_string函數放在腳本，Action()部分裏最後一個web_url()函數的後面，return 0的前面

 

if(atoi(lr_eval_string("{title_count}"))!=0)

{

  lr_output_message("發帖成功");//輸出日誌，輸出來是黑色的

}                                      

else

{

  lr_error_message("發帖失敗");//輸出日誌，輸出來是紅色的

}

 

web_image_check("imcheck","Src=圖片的相對路徑",LAST)是圖像檢查點函數，要放在請求的後面，第一個參數能夠隨便，叫什麼名字均可以，第二個參數是圖片的相對地址， 如何查找圖片的相對地址呢，首先找到要設置成圖片檢查點的圖片，點擊鼠標右鍵，點擊屬性按鈕，就能夠看到圖片的地址，去掉登陸頁面的URL剩下的部分就是圖片的相對地址，設置成圖片檢查點後，還要設置一下，在LR腳本頁面點擊Vuser按鈕，找到Run_Time_Settings，在Preferences標籤裏找到Checks選項，勾選Enable Image and text check，就是設置圖片和文本檢查點的前置條件就是勾選上Enable Image and text check，不管是文本檢查點仍是圖片檢查點檢查的都是源碼，HTML的源文件，源碼裏Src對應的相對路徑，若是Src那裏填上絕對路徑就會查不到，並且還會報錯

 

loadrunner事務響應時間包括數據發送和數據接收的時間，包括請求接收完畢，事務完成，loadrunner和jmeter都是完整的接收返回結果，才能發送下一次請求，ab，webbench只判斷服務器狀態2X，不接收服務器返回結果，只握手不揮手，由於測試是面向用戶的，要接收返回結果，我是用loadrunner測試的，以個人爲準，只包括髮送時間，響應時間短，天然併發就會多一些，ab，webbench和cpu的關係，測試併發不同，cpu越多，發出的請求越多，併發越多

ab、webbench比 loadrunner 、jmeter併發多不少，jmeter比loadrunner測的響應時間會短一些，loadrunner比jmeter測的準確一些，併發過萬的話用ab，webbench，他們沒有license的限制，併發不到1萬的話用哪一個工具都行，jmeter性能測試的tps比loadrunner的大10倍，由於jmeter默認勾選了Use KeepAlive，連接不會斷開，還使用這個連接通道

 

jmeter自己內存溢出、垃圾回收或服務器掛了，tps沒有變化，請求沒有發出去，響應也沒有返回來

 

在多大併發下的響應時間，在多長響應時間內的併發數，按照開發的角度定義事務，響應時間不包括前端頁面的加載 

從負載機發起壓力，到最終負載機接收到整個數據包結束，end transaction結束，這個過程是loadrunner的響應時間

 

開發說爲何我看到的響應時間比你看到的響應時間小不少？

開發看時間在日誌裏看，看接口，打點end-start

一、測試工具的差別性  二、測試腳本的差別性(事務定義不同致使測試結果不同、思考時間的位置不同)  三、測試版本  四、測試環境(硬件，軟件，數據)，硬件是整個架構的全部硬件，軟件是指數據庫的配置，redis的配置，nginx的配置，數據量大小測試結果也不同  五、人爲緣由(壓測時別人也在操做服務器，對服務器壓測)