51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3181|回复: 4
打印 上一主题 下一主题

[原创] LoadRunner协议选择

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-6-1 11:21:07 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
 正确选择协议,就要熟悉被测试应用的技术架构。以下列出一些LoadRounner支持的协议:
  一般应用:C Vuser、VB Vuser、VB scrīpt Vuser、JAVA Vuser、Javascrīpt Vuser
  电子商务:WEB(Http/Html)、FTP、LDAP、Palm、Web/WinsocketDual Protocol
  客户端/服务器:MS SQL Server、ODBC、Oracle、DB2、Sybase CTlib、Sybase DBlib、Domain Name Resolution(DNS)、Windows Socket
  分布式组件:COM/DCOM、Corba-Java、Rmi_Java
  EJB:EJB、Rmi_Java
  ERP/CRP: Oracle NCA、SAP-Web、SAPGUI、SAPGUI/SAP-Web Dual Protocol、PropleSoft_Tuxedo、Siebel Web、Siebel-DB2 CLI、Sieble-MSSQL、Sieble Oracle
  遗留系统:Terminal Emulation (RTE)
  Mail 服务:Internet Messaging(IMAP)、MS Exchange(MAPI)、POP3、SMTP
  中间件:Jacada、Tuxedo 6、Tuxedo 7
  无线系统:i-mode、voiceXML、WAP
  应用部署软件:Citrix_ICA流:Media Plays(MMS)、Real
  一段对于loadrunner协议选择的经典解答协议是数据在网络中传输的结构模式。协议不同,其数据报文的结构也有所不同。协议是有层次的,一般我们从ip层开始,往上有TCP协议层,UDP协议层,而TCP和UDP协议层上又有http协议层,ftp协议层,smtp协议层等我们在lr中看到的这些应用层的协议。其实这些高层协议都是对底层协议进行的进一步封装。举个简单例子,本来IP协议的数据报文是无序,不是可靠传输的,在其数据报文外面增加了报文序号,报文状态等数据段就构成了TCP协议层。所以我们很多网络应用,没有找到合适的协议,就用winsock来录制,那是肯定没有问题的。因为几乎所有的网络传输中都是基于tcp 协议或udp协议的,而socket正是这一级上的概念。但是由于socket协议级别太低,你录下来的东西是很难理解的,都是 socket,port,data之类的东西。所以,我们尽量用高层协议来录制,我们就能看懂了。
  话要再说回来,解决一下具体的问题。我们看到一个软件体系架构,应该怎样选择录制协议呢?说到这里,我要说一下自己对lr录制机理的理解(我没有接触过lr内核,只是凭猜测和推断)。在录制时,lr应该会对你从本机发出去的数据进行截包,并拆包。因为我们知道协议的不同就是体现在数据包的结构不同,lr应该通过对包结构的分析,判断是不是它支持的协议,对包数据的分析,来获取用户发送的东西。比如你用ftp的协议去录制一个访问网页的IE操作,那肯定是无所收获的。因为lr没有在网络截获到 ftp协议格式的包,都是http协议格式的包,它不认,当然就是一个录制为空的结果了。现在我们弄懂了这个事情,就知道该如何选择协议了。看见很多人关心lr是不是支持mysql协议。我认为要寻找的答案的思路是这样的:
  1、首先弄清mysql协议和其他数据库协议的关系,看能不能用其它数据库协议录制。但其实oracle的cs协议是oracle独有自己开发的协议,sqlserver也是一样,而mysql又与这几大产品又不是隶属关系,其脚本录制的可能性很小。
  2、mysql协议的底层是基于什么协议的,如果直接构建在tcp协议上,lr又不支持mysql协议,那只能考虑用低一点的协议录录看,即socket。如果mysql协议是构建在odbc协议上的,那么就可能用lr的odbc api来写。
  很多时候一提到不是基于浏览器的应用,很多人就会想到用WinSocket协议来录制,仿佛Form窗体都可以用Winsocket 。从道理上讲网络通讯的底层都是基于Socket的,例如TCP、UPD等,似乎所有的程序都可以用Socket协议来录制。但是事实不是这样的,因为选择的协议决定了LoadRunner如何捕获数据包。否则会多捕获很多无用的数据。因此,不是所有的程序都是适合WinSocket协议的。实际上,那些基于Socket开发的应用才真正适合Socket协议来进行录制。其他的,例如基于数据库的应用,就不太时候Socket协议,甚至可能录制不到脚本。很多C/S程序,一定要选择合适的协议。根据作者的经验,C/S的程序多数需要手工开发很多脚本,因为录制的很多回放时候或多或少都会有些问题,但是可以参考录制的结果。所以测试一个程序,一定要搞清楚开发人员用了什么技术、数据流是什么协议封装的。理论上来说我们在对一个系统做性能测试以前,要先和开发人员了解一下他们在开发过程中都用了些什么技术,数据流是用什么协议封装的,还要了解我们要测试的系统的网络结构,服务器的配置等问题;还有就是要知道系统客户端和第一服务器间的协议,这中间就涉及到一个中间件的问题。另外我们要知道协议的选择直接关系到LR会捕获到什么样的数据包。这些是进行性能测试的基础。 下面说几个测试的原则(都是自己遇到过的,呵呵,没遇到过的就不知道了):
  1、一般情况下b/s构架的只要 选择WEB(Http/Html)协议就可以了,如果有中间件的则选择中间件服务器的协议 ;
  2、C/S结构,可以根据后端数据库的类型来选择。如SybaseCTLib协议用于测试后台的数据库为Sybase的应用;MS SQL Server协议用与测试后台数据库为 SQL Server的应用;
  3、一般不是基于浏览器的,对于一些没有数据库的Windows应用,我们在测试的过程中都会选择WinSocket协议来录制,理论上来讲我们这样选择是正确的,但我们要知道在录制的时候所选择的协议就决定了LR如何捕获数据包,如果我们选择错误了,将会捕获到一些无用的数据包。cs结构是比较复杂的,在这里我要提醒大家,一定要搞清楚cs是client-database还是client-server-database结构的,只有这样我们才能够决定是选择WinSocket协议还是sql协议,或者说选择多个协议;当然协议的选择也是一个探索的过程,只要能够得到我们想要的结果,那就是正确的。还有一点,我们在做性能测试的时候应该是有测试重点的,呵呵。
  4、关于单协议和双协议,我只知道IE6内核的浏览器在录制脚本的时候要选择单协议,而IE7内核的浏览器在录制脚本的时候要使用双协议。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-6-1 15:56:08 | 只看该作者
一句话,无论测什么架构的软件在选择协议前一定要熟悉该软件实现的原理,然后再去选择协议,另外LR只适合做客户端对服务器测试,而把LR当作服务器对客户端测试时,LR存在着严重的先天不足!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-6-8 17:20:01 | 只看该作者
嘎嘎嘎嘎嘎嘎
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2009-9-29 09:20:09 | 只看该作者
用.net写的前台程序,后台是sybase,协议如何选择呢? 选sybase?
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2009-11-13 16:07:19 | 只看该作者
能力有限理解错误之处希望大家指出,谢谢
这个中间件协议是不是Client-Database之间有软件对数据进行连接处理这些叫做中间件吧?
我记得网站和数据库之间的通讯可以通过网站调用dll来实现数据库的操作,这个DLL是不是可以认为是编程工具开发的中间件呢?

如果是这样的话  问题
.net写的前台程序,后台是sybase,协议如何选择呢? 选sybase?
如果是 CS模式的话, 应该选择 sybase  在这里楼上没有说存在中间件或者说不知道有没有 假如存在中间件的话那就应该选择中间件为主的多协议或单协议模式进行选择
如果是BS模式的话,选择SYBASE WEB模式就可以了 如果存在中间件的话以中间件的协议为主选择单协议或多协议看看生成的脚本那个正确采用哪种协议选择方式。
那就是说这个中间件所需的协议应该和开发人员沟通来确定中间件的实现原理来选择测试所需的协议

[ 本帖最后由 gnixougil 于 2009-11-13 16:17 编辑 ]
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-9 09:51 , Processed in 0.083982 second(s), 27 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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