最近找我咨询性能测试问题的同学挺多,见识了不少案例,发现很多同学对性能测试依然存在很多理解的误区,即使是一些在测试岗位工作多年的资深工程师,依然存在这种情况。
市场上关于性能测试的专业书籍不少,专业的课程和免费的学习资料以及技术文章也有不少干货,但部分同学依然是从来不主动学习,遇到问题才想起来临时抱佛脚,这样其实对技术提升不怎么友好。
性能测试,说简单也简单,因为实施性能测试的方法和流程和正常的功能测试没太多区别。说难也难,因为要想正确的开展性能测试并达到目标,对技术广度和深度都有一定的要求。
2、对比单接口调试的请求内容和用JMeter组装的请求内容,是否存在差异。
为什么要对比JMeter的请求内容呢?因为它模拟请求的原理,是自己定义请求头和请求的body主体,和postman等测试工具还是存在一定差异的,很多时候就是因为些许差异导致请求失败。
即使是对性能测试有一定实践经验的测试同学来说,这个误区依然是错误高发区。前几天有同学告诉我,他每次压测都要压到服务器资源耗尽才认为到了瓶颈,但有时候会发现资源使用率不高但已经压不上去,RT不断增高的现象,很困惑。原因就是走入了如副标题所述的误区。
所谓的性能瓶颈,是没有定量标准的,是否存在性能瓶颈,取决于性能目标如何定义。比如某个业务,希望能支撑200并发,并且响应时间不能超过50ms,这个时候如何判断是否存在性能瓶颈呢?
从需求的角度来看,通过压测并监控观测,是否能达到预期的指标。从技术的角度来看,还要考虑系统稳定性以及系统性能的冗余能力,那就加上成功率99.99%和CPU%<40%。
合并一下,性能指标就是:TPS>200,99RT<50ms,请求成功率>99.99%,CPU使用率<40%。只要压测监控到的性能表现满足这些要求,就可以认为满足性能预期,不存在性能瓶颈,否则就要针对性分析定位和优化。
除了上述两个测试同学的理解误区之外,性能测试对技术的广度和深度都有一定要求。
首先,你要对被测系统和请求链路很熟悉,这就要求你熟知被测系统的系统架构和请求调用关系;其次,要对业务有很深入的理解,并且和业务以及研发团队有良好的沟通,这样才能得到比较明确的性能指标;最后,还要对常见的各种中间件如Redis/MQ比较了解,且对网络协议和操作系统有基本的了解,否则请求报错查看日志都搞不定,就很难将性能测试工作开展下去。
再扩展来说,性能测试是很吃经验的,很多所谓的性能瓶颈其实并不难定位,但经验的价值就在于可以让你快速筛选出大概率存在问题的部分,并且快速验证和优化。