压测用例设计的条件依据

近期在做游戏服务器压测部分的内容，这里做下记录。首先游戏服务器压测过程的性能策略与web接口性能压测有些区别。游戏服务器压测有两种方式，一种是通过编写逻辑机器人来实现，这种是完全免客户端逻辑的压测方式，纯粹对服务器在时间、空间资源方面的压测测试，另外一种是通过客户端协议，依赖前后端协议进行逻辑交互的测试方式。前者需要依赖于服务器相关逻辑完成机器人，后者需要依赖客户端核心通信逻辑完成协议搭建，虽说两者都需要代码编写，不过相比来说，后者相对简单许多。只需要搭建好通信等核心逻辑，便可以通过协议来完成逻辑用例编写。
目前NB项目用的是服务端编写逻辑机器人实现压测，压测前需要进行性能用例设计。用例在设计有下几个方面需要考虑。
1、压测的预期数据来源。要做压测，那么预期数据是我们能否精准测试出性能情况的关键基础。抛开数据来设计用例算是百搭。其实在我设计用例之前，都是么有支撑的，那么该如何获取数据呢？
主要依据两种数据：第一种是如果游戏还没上线的话，那么可以依据与同类已经上线的产品，通过该类产品的数据获取到线上各个系统的峰值数值，在预期目标中以2倍左右数量来设计。第二种是该游戏已经上线并运行过一段时间或者经过删档测试内测或者公测阶段，通过线上的峰值数据*2来设计预期数据。
2、分析系统的重要分级。系统的重要等级区分也可以 同类产品或者线上、内测（公测）期间服务器的各个协议调用频率数，协议处理时间长短来确定重要系统场景。协议调用频率这些数据需要程序进行打log记录。
如果没有线上数据、也没有竞品数据的话，那么就依据该游戏自身的核心系统、核心系统的依赖系统以及涉及到全服参与的系统，比如世界聊天、搜索好友、世界boss等系统。

3、确定性能参数。性能参数的确定需要根据压测的类型来确定，要看是客户端协议类型压测还是服务器机器人类型压测，前者经过服务器处理、数据库处理、网络传输；而后者经过服务器处理、数据库处理两个阶段，没有网络处理过程。据此，我整理的性能参数有磁盘IO，QPS（每秒请求数）、内存占比、CPU占比、CPU load Average、CPU load Average时间、CPU占比在80%以上的时间、SQL查询时间、每秒事务数tps、平均请求响应时间、吞吐率这几个参数。
4、设计性能场景，性能场景可以分为单场景设计与混合场景设计（全链路）两种，这两种中前者是测试在并发情况下服务器处理某个场景逻辑的性能状况，后者测试并发下服务器在比较真实的混合场景处理下的性能状况。
5、设计测试的方式，需要设计的压测方式有容量测试、单场景测试、混合场景测试、稳定性测试。容量测试主要为了预估服务器最大负载程度和扩容预估，单场景测试某个系统的瓶颈，混合场景也是验证核心系统间的性能瓶颈，稳定性测试为了发现系统是否存在内存泄漏、偶现的问题、概率性等问题。
6、测试用例设计，测试用例根据测试方式进行具体的用例设计。但场景情况下，要设计好并发梯度，递增规则等。混合场景要设计好各个场景的占比，并发人数、持续时间等。