对于压测流程的一些思考与实践
一般从收到压测需求到需求上线的整个流程如下：
压测需求确定
梳理压测点
开发压测脚本
执行压测
上述每个环节对于保障压测的质量，都是缺一不可的，但是最终决定压测是否过关的步骤，应该是压测的执行。该环节除了测开执行压测脚本，还会穿插着程序优化、修改压测脚本、复测等，是耗时最长的环节。因此，为了保证压测质量，应该尽可能给该步骤留出充足的时间。下面我们详细看下各个环节的内容，以及哪些地方是可以压缩测试时间的。
测开收到压测需求（可能是策划、功能QA、程序开单）时，大多数情况下功能还未交付测试，这个时候，如果有时间，可以先看下策划文档，对功能有个基础的了解。有时也会出现收到压测需求的时候，功能已经临近上线，为了快速了解游戏，可以找功能QA进行玩法演示。
对功能了解后，才能更好地发掘遗漏的压测点。这个时候，先不要急着去确认压测点是否真的需要执行，先列出来。之前测某游戏的家园功能时，发现一个摆组件的压力点，问了程序是否需要，程序说是老功能，不会有问题。那是不是复用的就一定不会有问题呢？事实证明，真的就出现了问题。下面我们来详细看下这个问题：
1.
需求背景
某游戏开发了全新家园系统。玩家可以使用组件在家园内自由搭建。也可以购买蓝图，进行一键装修。下面是收到的压测需求的描述：
创建1k、5k、1w个家园，导入之前的蓝图压测数据，试试看在极限存盘的情况下，服务器压力如何。此外，此功能的QA还提出了一个“不停摆放组件”的压力测试点。
2.
测试结果
作者在对需求单中的压测点进行测试完成后，对于“不停摆组件”进行了测试，发现datebase进程的内存在缓慢增⻓，最终发现是家园数据在序列化时，出现内存泄漏问题。
而家园数据序列化的接口，是个老接口，为什么之前没有出现问题呢？
一是因为该功能本身的玩法特性，组件摆放自由度非常高，玩家操作也更加频繁，因此才暴露了这个问题。二是由于这个内存泄漏，本身也是非常缓慢的，下图是此功能投放一周的数据，可以看出内存虽然有增⻓，但是还是比较缓慢的。
因此，在需求梳理阶段，可以先将压力点列出来，而不要着急确认最终是否要进行压测，避免遗漏看起来无需压测但可能隐藏问题的压力点。
3.
压测点
这里我们将压测点分为两部分，并介绍两种压测点在梳理时需要关注的点：
1、压测单中的压测点
这部分是程序/策划/功能QA比较关注的点，可以设置为高优先级。
2、自主发现的压测点
功能压力点：压测需求单中的压测点，可能是不全面的。而测开对于压力点，可能会比较敏感一些，因此，收到压测需求后，需要测开体验功能，发现遗漏的压测点。
代码压力点：进行压测的测开同学，尽量先熟悉功能，而不是一上来就直接看程序代码实现。因为如果功能不熟悉，直接看代码，可能会先入为主，跟着程序代码的思路走。直接从代码中寻找遗漏的压力点一般是很难的。
该步完成时，功能一般已经交付测试了。压测点梳理完成，可以发给程序和策划看一眼，梳理出一个优先级。然后按照这个优先级进行脚本的书写和测试。
这个步骤，我认为是最能压缩时间的点。脚本设计得好，也可以在一定程度上提高压测执行的效率。下面是本人在某游戏的压测工作中的一些尝试：
1.
快速上手流程
平时就要积累一套比较上手的流程，比如如何快速定位功能点代码：
作者所在项目组压测一般用的是服务器机器人，压测脚本中调用的接口，最好是暴露给客户端的接口。一般会有以下几种方式来获取功能接口：
通过客戶端暴露
通过协议测试平台，获取RPC名称，找到RPC实现
直接读程序代码查找
最简单的就是，找程序询问
2.
组内统一压测框架
框架内，基础功能要完善，如创建机器人、好友操作、队伍/团队操作、家园、帮会等基础操作。
基础接口，备注要完善。
脚本配置化。
为了提高脚本的可复用性，对于脚本中，可能会有变化的值，尽量抽取到配置文件中。举个简单的例子，创建机器人时，机器人等级、装备、技能等，在不同的压测需求下，可能有不同的取值。因此，将这些值抽取到配置中，如：
这样，针对不同的需求，只需要修改配置即可。而且，将配置抽取出来，也可以提高用例脚本的稳定性。只有当游戏中逻辑或接口有变更时，才需要去修改相关的用例脚本，平时对于不同的压测需求，基本都需要用到诸如创建机器人之类的用例，这个时候都可以直接复用，省去调试时间。统一组内压测框架优点：
提高代码复用率，省去重复脚本开发，可以明显提高新需求脚本的开发效率。
新人易上手。
功能复用，要复压时，如果之前是其他同学写的脚本，使用同一套框架，会更容易理解。
当压测中间遇到问题，需要其他同学帮忙时，也可以减少一定的沟通成本。
3.
用例原子化
将用例拆分成单元用例，这样需要的时候，方便用例“拼接”。
比如测某个活动，前提是需要结拜的两个人进行操作。因为加好友、结拜等好友相关的操作，都已经封装好，可以直接拿来用，在一定程度上提高了开发效率。下面是将一些基础的功能操作进行的封装的例子，这样每次有新需求时，只需要专注新功能的逻辑即可。
首先，压测时间需要尽可能保证。不充分的测试，带来的最终结果，可能是线上bug。在条件允许的情况下，应当留给压测足够的时间，对功能进行更加充分的测试。
但是如何把握压测的时间，一直是困扰我的难题。想更加充分测试，一般需要耗费大量时间。服务器性能测试还好，一般程序结构确定后，很少去大改。但是客戶端性能就比较麻烦，有时临上线前仍然会有资源的修改。作者经历过几次客户端性能压测，总结出一点点小经验：
当提交测试后，先进行一波压测，重点可以先放在服务器性能相关的内容。
当客户端资源基本确定后，再进行一波压测，这个时候，要重点看下各种类型的客户端在不同性能机器上的表现。
时间尽量拉⻓一点，比如可以晚上下班后，持续跑几小时看下情况。
临上线前，最好再回归压测一波。
推荐阅读
都看到这里了，点个赞再走吧~