最近项目中遇到相关性能测试不同方法产生的争议，我这就这个问题在测试环境做了个实验，得出一些指标数据间的有趣关系，供大家讨论学习：
预备知识点：
业界有个TPS ,ART和实际并发量三者间的模拟换算公式：U实际并发量=TPS*ART均值
LR有个.net4.0的计数器Request Current能反应实际的测试过程中实际的PV/s量
设置迭代pacing time情况：
请求用户数：15; pacing time:3s; 理论PV：15/3=5;
TPS:3.4; ART：1.4 Request Current:4.6 U并发=TPS*ART=3.4*1.4=4.76
请求用户数：75; pacing time:15s; 理论PV：75/15=5;
TPS:4.5; ART：1.5 Request Current:6.6 U并发=TPS*ART=4.5*1.5=6.75
请求用户数：100; pacing time:20s; 理论PV：100/20=5;
TPS:4.5; ART：1.6 Request Current:6.9 U并发=TPS*ART=4.5*1.5=7.2
1.从上面的数据可以看出实际的Request Current（实际PV/s量）几乎接近实际的并发量,而在有pacing time情况下理论PV和实际PV是随着模拟请求用户数的变化两者的差别变化也是较大，有交集但不同步变化，这个方式不可以预见实际并发量，只能通过测试结果来判断大概的实际并发量，但可以很好的控制模拟请求。
无思考时间和无迭代pacing time情况：
请求用户数：5; pacing time:无; 理论PV：5;
TPS:3.56; ART：1.4 Request Current:4.75 U并发=TPS*ART=3.56*1.4=4.98
请求用户数：10; pacing time:无; 理论PV：10;
TPS:7.69; ART1.3： Request Current:9.4 U并发=TPS*ART=7.69*1.3=9.99
请求用户数：15; pacing time:无; 理论PV：15;
TPS:8.4; ART：1.7 Request Current:14.4 U并发=TPS*ART=8.4*1.7=14.28
2.从上面的数据可以看出实际的Request Current（实际PV/s量）几乎接近实际的并发量,并且在无pacing time和思考时间情况下理论PV和实际PV和实际并发量几乎同步保持一致（我们目前大多数情况采用的都是这个方式压测）。
这里只针对一个transaction对应一个URL请求的情况，特别是接口类的。
其实两个方法都是性能测试中针对不同测试目的而使用的，各有特点。