利用LoadRunner测试一个应用的时候，需要验证域用户，所以即使录制成功，每次回放的时候都提示错误，用户名和密码不对，对此耿耿于怀了很久。今天居然解决了。解决方法就是一个简单的函数调用： web_set_user，此函数的解释和用法如下：
The web_set_user function is a Service function that specifies a login string and password for a Web server or proxy server. It can be called more than once if several proxy servers require authentication. web_set_user overrides the run-time proxy authentication settings for user name and password.
When you log onto a server that requires user and password validation, VuGen records a web_set_user statement containing the login details. However, there are some more stringent, authentication methods for which VuGen is unable to insert web_set_user statements. See User Authentication for more detail. In such cases, you can add web_set_user into your scrīpt manually.
When you run the scrīpt, LoadRunner automatically submits the user authorization along with every subsequent request to that server. At the end of the scrīpt, LoadRunner resets the authorization.
This function is supported for all Web Vusers, and for WAP Vusers running in HTTP mode only. It is not supported for WAP Vusers running in Wireless Session Protocol (WSP) replay mode.
Example 3
The following example was inserted manually by the user into the scrīpt as the Web server “mansfield” uses NTLM authentication. VuGen cannot record NTLM or Digest authentication. Note that for NTLM authentication the domain name “mansfield” followed by a double backslash must be prepended to the user name:
web_set_user(”mansfield\\freddy”, “XYZ”, “mansfield:80″);
原来一直没有想到域的设置，结果一直不行，现在可以了。
另外一个问题跟之前这个有关系，那就是验证码的问题，之前曾经看过段念（关河大侠）的关于验证码的是三个解决方案，这里是第四种解决方案。对于一些比较简单有规律的验证码可以搞定。对于复杂的比如有干扰的，或者没有规律的则参考关大侠的其他解决方案。
这个应用经过源代码分析，发现每次客户端请求过来的验证码都可以取到，格式如下固定，是四个数字的组合。经过多次尝试发现如下规律：
验证码如下： 52|52|52|51|46|47|49|55|
对应界面的验证码是： 6039
规律是第2，5，8，9位的值减去46对应的即是验证码。
有了这个规律，就可以通过关联提前取得服务器的验证码，然后通过简单的计算，得到结果。详细代码如下：

#include “web_api.h”
Action()
{
// char* str = “52|52|52|51|46|47|49|55|”;
char result[64];
int num1;
int num2;
int num3;
int num4;
int temp1;
int temp2;
int temp3;
int temp4;
web_set_user(”XXXXDomain\\szXXXX”,
lr_decrypt(”46246a2633f042c67758b9ddc2b863038aa063c03d7e”),
“XXXX.XXXX.com.cn:8080″);
web_reg_save_param(”check”, “LB=Image=”, “RB=\\”, LAST);
web_url(”Register”,
“URL=http://XXXX.XXXX.com.cn:8080/xx/main/Register”,
“Resource=0″,
“RecContentType=text/html”,
“Referer=”,
“Snapshot=t1.inf”,
“Mode=HTML”,
LAST);
lr_think_time( 6 );
sscanf(lr_eval_string(”{check}”), “%d|%d|%d|%d|%d|%d|%d|%d”, &temp1, &num1, &temp2, &temp3, &num2, &temp4, &num3, &num4);
num1 -= 46;
num2 -= 46;
num3 -= 46;
num4 -= 46;
sprintf(result, “%d%d%d%d”, num1, num2, num3, num4);
lr_log_message(”getvalue : %s”, result);
web_submit_form(”Register;jsessionid=6726009A7D21963602B166D91C883413″,
“Snapshot=t2.inf”,
ITEMDATA,
“Name=Register.reason”, “Value= “, ENDITEM,
“Name=set_attach”, “Value=result”, ENDITEM,
LAST);
return 0;
}
本文来源于天行健，君子以自强不息 http://www.rickyzhu.com , 原文地址： http://www.rickyzhu.com/173_case-three-of-loadrunner.html

可以利用LR的内置函数web_get_int_property判断HTTP服务器的返回状态, 如下是一个简单的例子:
#include "web_api.h"

Action()
{
int HttpRetCode;
web_url("my_home","URL=http://myhomeurl","TargetFrame=_TOP", LAST);
HttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE);

if (HttpRetCode == 200)
 lr_log_message("The scrīpt successfully accessed the My_home home page");
else
 lr_log_message("The scrīpt failed to access the My_home home page ");

 return 0;
}

看到xingcyx兄博客上一篇关于LoadRunner Pacing的设置文章,完全是根据他自己的经验写的,并且参考了Kirk的一些观点,后面引发了多位高手的激烈讨论,其实讨论本身比文章更有吸引力. 所以就转了过来. 原贴的位置: http://www.blogjava.net/xingcyx/archive/2006/12/28/90498.html
在 LoadRunner 的运行场景中，有一个不大起眼的设置，可能经常会被很多人忽略，它就是 Pacing 。具体设置方式为： Run-Time settings à General à Pacing ，这个设置的功能从字面上就很容易理解，即在场景的两次迭代 (iteration) 之间，加入一个时间间隔（步进）。设置方法也很简单，这里就不赘述了，我在这里想说明的是，这个设置到底有什么作用？为什么要进行这个设置？说实话，虽然我在以前做过的一些性能测试中，偶尔会对这个步进值进行一些设置，但其实对它的真正含义和作用，我还并不十分清楚。
前段时间，我在对X银行招聘信息系统进行性能测试的时候，发现这个值的设置对于测试的结果有着很大的影响，很遗憾当时没有深入研究这个问题，而只是简单地认为它同脚本中的 thinktime 一样只是为了更真实地模拟实际情况而已。最近在网络上看到一篇题为《调整压力测试工具》的文章，读完之后，再用之前我的测试经历加以印证，真有种豁然开朗的感觉。以下就将我的一些体会与大家分享：
通常我们在谈到一个软件的“性能”的时候，首先想到的就是“响应时间”和“并发用户数”这两个概念。我们看到的性能需求经常都是这样定义的：
“要求系统支持 100 个并发用户”
看到这样的性能需求，我们往往会不假思索地就在测试场景中设置 100 个用户，让它们同时执行某一个测试脚本，然后观察其操作的响应时间，我们都是这样做的，不是吗？我在实际实施性能测试的过程中，也往往都是这样做的。可惜的是，我们中的大多数人很少去更深入地思考一下其中的奥妙，包括我自己。
事实上，评价一个软件系统的性能，可以从两个不同的视角去看待：客户端视角和服务器视角（也有人把它叫做用户视角和系统视角），与此相对应的，又可以引出两个让初学者很容易混淆的两个概念：“并发用户数”和“每秒请求数”。“并发用户数”是从客户端视角去定义的，而“每秒请求数”则是从服务器视角去定义的。
因此，上面所描述的做法的局限性就是，它反映的仅仅是客户端的视角。
对于这个世界上的很多事情，变换不同的角度去看它，往往可以有助于我们得到更正确的结论。现在，我们就转换一下角度，以服务器的视角来看看性能需求应该怎么样定义：
“要求系统的事务处理能力达到 100 个 / 秒” ( 这里为了理解的方便，假定在测试脚本中的一个事务仅仅包含一次请求 )
面对以这样方式提出的性能需求，在 LoadRunner 中，我们又该如何去设置它的并发用户数呢？千万不要想当然地以为设置了 100 个并发用户数，它就会每秒向服务器提交 100 个请求，这是两个不同的概念，因为 LoadRunner 模 拟客户端向服务器发出请求，必须等待服务器对这个请求做出响应，并且客户端收到这个响应之后，才会重新发出新的请求，而服务器对请求的处理是需要一个时间 的。我们换个说法，对于每个虚拟用户来说，它对服务器发出请求的频率将依赖于服务器对这个请求的处理时间。而服务器对请求的处理时间是不可控的，如果我们 想要在测试过程中维持一个稳定的每秒请求数（ RPS ），只有一个方法，那就是通过增加并发用户数的数量来达到这个目的。这个方法看起来似乎没有什么问题，如果我们在测试场景中只执行一次迭代的话。然而有经验的朋友都会知道，实际情况并不是这样，我们通常会对场景设置一个持续运行时间（即多次迭代），通过多个事务 (transaction) 的取样平均值来保证测试结果的准确性。测试场景以迭代的方式进行，如果不设置步进值的话，那么对于每个虚拟用户来说，每一个发到服务器的请求得到响应之后，会马上发送下一次请求。同时，我们知道， LoadRunner 是以客户端的角度来定义“响应时间”的 ，当客户端请求发出去后， LoadRunner 就开始计算响应时间，一直到它收到服务器端的响应。这个时候问题就产生了：如果此时的服务器端的排队队列已满，服务器资源正处于忙碌的状态，那么该请求会驻留在服务器的线程中，换句话说，这个新产生的请求并不会对服务器端产生真正的负载， 但很遗憾的是，该请求的计时器已经启动了，因此我们很容易就可以预见到，这个请求的响应时间会变得很长，甚至可能长到使得该请求由于超时而失败。等到测试 结束后，我们查看一下结果，就会发现这样一个很不幸的现象：事务平均响应时间很长，最小响应时间与最大响应时间的差距很大，而这个时候的平均响应时间，其 实也就失去了它应有的意义。也就是说，由于客户端发送的请求太快而导致影响了实际的测量结果。
因此，为了解决这个问题，我们可以在每两个请求之间插入一个间隔时间，这将会降低单个用户启动请求的速度。间歇会减少请求在线程中驻留的时间，从而提供更符合现实的响应时间。这就是我在文章开头所提到的 Pacing 这个值的作用。
最后再补充一句话：虽然性能测试通常都是从客户端活动的角度定义的，但是它们应该以服务器为中心的视角来看待。请注意这句话，理解它很重要，只有真正理解了这句话，你才会明白为什么我们一直强调做性能测试的时候要保证一个独立、干净的测试环境，以及一个稳定的网络，因为我们希望评价的是软件系统真正的性能，所以必须排除其它一切因素对系统性能造成的影响。
花了几天的时间才完成这篇文章，如果它能够帮助大家对性能测试多一些理解或者多一些思考，那就是我的荣幸了。 ^_^
参考资料：
Kirk Pepperdine 《 Tuning your stress test harness 》
http://www.theserverside.com/tt/articles/article.tss?l=StressTest
 
 
下面就是回复了:
 
e: 谈谈LoadRunner中Pacing的设置 2006-12-28 23:15 | Jackei
其 实这篇文章最早是在 2006 年初看到的，过去几个月，发现对里面的内容已经有点遗忘了。所以看到你在我 blog 留言后，就又翻出来看了几遍。这次再看，发现有不少地方同 Kirk 的看法有分歧。本来想专门写篇文章来讨论一下，不过看到兄台已经打了个基础，不妨咱们就依照这个基础来讨论下去 ^_^
由于晚上时间也有限，所以我想今天我先说说我对 Tuning your stress test harness 这篇文章的一些不同看法，改天咱们可以继续讨论，搞个连载 ^_^
Kirk 在 Tuning your stress test harness 一文中提出的一个重要的观点就是“放慢速度，做得越多”。这其实是一种场景设计的思路，Kirk 提出这个的原因是他认为那些“不增加服务器负载的线程看起来会降低服务器的性能”，于是，Kirk 通过人为的方法来限制了 RPS（Request per Second）的值——这里我们要注意到的是，实际上 Kirk 是将 RPS 控制为小于 The Number of Concurrent Users 的值。以文中的例子来说，Kirk 是在 50 个并发用户的情况下，将 RPS 控制在了 9 个左右。这样的结果是什么？不知道你有没有注意到，在这篇文章中，Kirk 是以 RPS 作为指标衡量系统负载的，这种做法就算是所谓的“服务器视角”了吗？
我们知道对于一个给定的系统来说，在某个特定的环境和场景中，它的“最佳并发用户数(The Optimum Number of Concurrent Users)”是客观存在的——关于“最佳并发用户数”的概念可以参见我的《LoadRunner没有告诉你的之三——理发店模型》一文（http://www.cnblogs.com/jackei/archive/2006/11/20/565527.html ）。当并发用户数大于这个“最佳”时，就会出现排队的情况。如果这个并发量一直持续，那么随着时间的流逝，队列也会越来越长，而越往后的请求在队列中等待 的时间也越长，从性能测试工具中看到的响应时间也会越来越长。而这就是 Kirk 认为不合理的地方。但实际上是这样吗？当我们使用 LR 或者 JMeter 这类性能测试工具测试时，队列真的会越来越长吗？响应时间也会越来越长吗？
今天先写这么多，如果有了不同的看法，我们明天继续 ^_^
e: 谈谈LoadRunner中Pacing的设置 2006-12-29 10:06 | xingcyx[匿名]
谢谢Jackie的回复！
按照我的理解，Kirk所说的RPS，是以服务器为视角来看的每秒请求数，也就是每秒钟到达服务器端的请求，而不是从客户端发出请求的频率，我们 知道这二者是会有差别的，否则的话，我们也用不着一直强调说做性能测试的时候一定要排除网络等因素的影响。同时这也是我看这篇文章获得最大的一个收获，因 为他教我们用一个不同角度去看待问题。不过说实话，我也没有弄明白他把RPS设成9的原因，从他的描述和图中，我看不出这其中的对应关系。这个问题其实也 让我想了好久，但他所说的RPS代表服务器视角，这一点我还是比较认同的，不知道你的意见如何，欢迎继续讨论。
当我们使用LR等工具的时候，队列确实不会越来越长，这个问题Kirk在文中也提到过了，他想告诉我们的是，由于我们所使用的工具的限制，导致了 看似服务器在应付一种稳定状态的负载，其实却是个发散的队列（因为工具会在收到服务器响应后才会发出第二个请求），这也是他所指出的问题关键所在。但响应 时间的确会越来越长的，因为当客户端收到服务器请求以后，如果我们没有设置延时，那么客户端会立即发出下一个请求，同时启动计时器，而此时如果服务器的资 源已经满负荷，这个请求并不会进入排队队列，那么这个时间其实是多计算的，因此后面的这些请求的平均时间将越来越长，导致整个平均值不准确。
另外这里我再提一个没有在我上面的文章中提到的一个问题，就是这个以“服务器视角”提出的性能需求应该是什么样子的，以前从来没有考虑过这个问题。
e: 谈谈LoadRunner中Pacing的设置 2006-12-29 12:25 | wufeiwufei
我也看过这篇文章，但我当时就发现这篇文章其实并不是写给测试工程师看的，我认为kirk想象中的读者应该是那些性能优化工程师（虽然国内这两个职业常常放到一块，因为国内对性能优化所能做的事情最多的大概就是添加硬件呢）。为什么这么说呢？因为角度不一样。
1、测试工程师站在客户角度，对客户来说请求的响应时间就是请求的排队时间加上请求的处理时间再加上网络传输的时间。测试工程师需要做的是按照需求，设置 场景，然后验证排队时间加上处理时间加上传输时间是符合客户的忍耐标准的。在这个标准下，找到最优并发数，最大并发数。
2、而对性能优化工程师来说，他们的目标是系统，设计的系统有没有问题，只和系统的本身有关，而不应该考虑那些客观存在的条件，传输的时间太长是网络问题 和系统无关，传输时间不应该考虑进去，排队的时间是操作系统的问题，如果已经排除呢系统设置的线程池（例如数据库连接池）的问题，那么也不应该考虑进去。 性能优化工程师要考虑的是，系统处理那些连续的请求，处理时间是否有线性上升，大概在什么样的请求数量下已经不符合系统设计时候的处理时限要求。
最后再举两个例子：A客户需求上要求100个并发用户下，数据库查询响应时间不能大于5秒。B系统设计书上设计系统处理单个查询请求不能时间不能大于2 秒。对A的测试脚本很好写，对B的测试场景设计起来要相对复杂，因为你要找到那个持续点，也就是kirk指的收敛点，并设计出pacing值。
e: 谈谈LoadRunner中Pacing的设置 2006-12-29 12:53 | xingcyx[匿名]
同样谢谢wufeiwufei的回复！我的BLOG是新开张，留言的人还不多，没想到一出手的就全是行家！^_^
你说的不错，kirk这篇文章的确更适合给性能优化工程师看，我不知道国外对于性能测试工程师和性能优化工程师是否有明确的定义和分工，但至少在 国内，这二者的区别是不大的。到目前为止，我所接手过的性能测试工作，大部分也是同时承担这二者的角色的，因为客户或者项目经理，请你来做性能测试工作， 不仅仅是要你指出系统存在什么性能问题，并且往往还希望你能告诉他们如何去解决。而且我也是这样来要求自己的，作为性能测试工程师，我认为我们也只有能够 做到这一步，才更有成就感！:)
e: 谈谈LoadRunner中Pacing的设置 2006-12-29 20:39 | Jackei
嗯，我现在来扮演反方吧，指出 Kirk 在文中的一些前后矛盾的地方，也是我对他的思路存在质疑的地方。
Kirk 在文中提到：我们将看到服务器正在处理稳定的请求流，而处理请求的时间似乎越来越长（“只做力所能及的”的那一节）。后面有提到：不增加服务器负载的线程 看起来会降低服务器的性能。并且“因为线程一离开就进入系统，就造成了这样的情况：线程必须等待其他每个线程完成后才能被服务。在这种场景下，线程越多就 会造成队列和响应时间越长。”——（“三思而后行”那一节）
如果大家对性能测试工具的工作原理比较熟悉，那么不难发现 Kirk 的理解的确存在一些偏差。首先，当某个系统在一个给定的环境和场景中时，它的“最佳并发用户数”是客观存在的，也就是说系统的响应能力的限度是客观存在 的。当每秒的请求数量大于这个限度时，必然会导致某些请求需要排队。但是这个排队并不会像 Kirk 说的那样——线程越多就会造成队列和响应时间越长。
我们举个例子来看：
- 假如系统的最佳并发用户数是 10，那么当并发用户数为 20 时（假定是 R1-R20），如果系统依旧平稳的每秒完成 10 个请求的响应，那么我们可以看到。第一秒的时候，R1-R10 完成了响应，而 R11-R20 在排队。第二秒时，R11-R20 被响应，而 R1-R10 又重新进入队列等待处理；第三秒，R1-R10 被处理，R11-R20 在排队…… 周而复始下去。Kirk 的看法，说到根本上就是认为这个队列会越来越长，所以他要控制一下。但是就如上面我们所说的，当并发用户数大于最佳并发用户数后，出现排队是正常的。而 Kirk 的方法最终的结果是让工具模拟了 100 个用户，但是系统在任意时刻却只有 50 个负载。认为的将负载控制在最佳并发用户数的范围内有意义吗？
所谓的“放慢速度，做得更多”，那么什么时候做得最多？当并发用户数等于系统的最佳并发用户数时系统做得最多，因为这时系统的整体效率最高。
Kirk 在文章最后的部分的论述，说明他明白性能测试工具工作的原理，所谓的稳定的请求流，而处理请求的时间似乎越来越长的情况是不会出现的——恰恰相反的是，请 求流是稳定的，响应时间也是稳定的。而他用大用户量模拟小并发量的做法我更是不赞同。因为在我的观点看来，RPS 并不是很适合用来度量负载的大小，因为在实际的测试中，这个值只与系统的响应能力有关。理论上来说，RPS 其实是等于 TPS 的，而 TPS 是用来度量系统的响应能力的。
另外，Kirk 在文中的观点认为，响应时间的延长是因为队列造成的，“不增加服务器负载的线程看起来会降低服务器的性能”。但是事实上并不是这样的。因为那些线程并非“不增加服务器负载”，而响应时间的延长也不单单是因为后面的线程的响应时间中包含了排队时间。
个人观点：最佳并发用户数是衡量系统性能的一个很关键的指标，而 Kirk 在整篇文章中关注的其实是当并发用户数大于最佳并发用户数以后的情况。他通过人为的方法将系统的负载控制在最佳并发用户数上下。所以，我认为他提出的以 RPS 来衡量系统负载的方法并不是合适，因为真正应该关心的其实应该是系统在任意时刻的负载。
说实话，我现在觉得 Kirk 这篇文章的思路并不是很清晰，或许是因为他没有提供更多的背景信息吧。
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 10:05 | wufeiwufei
Jackei兄还是没有理解kirk的意思啊，kirk并不是一个测试工程师，他主要是从事java性能优化的，所以注定他必定是站在开发人员的角度去理解系统性能，直接的说他是为了发现程序中的性能问题而尽量避免因为硬件或是操作系统带来的影响。
我把你举的例子进一步假设：这是一个基于80端口的web项目（我们暂且叫做A程序），采用的windows nt操作系统，该操作系统对于80端口的连接限制为6个，A程序在运行过程中最多向cpu申请到4个线程。每个用户每次只发一个请求。
让我来按照我理解的kirk的思想分析你举的例子的：
1、让我们先来看看10个最佳并发用户数都在干些什么。按照单cpu来看，系统在一个时间片上只处理一个请求，也就是说只有1个用户被系统处理，那么其他 的9个在干什么呢？按照假设，3个请求已经申请到线程，在等待cpu处理。6个请求在操作系统端，已经建立了连接，等待分配线程。
2、当20个并发数产生时，他们又在干什么呢？还是只有一个请求在被cpu处理，还是只有3个请求申请到线程，在等待cpu处理，仍然只有6个请求在操作系统端，已经建立了连接，等待分配线程，但是我们发现却多了10个请求在等待进入80端口，还没有建立连接。
3、那么kirk作为java程序优化工程师，什么是他关心的呢？有两点是他最关心的。a、每个请求的A程序处理时限；b、A程序对资源的占用和释放，对 cpu线程申请是否合理。前一个很好理解，后一个我再做进一步解释，程序写的好坏，有很大一部分在于对资源的占用和释放，假设有个死循环在系统里，那么一 旦申请到资源（cpu时间片），它始终不释放，必然导致cpu占用率一直是100％。再假设如果按照cpu的处理能力，A程序其实可以申请到4个时间片进 行处理，但是实际上由于某个线程没有及时释放资源，或者对于一个需要长时间的请求没有sleep，导致只能申请到2个时间片，那就需要优化程序了。
通过上面的解释我们就可以发现其实只有4个请求的处理时间是kirk关心的。而其他的，那并不是程序优化应该关心的事情，你可以转交给系统工程师进行进一步的优化。
4、那么如何才能让这4个请求的处理时间更加准确了？很显然，由于loadrunner只能从发出请求就开始计算时间，因此如果前面的等待端口和等待分配 线程的时间越长，那么得到的数据就越不准确。最合理的是根本就不要等待端口，最好每个请求都能直接建立并得到线程，进入cpu处理队列，当然因为我们并不 知道cpu实际的队列长度，所以很难进行控制。
5、那么我们应该怎么作呢？首先我们找到最佳请求数，因为我们知道最佳请求数其实就是已经建立连接的6个请求加上分配到线程的3个请求，再加上1个正在处 理的请求。然后我们逐步减少最佳请求数，其实也就是减少建立连接等待分配线程的请求数，随着逐步的减少，等待分配线程的时间也就减少，最终当我们减少到4 个时，我们发现响应时间不再提高，我们也就找到了我们最关心的响应时间的最准确值。这个过程就是kirk说的从发散到平稳到收敛的过程。
6、我们还应该注意什么呢？因为我们无法把握cpu的处理时间，所以我们也不可能算好，第5个请求正好在第一个请求处理完成后发起，因此我们不可能准确的 找到这个值。所以我在上个回复中说了，我们只有尽可能的接近收敛点，反复设置pacing值，好达到第5个请求到达时间接近第一个请求的释放时间，或是第 6个请求到达时间不超过太多第一个请求释放时间。
7、什么是系统真正的性能，什么是程序A的最佳并发数？系统真正的性能并不等同于用户需求定义的性能，在kirk理解上，系统真正的性能是系统处理他应该 去处理的事所得到的性能。如果请求建立连接的数量越多，那么必然耗损cpu时间，从而降低去处理A程序的效率，因此kirk认为我们应该减少并发数量，去 测试真正的系统性能。而从这个角度理解，4个用户才是kirk认为的最佳并发数。
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 10:17 | wufeiwufei
@xingcyx
一个性能优化工程师所要积累的知识并不是看看书，编编程就能达到的，我觉得一个优秀的性能优化工程师大概要有3年的操作系统级编程经验，2年的web经验，3年的数据库经验，再加2年的测试经验。
而国内根本不具备这个条件，对测试的轻视，对技术的追逐，导致有几个资深的开发人员会进入这个行业，导致有几个项目能给你时间，成本去积累这些知识。这真是可悲啊。
所以我觉得，我们这批测试工程师只能更多的发现问题，更多的去揭示问题，让中国的软件行业快点意识到其实还有一片更大的天空。
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 13:33 | Jackei
想到一个问题：如果我们以单位时间 1 秒来衡量系统的处理能力，发现每秒可以响应的请求数量是 10，也就是说每秒“流出”的是 10，那么是否可以认为最佳的请求数 RPS 也是 10 ？
也就是说，我们知道通常一个请求并不是只用一个 CPU 时间片就可以处理完的，而且单个 CPU 时间片是很短的。那么我们对于最佳请求数的评估是否要有一个时间单位做为基准？例如 1 秒。那么如果以 1 秒做为基准，是否最佳请求数同我之前提到的最佳并发用户数是同一个概念？
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 14:00 | xingcyx[匿名]
还是那句话，这应该是同一个问题，从两个不同的方面去理解。
我看过你写的《LoadRunner没有告诉你的》，里面对于“最佳并发用户数”的解释，我是赞同的，但“最佳请求数”这个概念，我相信很少有性 能需求会这样去提的。所以我觉得还是像wufeiwufei所提到的那样，国内把测试工程师和性能优化工程师两个角色混在一起了，因此这二者之间的界限很 模糊，在我做过的性能测试工作中，很多都是混在一起的，而偏偏客户和测试者都没有意识到这一点。
因此我是这样来理解的：如果是以用户的角度去测试，那之前谈到的最佳并发用户数的概念是没有错的，而一旦是涉及到性能瓶颈的定位、调优等，那还 是需要从服务器的角度去测试。系统是否存在一个“最佳请求数”，并不是很重要，我们只需要保证在测试的过程中，能够使系统维持一个稳定的负载，保证测试结 果准确、可信，不会有偏差就够了，也就是kirk说的，让服务器的队列处于稳定的而不是发散的状态。
re: 谈谈LoadRunner中Pacing的设置 2006-12-30 14:48 | wufeiwufei
@Jackei
我觉得可以这么理解，但是最佳并不是非常合适，虽然从大的方面讲增加请求数会在一定程度上增加cpu的负载，因而导致rps在某个阶段是有个最大的值，但 实际上这和性能测试工程师理解的最佳有一定的差别的，性能测试工程师得到最佳并发用户数是更多的为了验证用户要求的性能目标或是为了以后的扩容有个量的了 解，而从测试中得到这个rps更多的是为了发现问题进行优化，而不是为了达到某个目标，从这个角度来讲，rps没有最佳。
我一直认为rps对我们现在来说没有太大的意义，为什么这么说呢？
这是由于现在的性能测试过程决定的。现在的测试过程一般是：根据业务需求，设置目标，进行性能测试，获得基础数据－>根据数据对比业务需求，分解 transcation，设置关注点－>再次测试 这样一个循环的过程。我们之所以认为有问题，是因为我们站在用户角度去进行测试，对于客户来说是不管是设备的问题还是软件的问题都是我们的问题，因此对于 我们来说并不需要按照kirk的方式去追求rps，因为在这个过程中，我们可以把等待连接和分配进程的时间看成一个常量，而这个常量在所有的 transcation中都是存在的。我们更多是去确定是那个trancation有问题，然后针对这个transcation进行优化。
而kirk是这样测试的（仅仅是我自己的看法），分别对软硬件进行性能测试－>软件寻找rps－>根据经验，判断是否合理－>然后进行优化。
看出这两个差别了吗？举个例子更好理解，项目A要求100个并发数下动态页面的响应时间不大于5秒，静态页面的响应时间不大于2秒。举出三种测试情况：
1、动态页面是6秒，静态页面是1秒。
2、动态页面是6秒，静态页面是3秒。
3、动态页面是4秒，静态页面是1秒。
只有在第二种情况下，我们才会去寻找是否是硬件的问题。而通常在这种情况下，其实我们已经要求更换硬件了。
而对kirk来说，三种情况并没什么区别，他一样要找到rps，然后根据技术标准来看是否需要对程序进行优化。
为什么会造成这种差别呢？我认为最重要的原因，国内没有积累，企业缺少规范，非常缺少性能优化工程师这类专业人才，只有用业务需求的标准来衡量，而没有真正的技术标准，没有技术标准，即使我们得到rps，你又如何分析出是否合理，是否需要优化呢？
以上只是我一家之言，而且我对操作系统层面的东西也不是很清楚，毕竟我只作过1年不到的开发。
很高兴能和你们一起交流。
我的联系方式:wufei@133sh.com
msn:wufeisuliang@hotmail.com
re: 谈谈LoadRunner中Pacing的设置 2007-01-08 18:03 | 关河
呵呵，好容易看完了这么长的文章和评论，感觉这是精彩绝伦，赞一个先：）
严重同意wufeiwufei的观点，Kirk提出的问题，其实关键点在于他是从 “代码优化” 的角度来考虑问题的，他要的结果是“没有任何疑义的完全由于代码执行消耗的时间”，而不应该包括“队列等待时间”。
但对测试工程师来说，我们的任务是准确地知道真正的用户在使用这个系统时的性能感受，也就是完全的用户视角的“响应时间”，那当然应该包括全部的时间范围在内，Kirk提出的方法并不适用——所谓目的不同。
另外， 提出一点我的个人意见，上文所提到的RPS（或是TPS），我认为可以作为一个衡量系统压力的主要指标，在我看来，并发用户数和TPS都是在进行性能压力测试，或是衡量响应时间的依据，只有说“在XX用户数下，在XXTPS水平下”，响应时间才是有意义的。
re: 谈谈LoadRunner中Pacing的设置 2007-01-09 09:36 | xingcyx[匿名]
连关河老师都来参与讨论了啊，呵呵！
Kirk确实是从“代码优化”的角度来考虑问题的。我不知道国外对于测试工程师和性能优化工程师这两个角色是否有严格的划分，但至少我自己在实际 工作中，是没有分的，很多时候我都要身兼这两个角色，所以我觉得学会从两个角度来看待性能，是很有必要的，这也是我看Kirk文章的收获。另外，在我所做 过的性能测试中，通常都会要求将后台服务器的一些无关进程、服务停掉，并且尽量使网络独立、或者保证带宽足够，这样的做法，本质上也是在确保使测试出来的 性能结果尽量接近“实际的代码执行时间”。不知道各位在实际的工作中是怎样做的，这个问题也希望大家踊跃讨论。
关于关河老师最后提到的将RPS（TPS）作为衡量系统压力的指标，我也非常认同。
re: 谈谈LoadRunner中Pacing的设置 2007-01-09 15:00 | wufeiwufei
@关河
“在XX用户数下，在XXTPS水平下”，响应时间才是有意义的。 ”
我觉得准确得应该说 在xx用户数下，响应时间是多少，并单独加上tps值，和响应时间作为并列的性能指标。tps提交给开发组，响应时间记录进性能测试报告中。
我有几点问题，想请教关老师，jackei，xingxing等各位前辈同仁
1、我们都知道现在的性能测试，几乎都是根据预定的系统目标来衡量，而对代码的执行效率几乎没有任何评估，在这种情况下tps这个值到底还有多大意义。
2、如果我们真的关注代码的执行效率，那么通过loadrunner等性能测试工具得出tps值既烦琐而且得出的数值对定位问题几乎无多大的帮助，而据我 所知行业中有针对java和.net的应用级的监控工具（例如：wily公司的introscope），从这个工具可以很轻松的观察到各个程序块的相对运 行时间，随着并发用户数增加的，处理时间，占用资源的情况。那么kirk这篇文章又有多大的作用呢？
re: 谈谈LoadRunner中Pacing的设置 2007-01-10 09:25 | xingcyx[匿名]
@wufeiwufei
说说我的想法。
问题1：以我的实际经验来看，tps这个值通常是客户方关注得比较多，这是他们衡量一个应用系统性能好坏的一个重要标准。而对于项目组（程序代码的直接开发者）的性能定位、调优则几乎没有什么帮助。换句话说，这个值更多的用于“性能评测”，而不是“性能调优”。
问题2：你提到的wily公司的introscope主要是帮助我们来定位应用系统的性能问题，而kirk这篇文章则启发了我们，根据不同的测试目的应该有不同的测试策略。如果你的性能测试是为了定位程序中的性能问题，就应当尽可能地排除其它因素的干扰。
另：introscope这个工具我曾经看过wily公司的演示，感觉还可以，但我自己试用的时候却没配置成功。不知道你有是否对它有研究？
re: 谈谈LoadRunner中Pacing的设置 2007-01-10 09:41 | wufeiwufei
@xingcyx[匿名]
不好意思，写错了，不是tps，我的意思是rps，你可能没有明白我的意思，我是说我们现在的测试立足点基本就是站在客户方，而调优仅仅是在达不到客户方 要求的情况下才进行的，因此我觉得过分追捧kirk的理论对我们现实的测试工作没有任何帮助，因为即使我们利用这个理论去找到最接近系统处理能力的 rps，但是实际上也无助于我们进行性能调优（因为我们几乎无法对这个值进行评测）。
至于introscope的设置不好搞，我个人认为也因而导致他的推广的不力，我自己并没有单独成功配置过，基本上都需要他们的支持人员帮助才能搞定（通常还要花很长时间）
re: 谈谈LoadRunner中Pacing的设置 2007-01-31 17:40 | 槛外人
看了上面各位大侠的评论，收获颇多。
非常同意wufeiwufei的观点，我们现在的性能测试相当于验收测试，在功能差不多稳定的情况下，验证系统是否满足需求方提出的各个性能指标。而Kirk跟我们进行的不是一个层面的工作。他不管用户需求，只考虑自己的程序是否还有调优的空间。
有关于RPS说几句。在我们公司的测试中，性能指标不是由需求方提出来的，而是我们测试人员根据线上的日志分析出出来的。一般关键的指标是2点：TPS和 响应时间。而并发用户数我们是不关注的。跟我们系统本身的特点有关。我们做的是网络支付行业，一般来说，如果用户不提交请求，只浏览页面，对于系统造成的 压力我们是忽略的。
TPS是测试工程师分析线上的日志情况，计算出每天的高峰请求数。响应时间则是按照行业内的2/5/8原则。
按照这样的情况设计的测试场景[测试工具是LoadRunner]，是基于目标的场景，即设置系统每秒要达到的TPS，至于并发用户数是工具根据响应时间自动计算出来的。
在这种情况下，我在想Pacing的设置可能没有太多的关系。因为我们的测试本身就是以服务器的角度来考虑的。不知道这样的想法是否正确，还请各位高手指点。
终于贴完了,精彩吧.希望以后类似的讨论会越来越多.

更新方式：

.      Each Occurrence

每次遇到参数就进行更新。

多次使用同一参数，而且没有什么关联，例如随机数。

Each Iteration

每次迭代时发生更新。 如果参数出现几次，虚拟用户用同一个数值。

适用同一个关联的参数。

Once

所有的地方都用同一个数值，包括所以的迭代。

文件类型参数分派方法

Sequential

按照顺序访问。

 

	更新方式	Sequential	例子
1.	Each Iteration	所有用户每次迭代同时取下一个数值。	All the Vusers use Kim in the first iteration, David in the second iteration, Michael inthe third iteration, etc.
2.	Each Occurrence	所有用户每次遇到同时取下一个数值，即使在同一个迭代。	All the Vusers use Kim in the first occurrence, David in the second occurrence,Michael in the third occurrence, etc.
3.	Once	所有用户第一次迭代时同时取第一个值，该用户所有的子迭代值不变。	If you specified Once, all Vusers take Kim for all iterations.

 

例子：

First Name

Kim

David

Michael

Jane

Ron

Alice

Ken

Julie

 

没有足够的值，从第一行开始重新取值。

 

 

 

 

 

Random：每个虚拟用户开始运行时安排随机的数值。

 

	更新方式	Random
1.	Each Iteration	每次迭代时，随机从数据表中取数。
2.	Each Occurrence	每次遇到随机取一个数值，即使在同一个迭代。
3.	Once	第一次迭代时随机取值，改用户所有的子迭代值不变。

 

 

数据必须足够，例如20个虚拟用户，5次迭代，至少要有100个数据。

http://www.rayfile.com/zh-cn/files/24552c9c-1b5a-11dd-b1d1-0014221f4662/

选自《Web性能测试实战》

      

        配套性能测试课程：

        1、LoadRunner性能测试入门与虚拟用户开发基础（点击进入）

        2、LoadRunner Controller使用基础（点击进入）

      

        请看下面一个性能测试小案例：

某公司OA产品的新版本即将发布。为了看看系统的性能，决定安排测试工程师A君执行性能测试任务。A君做法如下：

1.       找到一台PC机，CPU主频1G，内存512M，……；

2.       在找到的PC机上搭建了测试环境：安装了Oracle9i、Weblogic等系统软件；

3.       在自己的工作机上安装了LoadRunner7.8;

4.       然后录制了登陆、发布公告等功能；

5.       开始设置30、50、100、500不同的并发用户数目进行并发；

6.       最后得出结论：系统只能运行80个左右的并发用户……。

无疑上面的做法存在很多不合理的地方，例如测试内容太少、测试服务器配置太低等。现实工作中，尽管性能测试以其在测试中独特的地位越来越为软件测试人员、开发人员和用户所重视，但是不管是测试人员还是开发人员，仍然在认识上存在这样或者那样的误区。

误区1：提高一下硬件配置就可以提高性能了，因此性能测试不重要。

这是以前系统规模不大时期留下来的认识。DOS时代以及后来Windows操作系统流行的初期，软件规模一般较小，而硬件的更新却是日新月异，软件性能一般不是突出问题，因为只要升级一下硬件，很容易就解决了性能问题。

现在随着软件规模的扩大，提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题，再多的资源可能也不够用，例如内存泄漏问题，随着时间的增加，内存终究会被耗尽，最后导致系统崩溃。

因此，如果用户对软件的性能要求较高，这将意味着不但要从硬件方面来提供性能，还要从数据库、WebServer、操作系统配置等方面入手来提高性能，同时开发的软件系统本身也要进行优化，以便全面提高性能。

误区2：性能测试在所有其它测试完成后，测试一下看看就可以了。

这是目前特别普遍的一种现象，例如前面的A君，这种现象主要是没有意识到性能测试的重要性。这种做法最严重的后果是如果性能问题是由软件系统本身产生的，可能会无法根治性能问题。例如架构设计方面的失误，可能意味着软件系统将被废掉。

当然这并不意味所有的性能测试都要尽早进行，性能测试的启动时间要由软件特点来决定。性能测试策略的制定问题可以参考《程序员》2005第10、11期的《治疗软件亚健康》。

误区3：性能测试独立于功能测试。

功能测试可以发现性能问题，性能测试也能发现功能问题。性能测试和功能测试是紧密联系在一起的，原因之一是由于很多性能问题是由软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下，通常会带来一些性能问题。功能测试通常要先于性能测试执行或者同步进行，软件功能完善可以保证性能测试进行得更加顺利。

误区4：性能测试就是用户并发测试。

仍然有很多人（尤其是开发人员和部分项目实施人员）一提到性能测试，就会联想到并发用户测试，进而认为性能测试就是“测试一下多用户的并发情况”。严格地讲，性能测试是以用户并发测试为主的测试。实际性能测试还包含强度测试、大数据量测试等许多内容。

误区5：在开发环境下进行一下性能测试就可以了。

很多时候，在软件开发完成后会进行性能测试，看一看软件的性能。实际上大多数的开发环境因为硬件条件比较差，所以反映不了过多的性能问题。

因此性能测试要尽量在高配置的用户投产环境下进行。但是有两种可以例外的情况：一种是为了发现某些功能方面的问题，例如为了发现并发算法的一些缺陷；另外一种就是有非常好的硬件资源或者实验室作为开发环境。

误区6：系统存在瓶颈，不可以使用。

系统发现了瓶颈，的确是很让人担心的一件事情。不过不要紧，很多的瓶颈可以不必去理会。发现瓶颈的目的主要是为了掌握系统特性，为改善和扩展系统提供依据。因此在性能方面给系统留有30％左右的扩展空间就可以了。

例如，1000个用户并发时发现了系统瓶颈，而客户的最大并发用户数量在500左右，这样的性能问题完全没有必要处理，要是550或者600个并发用户出现性能问题就应该认真地调整系统性能了。

误区7：不切实际的性能指标。

这种现象主要归结于对软件应用需求的不了解。很多时候，尤其是用户会提出很多不切实际的性能指标，例如，针对500个用户使用的OA系统，可能有的用户负责人会提出要满足100个甚至500个用户并发的性能目标，而实际并发数量不会高于50。这种情况只有和用户进行沟通才可以解决。

上面列举的都是日常性能测试工作中相关人员常犯的错误，这些观点只在极其特殊的情况下才正确。希望读者了解这些常见的性能测试误区后，能在以后的工作中避免类似的情况。

 

选自《Web性能测试实战》

      

        图书配套性能测试课程：

        1、LoadRunner性能测试入门与虚拟用户开发基础（点击进入）

        2、LoadRunner Controller使用基础（点击进入）

 

注：转载请注明出处与原文地址。 

在各类软件测试工作中，性能测试往往不被重视，而项目中由于系统性能不合格带来损失的例子却非常多。造成这种现象的原因之一就是各个公司习惯压缩测试成本，而在性能测试方面的投入则更少。

本文重点介绍如何基于场景来设计性能测试。选择典型的用户场景来进行测试，不但可以大大降低执行成本，更能提高性能测试执行效率。

在以前的《治疗软件亚健康》中，笔者重点讨论了运用“全面性能测试模型”来组织各类性能测试的方法。“全面性能测试模型”提出了设计性能测试用例的框架，在实际项目中通过它可以确定性能测试用例的范围和类别。而在测试用例内容确定后，接下来就要设计各类性能测试用例中的具体内容。

性能测试按照场景不同一般可以分为两大类，一类是为了测试目的而进行的场景测试，另外一类是基于用户实际情况而进行的场景测试。因此，性能测试用例的设计应该面向性能测试场景来进行。

实际上，由于开发环境硬件配置不高，基于用户的测试多在用户现场进行，而为了测试目的而进行的测试多在开发环境即开发团队内部进行，不过两者进行的场所没有严格的界限，例如也可以在开发团队内部模拟用户的环境进行性能测试。

“为了测试目的而设计的测试用例场景”主要根据测试设计人员的经验来进行，但是仍然要参考用户的实际场景，用户实际使用场景是设计所有测试用例的依据。例如一些业务系统，虽然备份历史数据的周期为一年，但是设计大数据量测试用例时仍然包含了系统运行一个月、半年等的数据量模拟测试，因为这些均属于用户的典型场景。

综合上面可以看出，性能测试用例设计首先要分析出用户现实中的典型场景，然后参照典型场景进行设计。下面详细介绍一下常见的三类用户场景：

一天内不同时间段的使用场景。在同一天内，大多数系统的使用情况都会随着时间发生变化。例如对于新浪、网易等门户网站，在周一到周五早上刚一上班时，可能邮件系统用户比较多，而上班前或者中午休息时间则浏览新闻的用户较多；而对于一般的OA系统则早上阅读公告的较多，其他时间可能很多人没有使用系统或者仅有少量的秘书或领导在起草和审批公文。这类场景分析的任务是找出对系统产生压力较大的场景进行测试。

系统运行不同时期的场景。系统运行不同时期的场景是大数据量性能测试用例设计的依据。随着时间的推移，系统历史数据将会不断增加，这将对系统响应速度产生很大的影响。大数据量性能测试通常会模拟一个月、一季度、半年、一年、……的数据量进行测试，其中数据量的上限是系统历史记录转移前可能产生的最大数据量，模拟的时间点是系统预计转移数据的某一时间。

不同业务模式下的场景。同一系统可能会处于不同的业务模式，例如很多电子商务系统在早上8点到10点以浏览模式为主，10点到下午3点以定购模式为主，而在下午3点以后可能以混合模式为主。因此需要分析哪些模式是典型的即压力较大的模式，进而对这些模式单独进行测试，这样做可以有效的对系统瓶颈进行隔离定位。与“一天内不同时间段的场景测试”不同，“不同业务模式下的场景测试”更专注于某一种模式的测试，而“一天内不同时间段的场景测试”则多数是不同模式的混合场景，更接近用户的实际使用情况。

上面只介绍了三种典型的场景，实际项目中分析场景一般不会孤立的分析某一特定类型场景，而是把两种或者几种类型场景结合起来进行分析设计，这样做主要是为了选择更典型的场景和节省一些测试成本。

有了上面的基础知识，下面开始逐一讨论各类测试用例设计的细节。在下面的讨论中，将以图2所示的某视频点播网站做为示例，图2显示了该视频点播网站的主要业务以及各个时间段使用场景。

 

图2网上视频点播系统使用情况图

1、 确定用户使用系统情况的方法

确定用户对系统的使用情况是设计用例具体数据的基础，后面并发用户数据设计、疲劳强度设计、以及各种场景设计都要依赖对用户使用系统情况的分析结果。分析用户使用情况经常采用现场调查和分析系统日志两种方法。

l  用户现场调查

用户现场调查实际就是通过和用户进行沟通，进而确定用户的人员组成情况。这类方法适用于用户群体固定且目标测试系统没有投产前的情况。

l  分析系统日志

很多时候，通过和用户沟通不能掌握其使用系统的详细情况，尤其是诸如图2的网站业务系统，因为目标用户使用系统的情况是不确定的。当用户比较分散、现场调查比较困难时，可以采用对系统日志进行分析的方法，以此作为对用户现场调查信息的补充。

大多数的系统都会对用户使用系统的情况进行日志管理，因此可以对日志进行分析，日志分析方法适用于已经投产或者试运行的系统。如果没有系统日志功能，可以和开发人员进行沟通，在测试过程中增加日志管理功能。通常分析系统日志可能要开发一些程序来对其进行统计分析。

在具体设计过程中，一般是两种方法结合使用。图2的网上视频点播系统就是通过两种方法得到的测试数据：通过和用户进行沟通得到全国各地维护人员使用系统的大概情况，然后通过对系统一个月的日志进行分析得出其它用户使用系统的情况，最后综合在一起就得到了系统的使用情况图。

也许有人会问：为什么不通过日志分析得出全部的用户使用情况？主要原因有两个：一是日志分析不一定能得出全部的使用情况，可能产生偏差，例如用户反复登陆系统、注册多个帐号都会影响统计结果；二是日志分析往往较用户调研成本大，因为多会涉及开发工作。

2、 并发用户数量设计

并发用户尤其是最大并发用户数量的设计一直是网上很多测试论坛津津乐道的话题。在前面文章中，已经介绍了并发用户和并发用户数量两个概念，下面将在其基础上讨论一下如何在性能测试用例中设计并发用户数量。

在设计并发用户数量前，首先要了解确定系统最大并发用户数量的方法。下面介绍根据系统的最大使用人数或者最大在线数量来评估最大并发用户数量的方法（注：这里的最大并发用户数量不是指系统支持的最大并发用户数量，而是指系统在生存周期内可能达到的最大并发用户数量）。

l  极限法。取最大在线用户数作为最大并发数，这种方法适用于系统已经投产或者目标用户群体不确定的门户网站，可以通过分析日志来得出结果；也可以使用系统已经注册的用户数量做为系统的用户数量，然后按照经验公式来估算最大并发用户数量。

l  用户趋势分析。对软件生存周期内的用户未来走势进行分析，预测系统可能达到的最大使用用户数目，从而估计系统的最大并发用户数目，这种方法多用于系统用户数目逐渐增加的情况。

l  经验评估法。按照经验来评估系统可能的最大并发用户数，这种方法多用于系统的使用用户数目相对稳定且比较明确的系统。

完成最大并发用户数量的评估后，接下来就可以设计每个用例要模拟的用户数量。表1是上面OA系统的一个性能测试用例。

功能		系统支持多个用户同时进行登录邮件系统的操作。
目的		测试多用户访问邮件模块时系统的处理能力。
方法		模拟多个用户在不同客户端登录邮件，然后进行并发进入邮件系统的操作
并发用户数与事务执行情况
并发用户数	事务平均响应时间		事务最大响应时间	事务成功率	平均流量（字节/秒）
30
60
90
110

表1 性能测试用例并发用户设计示例

通过表1可以看出并发用户数量的设计很简单，基本是按照最大并发用户数量的百分比来设计，例如可以按照最大用户的20％不断增加来设计并发用户数量，直到达到最大并发用户数量。对于某一特定的用例，设计用户数量需要注意下面三点：

（1）              按照各类用户同时递增的方式来设计用户数量。按照递增的顺序设计测试用例是为了按照由浅入深的方法来发现系统的瓶颈，因此系统的各类用户应该同时增加。

（2）              并发用户数的最大值一般不会超过前面计算的最大并发用户数量的20％，除非是为了测试系统能支持的最大并发用户数量。

（3）              设计用户数量时要考虑成本，因为每组用户数都意味着至少执行一次测试。

综合上面的内容，可以看出用户并发数量设计是很灵活的，不用拘泥于公式和形式，只要充分考虑到用户现在和未来的增长趋势就可以了。

3、 系统不同时间段场景的设计

不同时间段的场景更接近用户使用情况，也是设计核心模块和组合模块并发性能测试用例的基础。例如图2的网上电影点播系统，每两个小时使用系统的情况都是不同的，因此需要设计一些典型的场景。

不同时间段场景分析的数据来源主要是前面的需求分析和日志分析结果。通过图2，很容易看出各个时间段不同模块的用户是如何并发的。有了上面的资料，就可以设计各个时间段的组合模块测试用例。下面是图2所示的网上电影点播系统“0~2点” 场景的一个测试用例：

模块名称	并发人数	运行时间
扣费批处理	20	1小时
帐号维护	60
系统备份	11

上面场景的并发人数只是一个实际例子，如何设计最大并发用户可以参考本节“并发用户数量设计”和“业务模式设计”的相关内容。

查看(294) 评论(0) 收藏 分享 管理