分享一个江湖小辈如何参透性能测试这本武功秘籍的心路历程，适用于刚踏入性能测试江湖里的小白，一起来一探究竟。
【第一幕】该不该预测一个初始值/p>
第一次真正接触性能测试是在邮箱大师组，当时是要去对“邮件撤回”的接口进行性能测试，2017年6月25日接到任务，二话不说开始准备了起来。对jmeter速成之后，拿着wzprecall的脚本就开始开压。
那么第一个问题来了：
我：我应该怎么压是说有没有一个初始的值可以入手去压..
我：YW大神经验丰富，是否可以预测出这个初始值/p>
YW大神：不能。
我：…
YW大神：如果我都预测出来了，那还需要性能测试做什么/p>
我：哦…
YW大神：两个方法：要么和产品交流拿到实际的用户量数据，要么自己想办法。
我：好嘞。
屁颠屁颠跑去找产品同学，在我的三寸不烂之舌以及一箩筐解释下，产品同学终于听懂了，但是回答是：我不知道，我真的不知道，我真的真的不知道。。。怀着复杂的心情我翻开了YW大神的武林秘籍第一页，当时有这么一张图：
经过初探武林秘籍形成练法心得之后，开始了自己的第一层修炼，数据如下：
上图可以看到一个用户的执行一次的响应时间，然后可以慢慢递增。然后我将线程数逐渐增加的同时，有了以下的测试数据：
数据中看到：用户量在30到40之间基本饱和，withdrawQuery请求吞吐量基本在16.5/s。
测试数据看起来已经有点样子也得到了结果，拿着数据我找了YW大神。
【第四幕】控制吞吐！控制吞吐！控制吞吐！
YW大神：吞吐20都不到，这个是不可能的。
我：…
YW大神：注意控制吞吐！
测了这么多的数据，发现很多时候的步骤都是自己不断尝试不同的线程数，在有很多未知的情况下去试探，这种方法耗时耗力，而且最后得到的数据并不能说明问题。那么另一种方法就是完全通过定时器来控制QPS，这就类似于控制变量法，将吞吐控制之后，如果实际的吞吐达到限制的吞吐表示现在性能合理，且有上升空间，如果随着线程数的增加限制的吞吐和实际吞吐差别很大，那么恭喜你，你找到了这个接口性能的天花板中的一板。Jmeter提供了一个非常有用的定时器，称为ConstantThroughputTimer(常数吞吐量定时器)，该定时器可以方便地控制给定的取样器发送请求的吞吐量。
Targetthroughput(insamplesperminute)：目标吞吐量。注意这里是每分钟发送的请求数。20QPS，这里的值应该是1200。
CalculateThroughputbasedon：有5个选项，分别是：
Thisthreadonly：控制每个线程的吞吐量，选择这种模式时，总的吞吐量为设置的targetThroughput乘以该线程的数量。
Allactivethreads：设置的targetThroughput将分配在每个活跃线程上，每个活跃线程在上一次运行结束后等待合理的时间后再次运行。活跃线程指同一时刻同时运行的线程。
Allactivethreadsincurrentthreadgroup：设置的targetThroughput将分配在当前线程组的每一个活跃线程上，当测试计划中只有一个线程组时，该选项和Allactivethreads选项的效果完全相同。
Allactivethreads(shared)：与Allactivethreads的选项基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程上一次运行结束后等待合理的时间后再次运行。
Allcativethreadsincurrentthreadgroup(shared)：与Allactivethreadsincurrentthreadgroup基本相同，唯一的区别是，每个活跃线程都会在所有活跃线程的上一次运行结束后等待合理的时间后再次运行。
在控制吞吐之后，得到的数据有模有样：
总结：
用户量为40的时候，平均响应时间基本在400ms左右，此时吞吐量在1500/min(25/s)，吞吐量还在上升阶段。
用户量到55~65阶段，吞吐量基本达到峰值2076/min(34.6/s)，用户量在65的时候，响应时间开始快速上升。
用户量在70+以后，吞吐量急速下降，相应的响应时间也在75的时候达到了1000ms+左右。
通过以上评估，压力
当用户>70的时候，为buckleZone阶段。
欢迎加入 51软件测试大家庭，在这里你将获得【最新行业资讯】，【免费测试工具安装包】，【软件测试技术干货】，【面试求职技巧】… 51与你共同学习，一起成长！期待你的加入： QQ 群： 755431660
相关资源：最强劲的加密软件TrueCrypt_Setup_7.1a_最强劲的越野车- 络攻防…
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！