而web_find是查找前面的請求結果;使用時將它放在請求語句的後面。
另二者的參數也完成不一樣的,web_reg_find參數中SaveCount記錄查找匹配的次數,
web_find的機制是一旦查找匹配成功就立即返回,並不繼續查找和記錄匹配次數
再者Run-time設置中的“enable image and textcheck”對web_find有效,而對web_reg_find無效。
注意:web_find不支持URL模式下錄製的腳本。
執行效率:
web_reg_find可以直接在內存裏面檢查所指定對象是否存在;而web_find是文本檢查點,需要對應頁面完全顯示出來之後,纔會執行檢查。概言之,使用web_reg_find不用啓用文本檢查點功能;使用web_find就一定要啓用文本檢查點功能,否則檢查點無效。
很顯然,前者比後者執行效率要高,這也是LR要不建議使用後者的原因。
而web_reg_find()就不能通過它的返回值來作爲事務的判斷條件,因爲web_reg_find()的返回值0和1表示web_reg_find()是否註冊成功(web_reg_find是註冊類型函數,它本身並不執行),並不代表查找的內容是否存在,也就是說無論查找的文本內容是否存在,都返回0,(和web_find的返回值意義就不同了)。
我想問的是有什麼方法用web_reg_find()來作爲事務的判斷條件?
利用web_reg_find創建的參數SaveCount ,作爲判斷條件就可以了(如SaveCount>0)
web_find()(幫助不太推薦使用web_find而是推薦使用web_reg_find)要寫在請求後,也就是要在事務內了。這樣通過事務統計出來的響應時間就(包括了web_find()這個函數的執行時間)不真實了。而web_reg_find()是寫在請求前面的。如果能用web_reg_find()來作爲事務結束條件,那就是最好的.
事務時間等於Duration-Wasted Time,web_reg_find執行的時間Loadrunner會自動減掉的
另,LR自身已經提供了關於Page title的檢查點的設置。路徑: Recording setting >Advanced.
腳本示例:
Action.c(50): Error -26366:"Text=Dashboard" not found for web_reg_find [MsgId:MERR-26366]
Action.c(50):web_submit_form("wp-login.php_2") highest severity level was"ERROR", 39882 body bytes, 3207 header bytes, 12 chunking overheadbytes [MsgId:MMSG-26387]
Action.c(50): Notify: Transaction"Login_WordPress" ended with "Fail" status (Duration: 5.9267 WastedTime: 0.0000).
Ending action Action.
Action.c(110):web_url("index-extra.php_5") was successful, 1047 body bytes, 2682header bytes, 12 chunking overhead bytes [MsgId:MMSG-26385]
Action.c(124): Log onsuccessfully
Ending action Action.
Ending iteration 2.