小游戏压测如何做，看这篇即可！

lsekfe

压测在很多项目中都有应用，是测试小伙伴必备的一项基本技能，刚好最近接手了一个小游戏的压测任务，一轮压测下来，颇有收获，赶紧记录下来，与大家分享一下，希望大家能少踩坑。
　　一、压测的时机
　　压测的时机很重要，如果时间选择不对，可能会做无用功，简单总结下5个常见的压测场景：
　　1、活动上线前压测
　　活动类的项目，常规操作是在活动上线前，对系统进行一个摸高压测，根据预估的流量，对系统配置进行优化调整，保证活动期间，系统能正常运行。本次的小游戏项目，就属于活动类，在上线前进行了压测。
　　2、项目上线稳定后，对系统评估
　　系统上线后，随着用户量不断增加，承受的压力会越来越大，为了让系统在未来的时间内稳定运行，需要通过压测对系统进行评估，以调整配置或优化接口，来充分应对不断增长的用户量。
　　3、项目研发后期，对系统的检验
　　在项目后期，由于领导或团队的要求，需要对系统的稳定性做校验，保证系统短时间内流量陡增时能稳定运行，可以给系统的部署提供参考。
　　4、线上出现性能问题
　　有些项目为了抢占市场，节省时间，完成了基本的功能就上线了，没有做压测，当用户突然增加出现线上性能问题后，反过来做压测，这种情况的风险是很大的，不推荐。
　　5、合作方要求
　　有些合作方对性能有明确的要求，并且写进了合同，这种情况下就必须去做压测了。
　　二、压测过程
　　可做压测的工具很多，业界用得比较多的是Jmeter，今天我们就以Jmeter为例，分享下做压测的6个步骤：
　　1、编写压测脚本

　　①添加HTTP请求
　　填写请求方法，路径，请求参数

　　②添加HTTP信息头管理器
　　有些请求不要添加，使用默认值，有些要添加，与开发同学确认即可，注意请求体为BodyData时，大部分情况下需要添加请求头Content-Type: application/json

　　③添加响应断言

　　④添加断言持续时间
　　根据项目情况确定，一般设置为60s

　　⑤评估是否需要限制吞吐率（添加Constant Throughput Timer )
　　有时候为了模拟真实的使用场景，尽量保证线程组设置的并发数与聚合报告中的吞吐率一致。

　　⑥查看结果树
　　开始压测时勾选仅错误日志，便于查看报错信息，调试时需要查看所有日志，保证接口脚本能正常调通。

　　⑦聚合报告
　　2、准备压测服务器（测试服务器/线上服务器）
　　有些项目需要在测试服务器上进行，而有些则直接在线上服务器进行，例如还未上线的活动类项目，就可直接在线上压测，不同的服务器配置，压出来的结果是不同的。
　　3、开始压测
　　提前与开发和产品同学确认并发量，如果项目有明确的用户数，比如500用户，那就直接用500并发或者稍稍高于500的并发，如果项目没有明确的并发，可根据当前项目情况酌情施压。在压测过程中，注意观察服务器资源消耗情况，例如cpu，内存，磁盘，网络等以及服务器Nginx的日志。观察服务器的压力，如果在测试环境，可以在服务器上装个nmon工具，可实时查看服务器的资源消耗情况，如果是线上环境，一般不能直接远程服务器，可以找运维同学要链接，比如这次运维同学直接给了夜莺（Nightingale）的链接地址，登录可直接查看服务器的资源消耗情况。查看服务器的Nginx，主要是看是否有报错信息以及请求是否打到了测试服务器上。
　　4、记录结果
　　主要包括服务器配置，压测场景、Jmeter聚合报告以及接口报错情况，服务器资源监控等。
　　①服务器配置
　　测试环境机器配置：单台机器配置为6核6G内存
　　线上环境机器配置：两台Web应用程序服务器负载均衡，一台数据库服务器，每台配置为6核8G内存
　　②压测场景
　　打开红包+猜测红包大小+获取红包状态接口（写上接口的URI）
　　Iv1/apilred
　　③聚合报告
　　1s起1000个线程数，循环次数500次，压测时间：2023/01/17 15:00~15:05（记录压测时间是为了在夜莺（Nightingale）上查看时间段内的资源消耗情况图）

　　主要关注平均响应时间Average，Error%，Throughput
　　④测试结果
　　查看结果树，将报错的类型全部列举出来，例如存在连接超时的报错：Connection timed out

　　5、提性能Bug和验证Bug
　　6、发送压测报告