集合点的用处对于LoadRunner来说意义非常大，它可以设置多个虚拟用户等待到一个点，同时触发一个事务，以达到模拟真实环境下同时多个用户操作，同时模拟负载,实现性能测试的最终目的。由此可见，插入集合点主要是为了衡量在加重负载的情况下服务器的性能情况。

　　举例如下：在客户的需求中，可能会要求系统能够承受1000人同时提交数据。在LoadRunner中可以通过在提交数据操作前面加入集合点，当虚拟用户运行到提交数据的集合点时，Loadrunner就会检查同时有多少用户运行到集合点，如果我们设定脚本运行的虚拟用户数为1000，等到这1000个虚拟用户都运行到集合点后，就会触发同时进行提交数据的操作，从而能够测试系统对于这1000个用户提交数据的响应情况，依次来看系统是否满足客户的该点需求。

　　集合点除了用于多用户并发操作对服务器施压的性能测试外，还可以用户系统的功能测试，而且这些功能测试都是手工测试所不能实现的，下面以本人实际遇到的两种情况进行说明。

　　A. 用集合点测试编号生成策略：

　　被测系统为一个订单处理的准生产系统，在系统中形成订单的时候会自动生成订单编号，订单编号的生成规则是【日期+时间+4位随机数+2位编号】，如：20091216104924276201，系统中要保证所有生成的订单编号不能重复，而订单编号中关系编号是否重复的关键是“4位随机数”。现在系统的实际操作可能会出现同时有200个订单录入员提交订单，提交订单时会生成订单编号，要保证不会出现重复的编号，设计测试用例：在提交订单之前插入集合点，虚拟用户为200，运行脚本，运行结束后查看运行后提交的订单个数，然后查看订单编号是否有重复的情况；

　　如果运行脚本发现频繁出现有订单编号重复的情况，可能订单编号的4位随机数生成策略不能满足需求，需要考虑采用更好的生成策略；如果多次运行脚本未出现有订单编号重复的情况，那么可以说明4为随机数生成策略以满足订单编号生成的需求和设计。

　　B. 用集合点测试互斥锁定策略：

　　被测系统还是订单处理的准生产系统，生成后的订单是可以被部分用户把信息读取到另一个系统中的，读取的时候要保证一个订单同时只能被一个用户读取，一旦一个订单被一个用户读取到后，其他的用户就不能再读取到这个订单，只能读取到其他可以被读取的订单。读取订单时是可以选择读哪一个订单，也可以不选定，不选定系统就会自动分配。

　　设计实现这个功能的时候，实现方式是，订单被用户读取到后，就将该订单加锁，加锁的订单其他的用户是不能读取到的，这时系统就会按照策略分配其他可被提取的订单给其他的用户。手工测试是这样进行的：

　　预置条件：系统中有多个待读取的订单A、B、C……，默认读取顺序就是A、B、C……

操作步骤：

　　1、用户1选择读取订单A，读取成功；然后用户2选择读取订单A；

　　2、用户1读取订单，读取到订单A；然后用户2读取订单；

　　预期结果：

　　1、用户2读取订单A失败，返回正确合理的提示信息；

　　2、用户2读取到订单B；

　　手工测试并未测试出设计和实现有什么样的缺陷，功能正常。

　　考虑到客户实际使用系统时，提取订单的用户是上百个的，很可能出现这些用户同时读取订单的情况，这样的场景下，几个测试人员手工测试是不现实的，这时考虑设计集合点并触发多个用户同时进行读取订单事务操作就比较适用。

　　而实际运行的情况是，在订单读取操作前设置集合点，只使用两个虚拟用户在同一时刻读取订单就出现了读取到同一订单的情况，说明程序在实现上是存在缺陷的，这也很好的对手工测试不能覆盖到的地方做了测试补充。

　　集合点插入方法：

　　1. 录制时，在需要并发操作的事务前直接点击插入集合的按钮；

　　2. 录制后，录制的脚本中，在并发操作事务提交前插入，点击右键，选择，然后选择后面出现的，输入集合名称，脚本中出现，即添加集合点成功；

　　备注：集合点只能插入到Action部分，vuser_init和vuser_end中不能插入集合点。如果想要测试系统所能支持同时登录的用户数，登录的事务要写入到Action中，然后插入集合点进行测试……

（以上言论仅代表作者的个人观点，不代表51Testing观点）

版权声明：本文出自shiruili215的51Testing软件测试博客：http://www.51testing.com/?165464