声明：以下的问答是我根据实际工作经验和通过各种途径得到的信息而整理的，其回答内容主要代表我个人观点，并非标准答案，读者如有不同意见，欢迎批评指教。
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：
楼上说的是最常见的一种情况，在这种测试需求下，我会设置一个混合场景来测试，也就是按照做不同事情的用户的百分比去设置。
但会有另外一些时候，并不是一个实际的应用系统，可能是一个开发平台，或者工作引擎等，它涉及的性能的概念会更偏向底层一些，这个时候可能就不是像一般的应用系统那样，设置一个混合场景来测试那么简单了。
大漠飞鹰：
一般说的并发数指的是业务并发，而不是服务器端得并发数。
