我们有时候会遇到玩家吐槽为什么自己玩的游戏是土豆服务器，或者新游戏上线后长时间处于排队无法进入，又或者是总会出现异常的掉线等等情况，导致玩家的游戏体验变差。在这个时候，愤怒的玩家就会质问游戏研发：“难道你们就不做测试的吗？！”
那么对于游戏测试来说，要如何保证游戏服务器的稳定性呢？对于游戏服务器压测，和传统的性能和压力测试有哪些区别？这回我会分几次来和大家简单分享一下我对于压力测试工作的理解。
压力测试需求来源
不论是什么类型的测试，面对被测对象，我们首先要分析测试需求的来源，才能更好的理解和执行接下来的测试内容。对于压力测试而言，要从以下两个方面来关注需求：
一、技术层面
1、确认服务器架构：新游戏的开发架构和最终上线架构可能是存在差异的。这个差异的来源可能是由于策划的需求变更，也可能是上线运营的稳定性考量，当然最重要的，是需要根据压力测试结果来调整正式的服务器部署情况。
2、单组服务器压力：对每个功能服务器单独进行压测，确定每类功能的最大承载能力和高负载压力。
3、数据传输和存储：查看极限状态下的消息传递和数据存储是否正常。
4、发现bug：尽早发现服务器的bug以及性能瓶颈。
二、设计/策划层面
1、确定单服人数的最高承载能力：确认单服承载人数可不可以满足正常运营需求，同时也可以给出运维准备线上服务器数量的一个标准。
2、通过各类功能服务器的负载情况来指导功能玩法的调整或设计。
压力测试目标基准衡量方法
在确认了压力测试需求后，我们就需要针对本次测试制定一个合理的目标基准，用来衡量测试结果是否符合预期，能否给出测试通过的结论。
一、实际使用场景
游戏服务器的承载能力当然是越高越好。但对于压力测试来说，目标值却不是越高越好。一个活跃人数50万的游戏当然不需要并发500万级别的服务器性能，我们不能把自己的测试当做是在给春晚抢红包做压测，那样是没有意义的。所以还是需要结合自己的实际场景来制定合理的目标值。
对于整体的游戏服务器压测来说，最需要考虑的实际场景就是运营层面的单服承载人数（PCU）和预期活跃用户数量（DAU）。当这两个目标确认下来后，我们可以用这两个值的1.5倍来作为自己压测峰值人数的参考值。
对于单个功能的压测来说，则要考虑该功能设计上的适用范围，也是以同时使用此功能的最大人数的1.5倍来作为自己压测的参考值。
二、瓶颈/限制点
除了根据运营需求设定目标外，还要考虑一些服务器本身存在的瓶颈或限制。
这里主要指以下两点：
- 平台服务器的限制。这里的平台指的是独立于游戏架构外的平台，如账号平台、支付平台等等。比如账号平台的最大并发量是10000 TPS，那我们在测试游戏登录过程中就不需要考虑10000以上的并发，因为即便游戏服务器可以承载更高，也无法突破平台的限制。这样的测试就是无效测试项。
- 游戏功能玩法的限制。这个就是指的玩法人数对于我们设置目标值的限制，上面已经说过，不再复述。
绘制服务器架构图
大家应该都学过UML图的绘制方法，所以基础绘制这里就不说了。我只提两个对于游戏架构图来说比较重要的部分吧。
基本要求：单台服务器需要单独表示、服务器之间通信的连接线尽量不要交叉、连接线的箭头需要指向被动连接的一方、需要画出游戏和平台服务器之间的交互；
进阶要求：标出内外网端口，且尽量将公网端口和私网端口分开展示、标出服务器基本配置信息。
开发架构图和运维架构图的区别？
压力测试除了要完成服务器性能的相关测试外，最重要的一个目的就是要把简单的开发架构图转化成可供运维执行的上线架构图。
对于开发来说，他们的关注重点在于功能实现。但对于测试来说，需要通过压测结果，来考虑哪些服务器是可以供全服公用的、哪些服务器是可以平行扩展的、哪些服务器由于是单点而存在压力风险，这些都需要画在你的架构图上面。
编写压力测试计划
根据以上提到的内容，我们要写出一份可供执行的测试计划。主要包含几个内容：
- 第一是分解被测对象，一般以功能服务器为目标；
- 第二是根据测试需求和具体衡量标准来划定测试目标值；
- 第三是测试环境部署计划；
- 第四是测试周期和进度追踪。
源自公众号 游戏测试那点事儿