1、log的設定方式。
在 runtime setting中可以設定log的生成方式：
預設的log方式：
enable logging選中，log option是send messages only when an error occurs.
可以修改日誌的方式：
always send messages（這種方式會一直列印輸出日誌，不僅在錯誤時）
standard log——記錄所有的請求反饋的日誌，包括successful和fail的日誌。
extended log——可提供擴充套件的日誌資訊，包括
parameter subsititution——日誌中列印所有中使用的引數值。
data returned by server——日誌中列印每個客戶端請求伺服器返回的資料值
advanced trace——日誌中列印所有的訊息資訊和函式執行資訊
2、log的儲存方式
log的儲存路徑在res資料夾下。
如果是從指令碼中直接關聯create scenario則在指令碼的目錄下的res下。如果是直接create scenario然後再選擇指令碼的話，則儲存在c盤，如「c:documents and settingsusernamelocal settingstempreslog」
具體該場景的日誌結果存哪，可以檢視controll的result介面的result setting定義的目錄。
根據不同的log記錄級別，在log檔案中記錄日誌。
3、log資訊的分析
1）從log中得到虛擬使用者失敗的原因。
通常如果場景在執行時出現使用者失敗，則先要檢視錯誤原因，可直接檢視日誌，從日誌中檢視error的資訊；
從outputdb中可以檢視到錯誤**error code
2）從日誌中確認每次分配給虛擬使用者的引數值
想判斷是否在場景中每個使用者使用不同的或預定義規則的引數，可以通過在log生成規則處設定為parameter subsititution，然後檢視每個日誌檔案中的對應行引數值是否為預計的引數值。可從此判斷出是否同使用者的實際使用類似，是否達到對伺服器的壓力策略。
3）從日誌中確認伺服器端返回的值是什麼。
在指令碼中通常設定了檢查點，檢查點策略是否生效，如果對此產生懷疑則可以考慮從日誌中檢視一下。檢視伺服器返回的值來驗證是不是所期待得到的值。
思考問題
log的輸出 會不會影響到客戶端，會不會使客戶端成為瓶頸？（認為是會的，任何程式都是要消耗資源的，loadrunner也一樣，所以選取日誌輸出的模式是要謹慎考慮盡量以適用為前提）
loadrunner輸出log中的亂碼解決
方法一 直接在loadrunner裡面轉碼 特別是當返回值是亂碼，卻要作為引數的時候 char token char temp 100 lr convert string encoding lr eval string utf 8 null,myroom 將utf 8轉成系統當前的編碼 strcpy...
LoadRunner學習筆記log函式
lr log message 只是記會寫到本地vuser的log裡面。lr message和lr output message基本相同，它們會同時寫到vuser的log和傳送到controller裡面，也就是說如果你 在有很多壓力客戶機，它們會把資訊除了記錄在本地的vuser之外，還要傳送到遠端的c...
loadrunner中的事務
loadrunner中的事務是度量操作客戶端與伺服器之間的響應時間,度量每乙個虛擬使用者的請求所消耗的時間的乙個單位.分為以下2種 1 指令碼預設的transaction,如action，這個是在最大的transaction。如平均響應時間這些的最大的事務就是action transaction，小...