一种业务测试方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种业务测试方法及装置。

背景技术：

目前，互联网上的应用给人们的生活带来了很大的便利，随着应用涉及的业务链路越来越复杂，用户群体越来越大，对业务链路的功能和性能要求也越来越高。

一般的，一项业务可以包括多种业务场景，不同的业务场景对应着不同的业务链路，当业务场景确定后，可以由一个应用或多个应用通过参与执行该业务场景对应的业务链路，为用户提供相应的服务。其中，所述业务链路可以由多个业务节点串联构成，每个业务节点具体可以是应用内的一个功能模块，也可以是一个应用。

在实际应用中，每个业务节点都提供了很多业务功能应用程序编程接口(Application Programming Interface，API)，通过对业务节点的各业务功能API进行调用，可以相应地使用该业务节点的各项功能。

在现有技术中，研发人员可以通过编写测试用例，以及在测试系统上执行测试用例的方法，对业务链路的功能和性能进行测试。

研发人员在测试用例中构建对业务链路的测试逻辑时，需要大量地使用该业务链路对应的业务节点提供的各业务功能API，而且这些业务功能API相互之间的关系也比较复杂，因此，编写测试用例需要耗费研发人员极大的精力，相应的，测试系统在执行测试用例时，也需要针对业务链路对应的各功能模块，大量地调用这些业务功能API，测试系统的处理负担较大，测试效率较低。

技术实现要素：

本申请实施例提供一种业务测试方法及装置，用以解决现有技术中测试业务链路时，测试系统的处理负担较大，测试效率较低的问题。

本申请实施例提供另一种业务测试方法及装置，用以解决现有技术中测试业务链路时，测试系统的处理负担较大，测试效率较低的问题。

本申请实施例提供的一种业务测试方法，包括：

封装平台根据业务节点提供的至少两个业务功能API，生成该业务节点的业务节点API；

当接收到测试系统对所述业务节点API的第一调用请求时，确定该第一调用请求对应的第一调用结果，并返回给测试系统。

本申请实施例提供的另一种业务测试方法，包括：

封装平台接收测试系统的业务处理请求，其中，所述业务处理请求中包含对各业务节点的业务节点API的第一调用请求，业务节点API是对业务节点的至少两个业务功能API进行封装后生成的；

调用所述各业务节点API内封装的各业务功能API；

接收所述各业务节点返回的第一调用结果，并将所述第一调用结果返回给测试系统。

本申请实施例提供的一种业务测试装置，包括：

第一生成模块，用于根据业务节点提供的至少两个业务功能API，生成该业务节点的业务节点API；

第一确定模块，用于当接收到测试系统对所述业务节点API的第一调用请求时，确定该第一调用请求对应的第一调用结果，并返回给测试系统。

本申请实施例提供的另一种业务测试装置，包括：

接收模块，用于接收测试系统的业务处理请求，其中，所述业务处理请求中包含对各业务节点的业务节点API的第一调用请求，业务节点API是对业务节点的至少两个业务功能API进行封装后生成的；

调用模块，用于调用所述各业务节点API内封装的各业务功能API；

返回模块，用于接收所述各业务节点返回的第一调用结果，并将所述第一调用结果返回给测试系统。

本申请实施例通过上述至少一种技术方案，在对业务链路进行测试过程中，当想要使用业务节点的功能时，不用一一对该业务节点提供的各业务功能API进行调用，而是只要调用预先该业务节点的业务进行封装后生成的业务节点API进行调用即可，因此，可以降低测试系统的处理负担，提高测试效率。

附图说明

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

图1为本申请实施例提供的业务测试方法的过程；

图2为在实际应用中，支付业务在一种业务场景下的处理流程；

图3为本申请实施例提供的另一种业务测试方法的过程；

图4为本申请实施例提供的、在实际应用中的一种支付业务测试过程；

图5为本申请实施例提供的封装平台的一种系统架构图；

图6为本申请实施例提供的、为支付业务相关的一个业务节点生成业务节点API和校验API的示意图；

图7为本申请实施例提供的对应于图1的业务测试装置结构示意图；

图8为本申请实施例提供的对应于图3的业务测试装置结构示意图。

具体实施方式

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

图1为本申请实施例提供的业务测试方法的过程，具体包括以下步骤：

S101：封装平台根据业务节点提供的至少两个业务功能API，生成该业务节点的业务节点API。

S102：封装平台当接收到测试系统对所述业务节点API的第一调用请求时，确定该第一调用请求对应的第一调用结果，并返回给测试系统。

在本申请实施例中，所述封装平台是可以用于对业务节点的业务(所述业务包括但不限于：业务功能API和其他的业务数据等)进行封装和校验的平台，所述封装平台可以搭载于服务器或终端上。所述服务器包括但不限于：大中型计算机、计算机集群等。所述终端包括但不限于：个人计算机、手机、平板电脑、智能手表、车载移动台等。搭载所述执行主体的设备并不构成对本申请的限定。

本申请对所述业务的具体内容并不做限定，所述业务可以是电商业务、支付业务、金融业务、通讯业务、通信业务、多媒体业务等终端上的应用可以提供业务。所述测试系统可以是任一应用系统，例如，业务应用、基于指定测试框架的自动化测试平台、半自动化测试平台、手工测试平台，等等。

本申请实施例提供的业务测试方法可以用于测试任一项基于软件或软硬件结合的业务，对于不同的业务，测试该业务时可能使用的各业务节点也可能不同。对于要基于所述业务测试方法进行测试的一项待测业务称为待测业务，则步骤S101中的所述业务节点可以是测试该待测业务时需要使用的任一个业务节点。其中，各业务节点可以位于同一个业务服务器上，也可以位于不同的业务服务器上。

以支付业务为例进行说明。在用户采用信用卡进行支付的业务场景下，对应的业务链路包含的业务节点依次为：名称为“收银台”的业务节点、名称为“计费核心”的业务节点、名称为“支付核心”的业务节点，等等。为了便于 描述，以下直接以业务节点的名称表示该业务节点。

相应的，图2示出了假定用户提交了一个业务请求后，对应的各业务节点的处理流程简图(省略了一些步骤)，主要包括以下步骤：

S201：用户通过终端向收银台发送支付请求。

S202：收银台根据该支付请求，向计费核心发送预计费请求。

S203：计费核心根据预计费请求，生成预计费结果并返回给收银台。

S204：收银台向支付核心发送支付创建请求。

S205：支付核心根据支付创建请求，生成支付创建结果并返回给收银台。

S206：收银台根据预计费结果和支付创建结果，生成支付结果，并返回给终端。

可以看到，在以上的业务链路中，收银台提供了S202、S204、S206这三个步骤相关的业务，计费核心提供了S203这个步骤相关的业务，支付核心提供了S205这个步骤相关的业务。对于这三个业务节点，每个节点都提供了多个业务功能API实现该业务节点对应的业务。

根据在背景技术中的说明，在现有技术中，对一条业务链路进行测试具体包括：依次对该业务链路上的每个业务节点提供的业务进行测试，因此，研发人员在编写测试用例，对于每个业务节点，都要用到该业务节点的多个业务功能API，相应的，测试系统在执行测试用例时，也要大量地调用这些业务功能API，因此，测试系统的处理负担较大，测试效率较低。

以计费核心为例进行说明，计费核心在实现步骤S203时，提供的业务主要包括：产品创建、合约创建、计费服务这三项(在实际应用中，可能包括更多项)。其中，每一项具体可以对应于计费核心提供的一个或多个业务功能API，具体的，假定以上三项对应的业务功能API分别为：产品创建API、合约创建API、计费服务API。则在现有技术中，测试计费核心的业务时需要调用这三类API，这三类API的具体数量为至少三个。在这种情况下，测试系统在测试计费核心的业务时，要分别调用这三类API，测试系统的处理负担较大， 测试效率较低。

为了解决上述问题，在本申请实施例中，对于任一业务节点，封装平台可以预先对该业务节点提供各业务功能API进行封装，本申请将封装后生成的API称为：该业务节点的业务节点API(所述业务节点API的功能包括但不限于：所述各业务功能API的功能)。

在这种情况下，研发人员在测试用例中构建测试逻辑时，可以调用业务节点的业务节点API，而不用一一调用业务节点的各业务功能API。研发人员编写完测试用例后，可以在测试系统上执行测试用例，当执行至用于调用各业务功能API的代码部分时，测试系统相应地向封装平台发送对业务节点API的调用请求(在本申请实施例中，可以将对业务节点API的调用请求称为：第一调用请求)，进而，封装平台可以执行步骤S102。

通过上述方法，相比于现有技术，可以减少测试系统在测试业务链路时调用的API的数量，因此，可以降低测试系统的处理负担，提高测试效率，同时，也可以降低编写测试用例的成本。

在本申请实施例中，对于上述步骤S101，生成该业务节点的业务节点API，具体可以包括：确定该业务节点提供的至少两个业务功能API；基于指定的对象组装组件，对所述至少两个业务功能API进行封装，生成该业务节点的业务节点API。其中，所述对象组装组件用于对带封装的各业务功能API中包含的属性和函数等数据进行组装，所述对象组装组件可以从现有技术中通用的工具组件中直接获得，这样的话，可以减少封装平台的构造成本。当然，对于安全等级较高的业务，为了减少业务节点API受到攻击的风险，也可以不基于所述对象组装组件封装生成业务节点API，而是可以由研发人员开发非通用的组件用于封装生成业务节点API。

进一步的，在实际应用中，在生成业务节点API时，还可以根据业务场景，对业务功能API进行重载，通过所述重载的操作可以减少业务功能API的参数的个数，和/或改变业务功能API的参数的类型，使重载后的业务功能API 更适用于该业务场景，然后再基于指定的对象组装组件，对所述业务功能API进行封装，生成业务节点API。

在现有技术中，一般不会在测试脚本中进行校验，而是人工分析业务链路的最终计算结果，若有问题，再对该业务链路上的各个业务节点进行问题排查，因此，不仅耗费人力资源，而且对业务链路的校验效率较低。

而在本申请实施例中，除了将第一调用请求对应的调用结果(以下可以称为第一调用结果)，并返回给测试系统之外，还可以基于封装平台预先生成的业务节点的校验API，对该业务节点的业务节点API的第一调用结果进行校验，并将校验结果返回给测试系统。从而，可以实现封装平台自动对业务链路进行校验，这种校验方式解放了人力资源，而且对业务链路的校验效率较高。

具体的，封装平台除了执行步骤S101和S102以外，还可以执行以下步骤：封装平台根据该业务节点提供的至少两个业务功能API，生成该业务节点的校验API；封装平台当接收到测试系统对所述校验API的调用请求(在本申请实施例中，可以将对校验API的调用请求称为：第二调用请求)时，对所述业务节点API的第一调用结果进行校验，将校验结果作为该第二调用请求对应的第二调用结果，并返回给测试系统。

更具体的，生成该业务节点的校验API，具体可以包括：确定该业务节点提供的至少两个业务功能API；通过基于指定的数据访问组件和对象组装组件，对所述至少两个业务功能API进行封装，生成该业务节点的校验API。

需要说明的是，与对象组装组件类似，所述数据访问组件也可以从现有技术中通用的工具组件中直接获得，所述数据访问组件用于为校验过程提供对业务节点相关的数据库的访问支持。一般的，同一个业务节点的业务节点API和业务节点API这两者中封装的业务功能API是不相同的，后面会举例进行说明。

根据上述的说明，在一个业务场景下，封装平台可以预先为每个业务节点分别生成一个业务节点API和一个校验API，该业务节点API用于对该业务节 点的业务进行计算，该校验API用于对计算结果进行校验。在这种情况下，在对业务链路进行测试时，测试系统可以接收到该业务链路中的各业务节点对业务的计算结果，以及各所述计算结果对应的验证结果。

以上主要是基于封装平台封装业务节点API和校验API，说明了本申请实施例提供的业务测试方法的过程，进一步的，下面基于封装平台接收测试系统的业务处理请求的场景，说明本申请实施例提供的另一种业务测试方法的过程，如图3所示，具体包括以下步骤：

S301：封装平台接收测试系统的业务处理请求，其中，所述业务处理请求中包含对各业务节点的业务节点API的第一调用请求，业务节点API是对业务节点的至少两个业务功能API进行封装后生成的。

在本申请实施例中，所述业务处理请求可以是测试系统在执行测试用例时向封装平台发送的。对各业务节点API的调用顺序可以在业务处理请求中预先指定(称为：用例指定方案)，或者，也可以由封装平台在接收到所述业务处理请求后，按照预设规则进行确定(称为：封装平台指定方案)。

S302：封装平台调用所述各业务节点API内封装的各业务功能API；

S303：封装平台接收所述各业务节点返回的第一调用结果，并将所述第一调用结果返回给测试系统。

通过上述方法，相比于现有技术，可以减少测试系统在测试业务链路时调用的API的数量，因此，可以降低测试系统的处理负担，提高测试效率，同时，也可以降低编写测试用例的成本。

在本申请实施例中，任一业务节点API的输出可能作为另一个业务节点API的输入，任一业务节点API的输入也可能是另一个业务节点API的输出，在这种情况下，封装平台按照不同的处理顺序，处理各第一调用请求时，确定出的对应的各第一调用结果也可能不同，一般的，封装平台可以根据测试系统要测试的业务链路中的各业务节点的顺序，处理各第一调用请求。

因此，对于步骤S302，调用所述各业务节点API内封装的各业务功能API， 具体可以包括：根据所述业务处理请求中包含的各第一调用请求，确定业务链路；根据所述业务链路上的各业务节点的顺序，依次处理所述各业务节点对应的第一调用请求，其中，每处理一个业务节点对应的第一调用请求时，调用该业务节点API内封装的各业务功能API。

进一步的，调用所述各业务节点API内封装的各业务功能API，具体可以包括：根据所述业务处理请求中包含的各第一调用请求，确定业务链路；根据所述业务链路上的各业务节点的顺序，依次处理所述各业务节点对应的第一调用请求，其中，每处理一个业务节点对应的第一调用请求时，调用该业务节点API内封装的各业务功能API。

更进一步的，根据所述业务处理请求中包含的各第一调用请求，确定业务链路，具体可以包括：确定所述业务处理请求中包含的各第一调用请求对应的业务节点；根据各第一调用请求在所述业务处理请求中的顺序，将各第一调用请求对应的业务节点按照所述接收顺序串联，构成业务链路(对应于上述的用例指定方案)；或者，根据所述各第一调用请求对应的业务节点，按照预设规则，构成业务链路(对应于上述的封装平台指定方案)。

在本申请实施例中，所述业务处理请求中还可以包含对所述各业务节点的校验API的第二调用请求，校验API是对业务节点的至少两个业务功能API进行封装后生成的，所述方法还可以包括：对所述各业务节点API的第一调用结果进行校验，将校验结果作为该第二调用请求对应的第二调用结果，并返回给测试系统。

为了便于理解，下面以实际应用中的支付业务为例，对本申请实施例提供的业务测试方法的过程进行说明，如图4所示，具体可以包括以下步骤：

S401：用户(如研发人员)触发测试系统执行支付测试用例，其中，所述测试用例中至少可以包括用于对计费核心的业务节点API和校验API进行调用的代码段，以及对支付核心的业务节点API和校验API进行调用的代码段。

需要说明的是，对于收银台这个业务节点，由于其主要功能是对业务信息 进行转发，而及业务的计算处理较少，发生业务问题的概率相对较低。因此，在编写测试用例的时候，可以直接用将转发逻辑相关的代码写入测试用例，可以不用为这个业务节点生成业务节点API和校验API，从而也可以降低封装平台的处理负担。

S402：测试系统向封装平台发送对计费核心的业务节点API的第一调用请求，以及发送对支付核心的业务节点API的第一调用请求。

S403：封装平台分别确定计费核心和支付核心针对第一调用请求的第一调用结果，并返回给测试系统。

S404：测试系统向封装平台发送对计费核心的校验API的第二调用请求。

S405：封装平台根据该第二调用请求，对计费核心针对第一调用请求的第一调用结果进行校验，并将校验结果返回给测试系统。

S406：测试系统向封装平台发送对支付核心的校验API的第二调用请求。

S407：封装平台根据该第二调用请求，对支付核心针对第一调用请求的第一调用结果进行校验，并将校验结果返回给测试系统。

S408：测试系统对接收到的各第一调用结果，以及对应的各校验结果进行整合和/或分析，获得对业务链路的测试结果，并将测试结果返回给用户。

需要说明的是，在实际应用中，可以在确定每个业务节点的计算结果后立刻对该计算结果进行校验，也可以在确定全部业务节点的计算结果后再分别对每个计算结果进行校验，等等。因此，图4中只是示出了一种实际应用场景下的过程，本申请对图4中的各步骤的执行顺序并不做限定。

为了便于理解，本申请实施例提供了所述封装平台的一种系统架构图，如图5所示。

图5中的封装平台可以包括四层：业务及校验服务门面、业务及校验封装层、业务依赖层、通用工具层。该封装平台可以基于通用工具层中的组件，在业务及校验封装层，对业务依赖层的业务(具体可以是业务功能API)进行封装，从而，生成业务及校验门面中的各业务节点API和对应的各校验API，以 提供给用户和测试系统(在图5中示出了3个测试系统与封装平台之间的交互)使用。

进一步的，本申请实施例提供了还提供了一种在图5的封装平台中，为计费核心生成业务节点API和校验API的示意图，如图6所示。

可以看到，图6中主要示出了对计费核心的业务的封装。计费业务API即是封装后生成的业务节点API；计费校验API即是封装后生成的校验API。其中，在计费业务API中可以封装产品创建、合约创建、计费服务等几项业务对应的业务功能API，在计费校验API中可以封装产品查询、收费账单查询等几项业务对应的业务功能API。

以上为本申请实施例提供的业务测试方法，基于同样的思路，本申请实施例还提供相应的业务测试装置，如图7、图8所示。

图7为本申请实施例提供的对应于图1的业务测试装置结构示意图，具体包括：

第一生成模块701，用于根据业务节点提供的至少两个业务功能API，生成该业务节点的业务节点API；

第一确定模块702，用于当接收到测试系统对所述业务节点API的第一调用请求时，确定该第一调用请求对应的第一调用结果，并返回给测试系统。

所述第一生成模块701具体用于：确定该业务节点提供的至少两个业务功能API；基于指定的对象组装组件，对所述至少两个业务功能API进行封装，生成该业务节点的业务节点API。

所述装置还包括：

第二生成模块703，用于根据该业务节点提供的至少两个业务功能API，生成该业务节点的校验API；

第二确定模块704，用于当接收到测试系统对所述校验API的第二调用请求时，对所述业务节点API的第一调用结果进行校验，将校验结果作为该第二调用请求对应的第二调用结果，并返回给测试系统。

所述第二生成模块703具体用于：确定该业务节点提供的至少两个业务功能API；通过基于指定的数据访问组件和对象组装组件，对所述至少两个业务功能API进行封装，生成该业务节点的校验API。

具体的上述如图7所示的装置可以位于终端、服务器上。

图8为本申请实施例提供的对应于图3的业务测试装置结构示意图，具体包括：

接收模块801，接收测试系统的业务处理请求，其中，所述业务处理请求中包含对各业务节点的业务节点API的第一调用请求，业务节点API是对业务节点的至少两个业务功能API进行封装后生成的；

调用模块802，用于调用所述各业务节点API内封装的各业务功能API；

返回模块803，用于接收所述各业务节点返回的第一调用结果，并将所述第一调用结果返回给测试系统。

所述调用模块802具体用于：根据所述业务处理请求中包含的各第一调用请求，确定业务链路；根据所述业务链路上的各业务节点的顺序，依次处理所述各业务节点对应的第一调用请求，其中，每处理一个业务节点对应的第一调用请求时，调用该业务节点API内封装的各业务功能API。

所述调用模块802具体用于：确定所述业务处理请求中包含的各第一调用请求对应的业务节点；根据各第一调用请求在所述业务处理请求中的顺序，将各第一调用请求对应的业务节点按照所述接收顺序串联，构成业务链路；或者，根据所述各第一调用请求对应的业务节点，按照预设规则，构成业务链路。

所述业务处理请求中还包含对所述各业务节点的校验API的第二调用请求，校验API是对业务节点的至少两个业务功能API进行封装后生成的，所述装置还包括：

校验模块804，用于对所述各业务节点API的第一调用结果进行校验，将校验结果作为该第二调用请求对应的第二调用结果，并返回给测试系统。

具体的上述如图8所示的装置可以位于终端、服务器上。

本申请实施例提供一种业务测试方法及装置，该方法包括：封装平台根据业务节点提供的至少两个业务功能API，生成该业务节点的业务节点API；当接收到测试系统对所述业务节点API的第一调用请求时，确定该第一调用请求对应的第一调用结果，并返回给测试系统。通过上述方法，在对业务链路进行测试过程中，当想要使用业务节点的功能时，不用一一对该业务节点提供的各业务功能API进行调用，而是只要调用预先该业务节点的业务进行封装后生成的业务节点API进行调用即可，因此，可以降低测试系统的处理负担，提高测试效率。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处 理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算 机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。