• 方法1：用新建来测试并发——只有在拆除阶段的时候，会有连接的拆除。
• 方法2：用并发的方式来测试并发，边建立边拆除——在达到期望的并发值后，开始有连接的拆除和新建。
• 方法3：用并发的方式来测试并发，从一开始就边建立边拆除——在达到期望并发值的过程中，就有连接的拆除和建立。
• 方法4：用并发的方式来测试并发，只建立不拆除——测试至始至终都不拆除

方法3：用并发的方式来测试并发，从一开始就边建边拆

测试场景（可以把新建和并发关联起来测试，找到两者的平衡点）

场景1：想知道，某现网环境，平均50w并发，3000新建，设备是否可以支持。

场景2：想知道在xxx的并发下，新建最大可以达到多少。

测试思路

• 先测试最大新建。
• 然后以最大新建的1/10来估计整体的爬坡时间（1/10是经验值，整体爬坡时间=期望的并发值/新建值）
• 然后考虑在爬坡过程中，希望拆除和新建几次。（如果以1/10来估计，那希望拆除和新建的次数不能超过10次，如果是以1/8来估计，就不能超过8次，依次类推）
• 假设我希望的拆除和新建的次数是4次。那就设置think time为爬坡时间，除以4。

测试用例5：测试在并发100w情况下，系统最大的新建能够达到多少

还是以上面的100w并发为例（AMD平台）。

假设AMD平台测试的新建是3w。以最大新建的1/10来设置当前的新建，及新建为3000.
此时的爬坡时间为：100w/3000= 334s

假设我希望在这个测试模型中，在爬坡阶段，可以有4次连接的建立和拆除。
设置think time = 334 /4 =84s

Load配置：

结果分析：

测试时，在tcp新建为9000左右，出现了失败，对应的并发为70w左右。
———这也是在测试并发的时候，有时候并发会打不上去的原因。

根据结果进行调整，进行第二轮测试

调整方式第一步：首先考虑增加think time的时间。

这可以通过减少在爬坡阶段拆除和新建的次数来达到。在这个例子中，可以将拆除和新建的次数先减少为3次（从4改为3）

对应的，将think time改为 334/3 = 112s

再次运行，发现还是出现大量失败：

通过实时统计来分析结果：

发现在新建9000的时候，维持一段时间，大概在并发90w左右，还是出现大量的失败，这说明在新建9000下的并发90w几乎达到了系统最大的处理能力。

对HTTP transactions这个图，找靠近失败附近，但是可以成功的新建值，发现是8500左右。

由于90w离100w并发还有一定的负载压力，所以我们可以考虑取 7000~8000的新建，作为在爬坡阶段，可以达到的最大的新建值。

这里，我们用7000新建来试试看。

假设还是希望在爬坡中可以拆除和新建4次，那此时的新建速率就是1750。
爬坡时间就变成了 100w/1750 = 572s
Think time = 572/4 = 142s

修改后的load和action列表如下：

再次运行，发现还是会出现少量失败：

这说明在并发100w的情况下，新建最多为每秒6000 connections。

扩展说明

在上述并发100w的情况下，新建最多为每秒6000 connections。

此时虽然客户端没有unsuccessful（说明都收到了200 ok）

但此时服务器端已经出现了大量失败（closed with error）。

从业务的层面，可以认为测试成功（可以理解为200ok，即为数据传输成功）

但是从传输层面，依然是不成功的。

这时，think time和latency的差别就会显现出来——所有配置条件不变，把think time改为latency，应该就会出现比较大的失败。

方法4：用并发的方式来测试并发，只建立不拆除

测试场景：测试最好值

方法过于简单，和实际场景的差异也比较大，本文不介绍。