我的评论

re: 喝酒与测试[未登录] xingcyx 2009-04-29 14:38  
GO ON。。。


酒是一样的,可是喝酒的人是不同的。
你越喝脸越红,这叫频繁分配释放资源。
你越喝脸越白,这叫资源不释放。
你已经醉了,却说我还能喝,叫做资源额度不足。
你明明能喝,却说我已经醉了,叫做资源保留。
你喝一段时间就上厕所,这叫cache。

酒过三巡,你也该活动活动了。
你一桌一桌的走,这叫轮巡。
你突然看到某一桌的漂亮mm,走了过去,这叫优先级。
你去了坐下来就不打算走了,这叫死循环。
你的老大举杯邀你过去,你只好过去,这叫激活事件。
你向一桌敬酒,他们说不行不行我们都喝白的,于是你也喝白的,这叫本地化。
你向boss敬酒,可是boss被围了起来,你只能站在外圈,这叫排队。
你终于到了内圈,小心翼翼的向前一步,这叫访问临界区。
你拍着boss的肩膀说哥们咱们喝一杯,这叫越界。
你不知喝了几圈了,只会说两个字,干了,这叫udp。
可是还有人拿着酒瓶跑过来说,刚才都没跟你喝,这叫丢包。

喝酒喝到最后的结果都一样

你突然跑向厕所,这叫捕获异常。
你在厕所吐了,反而觉得状态不错,这叫清空内存。
你在台面上吐了,觉得很惭愧,这叫程序异常。
你在boss面前吐了,觉得很害怕,这叫系统崩溃。
你吐到了boss身上,只能索性晕倒了,这叫硬件休克 。
re: 喝酒与测试[未登录] xingcyx 2009-04-29 14:37  
继续:

菜过三巡,你就不跟他们客气了。
你向对面的人敬酒,这叫p2p.
你向对面的人敬酒,他回敬你,你又再敬他……,这叫tcp.
你向一桌人挨个敬酒,这叫令牌环。
你说只要是兄弟就干了这杯,这叫广播。
可是你的上司jj听了不高兴了,只有兄弟么,罚酒三杯。这叫炸弹。
可是你的下级mm听了不高兴了,我喝一口,你喝一杯,这叫恶意攻击。
有一个人过来向这桌敬酒,你说不行你先过了我这关,这叫防火墙。
你的小弟们过来敬你酒,这叫一对多。
你是boss,所有人过来敬你酒,这叫服务器。
re: 喝酒与测试[未登录] xingcyx 2009-04-02 16:55  
再补充一个:

自己吹瓶 叫 单交易负载测试
被别人敬酒 叫 压力测试
喝了一个晚上 叫 稳定性压力测试
喝得脸不改色:还有上升空间,继续实施压力
喝到晕:资源已经接近瓶颈点
喝到吐:资源已经出现瓶颈
喝到不省人事:机器被压宕机
喝到隔屁:机器被压死机
我的LR是8.0。
在录制的过程中就同时生成脚本了,可以切换回脚本的窗口的。
8.1不知道是否还是同样,我的8.0是这样的。
@tester
能否更详细说一下,如何通过检查VUser来处理实际处理能力?
@cc
从你描述的情况看,我想很可能是JBOSS的连接数问题。
这里指的一个请求是指客户端和服务器的一次交互(或者连接)。
服务器的响应是处理完请求的响应。
呵呵,我的文章被四处copy了吗?
好早的时候写的了。
现在好象HP已经放弃对winrunner的支持了,全力发展QTP。。
以后没有必要对这二者再做比较了,嘿嘿。。。
thinktime是指在测试的过程中,每一步操作中间的思考时间(停顿)。
pacing是指在测试过程中,每两次迭代(或称循环)间的停顿。
取最大的访问量的80%(根据“二八原则”)。
@ppent

我没有用过你说的这个函数,所以不确定是不是可以在非http协议脚本使用,有机会可以在QQ或MSN上和我讨论一下。
滚!
这个是因为本身比较简单!
^_^
re: LoadRunner培训教材 xingcyx 2007-10-22 22:16  
楼上的,“蒙事”是什么意思?
re: LoadRunner中的一个关联技巧 xingcyx 2007-10-22 17:17  
是啊,当时我也写了一点,但是不够详细,那天又遇到这个问题,看了自己以前写的,还是不懂,所以这次就写得更详细些。
@mxlly

我这篇文章没有提高QTP,贬低Winrunner的意思。
这二者应该是各有优缺点,只要能熟练掌握其中的一种,是可以较好地实现自动化测试的。而且,这二者都是同一家公司的产品,在很多地方是相通的,并不互相排斥。
@water_jie
你可能没有理解我说的。
我的意思是,设置多个组,第一个组为初始用户数,如100,第二个组以50或100递增,直至达到所需的200用户,300用户等,并不是说第一个组100,第二个组200,第三个组300……
对的。
不过我建议你找一个实际的测试结果,自己看看,会理解得更清楚些。
哦,不好意思,我上面说得不太准确。
其实我的意思是,响应时间长了,也就意味着TPS低。
不是说响应时间长会影响TPS,而是说响应时间长了会导致TPS低。
也就是你要衡量的这个事务性能有问题,详细的要再跟踪。
晕,这个问题比较汗。。。
当然会影响啊,你自己都知道TPS是事务数/时间,那么时间越大,当然TPS就越小啦。
怎么一下子提这么多问题。
一个一个来吧:
1、是的。但是TPS值这么小,你要检查一下具体的原因。如,是不是把thinktime算进去了?你的事务定义得是否有问题?等等。
2、每秒事务数可以是每秒交易数,这要看你的事务和交易分别是怎么定义的。
3、平均TPS值是这样算的没有错。
是的。Transactions per Second就是每秒事务数,也就是我们通常说的TPS
再次针对以上问题进行试验,我在lrt_strcpy(sendBuf1, sendBuf);语句的前后各加了一句调试信息:lr_output_message("sendBuf:%s",sendBuf);
和lr_output_message("sendBuf1:%s",sendBuf1);
打印出来的结果截然不同,前者的输出显示没有传入参数值,而后者则成功传入参数。这表明确实是lrt_strcpy这个函数在搞鬼。
至此,这个问题可以圆满结束了!感谢Zee同学的热情解答!^_^
昨天和Zee讨论了一个下午,结论还是没有明确。今天上午继续试验,试验结果表明Zee说的是正确的,不能直接将C语言里的变量直接当作LR变量使用,而需要做一些转换。事实上,执行strcpy(a,"{a}");后,并没有真正将参数值传给a。需要这样写:strcpy(a,lr_eval_string("{a}"));这样就没问题了。

不过,问题还没有结束,在tuxedo协议中,用 lrt_strcpy函数则没有这个问题存在,例如:lrt_strcpy(sendBuf1, sendBuf);则可以成功地将sendBuf中的参数值赋值给sendBuf1。目前怀疑是该函数在内部已经进行过转换,但并不肯定,尚待证实。
@rickyzhu
呵呵,你太客气了!
我从你的文章里知道你现在正在oracle任职吧?这些东西你应该比我清楚才对啊,以后多指教!
首先要安装oracle客户端,完成相关配置,再添加oracle计数器就可以了。
至于要监控哪些参数,完全看你的需要,这个需要参考下oracle的资料。
re: 回到上海[未登录] xingcyx 2007-04-09 22:15  
你没看清楚吧?
我是回到项目组,不是回厦门。
这次回来比上次更忙了,天天加班到晚上9点以后,周末也不例外。
恐怕暂时还是没有时间写文章了。

另:你的blog搬家了,可是没告诉我新地址啊,我怎么给你换啊?
re: 看懂LoadRunner分析报表(一) xingcyx 2007-03-30 22:01  
@rickzhu

呵呵,我写这个已经有一段时间了,现在自己再看我写的这几句话,也挺费解,已经想不起来为什么当时会这么写了。

现在想想其实我这样的描述似乎并不是很合适,对于帮助里的这句话,仅仅从它字面上的意思就挺好理解了,没有必要区分这里的前者和后者,我这样描述反而可能对大家造成误导了,不好意思。^o^
呵呵,谢谢楼上两位的精彩评论,很高兴看到这个贴子至今还有人顶,不要客气,继续继续哈~^_^
最近忙于在外地出差,所以就不常来发贴了,不好意思!
我也来说说看法吧。
对于以上的第一个问题,我同意槛外人“如何确定是否要对一个功能进行性能测试,是根据其实现过程分析它给系统带来的性能消耗来决定的。”的说法。
至于第二个问题,Pacing设置的确是客户端的设置,通过控制虚拟用户发送的请求频率来对服务器端造成压力。Pacing究竟对服务器的性能结果是否有影响?以及如何影响的?在原文中已经说得很清楚,当发送的请求频率在服务器处理能力范围内(队列处于收敛和稳定状态)时,而当发送的请求达到一定的频率,超过了服务器处理的能力(队列处于发散状态)时,是会对测试结果产生影响的。
@槛外人

关于你说的第一个问题,按照帮助文件中的说法,可能我在上文中表述的意思有些模糊,其实我的理解是这样的:在场景运行的整个过程中,LR都会对每一个时间点采样一次,取在这个时间点上通过的事务数,然后画一个分析图。而你说的“总的事务数/场景运行时间=每秒事务数。 ”我不清楚你说的这个“每秒事务数”是从哪里得到的,如果是TPS图下方的平均值,我认为这个值应该是这些采样值的平均,而不是这样得到的。当然也有可能是我理解的错误,欢迎继续讨论,希望我们最终能得到一个正确的结论。

至于你的第二个问题,我不太理解你的意思,,虚拟用户数和完成的事务数并没有确实的对应关系,一个虚拟用户执行的脚本中可能包含多个事务(有时还会包括init和end事务),所以你说的“虚拟用户数/响应时间=每秒完成的事务数”,是没有什么根据的。
re: 看懂LoadRunner分析报表(一) xingcyx 2007-03-07 14:22  
@ppent
我在上文中说的是每秒事务数图所表示的含义,LR在运行场景的过程中,会对每一个时间点采样一次,记录在这个时间点上所通过的事务数,将其绘制成分析图,这就是我们所看到的“每秒事务数图”,而我们通常所关注的TPS值,应该是由这些采样值所取的平均值,这样看来,事务响应时间和每秒事务数肯定不会是简单的倒数关系。
我本来就没有贴图啊。
我只是在说这几张图所表示的含义,这几张图的名称都比较容易看懂,用不着贴图了吧?
呵呵,不客气,一起学习,共同进步!^_^
re: LoadRunner测试结果分析[未登录] xingcyx 2007-02-08 15:59  
二、关于TPS(Transactions per Second):
每秒处理事务数。这个值可以说明系统在特定的负载情况下,每秒可以处理多少个客户端请求,这是一个衡量服务器端性能的重要指标,相信各位在进行性能测试的时候经常会用到这个指标。但是一直以来我都有一个疑问,到底这个值是怎么算出来的。既然是每秒事务数,那算法自然是“事务数/时间”。事务数很好理解,执行了多少就是多少,关键是这个时间。是整个场景执行的时间,还是仅仅是在服务器端执行的时间?因为我们知道,这两个时间肯定是有区别的,前者还包括thinktime的时间、pacing的时间以及在网络上耗费的时间等等。
为了弄明白这个问题,我今天特地查了一下帮助文档,看到上面是这么说的:“每秒事务数图显示在场景或会话步骤运行的每一秒中,每个事务通过、失败以及停止的次数。”如果按照这句话去理解,那么上面那个问题的答案应该是后者,也就是说,在Transaactions per Second这张图中,LoadRunner是针对场景运行过程中的每一个时间点取样一次,显示在这个时间点上每个事务的通过、失败以及停止的个数。
另外,我还在Analysis里面找了一下,发现图表的时间显示粒度也是可以设置的。具体方法为:在图表上点击右键->选择“Set Granularity”或者直接按Ctrl+G。我试着把时间粒度调成以毫秒为单位,结果LoadRunner提示当前不支持以毫秒为显示粒度,由此我推断LoadRunner对于Transactions per Second这张图,最小的取样粒度为1秒。
以上分析如果有不对的地方,希望各位提出批评。
不好意思,最近这几天比较忙,没有时间来回复。
@槛外人
我个人的看法,如果按照你所说的,场景是基于目标的,那么Pacing的设置确实没有太多关系,不过在我的实际工作中,通过并发用户去设置场景的情况还是比较多,所以Pacing的设置还是会对测试结果产生一些影响的。
谢谢你的回复,欢迎继续探讨!
* 在Analysis中,可以很方便地将各个分析图表拷贝出来。方法是:先切换到某个图表页(Graph),再使用EditCopy to Clipboard功能,便可将该图表的图、数据等复制到剪贴板,然后就可以粘贴到需要的地方(如测试报告)去。
* 将参数设置为Unique时,要特别注意提供的参数列表是否足够,在Controller中分配值的选项(Allocate Vuser values in the Controller)默认设置为自动分配数据块(Automatically allocate block size),这样的设置在场景的执行过程中往往会出问题,报出“参数不够”的错误,可以修改为由人工分配(Allocate__values for each Vuser),为每个虚拟用户分配指定数目的参数,以便于控制。
* LR在录制脚本时有时常会出现一些乱七八糟的字符,例如:
"Name=save_path", "Value=D:"
"\\x5C"
"resin-2.1.12"
"\\x5C"
"doc"
以上脚本片断中用红色标出的“x5C”部分就是录制下来的乱字符,该脚本原本是为了将附件上传到服务器端保存,可录制下来的保存路径却多了以上的乱字符,导致本应的保存路径D:\resin-2.1.12\doc\...,变为D:\x5Cresin-2.1.12\x5Cdoc\...。要特别注意,以避免产生不必要的错误。
re: 性能测试常见问题解答 xingcyx 2007-01-25 22:36  
Q:性能测试有哪些测试类型?有何异同?
A:性能测试是一个涵义很广的概念,它包括负载测试、压力测试、强度测试、可伸缩性/扩展性测试等。
1.负载测试:通过逐步增加系统负载,最终确定在满足性能指标的情况下,系统能承受的最大负载量的测试。 2.压力测试:通过逐步增加系统负载,最终确定在什么负载条件下系统性能将处于崩溃状态,以此获得系统能提供的最大服务级别的测试。 3.强度测试:又称疲劳强度测试,在系统稳定运行的情况下能够支持的最大并发用户数,持续执行一段时间业务,通过综合分析,确定系统处理最大工作量强度性能的过程。4.可伸缩性(Scalability)是衡量一个系统处理能力或容量的属性,举个例子说,就是当为一个系统增加了资源——特别是硬件资源后,系统可以承受更大的负载,并获得更大的 吞吐量,这个系统可以被称为 Scalable System (可伸缩的系统)。例如测试一个使用了负载均衡和集群技术的系统,测试当增加新的 Cluster 之后是否可以承受更大的负载,并获得相应的吞吐量提升。


Q:“并发用户数”在英文中是如何表示的?
A:并发用户数量:the number of concurrent users
最佳并发用户数量:the optimum number of concurrent users
最大并发用户数量:the maximum number of concurrent users
峰值并发用户数量:the peak number of concurrent users
平均并发用户数量:the average number of concurrent users

Q:“注册用户数”和“最大并发用户数”有联系吗?
A: 注册用户数和最大并发用户数之间本身没有必然联系。一般根据特定时间段的峰值来进行计算。如注册用户数为2000,按照行业标准一般峰值使用人数为5%-10%,也可以通过前期项目进行统计后,得到较为准确的百分数。
网友 大漠飞鹰:

并发中有两个概念,一个是业务并发数,指的是客户端的访问用户量;
还有一个是服务器端的并发数,指的是服务器端的处理数量;

实际操作中,我们比较方便控制客户端的并发数,而服务器端的则几乎无法控制和操作,因此我们平时说的并发数指的都是业务并发数。
re: 性能测试问答[未登录] xingcyx 2007-01-22 22:49  
以下是在51testing论坛上的讨论贴:

Zee:
关于集合点,我一直觉得没有什么可争议的,这两天看到几个帖子在说这个东西。有一点我想大家都是认同的:集合是相对的集合。
集合是在产生负载的机器上的集合。如果考虑网络,中间件等等的因素。到服务器肯定不会是同一时间点,那于是就有人希望能更接近在服务器端实现并发的操作。认为这才是真正的并发。
我觉得首先要做的是分析应用系统,到底你想做的是什么。
比如说,你想让某个URL能达到1000个同时请求的目的。这样的目标就比较明确了。
而在讨论集合点的时候,大家很少拿具体的东西来举个例子。这样有点说不清楚。要想达到并发。我觉得应该更具体的分析应用。再来定下目标来做。而不是一直在讨论LR如何能实现。

xingcyx:
因为在实践中,我经常会碰到这样的情况:
测试需求说,该系统应支持200个并发用户。

那么我们就开始测,录制好脚本,下一步就是在场景中执行了,在控制台中设置某脚本并发用户数为200,测试结果为通过或未通过。此时争议就来了:这200个用户的脚本如果执行通过,测试结果可以接受,是否可以说这个系统支持了200个并发呢?

Zee:
你说的是不是太过泛泛?如果用户说这系统要支持200个并发。那做性能测试的人知道这句话有很大的出入。

大漠飞鹰:
测试前肯定要了解需求,或者说是测试目的。
就说明“该系统应支持200个并发用户。”, 这种需求严格意义上来说是不合格的需求,因为描述不够清晰,过于模糊等。
当然,在实际中,这类需求到了我们测试人的手里也是常有的,一般就当普遍的情况来出来。
比如,web系统,就按2/5/8,或者2/5/10来处理,如果能通过就pass,否则就让开发人员调优。

xingcyx:
那么楼上的两位就请说说,你们实际的工作中,需求是怎么提出来的,或者你们是怎么去确定出来的,到了最后确定了的测试需求是个什么样子?给出来大家参考一下。

Zee:
从集合点到并发数的确定。我觉得这其中的转换最主要的地方在于分析业务。

比如用户说了:要求200个用户并发。
那要问清楚的就是,200个用户是个什么样的比例,有多少人在干这个,有多人在干那个,按百分比,用不同的脚本来跑。
那再来想一下客户。他关心的是200个用户在服务器上同时点同一个URL或者某一个相同的资源?这个客户我想大多不会关心。而他想要的就是我有200个用户在线的时候。响应时间不至于让人不可接受。至于多少才不可接受。按平常人的心理承受能力来衡量就可以了。再或者有其他的说法,就是200人同时点同一 URL或者请求同一资源,我想可以通过计算来增加vuser的数量或者集合呀,或者其他的方法来努力的向这个目标靠近。

如果说非要在服务器上这个时间并发这么多的用户。我觉得只能尽量把它缩小到一个时间段内。而这样做我觉得并不是从分析业务出发的

xingcyx:
楼上说的是最常见的一种情况,在这种测试需求下,我会设置一个混合场景来测试,也就是按照做不同事情的用户的百分比去设置。
但会有另外一些时候,并不是一个实际的应用系统,可能是一个开发平台,或者工作引擎等,它涉及的性能的概念会更偏向底层一些,这个时候可能就不是像一般的应用系统那样,设置一个混合场景来测试那么简单了。

大漠飞鹰:
一般说的并发数指的是业务并发,而不是服务器端得并发数。

cc_lion:
一个业务并发,一个服务端最大并发数,针对测试目标不一样选择其中

测最大并发数可能有意外收获哦!!资源争用,DEADLOCK,等
6. 设置Internet首选项的其它选项
几个比较常用的:
由资源引起的步骤超时是警告(Step timeout caused by resources is a warning):如果由于资源未在超时间隔内加载而引起超时,将发出警告而不是错误。对于非资源,VuGen 总是发出错误。(默认情况下为 NO)
HTTP 请求连接超时(秒)(HTTP-request connect timeout(sec)):Vuser 终止之前在步骤内等待特定 HTTP 请求连接的时间(秒)。超时为服务器保持稳定并响应用户提供了机会。默认值为 120 秒。
HTTP 请求接收超时(秒)(HTTP-request receive timeout(sec)):Vuser 终止之前在步骤内等待接收特定 HTTP 请求的响应时间(秒)。超时为服务器保持稳定并响应用户提供了机会。默认值为 120 秒。
超时设置主要用于以下高级用户:这些用户已确定可接受的超时值应该随环境而异。大多数情况下,默认设置应该足够长。如果服务器在合理的时间内并未做出响应,请检查其他与连接相关的问题,不要设置太长的超时,否则可能会导致脚本不必要地等待。
网络缓冲区大小(Network buffer size):设置用于接收 HTTP 响应的缓冲区的最大大小。如果该数据的大小超过了指定的大小,则服务器将按块发送数据,从而增加了系统开销。从 Controller 中运行多个 Vuser 时,每个 Vuser 都使用自己的网络缓冲区。该设置主要用于以下高级用户:这些用户已确定网路缓冲区的大小可能影响其脚本的性能。默认值为 12K 字节。
* 在启动录制脚本操作的Start Recording对话框,去掉Record the application startup前的选择,可以不录制应用程序启动时的操作,而仅录制所需的特定操作。

* 添加windows性能计数器时,必须先用管理员身份登录该台服务器,然后添加才可生效(注意先后顺序)。

* 设置DB2数据库监视:在Monitored Server Machines中配置Machine Information机器信息,Name中要填写“主机名@实例名”,如“168.31.6.47@DB2”,其中实例名要填完整,包括节点名称。Platform选“N/A”。

* 添加windows性能计数器时,必须先用管理员身份登录该台服务器,然后添加才可生效(注意先后顺序)。

* web_reg_save_param是在web脚本中用于关联HTML语句的函数。只有在录制中的关联有效时(在录制选项中设置),web_reg_save_param才会被自动录制。
以下是我的回复,想法不一定正确,希望抛砖引玉:

我看完邮件的描述,发现这正好和我前不久做过的一个系统比较像,但我不敢保证我的做法就是对的,只能把他提出的问题,结合我的实际经验,提出来和大家讨论一下。
1、关于在线用户数和并发用户数的之间的换算关系,其实很难有一个确定的说法,这个问题我一直在考虑,也很希望能够有一个更好的方法来实现这个换算,但10%是一个普遍为大家所接受的比例,我个人觉得没有什么问题。至于“背景用户”,我觉得也是需要的,因为对于这样的性能需求来说,很重要的一点就是要尽量地接近于真实的业务场景,只要你所模拟的是现实中的业务操作,那么测试出来的结果就是可信的。
2、对于第二个问题,我没大看明白他的意思,如果他的场景是混合场景,那无疑应该是按照模型中的比例去设置虚拟用户,但我猜测他之所以会提出这个问题,可能是想对单个业务交易去做测试,不知道我猜的对不对。
3、所谓突发性的大并发加压策略,模拟的是一种业务处于高峰期时的,以及一些突发的、意外的情况,要看各个系统的具体业务情况来定,如果业务上存在这样一种高峰时段(比如到了月底,会有大量的报表生成、导出等工作),我个人认为还是非常有必要考虑的,尤其是要关注一下当这样的压力过去后,系统是否可以恢复正常。

另外这边我也提几个问题:
1、“网站的每日访问量10万人次”,不知应如何去实现测试?
2、所谓的“页面访问量”是LR中好象是给不出来的,那么我们是否可以将其换算成点击率的指标,然后再去进行测试?我在之前做的那个系统就是类似于网站性质的,我对于网站的测试也没有什么经验,仅仅做过那一次,因此也想听听两位的意见。