51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 9019|回复: 15
打印 上一主题 下一主题

[原创] LoadRunner的URL和HTML方式的区别

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-5-7 17:13:19 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
请熟悉的人能否说下:

LoadRunner的URL和HTML录制方式的区别?
(主要区别基本知道)

主要是这两种方式都适用什么样的需求和场合?为什么?

比如我想测试sohu首页登录的性能,录制的时候如果选择HTML方式,因为页面有居多其他元素(图片,框架等),会大大影响测试后的结果。

这种情况下是不是要录制成URL方式,然后把页面对其他资源的请求的语句删除?

忘赐教!
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2008-5-7 17:38:11 | 只看该作者
关注一下,学习...
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2008-5-7 17:52:59 | 只看该作者
HTML-based Script,说明脚本中采用HTML 页面的形式来表示这种方式的Script 脚本容易维护,容易理解;
       URL-based Script,说明脚本中的表示采用基于URL 的方式,WAS 和ACT
中的录制方式就是这种,这种方式看上去比较乱。
选择哪种方式录制,有以下参考原则:
(1) 基于浏览器的应用程序推荐使用HTML-based Script
(2) 不是基于浏览器的应用程序推荐使用URL-based Script。
(3)如果基于浏览器的应用程序中包含了JavaScript 并且该脚本向服务器产生
了请求,比如DataGrid 的分页按钮等,也要使用URL-based 方式录制
(4 )基于浏览器的应用程序中使用了HTTPS 安全协议,使用URL-based 方式
录制
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2008-5-7 18:02:25 | 只看该作者
不错
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2008-5-7 18:08:36 | 只看该作者
正在学LR,关注一下
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2008-5-7 22:15:14 | 只看该作者
使用AJAX技术较多的系统最好使用URL方式
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2008-5-8 10:58:19 | 只看该作者
原帖由 shenzhen2008 于 2008-5-7 17:52 发表
HTML-based Script,说明脚本中采用HTML 页面的形式来表示这种方式的Script 脚本容易维护,容易理解;
       URL-based Script,说明脚本中的表示采用基于URL 的方式,WAS 和ACT
中的录制方式就是这种,这种方式看 ...



首先感谢你的答复。但是你说的那几条参考原则我网上很多地方都看到,我的问题是:

(1) 基于浏览器的应用程序推荐使用HTML-based Script。   为什么?如果采用另一种方式只是影响维护吗?对测试规划和测试结果有什么影响?
(2) 不是基于浏览器的应用程序推荐使用URL-based Script。  为什么?如果采用另一种方式只是影响维护吗?对测试规划和测试结果有什么影响?

(3)如果基于浏览器的应用程序中包含了JavaScript 并且该脚本向服务器产生了请求,比如DataGrid 的分页按钮等,也要使用URL-based 方式录制  为什么?如果采用另一种方式只是影响维护吗?对测试规划和测试结果有什么影响?

(4 )基于浏览器的应用程序中使用了HTTPS 安全协议,使用URL-based 方式录制   为什么?如果采用另一种方式只是影响维护吗?对测试规划和测试结果有什么影响?
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2008-5-8 10:59:08 | 只看该作者
还有关于sohu登录的那个问题,能一起讨论下吗?
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2008-5-8 11:46:06 | 只看该作者
据我理解html模式录制脚本,lr会把将页面发出的请求写在一个函数里,这样集成性较高,在代码阅读方面也比较容易,这种方式录制出来的脚本可以说是一种高级脚本
url方式录制的脚本是将页面所有的请求分别建立一个函数,这样的代码比较靠近底层,能更容易的监控到页面每个元素的情况
再举个例子HTML模式相当于编程语言中的VC,url模式相当于C或者汇编语言写的脚本
不知道这样理解对不对  希望大家指点
回复 支持 反对

使用道具 举报

该用户从未签到

10#
 楼主| 发表于 2008-5-8 15:03:46 | 只看该作者
原帖由 huruihai 于 2008-5-8 11:46 发表
据我理解html模式录制脚本,lr会把将页面发出的请求写在一个函数里,这样集成性较高,在代码阅读方面也比较容易,这种方式录制出来的脚本可以说是一种高级脚本
url方式录制的脚本是将页面所有的请求分别建立一个函数 ...



你说的很对。我也是这么理解的。

但是我关心的是为什么在那些场合要选择那些方式?我觉得两者只是表现方式不一样,但是对后期的处理(如场景设计和结果分析)有什么影响呢?
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2008-5-8 15:41:17 | 只看该作者
我认为
1. 如果是基于浏览器操作的应用,用url-based和html-based效果一样
但是刚才查了一下For normal browser recordings, it is not recommended to use the URL-based mode since is more prone to correlation related issues. If, however, you are recording pages such as applets and non-browser applications, this mode is ideal.
意思是如果是普通的html,还是不建议用html-base方法,后面的原因(since is more prone to correlation related issues.)我也没太看明白.. 哪位看明白了说说~~
2. 如果不是基于浏览器的,用html方法可能录制不出来,或者说录制不出所有的交互。那样的话,当然需要用url-based方法。

[ 本帖最后由 hmilyjch 于 2008-5-8 16:12 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

12#
 楼主| 发表于 2008-5-8 16:43:47 | 只看该作者
since is more prone to correlation related issues

可以这么翻译吧: “因为更加容易产生关联性相关的问题”



谢谢。能否说下你从哪里看到这些的,是帮助文档吗? 给个全文或者链接都行。

[ 本帖最后由 KingRight 于 2008-5-8 16:45 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2008-5-8 16:45:07 | 只看该作者
会是什么样的问题呢?~
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2008-5-8 17:09:20 | 只看该作者
是lr的帮助文档
打开lr在help里面
然后在索引里面找HTML-based mode就行
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2008-12-17 17:36:47 | 只看该作者
原帖由 hmilyjch 于 2008-5-8 15:41 发表
我认为
1. 如果是基于浏览器操作的应用,用url-based和html-based效果一样
但是刚才查了一下For normal browser recordings, it is not recommended to use the URL-based mode since is more prone to correlatio ...
意思是如果是普通的html,还是不建议用html-base方法


这里应该是不建议用url-based模式
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2009-9-7 16:39:15 | 只看该作者
我觉得这里的建议也是不采用URL-based方式,采用URL-based方式时,对于一个页面可能需要关联多次,而采用HTML方式则不存在这个问题
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-9-28 00:59 , Processed in 0.095233 second(s), 28 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表