Loadrunner經常使用操做

  LoadRunner 參數化

爲何須要參數化？

大衆理解：爲了更加真實的模擬用戶操做

底層原理: 1，應用服務，數據庫會校驗該值的惟一性（unique key）

          2，爲了不數據庫的查詢緩存對性能測試結果的影響

  LoadRunner 關聯

1、爲何須要作關聯？

1，回放的時候業務沒有成功

2，服務器返回一個動態變化的值，而且下次請求時須要用到這個動態變化的值

3，提交請求的時候，服務器會校驗這些值的合法性；它們之間有依賴關係

2、關聯步驟：

1，找到服務器返回的動態變化的值

2，保存爲一個參數

3，替換

3、哪些值須要作關聯？

1， 服務器返回的動態變化的值，而後提交的時候校驗該值的合法性（跟數據不打交道）

A,驗證碼（圖片驗證碼、手機/短信驗證碼、郵箱驗證碼）

圖片驗證碼 關聯不到裏面的字符串（須要知道字符串從哪一個jsp 裏取出來的）

手機/短信驗證碼、郵箱驗證碼  驗證碼都是加密之後的

解決方法：1，讓開發設置萬能驗證碼；2，去掉驗證碼（通常不建議）

B,Session ,token 

C,時間戳

D,看起來沒有任何意義的特殊字符串，還出如今你的請求裏而且還不是你本身輸入的字符串  

2， 跟數據庫打交道的(增刪改查)

A.Insert  插入的值跟其餘數據有關聯關係-經過一系列ID 創建這種關係

特徵： 自增主鍵   Xxid   int 類型

Insert into 帖子表 values (uid,title,msg,posttime,fid)

Insert into 回帖表 values(tid,uid,msg,posttime,fid)

B.Delete  補全where id 類條件

Delete from table where xxid = ?? and xxid =?? And

                      In  （，，）

                      Not in (,,)

 between < >

C. Update 補全where 後面的 id類條件

Update table   set      where  同上

D .  select  補全where 後面的 id 類條件

select  字段 from 表 where 同上

實操： 淘寶網註冊-> 登陸-> 綁定收件信息->修改暱稱->刪除一條收件地址->瀏覽商品->添加到購物車->支付->查看訂單-> 取消訂單-> 撤銷申請-> 確認收貨->評論-> 追加評論

註冊：參數化 手機號 （惟一性校驗）關聯：手機驗證，session/token

登陸：參數化 手機號（惟一性校驗）關聯：session /token

綁定收件信息：關聯uid

修改暱稱： 關聯uid

刪除一條收件地址：關聯uid ,收件信息id

瀏覽商品：參數化 商品id

添加到購物車：關聯uid, 商品id 店鋪 id

支付：關聯uid ,訂單id

查看訂單： 關聯uid ,訂單id

取消訂單： 關聯uid ,訂單id

撤銷申請： 關聯uid ,id(訂單id 或者工單id )

   確認收貨：關聯uid ,訂單id

   評論：關聯uid,訂單id ,店鋪id,商品id

   追加評論：關聯uid , 訂單id ,評論id

4、關聯函數的位置

關聯函數放在哪一個函數的前面，只會做用於它的下一個請求，因此關聯函數的位置很重要

Insert  操做後緊接一條select 操做，將id 查出來以便後續操做--關聯參數放在insert 以前

5、關聯函數的寫法

A,response 右鍵直接關聯 (位置必定對)

B, insert -new step

C，Data returned by server （tree 視圖中沒有內容的時候）

D, 頁面源代碼

E，抓包

Fiddler 4 操做

Fiddler hide if url contains :REGEX:\.(js|css|js|png|gif|ico|gif\?.*|css\?.*|js\?.*|png\?.*)$

Any process  點擊拖拽到瀏覽器上，則只記錄該瀏覽器上的操做

 

腳本精簡：跟實現業務無關的請求均可以去掉，可是關聯的依賴請求不能去掉

 完善腳本

1、插入事務

事務：是一切腳本的基礎

是成對出現的，start end 中名字需如出一轍

事務需定義準確，不要包含與被測接口無關的請求

事務中不包含集合的、思考時間

爲了保持請求的乾淨及事務響應時間的準確性

2、模擬用戶思考時間

Think Time : 等待多長時間再執行下面的請求

底層做用：控制請求的發送頻率，以達到控制服務器壓力的目的

能影響事務的響應時間及tps

Tps:1s 鐘的時間能處理幾個事務

3、插入檢查點

檢查點：會影響性能

爲了調試用的；通常壓測過程當中去掉檢查點

Web_reg_find  預註冊函數，放在請求前

Web_find ,web_image_check 等函數性能很差，不建議使用

注意事項：文本檢查點函數須要注意位置；圖片檢查點須要開啓run-time settings 裏的設置

數據庫寫操做能夠不加檢查點

Select 操做時才須要加檢查點

4、插入集合點

集合點：

是反映服務器的瞬時壓力

集合點只是在某些特殊場景中須要驗證嚴格併發是否可以經過，好比秒殺

集合點不能添加到事務中，要放在事務外，不然事務的統計會把集合點的等待時間也統計進去

進程、線程：默認勾選線程，進程資源消耗太多，通常沒那麼多執行機資源的

實踐經驗：若是跑場景是出現亂七八糟的事務，run-time settings  中miscellaneous 中先勾選 automatic transactions 下的兩個選項，

點擊【保存】->再次打開run-time settings ，取消勾選這兩項，點擊【保存】便可

  其餘協議腳本

 1、Webservice 實例

第一個是檢查點，第2、三個是關聯

兩關聯是如出一轍，只是結果稍有不一樣。工做中任選

對應的函數分別爲：

Lr_xml_get_values()

Lr_xml_find()

Lr_xml_extract()

2、WindowsSocket 協議：

選擇windowsSocket協議，點擊錄製

相關函數：

Lrs_receive_ex

Lrs_receive

Lrs_save_param