CN111258873B - 测试方法及装置 - Google Patents

Abstract

本说明书一个或多个实施例提供一种测试方法及装置，该方法可以包括：获取测试用例包含的节点；确定所述节点被配置的接口类型、属性参数和入参；对所述接口类型对应的预设方法进行泛化调用，以根据所述属性参数和所述入参对所述节点进行测试。

Description

测试方法及装置

技术领域

本说明书一个或多个实施例涉及终端技术领域，尤其涉及一种测试方法及装置。

背景技术

业务实现的过程中往往包含多个应用，这些应用可能涉及到不同接口类型的方法调用。在相关技术中，按照接口类型对业务包含的应用进行划分，并分别针对划分得到的每个部分实施测试操作。当各个部分均通过测试后，确定上述业务通过测试，可以对该业务进行发布。

发明内容

有鉴于此，本说明书一个或多个实施例提供一种测试方法及装置。

为实现上述目的，本说明书一个或多个实施例提供技术方案如下：

根据本说明书一个或多个实施例的第一方面，提出了一种测试方法，包括：

获取测试用例包含的节点；

确定所述节点被配置的接口类型、属性参数和入参；

对所述接口类型对应的预设方法进行泛化调用，以根据所述属性参数和所述入参对所述节点进行测试。

根据本说明书一个或多个实施例的第二方面，提出了一种测试装置，包括：

第一获取单元，获取测试用例包含的节点；

确定单元，确定所述节点被配置的接口类型、属性参数和入参；

调用单元，对所述接口类型对应的预设方法进行泛化调用，以根据所述属性参数和所述入参对所述节点进行测试。

附图说明

图1是一示例性实施例提供的一种测试系统的架构示意图。

图2是一示例性实施例提供的一种测试方法的流程图。

图3是一示例性实施例提供的一种创建测试用例的示意图。

图4是一示例性实施例提供的一种测试用例对应的业务流程的示意图。

图5是一示例性实施例提供的一种执行测试操作的示意图。

图6是一示例性实施例提供的一种设备的结构示意图。

图7是一示例性实施例提供的一种测试装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

在一实施例中，本说明书的测试方案可以应用于电子设备中，例如该电子设备可以包括手机、平板设备、笔记本电脑、掌上电脑(PDAs，Personal Digital Assistants)、可穿戴设备(如智能眼镜、智能手表等)等任意类型，本说明书并不对此进行限制。在运行过程中，该电子设备可以运行测试系统，以实现本说明书的测试方案。

在一实施例中，图1是一示例性实施例提供的一种测试系统的架构示意图。如图1所示，该系统可以包括服务器11、网络12、若干电子设备，比如手机13、PC14等。其中，服务器11在运行过程中，可以运行测试系统的服务端侧的程序，以实现相关的处理等功能；而手机13、PC14在运行过程中，可以运行测试系统的客户端侧的程序，以实现相关的展示、人机交互等功能，从而在服务器11与手机13、PC14之间配合实现该测试系统。

服务器11可以为包含一独立主机的物理服务器，或者该服务器11可以为主机集群承载的虚拟服务器。电子设备除了上述的手机13、PC14之外，还可以包括下述其他类型的设备：平板设备、笔记本电脑、掌上电脑(PDAs，Personal Digital Assistants)、可穿戴设备(如智能眼镜、智能手表等)等，本说明书一个或多个实施例并不对此进行限制。而对于手机13、PC14与服务器11之间进行交互的网络12，可以包括多种类型的有线或无线网络。在一实施例中，该网络12可以包括公共交换电话网络(Public Switched Telephone Network，PSTN)和因特网。其中，测试系统的客户端的应用程序可以被预先安装在电子设备上，使得该客户端可以在该电子设备上被启动并运行；当然，当采用诸如HTML5技术的在线“客户端”时，无需在电子设备上安装相应的应用程序，即可获得并运行该客户端。

图2是一示例性实施例提供的一种测试方法的流程图。如图2所示，该方法可以包括以下步骤：

步骤202，获取测试用例包含的节点。

在一实施例中，通过选取已创建的测试用例，可以针对该测试用例实施测试操作；其中，可以具体获取该测试用例所包含的节点，并针对每一节点分别进行测试。

在一实施例中，可以根据用户输入的测试环境和关键词实施查询操作，以查找到相匹配的测试用例，从而针对查找到的一个或多个测试用例实施测试操作。其中，当存在多个测试用例时，可以依次对各个测试用例实施测试操作，或者可以对多个测试用例进行分发，以通过并发测试而提升测试效率。

步骤204，确定所述节点被配置的接口类型、属性参数和入参。

在一实施例中，通过预先对各种接口类型的原子方法进行抽象，可以将各个原子方法抽象为“节点+配置信息”的表征形式，使得节点没有过重的业务逻辑(比如仅包含各个业务的基础逻辑或通用逻辑，其他业务逻辑由配置信息进行表达)，使得各个测试用例均可以对节点进行重复引用，并且仅需要对配置信息进行设定、不需要重复编写相关代码，可以简化对测试用例的创建难度。

在一实施例中，针对节点的配置信息可以包括接口类型、属性参数和入参。接口类型可以包括HSF类型、POP类型、本地类型等，本说明书并不对此进行限制。属性参数与上述的接口类型相关，比如HSF类型的属性参数可以包括ServiceName(服务名称)、Version(版本号)、MethodName(方法名称)、ParameterType(参数类型)，再比如POP类型的属性参数可以包括Domain(域)、Version、Action(动作)，又比如本地方法只需要配置Bean的对象名称等。每一节点的入参可以与其他节点无关，或者可以与其他节点相关、以实现各个节点之间的参数传递。

步骤206，对所述接口类型对应的预设方法进行泛化调用，以根据所述属性参数和所述入参对所述节点进行测试。

在一实施例中，通过采用上述的“节点+配置信息”的结构，并结合对相应方法的泛化调用，使得仅通过配置即可对相应的方法进行调用，而不需要经过程序发布。同时，在用例失败后仅需要修改入参即可，无需对代码进行修改和重新提交，极大地简化了对测试用例的调整过程。

在一实施例中，泛化调用可以将具体、个别的接口抽象为统一、通用的接口(如通用服务接口Generic Service)，因而可以在无需引入和依赖相应的接口jar包的情况下，直接基于该通用的接口对各个接口类型对应的预设方法进行调用。例如，对于用于实现充值功能的HSF接口，需要提供号码和面额两个参数，当采用泛化调用进行抽象后，可以将该接口定义为[接口,类型:HSF,用途:充值,入参:param1,param2]，其中param1代表号码的取值、param2代表面额的取值。再例如，对于用于实现查询功能的POP接口，需要提供号码、类型和城市三个参数，当采用泛化调用进行抽象后，可以将该接口定义为[接口,类型:POP,用途:查询,入参:param1,param2,param3]，其中param1代表号码的取值、param2代表类型的取值、param3代表城市的取值。可见，基于泛化调用功能，对HSF接口与POP接口实现了的统一化、通用化的接口定义。

在一实施例中，测试用例可以包含一个或多个节点；其中，当测试用例包含多个节点时，该多个节点可以至少对应于两种接口类型。因此，当业务包含的应用涉及到多种接口类型的方法调用时，本说明书的测试方案可以对该业务的完整流程进行测试，相比于相关技术中根据接口类型将业务划分为多个部分、分别对各个部分进行单独测试，本说明书的测试方案有助于发现和解决不同接口类型的应用之间可能存在的适配问题，避免发生单个应用通过测试但业务执行失败的情况。

在一实施例中，所述测试用例可以包含多个节点，分别对应于预设业务的完整流程中的各个步骤；其中，所述多个节点被基于所述各个步骤之间的执行顺序进行组织而形成所述测试用例。换言之，上述的测试用例可以对该预设业务的完整流程进行有效验证，从而确保该预设业务能够可靠运行。

在一实施例中，所述测试用例可以包含多个节点，所述多个节点之间按照预设顺序(比如预设业务的完整流程中的各个步骤之间的顺序，或者其他设定的顺序)进行组织；其中，相邻节点之间存在至少一个参数的数据传递。例如，可以将相邻的前一节点的输出作为后一节点的入参；再例如，可以对相邻的前一节点的输出实施特定计算，而计算结果作为后一节点的入参。

在一实施例中，节点的入参可以为自定义取值，比如用户设定的某一数值。

在一实施例中，节点的入参可以为变量，而用户可以为该变量设定赋值规则，使得在测试过程中可以基于该赋值规则自动实现变量替换，从而完成对变量的赋值。例如，赋值规则可以为用户预定义的第一预设函数，譬如该第一预设函数可以为“取当前时刻”等；再例如，赋值规则可以为继承指定的上下文信息，譬如可以将前一节点的输出(或其他变量的取值)作为该变量的取值；又例如，赋值规则可以同时与用户预定义的第二预设函数和上下文信息相关，譬如通过第二预设函数对前一节点的输出(或其他变量的取值)进行计算，并将计算结果作为该变量的取值。

在一实施例中，所述测试用例可以包含多个节点，所述多个节点之间按照预设顺序(比如预设业务的完整流程中的各个步骤之间的顺序，或者其他设定的顺序)进行组织。在针对各个节点进行测试的过程中，可以获取针对任一节点的测试结果，并当测试结果为通过时，允许对所述任一节点的后一节点实施测试，直至完成对所述多个节点的测试。当所有的多个节点的测试结果均为通过时，可以判定测试用例通过测试；否则，当某个节点的测试结果为未通过时，可以判定测试用例未通过测试。

在一实施例中，当所述节点的测试结果为未通过测试时，由于本说明书中采用“节点和配置信息”的表征形式，因而在无需修改代码的情况下，仅需要对配置信息进行调整即可，比如可以获取针对入参进行修改而得到的修改后入参，并根据所述修改后入参重启对所述节点的测试，极大地提升了测试灵活度和测试效率。

为了便于理解，以网络交易平台上的“商品下单”场景为例，具体描述如何通过本说明书的测试方案对该场景下的相关业务进行测试。其中，测试过程可以划分为“创建测试用例”和“执行测试操作”两个阶段，下面分别对每一阶段进行描述。

图3是一示例性实施例提供的一种创建测试用例的示意图。用户可以在电子设备上查看到如图3所示的测试用例创建界面300，以用于创建对应于上述场景的测试用例。例如，用户可以为该测试用例设定相应的用例名称为“商品下单”，测试系统也可以针对该测试用例生成唯一对应的用例ID，以区分于其他的测试用例。

在一实施例中，测试用例可以由若干节点组织而成，而用户需要针对各个节点进行分别配置，并设定各个节点之间的顺序关系与参数传递，从而表现为如图4所示的业务流程。例如，“商品下单”的业务流程可以包括如图4所示的下述步骤：保存订单、发布订单、接单、检查订单数据、交单、验收、查询订单状态等，分别对应于相应的节点1～节点7。

在一实施例中，本说明书的技术方案预先将各个原子方法抽象为上述的“节点”，当业务流程中需要实施一个步骤时，用户可以通过触发如图3所示的“+添加节点”选项，在该业务流程中添加对应的节点，比如在图3所示实施例的基础上，如果需要实施上述的步骤“交单”，可以通过触发“+添加节点”选项而唤出节点5，而用户可以进一步对该节点5自身进行配置，以及对该节点5与其他节点之间的关系进行设定。

以针对节点4进行配置为例。当检测到用户选取节点4后，电子设备上可以示出如图3所示的配置窗口302，使得用户可以基于该窗口302对该节点4进行配置。首先，用户可以对节点类型进行设定，而窗口302中示出的属性配置选项与该节点类型相关；例如，当节点4的节点类型被设定为“HSF类型”时，表明该节点4的步骤实施需要基于HSF接口实现方法调用，因而窗口302可以示出相应的属性配置选项，比如ServiceName、Version、MethodName、ParameterType等，以供用户进行配置。用户可以通过触发“HSF类型”右侧的▼标识，查看或调整为其他的节点类型。

进一步地，用户还需设定节点4的入参。本说明书中的入参可以包含多种类型，比如用户可以将某一数值设定为入参，或者用户可以将入参设定为变量，并设定该变量的替换规则，以在测试过程中通过变量替换而自动完成对入参的取值设定。

例如，入参可以为函数变量。比如当某一节点中需要将作为入参的字段“abc”设定为当前时刻，可以通过"abc":"${M_Time}"设定上述的替换规则，使得该字段“abc”的取值可以被设定为相应时刻。

再例如，入参可以为上下文变量。比如当某一节点中需要将作为入参的字段“abc”设定为另一节点nodex的执行结果bizID，可以通过"abc":"${P_node1.response.bizId}"设定上述的替换规则，使得该字段“abc”的取值可以被设定为该执行结果bizID的值。

又例如，入参可以为JS脚本自定义变量。比如需要将节点nodex的执行结果bizID进行计算后，设定为某一节点中需要将作为入参的字段“abc”的取值，可以通过"abc":"${M_Compute.Math.ceil(${P_node1.request.abc}/10)}"设定上述的替换规则，完成对该字段“abc”的取值设定。

举例而言，假定上述的“商品下单”业务具体涉及到“游戏代练”商品，那么上述的“订单”具体为“代练单”，而各个节点对应的步骤可以包括：节点1对应的步骤为通过HSF接口保存代练单、节点2对应的步骤为通过HSF接口发布代练单、节点3对应的步骤为通过POP接口接单、节点4对应的步骤为通过HSF接口检查节点3中所接代练单的数据、节点5对应的步骤为通过POP接口交单、节点6对应的步骤为通过HSF接口验收代练单、接口7对应的步骤为通过HSF接口查询代练单状态。与相关技术相区别的是，本说明书中可以针对上述节点1～节点7进行完整测试，相当于完整地检测了“商品下单”业务的所有流程步骤，而并非分别检测若干流程步骤，可以更加全面地检测出该“商品下单”业务可能存在的问题。

针对图3-4中创建的测试用例“商品下单”，图5是一示例性实施例提供的一种执行测试操作的示意图。如图5所示，用户(如测试人员)可以通过输入查询条件，以查找所需测试的测试用例；比如该查询条件可以包括测试环境、测试用例的关键词等。

在一实施例中，可能查询到一个或多个匹配于上述查询条件的测试用例；若仅查询到一个测试用例，则可以直接针对该测试用例实施测试操作；若查询到多个测试用例，比如图5所示的case0、case1等，可以对这些测试用例进行分发，以由多台设备针对这些测试用例进行并发测试，从而提升测试效率。

假定case0为图3-4所示实施例中创建的测试用例，针对case0实施测试操作可以包含分别针对其包含的节点1～节点7进行测试；其中，针对每一节点实施测试操作的过程可以包括以下步骤：

步骤501，执行延时。

在一实施例中，在配置节点的过程中，可以为节点设定是否需要延时以及所需延迟的时长。若不需要延时，可以直接转入步骤502；若需要延时，则延迟设定的时长后，再转入步骤502。

步骤502，类型区分。

在一实施例中，可以针对节点的配置信息，确定节点的接口类型；用户可以通过该如图3所示的窗口302中的“节点类型”选项进行设置，比如HSF类型、POP类型、本地类型等，本说明书并不对此进行限制。

步骤503，变量替换。

在一实施例中，当用户为节点配置的变量时，可以根据预定义的替换规则执行变量替换，以确定该变量的取值，从而作为相关节点的入参。当然，节点的入参也可以为用户指定的数值，而并不一定为待替换的变量，本说明书并不对此进行限制。

步骤504，泛化调用。

在一实施例中，根据步骤502中确定的节点的接口类型，对相应的方法进行泛化调用，从而基于步骤503中确定的入参，实现相应的测试操作。通过采用泛化调用，配合于抽象后的节点以及用户对节点的配置，使得用户只需要对节点的接口类型、属性参数、入参等进行配置，即可对相关方法进行调用，相当于对该相关方法的程序进行调用，而无需额外编写和发布程序，极大地简化了测试用例的创建过程、提升了创建效率、降低了出错概率。

步骤505，结果校验。

在一实施例中，当针对节点1的测试结果通过校验时，可以转入对节点2的测试；类似地，当针对节点2的测试结果通过校验时，可以转入对节点3的测试；以此类推，依次完成对所有节点1～节点7的测试操作，每一节点的测试操作均可以通过上述的步骤501～505而实现。

在一实施例中，当针对某一节点的测试结果未通过校验时，比如对节点1的测试结果未通过校验，将不会转入对后一节点的测试。例如，可以输出测试失败，并终止测试；然后，用户可以对节点1的入参进行调整，从而在无需修改与提交代码的情况下，快速重启对节点1的测试。

图6是一示例性实施例提供的一种设备的示意结构图。请参考图6，在硬件层面，该设备包括处理器602、内部总线604、网络接口606、内存608以及非易失性存储器610，当然还可能包括其他业务所需要的硬件。处理器602从非易失性存储器610中读取对应的计算机程序到内存608中然后运行，在逻辑层面上形成测试装置。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图7，在软件实施方式中，该测试装置可以包括：

第一获取单元701，获取测试用例包含的节点；

确定单元702，确定所述节点被配置的接口类型、属性参数和入参；

调用单元703，对所述接口类型对应的预设方法进行泛化调用，以根据所述属性参数和所述入参对所述节点进行测试。

可选的，所述测试用例包含多个节点，所述多个节点至少对应于两种接口类型。

可选的，所述测试用例包含多个节点，分别对应于预设业务的完整流程中的各个步骤；其中，所述多个节点被基于所述各个步骤之间的执行顺序进行组织而形成所述测试用例。

可选的，所述测试用例包含多个节点，所述多个节点之间按照预设顺序进行组织；其中，相邻节点之间存在至少一个参数的数据传递。

可选的，所述入参包括以下至少之一：

自定义取值、基于第一预设函数的变量替换结果、基于上下文信息的变量替换结果、基于第二预设函数对上下文信息进行计算得到的变量替换结果。

可选的，所述测试用例包含多个节点，所述多个节点之间按照预设顺序进行组织；所述装置还包括：

第二获取单元704，获取针对任一节点的测试结果；

权限管理单元705，当测试结果为通过时，允许对所述任一节点的后一节点实施测试，直至完成对所述多个节点的测试。

可选的，还包括：

第三获取单元706，当所述节点的测试结果为未通过测试时，获取针对所述入参进行修改而得到的修改后入参；

重启单元707，根据所述修改后入参重启对所述节点的测试。

可选的，还包括：

查询单元708，根据用户输入的测试环境和关键词实施查询操作；

分发单元709，当查询到多个所述测试用例时，对多个所述测试用例进行分发，以实施并发测试。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

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

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

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

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

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

Claims (16)

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

获取测试用例包含的节点；

确定所述节点被配置的接口类型、属性参数和入参；

在无需引入jar包的情况下，基于由具体接口抽象而成的通用接口对所述接口类型对应的预设方法进行调用，以根据所述属性参数和所述入参对所述节点进行测试。

2.根据权利要求1所述的方法，其特征在于，所述测试用例包含多个节点，所述多个节点至少对应于两种接口类型。

3.根据权利要求1所述的方法，其特征在于，所述测试用例包含多个节点，分别对应于预设业务的完整流程中的各个步骤；其中，所述多个节点被基于所述各个步骤之间的执行顺序进行组织而形成所述测试用例。

4.根据权利要求1所述的方法，其特征在于，所述测试用例包含多个节点，所述多个节点之间按照预设顺序进行组织；其中，相邻节点之间存在至少一个参数的数据传递。

5.根据权利要求1所述的方法，其特征在于，所述入参包括以下至少之一：

自定义取值、基于第一预设函数的变量替换结果、基于上下文信息的变量替换结果、基于第二预设函数对上下文信息进行计算得到的变量替换结果。

6.根据权利要求1所述的方法，其特征在于，所述测试用例包含多个节点，所述多个节点之间按照预设顺序进行组织；所述方法还包括：

获取针对任一节点的测试结果；

当测试结果为通过时，允许对所述任一节点的后一节点实施测试，直至完成对所述多个节点的测试。

7.根据权利要求1所述的方法，其特征在于，还包括：

当所述节点的测试结果为未通过测试时，获取针对所述入参进行修改而得到的修改后入参；

根据所述修改后入参重启对所述节点的测试。

8.根据权利要求1所述的方法，其特征在于，还包括：

根据用户输入的测试环境和关键词实施查询操作；

当查询到多个所述测试用例时，对多个所述测试用例进行分发，以实施并发测试。

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

第一获取单元，获取测试用例包含的节点；

确定单元，确定所述节点被配置的接口类型、属性参数和入参；

调用单元，在无需引入jar包的情况下，基于由具体接口抽象而成的通用接口对所述接口类型对应的预设方法进行调用，以根据所述属性参数和所述入参对所述节点进行测试。

10.根据权利要求9所述的装置，其特征在于，所述测试用例包含多个节点，所述多个节点至少对应于两种接口类型。

11.根据权利要求9所述的装置，其特征在于，所述测试用例包含多个节点，分别对应于预设业务的完整流程中的各个步骤；其中，所述多个节点被基于所述各个步骤之间的执行顺序进行组织而形成所述测试用例。

12.根据权利要求9所述的装置，其特征在于，所述测试用例包含多个节点，所述多个节点之间按照预设顺序进行组织；其中，相邻节点之间存在至少一个参数的数据传递。

13.根据权利要求9所述的装置，其特征在于，所述入参包括以下至少之一：

自定义取值、基于第一预设函数的变量替换结果、基于上下文信息的变量替换结果、基于第二预设函数对上下文信息进行计算得到的变量替换结果。

14.根据权利要求9所述的装置，其特征在于，所述测试用例包含多个节点，所述多个节点之间按照预设顺序进行组织；所述装置还包括：

第二获取单元，获取针对任一节点的测试结果；

权限管理单元，当测试结果为通过时，允许对所述任一节点的后一节点实施测试，直至完成对所述多个节点的测试。

15.根据权利要求9所述的装置，其特征在于，还包括：

第三获取单元，当所述节点的测试结果为未通过测试时，获取针对所述入参进行修改而得到的修改后入参；

重启单元，根据所述修改后入参重启对所述节点的测试。

16.根据权利要求9所述的装置，其特征在于，还包括：

查询单元，根据用户输入的测试环境和关键词实施查询操作；

分发单元，当查询到多个所述测试用例时，对多个所述测试用例进行分发，以实施并发测试。

Images