一、性能测试流程

  二、测试环境与生产环境

Loadrunner性能测试需求分析、测试计划20240823更新

  尽量模拟生产环境,模拟硬件比较难,可以等比模拟,比如生产是4台服务器,测试环境可以有2台服务器;

  模拟软件,尽量保证所有的软件版本位数都要一样;

  使用负载均衡模拟共享中心的应用 将服务器都放到同一个机房,这样可以最大限度避免网络问题,一般都会在同一个机房。

  三、性能负载模型图

  随着虚拟用户数量的变化,吞吐量、响应时间、资源利用率的变化如图:

  从图中可以看出最佳用户数,之后随着用户数的增加,资源利用率和吞吐量、响应时间趋于平稳,达到最大用户数时,资源利用率偏高、吞吐量下降、响应时间也在变大。

  要进行多次负载测试和压力测试可能才能得出最佳用户数,不过也不是绝对的要结合业务和实际情况去得出最佳用户数。

  四、性能测试需求分析的目的

  1、找出TPS每秒处理事务数、并发数(最佳用户数、最大用户数)、硬件相关指标(CPU、内存、磁盘、网络)

  2、分析用户使用行为,分析业务量,为估算做准备,比如双十一零点抢购等业务量爆发等用户行为;或者日常某些时间点用户业务量比较多等

  3、分析出测试点,要分析哪些业务要纳入性能测试范围,比如一个订票系统,订票就会比较容易发生集中购买的性能问题,就是找出系统中的哪个业务点是比较容易会用到并且会引发性能问题。

  五、被测试系统分析

  1)跟产品、运营、开发沟通出性能需求,比如某个模块的响应时间要小于几秒,2-5-8是业界经理理论,2秒是快的,5秒是可以接受,8秒是难以忍受的。

  2)与开发沟通系统的处理能力,资源占用率,数据库的访问量等

  3)可以拿历史日志和同类产品的分析哪个时间段用户量业务量比较多,哪些业务用户用的比较多,一般系统都会有大数据埋点,通过大数据分析出用户的行为得出哪些业务在哪个时间段会比较集中

  4)根据80/20原则进行估算处理能力-TPS每秒事务数:

  比如有一个需求是这样的,某邮箱去年全年处理邮件约100万条,考虑到3年后可能递增到每年200万条。假设每年处理量集中在8个月,每个月20个工作日,每个工作日8小时,试问采用80/20原理估算系统服务器高峰期的处理能力应该达到什么水平,就是TPS大概是多少?

  采用80/20原则,80%业务会集中在20%的时间完成;

  200万条/8个月/20天=1.25万条记录,计算出每天处理的数;

  (1.25万条/8小时20%/3600)80%=1.736条记录,8小时*20%是一天中有20%的时间也就是1.6小时会集中处理业务,再除以3600计算出秒数,1.736就是每秒处理的条数;

  5、要重点测试哪些模块呢,拿一个洗车业务举例:

  用户常用功能,比如登录

  数据流转复杂或者频繁的地方,比如购买洗车订单,查看洗车列表,到确认订单,到支付订单,

  发生频率非常高,比如查看洗车列表,查看洗车价格

  关键程度非常高

  资源占用非常严重,比如返回洗车列表,查询数据库

  关键的接口,比如洗车列表排序、距离定位等接口

  1、项目背景

  2、测试目的:要测试什么指标

  3、测试计划:人员安排,时间规划

  4、测试环境:软件版本、硬件环境

  5、测试策略:脚本设计策略、场景设计策略

  5.1测试点的提取

  5.2并发数与预期指标预估

  5.3通过准则

  5.4场景用例

  6、测试数据准备

  7、测试工具说明

  8、测试限制与风险

  也可以参考:

  1、日志策略

  Loadrunner的日志在调试时可以打开,在执行时只输出错误日志就行。

  java日志设置成warn,避免大量打印log对性能结果的影响,不过也要根据实际的程序去设置,以免在测试时是warn级别,到生产上是info级别或者debug级别。

  2、前台缓存策略

  性能测试时要模拟没有缓存的情况,所以要设置每一次都是新用户,清除缓存

  3、场景设计策略

  先单场景,后混合场景,确保每个性能瓶颈都得到调优;

  单场景可以详细到某个页面,某个接口等;

  在单场景优化完后,按照一定比例对各场景进行组合,测试整个应用系统的总体性能表现。

  linux服务器想在loadrunner中监控需要安装rpc,如果不在loadrunner中监控,可以在linux中安装nmon监控工具,性能测试时使用nmon监控linux服务器就可以了。