【Performance】04.性能测试技术磨合篇之性能测试场景设计
1. 前言
性能测试场景设计是执行性能测试的基础,如同功能测试一样,需要先制定测试计划、确定测试范围、测试方法、测试目标、测试介入/退出条件等内容,不至于在执行测试的过程中一头雾水,这样的测试工作才会更有价值。
2. 场景设计
性能测试的场景设计,最直接的参考来源就是项目的技术方案或需求规格说明书,文档中列出了用户对于该项目的性能指标需求,咱们可以简单划分成以下三种场景类型。
序号 | 场景分类 | 示例 |
---|---|---|
1 | 单业务场景 | 用户登录、文件上传/下载接口等 |
2 | 综合业务场景 | 用户登录+用户开户+用户销户+用户移机+用户改套餐等 |
3 | 稳定性场景 | 7*24小时不间断运行等 |
2.1. 单业务场景
以文件上传接口场景为例,某项目的该性能需求描述如下:
支持同时100个用户同时上传不大于10M的文本、图像以及pdf文件
2.2. 综合业务场景
综合业务场景的设计并不是简单地将单业务场景合并在一起,它还需要考虑综合业务场景的总并发数、分配给每个业务的并发数、并发用户数的启动策略、综合场景的运行时长等因素,这些因素的不同,会对性能测试的结果产生不同的影响。
这些场景因子的配置策略,主要是参考用户真实环境,然后进行适当的调整,测试出来的结果也才会更加接近于真实环境。
例:某购物平台的某时间断内各业务请求的日常在线用户和促销日在线用户占比如下:
序号 | 业务名称 | 日常在线用户占比 | 促销日在线用户占比 |
---|---|---|---|
1 | 商品查询 | 36% | 40% |
2 | 商品加购 | 20% | 24% |
3 | 订单提交 | 16% | 18% |
4 | 订单付款 | 12% | 12% |
5 | 订单查询 | 12% | 4.5% |
6 | 用户信息更新 | 1% | 0.5% |
7 | 商品退换货 | 3% | 1% |
- 并发用户数
JMeter线程组配置元件中,并发用户数(Number of Threads)
属性用来控制JMeter模拟多少个线程来执行测试,一个线程代表一个用户,当确定好总的并发用户数时,就可以参考在线用户占比,为单个业务场景进行分配并发用户数了。
- 线程启动时间
JMeter线程组配置元件中,启动时间(Ramp-up preriod)
属性用来指定JMeter花费多长时间来初始化这些线程,当启动时间配置太小时,会使得JMeter在启动测试的短时间内初始化比较多的线程数,可能使得还未执行到业务场景时,服务器就已经达到饱和状态;当启动时间配置太大时,就可能存在最后一个线程组还未启动的情况下,第一个线程就已经完成测试了,这类测试结果并没有满足并发用户数的要求。
一般地,线程启动时间合理的规则就是:使线程启动过程时的点击率接近平均点击率,例:平均点击率为10次/秒,指定的线程数是200,那么比较合理的线程启动时间就是:$\frac{100}{10} = 20$。
- 运行时长
JMeter线程组配置元件中,运行时长(Duration)
属性用来指示JMeter为线程组配置一个定时器,当线程组运行满足指定的时长后,中断所有线程,测试停止。
运行时长的配置不宜太短,否则样本空间不够丰富,导致测试结果不准确;同时也不能够太长(压力测试除外),随着时间的推移,当样本空间达到一定级别后,测试结果可能会趋于稳定,此后的样本数据结果不会对最终测试结果产生较大的影响。
3. 总结
以上只是性能测试场景设计中的冰山一角,还有线程的循环控制配置、启动延迟配置、逻辑控制器的循环控制配置等等,需要结合实际性能测试点和真实环境进行分析,通过合理且巧妙地配置各项参数,来满足测试场景的要求。
总而言之,无论是单业务场景,还是综合业务场景性能测试的场景设计,都不是单纯的编写脚本、组合脚本,更多的是要从用户的角度出发,场景符合用户的行为习惯,以此来模拟更真实的运行环境。
性能测试工具JMeter合集
【Performance】01. 性能测试技术初探篇之性能测试介绍
【Performance】02. 性能测试技术初探篇之常用性能测试工具
【Performance】03. 性能测试技术初探篇之 JMeter 工具使用
【Performance】04. 性能测试技术磨合篇之性能测试场景设计
【Performance】05. 性能测试技术磨合篇之脚本录制和调试
【Performance】06. 性能测试技术磨合篇之脚本执行和结果分析
【Performance】07. 性能测试技术历练篇之性能监控工具
【Performance】08. 性能测试技术历练篇之性能分析神器 JProfile
【Performance】09. 性能测试技术历练篇之 Java 诊断工具 Arthas