大家好！目前项目正在做某大型国企的性能测试。由于刚接触性能测试，对很多的基础概念并不了解，测试中遇到的一个问题就是在并发测试中是否需要加入集合点。在此将“并发用户测试与集合点”之间的关系分享给大家。（参考网络博客，并总结）。
备注：此处以倒叙的方式分享，即先将我的最终结论展示给大家，再分享“并发用户测试与集合点”之间的关系。
项目背景：
企业CRM系统；具体业务以订购某个商品A为例；
我们此阶段的性能主要目的是对系统的调优，
那么首先这个性能脚本从登陆、用户初始化、进入商品订购页面、选择商品、订购提交、退出系统这六个主要事物组成。这里以并发100用户数为例。
痛点：
并发测试中是否应该加入集合点？集合点应该加入在哪里？
最佳实践：
集合点是一种特殊的并发，通常是以调优为目的性能测试中才会用到，主要是有针对性的进行试压，以便找到性能瓶颈。
正如项目背景中所提的，我们此阶段的性能测试目的是性能调优，所以最终方案选定为：加入集合点；集合点加在事物“订购提交”事物前面（插入的具体位置是业务层面的，此处不做解释）。
并发测试与集合点的关系：
此图为系统结构图
如上所示：一个系统的运行过程，包括A:客户端、B:网络、C:应用服务器、D数据库服务器；
从客户端发送出请求开始，再到客户端收到应答这段过程就是我们性能测试所要关注的内容。这个过程中每一个环节都会有各自的延迟，都会成为性能的瓶颈，并不能达到严格意义上的并发。
并发用户：就是同时操作的用户，但是并不是严格意义上的并发；在此项目背景下就是100个用户同时初始化、然后进入业务办理页面、订购商品、提交。由系统结构可以知道：客户端从提交到得到应答经历了很多个环节，每一个环节的时间并不能保证严格一致。也许会造成70个用户同时在提交环节、而其余30个用户由于网络或其他原因还在进入业务办理界面这个事物上。所以最终对“订购提交”这个点上并不能给予足够大的并发施压。
集合点：集合点是一种特殊的并发，是等到特定的用户数后再一起执行某个操作，是相对严格意义上的并发。如：把集合点放在“订购提交”事物前面，先来的10个用户并不会进入“订购提交”，而是要等到100个用户都来到了这个事物前面才会统一发送“订购提交”这个请求。这样对“订购提交”这个点上所压的数据量就是100个了。
备注：我在集合点上面说到一个词“相对严格意义的并发”。为什么是相对意义的并发呢？因为实际情况中并非所有用户都会同时到达集合点，请参考上面结构图，因为从客户端发出到网络、应用服务器、数据库中的每一个环节都有延时，也就是说不可能所有的用户都能到达所谓的集合点，才开始同时执行操作。（其实没有必要追的这么细）
总结
实际使用“集合点”时，还要具体业务具体分析。比如我这个业的性能脚本从登陆、用户初始化、进入商品订购页面、选择商品、订购提交、退出系统这六个主要事物组成，而主要性能压力点是在订购提交，这需要使用集合点。而如果只是对登录系统做并发的话使用集合点就基本不存在意义，这个大家可以插入集合点试一下，据说是否使用“集合点”对系统性能影响不大。
性能测试的执行应该是有目的，通常是为了调优，也有的是为了评测
在以评测为目的的性能测试中，用户更关心的是业务上的并发，其实是真实业务场景的并发情况，这种情况下就不需要设置集合点了。
集合点是一种特殊情况下的并发，通常是在以调优为目的的性能测试中才会用得到，主要是为了有针对性地进行施压，以便找到性能瓶颈。
此阶段做工作目的是调优，所以加上集合点是必然的。那么最后验收评测呢？是否有必要加集合点呢？由于甲方对此次系统的性能十分关心，每周一次性能周例会，是否使用集合点的结论可想而知。“必须使用集合点，最大程度的给系统试压，如果可以的话，给我插入100个集合点”。（甲方虐我千百遍，我待甲方如初恋）
参考文献：
1、http://blog.csdn.net/e421083458/article/details/17240429
2、http://www.cnblogs.com/fnng/archive/2013/03/04/2943513.html#