GO ON。。。


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

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

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

你突然跑向厕所，这叫捕获异常。
你在厕所吐了，反而觉得状态不错，这叫清空内存。
你在台面上吐了，觉得很惭愧，这叫程序异常。
你在boss面前吐了，觉得很害怕，这叫系统崩溃。
你吐到了boss身上，只能索性晕倒了，这叫硬件休克 。

继续：

菜过三巡，你就不跟他们客气了。
你向对面的人敬酒，这叫p2p.
你向对面的人敬酒，他回敬你，你又再敬他……，这叫tcp.
你向一桌人挨个敬酒，这叫令牌环。
你说只要是兄弟就干了这杯，这叫广播。
可是你的上司jj听了不高兴了，只有兄弟么，罚酒三杯。这叫炸弹。
可是你的下级mm听了不高兴了，我喝一口，你喝一杯，这叫恶意攻击。
有一个人过来向这桌敬酒，你说不行你先过了我这关，这叫防火墙。
你的小弟们过来敬你酒，这叫一对多。
你是boss，所有人过来敬你酒，这叫服务器。

再补充一个：

自己吹瓶 叫 单交易负载测试
被别人敬酒 叫 压力测试
喝了一个晚上 叫 稳定性压力测试
喝得脸不改色：还有上升空间，继续实施压力
喝到晕：资源已经接近瓶颈点
喝到吐：资源已经出现瓶颈
喝到不省人事:机器被压宕机
喝到隔屁:机器被压死机

我的LR是8.0。
在录制的过程中就同时生成脚本了，可以切换回脚本的窗口的。
8.1不知道是否还是同样，我的8.0是这样的。

@tester
能否更详细说一下，如何通过检查VUser来处理实际处理能力？

@cc
从你描述的情况看，我想很可能是JBOSS的连接数问题。
这里指的一个请求是指客户端和服务器的一次交互（或者连接）。
服务器的响应是处理完请求的响应。

呵呵，我的文章被四处copy了吗？
好早的时候写的了。
现在好象HP已经放弃对winrunner的支持了，全力发展QTP。。
以后没有必要对这二者再做比较了，嘿嘿。。。

thinktime是指在测试的过程中，每一步操作中间的思考时间（停顿）。
pacing是指在测试过程中，每两次迭代（或称循环）间的停顿。

取最大的访问量的80%（根据“二八原则”）。

@ppent

我没有用过你说的这个函数，所以不确定是不是可以在非http协议脚本使用，有机会可以在QQ或MSN上和我讨论一下。

滚！
这个是因为本身比较简单！
^_^

楼上的，“蒙事”是什么意思？

是啊，当时我也写了一点，但是不够详细，那天又遇到这个问题，看了自己以前写的，还是不懂，所以这次就写得更详细些。

@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的资料。

你没看清楚吧？
我是回到项目组，不是回厦门。
这次回来比上次更忙了，天天加班到晚上9点以后，周末也不例外。
恐怕暂时还是没有时间写文章了。

另：你的blog搬家了，可是没告诉我新地址啊，我怎么给你换啊？

@rickzhu

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

现在想想其实我这样的描述似乎并不是很合适，对于帮助里的这句话，仅仅从它字面上的意思就挺好理解了，没有必要区分这里的前者和后者，我这样描述反而可能对大家造成误导了，不好意思。^o^

呵呵，谢谢楼上两位的精彩评论，很高兴看到这个贴子至今还有人顶，不要客气，继续继续哈~^_^
最近忙于在外地出差，所以就不常来发贴了，不好意思！
我也来说说看法吧。
对于以上的第一个问题，我同意槛外人“如何确定是否要对一个功能进行性能测试，是根据其实现过程分析它给系统带来的性能消耗来决定的。”的说法。
至于第二个问题，Pacing设置的确是客户端的设置，通过控制虚拟用户发送的请求频率来对服务器端造成压力。Pacing究竟对服务器的性能结果是否有影响？以及如何影响的？在原文中已经说得很清楚，当发送的请求频率在服务器处理能力范围内（队列处于收敛和稳定状态）时，而当发送的请求达到一定的频率，超过了服务器处理的能力（队列处于发散状态）时，是会对测试结果产生影响的。

@槛外人

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

至于你的第二个问题，我不太理解你的意思，，虚拟用户数和完成的事务数并没有确实的对应关系，一个虚拟用户执行的脚本中可能包含多个事务（有时还会包括init和end事务），所以你说的“虚拟用户数/响应时间=每秒完成的事务数”，是没有什么根据的。

@ppent
我在上文中说的是每秒事务数图所表示的含义，LR在运行场景的过程中，会对每一个时间点采样一次，记录在这个时间点上所通过的事务数，将其绘制成分析图，这就是我们所看到的“每秒事务数图”，而我们通常所关注的TPS值，应该是由这些采样值所取的平均值，这样看来，事务响应时间和每秒事务数肯定不会是简单的倒数关系。

我本来就没有贴图啊。
我只是在说这几张图所表示的含义，这几张图的名称都比较容易看懂，用不着贴图了吧？

呵呵，不客气，一起学习，共同进步！^_^

二、关于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\...。要特别注意，以避免产生不必要的错误。

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％，也可以通过前期项目进行统计后，得到较为准确的百分数。

网友 大漠飞鹰：

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

实际操作中，我们比较方便控制客户端的并发数，而服务器端的则几乎无法控制和操作，因此我们平时说的并发数指的都是业务并发数。

以下是在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中好象是给不出来的，那么我们是否可以将其换算成点击率的指标，然后再去进行测试？我在之前做的那个系统就是类似于网站性质的，我对于网站的测试也没有什么经验，仅仅做过那一次，因此也想听听两位的意见。