CN113641583A - 数据处理方法、装置、电子设备、存储介质及程序产品 - Google Patents

Abstract

本公开实施例公开了一种数据处理方法、装置、电子设备、存储介质及程序产品，所述数据处理方法包括：接收测试数据请求；根据所述测试数据请求确定目标测试数据包类别；从与所述目标测试数据包类别对应的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方，其中，所述测试数据包存储组件中存放有一个或多个测试数据包，且所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别。该技术方案能够实现测试数据包的稳定获取和长期有效性，以及测试数据的有效生成和管理，不仅大大提高了数据的执行效率，还避免了由于数据过期腐化和数据污染导致的数据不可用的问题。

Description

数据处理方法、装置、电子设备、存储介质及程序产品

技术领域

本公开涉及数据处理技术领域，具体涉及一种数据处理方法、装置、电子设备、存储介质及程序产品。

背景技术

测试数据的准备是软件测试中的一个重要步骤组成。测试用例有一个重要设计原则：测试用例之间不应当存在依赖关系，一个测试用例的执行结果不应当受到其他测试用例执行结果的影响。基于该原则，一个测试用例所需要的测试数据应当全部由自己准备，但由于测试数据的准备大多涉及多方数据来源，而且数据来源的可用性无法保障，这就大大降低了数据执行效率，尤其对于测试数据种类众多、数据之间关联性较强的软件***更是如此。如果采用事先准备好的静态测试数据，则又会面临数据的过期腐化和多方使用带来的数据污染问题。因此亟需一种既能够提高数据的执行效率、又能够有效避免由于数据过期腐化和数据污染导致数据不可用的解决方案。

发明内容

本公开实施例提供一种数据处理方法、装置、电子设备、存储介质及程序产品。

第一方面，本公开实施例中提供了一种数据处理方法。

具体的，所述数据处理方法，包括：

接收测试数据请求；

根据所述测试数据请求确定目标测试数据包类别；

从与所述目标测试数据包类别对应的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方，其中，所述测试数据包存储组件中存放有一个或多个测试数据包，且所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别。

结合第一方面，本公开在第一方面的第一种实现方式中，还包括：

生成测试数据包，并将所述测试数据包存入与所述测试数据包的类别对应的测试数据包存储组件中。

结合第一方面和第一方面的第一种实现方式，本公开实施例在第一方面的第二种实现方式中，所述生成测试数据包，包括：

从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包。

结合第一方面、第一方面的第一种实现方式和第一方面的第二种实现方式，本公开实施例在第一方面的第三种实现方式中，所述从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包，包括：

获取所述测试数据的标识信息，并将所述测试数据的标识信息组成测试数据包；

将所述测试数据的数据本体存入数据本体数据库中；

建立所述测试数据的数据本体与标识信息之间的对应关系。

结合第一方面、第一方面的第一种实现方式、第一方面的第二种实现方式和第一方面的第三种实现方式，本公开实施例在第一方面的第四种实现方式中，还包括：

响应于检测到所述测试数据存储组件中剩余测试数据包的数量低于第一预设数量阈值，生成与所述测试数据存储组件类别对应的测试数据包，并将其填充入所述测试数据存储组件中，以使所述测试数据存储组件中剩余测试数据包的数量高于所述第一预设数量阈值。

结合第一方面、第一方面的第一种实现方式、第一方面的第二种实现方式、第一方面的第三种实现方式和第一方面的第四种实现方式，本公开实施例在第一方面的第五种实现方式中，还包括：

将所述目标测试数据包标记为已用，并将已用测试数据包迁移至已用测试数据包存储组件中。

结合第一方面、第一方面的第一种实现方式、第一方面的第二种实现方式、第一方面的第三种实现方式、第一方面的第四种实现方式和第一方面的第五种实现方式，本公开实施例在第一方面的第六种实现方式中，还包括：

响应于检测到满足数据清理条件，清理所述已用测试数据包存储组件中的已用测试数据包。

结合第一方面、第一方面的第一种实现方式、第一方面的第二种实现方式、第一方面的第三种实现方式、第一方面的第四种实现方式、第一方面的第五种实现方式和第一方面的第六种实现方式，本公开实施例在第一方面的第七种实现方式中，还包括：

清理所述数据本体数据库中与被清理的已用测试数据包中的标识信息对应的数据本体。

第二方面，本公开实施例中提供了一种数据处理装置。

具体的，所述数据处理装置，包括：

接收模块，被配置为接收测试数据请求；

确定模块，被配置为根据所述测试数据请求确定目标测试数据包类别；

发送模块，被配置为从与所述目标测试数据包类别对应的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方，其中，所述测试数据包存储组件中存放有一个或多个测试数据包，且所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别。

结合第二方面，本公开在第二方面的第一种实现方式中，还包括：

生成模块，被配置为生成测试数据包，并将所述测试数据包存入与所述测试数据包的类别对应的测试数据包存储组件中。

结合第二方面和第二方面的第一种实现方式，本公开实施例在第二方面的第二种实现方式中，所述生成模块被配置为：

从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包。

结合第二方面、第二方面的第一种实现方式和第二方面的第二种实现方式，本公开实施例在第二方面的第三种实现方式中，所述从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包的部分，被配置为：

获取所述测试数据的标识信息，并将所述测试数据的标识信息组成测试数据包；

将所述测试数据的数据本体存入数据本体数据库中；

建立所述测试数据的数据本体与标识信息之间的对应关系。

结合第二方面、第二方面的第一种实现方式、第二方面的第二种实现方式和第二方面的第三种实现方式，本公开实施例在第二方面的第四种实现方式中，还包括：

填充模块，被配置为响应于检测到所述测试数据存储组件中剩余测试数据包的数量低于第一预设数量阈值，生成与所述测试数据存储组件类别对应的测试数据包，并将其填充入所述测试数据存储组件中，以使所述测试数据存储组件中剩余测试数据包的数量高于所述第一预设数量阈值。

结合第二方面、第二方面的第一种实现方式、第二方面的第二种实现方式、第二方面的第三种实现方式和第二方面的第四种实现方式，本公开实施例在第二方面的第五种实现方式中，还包括：

迁移模块，被配置为将所述目标测试数据包标记为已用，并将已用测试数据包迁移至已用测试数据包存储组件中。

结合第二方面、第二方面的第一种实现方式、第二方面的第二种实现方式、第二方面的第三种实现方式、第二方面的第四种实现方式和第二方面的第五种实现方式，本公开实施例在第二方面的第六种实现方式中，还包括：

清理模块，被配置为响应于检测到满足数据清理条件，清理所述已用测试数据包存储组件中的已用测试数据包。

结合第二方面、第二方面的第一种实现方式、第二方面的第二种实现方式、第二方面的第三种实现方式、第二方面的第四种实现方式、第二方面的第五种实现方式和第二方面的第六种实现方式，本公开实施例在第二方面的第七种实现方式中，所述清理模块还被配置为：

清理所述数据本体数据库中与被清理的已用测试数据包中的标识信息对应的数据本体。

第三方面，本公开实施例提供了一种电子设备，包括存储器和至少一个处理器，其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述至少一个处理器执行以实现上述数据处理方法的方法步骤。

第四方面，本公开实施例提供了一种计算机可读存储介质，用于存储数据处理装置所用的计算机指令，其包含用于执行上述数据处理方法为数据处理装置所涉及的计算机指令。

第五方面，本公开实施例提供了一种计算机程序产品，包括计算机程序/指令，其中，该计算机程序/指令被处理器执行时实现上述数据处理方法的方法步骤。

本公开实施例提供的技术方案可以包括以下有益效果：

上述技术方案预先设置了多个不同类别的测试数据包存储组件来存放不同类别的测试数据包，以实现数据生产和消费的解耦，并对于测试数据包存储组件中的测试数据包进行有效性管理。该技术方案能够实现测试数据包的稳定获取和长期有效性，以及测试数据的有效生成和管理，不仅大大提高了数据的执行效率，还避免了由于数据过期腐化和数据污染导致的数据不可用的问题。

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

附图说明

结合附图，通过以下非限制性实施方式的详细描述，本公开的其它特征、目的和优点将变得更加明显。在附图中：

图1示出根据本公开一实施方式的数据处理方法的流程图；

图2示出根据本公开一实施方式的数据处理方法的整体流程图；

图3示出根据本公开一实施方式的数据处理装置的结构框图；

图4示出根据本公开一实施方式的电子设备的结构框图；

图5是适于用来实现根据本公开一实施方式的数据处理方法的计算机***的结构示意图。

具体实施方式

下文中，将参考附图详细描述本公开的示例性实施方式，以使本领域技术人员可容易地实现它们。此外，为了清楚起见，在附图中省略了与描述示例性实施方式无关的部分。

在本公开中，应理解，诸如“包括”或“具有”等的术语旨在指示本说明书中所公开的特征、数字、步骤、行为、部件、部分或其组合的存在，并且不欲排除一个或多个其他特征、数字、步骤、行为、部件、部分或其组合存在或被添加的可能性。

另外还需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。

本公开实施例提供的技术方案预先设置了多个不同类别的测试数据包存储组件来存放不同类别的测试数据包，以实现数据生产和消费的解耦，并对于测试数据包存储组件中的测试数据包进行有效性管理。该技术方案能够实现测试数据包的稳定获取和长期有效性，以及测试数据的有效生成和管理，不仅大大提高了数据的执行效率，还避免了由于数据过期腐化和数据污染导致的数据不可用的问题。

图1示出根据本公开一实施方式的数据处理方法的流程图，如图1所示，所述数据处理方法包括以下步骤S101-S103：

在步骤S101中，接收测试数据请求；

在步骤S102中，根据所述测试数据请求确定目标测试数据包类别；

在步骤S103中，从与所述目标测试数据包类别对应的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方，其中，所述测试数据包存储组件中存放有一个或多个测试数据包，且所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别。

上文提及，测试数据的准备是软件测试中的一个重要步骤组成。测试用例有一个重要设计原则：测试用例之间不应当存在依赖关系，一个测试用例的执行结果不应当受到其他测试用例执行结果的影响。基于该原则，一个测试用例所需要的测试数据应当全部由自己准备，但由于测试数据的准备大多涉及多方数据来源，而且数据来源的可用性无法保障，这就大大降低了数据执行效率，尤其对于测试数据种类众多、数据之间关联性较强的软件***更是如此。如果采用事先准备好的静态测试数据，则又会面临数据的过期腐化和多方使用带来的数据污染问题。因此亟需一种既能够提高数据的执行效率、又能够有效避免由于数据过期腐化和数据污染导致数据不可用的解决方案。

考虑到上述缺陷，在该实施方式中，提出一种数据处理方法，该方法预先设置了多个不同类别的测试数据包存储组件来存放不同类别的测试数据包，以实现数据生产和消费的解耦，并对于测试数据包存储组件中的测试数据包进行有效性管理。该技术方案能够实现测试数据包的稳定获取和长期有效性，以及测试数据的有效生成和管理，不仅大大提高了数据的执行效率，还避免了由于数据过期腐化和数据污染导致的数据不可用的问题。

在本公开一实施方式中，所述数据处理方法可适用于对于测试数据进行处理的计算机、计算设备、电子设备、服务器等测试数据提供方。

在本公开一实施方式中，所述测试数据请求指的是测试数据请求方向测试数据提供方发出的、携带有获取测试数据的具体需求的、用于获取测试数据的请求，其中，所述测试数据请求可携带有想要获取的目标测试数据包的类别、数量等信息，基于所述测试数据请求即可确定测试数据请求方想要获取的目标测试数据包的类别和数量。其中，所述测试数据请求可通过对外提供的统一数据接口来获取，即测试数据请求方可通过所述测试数据提供方对外提供的统一数据接口来发送所述测试数据请求。

在本公开一实施方式中，所述测试数据包存储组件指的是用于存放生产得到的一个或多个测试数据包的组件，其中，所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别，比如，在下单支付等电子商务场景中，有可能会用到商户数据、商品数据、营销数据，店铺数据、用户数据等等，那么电子商务场景中可能会用到的测试数据包的类别可包括：商户、商品、营销、店铺、用户等等，则可将某一类别的测试数据包存放入相应类别的测试数据包存储组件中，也就是说，所述测试数据包存储组件的类别与所述测试数据包的类别相一致，即所述测试数据包存储组件的类别可包括：商户、商品、营销、店铺、用户等等，且每一类别的测试数据包存储组件只存放对应类别的测试数据包，这样就会提高测试数据包获取的针对性，进而提升获取测试数据包的速度。

由上可见，可取用的测试数据包的类别可以为一个或多个，用于存储所述测试数据包的测试数据包存储组件的类别可以为一个或多个，对于某一测试数据请求来说，该请求所携带的想要获取的目标测试数据包的类别也可以为一个或多个。

在上述实施方式中，接收到测试数据请求方发送的测试数据请求之后，基于所述测试数据请求确定所述测试数据请求方想要获取的目标测试数据包的类别，然后分别从相应类别的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方。

在本公开一实施方式中，所述方法还可包括以下步骤：

生成测试数据包，并将所述测试数据包存入与所述测试数据包的类别对应的测试数据包存储组件中。

为了使得测试数据请求方在想要测试数据包时就能够请求获取，保障测试数据包提供的稳定性，并提高测试数据包获取的针对性，进而提升获取测试数据包的速度，在该实施方式中，需要提前生成一定数量的各类别的测试数据包，并将这些测试数据包存放至与所述测试数据包的类别对应的测试数据包存储组件中，以备后续测试数据请求方请求获取，即一个测试数据包存储组件只存放一种类别的测试数据包，比如商品测试数据包存储组件只存放商品测试数据包，店铺测试数据包存储组件只存放店铺测试数据包。

进一步地，考虑到所述测试数据包存在有效期，不同测试数据包的有效期有可能不同，因此，在将所述测试数据包存入与相应类别的测试数据包存储组件中时，可同时存入所述测试数据包有效期信息。并且，为了保障每一测试数据包都能够在其有效期内被使用，在所述测试数据包被调用时，可优先提供有效期临近的测试数据包。比如，假设某一类型的测试数据包的最小有效时长为3天，相应测试数据包存储组件中存放有120个测试数据包，其中，40个测试数据包是2天前创建的，即将面临过期，可将其标记为A类测试数据包；40个商品是1天前创建的，可将其标记为B类测试数据包；40个商品是当天创建的，可将其标记为C类测试数据包，在所述测试数据包被调用时，可优先提供有效期临近的测试数据包，即A类测试数据包。

在本公开一实施方式中，所述生成测试数据包的步骤，可包括以下步骤：

从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包。

上文提及，测试数据大多涉及多方数据来源，比如，某一下单交易的测试用例，需要用到商户测试数据、商品测试数据、店铺测试数据、用户测试数据、营销测试数据等多个类别的测试数据；某一商品管理的测试用例不仅需要用到商品测试数据，还会用到店铺测试数据、商户测试数据等多个类别的测试数据。因此，在该实施方式中，在生成所述测试数据包时，首先需要确定该测试数据包所需要用到的数据来源及其他关联数据来源，然后再从所述数据来源和关联数据来源中获取相应的测试数据，组成测试数据包。比如，对于商品管理的测试用例来说，其需要用到的数据来源为商品应用，但从商品应用中仅可获取商品测试数据，无法提供店铺测试数据和商户测试数据，因此需从其他关联数据来源，比如从店铺应用中获取店铺测试数据，从商户应用中获取商户测试数据，将获得的商品测试数据、店铺测试数据和商户测试数据组成一个可完成商品管理测试的测试数据包。

其中，所述测试数据包中数据的数量和组成可根据实际应用的需要进行确定，只要所述测试数据包能够满足相应测试用例的需求即可。

在本公开一实施方式中，所述从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包的步骤，可包括以下步骤：

获取所述测试数据的标识信息，并将所述测试数据的标识信息组成测试数据包；

将所述测试数据的数据本体存入数据本体数据库中；

建立所述测试数据的数据本体与标识信息之间的对应关系。

为了节约数据存储空间，降低数据传输成本，在该实施方式中，只将测试数据的标识信息组成测试数据包，即，在从相应的数据来源中获取得到测试数据之后，提取出这些测试数据的标识信息，将所述测试数据的标识信息组成测试数据包，对应的所述测试数据的数据本体并不放入测试数据包中，而是存入一预先设置的数据本体数据库中，然后建立所述测试数据的数据本体与标识信息之间的对应关系，这样既能够满足测试用例对于测试数据的使用需要，而且在后续需要用到数据本体时，还可根据所述测试数据的标识信息从所述数据本体数据库中获取得到与所述测试数据的标识信息对应的数据本体。其中，所述测试数据的标识信息比如可以为所述测试数据的ID等等。

在本公开一实施方式中，所述方法还可包括以下步骤：

响应于检测到所述测试数据存储组件中剩余测试数据包的数量低于第一预设数量阈值，生成与所述测试数据存储组件类别对应的测试数据包，并将其填充入所述测试数据存储组件中，以使所述测试数据存储组件中剩余测试数据包的数量高于所述第一预设数量阈值。

为了进一步保障测试数据包提供的稳定性和及时性，在该实施方式中，当发现测试数据存储组件中剩余的测试数据包不足时，应及时触发测试数据包的填充，具体地，若检测到所述测试数据存储组件中剩余测试数据包的数量低于第一预设数量阈值时，则触发测试数据包的生成和填充，即生成与所述测试数据存储组件类别对应的测试数据包，并将其填充入所述测试数据存储组件中，直至所述测试数据存储组件中剩余测试数据包的数量高于所述第一预设数量阈值。其中，为了节省检测成本，对于所述测试数据存储组件中剩余测试数据包数量的检测也可以定时来进行，比如可以以分钟或者小时为单位进行所述测试数据存储组件中剩余测试数据包数量的检测。这样就能够实现数据生产和消费的解耦，避免出现数据消费速率高于数据生产速率，或者由于数据生产失败而导致的可用测试数据不足，进而阻塞数据测试流程的情况，保证了测试数据的充足性，使得测试数据随时可以取用。

其中，所述第一预设数量阈值可根据实际应用的需要进行确定。需要特别说明的是，每一类型的测试数据包或者说每一类型的测试数据存储组件对应的第一预设数量阈值非常重要，如果将其设置地太低，将会导致测试数据存储组件中的数据不够用，如果将其设置地太高，将会导致测试数据包产生积压，久而久之，最终将会导致测试数据包“腐烂”，即数据过期，以电子商品数据为例，每个电子商品数据都会设置可售卖时间，一般是几周或者一个月，如果电子商品数据一直处于积压状态，将会导致与所述电子商品数据相关的商品过了可售卖的时间却依旧没有被清理，测试数据存储组件中的商品数据还没有用就已经不能用了。另外，店铺、商户、营销活动、用户的券资产等数据，由于其特性不一，有效时间长度不一样，每类数据的使用情况不一样，最终会要求每一类商品数据有不同的第一预设数量阈值，比如，如果某一类型的测试数据包使用较为频繁，每天使用的数量较大，则需要将第一预设数量阈值设置地高一些，反之，需要将第一预设数量阈值设置地低一些。综上可见，每一类型的测试数据包或者说每一类型的测试数据存储组件对应的第一预设数量阈值需与测试数据包的特性相吻合，且需根据商品数据的不同进行及时的调整。

在本公开一实施方式中，可基于对于历史测试数据包使用情况的分析，来动态调整对应的第一预设数量阈值。具体地，可基于预设历史时间段内具有相同或相应时间特征的某一类测试数据包的使用量估计得到当前时间该类测试数据包的使用量，并基于当前时间该类测试数据包的使用量来确定第一预设数量阈值。比如，可以在过去的一个月时间内，以周为单位，记录每一天、每一类测试数据包的使用数量，然后采用同比方式(每周一数据使用量相比、每周二数据使用量相比等等)进行数据归类，然后采用线性回归算法，基于上述统计得到的数据使用量情况预测当天的数据使用量，以商品数据为例，当天(周三)的第一预设数量阈值，就是基于过去一个月内每个周三的商品数据使用量，进行线性回归后估计得到的值。

其中，对于所述测试数据存储组件中剩余测试数据包数量的检测可按照一定的时间频率进行，比如，可每隔几分钟或者几小时就对测试数据存储组件中剩余测试数据包的数量进行一次检测。

另外，考虑到不同类别的测试数据包的使用频繁程度可能相同也可能不同，因此，在本公开一实施方式中，不同类别的测试数据存储组件对应的第一预设数量阈值可以相同也可以不同，剩余测试数据包数量的检测频率也可以相同可以不同。即，不同类别测试数据存储组件对应的第一预设数量阈值及其剩余测试数据包数量的检测频率均可根据实际应用的需要进行设置。

在本公开一实施方式中，所述方法还可包括以下步骤：

将所述目标测试数据包标记为已用，并将已用测试数据包迁移至已用测试数据包存储组件中。

为了避免出现某一测试数据包被多方使用带来的相互干扰以及数据有可能会被污染，以及已用测试数据包存放太多影响数据计算性能和计算功能等情况，因此，在该实施方式中，还需对于已用测试数据包进行及时的清理，具体地：若检测到某一测试数据包被调用，则将该测试数据包标记为已用，并将该已用测试数据包迁移至一预先设置好的已用测试数据包存储组件中，即实现测试数据包一被调用即迁移至已用测试数据包存储组件中，从而避免了现有技术中采用事先准备好的静态测试数据带来的数据过期腐化和多方使用数据污染问题。其中，所述已用测试数据包存储组件可以为多类别测试数据存储组件共用，也可为对应类别的测试数据存储组件独用，此时，所述已用测试数据包存储组件的类别与所述已用测试数据包对应测试数据存储组件的类别一致。

上文提及，在将测试数据包存入与相应类别的测试数据包存储组件中时，同时存入所述测试数据包有效期信息。因此，在本公开一实施方式中，为了保障测试数据包的有效性，还可对于所述测试数据包存储组件中的测试数据包进行有效期定时检查，若检查发现测试数据包的到期时间大于当前时间并且与所述当前时间之间的时间差小于预设时长，则将所述测试数据包标记为即将过期，并将即将过期测试数据包迁移至已用测试数据包存储组件中。比如，可于每日23:00进行一次测试数据包有效期的检查，将检查发现的24小时内将会过期的测试数据包迁移至已用测试数据包存储组件中，从而进一步保障了测试数据包存储组件中测试数据包的有效性。

在本公开一实施方式中，所述方法还可包括以下步骤：

响应于检测到满足数据清理条件，清理所述已用测试数据包存储组件中的已用测试数据包。

为了节约数据存储空间，提高数据存储空间的利用率，避免出现由于数据堆积过多而导致的***性能功能异常的情况，比如，若某个商户名下不断的创建店铺，但是对于失效店铺信息不及时清理，一段时间之后该商户名下将存在成千上万的店铺，这样势必会影响***工作性能，在该实施方式中，还需对于所述已用测试数据包存储组件进行及时清理。具体地，若检测到数据清理条件被满足，则对于所述已用测试数据包存储组件中的已用测试数据包进行清理，即实现已用测试数据包存储组件的轮询清理。其中，所述数据清理条件可以为：所述已用测试数据包存储组件中已用测试数据包的数量超过第二预设数量阈值，或者，到达预设数据清理时间，其中，所述第二预设数量阈值可根据实际应用的需要进行确定。也就是说，可在发现某一已用测试数据包存储组件中存放的已用测试数据包的数量已足够多时，对于所述已用测试数据包存储组件进行清理；也可按照一预设时间频率对于所述已用测试数据包存储组件进行清理，其中，已用测试数据包存储组件的清理时间频率与所述已用测试数据包的使用或更新频率相关，例如，存放频繁被使用或更新的已用测试数据包的已用测试数据包存储组件的清理时间频率可设置地较高，比如商品数据可以每天清理一次，存放很少被使用或更新的已用测试数据包的已用测试数据包存储组件的清理时间频率可设置地较低，比如商户数据可以每月清理一次。

在本公开一实施方式中，所述方法还可包括以下步骤：

清理所述数据本体数据库中与被清理的已用测试数据包中的标识信息对应的数据本体。

为了进一步提高数据存储空间的利用率，在该实施方式中，在对于所述已用测试数据包存储组件中的已用测试数据包进行清理时，还需对于所述数据本体数据库中存放的、与被清理的已用测试数据包中的标识信息对应的数据本体进行同步清理。

图2示出根据本公开一实施方式的数据处理方法的流程图，如图2所示，以下单支付场景为例，在测试数据提供方接收到测试数据请求后，确定该测试数据请求涉及的目标测试数据包包括：商户测试数据包、商品测试数据包、营销测试数据包，店铺测试数据包和用户测试数据包这几个类别，以及各类别测试数据包的数量，然后所述测试数据提供方就可以分别到商户测试数据包存储组件、商品测试数据包存储组件、营销测试数据包存储组件，店铺测试数据包存储组件和用户测试数据包存储组件中取出相应数量的商户测试数据包、商品测试数据包、营销测试数据包，店铺测试数据包和用户测试数据包发送给测试数据请求方。最初，商户测试数据包存储组件、商品测试数据包存储组件、营销测试数据包存储组件，店铺测试数据包存储组件和用户测试数据包存储组件中均存放有第一预设数量阈值以上的测试数据包，如图中实心圆圈所示。在测试过程中，定时检测商户测试数据包存储组件、商品测试数据包存储组件、营销测试数据包存储组件，店铺测试数据包存储组件和用户测试数据包存储组件中剩余测试数据包的数量，若发现某一测试数据包存储组件中剩余测试数据包的数量低于所述第一预设数量阈值，如图中长虚线所示，则从与该测试数据包存储组件对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包，并填充至该测试数据包存储组件中，图中仅以商户测试数据包存储组件为例展示。在测试过程中，所述各测试数据包存储组件中每一测试数据包在被调用之后均标记为已用，并将其迁移至相应类别的已用测试数据包存储组件中，其中，已用测试数据包存储组件中存放的已用测试数据包将会定期被清理，图中也仅以商户测试数据包存储组件为例展示。

下述为本公开装置实施例，可以用于执行本公开方法实施例。

图3示出根据本公开一实施方式的数据处理装置的结构框图，该装置可以通过软件、硬件或者两者的结合实现成为电子设备的部分或者全部。如图3所示，所述数据处理装置包括：

接收模块301，被配置为接收测试数据请求；

确定模块302，被配置为根据所述测试数据请求确定目标测试数据包类别；

发送模块303，被配置为从与所述目标测试数据包类别对应的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方，其中，所述测试数据包存储组件中存放有一个或多个测试数据包，且所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别。

上文提及，测试数据的准备是软件测试中的一个重要步骤组成。测试用例有一个重要设计原则：测试用例之间不应当存在依赖关系，一个测试用例的执行结果不应当受到其他测试用例执行结果的影响。基于该原则，一个测试用例所需要的测试数据应当全部由自己准备，但由于测试数据的准备大多涉及多方数据来源，而且数据来源的可用性无法保障，这就大大降低了数据执行效率，尤其对于测试数据种类众多、数据之间关联性较强的软件***更是如此。如果采用事先准备好的静态测试数据，则又会面临数据的过期腐化和多方使用带来的数据污染问题。因此亟需一种既能够提高数据的执行效率、又能够有效避免由于数据过期腐化和数据污染导致数据不可用的解决方案。

考虑到上述缺陷，在该实施方式中，提出一种数据处理装置，该装置预先设置了多个不同类别的测试数据包存储组件来存放不同类别的测试数据包，以实现数据生产和消费的解耦，并对于测试数据包存储组件中的测试数据包进行有效性管理。该技术方案能够实现测试数据包的稳定获取和长期有效性，以及测试数据的有效生成和管理，不仅大大提高了数据的执行效率，还避免了由于数据过期腐化和数据污染导致的数据不可用的问题。

在本公开一实施方式中，所述数据处理装置可实现为对于测试数据进行处理的计算机、计算设备、电子设备、服务器等测试数据提供方。

在本公开一实施方式中，所述测试数据请求指的是测试数据请求方向测试数据提供方发出的、携带有获取测试数据的具体需求的、用于获取测试数据的请求，其中，所述测试数据请求可携带有想要获取的目标测试数据包的类别、数量等信息，基于所述测试数据请求即可确定测试数据请求方想要获取的目标测试数据包的类别和数量。其中，所述测试数据请求可通过对外提供的统一数据接口来获取，即测试数据请求方可通过所述测试数据提供方对外提供的统一数据接口来发送所述测试数据请求。

在本公开一实施方式中，所述测试数据包存储组件指的是用于存放生产得到的一个或多个测试数据包的组件，其中，所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别，比如，在下单支付等电子商务场景中，有可能会用到商户数据、商品数据、营销数据，店铺数据、用户数据等等，那么电子商务场景中可能会用到的测试数据包的类别可包括：商户、商品、营销、店铺、用户等等，则可将某一类别的测试数据包存放入相应类别的测试数据包存储组件中，也就是说，所述测试数据包存储组件的类别与所述测试数据包的类别相一致，即所述测试数据包存储组件的类别可包括：商户、商品、营销、店铺、用户等等，且每一类别的测试数据包存储组件只存放对应类别的测试数据包，这样就会提高测试数据包获取的针对性，进而提升获取测试数据包的速度。

由上可见，可取用的测试数据包的类别可以为一个或多个，用于存储所述测试数据包的测试数据包存储组件的类别可以为一个或多个，对于某一测试数据请求来说，该请求所携带的想要获取的目标测试数据包的类别也可以为一个或多个。

在上述实施方式中，接收到测试数据请求方发送的测试数据请求之后，基于所述测试数据请求确定所述测试数据请求方想要获取的目标测试数据包的类别，然后分别从相应类别的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方。

在本公开一实施方式中，所述装置还可包括：

生成模块，被配置为生成测试数据包，并将所述测试数据包存入与所述测试数据包的类别对应的测试数据包存储组件中。

为了使得测试数据请求方在想要测试数据包时就能够请求获取，保障测试数据包提供的稳定性，并提高测试数据包获取的针对性，进而提升获取测试数据包的速度，在该实施方式中，需要提前生成一定数量的各类别的测试数据包，并将这些测试数据包存放至与所述测试数据包的类别对应的测试数据包存储组件中，以备后续测试数据请求方请求获取，即一个测试数据包存储组件只存放一种类别的测试数据包，比如商品测试数据包存储组件只存放商品测试数据包，店铺测试数据包存储组件只存放店铺测试数据包。

进一步地，考虑到所述测试数据包存在有效期，不同测试数据包的有效期有可能不同，因此，在将所述测试数据包存入与相应类别的测试数据包存储组件中时，可同时存入所述测试数据包有效期信息。并且，为了保障每一测试数据包都能够在其有效期内被使用，在所述测试数据包被调用时，可优先提供有效期临近的测试数据包。比如，假设某一类型的测试数据包的最小有效时长为3天，相应测试数据包存储组件中存放有120个测试数据包，其中，40个测试数据包是2天前创建的，即将面临过期，可将其标记为A类测试数据包；40个商品是1天前创建的，可将其标记为B类测试数据包；40个商品是当天创建的，可将其标记为C类测试数据包，在所述测试数据包被调用时，可优先提供有效期临近的测试数据包，即A类测试数据包。

在本公开一实施方式中，所述生成模块可被配置为：

从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包。

上文提及，测试数据大多涉及多方数据来源，比如，某一下单交易的测试用例，需要用到商户测试数据、商品测试数据、店铺测试数据、用户测试数据、营销测试数据等多个类别的测试数据；某一商品管理的测试用例不仅需要用到商品测试数据，还会用到店铺测试数据、商户测试数据等多个类别的测试数据。因此，在该实施方式中，在生成所述测试数据包时，首先需要确定该测试数据包所需要用到的数据来源及其他关联数据来源，然后再从所述数据来源和关联数据来源中获取相应的测试数据，组成测试数据包。比如，对于商品管理的测试用例来说，其需要用到的数据来源为商品应用，但从商品应用中仅可获取商品测试数据，无法提供店铺测试数据和商户测试数据，因此需从其他关联数据来源，比如从店铺应用中获取店铺测试数据，从商户应用中获取商户测试数据，将获得的商品测试数据、店铺测试数据和商户测试数据组成一个可完成商品管理测试的测试数据包。

其中，所述测试数据包中数据的数量和组成可根据实际应用的需要进行确定，只要所述测试数据包能够满足相应测试用例的需求即可。

在本公开一实施方式中，所述从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包的部分，可被配置为：

获取所述测试数据的标识信息，并将所述测试数据的标识信息组成测试数据包；

将所述测试数据的数据本体存入数据本体数据库中；

建立所述测试数据的数据本体与标识信息之间的对应关系。

为了节约数据存储空间，降低数据传输成本，在该实施方式中，只将测试数据的标识信息组成测试数据包，即，在从相应的数据来源中获取得到测试数据之后，提取出这些测试数据的标识信息，将所述测试数据的标识信息组成测试数据包，对应的所述测试数据的数据本体并不放入测试数据包中，而是存入一预先设置的数据本体数据库中，然后建立所述测试数据的数据本体与标识信息之间的对应关系，这样既能够满足测试用例对于测试数据的使用需要，而且在后续需要用到数据本体时，还可根据所述测试数据的标识信息从所述数据本体数据库中获取得到与所述测试数据的标识信息对应的数据本体。其中，所述测试数据的标识信息比如可以为所述测试数据的ID等等。

在本公开一实施方式中，所述装置还可包括：

填充模块，被配置为响应于检测到所述测试数据存储组件中剩余测试数据包的数量低于第一预设数量阈值，生成与所述测试数据存储组件类别对应的测试数据包，并将其填充入所述测试数据存储组件中，以使所述测试数据存储组件中剩余测试数据包的数量高于所述第一预设数量阈值。

为了进一步保障测试数据包提供的稳定性和及时性，在该实施方式中，当发现测试数据存储组件中剩余的测试数据包不足时，应及时触发测试数据包的填充，具体地，若检测到所述测试数据存储组件中剩余测试数据包的数量低于第一预设数量阈值时，则触发测试数据包的生成和填充，即生成与所述测试数据存储组件类别对应的测试数据包，并将其填充入所述测试数据存储组件中，直至所述测试数据存储组件中剩余测试数据包的数量高于所述第一预设数量阈值。其中，为了节省检测成本，对于所述测试数据存储组件中剩余测试数据包数量的检测也可以定时来进行，比如可以以分钟或者小时为单位进行所述测试数据存储组件中剩余测试数据包数量的检测。这样就能够实现数据生产和消费的解耦，避免出现数据消费速率高于数据生产速率，或者由于数据生产失败而导致的可用测试数据不足，进而阻塞数据测试流程的情况，保证了测试数据的充足性，使得测试数据随时可以取用。

其中，所述第一预设数量阈值可根据实际应用的需要进行确定。需要特别说明的是，每一类型的测试数据包或者说每一类型的测试数据存储组件对应的第一预设数量阈值非常重要，如果将其设置地太低，将会导致测试数据存储组件中的数据不够用，如果将其设置地太高，将会导致测试数据包产生积压，久而久之，最终将会导致测试数据包“腐烂”，即数据过期，以电子商品数据为例，每个电子商品数据都会设置可售卖时间，一般是几周或者一个月，如果电子商品数据一直处于积压状态，将会导致与所述电子商品数据相关的商品过了可售卖的时间却依旧没有被清理，测试数据存储组件中的商品数据还没有用就已经不能用了。另外，店铺、商户、营销活动、用户的券资产等数据，由于其特性不一，有效时间长度不一样，每类数据的使用情况不一样，最终会要求每一类商品数据有不同的第一预设数量阈值，比如，如果某一类型的测试数据包使用较为频繁，每天使用的数量较大，则需要将第一预设数量阈值设置地高一些，反之，需要将第一预设数量阈值设置地低一些。综上可见，每一类型的测试数据包或者说每一类型的测试数据存储组件对应的第一预设数量阈值需与测试数据包的特性相吻合，且需根据商品数据的不同进行及时的调整。

在本公开一实施方式中，可基于对于历史测试数据包使用情况的分析，来动态调整对应的第一预设数量阈值。具体地，可基于预设历史时间段内具有相同或相应时间特征的某一类测试数据包的使用量估计得到当前时间该类测试数据包的使用量，并基于当前时间该类测试数据包的使用量来确定第一预设数量阈值。比如，可以在过去的一个月时间内，以周为单位，记录每一天、每一类测试数据包的使用数量，然后采用同比方式(每周一数据使用量相比、每周二数据使用量相比等等)进行数据归类，然后采用线性回归算法，基于上述统计得到的数据使用量情况预测当天的数据使用量，以商品数据为例，当天(周三)的第一预设数量阈值，就是基于过去一个月内每个周三的商品数据使用量，进行线性回归后估计得到的值。

其中，对于所述测试数据存储组件中剩余测试数据包数量的检测可按照一定的时间频率进行，比如，可每隔几分钟或者几小时就对测试数据存储组件中剩余测试数据包的数量进行一次检测。

另外，考虑到不同类别的测试数据包的使用频繁程度可能相同也可能不同，因此，在本公开一实施方式中，不同类别的测试数据存储组件对应的第一预设数量阈值可以相同也可以不同，剩余测试数据包数量的检测频率也可以相同可以不同。即，不同类别测试数据存储组件对应的第一预设数量阈值及其剩余测试数据包数量的检测频率均可根据实际应用的需要进行设置。

在本公开一实施方式中，所述装置还可包括：

迁移模块，被配置为将所述目标测试数据包标记为已用，并将已用测试数据包迁移至已用测试数据包存储组件中。

为了避免出现某一测试数据包被多方使用带来的相互干扰以及数据有可能会被污染，以及已用测试数据包存放太多影响数据计算性能和计算功能等情况，因此，在该实施方式中，还需对于已用测试数据包进行及时的清理，具体地：若检测到某一测试数据包被调用，则将该测试数据包标记为已用，并将该已用测试数据包迁移至一预先设置好的已用测试数据包存储组件中，即实现测试数据包一被调用即迁移至已用测试数据包存储组件中，从而避免了现有技术中采用事先准备好的静态测试数据带来的数据过期腐化和多方使用数据污染问题。其中，所述已用测试数据包存储组件可以为多类别测试数据存储组件共用，也可为对应类别的测试数据存储组件独用，此时，所述已用测试数据包存储组件的类别与所述已用测试数据包对应测试数据存储组件的类别一致。

上文提及，在将测试数据包存入与相应类别的测试数据包存储组件中时，同时存入所述测试数据包有效期信息。因此，在本公开一实施方式中，为了保障测试数据包的有效性，还可对于所述测试数据包存储组件中的测试数据包进行有效期定时检查，若检查发现测试数据包的到期时间大于当前时间并且与所述当前时间之间的时间差小于预设时长，则将所述测试数据包标记为即将过期，并将即将过期测试数据包迁移至已用测试数据包存储组件中。比如，可于每日23:00进行一次测试数据包有效期的检查，将检查发现的24小时内将会过期的测试数据包迁移至已用测试数据包存储组件中，从而进一步保障了测试数据包存储组件中测试数据包的有效性。

在本公开一实施方式中，所述装置还可包括：

清理模块，被配置为响应于检测到满足数据清理条件，清理所述已用测试数据包存储组件中的已用测试数据包。

为了节约数据存储空间，提高数据存储空间的利用率，避免出现由于数据堆积过多而导致的***性能功能异常的情况，比如，若某个商户名下不断的创建店铺，但是对于失效店铺信息不及时清理，一段时间之后该商户名下将存在成千上万的店铺，这样势必会影响***工作性能，在该实施方式中，还需对于所述已用测试数据包存储组件进行及时清理。具体地，若检测到数据清理条件被满足，则对于所述已用测试数据包存储组件中的已用测试数据包进行清理，即实现已用测试数据包存储组件的轮询清理。其中，所述数据清理条件可以为：所述已用测试数据包存储组件中已用测试数据包的数量超过第二预设数量阈值，或者，到达预设数据清理时间，其中，所述第二预设数量阈值可根据实际应用的需要进行确定。也就是说，可在发现某一已用测试数据包存储组件中存放的已用测试数据包的数量已足够多时，对于所述已用测试数据包存储组件进行清理；也可按照一预设时间频率对于所述已用测试数据包存储组件进行清理，其中，已用测试数据包存储组件的清理时间频率与所述已用测试数据包的使用或更新频率相关，例如，存放频繁被使用或更新的已用测试数据包的已用测试数据包存储组件的清理时间频率可设置地较高，比如商品数据可以每天清理一次，存放很少被使用或更新的已用测试数据包的已用测试数据包存储组件的清理时间频率可设置地较低，比如商户数据可以每月清理一次。

在本公开一实施方式中，所述清理模块还可被配置为：

清理所述数据本体数据库中与被清理的已用测试数据包中的标识信息对应的数据本体。

为了进一步提高数据存储空间的利用率，在该实施方式中，在对于所述已用测试数据包存储组件中的已用测试数据包进行清理时，还需对于所述数据本体数据库中存放的、与被清理的已用测试数据包中的标识信息对应的数据本体进行同步清理。

本公开还公开了一种电子设备，图4示出根据本公开一实施方式的电子设备的结构框图，如图4所示，所述电子设备400包括存储器401和处理器402；其中，

所述存储器401用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述处理器402执行以实现上述方法步骤。

图5是适于用来实现根据本公开一实施方式的数据处理方法的计算机***的结构示意图。

如图5所示，计算机***500包括处理单元501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行上述实施方式中的各种处理。在RAM503中，还存储有***500操作所需的各种程序和数据。处理单元501、ROM502以及RAM503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

以下部件连接至I/O接口505：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。其中，所述处理单元501可实现为CPU、GPU、TPU、FPGA、NPU等处理单元。

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

描述于本公开实施方式中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定。

作为另一方面，本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施方式中所述装置中所包含的计算机可读存储介质；也可以是单独存在，未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序，所述程序被一个或者一个以上的处理器用来执行描述于本公开的方法。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种数据处理方法，包括：

接收测试数据请求；

根据所述测试数据请求确定目标测试数据包类别；

从与所述目标测试数据包类别对应的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方，其中，所述测试数据包存储组件中存放有一个或多个测试数据包，且所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别。

2.根据权利要求1所述的方法，还包括：

生成测试数据包，并将所述测试数据包存入与所述测试数据包的类别对应的测试数据包存储组件中。

3.根据权利要求2所述的方法，所述生成测试数据包，包括：

从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包。

4.根据权利要求3所述的方法，所述从与所述测试数据包的类别对应的数据来源及其关联数据来源中获取测试数据，组成测试数据包，包括：

获取所述测试数据的标识信息，并将所述测试数据的标识信息组成测试数据包；

将所述测试数据的数据本体存入数据本体数据库中；

建立所述测试数据的数据本体与标识信息之间的对应关系。

5.根据权利要求4所述的方法，还包括：

响应于检测到所述测试数据存储组件中剩余测试数据包的数量低于第一预设数量阈值，生成与所述测试数据存储组件类别对应的测试数据包，并将其填充入所述测试数据存储组件中，以使所述测试数据存储组件中剩余测试数据包的数量高于所述第一预设数量阈值。

6.根据权利要求4或5所述的方法，还包括：

将所述目标测试数据包标记为已用，并将已用测试数据包迁移至已用测试数据包存储组件中。

7.根据权利要求6所述的方法，还包括：

响应于检测到满足数据清理条件，清理所述已用测试数据包存储组件中的已用测试数据包。

8.根据权利要求7所述的方法，还包括：

清理所述数据本体数据库中与被清理的已用测试数据包中的标识信息对应的数据本体。

9.一种数据处理装置，包括：

接收模块，被配置为接收测试数据请求；

确定模块，被配置为根据所述测试数据请求确定目标测试数据包类别；

发送模块，被配置为从与所述目标测试数据包类别对应的测试数据包存储组件中取出所述目标测试数据包发送给测试数据请求方，其中，所述测试数据包存储组件中存放有一个或多个测试数据包，且所述测试数据包存储组件具有与所存放的测试数据包类别相应的类别。

10.一种电子设备，包括存储器和至少一个处理器；其中，所述存储器用于存储一条或多条计算机指令，其中，所述一条或多条计算机指令被所述至少一个处理器执行以实现权利要求1-8任一项所述的方法步骤。

Images