• 很多资深测试工程师对性能测试存有误区
  • 发布于 2个月前
  • 81 热度
    0 评论

最近找我咨询性能测试问题的同学挺多,见识了不少案例,发现很多同学对性能测试依然存在很多理解的误区,即使是一些在测试岗位工作多年的资深工程师,依然存在这种情况。


市场上关于性能测试的专业书籍不少,专业的课程和免费的学习资料以及技术文章也有不少干货,但部分同学依然是从来不主动学习,遇到问题才想起来临时抱佛脚,这样其实对技术提升不怎么友好。


性能测试,说简单也简单,因为实施性能测试的方法和流程和正常的功能测试没太多区别。说难也难,因为要想正确的开展性能测试并达到目标,对技术广度和深度都有一定的要求。


这篇文章,我会列举一些常见的理解误区,并对此做出解释,希望能对测试同学们有所帮助。

误区一、性能测试就是工具+高并发
这是很多初学者最容易犯的一个错误,认为性能测试就是找个工具模拟高并发,不断加压然后看监控统计结果,其实不然。举一个在技术交流群看到的例子:单接口调用没问题,用JMeter调试系统返回code:500。遇到这个问题该如何处理呢?
一般来说,当请求响应返回的状态码为500时,可以判断请求是通的,只是返回的响应体不是我们预期的结果。这个时候可以从这两点出发来分析问题:
1、查看被测服务日志,看详细的请求和响应信息,以及报错的堆栈信息。

2、对比单接口调试的请求内容和用JMeter组装的请求内容,是否存在差异。


为什么要对比JMeter的请求内容呢?因为它模拟请求的原理,是自己定义请求头和请求的body主体,和postman等测试工具还是存在一定差异的,很多时候就是因为些许差异导致请求失败。


对于性能测试的初学者,我建议在学习压测工具之前,先对网络协议如HTTP/TCP协议有一定的了解,否则只是学习压测工具的使用方法,很容易被卡在性能测试的门槛之外。

误区二、性能瓶颈一定要压到资源耗尽

即使是对性能测试有一定实践经验的测试同学来说,这个误区依然是错误高发区。前几天有同学告诉我,他每次压测都要压到服务器资源耗尽才认为到了瓶颈,但有时候会发现资源使用率不高但已经压不上去,RT不断增高的现象,很困惑。原因就是走入了如副标题所述的误区。


所谓的性能瓶颈,是没有定量标准的,是否存在性能瓶颈,取决于性能目标如何定义。比如某个业务,希望能支撑200并发,并且响应时间不能超过50ms,这个时候如何判断是否存在性能瓶颈呢?


从需求的角度来看,通过压测并监控观测,是否能达到预期的指标。从技术的角度来看,还要考虑系统稳定性以及系统性能的冗余能力,那就加上成功率99.99%和CPU%<40%。


合并一下,性能指标就是:TPS>200,99RT<50ms,请求成功率>99.99%,CPU使用率<40%。只要压测监控到的性能表现满足这些要求,就可以认为满足性能预期,不存在性能瓶颈,否则就要针对性分析定位和优化。


所谓性能瓶颈,是没达到性能预期指标,而压测监控到的诸如TPS之类的技术指标,只是反映了系统当前的性能表现,这是现象,不是瓶颈。

除了上述两个测试同学的理解误区之外,性能测试对技术的广度和深度都有一定要求。


首先,你要对被测系统和请求链路很熟悉,这就要求你熟知被测系统的系统架构和请求调用关系;其次,要对业务有很深入的理解,并且和业务以及研发团队有良好的沟通,这样才能得到比较明确的性能指标;最后,还要对常见的各种中间件如Redis/MQ比较了解,且对网络协议和操作系统有基本的了解,否则请求报错查看日志都搞不定,就很难将性能测试工作开展下去。


再扩展来说,性能测试是很吃经验的,很多所谓的性能瓶颈其实并不难定位,但经验的价值就在于可以让你快速筛选出大概率存在问题的部分,并且快速验证和优化。


对新手来说,打好技术基础,熟练掌握工具使用,深入理解业务,再找到好的性能测试资料深读,就能快速掌握性能测试并应对大多数日常的性能测试工作。
用户评论