場景
用loadrunner11錄制腳本，處理后回放，加上檢查點，報錯找不到檢查點對應的內容，去掉檢查點，沒有報錯，但是打開頁面沒有該操作的痕跡。手動在頁面上操作沒有問題。
解決過程
- 懷疑是腳本中請求有問題或者沒有作關聯。在頁面上通過開發者工具（F12）查看幾個關鍵請求，都沒有問題，順序和內容都能對得上。使用到的參數和返回值，都是固定的，無須關聯。
- 查看應用日志，看是否有報錯信息。應用有十幾個中心，通過dubbo調用，然而由於使用的docker容器，日志沒有做改造，無法進行采集查看，而且啟用的容器數量比較多，還有其他人使用，查看入口的web容器日志（6個），跑loadrunner腳本，無法看清日志內容，只能作罷。
- 使用postman模擬loadrunner中報錯的請求。將loadrunner中的請求轉換在postman中實現，發現報錯用戶沒有登錄。這次采用的架構與之前不同，后端為java應用，前端為react，通過接口和后端交互，所以其實loadrunner中的請求與前端和后端交互的請求基本一致，但是loadrunner沒有保存接口要求的驗證信息token，同時，token經過一定時間要求更新，所以出現該問題。
解決方案
知道了問題為loadrunner請求時沒有在header中加入token，就簡單了很多。在登錄步驟，獲取token，然后，在需要token認證的步驟的header中加入token。
// token長度較長，web_reg_save_param默認長度為256，不夠存儲，所以需要該函數設置其長度（1024字節）
web_set_max_html_param_len("1024");
// 獲取token函數，第一個參數為存儲的變量名，LB和RB為左邊界和右邊界，ORD為第幾位，NotFound為找不到時的響應
web_reg_save_param("token",
"LB=\"token\":\"",
"RB=\"",
"ORD=1",
"NotFound=warning",
LAST);
// 打印
lr_output_message("token is %s\n",lr_eval_string("{token}"));
// 為接下來的請求header添加內容
web_add_header("token","{token}");
總結
壓測相關的東西，現在是在邊實戰邊學（主要是之前搞壓測的同事離職了），之前看着同事弄，感覺很簡單，就是錄制，然后參數化，關聯，就完事了，只要懂業務就行了，自己上手了才發現，好多loadrunner方面的東西很多都不懂，還有業務方面也有很多不懂，還是要多動手多學習。
------------------------------------------分割線-------------------------------------------------------------
2019.10.16號補充：
今天發現，web_add_header只對后續的第一個請求有效（這個早就知道了其實），而如果是通過頁面錄制的腳本，往往請求數很多，每個請求前都加上會很麻煩，lr提供了另一個函數web_add_auto_header，自動為所有請求加上header，只需要在獲取到token后，使用該函數，則會自動為后面所有請求添加header。