loadrunner:文本检查点web_reg_find和web_find两个函数的区别
而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
Action.c(50):web_submit_form("wp-login.php_2") highest severity level was"ERROR", 39882 body bytes, 3207 header bytes, 12 chunking overheadbytes
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
Action.c(124): Log onsuccessfully
Ending action Action.
Ending iteration 2.