游戏的测试方法、装置、电子设备及计算机可读介质

摘要

本公开涉及一种游戏的测试方法、装置、电子设备及计算机可读介质，属于游戏测试技术领域。该方法包括：获取游戏的待测试功能的原始方案，并根据原始方案得到待测试功能的待测方案；确定待测试功能的测试服务器，并在测试时间段内，将进入测试服务器的用户划分为对比用户或测试用户，使对比用户根据原始方案进行游戏，测试用户根据待测方案进行游戏；获取对比用户在测试时间段内的对比数据，以及测试用户在测试时间段内的测试数据，并根据对比数据和测试数据得到待测试功能的测试结果。本公开通过将测试服务器中的用户划分为对比用户和测试用户并分别执行对应的原始方案或待测方案，可以降低测试过程中干扰因素的影响，使测试结果更加准确。

说明书

技术领域

本公开涉及游戏测试技术领域，具体而言，涉及一种游戏的测试方法、游戏的测试装置、电子设备及计算机可读介质。

背景技术

在游戏项目中，经常会由于一些新功能的上线而需要对新功能进行测试，从而评估游戏功能改进的效果。

然而在游戏测试的过程中，由于不同服务器中的用户不同，游戏环境也会有所差别，因此会产生各种各样的测试干扰因素，导致测试的结果不够准确。

鉴于此，本领域亟需一种新的游戏的测试方法，以提高游戏测试结果的准确性。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种游戏的测试方法、游戏的测试装置、电子设备及计算机可读介质，进而至少在一定程度上提高游戏测试结果的准确性。

根据本公开的第一个方面，提供一种游戏的测试方法，包括：

获取游戏的待测试功能的原始方案，并根据所述原始方案得到所述待测试功能的待测方案；

确定所述待测试功能的测试服务器，并在测试时间段内，将进入所述测试服务器的用户划分为对比用户或测试用户，使所述对比用户根据所述原始方案进行游戏，所述测试用户根据所述待测方案进行游戏；

获取所述对比用户在所述测试时间段内的对比数据，以及所述测试用户在所述测试时间段内的测试数据，并根据所述对比数据和所述测试数据得到所述待测试功能的测试结果。

在本公开的一种示例性实施例中，所述根据所述原始方案得到所述待测试功能的待测方案，包括：

根据所述原始方案，得到所述原始方案对应的复制方案；

获取所述待测试功能的功能需求，并根据所述功能需求对所述复制方案进行调整，得到所述待测试功能的待测方案。

在本公开的一种示例性实施例中，所述根据所述原始方案，得到所述原始方案对应的复制方案，包括：

将所述原始方案中的所有功能代码和配置数据进行复制，得到所述原始方案对应的复制方案。

在本公开的一种示例性实施例中，所述方法还包括：

获取所述原始方案的索引标识，并根据所述原始方案的索引标识得到所述待测方案的索引标识；

将所述原始方案的配置数据和所述待测方案的配置数据分别根据所述原始方案的索引标识和所述待测方案的索引标识保存在配置表中。

在本公开的一种示例性实施例中，所述使所述对比用户根据所述原始方案进行游戏，所述测试用户根据所述待测方案进行游戏，包括：

通过所述原始方案的索引标识获取所述配置表中所述原始方案的配置数据，并使所述对比用户根据所述原始方案和所述原始方案的配置数据进行游戏；

通过所述待测方案的索引标识获取所述配置表中所述待测方案的配置数据，并使所述测试用户根据所述待测方案和所述待测方案的配置数据进行游戏。

在本公开的一种示例性实施例中，所述将进入所述测试服务器的用户划分为对比用户或测试用户，包括：

获取对比样例数量和测试样例数量，并根据所述对比样例数量和测试样例数量确定所述对比用户和测试用户的比例；

根据所述对比用户和测试用户的比例，将进入所述测试服务器的用户随机划分为对比用户或测试用户。

在本公开的一种示例性实施例中，所述方法还包括：

在所述测试时间段结束时，获取所述测试用户当前的测试数据，作为所述测试用户根据所述待测方案进行游戏后的状态数据；

对所述状态数据进行检测，以确定所述状态数据与所述测试时间段结束后的游戏数据是否相匹配。

根据本公开的第二方面，提供一种游戏的测试装置，包括：

待测方案确定模块，用于获取游戏的待测试功能的原始方案，并根据所述原始方案得到所述待测试功能的待测方案；

测试用户划分模块，用于确定所述待测试功能的测试服务器，并在测试时间段内，将进入所述测试服务器的用户划分为对比用户或测试用户，使所述对比用户根据所述原始方案进行游戏，所述测试用户根据所述待测方案进行游戏；

测试结果确定模块，用于获取所述对比用户在所述测试时间段内的对比数据，以及所述测试用户在所述测试时间段内的测试数据，并根据所述对比数据和所述测试数据得到所述待测试功能的测试结果。

根据本公开的第三方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的游戏的测试方法。

根据本公开的第四方面，提供一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的游戏的测试方法。

本公开示例性实施例可以具有以下有益效果：

本公开示例实施方式的游戏的测试方法中，一方面，通过将测试服务器中的用户划分为对比用户和测试用户并分别执行对应的原始方案或待测方案，实现了同服务器内的用户分组，通过在同一个线上环境内创建对比用户组，获得测试数据，可以减少由于用户成分不同而造成的干扰因素的影响，使测试结果更加准确。另一方面，对于具有复杂服务器架构的实时网络运行项目而言，可以将测试功能带来的风险控制在若干个测试服务器内，对其他服务器的用户来说则无任何影响，而测试过程对于用户来说也毫无干扰。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出了根据本公开的一个具体实施方式的实验室观察法的示意图；

图2示意性示出了根据本公开的一个具体实施方式的AB测试对比的示意图；

图3示出了本公开示例实施方式的游戏的测试方法的流程示意图；

图4示出了本公开示例实施方式的得到待测方案的流程示意图；

图5示出了本公开示例实施方式的配置数据存储的流程示意图；

图6示出了本公开示例实施方式的对比用户和测试用户划分的流程示意图；

图7示意性示出了根据本公开的一个具体实施方式的服务器内部AB测试对比的示意图；

图8示出了本公开示例实施方式的用户根据对应方案进行游戏的流程示意图；

图9示出了本公开示例实施方式的服务器单独推进游戏进程的流程示意图；

图10示出了本公开示例实施方式的服务器和客户端共同推进游戏进程的流程示意图；

图11示出了本公开示例实施方式的游戏测试结束时的状态数据检测的流程示意图；

图12示出了本公开示例实施方式的游戏的测试装置的框图；

图13示出了适于用来实现本公开实施方式的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

在游戏中，由于新功能的上线，因此经常需要进行新功能的测试，将其与原有版本中的功能进行对比，从而评估游戏功能改进的效果。

在一些相关的实施例中，可以通过实验室观察法进行新功能的测试。如图1所示的实验室观察法的示意图中，在目前使用游戏项目的用户中，邀请少量测试用户101到特定的实验室对产品102进行试用，由测试员103采取一对一的方式进行有提问有体验的测试流程，期间项目观察者104则在观察窗口后对测试用户101进行观察，并且事后获得测试期间测试用户101的所有对话反馈，以及终端设备上的操作数据，从而得到测试结果。

在另一些相关的实施例中，还可以通过AB测试对比数据的方法进行新功能的测试。AB测试指的是将待测试功能在上线后特定时间内所产生的数据，与该功能上线前的原有数据进行对比，从而评估改进的差异。正式上线的电子游戏项目中，由于其无时无刻都有玩家(用户)在进行游戏(使用服务)，为了实现用户数据的存储、读写操作等，一个游戏项目往往由多个服务器结构搭建，一般有专门负责登录的登录服务器，以及运行逻辑数据的游戏服务器等等。如图2所示，在游戏项目上应用AB测试的方法，往往是基于服务器来进行对比组区分的。例如，服务器5，6，7是测试服务器，而服务器2，3，4则是用来做对比样例的对比服务器。最终经过一定的测试时间(能够充分让改动影响发展出来的时间)后，对测试数据和对比数据进行数据统计，设定关键数据指标，并根据关键数据指标查看两者间的区别，从而评估改动的效果。

然而，上述AB测试的做法对于游戏用户群体稀少的端游时代，或者是用户群体极为稳定的游戏项目来说，是有一定价值的。因为上述两种情况下，不同的服务器间进入的用户群体的属性是相似的。但是，在手机游戏时代，这种做法则具有很大的弊端。由于目前网络技术的飞速发展，智能手机在各个年龄层的用户间具有非常广泛的普及率。因此一款手机游戏，无论其题材或玩法是什么，它都具有接触到各类用户群体的可能。这就决定了手机游戏项目的一个重要的客观环境：新增用户成分的多样性和多变性。

同一款游戏，在不同时间开启的两个服务器，极可能因为包括但不限于以下因素，使得两个服务器里进入的用户成分有较大的差异：

1、因为法定节假日，寒暑假等假期，造成学生或者白领阶层人群的增多或减少。

2、因某些玩家群体(例如公会等组织)自发约定的集体进入，或者如100服，888服等特殊数字编号的服务器导致大量用户的涌入。

3、因手机游戏自身运营需求而进行的导量买量行为。

4、因短视频平台同人创作，或者直播平台游戏主播等的影响力而进入服务器。

在手机网络发达的如今，上述各种情况的发生是无法提前预知的，而这些情况对AB测试来说都是额外的干扰因素，会使要测试的环境变得复杂，将真正改动引发的变化掩盖在大量由于用户属性不同行为不同而带来的差异之中。因此，需要针对已经线上运营中的游戏项目，最大化地去除AB测试中的干扰因素，让对比差异只存在于测试组与对比组间要测试的改动部分。

针对以上问题，更好的办法是在同一个游戏服务器内进行对比，这样可以最大限度地消除干扰因素。在上述造成用户成分差异的状况发生时，由于用户是在同一个时间离散地进入相同的服务器，所以受到干扰因素的影响是相同的，因此不构成差异。

本示例实施方式首先提供了一种游戏的测试方法。参考图3所示，上述游戏的测试方法可以包括以下步骤：

步骤S310.获取游戏的待测试功能的原始方案，并根据原始方案得到待测试功能的待测方案。

步骤S320.确定待测试功能的测试服务器，并在测试时间段内，将进入测试服务器的用户划分为对比用户或测试用户，使对比用户根据原始方案进行游戏，测试用户根据待测方案进行游戏。

步骤S330.获取对比用户在测试时间段内的对比数据，以及测试用户在测试时间段内的测试数据，并根据对比数据和测试数据得到待测试功能的测试结果。

本公开示例实施方式的游戏的测试方法中，一方面，通过将测试服务器中的用户划分为对比用户和测试用户并分别执行对应的原始方案或待测方案，实现了同服务器内的用户分组，通过在同一个线上环境内创建对比用户组，获得测试数据，可以减少由于用户成分不同而造成的干扰因素的影响，使测试结果更加准确。另一方面，对于具有复杂服务器架构的实时网络运行项目而言，可以将测试功能带来的风险控制在若干个测试服务器内，对其他服务器的用户来说则无任何影响，而测试过程对于用户来说也毫无干扰。

下面，结合图4至图11对本示例实施方式的上述步骤进行更加详细的说明。

在步骤S310中，获取游戏的待测试功能的原始方案，并根据原始方案得到待测试功能的待测方案。

本示例实施方式中，获取游戏的待测试功能一般指的是游戏需要上线的新功能，包括游戏中的一些新玩法、新任务线等等。待测试功能调整和优化所针对的原有功能即为原始方案，原始方案是被验证的线上运行无异常的正确方案。待测方案指的是新开发的对游戏效果具有不确定性的待测试的方案，而待测试的新功能可以被开发为一个独立的待测方案，存储于游戏代码中，可以随时通过开关进行控制采用或下线。

本示例实施方式中，如图4所示，根据原始方案得到待测试功能的待测方案，具体可以包括以下几个步骤：

步骤S410.根据原始方案，得到原始方案对应的复制方案。

本示例实施方式中，将原始方案中的所有功能代码和配置数据进行复制，可以得到原始方案对应的复制方案。

步骤S420.获取待测试功能的功能需求，并根据功能需求对复制方案进行调整，得到待测试功能的待测方案。

本示例实施方式中，可以根据待测试的新功能的需求，针对复制方案进行二次开发或调整得到待测方案，使其满足待测试功能的功能需求，从而完整地实现待测试功能。

由于一个游戏项目中往往由大量开发人员组成的开发团队进行维护，即使是同一个功能的不同调整，也可能由不同的人进行完成。开发人员的个人习惯、编码风格、功能实现的思路、架构思想等往往有巨大的差异，即使约束于同一个项目的代码规范下，仍有很多的个人发挥空间。这种开发人员的个体差异在制作新功能时尤为明显，如无约束，新功能的实现方式很可能将与原有功能产生巨大差异，虽然都能实现新功能，但是却可能产生额外的影响。

而本示例实施方式中，是在开发新功能方案前，先对原始方案进行复制，在原始方案的结构基础上进行开发，只针对新功能所要改进的点进行调整，因此，能更有效地保证功能代码的一致性，更加细化地约束改进范围，以尽量减少产生差异的因素，并且对新功能改动可能产生的连带影响具有一定的控制作用。

通过对原始方案的复制，相当于对原始方案的所有配置、代码逻辑等内容进行了一次复盘，在开发新的功能时，对原始方案做出的调整可以细化具体到非常细节的程度。比如说，小到一个UI(用户界面，User Interface)控件的层级，坐标的像素偏移，大到一个功能的流程改变等，只要管理好功能两端的输入和输出，功能中间的所有内容都可以进行调整。

在得到待测试功能的待测方案之后，如图5所示，本示例实施方式还可以包括以下几个步骤：

步骤S510.获取原始方案的索引标识，并根据原始方案的索引标识得到待测方案的索引标识。

步骤S520.将原始方案的配置数据和待测方案的配置数据分别根据原始方案的索引标识和待测方案的索引标识保存在配置表中。

本示例实施方式中，在开发阶段，可以在代码中使用固定的标记方案进行识别，根据原始方案的索引标识得到待测方案的索引标识，例如，可以将复制方案的配置表或者索引id固定为原始方案索引id+100000等。然后，再根据原始方案的索引标识和待测方案的索引标识，将原始方案的配置数据和待测方案的配置数据分别保存在配置表中。

继续参考图3，在步骤S320中，确定待测试功能的测试服务器，并在测试时间段内，将进入测试服务器的用户划分为对比用户或测试用户，使对比用户根据原始方案进行游戏，测试用户根据待测方案进行游戏。

本示例实施方式中，正常线上运营的游戏服务器均采用原始方案运行。在到达预先设定的测试时间时，可以通过后台控制更换方案进行AB测试。在测试时间段内后台更改为AB测试阶段时，被设置为测试服务器中所进来的用户，会被随机地分配使用原始方案或者待测方案进行游戏。用户的分配是完全随机的，可以按照预设比例，例如50％-50％的比例进行分配。而当测试时间段结束时，可以从控制台关闭测试，后续服务器又会重新回到原始方案的状态。通过这样的测试方法，不仅能在最真实的外网环境下，获得同服务器内不同方案下用户数据的对比信息，并且对于新方案可能带来的影响风险也控制到了最小。

本示例实施方式中，如图6所示，将进入测试服务器的用户划分为对比用户或测试用户，具体可以包括以下几个步骤：

步骤S610.获取对比样例数量和测试样例数量，并根据对比样例数量和测试样例数量确定对比用户和测试用户的比例。

步骤S620.根据对比用户和测试用户的比例，将进入测试服务器的用户随机划分为对比用户或测试用户。

本示例实施方式中，可以根据具体的测试需求，确定执行原始方案的对比样例的数量，以及执行待测方案的测试样例的数量，再根据对比样例数量和测试样例数量确定对比用户和测试用户的比例。例如，需要测试的待测方案只有一种，原始方案为一种，则对比用户和测试用户的比例即为1:1；如果需要测试的待测方案有两种，原始方案为一种，则对比用户和测试用户的比例即为1:2。

本示例实施方式中，可以支持超过两个对比样例，只需要需求方将每一种需求描述清楚，然后程序根据规则具体确认玩家使用哪一个对比样例即可，一般是在创建角色时根据玩家ID来随机决定。

如图7所示是服务器内部AB测试对比的示意图，测试服务器为服务器5，6，7，当时间线到达测试时间段时，将每个测试服务器中的用户按照1:1的比例划为对比用户与测试用户，A组为对比组，执行原始方案，而B组则为测试组，执行待测方案。

本示例实施方式中，如图8所示，使对比用户根据原始方案进行游戏，测试用户根据待测方案进行游戏，具体可以包括以下几个步骤：

步骤S810.通过原始方案的索引标识获取配置表中原始方案的配置数据，并使对比用户根据原始方案和原始方案的配置数据进行游戏。

步骤S820.通过待测方案的索引标识获取配置表中待测方案的配置数据，并使测试用户根据待测方案和待测方案的配置数据进行游戏。

在之前的步骤中，已经将原始方案的配置数据和待测方案的配置数据分别根据原始方案的索引标识和待测方案的索引标识保存在配置表中，因此，在测试阶段执行时，需要通过原始方案的索引标识获取配置表中原始方案的配置数据，并使对比用户根据原始方案和原始方案的配置数据进行游戏；以及通过待测方案的索引标识获取配置表中待测方案的配置数据，并使测试用户根据待测方案和待测方案的配置数据进行游戏。

游戏过程中玩家的游戏进度都是存储于服务器的，而进度推进的数据来源分为两种，一种是服务器主动记录获取，另一种是客户端服务器共同推动进度，这种情况下，一般是由客户端按照正常游戏协议发送，然后在一些约定内容上，再由服务器根据客户端推送的协议来推动进度。

服务器单独推进游戏进度的流程示意图如图9所示，具体可以包括以下几个步骤：

步骤S910.创角流程。

步骤S920.决定对比线。

步骤S930.服务器处理。

步骤S940.客户端处理。

如图9所示的游戏进度推进的方法主要是针对配置数据来进行区分的，服务器确定整个流程的推进，而客户端只做纯显示功能，也就是说，客户端是通用逻辑，不需要区分用户当前走的是哪条对比线。以任务为例，如果玩家执行的是两条不同的任务线，两条任务线的配置数据都在同一个配置表中，其中一条任务线的用户ID从10000开始，而用于对比的一条任务线的用户ID从10000000开始，这样一来，服务器在玩家生成时就确定了玩家的任务ID。

而后续任务的开启都可以通过类似于上述的方法进行推进，在玩家需要开启新任务的时候，服务器记录下对应的任务ID，生成的数据存储在配置表中。客户端在做任务显示的时候，只需要去配置表中读取当前进行中的任务，然后根据当前进行中的任务组织数据，在显示时根据任务ID从配置表中去读取需要显示的字段即可，客户端实际上不用关心玩家当前执行的是一条任务线。

服务器和客户端共同推进游戏进度的流程示意图如图10所示，具体可以包括以下几个步骤：

步骤S1010.创角流程。

步骤S1020.决定对比线。

步骤S1030.服务器处理。

步骤S1040.客户端处理。

步骤S1050.综合服务器和客户端信息获得进度信息。

如图10所示的游戏进度推进的方法一般来说配置更多是涉及客户端的，客户端将具体执行的步骤与服务器约定好，由客户端发送具体的协议，服务器在关键节点上记录进度，然后将进度数据推送给客户端，客户端再根据进度数据确认继续执行以及中途玩家退出再进入的开始步骤。以新手引导的任务为例，客户端存在配置表1和配置表2，里面记录了新手引导任务所要显示的具体内容。然后客户端同服务器约定以每次出征作为关键点，在关键点上，服务器会刷新玩家的进度字段，引导地图的显示变化，这一部分是由服务器单独处理的，因此服务器需要区分使用的是哪种引导方式。而客户端在这一部分也需要区分引导方式，然后在不同的地方做显示分支的判断。这一部分的实现依赖系统的复杂度，因为引导是一个比较复杂的系统，所以客户端会通过大量代码去判断如何引导，以及需要在哪些地方做特殊处理。

继续参考图3，在步骤S330中，获取对比用户在测试时间段内的对比数据，以及测试用户在测试时间段内的测试数据，并根据对比数据和测试数据得到待测试功能的测试结果。

对比数据是对比用户在测试时间段内，通过执行原始方案得到的游戏数据，测试数据是测试用户在测试时间段内，通过执行待测方案得到的游戏数据。通过获取对比数据和测试数据，并比较二者的差异，可以得到待测试功能的测试结果。

在测试时间段结束时，如图11所示，本示例实施方式中的游戏的测试方法还可以包括以下几个步骤：

步骤S1110.在测试时间段结束时，获取测试用户当前的测试数据，作为测试用户根据待测方案进行游戏后的状态数据。

用户的状态数据指的是用户在完成测试方案时的最终状态下的测试数据，属于测试数据的一部分，这部分的最终状态数据需要在测试结束时能够与其他游戏内容正常对接。

步骤S1120.对状态数据进行检测，以确定状态数据与测试时间段结束后的游戏数据是否相匹配。

在测试时间段结束时，还需要针对行为日志、版本标记等数据信息进行补全，然后检查用户的状态数据，确保待测方案下用户最终状态的游戏数据能够与其他游戏内容的数据相匹配，保证待测方案与其他游戏内容正常对接。

除此之外，本示例实施方式中，可以通过约定合适的测试时间，在后台控制进行测试。通过开发对游戏服进行控制的后台控制器，能够设置关闭或打开不同方案，以及开启测试模式等功能，并且整个过程无需服务器重启或更新文件，对玩家来说控制过程完全无感。其中，不仅对于已经进入服务器的玩家是完全无感的，已经接触到待测试功能的用户会继续按照原版本进行，而新进入的用户则会根据配置，获得待测的新方案或者原始方案，而新进入的用户并不知晓另一套方案的存在，因此整个过程对用户游戏体验来说毫无干扰。

后台工具对于功能的控制可以细化到每一台服务器上，一旦新功能出现重大问题，在最坏的情况下也只会导致一台服务器的用户体验下降，只要更改配置关闭测试，对后续的新用户则无影响。由于新功能都在不同程度上具有未知的风险可能，因此这种随时关停，区分服务器的方法可以将风险控制在一个服务器内，对具有上千个游戏服在运行的大型游戏来说，可以将风险控制在极小的范围内。

应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

进一步的，本公开还提供了一种游戏的测试装置。参考图12所示，该游戏的测试装置可以包括待测方案确定模块1210、测试用户划分模块1220以及测试结果确定模块1230。其中：

待测方案确定模块1210可以用于获取游戏的待测试功能的原始方案，并根据原始方案得到待测试功能的待测方案；

测试用户划分模块1220可以用于确定待测试功能的测试服务器，并在测试时间段内，将进入测试服务器的用户划分为对比用户或测试用户，使对比用户根据原始方案进行游戏，测试用户根据待测方案进行游戏；

测试结果确定模块1230可以用于获取对比用户在测试时间段内的对比数据，以及测试用户在测试时间段内的测试数据，并根据对比数据和测试数据得到待测试功能的测试结果。

在本公开的一些示例性实施例中，待测方案确定模块1210可以包括复制方案确定单元以及复制方案调整单元。其中：

复制方案确定单元可以用于根据原始方案，得到原始方案对应的复制方案；

复制方案调整单元可以用于获取待测试功能的功能需求，并根据功能需求对复制方案进行调整，得到待测试功能的待测方案。

在本公开的一些示例性实施例中，复制方案确定单元可以包括数据代码复制单元，可以用于将原始方案中的所有功能代码和配置数据进行复制，得到原始方案对应的复制方案。

在本公开的一些示例性实施例中，待测方案确定模块1210还可以包括索引标识确定单元以及配置数据保存单元。其中：

索引标识确定单元可以用于获取原始方案的索引标识，并根据原始方案的索引标识得到待测方案的索引标识；

配置数据保存单元可以用于将原始方案的配置数据和待测方案的配置数据分别根据原始方案的索引标识和待测方案的索引标识保存在配置表中。

在本公开的一些示例性实施例中，测试用户划分模块1220可以包括原始方案执行单元以及待测方案执行单元。其中：

原始方案执行单元可以用于通过原始方案的索引标识获取配置表中原始方案的配置数据，并使对比用户根据原始方案和原始方案的配置数据进行游戏；

待测方案执行单元可以用于通过待测方案的索引标识获取配置表中待测方案的配置数据，并使测试用户根据待测方案和待测方案的配置数据进行游戏。

在本公开的一些示例性实施例中，测试用户划分模块1220还可以包括测试比例确定单元以及测试用户划分单元。其中：

测试比例确定单元可以用于获取对比样例数量和测试样例数量，并根据对比样例数量和测试样例数量确定对比用户和测试用户的比例；

测试用户划分单元可以用于根据对比用户和测试用户的比例，将进入测试服务器的用户随机划分为对比用户或测试用户。

在本公开的一些示例性实施例中，本公开提供的一种游戏的测试装置还可以包括状态数据获取模块以及状态数据检测模块。其中：

状态数据获取模块可以用于在测试时间段结束时，获取测试用户当前的测试数据，作为测试用户根据待测方案进行游戏后的状态数据；

状态数据检测模块可以用于对状态数据进行检测，以确定状态数据与测试时间段结束后的游戏数据是否相匹配。

上述游戏的测试装置中各模块/单元的具体细节在相应的方法实施例部分已有详细的说明，此处不再赘述。

图13示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图13示出的电子设备的计算机系统1300仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图13所示，计算机系统1300包括中央处理单元(CPU)1301，其可以根据存储在只读存储器(ROM)1302中的程序或者从存储部分1308加载到随机访问存储器(RAM)1303中的程序而执行各种适当的动作和处理。在RAM 1303中，还存储有系统操作所需的各种程序和数据。CPU1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

以下部件连接至I/O接口1305：包括键盘、鼠标等的输入部分1306；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1307；包括硬盘等的存储部分1308；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1309。通信部分1309经由诸如因特网的网络执行通信处理。驱动器1310也根据需要连接至I/O接口1305。可拆卸介质1311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1310上，以便于从其上读出的计算机程序根据需要被安装入存储部分1308。

特别地，根据本发明的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1309从网络上被下载和安装，和/或从可拆卸介质1311被安装。在该计算机程序被中央处理单元(CPU)1301执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。