性能测试场景浅析

Posted 2020-06-17

性能测试过程中，目标不同，需要选择的性能测试场景也有很大的差异，今天以HyperPacer为例，简单说说并发测试、负载测试、压力测试到底都是什么怎么个含义。

 

并发测试

所谓并发测试就是模拟一群人同一时间做事。在性能测试工具还未普及的暗黑岁月，并发测试都是一群人盯着电脑，一个人喊开始，大家便在同一时间点开始操作的那种，点完之后还得每个人看响应，报时间，一群人玩儿的不亦乐乎，做个性能测试顺道还能交流交流，联络联络感情，看着挺好玩，但效率上保证不了。而且并发量不是非常大这样还能玩的起来，并发量要是成百上千的话，就没法这么弄了。

之后有了性能测试工具介入之后，这种好玩的场景便销声匿迹了。并发测试开始了新的篇章，不会有没反应过来慢半拍的同事，都是一水儿的稳准狠。还能对并发操作进行精细的调整控制，以便更好的模拟真实的场景。

瞎扯的说那么多，现在上干货。并发测试就是对被测系统的并发处理能力进行考察的一种测试手段，一般都是看在绝对并发的情况下，系统能承载多大的并发量，或者在一定的并发量下，系统的响应时间是否是可接受的。

由于是绝对并发对服务器的瞬时压力非常大，性能测试人员在开展并发性能测试之前，一定要调查清楚实际的测试需求是不是真正的绝对并发，绝对并发量到底有多少。有时候需求人员在不知道确定概念之下，把相对并发的那种场景也按绝对并发说，往往得到的结果是系统不能有效支持，而实际却是绝对并发场景的含义两边理解的不一样。

举个形象的例子，12306春运期间的放票，一到放票开始，N多的用户在同一时间点对服务器发起买票的请求。比如8:00放票时段，有100万用户对12306发起了买票的请求。由于各自请求经过的路由不完全一样，到达服务器时的顺序也是有先有后。实际同一时间点对该服务的压力只有100万中的一部分,假如是5万个用户请求，剩下的略慢到达的95万用户请求，才陆陆续续到达，都在后面排队等待处理。此时票务处理过程第一波的绝对并发就不是那100万发起请求的用户数，而是真正得到处理的那5万个的用户，等这5万个之中有处理完成的，再放一部分用户的请求进来处理。（由于不是铁路系统内相关系统的操作人员，这个只是为了举例而假想的场景，知情人士可一笑而过）。这其中的5万用户才是票务处理系统实实在在的绝对并发用户量，而不是实际参与的100万都要算进来。

需要做并发测试时，在LoadRunner里有集合点，在HyperPacer里叫做同步定时器，都是对这种场景模拟时用到的同一个东西。作用是当累积到的用户量符合释放条件时，就所有用户一起释放，模拟大家一起操作的场景。如果不加集合点/同步定时器的话，则是早到的早开始，晚到的晚开始，达不到绝对并发的那种效果了。

如果需要测试的场景不是严格意义上的绝对并发，而是在一定的时间范围内进行释放，则可在同步定时器后面再加泊松随机定时器或高斯随机定时器一类的元件来模拟。

 

压力测试

压力测试是在接近用户承载量极限以下一些（还不足以把系统压垮的用户量），较长时间不间断执行的性能测试，是检查系统稳定性，系统性能瓶颈的一种常用场景。

由于性能测试通常都要尽可能模拟实际用户使用场景，在压力测试过程中，用户的加载策略，操作方式等就需要尽量模拟真实情况下的操作用数量和上下线策略。比如在早上半个小时内，会有500个用户登录，完成登录后就一直操作；下班前15分钟，则陆续退出系统。当然实际的系统的用户登录上线和下线不一定那么规律整齐划一。可通过不同分组设置相应的用户数量、采用不同延时，不同的持续时间来模拟。关于用户初始和用户结束之类的加载策略由于超出了本文的范围，此处一笔带过，将来有机会再表。

 

负载测试

负载测试和压力测试经常有人弄混，出个加载策略图和前一个场景的加载策略图比较一下就明白了。

 

所谓负载测试，从图上直观上看就是一批一批的加用户，待到当前在线用户执行稳定后，再加下一批的用户，像这样不停的持续加压，直至系统性能明显下降或系统崩溃为止。是测试系统用户上限，查找系统性能瓶颈的重要手段。通常在还不知道系统能承载多大业务量的情况下，为找到用户承载量极限或为了快速定位系统性能瓶颈时，会采用此种方式进行测试。

 

总结

虽然性能测试工具提供了多种的性能测试场景来做性能测试过程的调度，但在实际性能测试过程中，依然是按照实际性能测试需求为准，尽量模拟用户的实际行为。在充分了解了性能测试目标的情况下有的放矢，从容选择。而不是无论那种性能测试需求，都先用负载测试的场景测到系统崩溃再说。