以下是我的回复，想法不一定正确，希望抛砖引玉：

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

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

以下是wufeiwufei的回复：

您好！
看了那位同行的问题，说实话，如果项目组给我这样的一个业务调研结果，我在需求评审中是不会通过，因为对于一个门户网站，如果你不能估计峰值，不能估计数据量，你是如何确定硬件的？如何选择中间件，如何选择数据库的？如果需求开发都做不好，怎么能保证后期的设计和测试阶段能好？这时我会要求项目组按照我说的几点重新调研，如果实在做不到，我只会根据初步的估计，然后算出最佳的并发数，最大的并发数，及在这些并发数下的各个业务的响应时间，并作成图表，然后作为测试结果提交。
为了更好的回答，将问题整理下：
1、根据每日访问量10万人次、目前在网系统每天的页面访问量、能满足同时在线人数2000人的访问三个条件，确定测试模型。
2、为什么查询类对系统瓶颈最大？
需要再次说明的是：这种情况我遇到过，但是都被我挡回去了，或者我是先算出最佳后，反向推导出业务数据，然后说服了客户，并没有根据这些值确立目标，以下是我的粗浅的见解，可能并不正确，还望jackei兄指导。
第一个问题: 按照现在的业务调研数据，想要精确的算出是不可能的，只能算出最低值，所以测试方案仅供参考，请根据实际情况进行调整。
模型如下：
1、收集系统每天页面访问量和对应数据库中的数据量（日志，业务表插入记录数，表空间等等），如果设计的时候有准备最好以年为统计时段，实在不行就用估计的业务量最大的一个月，再不行只有用1个星期了。得出平均的每日访问量与数据库数据量之间的比例，例如：平均日访问量10000，数据库业务表插入1000条数据。根据这个比例算出日访问量10万次时，数据库数据量的膨胀值。最好还能根据这些得出那些表的访问量大，查询动作多还是update动作多，为第二问题做些准备。
2、以几个星期或者几天为时间，在数据库中做个定时器，将每小时的访问量读出存入一个特定表中（24个小时24个字段），形成图表，算出每小时访问量所占最大比值，80％的平均比值，然后乘以100000，得到每小时访问量最大值，80％平均值。假设得到的最大值是20000人/次，80％平均值是5000人/次。
3、对于在线人数2000人，有两种理解，分别是平均在线人数2000人和最大在线人数2000人。按照你的描述，我就把它当成是指最大在线人数2000人。如果你是为了推算session过期时间，那么根据每小时访问量最大值是20000人/次，我觉得session设置成6分钟就足够了，如果你已经设置了1小时的session过期时间，那么根据每小时访问量最大值是20000人/次，你必须考虑到此时最大在线人数已经是20000次了，你必须根据这个值（而不是原来的2000）算出内存大小，至于每个session的大小，为了严谨，请根据实际情况进行查看。其实我觉得在线人数2000人，除了算session过期时间，衡量内存（你要全部都用cookie，那也没必要算），没什么大用。如果实在要测，可以采用不录制退出（当然程序设计里要去掉重复登陆的判断，或是找到足够多的ip地址），准备大量数据多次迭代，持续测试来达到验证这个值的目的。
4、根据你session设置的时间，参考在线人数和最大每小时访问人数，算出平均每秒并发数，按照假设，算出每秒只需6个并发数。以这个做为最佳并发数的最低标准。最大并发数以测试数据为准。一般这种情况下，最佳并发值一定比这个标准大10到20倍。进而反向推算内存大小，业务数量等。
5、如果你按照每秒6个并发数，请不要在脚本中设置thinktime和pacing，同时必须至少测试24个小时，因为数据是从一天推断而来。

第二个问题：
1、根据那位同行的描述，我看不明白他的脚本如何设置的，并不清楚并发用户数多少，以及trancation中包含什么，而导致查询速度较慢。
2、如果我来分析，首先写个简单的接口调用页面（传入参数，判断返回值，不显示返回数据），然后跳过系统，直接测试接口，如果速度不慢，将展现返回数据的页面加上，再次测试；如果还是慢，那么跳过接口，直接测试存储过程或是sql语句。

发送了几次邮件，总是发不出去，最后一次貌似发送成功了，也不知道是否可以收到 ^_^

以下是jackei的回复：

两位仁兄好。实在不好意思，今天才给大家回复邮件，下面是我的一些看法。

首先，性能测试的主要目的还是去了解和验证系统的响应能力，并尽可能避免系统在上线运行后出现性能缺陷。而为了达到这个目的，一方面要了解客户的性能需求，另一方面要尽可能的去模拟上线后的情况——这两个方面看似相同，但实际上还是存在少少的差别的。例如，有的时候客户提出的需求未必合理，或者未必是准确的、可度量的，那我们就更需要根据对客户以往的业务情况来进行分析和整理。

我们再来看一下在这封邮件中，所提供的信息包括如下几条：

1. 每日访问量10万人次；

2. 目前在网系统每天的页面访问量

3. 能满足同时在线人数2000人的访问

正如原文中提到的，这是一个比较复杂的门户网站，提供了多种可供访问的服务，如果我们不能进一步获取有关系统负载更准确的数据，而仅仅是依靠上面的几条信息，恐怕是很难模拟出一个尽可能有效的场景的。不过我们也知道，要模拟一个完全真实的场景是不可能的，我们只能是尽可能的无限接近真实的场景。下面是我的思路：

1. 在进行多个业务的组合场景的测试前，先对每个单一的业务模块本身的性能进行验证。如果单一模块的性能都无法达到要求，或者单一模块已经在满足性能需求的同时消耗了大量的系统资源，那么它将成为制约系统性能的一块“短板”；

2. 为了对单一模块的性能进行验证，需要明确每个业务模块所要承受的负载有多大。可以考虑获取系统在上一年度中，每个月的月初、月中、月末每个业务的日均访问量，例如，查询模块1，一月上旬的日均访问量，一月中旬的日均访问量……并进一步根据 80/20 的原则（80％的业务发生在20％的时间内）来估算系统最终需要面对的负载；

3. 根据上面的数据，同客户方确定该模块应该要满足的性能需求——包括负载和响应时间要求（在原文中一直没有看到响应时间的要求）。另外，还需要明确数据环境，例如，系统中只有10万业务数据，和有1000万业务数据，在进行查询和业务办理时会导致性能表现的不同；

4. 对单一模块的性能进行验证，如果单一模块的性能无法满足需求，则先解决这个模块的问题——如果认为查询类业务性能较差，应该在这个时候进行分析，并识别性能瓶颈，进行优化；

5. 对于组合场景的模拟，一直是一个存在争议的问题。常用的方法是根据对系统某个时间的“剖面”，来获取系统负载在不同模块上的分配比例——例如上面我们分别取到了“系统在上一年度中，每个月的月初、月中、月末每个业务的日均访问量以及峰值”——再使用不同的脚本模拟不同的业务，并对每个业务分配相应的负载。根据原始邮件中的描述，会存在三种不同的组合场景，即：月初的偏查询型，月中的平衡型，和月末的偏业务型。在实际执行测试时，根据不同的模型为不同的脚本分配不同的用户数，并运行脚本足够长的时间，或足够多的迭代次数。关于这方面的，可以参考国外同行的一些资料，如下：

Part 2: Modeling Individual User Delays

Part 3: Modeling Individual User Patterns

Part 4: Modeling Groups of Users

6. 对于在线用户和并发用户的问题，我想我们是否可以进一步讨论一下：对于系统来说，所谓的在线用户并不是静止不动的，他们应该是来自于上一个操作，而且也一定会发起下一个操作——即便是直接离开网站。所以，如果想更准确的模拟用户场景，则还需要进一步对用户的行为进行分析。所以我不是很赞成简单的模拟一些用户占用一些资源的方法；

7. 可以不使用集合点，也可以不使用 think time，使用 Ramp up 的方式增加并发用户数更多的是用于了解随并发用户数增多，系统的性能表现会如何改变，所以“每10秒增2个用户”似乎意义不大，建议在组合场景中等比例的增加各个脚本的并发用户数量，并观察系统的性能表现；

8. 超过预期负载的测试也是必须的，特别是对于每天都处理大量业务的门户，需要考虑系统在任意时刻的可用性和面对超负荷运行时的可恢复性。这方面可以参考我在下面一篇文章提到的“可恢复性测试（Recoverability Testing）”。http://www.cnblogs.com/jackei/archive/2006/12/04/580966.html。

评论在继续，而且越来越精彩！以下是wufeiwufei的回复：

两位仁兄好，昨天有事未能及时回复，十分抱歉。

首先，我想先说说我不认同jackei和xingxin兄的两个推断性能标准的行业原则。根据我对门户网站的测试经验，发现有如下几种规律：

1、大部分人大多数时间是在看而非在操作。

2、大多数操作集中在查询和操作结果的显示上。

3、大多数人的操作所涉及的事务数仅仅只有几个。

4、根据门户网站的类型和业务的不同，大多数门户网站的常规忙时是可以预测的。（突发情况除外）

如果两位认同这几种规律，那我们再来看看这3个需求点。

1、每日访问量10万。

2、目前在网系统每日访问量

3、能满足同时在线2000人的访问量。

根据规律我们可以得出推断如下：

1、我们可以知道10万人和在线2000人都不能作为推断并发数的绝对依据。

2、根据规律4，我不太清楚，80％和20％的意义会有大（大概只有在测出真实性能指标反向推导业务量时候有作用）。

3、根据业务调研（这个调研是肯定可以得出的，因为常规的门户网站会有相应的业务量报表）以及每日访问量，我们可以推断出这个门户网站的忙时所占的业务量比值。

4、根据规律1，2，3，我不是很理解为什么要逐渐增加并发用户数（按照我的理解这样做的目的并不是为了得到最佳和最大，而逐渐增加并发用户数只是为了获得系统曲线，这个曲线对用户的意义不大，更多的是帮助我们分析），因为大多数的用户在大多数时间并没有发出请求。如果我们是要测试服务器极端情况，那也应该直接用最大的并发数进行测试或是用大于等于最佳并发数进行长时间负载测试。性能测试的最主要目的是找出系统的瓶颈所在，为了这个目的而使得脚本尽量接近真实的环境，但是一味的追求真实而忽略了根本目的，也就失去的性能测试的意义，想这种逐渐增加并发用户数，你得出的响应时间有多大意义了，这个时间既不能说服用户是真实的情况，又不如最佳时间那么有说服力，还不如最大并发数下的响应时间有警示作用。

5、我们根据这3个需求点是无法得出具体的性能指标的，这只能作为参考，做为我们得出实际的性能指标后，推导出业务量，并用来说服客户的一个依据。

先放下这个问题，我觉得我们有必要来探讨下性能测试工程师到底应该做些什么，我提出几个问题，希望jackie和xingxing兄能抽空思考下：

1、性能测试工程师更应该关注系统的性能还是对真实环境的模拟。

2、性能测试工程师的最重要守则是不是应该是诚实和准确。

3、性能测试工程师是为了检测系统性能还是为了保证系统的运行。

我给出我的见解：

1、性能测试工程师更应该关注系统的性能，真实环境的模拟只是关注性能的一种手段，如果手段与目的冲突，那就应该将舍弃真实环境而用更干净的环境。

2、性能测试工程师应该以诚实和准确作为自己的守则，也就是对于不准确不合理的需求应该有勇气去引导客户而不是让苦户引导你。比如上一种需求，如果在需求确认前，你应该引导客户，去取得需求，如果是在验收阶段，你应该是根据实际得性能指标去说服客户放弃前一个需求，接受后一个标准。

3、性能测试工程师是为了检测系统得最佳和最大性能，而不是为了保证系统在实际中得运行，这点是要强调的，因为我们测试所用的方法都是一种对请求和响应的模拟，这点本身就已经不真实了，所以得出的指标只能作为一种参考，因为实际中系统遇到的情况千奇百怪，你是无法预测的，而对这种情况的保证只有交给监控。比如：上述这个门户网站是有可能出现2000在线人数变成2000并发数的，你无法为了这个突发的情况去扩大成本，满足这种极端情况，所以你所能做的是让监控部门监控系统，遇到这种情况后，去主动拒绝掉其中部分人的请求，而保证系统的正常运行。

以下是我的回复：

认真拜读了suliang兄的邮件，只觉得说得真是精彩！真的学到了很多东西，非常感谢！

很巧合的是，suliang兄提出的问题“1、性能测试工程师更应该关注系统的性能还是对真实环境的模拟。”正好是我最近一直在思考的问题。而就在一个小时前，我在给关河老师的回复的贴子里面也提到了这个问题，正有意和各位同行讨论（见该链接：http://www.blogjava.net/xingcyx/archive/2007/01/09/90498.html#92514）

正如我在回复里面说的，我在实际的性能测试工作中，通常都会要求将后台服务器的一些无关进程、服务停掉，并且尽量使网络独立、或者保证带宽足够等，这样的做法，本质上也是在确保使测试出来的性能结果尽量接近“实际的代码执行时间”。也就是说实际上，对于这第一个问题，我和suliang兄的意见是一致的。因为在项目组提出性能测试的申请时，他们通常是要求我们能够帮助他们指出他所开发的“应用系统”的性能问题（或者更严格地说，是“代码执行”的效率）。然而，同时我可能会有另外一个身份，是作为公司的性能测试组成员，接受客户的委托，来对开发组开发的软件进行一个性能测试，因此也必然会出现两种不同角度的冲突。所以这个问题的提出非常好，真是提到我的心里去了，我也很希望听听jackei和其它专家的看法！

对于问题“2、性能测试工程师的最重要守则是不是应该是诚实和准确。”，我想答案是肯定的，我十分希望自己能够达到这样一个标准。不过实际的情况往往是不以我的意志为转移的，个人感觉在国内的软件业，要做到这一点是很困难的，个中原因我想我不用多说各位也都很清楚，也想听听suliang兄的成功经验。^_^

至于问题“3、性能测试工程师是为了检测系统性能还是为了保证系统的运行。”，提得更是非常之好！因为说实话，如果不是suliang兄提出，我一直到现在都没有意识到这个问题。我说说自己的看法吧：我觉得应该是前者。在我看来，性能测试的主要目的有两种：一是检验系统的性能是否符合要求（假如这个要求已经被提出的话），二是找到系统的性能瓶颈，为优化提供依据，简单概括就是“一评测、二调优”。每进行一次性能测试，目的总会是其中之一，或者兼而有之。我自己的实际工作中常常是兼而有之的，不知道两位的情况是怎样。而至于“保证系统的运行”，我认为应该是项目经理/产品经理/市场经理/销售经理等根据我们的测试结果去相应调整系统的运行配置或者销售策略等。当然这样做的前提是我们的测试结果要十分严谨、准确，能够真正有参考依据价值，这也是我们性能测试工程师的责任重大之所在。

这样的讨论越来越有趣和有意义了，我非常希望能够继续下去！再次感谢两位在百忙之中抽出时间对我的指教！

在第二段评论即wufeiwufei的回复中模型的第2点有如下的句子：
算出每小时访问量所占最大比值，80％的平均比值，然后乘以100000，得到每小时访问量最大值，80％平均值。假设得到的最大值是20000人/次，80％平均值是5000人/次。
我对“80％的平均比值”的意思不太明白。我是一个测试新手，能否给解释一下？

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