对于压测流程的一些思考与实践！

每个上线功能都存在压力点，但由于时间和人力的限制，无法对所有压力点进行全面压测。所以，要怎样才能在有限的时间内，提升我们的压测覆盖度呢？这是我们一直在思考和尝试解决的问题。本文分享了作者在压测方面的一些小想法，希望能对提升压测覆盖度有积极作用。

01、压测流程

一般从收到压测需求到需求上线的整个流程如下：

1. 压测需求确定

2. 梳理压测点

3. 开发压测脚本

4. 执行压测

上述每个环节对于保障压测的质量，都是缺一不可的，但是最终决定压测是否过关的步骤，应该是压测的执行。该环节除了测开执行压测脚本，还会穿插着程序优化、修改压测脚本、复测等，是耗时最长的环节。因此，为了保证压测质量，应该尽可能给该步骤留出充足的时间。下面我们详细看下各个环节的内容，以及哪些地方是可以压缩测试时间的。

02 、压测需求确定

对于要上线的功能，一般需要功能QA去评估下是否有压力点（一般分为客户端压力点和服务器压力点。客户端压力点，一般由策划提出），有压力点就需要进行压测。对于压力点的判断，其实比较考验功能QA的功力，要有足够的敏感度，才可能在需求阶段或功能交付测试前确认是否需要压测。个人认为，是否复用功能、是否曾经压测过并不能作为是否需要压测的评判标准。

不要求提出所有的压力点。压力点的判断，其实并不是一成不变的，而是综合考量实现原理、时间、人力等因素后，得出的结论。如果时间、人力充足，那所有的功能点都可以被压测。当然，这种情况，对于MMO等类型的游戏，几乎不可能实现。但是之前在卡牌游戏负责压测时，由于功能模块比较固定，因此每个功能都有自己的压测脚本。

03 、梳理压测点

测开收到压测需求（可能是策划、功能QA、程序开单）时，大多数情况下功能还未交付测试，这个时候，如果有时间，可以先看下策划文档，对功能有个基础的了解。有时也会出现收到压测需求的时候，功能已经临近上线，为了快速了解游戏，可以找功能QA进行玩法演示。

对功能了解后，才能更好地发掘遗漏的压测点。这个时候，先不要急着去确认压测点是否真的需要执行，先列出来。之前测某游戏的家园功能时，发现一个摆组件的压力点，问了程序是否需要，程序说是老功能，不会有问题。那是不是复用的就一定不会有问题呢？事实证明，真的就出现了问题。下面我们来详细看下这个问题：

1.需求背景

某游戏开发了全新家园系统。玩家可以使用组件在家园内自由搭建。也可以购买蓝图，进行一键装修。下面是收到的压测需求的描述：

创建1k、5k、1w个家园，导入之前的蓝图压测数据，试试看在极限存盘的情况下，服务器压力如何。此外，此功能的QA还提出了一个“不停摆放组件”的压力测试点。

2.测试结果

作者在对需求单中的压测点进行测试完成后，对于“不停摆组件”进行了测试，发现datebase进程的内存在缓慢增⻓，最终发现是家园数据在序列化时，出现内存泄漏问题。

而家园数据序列化的接口，是个老接口，为什么之前没有出现问题呢？

一是因为该功能本身的玩法特性，组件摆放自由度非常高，玩家操作也更加频繁，因此才暴露了这个问题。二是由于这个内存泄漏，本身也是非常缓慢的，下图是此功能投放一周的数据，可以看出内存虽然有增⻓，但是还是比较缓慢的。

因此，在需求梳理阶段，可以先将压力点列出来，而不要着急确认最终是否要进行压测，避免遗漏看起来无需压测但可能隐藏问题的压力点。

3.压测点

这里我们将压测点分为两部分，并介绍两种压测点在梳理时需要关注的点：

1、压测单中的压测点

• 这部分是程序/策划/功能QA比较关注的点，可以设置为高优先级。

2、自主发现的压测点

• 功能压力点：压测需求单中的压测点，可能是不全面的。而测开对于压力点，可能会比较敏感一些，因此，收到压测需求后，需要测开体验功能，发现遗漏的压测点。

• 代码压力点：进行压测的测开同学，尽量先熟悉功能，而不是一上来就直接看程序代码实现。因为如果功能不熟悉，直接看代码，可能会先入为主，跟着程序代码的思路走。直接从代码中寻找遗漏的压力点一般是很难的。

该步完成时，功能一般已经交付测试了。压测点梳理完成，可以发给程序和策划看一眼，梳理出一个优先级。然后按照这个优先级进行脚本的书写和测试。

04 、开发压测脚本

这个步骤，我认为是最能压缩时间的点。脚本设计得好，也可以在一定程度上提高压测执行的效率。下面是本人在某游戏的压测工作中的一些尝试：

1.快速上手流程

平时就要积累一套比较上手的流程，比如如何快速定位功能点代码：

作者所在项目组压测一般用的是服务器机器人，压测脚本中调用的接口，最好是暴露给客户端的接口。一般会有以下几种方式来获取功能接口：

• 通过客戶端暴露

• 通过协议测试平台，获取RPC名称，找到RPC实现

• 直接读程序代码查找

• 最简单的就是，找程序询问

2.组内统一压测框架

• 框架内，基础功能要完善，如创建机器人、好友操作、队伍/团队操作、家园、帮会等基础操作。

• 基础接口，备注要完善。

• 脚本配置化。

为了提高脚本的可复用性，对于脚本中，可能会有变化的值，尽量抽取到配置文件中。举个简单的例子，创建机器人时，机器人等级、装备、技能等，在不同的压测需求下，可能有不同的取值。因此，将这些值抽取到配置中，如：

这样，针对不同的需求，只需要修改配置即可。而且，将配置抽取出来，也可以提高用例脚本的稳定性。只有当游戏中逻辑或接口有变更时，才需要去修改相关的用例脚本，平时对于不同的压测需求，基本都需要用到诸如创建机器人之类的用例，这个时候都可以直接复用，省去调试时间。统一组内压测框架优点：

• 提高代码复用率，省去重复脚本开发，可以明显提高新需求脚本的开发效率。

• 新人易上手。

• 功能复用，要复压时，如果之前是其他同学写的脚本，使用同一套框架，会更容易理解。

• 当压测中间遇到问题，需要其他同学帮忙时，也可以减少一定的沟通成本。

3.用例原子化

将用例拆分成单元用例，这样需要的时候，方便用例“拼接”。

比如测某个活动，前提是需要结拜的两个人进行操作。因为加好友、结拜等好友相关的操作，都已经封装好，可以直接拿来用，在一定程度上提高了开发效率。下面是将一些基础的功能操作进行的封装的例子，这样每次有新需求时，只需要专注新功能的逻辑即可。

05 、执行压测

执行压测的步骤一般由功能QA或测开来完成。

首先，压测时间需要尽可能保证。不充分的测试，带来的最终结果，可能是线上bug。在条件允许的情况下，应当留给压测足够的时间，对功能进行更加充分的测试。

但是如何把握压测的时间，一直是困扰我的难题。想更加充分测试，一般需要耗费大量时间。服务器性能测试还好，一般程序结构确定后，很少去大改。但是客戶端性能就比较麻烦，有时临上线前仍然会有资源的修改。作者经历过几次客户端性能压测，总结出一点点小经验：

• 当提交测试后，先进行一波压测，重点可以先放在服务器性能相关的内容。

• 当客户端资源基本确定后，再进行一波压测，这个时候，要重点看下各种类型的客户端在不同性能机器上的表现。

• 时间尽量拉⻓一点，比如可以晚上下班后，持续跑几小时看下情况。

• 临上线前，最好再回归压测一波。

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走！ 

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。