寫在前面：我是一條魚，記憶只有7秒。
1.腳本處理要點
- 錄制設置
- 亂碼處理
- 幫助文檔使用說明
- 參數化
- 關聯
- 關聯數組
- 事務
- 檢查點
- 思考時間
- 集合點
2.錄制設置
2.1創建腳本時的協議選擇
方式一：已知被測系統采用的協議
如果已知被測系統的采用的協議，在新建腳本時，可以選擇對應的協議。
路徑：File->New Script and Solution 或者File->add->New Script.
方式二：未知被測系統的協議
如果不知道被測系統的協議，可以點擊上圖左小角的protocol advisor進行協議分析。
被測系統分為B/S系統和C/S系統，具體信息可以打開這個界面后按“F1”查看幫助文檔。
特別注意：當選擇web browser后，url address的地址中不要加【http://】。
如果loadrunner自帶的協議分析工具不好用（比如我的lr12+win10 64，就根本打不開ie），那么就搜索其他協議分析工具進行分析。
TIPS：最快的方式是，問開發?。。∷恢溃屯铣鋈?#算了。
2.2腳本錄制設置
1.錄制選項
Immediately和In delayed mode的區別在于：
Immediately：點擊錄制后就開始錄制腳本；
In delayed mode：點擊錄制后，會先在瀏覽器中打開url地址，再次點擊開始錄制，才會錄制操作腳本。
2. Recoding Options
選擇recording options對錄制過程中的一些選項進行設置。
設置一：選擇錄制的函數為web_url()[相當于get請求]和web_submit_data()[相當于post請求]。
為什么要這么選擇？
&&：因為這2個函數是不依賴于上下文的，有利于腳本的處理。
設置二：編碼設置，預防錄制亂碼。
在沒有進行設置時，錄制時的編碼是默認與操作系統一致的。通常操作系統為GB系列的編碼。當默認的錄制編碼與被測系統的編碼不一致時，錄制后的腳本中，就會存在亂碼。
Q：怎么查看被測系統的編碼？
&&：打開被測系統，在瀏覽器中右鍵查看源文件：
在錄制選項中，設置編碼，如圖：
2.3錄制過程中的操作
錄制過程中，當需要對腳本進行新建方法、添加事務、添加集合點、添加檢查點等操作時，可以直接在錄制界面，暫停后進行操作：
要了解詳細的操作過程，可以將鼠標放在這個操作欄上，然后按“F1”查看幫助文檔。
3.運行時設置
腳本錄制完成后，可以對腳本進行編譯和運行，查看腳本運行的結果是否符合預期。
3.1 runtime settings
路徑：replay->runtime settings
快捷鍵：F4
3.2 runtime settings中可以設置的內容
【將鼠標放在對應的選項上，會出現該選項具體的說明】
runtime settings中的設置進行保存后，可以作用于vugen、controller、性能中心等。
在該項設置中，可以設置如下內容：
- run logic：迭代次數、運行順序、每個action的運行次數等。可以用insert block進行分塊，設定每個模塊的運行比例，可以實現30%的用戶運行A模塊、70%的用戶運行B模塊；
- pacing：可以設置每次迭代的步進時間。設置有效的步進時間有利于更加真實地模擬用戶使用場景；
- think time：思考時間。可以設置運行時是否忽略思考時間（建議不要忽略）、思考時間的長短、還可以設置隨機思考時間。
- log：可以設置日志的輸出級別。如果在調試運行中，不想看到輸出全部日志數據在控制臺，可以設置出錯時才輸出日志。同時，可以設置腳本中用到的參數【parameter substitution】，在運行時，可以在控制臺看到每次迭代用到的數據變化。
- additional attribute：目前不知道這個的使用場景。感覺可以使用這個屬性在腳本中使用對應的值，比如用函數：lr_get_attrib_string()去獲取參數名對應值，在腳本中進行應用，類似于jmeter中用戶定義的變量?？梢杂糜谠O定全局變量。具體用法可以參考loadrunner中lr_get_attrib_string()給出的示例進行理解。
- miscellaneous：其他。這部分可以設置錯誤處理、每個用戶使用進程或線程、事務的統計方式(直接影響響應時間等的統計）。
- browser emulation：可以設置請求頭中的信息，如：瀏覽器信息、緩存機制等。
- Speed Simulation：帶寬模擬。默認為最大帶寬，可以根據被測系統用戶使用的真實場景進行帶寬的設定。
- content check：不知道這個的使用場景。查資料說明這個功能將會在腳本運行時自動幫你在頁面上檢查你的預期信息，聽起來類似于檢查點。具體使用方式為：添加應用、規則、檢查文本等信息，不過還是不知道怎么用。
- proxy：代理。設置代理信息。
- preferences：這一項里能設置的內容比較多。主要包括：編碼、http、ip、日志長度等相關信息，具體可以根據需要詳細查看。
4.參數化操作
為什么要進行參數化？當然是為了模擬用戶真實場景咯。
哪些數據需要進行參數化？在每次操作需要進行變化的數據。
哪些數據能夠進行參數化？已經存儲在數據庫且不會進行變化的數據。
4.1參數化類型
- 用戶名、密碼：已經存在數據庫的，需要預先獲取存在對應的文件中進行獲取；
- 日期
- 隨機數
- 表格
- xml格式
4.2參數化運行順序
- 順序
- 隨機
- 唯一
- 參數聯動（類似于表格格式了）
4.3參數化引用數據格式
{parameter}
調試時，可以采用lr_output_message(“{parameter}")輸出參數。
5.關聯
為什么要用關聯？當請求中用到的數據來源于之前請求的響應數據時。
5.1關聯的方式
方式一：錄制時可以設置關聯規則
方式二：錄制完成后，可以獲取需要關聯的數據
方式三：手動關聯
手動查找需要關聯的數據。
5.2關聯函數
這4個函數的使用方法可以見幫助文檔。
關聯函數需要放在獲取關聯數據的請求之前。
關聯數組：
在函數中增加ord=，示例如下：
web_reg_save_param("forum",
"LB=href=\"thread.php?fid=",
"RB=\" target=\"_blank\">",
"Ord=all",
LAST);
forum是一個數組，在引用的時候應該怎么操作呢？
&&：用loadrunner的自帶函數獲取數組的隨機值：lr_save_string(lr_paramarr_random("forum"), "forumid");
6.事務
- 統計一個請求或者一批請求的響應時間；
- 統計事務的成功率；
- 在要統計的請求前后添加事務的開始函數和結束函數：lr_start_transaction()
7.檢查點
檢查點用于判斷事務是否成功。因為事務自帶的判斷是通過判斷響應的狀態碼，只有4XX、5XX才會被判斷為失敗，這樣不一定符合業務邏輯，因此需要用到檢查點。
檢查點函數：
web_reg_find()，該函數放在要檢查的請求之前。
檢查點的用途：
- 判斷事務是否成功：
- 判斷當前頁面返回的值為A還是B，如果為A則執行A場景、為B則執行B場景，可用于腳本開發的場景設計；
- 檢查點的示例，可以查看該函數的幫助文檔，非常清晰明確。
8.思考時間
推薦設置隨機思考時間，并且不要太長，可以在runtime settings中進行設置。
9.集合點
9.1集合點的使用場景
適應場景：并發測試，屬于性能測試的一種。
負載測試、壓力測試、容量測試
- 并發測試：主要關注大用戶量并發時，所有用戶都在發同一種請求。
- 壓力測試：并發測試可以看做壓力測試的一個子集，當壓力測試時，指標出現異常卻不能分析出是哪個模塊出現異常時，可以采用并發測試對某個模塊進行測試，去定位問題。壓力測試是為了讓系統處于極限，在這類測試中可以忽略思考時間。
- 負載測試：評估性能指標時采用，比如：100個用戶時，系統是什么樣的狀態，1000個用戶時，系統是什么樣的狀態。因此，這類測試最需要接近于用戶的真實使用測試。
- 穩定性測試：長時間標準用戶數對系統進行測試。比如：采用最佳用戶數對系統進行長時間進行測試。
- 最佳用戶數的考量，需要系統的各項指標進行考量評估最佳用戶數；
- 最大用戶數：系統的某一項性能指標出現極限，則在當前狀態下為最大用戶數，該數據由負載測試獲取。
- 容量測試：模擬系統長時間運行后的性能狀態，比如：關系型數據庫。
9.2集合點的設置
在腳本中插入了集合點后，可以在controller中進行設置。
路徑為：scenario->rendezvous.可以啟用或者禁用，啟用可以設置集合點策略。
在腳本中，應該先有集合點，再有事務，否則集合點處的等待時間也會統計到事務中，不符合時間場景。因此順序為：集合點、事務起點、事務、事務終點。另一方面，當設置了集合點后，其實就不太符合用戶真實場景了，因此在執行有集合點的場景時，應該主要關注有集合點的這個請求是否會給服務器造成異常或者瓶頸。
寫在后面：忘得太快，下一篇要給自己備注一個采用了以上場景的腳本。
