CN106390451B - 对游戏服务器的容量进行测试的方法及装置 - Google Patents

Abstract

本发明公开了一种对游戏服务器的容量进行测试的方法及装置。该方法包括：获取消息指示信息，其中，该消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到当前游戏中的不同玩家发送的消息；根据上述消息指示信息确定平均消息发送频率，以及上述消息在不同目标功能场景下的消息占比，其中，该平均消息发送频率用于指示单位时间内单个玩家向游戏服务器发送的消息的数量，上述游戏中的功能场景包括多个目标功能场景；根据上述平均消息发送频率和上述消息在不同目标功能场景下的消息占比对游戏服务器的容量进行测试，得到测试结果，其中，该测试结果包括同时在线的玩家的数量的最大值。从而解决了服务器容量测试结果不准确的问题。

Description

对游戏服务器的容量进行测试的方法及装置

技术领域

本发明涉及测试领域，具体而言，涉及一种对游戏服务器的容量进行测试的方法及装置。

背景技术

在一款新的产品(例如，新的应用、新的游戏)上市之前，需要对该产品的各方面性能进行综合测试，下面以游戏上线为例进行说明：在对需要上线的新游戏进行测试时，需要对游戏服务器容量进行测量，该游戏服务器容量测试是在游戏大规模上线前，测试服务器上线后能承受的最大玩家同时在线个数(Peak Concurrent User，简称为PCU)。

在对游戏服务器容量进行测试时，需要构造玩家模型，在相关技术中，构造玩家模型主要是基于客户端视角来进行构造的。如图1所示，构造的主要流程可以包括以下操作：

通过打开客户端体验游戏，根据经验确定核心游戏功能(也可称为目标功能场景)，可以假设核心游戏功能为功能1，功能2，功能3；

整理各核心游戏功能消息时序，然后根据各功能的总游戏时间来设置消息包发送等待时间；

最后构造一个总的玩家模型，顺序地进行功能1，功能2，功能3的操作，全部完成以后退出，重新进入继续功能1，功能2，功能3，反复循环。

需要说明的是，采用相关技术中的构造玩家模型的方法，主要考虑了客户端的核心游戏功能，以及核心功能的持续时间段。采用这种玩家模型构造方式会存在如下问题：

考虑游戏核心功能类型时，不同游戏核心功能场景(也可称为目标功能场景)的使用频次没有进行差异化。

在较大量玩家同时在线的实际情况中，每个游戏功能场景被使用的频次是不一样的，并且不同游戏功能场景对于服务器端产生的资源消耗有很大差别，上述构造方式并未区分大量玩家在线时不同游戏功能场景的使用频次，因此会导致容量评估结果极不准确；

以及，玩家模型中的玩家平均操作频率在评估容量中同样非常重要，该值的误差会直接决定容量的误差，比如在预估的操作频率是每分钟6个协议包(即，每分钟发送6条消息)下，评估出单服最大在线是1万个玩家，若实际的操作频率是12个包，那么最大在线实际只能承载5千个玩家，如果参考1万结果上线，很有可能导致玩家在线卡顿，大大影响用户体验，而如果预估的操作频率偏大，则会浪费服务器资源。但是在相关技术的玩家模型构造方案中，该值是基于开发根据系统设计预估的，和实际值之间存在相当大的误差。也就是说如果测试结果小于服务器的实际可承载的最大玩家同时在线，会导致服务器资源的大大浪费，如果服务器容量结果误差达到50％，意味着要浪费50％的成本，在玩家同时在线很高的游戏中，这是一笔非常大的开销浪费；如果测试结果高于服务器的实际可承载能力，就会导致玩家进入游戏失败，或者在线游戏非常卡顿等情况，极大地影响用户体验。

由于相关技术中的玩家操作频率和核心功能列表是根据设计预估的，并且核心功能的使用人数没有进行差异化评估，会导致玩家模型不准确，基于该玩家模型确定的允许服务器最大同时在线人数也将极不准确。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种对游戏服务器的容量进行测试的方法及装置，以至少解决相关技术中存在的服务器容量测试结果不准确的问题。

根据本发明实施例的一个方面，提供了一种对游戏服务器的容量进行测试的方法，包括：获取消息指示信息，其中，所述消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到所述当前游戏中的不同玩家发送的消息；根据所述消息指示信息确定平均消息发送频率，以及所述消息在不同目标功能场景下的消息占比，其中，所述平均消息发送频率用于指示单位时间内单个玩家向所述游戏服务器发送的消息的数量，所述游戏中的功能场景包括多个所述目标功能场景；根据所述平均消息发送频率和所述消息在不同目标功能场景下的消息占比对所述游戏服务器的容量进行测试，得到测试结果，其中，所述测试结果包括同时在线的玩家的数量的最大值。

可选地，根据所述消息指示信息确定所述平均消息发送频率包括：根据所述消息指示信息确定所述预定时间段内的平均在线玩家数量、以及所述游戏服务器在所述预定时间段内接收到的所述消息的总数；根据如下公式确定所述平均消息发送频率：所述平均消息发送频率＝所述消息的总数÷所述平均在线玩家数量÷所述预定时间段的时长。

可选地，根据所述消息指示信息确定所述消息在不同目标功能场景下的消息占比包括：从所述消息的消息号中确定出多个目标消息号；根据所述消息指示信息确定每个所述目标消息号下的目标消息的数量与所述消息的总数之间的比值，其中，所有所述目标消息号的比值之和大于预定阈值且小于1；按比例将所有所述目标消息号的比值扩大至目标比值，其中，所有所述目标消息号的目标比值之和等于1；获取每个所述目标功能场景对应的所有所述目标消息号的目标比值之和，作为所述消息在所述目标功能场景下的消息占比，其中，每个所述目标消息号对应一个所述目标功能场景。

可选地，根据所述平均消息发送频率和所述消息在不同目标功能场景下的消息占比对所述游戏服务器的容量进行测试包括：重复执行以下操作，直到模拟玩家发送的消息的响应时间和响应成功率不符合第一预定条件、或所述游戏服务器的空闲资源不符合第二预定条件：按照所述消息占比将当前数量的模拟玩家分别分配到每个所述目标功能场景中；将每个所述模拟玩家的消息发送频率设置为所述平均消息发送频率，其中，所述消息发送频率用于表示在所述单位时间内向所述游戏服务器发送的消息的数量；根据所述分配的结果和所述设置的结果对所述游戏服务器的容量进行测试，并判断所述测试的过程中所述模拟玩家发送的消息的响应时间和响应成功率是否符合所述第一预定条件、且判断所述游戏服务器的空闲资源是否符合所述第二预定条件；若响应时间和响应成功率符合所述第一预定条件、且所述游戏服务器的空闲资源符合所述第二预定条件，则将所述当前数量进行增加，将增加后的结果作为所述当前数量；若响应时间和响应成功率不符合所述第一预定条件、或所述游戏服务器的资源不符合所述第二预定条件，则将前一次的当前数量记录为所述同时在线的玩家的数量的最大值。

可选地，获取所述消息指示信息包括：分别获取预定天数内的每天的所述消息指示信息；根据所述消息指示信息确定平均消息发送频率包括：根据每天的所述消息指示信息确定所述预定天数内的每天的平均消息发送频率；并从所述预定天数内的每天的平均消息发送频率中选取频率值最大的平均消息发送频率作为确定的所述平均消息发送频率。

根据本发明实施例的另一方面，还提供了一种对游戏服务器的容量进行测试的装置，包括：获取模块，用于获取消息指示信息，其中，所述消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到所述当前游戏中的不同玩家发送的消息；确定模块，用于根据所述消息指示信息确定平均消息发送频率，以及所述消息在不同目标功能场景下的消息占比，其中，所述平均消息发送频率用于指示单位时间内单个玩家向所述游戏服务器发送的消息的数量，所述游戏中的功能场景包括多个所述目标功能场景；测试模块，用于根据所述平均消息发送频率和所述消息在不同目标功能场景下的消息占比对所述游戏服务器的容量进行测试，得到测试结果，其中，所述测试结果包括同时在线的玩家的数量的最大值。

可选地，所述确定模块包括：第一确定单元，用于根据所述消息指示信息确定所述预定时间段内的平均在线玩家数量、以及所述游戏服务器在所述预定时间段内接收到的所述消息的总数；第二确定单元，用于根据如下公式确定所述平均消息发送频率：所述平均消息发送频率＝所述消息的总数÷所述平均在线玩家数量÷所述预定时间段的时长。

可选地，所述确定模块包括：第三确定单元，用于从所述消息的消息号中确定出多个目标消息号；第四确定单元，用于根据所述消息指示信息确定每个所述目标消息号下的目标消息的数量与所述消息的总数之间的比值，其中，所有所述目标消息号的比值之和大于预定阈值且小于1；扩大单元，用于按比例将所有所述目标消息号的比值扩大至目标比值，其中，所有所述目标消息号的目标比值之和等于1；获取单元，用于获取每个所述目标功能场景对应的所有所述目标消息号的目标比值之和，作为所述消息在所述目标功能场景下的消息占比，其中，每个所述目标消息号对应一个所述目标功能场景。

可选地，所述测试模块包括：执行单元，用于重复执行以下操作，直到模拟玩家发送的消息的响应时间和响应成功率不符合第一预定条件、或所述游戏服务器的空闲资源不符合第二预定条件：按照所述消息占比将当前数量的模拟玩家分别分配到每个所述目标功能场景中；将每个所述模拟玩家的消息发送频率设置为所述平均消息发送频率，其中，所述消息发送频率用于表示在所述单位时间内向所述游戏服务器发送的消息的数量；根据所述分配的结果和所述设置的结果对所述游戏服务器的容量进行测试，并判断所述测试的过程中所述模拟玩家发送的消息的响应时间和响应成功率是否符合所述第一预定条件、且判断所述游戏服务器的空闲资源是否符合所述第二预定条件；若响应时间和响应成功率符合所述第一预定条件、且所述游戏服务器的空闲资源符合所述第二预定条件，则将所述当前数量进行增加，将增加后的结果作为所述当前数量；记录单元，用于在响应时间和响应成功率不符合所述第一预定条件、或所述游戏服务器的资源不符合所述第二预定条件的情况下，则将前一次的当前数量记录为所述同时在线的玩家的数量的最大值。

可选地，所述获取模块包括：获取单元，用于分别获取预定天数内的每天的所述消息指示信息；所述确定模块包括：第五确定单元，用于根据每天的所述消息指示信息确定所述预定天数内的每天的平均消息发送频率；并从所述预定天数内的每天的平均消息发送频率中选取频率值最大的平均消息发送频率作为确定的所述平均消息发送频率。

在本发明实施例中，采用的是获取消息指示信息，其中，所述消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到所述当前游戏中的不同玩家发送的消息；根据所述消息指示信息确定平均消息发送频率，以及所述消息在不同目标功能场景下的消息占比，其中，所述平均消息发送频率用于指示单位时间内单个玩家向所述游戏服务器发送的消息的数量，所述游戏中的功能场景包括多个所述目标功能场景；根据所述平均消息发送频率和所述消息在不同目标功能场景下的消息占比对所述游戏服务器的容量进行测试，得到测试结果，其中，所述测试结果包括同时在线的玩家的数量的最大值的方式，即，在本发明中是根据真实的玩家数据确定的玩家平均消息发送频率以及目标功能场景的占比，从而能够得到准确的更为贴合实际的玩家的平均消息发送频率以及目标功能场景的占比，以及能够对不同的目标功能场景的使用频次进行了差异化测试，从而对游戏服务器进行准确的容量评估，进而解决了相关技术中存在的服务器容量测试结果不准确的的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是相关技术的一种对游戏服务器的容量进行测试的玩家操作流程示意图；

图2是根据本发明实施例的一种对游戏服务器的容量进行测试的方法的应用环境示意图；

图3是根据本发明实施例的一种对游戏服务器的容量进行测试的方法的流程图；

图4是根据本发明实施例的在线玩家人数变化图；

图5是根据本发明实施例的全部消息的格式示意图；

图6是根据本发明实施例的目标消息的格式示意图；

图7是根据本发明实施例的目标功能场景的占比示意图；

图8是根据本发明实施例的对服务器进行测试的玩家模型示意图；

图9是根据本发明实施例的对服务器进行测试的整体流程图；

图10是根据本发明实施例对游戏服务器的容量进行测试的装置的结构框图；

图11是根据本发明实施例对游戏服务器的容量进行测试的装置中确定模块1004的结构框图(一)；

图12是根据本发明实施例对游戏服务器的容量进行测试的装置中确定模块1004的结构框图(二)；

图13是根据本发明实施例对游戏服务器的容量进行测试的装置中测试模块1006的结构框图；

图14是根据本发明实施例对游戏服务器的容量进行测试的装置中获取模块1002和确定模块1004的结构框图；

图15是根据本发明实施例对游戏服务器的容量进行测试的服务器的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本发明实施例，提供了一种对游戏服务器的容量进行测试的方法，该方法可以应用于如图2所示的环境中，其中，运行有游戏客户端的终端202(实际操作时，202的数量可以多个的，与实际玩家数量对应，在图2中仅示意性地绘制了一个)，通过网络204与游戏客户端对应的游戏服务器206进行交互。本实施例中的方法可以应用于服务器(例如，图2所示的游戏服务器206)中。

在本实施例中，在对游戏服务器的容量进行测试时，需要构造玩家模型，也就是说，本实施例中所构造的玩家模型是基于服务器视角的玩家模型。在本实施例中，是利用大样本的真实玩家数据所进行的平均值的统计分析，减少单个误差，从而得到玩家的准确平均值(即，上述的平均消息发送频率)和各游戏功能场景占比情况。

可选地，本实施例中的测试方法可以通过如下方式实现：通过采集游戏灰度测试期(即真实玩家游戏时)玩家在线高峰时期的一定时段内，服务器接收的该时段内所有玩家在线发送的消息数量，分析和统计确定该时段内的单个玩家的平均操作频率(例如，平均消息发送频率)，各游戏功能场景的在线玩家数量。然后模拟计算当有M个(M为正整数，例如5000、8000、10000)玩家同时在线时，且单个玩家的操作频率为上述的平均操作频率，以及各游戏功能场景的在线玩家数量按照统计结果进行分布时，对服务器的压力，并在服务器存在空闲容量的情况下逐步增加压力，以得到测试游戏服务器的容量结果。

需要说明的是，上述用于实施对游戏服务器的容量进行测试的服务器可以但不限于替换为具有大数据处理能力的硬件设备，如处理器，本实施例中对此不做任何限定。

可选地，在本实施例中，上述终端可以包括但不限于以下至少之一：手机、平板电脑、笔记本电脑、台式PC机及其他安装有游戏客户端的终端。上述网络可以包括但不限于以下至少之一：广域网、城域网、局域网。上述只是一种示例，本实施例对此不做任何限定。

根据本发明实施例，提供了一种对游戏服务器的容量进行测试的方法，如图3所示，该方法包括：

步骤S302，获取消息指示信息，其中，该消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到当前游戏中的不同玩家发送的消息；

步骤S304，根据上述消息指示信息确定平均消息发送频率，以及上述消息在不同目标功能场景下的消息占比，其中，该平均消息发送频率用于指示单位时间内单个玩家向游戏服务器发送的消息的数量，上述游戏中的功能场景包括多个目标功能场景；

步骤S306，根据上述平均消息发送频率和上述消息在不同目标功能场景下的消息占比对游戏服务器的容量进行测试，得到测试结果，其中，该测试结果包括同时在线的玩家的数量的最大值。

其中，在本实施例中，消息指示信息可以是不同玩家所发送的具体消息，也可以是不同玩家所发送的具体消息的标识信息，或者是其他的能够指示不同玩家所发送的具体消息的指示信息。本实施例中的当前游戏中的不同玩家为实际玩家，即，在游戏灰度测试期间实际进行游戏操作的用户。利用真实玩家数据所得到的测试结果更贴合实际情况。

本实施例中的目标功能场景主要针对的是核心功能场景，也就是说从当前游戏的所有功能场景中确定出来的一些重要的功能场景，其中，在确定目标功能场景时，可以根据二八理论，选取最有价值的占比总和为80％(当然，根据实际情况，该比例是可以灵活调整的，不仅仅局限于80％。例如，可以调整为90％，调整为70％)的功能场景，需要说明的是，在进行目标功能场景的选择时，可以是依据场景下的消息发送的数量来进行确定，相应地，可以选取最优价值的占比总和为80％的核心消息，然后可以根据需求加入部分消息，其中，该重要消息可以是核心消息需要依赖于的部分非核心消息，或者，根据经验判断，可能是涉及功能比较复杂，需要在容量测试中覆盖的消息。

由上述步骤可知，在本实施例中是根据真实的玩家数据确定的玩家平均消息发送频率以及目标功能场景的占比，从而能够得到准确的更为贴合实际的玩家的平均消息发送频率以及目标功能场景的占比，以及能够对不同的目标功能场景的使用频次进行了差异化测试，从而对游戏服务器进行准确的容量评估，进而解决了相关技术中存在的服务器容量测试结果不准确的的技术问题。

可选地，在本实施例中，在根据上述消息指示信息确定平均消息发送频率时，可以通过如下方式确定：根据上述消息指示信息确定预定时间段内的平均在线玩家数量、以及上述游戏服务器在预定时间段内接收到的消息的总数；根据如下公式确定上述平均消息发送频率：平均消息发送频率＝消息的总数÷平均在线玩家数量÷预定时间段的时长。在本实施例中，预定时间段是一天中在线玩家人数最多的一个时间段，例如，图4所示是0点至21点期间的在线玩家人数变化图，从图4可知，人数最多的时间段大概是在12:00-14:00期间，在13：00达到顶峰，在进行测试时，可以选取12:00-14:00间的一段时间，例如选取12:30-13:00作为测试时间段(即，上述的预定时间段)。上述的平均在线玩家数量是根据选取的测试时间段中的玩家人数流量确定的，例如当选取12:30-13:00作为测试时间段时，假设监测到12:30-12:40间的在线人数为1000，12:40-12:50间的在线人数为1100，12:50-13:00间的在线人数为1200，则，该测试时间段中的平均在线玩家数量为1100。

可选地，在本实施例中，在根据上述消息指示信息确定消息在不同目标功能场景下的消息占比时，可以通过如下方式确定：从上述消息的消息号中确定出多个目标消息号；根据该消息指示信息确定每个目标消息号下的目标消息的数量与消息的总数之间的比值，其中，该所述目标消息号的比值之和大于预定阈值(该预定阈值可以根据实际情况进行确定，例如75％、80％)且小于1；按比例将所有目标消息号的比值扩大至目标比值，其中，所有目标消息号的目标比值之和等于1；获取每个目标功能场景对应的所有目标消息号的目标比值之和，作为消息在目标功能场景下的消息占比，其中，每个目标消息号对应一个目标功能场景。例如，全部消息(假定全部消息为消息1-消息21)可以如图5所示，选取的目标消息(假定目标消息为消息1-消息13)可以如图6所示，图6中的消息占比一列为消息1-消息13在全部消息(即，消息1-消息21)中的占比，图6中的测试消息占比一列为消息1-消息13分别在选取的目标消息(即，消息1-消息21)中的占比。在本实施例中，一个目标功能场景可能对应多种目标消息，因此，在确定一个目标功能场景在所有目标功能场景下的占比时，可以根据一个目标功能场景对应的多种消息在所有消息的占比之和来进行确定，具体可参考图7。

可选地，根据上述平均消息发送频率和消息在不同目标功能场景下的消息占比对游戏服务器的容量进行测试时，可以同如下方式实现：重复执行以下操作，直到模拟玩家发送的消息的响应时间和响应成功率不符合第一预定条件、或游戏服务器的空闲资源不符合第二预定条件：按照消息占比将当前数量的模拟玩家分别分配到每个目标功能场景中；将每个模拟玩家的消息发送频率设置为平均消息发送频率，其中，该消息发送频率用于表示在单位时间内向游戏服务器发送的消息的数量；根据所述分配的结果和设置的结果对游戏服务器的容量进行测试，并判断测试的过程中模拟玩家发送的消息的响应时间和响应成功率是否符合第一预定条件、且判断游戏服务器的空闲资源是否符合第二预定条件；若响应时间和响应成功率符合第一预定条件、且游戏服务器的空闲资源符合第二预定条件，则将当前数量进行增加，将增加后的结果作为当前数量；若响应时间和响应成功率不符合第一预定条件、或游戏服务器的资源不符合第二预定条件，则将前一次的当前数量记录为同时在线的玩家的数量的最大值。在本实施例中，在通过大样本的真实玩家数据确定了平均消息发送频率和消息在不同目标功能场景下的消息占比时，便可以利用确定的平均消息发送频率和消息在不同目标功能场景下的消息占比对游戏服务器的容量进行测试，在进行测试时，可以利用模拟玩家(即，用于模拟实际玩家的机器人)进行测试，在测试的过程中可以按照确定的平均消息发送频率和消息在不同目标功能场景下的消息占比对模拟玩家进行配置，并利用配置后的模拟玩家进行消息的发送，以实现对游戏服务器的容量的测试，从本实施例中的描述可知，在对游戏服务器的容量进行测试时，需要循环执行一些测试操作，直到确定出符合测试要求的同时在线的玩家的数量的最大值为止。上述的测试操作流程可以参考图8，在图8中，游戏核心功能场景总共有N个，transPer[i]表示第i个核心功能场景的占比；核心功能场景1中Message_ID1_1,Message_ID1_2,Message_ID1_J分别表示第1个核心功能场景的第1个消息标识(Identification，简称为ID)，第2个消息ID，第J个消息ID，并且核心功能场景1总共有J个消息；核心功能场景N中Message_IDN_1,Message_IDN_2,Message_IDN_k分别表示第N个核心功能场景的第1个消息ID，第2个消息ID，第k个消息ID，并且核心功能场景N总共有k个消息。图8中所示的等待时间需要根据具体情况确定(例如，根据某个副本的通关时间)，图8中所示的机器人即本实施例中所述的模拟玩家，在本实施例中可以假设机器人的总数为1万(w)个。

可选地，在本实施例中，获取上述消息指示信息包括：分别获取预定天数内的每天的消息指示信息；根据上述消息指示信息确定平均消息发送频率包括：根据每天的消息指示信息确定上述预定天数内的每天的平均消息发送频率；并从上述预定天数内的每天的平均消息发送频率中选取频率值最大的平均消息发送频率作为确定的平均消息发送频率。也就是说，仅仅依据一天的测试结果来确定平均消息发送频率可能是不准确的，因此，可以连续几天(例如，三天)记录在线玩家人数以及统计在线玩家发送的消息的数量，并综合对比几天的记录来确定最终的平均消息发送频率，例如，可以将几天中确定的最大的平均消息发送频率作为最终的消息发送频率。

下面结合图9对游戏服务器的容量测试方法进行描述，如图9所示，该方法包括如下步骤：

S1，维持游戏服务器稳定运行至少3天，并且在服务器端记录下这段时间内所有客户端发送过来的消息。然后观察这段时间内的在线玩家人数，如图4所示，可以得到13:00期间，会达到一个玩家在线人数的峰值，记录游戏的平均在线玩家数量。

S2，统计在线玩家人数峰值期间：起始时间为12:30，结束时间为13：00的半小时内，服务器接收到的全部在线玩家发送的消息数。数据格式可参考图5。

S3，根据消息记录统计数据，计算单个玩家的发包频率(每分钟的发包个数)。可以按照公式messNumPerM＝TotalMNums÷TotalPNums÷TotalMs计算单个玩家的发包频率，其中，

表示统计的消息数总和，TotalPNums表示统计的平均在线玩家数量，TotalMs表示统计的时间长度(单位：分钟)，即可以得到单个玩家每分钟发包个数。

S4，根据消息记录统计数据，确定各个核心功能场景(对应于上述的目标功能场景)的占比。

在确定各个核心功能场景的占比时，可以首先选取核心消息列表(对应于上述的目标消息的列表)。如图6所示，按照降序排列后，根据二八理论，选取最有价值的占比总和为80％的核心消息，然后再根据需求加入部分消息，需要加入的部分消息包括如下情况：1)核心消息需要依赖于的部分非核心消息。2)部分重要功能的消息，根据经验判断，可能是涉及功能比较复杂，需要在容量测试中覆盖。然后将核心消息的占比做转换，让选取的消息占比为100％。

然后，分析核心功能场景和核心消息的所属关系，计算出核心功能场景的占比。由于游戏中单个功能场景比较复杂，单个核心功能场景可能依赖于多条消息的配合使用。如图7中所示，各核心功能场景的占比TransPer[i]可以通过如下公式确定：

其中j表示属于该游戏的核心功能场景i的消息ID。

S5，计算得到单个玩家发包频率messNumPerM和核心游戏场景占比TransPer[i]后，在进行给定值PCU测试时，分配所有核心功能场景的机器人个数，并且设置好单个机器人的发包频率。机器人的分配和不同核心功能场景的流程可参考图8。

S6，选择压测工具，开发压测脚本，并设置好同时在线人数为N时的各个参数，测试出当前压力下，观察所有消息的响应成功率，响应时间，以及服务器的各种资源消耗。如果成功率和响应时间都符合要求，同时服务器资源还有空闲。可逐步增加玩家总在线人数TotalNum后测试，并观察结果，直至资源消耗遇到瓶颈导致消息成功率或者响应时间不达标，或者服务器资源没有空闲为止。那么前一组最大同时测试结果符合要求的TotalNum即为服务器的单服最大承载人数PCU。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述对游戏服务器的容量进行测试的装置，图10是根据本发明实施例对游戏服务器的容量进行测试的装置的结构框图，如图10所示，该装置包括获取模块1002、确定模块1004和测试模块1006，下面对该装置进行说明：

获取模块1002，用于获取消息指示信息，其中，该消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到当前游戏中的不同玩家发送的消息；

确定模块1004，用于根据上述消息指示信息确定平均消息发送频率，以及消息在不同目标功能场景下的消息占比，其中，该平均消息发送频率用于指示单位时间内单个玩家向游戏服务器发送的消息的数量，上述游戏中的功能场景包括多个所述目标功能场景；

测试模块1006，用于根据上述平均消息发送频率和消息在不同目标功能场景下的消息占比对上述游戏服务器的容量进行测试，得到测试结果，其中，该测试结果包括同时在线的玩家的数量的最大值。

其中，在本实施例中，消息指示信息可以是不同玩家所发送的具体消息，也可以是不同玩家所发送的具体消息的标识信息，或者是其他的能够指示不同玩家所发送的具体消息的指示信息。本实施例中的当前游戏中的不同玩家为实际玩家，即，在游戏灰度测试期间实际进行游戏操作的用户。利用真实玩家数据所得到的测试结果更贴合实际情况。

本实施例中的目标功能场景主要针对的是核心功能场景，也就是说从当前游戏的所有功能场景中确定出来的一些重要的功能场景，其中，在确定目标功能场景时，可以根据二八理论，选取最有价值的占比总和为80％(当然，根据实际情况，该比例是可以灵活调整的，不仅仅局限于80％。例如，可以调整为90％，调整为70％)的功能场景，需要说明的是，在进行目标功能场景的选择时，可以是依据场景下的消息发送的数量来进行确定，相应地，可以选取最优价值的占比总和为80％的核心消息，然后可以根据需求加入部分消息，其中，该重要消息可以是核心消息需要依赖于的部分非核心消息，或者，根据经验判断，可能是涉及功能比较复杂，需要在容量测试中覆盖的消息。

由上述步骤可知，在本实施例中是根据真实的玩家数据确定的玩家平均消息发送频率以及目标功能场景的占比，从而能够得到准确的更为贴合实际的玩家的平均消息发送频率以及目标功能场景的占比，以及能够对不同的目标功能场景的使用频次进行了差异化测试，从而对游戏服务器进行准确的容量评估，进而解决了相关技术中存在的服务器容量测试结果不准确的的技术问题。

图11是根据本发明实施例对游戏服务器的容量进行测试的装置中确定模块1004的结构框图(一)，如图11所示，该确定模块1004包括第一确定单元1102和第二确定单元1104，下面对该确定模块1004进行说明：

第一确定单元1102，用于根据消息指示信息确定上述预定时间段内的平均在线玩家数量、以及游戏服务器在预定时间段内接收到的消息的总数；

第二确定单元1104，用于根据如下公式确定上述平均消息发送频率：平均消息发送频率＝消息的总数÷平均在线玩家数量÷预定时间段的时长。

在本实施例中，预定时间段是一天中在线玩家人数最多的一个时间段，例如，图4所示是0点至21点期间的在线玩家人数变化图，从图4可知，人数最多的时间段大概是在12:00-14:00期间，在13：00达到顶峰，在进行测试时，可以选取12:00-14:00间的一段时间，例如选取12:30-13:00作为测试时间段(即，上述的预定时间段)。上述的平均在线玩家数量是根据选取的测试时间段中的玩家人数流量确定的，例如当选取12:30-13:00作为测试时间段时，假设监测到12:30-12:40间的在线人数为1000，12:40-12:50间的在线人数为1100，12:50-13:00间的在线人数为1200，则，该测试时间段中的平均在线玩家数量为1100。

图12是根据本发明实施例对游戏服务器的容量进行测试的装置中确定模块1004的结构框图(二)，如图12所示，该确定模块1004包括第三确定单元1202、第四确定单元1204、扩大单元1206和获取单元1208，下面对该确定模块1004进行说明：

第三确定单元1202，用于从消息的消息号中确定出多个目标消息号；

第四确定单元1204，用于根据消息指示信息确定每个目标消息号下的目标消息的数量与消息的总数之间的比值，其中，所有目标消息号的比值之和大于预定阈值且小于1；

扩大单元1206，用于按比例将所有目标消息号的比值扩大至目标比值，其中，所有目标消息号的目标比值之和等于1；

获取单元1208，用于获取每个目标功能场景对应的所有目标消息号的目标比值之和，作为上述消息在目标功能场景下的消息占比，其中，每个目标消息号对应一个目标功能场景。

在本实施例中全部消息(假定全部消息为消息1-消息21)可以如图5所示，选取的目标消息(假定目标消息为消息1-消息13)可以如图6所示，图6中的消息占比一列为消息1-消息13在全部消息(即，消息1-消息21)中的占比，图6中的测试消息占比一列为消息1-消息13分别在选取的目标消息(即，消息1-消息21)中的占比。在本实施例中，一个目标功能场景可能对应多种目标消息，因此，在确定一个目标功能场景在所有目标功能场景下的占比时，可以根据一个目标功能场景对应的多种消息在所有消息的占比之和来进行确定，具体可参考图7。

图13是根据本发明实施例对游戏服务器的容量进行测试的装置中测试模块1006的结构框图，如图13所示，该测试模块1006包括执行单元1302和记录单元1304，下面对该测试模块1006进行说明：

执行单元1302，用于重复执行以下操作，直到模拟玩家发送的消息的响应时间和响应成功率不符合第一预定条件、或游戏服务器的空闲资源不符合第二预定条件：按照消息占比将当前数量的模拟玩家分别分配到每个目标功能场景中；将每个模拟玩家的消息发送频率设置为平均消息发送频率，其中，消息发送频率用于表示在单位时间内向游戏服务器发送的消息的数量；根据分配的结果和设置的结果对游戏服务器的容量进行测试，并判断测试的过程中模拟玩家发送的消息的响应时间和响应成功率是否符合第一预定条件、且判断游戏服务器的空闲资源是否符合第二预定条件；若响应时间和响应成功率符合第一预定条件、且游戏服务器的空闲资源符合第二预定条件，则将当前数量进行增加，将增加后的结果作为当前数量；

记录单元1304，用于在响应时间和响应成功率不符合第一预定条件、或游戏服务器的资源不符合第二预定条件的情况下，则将前一次的当前数量记录为同时在线的玩家的数量的最大值。

在本实施例中，在通过大样本的真实玩家数据确定了平均消息发送频率和消息在不同目标功能场景下的消息占比时，便可以利用确定的平均消息发送频率和消息在不同目标功能场景下的消息占比对游戏服务器的容量进行测试，在进行测试时，可以利用模拟玩家(即，用于模拟实际玩家的机器人)进行测试，在测试的过程中可以按照确定的平均消息发送频率和消息在不同目标功能场景下的消息占比对模拟玩家进行配置，并利用配置后的模拟玩家进行消息的发送，以实现对游戏服务器的容量的测试，从本实施例中的描述可知，在对游戏服务器的容量进行测试时，需要循环执行一些测试操作，直到确定出符合测试要求的同时在线的玩家的数量的最大值为止。上述的测试操作流程可以参考图8，在图8中，游戏核心功能场景总共有N个，transPer[i]表示第i个核心功能场景的占比；核心功能场景1中Message_ID1_1,Message_ID1_2,Message_ID1_J分别表示第1个核心功能场景的第1个消息标识(Identification，简称为ID)，第2个消息ID，第J个消息ID，并且核心功能场景1总共有J个消息；核心功能场景N中Message_IDN_1,Message_IDN_2,Message_IDN_k分别表示第N个核心功能场景的第1个消息ID，第2个消息ID，第k个消息ID，并且核心功能场景N总共有k个消息。图8中所示的等待时间需要根据具体情况确定(例如，根据某个副本的通关时间)，图8中所示的机器人即本实施例中所述的模拟玩家，在本实施例中可以假设机器人的总数为1万(w)个。

图14是根据本发明实施例对游戏服务器的容量进行测试的装置中获取模块1002和确定模块1004的结构框图，如图14所示，获取模块1002包括获取单元1402，确定模块1004包括第五确定单元1404，下面对各单元进行说明：

获取单元1402，用于分别获取预定天数内的每天的消息指示信息；

第五确定单元1404，用于根据每天的消息指示信息确定预定天数内的每天的平均消息发送频率；并从预定天数内的每天的平均消息发送频率中选取频率值最大的平均消息发送频率作为确定的平均消息发送频率。

在本实施例中，仅仅依据一天的测试结果来确定平均消息发送频率可能是不准确的，因此，可以连续几天(例如，三天)记录在线玩家人数以及统计在线玩家发送的消息的数量，并综合对比几天的记录来确定最终的平均消息发送频率，例如，可以将几天中确定的最大的平均消息发送频率作为最终的消息发送频率。

实施例3

根据本发明实施例，还提供了一种用于实施上述对游戏服务器的容量进行测试的服务器，如图15所示，该服务器包括：

通讯接口1502，用于获取消息指示信息，其中，消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到当前游戏中的不同玩家发送的消息；

处理器1504，用于根据消息指示信息确定平均消息发送频率，以及消息在不同目标功能场景下的消息占比，其中，平均消息发送频率用于指示单位时间内单个玩家向游戏服务器发送的消息的数量，游戏中的功能场景包括多个目标功能场景；以及，根据平均消息发送频率和消息在不同目标功能场景下的消息占比对游戏服务器的容量进行测试，得到测试结果，其中，测试结果包括同时在线的玩家的数量的最大值。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

实施例4

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以位于网络中的多个网络设备中的至少一个网络设备。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

S1，用于获取消息指示信息，其中，消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到当前游戏中的不同玩家发送的消息；

S2，用于根据消息指示信息确定平均消息发送频率，以及消息在不同目标功能场景下的消息占比，其中，平均消息发送频率用于指示单位时间内单个玩家向游戏服务器发送的消息的数量，游戏中的功能场景包括多个目标功能场景；

S3，根据平均消息发送频率和消息在不同目标功能场景下的消息占比对游戏服务器的容量进行测试，得到测试结果，其中，测试结果包括同时在线的玩家的数量的最大值。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S1，根据消息指示信息确定预定时间段内的平均在线玩家数量、以及游戏服务器在预定时间段内接收到的消息的总数；

S2，根据如下公式确定平均消息发送频率：平均消息发送频率＝消息的总数÷平均在线玩家数量÷预定时间段的时长。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S1，从消息的消息号中确定出多个目标消息号；

S2，根据消息指示信息确定每个目标消息号下的目标消息的数量与消息的总数之间的比值，其中，所有目标消息号的比值之和大于预定阈值且小于1；

S3，按比例将所有目标消息号的比值扩大至目标比值，其中，所有目标消息号的目标比值之和等于1；

S4，获取每个目标功能场景对应的所有目标消息号的目标比值之和，作为消息在目标功能场景下的消息占比，其中，每个目标消息号对应一个目标功能场景。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S1，重复执行以下操作，直到模拟玩家发送的消息的响应时间和响应成功率不符合第一预定条件、或游戏服务器的空闲资源不符合第二预定条件：按照消息占比将当前数量的模拟玩家分别分配到每个目标功能场景中；将每个模拟玩家的消息发送频率设置为平均消息发送频率，其中，消息发送频率用于表示在单位时间内向游戏服务器发送的消息的数量；根据分配的结果和设置的结果对游戏服务器的容量进行测试，并判断测试的过程中模拟玩家发送的消息的响应时间和响应成功率是否符合第一预定条件、且判断游戏服务器的空闲资源是否符合第二预定条件；若响应时间和响应成功率符合第一预定条件、且游戏服务器的空闲资源符合第二预定条件，则将当前数量进行增加，将增加后的结果作为当前数量；

S2，若响应时间和响应成功率不符合第一预定条件、或游戏服务器的资源不符合第二预定条件，则将前一次的当前数量记录为同时在线的玩家的数量的最大值。

可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：

S1，分别获取预定天数内的每天的消息指示信息；

S2，根据每天的消息指示信息确定预定天数内的每天的平均消息发送频率；并从预定天数内的每天的平均消息发送频率中选取频率值最大的平均消息发送频率作为确定的平均消息发送频率。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

可选地，本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例，本实施例在此不再赘述。

需要说明的是，上述各实施例主要描述的是对游戏服务器的容量进行测试的方案，上述各实施例中的方案也可以应用到其他类型的服务器的容量测试中。

通过本发明各实施例中的方案，能够准确地模拟线上玩家行为，测试出较为准确地服务器容量结果，让玩家在享受到流畅服务的同时，还能够最大化地利用服务器资源。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (8)

1.一种对游戏服务器的容量进行测试的方法，其特征在于，包括：

获取消息指示信息，其中，所述消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到所述当前游戏中的不同玩家发送的消息；

根据所述消息指示信息确定平均消息发送频率，以及所述消息在不同目标功能场景下的消息占比，其中，所述平均消息发送频率用于指示单位时间内单个玩家向所述游戏服务器发送的消息的数量，所述游戏中的功能场景包括多个所述目标功能场景；

根据所述平均消息发送频率和所述消息在不同目标功能场景下的消息占比对所述游戏服务器的容量进行测试，得到测试结果，其中，所述测试结果包括同时在线的玩家的数量的最大值；

其中，所述获取所述消息指示信息包括：分别获取预定天数内的每天的所述消息指示信息；所述根据所述消息指示信息确定平均消息发送频率包括：根据每天的所述消息指示信息确定所述预定天数内的每天的平均消息发送频率；并从所述预定天数内的每天的平均消息发送频率中选取频率值最大的平均消息发送频率作为确定的所述平均消息发送频率。

2.根据权利要求1所述的方法，其特征在于，根据所述消息指示信息确定所述平均消息发送频率包括：

根据所述消息指示信息确定所述预定时间段内的平均在线玩家数量、以及所述游戏服务器在所述预定时间段内接收到的所述消息的总数；

根据如下公式确定所述平均消息发送频率：

所述平均消息发送频率＝所述消息的总数÷所述平均在线玩家数量÷所述预定时间段的时长。

3.根据权利要求1所述的方法，其特征在于，根据所述消息指示信息确定所述消息在不同目标功能场景下的消息占比包括：

从所述消息的消息号中确定出多个目标消息号；

根据所述消息指示信息确定每个所述目标消息号下的目标消息的数量与所述消息的总数之间的比值，其中，所有所述目标消息号的比值之和大于预定阈值且小于1；

按比例将所有所述目标消息号的比值扩大至目标比值，其中，所有所述目标消息号的目标比值之和等于1；

获取每个所述目标功能场景对应的所有所述目标消息号的目标比值之和，作为所述消息在所述目标功能场景下的消息占比，其中，每个所述目标消息号对应一个所述目标功能场景。

4.根据权利要求1所述的方法，其特征在于，根据所述平均消息发送频率和所述消息在不同目标功能场景下的消息占比对所述游戏服务器的容量进行测试包括：

重复执行以下操作，直到模拟玩家发送的消息的响应时间和响应成功率不符合第一预定条件、或所述游戏服务器的空闲资源不符合第二预定条件：

按照所述消息占比将当前数量的模拟玩家分别分配到每个所述目标功能场景中；

将每个所述模拟玩家的消息发送频率设置为所述平均消息发送频率，其中，所述消息发送频率用于表示在所述单位时间内向所述游戏服务器发送的消息的数量；

根据所述分配的结果和所述设置的结果对所述游戏服务器的容量进行测试，并判断所述测试的过程中所述模拟玩家发送的消息的响应时间和响应成功率是否符合所述第一预定条件、且判断所述游戏服务器的空闲资源是否符合所述第二预定条件；

若响应时间和响应成功率符合所述第一预定条件、且所述游戏服务器的空闲资源符合所述第二预定条件，则将所述当前数量进行增加，将增加后的结果作为所述当前数量；

若响应时间和响应成功率不符合所述第一预定条件、或所述游戏服务器的资源不符合所述第二预定条件，则将前一次的当前数量记录为所述同时在线的玩家的数量的最大值。

5.一种对游戏服务器的容量进行测试的装置，其特征在于，包括：

获取模块，用于获取消息指示信息，其中，所述消息指示信息用于指示当前游戏的游戏服务器在预定时间段内接收到所述当前游戏中的不同玩家发送的消息；

确定模块，用于根据所述消息指示信息确定平均消息发送频率，以及所述消息在不同目标功能场景下的消息占比，其中，所述平均消息发送频率用于指示单位时间内单个玩家向所述游戏服务器发送的消息的数量，所述游戏中的功能场景包括多个所述目标功能场景；

测试模块，用于根据所述平均消息发送频率和所述消息在不同目标功能场景下的消息占比对所述游戏服务器的容量进行测试，得到测试结果，其中，所述测试结果包括同时在线的玩家的数量的最大值；

其中，所述获取模块包括：获取单元，用于分别获取预定天数内的每天的所述消息指示信息；所述确定模块包括：第五确定单元，用于根据每天的所述消息指示信息确定所述预定天数内的每天的平均消息发送频率；并从所述预定天数内的每天的平均消息发送频率中选取频率值最大的平均消息发送频率作为确定的所述平均消息发送频率。

6.根据权利要求5所述的装置，其特征在于，所述确定模块包括：

第一确定单元，用于根据所述消息指示信息确定所述预定时间段内的平均在线玩家数量、以及所述游戏服务器在所述预定时间段内接收到的所述消息的总数；

第二确定单元，用于根据如下公式确定所述平均消息发送频率：

所述平均消息发送频率＝所述消息的总数÷所述平均在线玩家数量÷所述预定时间段的时长。

7.根据权利要求5所述的装置，其特征在于，所述确定模块包括：

第三确定单元，用于从所述消息的消息号中确定出多个目标消息号；

第四确定单元，用于根据所述消息指示信息确定每个所述目标消息号下的目标消息的数量与所述消息的总数之间的比值，其中，所有所述目标消息号的比值之和大于预定阈值且小于1；

扩大单元，用于按比例将所有所述目标消息号的比值扩大至目标比值，其中，所有所述目标消息号的目标比值之和等于1；

获取单元，用于获取每个所述目标功能场景对应的所有所述目标消息号的目标比值之和，作为所述消息在所述目标功能场景下的消息占比，其中，每个所述目标消息号对应一个所述目标功能场景。

8.根据权利要求5所述的装置，其特征在于，所述测试模块包括：

执行单元，用于重复执行以下操作，直到模拟玩家发送的消息的响应时间和响应成功率不符合第一预定条件、或所述游戏服务器的空闲资源不符合第二预定条件：

按照所述消息占比将当前数量的模拟玩家分别分配到每个所述目标功能场景中；

将每个所述模拟玩家的消息发送频率设置为所述平均消息发送频率，其中，所述消息发送频率用于表示在所述单位时间内向所述游戏服务器发送的消息的数量；

根据所述分配的结果和所述设置的结果对所述游戏服务器的容量进行测试，并判断所述测试的过程中所述模拟玩家发送的消息的响应时间和响应成功率是否符合所述第一预定条件、且判断所述游戏服务器的空闲资源是否符合所述第二预定条件；

若响应时间和响应成功率符合所述第一预定条件、且所述游戏服务器的空闲资源符合所述第二预定条件，则将所述当前数量进行增加，将增加后的结果作为所述当前数量；

记录单元，用于在响应时间和响应成功率不符合所述第一预定条件、或所述游戏服务器的资源不符合所述第二预定条件的情况下，则将前一次的当前数量记录为所述同时在线的玩家的数量的最大值。

Images