上两篇文章中，我们介绍了并发测试的方法1和方法2：
这篇文章我们介绍并发测试方法3：用并发的方式来测试并发，只建立不拆除——测试至始至终都不拆除
相关阅读：
首先我们来回顾一下并发测试的四种方法
并发测试的方法
并发有4种测试方法。主要的差异点就是在并发测试的时候，是否会有连接的拆除。简单总结如下：
- 方法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/1500 = 667
Think time = 667/4 = 167测试成功，如下图所示：
这说明在并发100w的情况下，新建最多为每秒6000 connections。
扩展说明
在上述并发100w的情况下，新建最多为每秒6000 connections。
此时虽然客户端没有unsuccessful（说明都收到了200 ok）
但此时服务器端已经出现了大量失败（closed with error）。
从业务的层面，可以认为测试成功（可以理解为200ok，即为数据传输成功）
但是从传输层面，依然是不成功的。
这时，think time和latency的差别就会显现出来——所有配置条件不变，把think time改为latency，应该就会出现比较大的失败。
方法4：用并发的方式来测试并发，只建立不拆除
测试场景：测试最好值
方法过于简单，和实际场景的差异也比较大，本文不介绍。