故事开始于xingcyx的一番话：

声明：以下的问答是我根据实际工作经验和通过各种途径得到的信息而整理的，其回答内容主要代表我个人观点，并非标准答案，读者如有不同意见，欢迎批评指教。

Q：并发用户数和集合点有必然联系吗？在性能测试中必须使用集合点来测试吗？

A：并发用户数，顾名思义，就是同时操作的用户，这里的“操作”可以指对系统真正的操作，也可以只是连接（此时通常叫作“并发连接数”），而集合点是一种特殊情况下的并发，多用于测试系统在瞬间加压的表现。因此，并发用户数和集合点有联系，但并非必然的联系，在测试并发用户的性能测试场景中，可以不必设置集合点，这将视测试目标和测试策略而定。

Q：不设置集合点的测试，能代表是“并发”操作吗？

A：有这样一种说法，设置集合点是为了确保“严格意义上”的并发，其实从本质上看，这主要是一个看问题的粒度大小的问题。集合点的作用是通过工具的控制，确保一个请求严格的“同时”从前台提交到后台。可是如果微观地看，是不存在严格意义上的并发的，即使在客户端通过设置集合点的方式将100个请求同时提交到后台，经过网络上的传输消耗，可能它们并不是同时到达的，而即便100个请求同时到达服务器端，受到中间件和应用系统、数据库的各种连接池、缓冲区， CPU处理队列等的限制，也可能在服务器端产生等待的。因此，严格意义上的“并发”可以说是不存在的，我们需要做的是在可以接受的粒度范围内取得一个最佳的平衡点，站在这个平衡点的层面上去看待“并发”这个问题。

性能测试无非有两个目的，一是评测，二是调优。

在以评测为目的的性能测试中，用户更关心的是业务上的并发，也就是真实业务场景的并发情况，这种情况下只要按照业务操作的模式去设置场景就可以了，并不需要设置集合点。

集合点是一种特殊情况下的并发，通常是在以调优为目的的性能测试中才会用得到，目的是有针对性地对某个可能存在性能问题的模块施压，以便找到性能瓶颈。

集合点在我实际的测试过程中用得并不多。

Zee：

关于集合点，我一直觉得没有什么可争议的，这两天看到几个帖子在说这个东西。有一点我想大家都是认同的：集合是相对的集合。

集合是在产生负载的机器上的集合。如果考虑网络，中间件等等的因素。到服务器肯定不会是同一时间点，那于是就有人希望能更接近在服务器端实现并发的操作。认为这才是真正的并发。

我觉得首先要做的是分析应用系统，到底你想做的是什么。

比如说，你想让某个URL能达到1000个同时请求的目的。这样的目标就比较明确了。

而在讨论集合点的时候，大家很少拿具体的东西来举个例子。这样有点说不清楚。要想达到并发。我觉得应该更具体的分析应用。再来定下目标来做。而不是一直在讨论LR如何能实现。

Xingcyx：

因为在实践中，我经常会碰到这样的情况：

测试需求说，该系统应支持200个并发用户。

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

大漠飞鹰：

测试前肯定要了解需求，或者说是测试目的。

就说明“该系统应支持200个并发用户。”， 这种需求严格意义上来说是不合格的需求，因为描述不够清晰，过于模糊等。

当然，在实际中，这类需求到了我们测试人的手里也是常有的，一般就当普遍的情况来出来。

比如，web系统，就按2/5/8，或者2/5/10来处理，如果能通过就pass，否则就让开发人员调优。

Zee：

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

比如用户说了：要求200个用户并发。

那要问清楚的就是，200个用户是个什么样的比例，有多少人在干这个，有多人在干那个，按百分比，用不同的脚本来跑。

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

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

Xingcyx：

楼上说的是最常见的一种情况，在这种测试需求下，我会设置一个混合场景来测试，也就是按照做不同事情的用户的百分比去设置。

但会有另外一些时候，并不是一个实际的应用系统，可能是一个开发平台，或者工作引擎等，它涉及的性能的概念会更偏向底层一些，这个时候可能就不是像一般的应用系统那样，设置一个混合场景来测试那么简单了。

大漠飞鹰：

一般说的并发数指的是业务并发，而不是服务器端得并发数。

下文转载 LR并发用户数：https://wenku.baidu.com/view/306189aba48da0116c175f0e7cd184254b351bee.html

问题：支持100个并发同时登录，怎么理解？

（并发用户数：在同一时刻与服务器进行了交互的在线用户数量）

刘德宝老师：100个并发同时登录并不代表你要设置100个虚拟用户，这是一个10*1和1*10的问题。100个并发可以100个虚拟用户同时做一件事情，也可以一个虚拟用户同时做100件事情。比例1：10000。如果一个系统要承受3500000的访问量，那可以设置350个虚拟用户。

随风：有广义并发和狭义并发之分。广义并发就是设定多少个虚拟用户，狭义并发还要设置集合点和虚拟并发用户数。刘德宝老师说的就是狭义和广义的概念，他可能是说广义并发用户和实际在线用户的比例1：10。针对测试目的不同广义狭义都要用。实际工作中，我们大部分应取狭义，如100个并发就设置100个虚拟用户做同一件事。

老师说的350个虚拟用户，不是绝对的比例而应该只是举例说明。

lich：某时刻点的并发，一个并发对应一个用户。某时间段内的并发量，则是一个用户可产生多个并发。具体某时间段内需要多少并发量，需要多少个用户，需要计算的，最多用到的是20/80原则。一个用户多个并发就是做完一件事  又去重复做sun：350000是指pv吗？

PV（page view）即页面浏览量，或点击量，通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。要转化成并发用户得看用户都有哪些操作行为 分别的比例是多少海带：能够支持2000个人同时操作系统。2000是同时在线人数，由同时在线用户要进行分析 转化成并发用户。20/80原则指的是20%的时间内，完成80%的交易。

举例：比如有预测1000个实体用户，需要在早上30个分钟内登录完毕，但在这半个小时内总有高峰段，比如10分钟内集中登录，那你就需要有个模型说预测这份高峰时多时。那就用2/8原则来预测。半个小时*0.2=6分钟，6分钟内800个用户登录上去。那你设置的场景就是6分钟，800个均匀的登录上去，如果能登录，系统指标正常，那表明登录模块问题不大。

集合点用于非常规测试，用来预测某一功能点的并发多线程能力。集合点只是手段，具体看你的目标是什么。

我的观点是：任何测试都是手段，手段后面的目标是什么需要分厂清晰。包括什么是2/8原则，无非就是测试的目标就是找出登录模块是否有瓶颈。

LoadRunner里面的100个并发，和我们所讲的系统能够支持100个并发用户是2个差别很大的概念。通俗点讲：LoadRunner里面的100个并发，都是机器人用户，会不断地操作功能点。（在相对不考虑思考时间） 而实体系统中的100个并发，有人很久才点某一个功能点，有人在发痴。。。。。等等。 所以2者的压力是完全不同的。

海带讲的就是2000个实体并发，得转换成loadruner里面的并发。如果是我拿到这个需求（100个并发同时登录），那就如果这个系统投产了，那就去生产取日志，然后统计每个交易量，这样配比和交易量出来了，场景就出来了。如果没有投产么，和业务拍脑袋了。先拍脑袋，后拍屁股定下来，再拍脚后跟，开始干活。

卡卡西：100用户集合点测试和没有集合点测试不一样的，还要看场景。场景要分析清楚 到底压力在db 还是memcache app 负责均衡 或者图片服务器