又一款游戏项目上线测试了，深刻体会到服务端在上线前的这段日子是比较“难熬”的。因为除了原有的开发任务，还有大量的第三方接口支持、统计支持、日志分析需求等，以及服务器各种测试和后续测试BUG的排除。其中测试关系到后续服务器能否满足要求稳定运行，马虎不得。
写这篇文章的目的主要是记录一下上线前服务器测试的个人经验，如果觉得内容有不妥或者遗漏的地方欢迎交流。
测试目的
测试不是盲目的，不要为了应付而测试。简单来说测试有以下目的：
- 检测是否满足运营/商务需求；怎么理解？比如游戏上线第一天通过平台/渠道买10W的量，可以假设这10W的量在1个小时之内进来，那么登录/创角大概在1666次/秒，系统能否正常承载？
- 高压力下发现系统瓶颈；
- 高压力下发现功能BUG；
- 得到系统承载数据，为后面可能存在的重构做数据支持；
需要发报告，为了应付；
怎么测试
首先我们看看测试需要统计的数据：
[TPS（Transaction Per Second）]，[对应进程CPU占比，内存占用，带宽占用]，[消息处理最大响应时间，最小响应时间，平均响应时间，整体成功率]
测前准备：
- 客户端机器人程序，能稳定，有效的模拟客户端连接行为；
- 部署好的服务器进程，客户端进程应与服务器进程分布在不同机器；
- 对应的日志与统计脚本（用来辅助生成统计数据）；
- 知会相关人员（正在使用某某机器测试，会对正常开发使用有影响）；
测试点：
- 创建角色；
- 用户登录；
- 用户登录后，模拟重要协议并间隔发送心跳；
- 用户离线；
这里啰嗦两句何为重要协议，简单的一句话概括： 涉及消费、核心功能的协议 。如果有可能尽量覆盖到网络小包到网络大包。
测试方法：
不断的增加客户端机器人数量，可以得到TPS与响应时间的曲线，可以找到最稳定时最大TPS与最小响应时间。
一般来说TPS与响应时间的关联曲线类似下面：
通过不断的增加请求数，CPU利用率维持在80%附近，成功率能保持在99.9+%时，找到TPS与响应时间的最优值。建议在最优点的情况下，测试机能跑满半天甚至一天时间观察稳定性。
额外的工作：
观察一下机器IO，理论上来说游戏服务器硬盘、内存、网络IO不会成为瓶颈（如果使用云服务器，需要注意下公网带宽）；
观察一下存储的稳定性与时延，就现在流行的mysql、redis来说，虽然官方有完备的benchmark可以作为数据参考，同时云服务也能提供完整的高可用服务（主备或者cluster），但是依旧需要排除滥用/误用的可能；
分析测试数据
拿到测试结果后，结果可能会出现问题的几个点：
1、TPS低
这个问题需要综合分析，一般来说这种情况平均响应时间会偏高：
首先确定机器资源和测试结果的合理性，配置越高的服务器TPS测试结果越高；
然后查看一下CPU是否利用完全了；
如果有缓存队列，观察一下队列长度，作为参考数据；
最后从接入层->业务层->存储层递进式的分析响应时间，找到耗时最多/不合理的那个点；
2、CPU负载正常，成功率低
在CPU负载正常的情况下，可能存在隐藏BUG，需要重视！
3、最大响应时间数值分布偏高
查看是否CPU存在毛刺，排查一下业务是否有高负载周期逻辑或者开发语言上的GC；若没有，想办法拆分定位到具体模块，可能是部分模块不稳定导致。
4、内存占用偏高
估算一下是否合理，不合理则存在内存泄漏。
最后一些个人建议
- 游戏服务器都会由一个有经验的主程来选择服务器框架，这些框架一般都是有过成功产品，官网有benchmark可以参考，所以在其性能和稳定上不用担心太多。在有条件和时间的前提下，建议在游戏开发中期进行一轮轻量测试。因为这个时候，系统整体已经完备，模块与模块之间也相互建立联系，此时测试有助于发现问题，及早修正甚至重构。
- 请重视每一个请求失败，找到原因并分析，每个失败通常会有潜在BUG。
- 如果是分布式架构，那么至少要准备两台机器测试，整个分布式框架流程需要覆盖到。
- 大厂虽然有测试小伙伴可以帮忙，但是还是建议自己搞一搞测试，测试也是对系统感知的一个过程，这个过程稳不稳，有没有犄角旮旯的异常最好切身体会。
（全文结束）
转载文章请注明出处：漫漫路 - lanindex.com