CN113485925A

CN113485925A - 游戏测试方法、装置、设备、存储介质

Info

Publication number: CN113485925A
Application number: CN202110750825.5A
Authority: CN
Inventors: 邓伟成; 胡娟娟
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2021-07-01
Filing date: 2021-07-01
Publication date: 2021-10-08

Abstract

本申请提供一种游戏测试方法、装置、设备、存储介质，可以获取多个子数据类型，并根据所述多个子数据类型生成游戏数据，所述游戏数据中包括与每个子数据类型对应的游戏子数据；根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果，通过待测试代码对所述游戏数据进行处理，得到第二游戏结果；根据所述第一游戏结果和所述第二游戏结果，确定所述待测试代码对应的测试结果。上述测试过程提高了测试效率。

Description

游戏测试方法、装置、设备、存储介质

技术领域

本申请实施例涉及数据处理技术领域，尤其涉及一种游戏测试方法、装置、设备、存储介质。

背景技术

随着网络和终端技术的发展，用户可以通过终端设备进行棋牌游戏。每种棋牌游戏在不同区域有其特定的玩法(即游戏规则)，使得棋牌游戏的玩法众多。

尽管棋牌游戏的玩法众多，但是不同玩法之间依然存在很多共性，这些共性在服务端采用公共代码的形式实现。例如，以麻将为例，在麻将游戏过程中，在每次玩家行牌之后，服务端检测每个玩家的牌型是否满足胡牌规则。进一步的，在检测到满足胡牌规则的情况下，还需要针对该牌型进行番型和番数的识别，识别结果用于进行玩家结算。在服务端，不同麻将玩法对应的胡牌判断逻辑、番型和番数的识别逻辑均可以采用公共代码实现。

在棋牌游戏开发过程中，如果对公共代码做了修改，则需要针对所有玩法进行回归测试。通常，在对棋牌游戏进行回归测试时，采用人工手动测试的方式。例如，以麻将为例，在针对番型和番数的识别逻辑进行回归测试时，需要测试人员以真实玩家的身份采用不同玩法进行麻将游戏，并在游戏过程中，通过一系列的行牌流程使得牌型满足胡牌规则。进而，测试人员检查服务端针对该牌型识别出的番型和番数是否准确。

然而，上述采用人工手动测试的方式，使得测试效率较低。

发明内容

本申请实施例提供一种游戏测试方法、装置、设备、存储介质，用以提高游戏测试效率。

第一方面，本申请提供一种游戏测试方法，包括：

获取多个子数据类型，并根据所述多个子数据类型生成游戏数据，所述游戏数据中包括与每个子数据类型对应的游戏子数据；

根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果；

通过待测试代码对所述游戏数据进行处理，得到第二游戏结果；

根据所述第一游戏结果和所述第二游戏结果，确定所述待测试代码对应的测试结果。

一种可能的实现方式中，获取多个子数据类型，包括：

获取游戏对象的总对象数量；

根据所述总对象数量，确定M个第一子数据类型和N个第二子数据类型，所述多个子数据类型包括所述M个第一子数据类型和N个第二子数据类型；

其中，所述M个第一子数据类型和N个第二子数据类型对应的对象数量之和为所述总对象数量，所述M为大于或等于1的整数，所述N为大于或等于0的整数。

一种可能的实现方式中，根据所述总对象数量，确定M个第一子数据类型和N个第二子数据类型，包括：

确定预设子数据类型；

根据所述预设子数据类型对应的对象数量和所述总对象数量，确定M-1个第一子数据类型，所述M个第一子数据类型包括所述预设子数据类型和所述M-1个第一子数据类型；

根据所述总对象数量和所述M个第一子数据类型对应的对象数量，确定所述N个第二子数据类型。

一种可能的实现方式中，根据所述预设子数据类型对应的对象数量和所述总对象数量，确定M-1个第一子数据类型，包括：

将所述总对象数量和所述预设子数据类型对应的对象数量的差值确定为第一剩余对象数量；

根据所述第一剩余对象数量，确定所述M-1个第一子数据类型，所述M-1个第一子数据类型对应的对象数量之和小于或等于所述第一剩余对象数量。

一种可能的实现方式中，根据所述总对象数量和所述M个第一子数据类型对应的对象数量，确定所述N个第二子数据类型，包括：

将所述总对象数量和所述M个第一子数据类型对应的对象数量的差值确定为第二剩余对象数量；

若所述第二剩余对象数量为0，则确定所述N为0；

若所述第二剩余对象数量大于0，则根据所述第二剩余对象数量确定所述N个第二子数据类型。

一种可能的实现方式中，根据所述多个子数据类型生成游戏数据，包括：

针对每个子数据类型，获取所述子数据类型对应的游戏子数据；

根据所述多个子数据类型各自对应的游戏子数据，生成所述游戏数据。

一种可能的实现方式中，获取所述子数据类型对应的游戏子数据，包括：

在预设数据库中获取所述子数据类型对应的游戏子数据；或者，

按照预设算法随机生成所述子数据类型对应的游戏子数据；或者，

显示可视化界面，接收用户在所述可视化界面输入的所述子数据类型对应的游戏子数据。

一种可能的实现方式中，根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果，包括：

根据所述多个子数据类型，确定所述游戏数据对应的子数据类型组合方式；

根据所述子数据类型组合方式查询预设对应关系，确定所述第一游戏结果，所述预设对应关系用于指示不同子数据类型组合方式与不同第一游戏结果之间的对应关系。

第二方面，本申请提供一种游戏测试装置，包括：

获取模块，用于获取多个子数据类型，并根据所述多个子数据类型生成游戏数据，所述游戏数据中包括与每个子数据类型对应的游戏子数据；

第一确定模块，用于根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果；

处理模块，用于通过待测试代码对所述游戏数据进行处理，得到第二游戏结果；

第二确定模块，用于根据所述第一游戏结果和所述第二游戏结果，确定所述待测试代码对应的测试结果。

一种可能的实现方式中，所述获取模块具体用于：

获取游戏对象的总对象数量；

一种可能的实现方式中，所述获取模块具体用于：

确定预设子数据类型；

一种可能的实现方式中，所述获取模块具体用于：

若所述第二剩余对象数量为0，则确定所述N为0；

一种可能的实现方式中，所述获取模块具体用于：

一种可能的实现方式中，所述第一确定模块具体用于：

第三方面，本申请提供一种电子设备，包括：存储器和处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序实现如第一方面任一项所述的方法。

第四方面，本申请提供一种计算机可读存储介质，包括：计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项所述的方法。

第五方面，本申请提供一种计算机程序产品，包括：计算机程序，所述计算机程序被处理器执行时实现如第一方面任一项所述的方法。

本申请提供的游戏测试方法、装置、设备、存储介质，可以获取多个子数据类型，并根据所述多个子数据类型生成游戏数据，所述游戏数据中包括与每个子数据类型对应的游戏子数据；根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果，通过待测试代码对所述游戏数据进行处理，得到第二游戏结果；根据所述第一游戏结果和所述第二游戏结果，确定所述待测试代码对应的测试结果。上述过程中，通过根据多个子数据类型生成游戏数据，使得无需经过虚拟客户端或者真实客户端的行牌流程，即可生成游戏数据，进而，可以利用生成的游戏数据对待测试代码进行自动测试，提高了测试效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例中棋牌游戏所涉及的系统架构的示意图；

图2为本申请实施例提供的测试场景示意图；

图3为本申请实施例提供的一种游戏测试方法的流程示意图；

图4为本申请实施例提供的游戏数据的生成过程的示意图；

图5为本申请实施例提供的另一种游戏测试方法的流程示意图；

图6A至图6G为本申请实施例提供的一组可视化界面的示意图；

图7为本申请实施例提供的一种游戏测试装置的结构示意图；

图8为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本申请实施例适用于对棋牌游戏进行回归测试的场景。为了便于理解本申请的方案，首先结合图1对棋牌游戏所涉及的系统架构进行介绍。

图1为本申请实施例中棋牌游戏所涉及的系统架构的示意图。如图1所示，该系统架构包括客户端和服务端。其中，客户端的数量可以为一个或者多个。应理解，针对不同类型的棋牌游戏，客户端的数量可能不同。例如，麻将游戏对应4个客户端，斗地主游戏对应3个客户端，等。每个客户端可以对应一个玩家。

需要说明的是，本申请实施例对于棋牌游戏的类型不作限定。但是为了描述方便，后续举例说明时均以麻将游戏为例进行举例说明。

在棋牌游戏过程中，客户端和服务端之间可以进行交互。以麻将游戏过程为例，服务端进行洗牌，洗牌后为每个客户端发牌。以4个客户端为例，发牌结束后，每个客户端拥有13张麻将牌。后续进行行牌流程，行牌流程包括但不限于：抓牌、出牌、吃牌、碰牌、开杠(明杠、暗杠)等。

示例性的，如图1所示，服务端中可以部署游戏代码。例如，服务器中部署有用于实现胡牌判断逻辑的代码，以及用于实现番型和番数的识别逻辑的代码。在每次行牌之后，服务端利用游戏代码检测每个玩家的牌型是否满足胡牌规则。进一步的，在检测到满足胡牌规则的情况下，还可以利用游戏代码对该牌型进行番型和番数的识别，识别结果用于进行玩家结算。

实际应用中，麻将的多种玩法对应的代码中可以存在公共代码。在开发过程中，如果对公共代码做了修改，则需要针对所有的玩法进行回归测试。通常，在进行回归测试时，采用人工手动测试的方式。例如，在针对番型和番数的识别逻辑进行回归测试时，需要测试人员以真实玩家的身份采用不同玩法进行麻将游戏，并在游戏过程中，通过一系列的行牌流程使得牌型满足胡牌规则。进而，测试人员检查服务端针对胡牌牌型识别出的番型和番数是否准确。

然而，上述测试方式中，需要测试人员以真实玩家的身份通过真实的行牌流程构建出胡牌牌型，使得测试效率较低。由于麻将的玩法众多，每次对公共代码进行修改后，都需要针对所有的玩法进行回归测试，需要花费的人力成本和时间成本较高。另外，对测试人员的要求较高，需要测试人员充分了解不同玩法的规则。

为了解决上述技术问题中的至少一个，本申请实施例提供一种游戏测试方法、装置、设备、存储介质。下面结合图2对本申请的发明构思进行说明。

图2为本申请实施例提供的测试场景示意图。如图2所示，本申请实施例提供的游戏测试方法可以由测试设备执行。其中，测试设备可以为任意具有数据处理能力的电子设备，例如，可以为终端设备，还可以为服务器。

本申请技术方案中，测试设备在测试过程中，无需经过虚拟客户端或者真实客户端的行牌流程，即可生成游戏数据(例如，游戏数据为满足胡牌规则的一组牌)，进而，可以利用游戏数据对服务端的游戏代码进行自动化测试，从而提高测试效率。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图3为本申请实施例提供的一种游戏测试方法的流程示意图。本实施例的测试方法可以由测试设备执行。可选的，测试设备的数量可以为一个或者多个。当测试设备的数量为多个时，每个测试设备可以执行本实施例中的一个或者多个步骤。

如图3所示，本实施例的方法，包括：

S301：获取多个子数据类型，并根据所述多个子数据类型生成游戏数据，所述游戏数据中包括与每个子数据类型对应的游戏子数据。

本实施例的应用场景中，需要对待测试代码的处理逻辑进行测试。待测试代码可以为一个棋牌游戏的全部代码或者部分代码。示例性的，待测试代码可以为图1或图2中服务端的游戏代码。

以麻将游戏为例，待测试代码可以为用于实现胡牌判断逻辑的代码。待测试代码还可以为用于实现番型和番数的识别逻辑的代码。应理解的是，无论是针对胡牌判断逻辑进行测试，还是针对番型和番数的识别逻辑进行测试，其测试流程和原理是类似的。本申请实施例为了描述方便，后续均以针对番型和番数的识别逻辑进行测试的场景为例进行举例说明。

在本申请实施例的场景中，将麻将中的一张牌称为一个游戏对象。游戏数据为待测试代码的输入。游戏数据为满足胡牌规则的一组牌。游戏数据中包括14个游戏对象，即14张牌。

本申请实施例中，无需测试人员以真实玩家的身份通过一系列的行牌流程生成游戏数据。而是可以获取多个子数据类型，根据所述多个子数据类型生成游戏数据。其中，游戏数据中包括与每个子数据类型对应的游戏子数据。

其中，子数据类型是指游戏子数据的类型。游戏子数据是指满足一定规则的多个游戏对象。例如，对子(即两张一样的牌)可以称为一个游戏子数据，顺子(即多张花色相同且牌值相连的牌)也可以称为一个游戏子数据，碰可以称为一个游戏子数据，明杠也可以称为一个游戏子数据，吃也可以称为一个游戏子数据，等等。每个游戏子数据对应有子数据类型。其中，子数据类型可以为下述中的任意一种：对子类型、顺子类型、碰类型、明杠类型、暗杠类型、吃类型等。其中，本实施例中，明杠和暗杠作为游戏子数据时，仅考虑作为手牌的3张麻将牌。也就是说，明杠类型的游戏子数据中包括3个游戏对象，暗杠类型的游戏子数据中包括3个游戏对象。

本实施例应用场景中，游戏数据是满足胡牌规则的一组牌。游戏数据中包括多个游戏子数据，每个游戏子数据包括至少两个牌。

需要说明的是，S301中获取的多个子数据类型中的任意两个子数据类型可以均不相同，或者，S301中获取的多个子数据类型中可以存着相同的子数据类型，本实施例对此不作限定。

获取到多个子数据类型后，可以针对每个子数据类型，生成该子数据类型对应的游戏子数据。进而，根据所述多个子数据类型各自对应的游戏子数据，生成游戏数据。

举例而言，一个示例中，假设获取的多个子数据类型分别为：对子类型、明杠类型、明杠类型、明杠类型、明杠类型，则根据上述4个子数据类型可以生成如下游戏数据：

{对子类型{一萬、一萬}、明杠类型{五萬、五萬、五萬}、明杠类型{六萬、六萬、六萬}、明杠类型{七萬、七萬、七萬}、明杠类型{八萬、八萬、八萬}}。

另一个示例中，假设获取的多个子数据类型分别为：对子类型、对子类型、对子类型、对子类型、对子类型、对子类型、对子类型，则根据上述7个子数据类型可以生成如下游戏数据：

{对子类型{一萬、一萬}、对子类型{二条、二条}、对子类型{三筒、三筒}、对子类型{四萬、四萬}、对子类型{五筒、五筒}、对子类型{六萬、六萬}、对子类型{七条、七条}}。

又一个示例中，假设获取的多个子数据类型分别为：对子类型、顺子类型、顺子类型、明杠类型、碰类型，则根据上述5个子数据类型可以生成如下游戏数据：

{对子类型{六萬、六萬}、顺子类型{二条、三条、四条}、顺子类型{一萬、二萬、三萬}、明杠类型{五萬、五萬、五萬}、碰类型{四筒、四筒、四筒}}。

S302：根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果。

本实施例应用场景中，游戏结果是指游戏数据对应的番型和番数。第一游戏结果是指根据多个子数据类型确定出的游戏数据对应的番型和番数。第一游戏结果也可以称为预期游戏结果，用于对后续S303中得到到第二游戏结果进行校验。

能够理解的，当游戏数据所包括的各游戏子数据对应的子数据类型确定后，该游戏数据对应的番型和番数也就是确定的了。因此，可以根据所述多个子数据类型，确定出游戏数据对应的第一游戏结果。

一种可能的实现方式中，可以根据所述多个子数据类型，确定出游戏数据对应的子数据类型组合方式，根据所述子数据类型组合方式查询预设对应关系，确定所述第一游戏结果，所述预设对应关系用于指示不同子数据类型组合方式与不同第一游戏结果之间的对应关系。

例如，预设对应关系可以如表1所示。

表1

S303：通过待测试代码对所述游戏数据进行处理，得到第二游戏结果。

本实施例应用场景中，待测试代码为用于实现番型和番数的识别逻辑的代码，则第二游戏结果是指通过待测试代码识别得到的番型和番数。

S304：根据所述第一游戏结果和所述第二游戏结果，确定所述待测试代码对应的测试结果。

具体的，将第一游戏结果和第二游戏结果进行比对，若第一游戏结果与第二游戏结果相同，则确定待测试代码对应的测试结果为通过。若第一游戏结果与第二游戏结果不同，则确定待测试代码对应的测试结果为不通过。

应理解的是，本实施例中描述的是利用一个游戏数据对待测试代码进行测试的过程。实际应用过程中，本实施例的方法可以重复执行多次，每次执行生成不同的游戏数据，从而利用多个游戏数据对待测试代码进行测试，保证测试结果的准确性。

本实施例提供的游戏测试方法，包括：获取多个子数据类型，并根据所述多个子数据类型生成游戏数据，所述游戏数据中包括与每个子数据类型对应的游戏子数据；根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果，通过待测试代码对所述游戏数据进行处理，得到第二游戏结果；根据所述第一游戏结果和所述第二游戏结果，确定所述待测试代码对应的测试结果。上述过程中，通过根据多个子数据类型生成游戏数据，使得无需经过虚拟客户端或者真实客户端的行牌流程，即可生成游戏数据，进而，可以利用生成的游戏数据对待测试代码进行自动测试，提高了测试效率，并且，测试人员无需了解各种玩法的具体规则，降低了对测试人员的要求。

在上述实施例的基础上，下面结合一个更具体的实施例描述游戏数据的生成过程。

图4为本申请实施例提供的游戏数据的生成过程的示意图。本实施例可以作为图3中的S301的一种可能的实现方式。如图4所示，本实施例的方法可以包括：

S401：获取游戏对象的总对象数量。

其中，游戏对象的总对象数量是指：游戏数据中所包括的游戏对象的数量。例如，在针对番型和番数的识别逻辑进行测试的场景中，游戏数据是满足胡牌规则的一组牌，因此，游戏数据中所包括的游戏对象的数量为14。

S402：根据所述总对象数量，确定M个第一子数据类型和N个第二子数据类型。

其中，所述M个第一子数据类型和N个第二子数据类型对应的对象数量之和为所述总对象数量，所述M为大于或等于1的整数，所述N为大于或等于0的整数，

在麻将游戏中，可以将每个玩家的麻将牌分为2类，一类称为手牌，一类称为明牌。其中，手牌是指玩家未公开的麻将牌。明牌是指玩家已公开的麻将牌。当发生胡牌时，胡牌牌型中的麻将牌可以全部是手牌，也可以部分是手牌部分是明牌。

本实施例中，第一子数据类型为手牌中的游戏子数据的类型。第一子数据类型可以包括但不限于：对子类型、顺子类型等。第二子数据类型为明牌中的游戏子数据的类型，第二子数据类型可以包括但不限于：明杠类型、暗杠类型、碰类型、吃类型、刻子类型、顺子类型等。

一种可能的实现方式中，可以采用如下方式确定出M个第一子数据类型和N个第二子数据类型：

(1)确定预设子数据类型。

以麻将游戏为例，麻将游戏发生胡牌时，胡牌牌型中一定包括对子。因此，本实施例中预设子数据类型可以为对子类型。

(2)根据所述预设子数据类型对应的对象数量和所述总对象数量，确定M-1个第一子数据类型，所述M个第一子数据类型包括所述预设子数据类型和所述M-1个第一子数据类型。

可选的，将所述总对象数量和所述预设子数据类型对应的对象数量的差值确定为第一剩余对象数量；根据所述第一剩余对象数量，确定所述M-1个第一子数据类型，所述M-1个第一子数据类型对应的对象数量之和小于或等于所述第一剩余对象数量。

举例而言，假设总对象数量为14，预设子数据类型为对子类型，预设子数据类型对应的对象数量为2，则第一剩余对象数量为10。则可以根据该第一剩余对象数量10，确定出M-1个第一子数据类型，保证M-1个子数据类型对应的对象数量之和小于或等于第一剩余对象数量10。

(3)根据所述总对象数量和所述M个第一子数据类型对应的对象数量，确定所述N个第二子数据类型。

可选的，将所述总对象数量和所述M个第一子数据类型对应的对象数量的差值确定为第二剩余对象数量；若所述第二剩余对象数量为0，则确定所述N为0；若所述第二剩余对象数量大于0，则根据所述第二剩余对象数量确定所述N个第二子数据类型。

举例而言，假设总对象数量为14，M＝1，M个第一子数据类型为对子类型。M个第一子数据类型对应的对象数量为2，则根据总对象数量(即14)以及M个第一子数据类型对应的对象数量(即2)，确定第二剩余对象数量(即12)。然后，根据第二剩余对象数量，确定N个第二子数据类型，保证N个第二子数据类型对应的对象数量之和为12。例如，可以得到如下4个第二子数据类型：明杠类型、明杠类型、明杠类型、明杠类型。这样，最终确定出的多个子数据类型包括：对子类型、明杠类型、明杠类型、明杠类型、明杠类型。

S403：针对每个第一子数据类型，获取所述第一子数据类型对应的游戏子数据。

S404：针对每个第二子数据类型，获取所述第二子数据类型对应的游戏子数据。

应理解的是，S403和S404的实现方式类似。针对每个子数据类型，可以采用如下几种可能的实现方式生成每个子数据类型对应的游戏子数据。

一种可能的实现方式中，可以在预设数据库中获取所述子数据类型对应的游戏子数据。示例性的，预设数据库可以存储有多种子数据类型对应的游戏子数据，每种子数据类型对应的游戏子数据的数量可以有多个。举例而言，当需要获取明杠类型对应的游戏子数据时，可以从预设数据库存储的明杠类型对应的多个游戏子数据中随机选择一个。该实现方式中，通过从预设数据库中获取游戏子数据，能够提高测试效率。

另一种可能的实现方式中，可以按照预设算法随机生成所述子数据类型对应的游戏子数据。示例性的，当需要获取明杠类型对应的游戏子数据时，则按照预设算法随机生成3个花色相同的游戏对象，作为明杠类型对应的游戏子数据。示例性的，当需要获取碰类型对应的游戏子数据时，则按照预设算法随机生成3个花色相同的游戏对象，作为碰类型对应的游戏子数据。该实现方式中，通过利用预设算法生成游戏子数据，能够保证测试的完备性。

又一种可能的实现方式中，可以显示可视化界面，接收用户在可视化界面输入的所述子数据类型对应的游戏子数据。该实现方式中，可以由用户输入每种子数据类型对应的游戏子数据，该可以提高测试灵活性。需要说明的是，本实施例对于可视化界面的形式不作限定，一种可能的实现方式可以参见后续实施例的详细描述。

S405：根据所述M个第一子数据类型和N个第二子数据类型各自对应的游戏子数据，生成所述游戏数据。

本实施例中，可以根据游戏对象的总对象数量，确定出M个第一子数据类型和N个第二子数据类型，并分别确定出每个第一子数据类型对应的游戏子数据，以及每个第二子数据类型对应的游戏子数据，进而根据M个第一子数据类型和N个第二子数据类型各自对应的游戏子数据，生成游戏数据。通过上述过程，使得无需经过虚拟客户端或者真实客户端的行牌流程，即可生成游戏数据，从而提高测试效率。

在上述任意实施例的基础上，下面结合一个具体的实施例描述游戏测试过程。本实施例中，可以根据用户在可视化界面中输入的多个子数据类型以及各子数据类型对应的游戏子数据，从而得到游戏数据。

图5为本申请实施例提供的另一种游戏测试方法的流程示意图。如图5所示，本实施例的方法，包括：

S501：显示可视化界面，接收用户在所述可视化界面输入的多个子数据类型、以及各子数据类型对应的游戏子数据。

S502：根据所述多个子数据类型各自对应的游戏子数据，生成游戏数据。

图6A至图6G为本申请实施例提供的一组可视化界面的示意图。其中，图6A示例的是游戏测试界面，参见图6A，游戏测试界面提供有游戏下拉菜单，用户可以通过下拉菜单选择待测试游戏，例如，用户选择XXXX麻将。游戏测试界面还提供“添加游戏数据”按钮，用于添加游戏测试过程所需的游戏数据。

当用户点击“添加游戏数据”按钮时，如图6B所示，游戏测试界面中显示新添加的游戏数据的相关信息项，包括：游戏数据的内容(由于还未添加游戏子数据，因此图6B中的游戏数据为空)、预期游戏结果(即第一游戏结果)、以及实际游戏结果(即第二游戏结果)。用户可以通过点击“添加游戏子数据”按钮向游戏数据1中添加游戏子数据。

当用户点击“添加游戏子数据”按钮后，显示图6C所示的游戏数据编辑界面。在该界面中，用户可以选择多个牌型，并为选择的牌型设置子数据类型，从而生成游戏子数据。举例而言，参见图6C，假设用户点击牌型“一萬”两次，则在“已选牌型”列表中显示牌型“一萬”，并标注牌型“一萬”的数量为2。进一步的，用户可以在子数据类型下拉菜单中为已选牌型选择子数据类型。其中，可选择的子数据类型可以包括：手牌、碰、吃、明杠、暗杠等。参见图6C，假设用户选择的子数据类型为“手牌”，当用户点击“添加”按钮后，在游戏数据中新增游戏子数据：手牌{一萬、一萬}，如图6D所示。

类似的，用户可以按照上述方式，继续添加其他游戏子数据。如图6E所示，假设用户添加了如下4个游戏子数据：碰{五萬、五萬、五萬}、碰{六萬、六萬、六萬}、碰{七萬、七萬、七萬}、碰{八萬、八萬、八萬}。至此，游戏数据中包括上述5个游戏子数据，且游戏数据中包括的游戏对象满足胡牌规则。当用户点击“确定”按钮后，在如图6F所示的游戏测试界面中，游戏数据的内容中包括上述5个游戏子数据。

S503：根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果。

本实施例中，第一游戏结果即为预期游戏结果。第二游戏结果即为实际游戏结果。

一些示例中，可以根据用户添加的5个游戏子数据对应的子数据类型，自动生成预期游戏结果(例如，番数x1，番型y1)，显示在如图6F所示的游戏测试界面中。

另一些示例中，还可以在可视化界面中接收用户输入的预期游戏结果。例如，用户通过对图6F中的游戏数据进行分析，确定出预期游戏结果(例如，番数x1，番型y1)，并在图6F所示的游戏测试界面中输入该预期游戏结果。

S504：通过待测试代码对所述游戏数据进行处理，得到第二游戏结果。

继续参见图6F和图6G，当用户在图6F所示界面中点击“测试”按钮后，触发待测试代码对游戏数据进行处理，得到实际游戏结果(例如，番数X1、番型Y1)，并将实际游戏结果显示在游戏测试界面中，如图6G所示。

一种可能的实现方式中，待测试代码部署在服务端，本实施例的方法可以由第一测试设备和第二测试设备协作执行。第一测试设备向用户提供交互功能，例如显示如图6A至图6G所示的可视化界面，并根据用户在可视化界面中的输入获取游戏数据。第二测试设备作为第一测试设备与服务端之间的中间件。第一测试设备获取游戏数据后，将游戏数据发送给第二测试设备，第二测试设备对游戏数据的数据格式进行校验，在数据格式校验正确的情况下，通过远程过程调用(Remote Procedure Call，RPC)的方式将游戏数据发送给服务端，使得服务端对游戏数据进行处理，得到实际游戏结果。服务端将实际游戏结果回传给第二测试设备，进而第二测试设备将实际游戏结果发送给第一测试设备进行显示。

S505：根据所述第一游戏结果和所述第二游戏结果，确定所述待测试代码对应的测试结果。

继续参见图6G，在预期游戏结果和实际游戏结果相同的情况下，说明待测试代码对该游戏数据的处理结果正确。用户可以点击“保存”按钮，将该游戏数据以及该游戏数据对应的预期游戏结果存储到预设数据库中。

或者，在图6F所示的测试界面中，用户输入游戏数据及其对应的预期游戏结果之后，可以立即点击“保存”按钮，将该游戏数据以及该游戏数据对应的预期游戏结果存储到预设数据库中。

能够理解的是，本实施例是以一个游戏数据的生成和测试过程为例进行描述的。实际测试过程中，本实施例中的S501至S505可以重复执行多次，生成多个测试数据，并利用多个测试数据对待测试代码进行测试，以保证测试结果的准确性。

这样，后续回归测试时，可以直接从预设数据库中获取游戏数据及其对应的预期游戏结果进行测试，从而进一步提高测试效率。

本实施例的游戏测试过程中，测试人员无需关注行牌流程，只需要根据多个子数据类型即可生成游戏数据，并确定出游戏数据对应的第一游戏结果，进而，通过待测试代码对游戏数据进行处理，得到第二游戏结果，根据第一游戏结果和第二游戏结果，确定待测试代码对应的测试结果。一方面，提高了测试效率，降低了人力成本和时间成本。另一方面，无需测试人员了解各种麻将玩法的规则，降低了对测试人员的要求。

图7为本申请实施例提供的一种游戏测试装置的结构示意图。本实施例的装置可以为软件和/或硬件的形式。如图7所示，本实施例提供的游戏测试装置700，包括：获取模块701、第一确定模块702、处理模块703和第二确定模块704。

其中，获取模块701，用于获取多个子数据类型，并根据所述多个子数据类型生成游戏数据，所述游戏数据中包括与每个子数据类型对应的游戏子数据；

第一确定模块702，用于根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果；

处理模块703，用于通过待测试代码对所述游戏数据进行处理，得到第二游戏结果；

第二确定模块704，用于根据所述第一游戏结果和所述第二游戏结果，确定所述待测试代码对应的测试结果。

一种可能的实现方式中，所述获取模块701具体用于：

获取游戏对象的总对象数量；

一种可能的实现方式中，所述获取模块701具体用于：

确定预设子数据类型；

一种可能的实现方式中，所述获取模块701具体用于：

若所述第二剩余对象数量为0，则确定所述N为0；

一种可能的实现方式中，所述获取模块701具体用于：

一种可能的实现方式中，所述第一确定模块702具体用于：

本实施例提供的游戏测试装置，可用于执行上述任一方法实施例提供的游戏测试方法，其实现原理和技术效果类似，此处不作赘述。

图8为本申请实施例提供的一种电子设备的结构示意图。该电子设备可以作为测试设备。如图8所示，本实施例提供的测试设备800，包括：处理器801以及存储器802。

其中，存储器802，用于存储计算机程序；处理器801，用于执行存储器中存储的计算机程序，以实现上述实施例中游戏测试方法中的一个或者多个步骤。具体可以参见前述方法实施例中的相关描述，其实现原理和技术效果类似，本实施例此处不再赘述。

可选地，存储器802既可以是独立的，也可以跟处理器801集成在一起。

当所述存储器802是独立于处理器801之外的器件时，所述电子设备800还可以包括：总线803，用于连接所述存储器802和处理器801。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机程序，所述计算机程序用于实现如上任一方法实施例中的游戏测试方法中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

本申请实施例还提供一种芯片，包括：存储器和处理器，所述存储器中存储有计算机程序，所述处理器运行所述计算机程序执行上述任一方法实施例中的游戏测试方法中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

本申请实施例还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述任一方法实施例中的游戏测试方法中的一个或者多个步骤，其实现原理和技术效果类似，此处不作赘述。

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

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

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

上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。

应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于专用集成电路(Application Specific Integrated Circuits，简称：ASIC)中。当然，处理器和存储介质也可以作为分立组件存在于电子设备或主控设备中。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims

1.一种游戏测试方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，获取多个子数据类型，包括：

获取游戏对象的总对象数量；

3.根据权利要求2所述的方法，其特征在于，根据所述总对象数量，确定M个第一子数据类型和N个第二子数据类型，包括：

确定预设子数据类型；

4.根据权利要求3所述的方法，其特征在于，根据所述预设子数据类型对应的对象数量和所述总对象数量，确定M-1个第一子数据类型，包括：

5.根据权利要求3或4所述的方法，其特征在于，根据所述总对象数量和所述M个第一子数据类型对应的对象数量，确定所述N个第二子数据类型，包括：

若所述第二剩余对象数量为0，则确定所述N为0；

6.根据权利要求1至5任一项所述的方法，其特征在于，根据所述多个子数据类型生成游戏数据，包括：

7.根据权利要求6所述的方法，其特征在于，获取所述子数据类型对应的游戏子数据，包括：

8.根据权利要求1至6任一项所述的方法，其特征在于，根据所述多个子数据类型，确定所述游戏数据对应的第一游戏结果，包括：

9.一种游戏测试装置，其特征在于，包括：

10.一种电子设备，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序实现如权利要求1至8任一项所述的方法。

11.一种计算机可读存储介质，其特征在于，包括：计算机程序，所述计算机程序被处理器执行时实现如权利要求1至8任一项所述的方法。