压测中的精准测试探讨

压测是每个项目必不可少的一个测试领域，而压测范围的评估是压测中最重要的环节之一，当我们在做压测分析时，绕不开的有以下几个问题：

• 在一次项目压测中，我们需要对哪些功能模块进行压测？

• 对于每一个功能模块的压测，如何把控压测用例的颗粒度？

• 评估的压测范围是不是太多了？例如好友模块里的“拉黑好友”，也需要进行压测吗？这个功能会有很多人用吗？

• 评估的压测范围是不是太少了？漏测导致线上问题怎么办？

此外，说到精准测试，我想部分人也并不陌生，精准测试的核心目标，就是通过技术的手段让测试的范围变得精准，提升测试质量与效率。本文想要探讨的就是在压测中精准测试的使用，我们希望能够在有限的时间资源内，通过合理地评估压测范围，尽可能去保证项目的压测质量。

01 压测范围全面性评估

——在压测中做加法

压测中的精准测试思路是：先对压测范围进行全面评估，然后再进行划分优先级挑出重要程度高的场景去进行压测，保证压测的质量和效率。所以，在进行压测分析时，首先我们要做的应该先对压测范围进行全面性评估，找到项目组所有需要进行压测的地方，通过系统分析做加法的方式，找到压测范围的全集，在这里可以总结出4种方法去做压测范围的评估：

1. 项目组QA需求收集

通常来说，项目组功能QA对自己测试的功能都非常熟悉，所以我们可以先从项目组QA出发，收集压测需求。但是由于每个人的习惯和经验都不一样，所以在进行需求收集时，可以先提出一个标准，让对接的QA能够更清楚地明白我们需要什么。

例如，好友系统的压测需求收集表格如下表所示：

模块	具体功能	开发状态	测试说明
好友	搜索好友	待上线
	加好友	待上线	玩家等级限制>=10级
	删除好友	待上线
	一键同意好友申请	开发中
	通过附近的人加好友	开发完成 暂不上线
	拉黑好友/取消好友拉黑	待上线

从表格中可以看出，我们向项目功能QA收集的模块需求，主要包含：

• 模块的主流程功能

• 每个功能的开发状态

• 功能的测试说明

通过这样的收集方式，我们能够对于被测的功能有一个非常快速直观的判断，并且功能QA能给我们提供一些基础的测试说明的话，压测过程也会更加顺利。

2. 压测案例库

学习和借鉴过往项目的测试经验，也是完善压测分析的一个重要环节；同时，为了保障以往项目已经发生过的问题，后续的项目中不会重蹈覆辙，压测组总结归纳了以往项目中出现过的典型压测案例，这也为我们做压测范围评估提供了一个重要的参考渠道。

继续以上述例子中的好友模块为例，我们可以在压测案例库中找到好友模块，查看历史总结出来的相应压测重点：

模块	压测重点用例	相关案例
好友	搜索好友	1、高并发情况下搜索好友中存在超时及请求无反馈的情况
	加好友	1、加好友压测大量超时导致好友服务器不可用
	单个玩家有大量好友申请，接受申请后好友数量达到上限	1、单个好友申请过多导致服务器宕机 2、好友申请列表数量较多时，快速点击同意好友申请，会被踢下线 3、好友列表人数较多时，客户端页面显示无法上下滚动

可以看出，“单个玩家有大量好友申请，接受申请后好友数量达到上限”这一条曾经发生过3例压测问题的bug，在第一步的项目组QA需求收集环节就没有考虑到；所以通过压测案例库，还是可以为压测用例的设计提供非常有价值的参考。

同时，我们也可以看出，压测案例库中整理的是非常典型的曾经出现过问题的案例；但是因为每个游戏项目都会有自己的特殊玩法、创意性功能，这些都是案例库难以覆盖的，且随着行业发展，我们也会有一些新的特性加入到新游戏中，所以在回归“历史”的时候，我们在做压测分析时也一定要与时俱进。

3. 压测用例评审

俗话说，“众人拾柴火焰高”，一个人的想法往往是难以考虑全面的，所以在重要环节的保障上，我们还是应该尽量地去借助团队的力量。

压测用例评审的参与方包括：

• 程序开发

• 项目组功能QA

• 项目组测开

• 压测组成员

项目组成员可以从项目组各自的职能角度出发提供压测意见，压测组成员具备过往压测项目的经验，可以提供在以往项目压测过程中具有参考意义的意见。

4. 项目服务器架构分析

在进行压测时，我们通常会借用服务器的架构理解，来帮助我们分析压力的来源，也就是性能瓶颈。比如下图为某项目服务器架构：

通过服务器架构分析，我们可以得知项目的压力来源入口有四种：

1.客户端与大厅服之间的通信，即全部的client_gateway_rpc接口

2.战斗服与大厅服之间的通信，即ue4_uegateway_rpc接口

3.大厅服集群内进程间的通信，即全部的nats_rpc接口

4.大厅服与第三方服务之间的通信，通常为Http协议请求

以上四种接口的全集，就是能够对服务器造成压力的全部入口来源了，我们可以从服务器的代码中进行简单的静态扫描，就可以快速得出接口的全集数量。

5. 实践效果

以笔者不久前进行的一个项目的阶段性压测来看，首先尝试的前三种评估方法，当时得出第一版压测范围为15个场景，57个用例（接口）；而在上文介绍的第四种方法中，项目服务器架构分析，通过代码扫描的方式共计648个接口。

这两个数据之间看起来差距有点大，前三种方法所得出的测试范围不及代码定义中接口梳理的十分之一，而648个接口都要压测的话也不是小工程，到底应该以哪个作为压测范围呢？

在这一步“做加法”的环节，我们的目标就是尽可能多的找到需要压测的场景，对整体的全局有所把握，所以这个环节中梳理出来的压测用例，我们都应该记录下来，接下来的话，我们需要做的就是“做减法”，也就是精准性评估，这部分在下一章中进行介绍。

02 压测范围精准性评估

——在压测中做减法

在上述篇幅中介绍了四种全面性评估的方法，可以称之为“做加法”，在做加法的阶段，我希望是能够尽可能多的找到需要压测的场景，当我们对全局有一个把握之后，可以通过精准性评估——“做减法”的方式来确定压测的优先级。这一环节的核心目标是：通过合理有效的方法评估压测功能的优先级，确保在有限的测试时间内保障重点功能的测试质量，这里总结了以下几种“做减法”的工具和方法。

1. 明确项目压测目标

第一种方法是看似简单实际却很容易产生疏忽的方法，那就是需要明确项目组的压测目标。这一条看似简单之处在于一般来说项目组的压测目标也就是简单几句话就可以概括的事情，例如“在10月海外测试中，项目可以支持2w人进行游戏”，这个就是一个项目在一次对外测试中的压测目标概述了。但是复杂的地方在于，我们需要对目标进行展开解读，而且还要关注这个目标在整个测试过程中的不断变化，这些都会对压测范围的评估产生影响。

对于压测目标的拆解，有以下4个点是比较值得关注的：

• 目标玩家数量，服务器上限人数及预估PCU

• 目标玩家地区，涉及外网服务器部署

• 本次测试开放功能范围：部分功能已经开发完成，但是项目组确定本次测试不对外开放的功能

• 本次测试的时间期限

但是往往在项目测试中，这些目标存在一定的不确定性，例如可能会被市场上的竞品影响，临时修改项目的测试目标，影响压测的测试进度，这里我们可以做的就是以“轮询”的方式去保持与项目组的沟通，每周定期在压测报告中强调本次压测的目标，压测范围，避免信息不同步导致的问题。

在已知项目压测目标和上线功能的情况下，我们就可以对上一章中全面性评估的结果去做减法。以上文中代码分析扫描出来的648个接口为例，其中本期不上线的功能覆盖的接口数量是120个，那么这些接口就可以以做减法的方式被排除掉了。此外我们需要保持对压测目标的关注度，如果功能范围发生变化，那么这个压测范围也需要有相应的改变。

2. 同类功能历史接口调用量参考

压测和普通功能测试的区分在于，压测的重点应该更多的放在性能热点上，如果一些场景在使用频率上就难以触达性能瓶颈，那么这些功能在做压测评估的时候，就可以适当的降低其优先级。

还是以好友功能为例，表格中的好友相关功能，从我们日常的感知上判断，“加好友”应该是一个比较高频的行为，而“删除好友”“拉黑好友”相对来说使用频率会比较低。但是如果我们要把“删除好友”、“拉黑好友”放在比较低的优先级是出于“我感觉应该这么做”的理由，显然是没有说服力的。如果能够从数据的角度证明我们的猜想，那就可以让结论变得具有说服力。

模块	具体功能	优先级
好友	加好友	高
	删除好友	低
	拉黑好友/取消好友拉黑	低

因此，我们可以借助参考其他已上线项目的历史数据，来让压测的范围评估变得更加精准。我们压测组也会计划收集更多已上线项目的调用数据，结合案例库给出用例的优先级评定，供各个项目组后期压测作为参考。

3. 高频接口调用统计工具

在第二点的方法中，我们是参考以往项目的数据来进行优先级的判定，但是这个方法局限性在于只适用于一些基础功能，显然对于一些新游戏的新玩法是无法覆盖的。那么这些新玩法里的功能，我们怎么去判定优先级呢？

针对上述痛点，我们整合了一个“高频接口调用统计分析工具”，通过收集日常集体测试中的接口调用量，进行统计分析，为功能压测优先级的评定提供参考。

工具基本链路如图所示：

首先，项目中已有rpc_send方法调用日志埋点，也就是可以记录所有的接口调用请求；

其次，本项目在周版本阶段和日版本阶段会根据版本频率进行每周/每日的集体测试，模拟玩家行为进行比赛游玩。集体测试后埋点日志会进行数据上报，那么我们可以根据上报的数据进行统计分析，确定接口的调用频次，如下表格即为调用频次统计表格：

接口名称	调用量	接口作用
get_discover_token	21189	网络探测
upload_fps_log	11266	上传fps日志
client_get_player_custome_info	6981	获取玩家基础信息
……
report_abnormal	2	上报异常问题
request_change_team_leader	2	要求成为队长

从结果可以看出，调用量最大的接口是“get_discover_token”——网络探测接口，那么这个接口肯定是有必要进行压测的；而调用量比较低的“request_change_team_leader”——要求成为队长接口，总的调用量只有2，所以可以调低其压测的优先级。

并且，在“高频接口调用统计分析”工具的使用过程中，除了能给压测功能评估优先级做参考外，还有其他意料之外的显著效果。

1.发现功能QA无法评估到的场景

如下表所示，本次测试阶段调用量最高的5个接口，在我们第一轮评估中，也就是通过“项目需求收集+压测案例库+压测用例review”的评估方法，只覆盖了其中1个接口。没有被评估到的接口大多是基础的日志接口，而这些接口在功能测试中一般不会有专人进行重点测试，所以容易被遗漏从而造成性能风险。

接口名称	接口作用	调用量	第一轮评估中是否涉及
get_discover_token	网络探测	21189	否
upload_fps_log	上传fps日志	11266	否
client_get_player_custome_info	获取玩家基础信息	6981	是
upload_watch_info	上传观战日志	5382	否
print_p_log	打印性能日志	4454	否

2.补充场景中的新增用例

工具的另一个显著效果就是可以补充场景中的新增用例，这些用例有些是在评估环境漏掉的，另一些是随着版本的开发进度新增的功能。比如笔者所在项目在使用工具过程中，在组队这个场景中补充了两个用例：

• Steam邀请组队：第一轮评估时还没有做这个功能，属于压测过程中版本新开发的功能；

• 加入队伍语音频道：第一轮人工评估时漏了。

3.发现功能开关问题

继续以上述例子调用量最高的5个接口为例，我们看到“upload_watch_info”这个观战相关接口也存在大量的接口调用量，然而在本阶段测试中，观战功能属于已经完成开发但是开关关闭不对外开放的功能，日志统计分析发现观战系统也存在大量接口调用，可能对服务器产生性能压力。如果我们直接按照“观战功能本期测试不涉及”去做压测的话，这个接口的性能问题在评估时就会被去掉，以至于无法发现问题。

可以看出，高频接口调用分析统计这个工具，相比人为评估压测范围，能够起到一定的补充作用，而相比代码扫描得出来的全部调用接口列表，又更加精简，可以帮助我们快速地确定接口的使用频次，作为优先级评定的参考。

03 总结

以上就是本文中介绍的所有压测范围的评估方法，这些方法在笔者所在项目组进行了相应实践，总结来说，先通过全面性评估全方位收集压测范围，再通过精准性评估划分优先级精简压测范围，最后得到的阶段性压测用例集可覆盖18个场景，共计122条用例（接口），这个数据相比第一轮评估得到的57条用例更加全面，相比代码扫描得出的648条用例足够精简，属于比较适中的范畴。

在压测中进行精准测试的探讨，尝试了各个方法以后发现所有的方法都是相辅相成的，要学会做加法，也要学会做减法，不能只依赖一个方法，也不能离开任意一个方法。这个道理不仅仅适用于压测，在功能测试、接口测试、性能测试等测试流程中也同样适用。

最后： 下方这份完整的软件测试视频学习教程已经整理上传完成，朋友们如果需要可以自行免费领取【保证100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！