以下是在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，等

网友 大漠飞鹰：

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

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

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

关于并发用户数和集合点补充的一些看法；
并发用户是从一个更大的概念上说的，可以说是在一个用户层次，而集合点是在事务层次的，这一点在没有运行脚本终可以设置集合点；
如果对于一个事务有10用户并发设置集合点也在次事务，此时设置不设置没有区别，但是如果有一个脚本有多个事务，而又对一个事务设置了集合点的话，这样就会又确别，对于此脚本中的其他事务用户可能不是并发，但是对于集合点的事务一定是并发的。

并发用户数 SimUsers（Vusers）前一个是Avalache里边的并发用户数（仿真用户数）后一个是LR的并发用户数（虚拟用户数）；
以下是Avalache用户手册中对于SimUsers的解释：
An abbreviation for simulated or virtual users. SimUser applies to a user processing through an Action list one time. This load specification generates enough load to reach and maintain a target number of concurrent simulated users. It allows you to determine the maximum number of concurrent users your device, infrastructure, or system can handle.
Use this specification if you want to keep applying load even after the device under test fails. The amount of traffic generated depends on the performance of the device under test. As the system slows down due to overloading, generally each user takes longer to process through the URL list, and the load "throttles back" and generates fewer new users.

注册用户数，首先是以个论坛的或系统的容器的量，它要看你的后台数据库能够支持的用户注册能力，可能约束的又用户ID（如果又长度比如十位，并且不能重复）那么应该可以注册 的用户数为10的10次方个用户；
并发用户数是指系统的提供服务的能力，即同时能够支持的在线用户数量；从测试的角度来讲，需要模拟足够多的用户去同时访问DUT，来确认最大并发用户数。