本文记录曹承臻老师关于《性能测试流程》的分享笔记
什么是性能测试
通过自动化的测试工具,模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行的测试。
为什么要做性能测试(性能测试关注的四个领域)
- 能力验证:关注在给定的软硬件条件下,系统能否具有预期的能力表现,++如,在要求平均响应时间小于2秒的前提下,如何判断系统是否能够支持50万用户/天的访问量?++
- 规划能力:关注如何使系统具有我们要求的性能能力,++如,某某系统计划在一年内获客量在到xxx万,系统到时候是否能支持这么多用户量?如果不能需要如何调整系统的配置?++
- 性能调优:主要用于对系统性能进行调优,++如,某某系统上线运行一段时间后响应速度越来越慢,此时应该如何办?++
- 缺陷发现:发现缺陷或问题重现、定位手段,++如,某些缺陷只有在高负载的情况下才能暴露出来,如线程锁、资源竞争或内存泄露。++
性能测试的分类
- 压力测试:是在一定的『负荷条件』下,长时间连续运行系统给系统性能造成的影响。++但是这个负载不一定是应用系统本身造成的,比如我们经常利用脚本或工具事先吃掉服务器的一部分cpu、内存或带宽等,创造出一定的负载环境并测试被测应用系统在此环境下的事物处理能力,响应时间等等++
- 稳定性压力测试:在选定的压力值下,长时间持续运行。通过这类压力测试,可以考察各项性能指标是否在指定范围内,有无内存泄漏、有无功能性故障等;
- 破坏性压力测试:在稳定性压力测试中可能会出现一些问题,如系统性能明显降低,但很难暴露出其真实的原因。通过破坏性不断加压的手段,往往能快速造成系统的崩溃或让问题明显的暴露出来;
负载测试:在一定的『工作负荷』下,给系统造成的负荷及系统响应的时间。不关注稳定性,也就是说不关注长时间运行,只是得到不同负载下相关性能指标即可
基准测试:与一般性能测试工作的主要区别在于其更短的回归周期与直观的趋势分析,并同时为混合业务性能场景的脚本线程配比计算提供依据。
性能测试具体流程
- 需求评估:评估是否需要做性能测试
- 需要做性能测试
- 新产品,预估单台机器QPS>100
- 已上线产品:之前没做过性能测试,接入新业务后,预估QPS>100
- 不需要做性能测试
- 预估单台机器QPS<50
- 有相同实现逻辑的产品,且已经做过性能测试
- 已上线的产品,之前做过性能测试,接入新业务后,预估QPS小于之前的打压结果
- 评估QPS的方法
- 产品已经做过灰度,或上过线
- 产品未上过线,但有类似产品上过线
- 产品无类似产品,且没上过线或灰度
- 84法则:80%的请求发生在一天的40%的时间内
- 简单的结果计算(预估PV 500w):
(80% * 500w)/(40% * 24小时 * 60分 * 60秒) = 115.7个请求/秒
- 需要做性能测试
逻辑了解
- 产品、测试、开发沟通会
- 相互认识,便于后续的沟通
- 了解整个性能测试的业务逻辑(参数、可取值等)
- 了解服务器部署情况(与线上隔离)
- 了解本次性能测试的测试目标QPS及推断方法
- 了解本次打压的请求间和参数间的比例
- 邮件
- 测试目的
- 接口信息:接口地址、参数说明、返回结果
- 测试数据
- 测试机器信息
- QPS估值
- 产品、测试、开发沟通会
测试计划
- 环境搭建
- 数据准备
- 数据有效性
- 测试机的查看权限:Log位置;Log信息
- 打压比例
- 脚本编写&优化
- 录制脚本 or 手动编写脚本
- 脚本优化
- 事务
- 检查点
- 参数化
- 集合点
- 关联
- Block块
- 尽量模拟用户场景;脚本尽量简单
- 打压过程
- 服务器性能指标监控:Vmstat、top、iostat、nload、free
- 客户端性能监控:HPS、TPS、响应时间
- 打压机性能监控
- 问题定位&优化
- 全面排查:Cpu、内存、磁盘IO、网络IO。检测点报错
- 缩小范围:排除不可能的因素
- 猜测原因:开发逻辑、应用类型判断
- 数据支持:服务器log、错误log、拆分打压
- 定位问题
- 报告产出
- 时机:性能测试达到预期结果之后
- 工具:Lranalysis,nmon
- 包含信息:
- 整体结论
- 具体性能图标及对应子结论
- 测试过程中发现的问题及解决方案
- 风险备忘
- 实际打压分组
- 上线域名信息