CN107203465A - 系统接口测试方法及装置 - Google Patents

Abstract

本申请实施例提供了一种系统接口测试方法及装置，该方法包括以下步骤：获取模拟mock对象发起的业务请求；在获取到目标调用对象针对所述业务请求返回的返回对象后，根据预设的处理逻辑修改所述返回对象，获得预期的返回对象；向所述mock对象返回所述预期的返回对象。本申请实施例可在获取到目标调用对象针对业务请求返回的返回对象后，根据预设的处理逻辑修改返回对象，获得预期的返回对象，从而实现了可以灵活的根据实际的结果或者实际的请求参数来改返回对象，满足了在系统接口测试自动化中构造各种复杂的业务场景的要求。

Description

系统接口测试方法及装置

技术领域

本申请涉及软件测试技术领域，尤其是涉及一种系统接口测试方法及装置。

背景技术

系统接口测试主要用于检测系统与系统外部之间以及系统内部各个子系统之间的交互点。系统接口测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

目前现有的系统接口测试可通过拦截器实现。而拦截器一般是在被调用的目标方法执行前或执行后去执行预定义的行为，比如选择继续执行连接点，或通过返回它们自己的返回值或抛出异常来短路执行。一般的，拦截器返回的返回值就是被调用的目标方法返回的返回值，而被调用的目标方法的返回值一般是预设好的一个定值。因此，现有的系统接口测试方法的可实现的测试场景比较单一，其无法满足日益复杂的系统接口测试需要。

发明内容

本申请实施例的目的在于提供一种系统接口测试方法及装置，以便于更为灵活的获取返回对象，从而实现复杂的业务场景下的系统接口测试。

为达到上述目的，本申请实施例提供了一种系统接口测试方法，包括以下步骤：

获取模拟mock对象发起的业务请求；

在获取到目标调用对象针对所述业务请求返回的返回对象后，根据预设的处理逻辑修改所述返回对象，获得预期的返回对象；

向所述mock对象返回所述预期的返回对象。

另一方面，本申请实施例还提供了一种系统接口测试装置，包括：

请求获取模块，用于获取模拟mock对象发起的业务请求；

返回处理模块，用于在获取到目标调用对象针对所述业务请求返回的返回对象后，根据预设的处理逻辑修改所述返回对象，获得预期的返回对象；

返回发送模块，用于向所述mock对象返回所述预期的返回对象。

本申请实施例可在获取到目标调用对象针对业务请求返回的返回对象后，根据预设的处理逻辑修改返回对象，获得预期的返回对象，从而实现了可以灵活的根据实际的结果或者实际的请求参数来改返回对象，满足了在系统接口测试自动化中构造各种复杂的业务场景的要求。

附图说明

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

图1为本申请一实施例的系统接口测试方法的流程图；

图2为本申请一实施例的系统接口测试装置的结构框图；

图3为本申请另一实施例的系统接口测试方法中包含多个返回处理模块模式下的处理流程示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本申请实施例做进一步详细说明。在此，本申请实施例的示意性实施例及其说明用于解释本申请实施例，但并不作为对本申请实施例的限定。

下面结合附图，对本申请实施例的具体实施方式作进一步的详细说明。

参考图1所示，本申请实施例的系统接口测试方法，包括以下步骤：

S101，获取mock对象发起的业务请求。

其中，mock对象是预先配置好的，其配置例如可为如下所示：

Add Mock With Cond(String mockId,Object expect,String cond,String iocConfig)

mockId–标识拦截的类，即目标调用对象

expect–构建的期望的返回对象

cond–按照条件进行返回对象的处理

S102，在获取到目标调用对象针对所述业务请求返回的返回对象后，根据预设的处理逻辑修改所述返回对象，获得预期的返回对象。

在本申请的一实施例中，当所述处理逻辑有多种时，这些处理逻辑可统一由一个返回处理模块来完成。

在本申请的另一实施例中，如图3所示，当所述处理逻辑有多种时，每种处理逻辑可由一一对应的返回处理模块完成(当系统启动时，这些返回处理模块会被初始化并加载到内存中)，并且所述mock对象发起的业务请求预先与一个返回处理模块绑定。例如在mock配置时可以增加如下配置：

iocConfig–返回处理模块的标识名

该标识名即表明了本次调用目标调用对象所需要的绑定的返回处理模块，通常mock对象发送的业务请求中会携带有该返回处理模块的标识名，当有该目标调用对象的业务请求被拦截时，就会根据返回处理模块的标识名调用相应的返回处理模块(即目标调用对象针对业务请求返回的返回对象被拦截后，会根据业务请求中携带的标识选择返回处理模块)。一般的，绑定仅对本次调用有效，在下次调用时可以根据需要预先绑定任何其他的返回处理模块，以实现另一些mock场景下的测试。

由于一个处理逻辑一般对应一个测试场景，这样以来，不仅各测试场景的职能划分比较清晰，参数层次简单易懂，具有较好的解耦合性；而且还方便了以后期扩展其他的测试场景，而不需要改变原有的返回处理模块，只需增加新的返回处理模块就可以了。

在本申请的一实施例中，所述根据预设的处理逻辑修改所述返回对象可以包括：

根据所述业务请求中的特定输入参数修改所述返回对象中的特定输出参数。

举例来说，某目标调用对象每次执行后生成的ID(identification)是随机的，而目标调用对象一般是测试用例中的某个需要测试的部分，但在整个测试用例中，由于通常上下文之间是有关联关系的，这时就需要用同一个ID贯穿整个测试用例，因此，调用完该目标调用对象后就需要根据预定义的条件属性修改该目标调用对象返回的返回对象中的ID。

比如cond＝"return_param1＝request_param1,return_param2＝request_param1"表示将入参请求中参数名为"request_param1"的参数值设置给返回对象中的参数：return_param1，…

当然，根据具体情况和需要return_param1还可以为复杂对象取参模式，从而可以实现从任何复杂的大对象取到任何参数。比如：

从子对象中取参数：param.id，param.name…

从数组中取参数：param[1].id

从list中取参数：

基础对象：param_list[1]

复杂对象：param_list[1].id

从map中取参数：

基础对象:param_map(key)

复杂对象:param_map(key).id

这样以来，最终实现了基于输入参数调整返回对象，从而获得期望的返回对象的目的。

在本申请的另一实施例中，所述根据预设的处理逻辑修改所述返回对象还可以包括：

根据预定义的条件属性修改返回对象中的特定输出参数。在获取到业务请求后，目标调用对象按照正常的流程进行业务处理，待获取到目标调用对象返回的返回对象后，根据预定义的条件属性修改该返回对象中的特定输出参数，使得最终返回的是期望的返回对象。比如cond＝"return_param1＝xxx,return_param2＝yyy"，则表示将正常业务返回的结果对象中名为"return_param1"的输出参数值修改为xxx；并将正常业务返回的结果对象中名为"return_param2"的输出参数值修改为yyy。

举例来说，某目标调用对象执行完后返回的某输出参数为true，如果期望该输出参数的返回是flase，则需要将true替换为flase，以保证后续整个测试用例往下执行是按照期望进行的。

在本申请的另一实施例中，所述根据预设的处理逻辑修改所述返回对象还可以包括：

当所述mock对象需多次调用同一个目标调用对象并预先配置有多个期望的返回对象时，根据业务请求中携带的特定指示参数决定选择所述多个期望的返回对象中的哪个作为本次调用后所期望的返回对象。

比如cond＝"PARAM＝trans_type,withdraw＝1,dback＝2"表示判断请求中的特定指示参数trans_type，当其值为'withdraw'时返回第一个对象，当其值为'dback'时返回第二个对象。

举例来说，一次性对某目标调用对象设置A，B，C三个返回对象，某测试用例可能会3次调用这个目标调用对象，按照期望，预想第一次调用目标调用对象后返回的返回对象为C，第二次调用目标调用对象后返回的返回对象为A，第三次调用目标调用对象后返回的返回对象为B，因此，可以根据预先定义的条件中的某特定指示参数来决定每次具体应返回哪个返回对象。

S103，向所述mock对象返回所述预期的返回对象。

虽然上文各个方法实施例描述的过程流程包括以特定顺序出现的多个操作，但是，应当清楚了解，这些过程可以包括更多或更少的操作，这些操作可以根据需要顺序执行或并行执行(例如使用并行处理器或多线程环境)。

本申请实施例可在获取到目标调用对象针对业务请求返回的返回对象后，根据预设的处理逻辑修改返回对象，获得预期的返回对象，从而实现了可以灵活的根据实际的结果或者实际的请求参数来改返回对象，满足了在系统接口测试自动化中构造各种复杂的业务场景的要求。并且，本申请实施例还可以通过不同的返回处理模块来处理不同的逻辑处理场景，因此，后续如需要进行测试场景扩展时，添加新返回处理模块即可，而不需要对原有的返回处理模块进行改动，非常方便。

参考图2所示，与上述方法实施例对应，本申请的系统接口测试装置包括：

请求获取模块21，用于获取模拟mock对象发起的业务请求。其中，mock对象是预先设置好的，例如：

Add Mock With Cond(String mockId,Object expect,String cond,String iocConfig)

mockId–标识拦截的类，即目标调用对象

expect–构建的期望的返回对象

cond–按照条件进行返回对象的处理

返回处理模块22，用于在获取到目标调用对象针对所述业务请求返回的返回对象后，根据预设的处理逻辑修改所述返回对象，获得预期的返回对象。

在本申请的一实施例中，当所述处理逻辑有多种时，这些处理逻辑可统一由一个返回处理模块来完成。

在本申请的另一实施例中，当所述处理逻辑有多种时，每种处理逻辑可由一一对应的返回处理模块完成(当系统启动时，这些返回处理模块会被初始化并加载到内存中)，并且所述mock对象发起的业务请求预先与一个返回处理模块绑定。例如在mock配置时可以增加如下配置：

iocConfig–返回处理模块的标识名

该标识名即表明了本次调用目标调用对象所需要的绑定的返回处理模块，通常mock对象发送的业务请求中会携带有该返回处理模块的标识名，当有该目标调用对象的业务请求被拦截时，就会根据返回处理模块的标识名调用相应的返回处理模块(即目标调用对象针对业务请求返回的返回对象被拦截后，会根据业务请求中携带的标识选择返回处理模块)。一般的，绑定仅对本次调用有效，在下次调用时可以根据需要预先绑定任何其他的返回处理模块，以实现另一些mock场景下的测试。

由于一个处理逻辑一般对应一个测试场景，这样以来，不仅各测试场景的职能划分比较清晰，参数层次简单易懂，具有较好的解耦合性；而且还方便了以后期扩展其他的测试场景，而不需要改变原有的返回处理模块，只需增加新的返回处理模块就可以了。

在本申请的一实施例中，所述根据预设的处理逻辑修改所述返回对象可以包括：

根据所述业务请求中的特定输入参数修改所述返回对象中的特定输出参数。举例来说，某目标调用对象每次执行后生成的ID(identification)是随机的，而目标调用对象一般是测试用例中的某个需要测试的部分，但在整个测试用例中，由于通常上下文之间是有关联关系的，这时就需要用同一个ID贯穿整个测试用例，因此，调用完该目标调用对象后就需要根据预定义的条件属性修改该目标调用对象返回的返回对象中的ID。

比如cond＝"return_param1＝request_param1,return_param2＝request_param1"表示将入参请求中参数名为"request_param1"的参数值设置给返回对象中的参数：return_param1，…

当然，根据具体情况和需要return_param1还可以为复杂对象取参模式，从而可以实现从任何复杂的大对象取到任何参数。比如：

从子对象中取参数：param.id，param.name…

从数组中取参数：param[1].id

从list中取参数：

基础对象：param_list[1]

复杂对象：param_list[1].id

从map中取参数：

基础对象:param_map(key)

复杂对象:param_map(key).id

这样以来，最终实现了基于输入参数调整返回对象，从而获得期望的返回对象的目的。

在本申请的另一实施例中，所述根据预设的处理逻辑修改所述返回对象还可以包括：

根据预定义的条件属性修改返回对象中的特定输出参数。在获取到业务请求后，目标调用对象按照正常的流程进行业务处理，待获取到目标调用对象返回的返回对象后，根据预定义的条件属性修改该返回对象中的特定输出参数，使得最终返回的是期望的返回对象。比如cond＝"return_param1＝xxx,return_param2＝yyy"，则表示将正常业务返回的结果对象中名为"return_param1"的输出参数值修改为xxx；并将正常业务返回的结果对象中名为"return_param2"的输出参数值修改为yyy。

举例来说，某目标调用对象执行完后返回的某输出参数为true，如果期望该输出参数的返回是flase，则需要将true替换为flase，以保证后续整个测试用例往下执行是按照期望进行的。

在本申请的另一实施例中，所述根据预设的处理逻辑修改所述返回对象还可以包括：

当所述mock对象需多次调用同一个目标调用对象并预先配置有多个期望的返回对象时，根据业务请求中携带的特定指示参数决定选择所述多个期望的返回对象中的哪个作为本次调用后所期望的返回对象。

比如cond＝"PARAM＝trans_type,withdraw＝1,dback＝2"表示判断请求中的特定指示参数trans_type，当其值为'withdraw'时返回第一个对象，当其值为'dback'时返回第二个对象。

举例来说，一次性对某目标调用对象设置A，B，C三个返回对象，某测试用例可能会3次调用这个目标调用对象，按照期望，预想第一次调用目标调用对象后返回的返回对象为C，第二次调用目标调用对象后返回的返回对象为A，第三次调用目标调用对象后返回的返回对象为B，因此，可以根据预先定义的条件中的某特定指示参数来决定每次具体应返回哪个返回对象。

返回发送模块23，用于向所述mock对象返回所述预期的返回对象。

本申请实施例可在获取到目标调用对象针对业务请求返回的返回对象后，根据预设的处理逻辑修改返回对象，获得预期的返回对象，从而实现了可以灵活的根据实际的结果或者实际的请求参数来改返回对象，满足了在系统接口测试自动化中构造各种复杂的业务场景的要求。并且，本申请实施例还可以通过不同的返回处理模块来处理不同的逻辑处理场景，因此，后续如需要进行测试场景扩展时，只需添加新返回处理模块即可，而不需要对原有的返回处理模块进行改动，非常方便。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片2。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logiccompiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(HardwareDescription Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog2。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone LabsC8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (12)

1.一种系统接口测试方法，其特征在于，包括以下步骤：

获取模拟mock对象发起的业务请求；

在获取到目标调用对象针对所述业务请求返回的返回对象后，根据预设的处理逻辑修改所述返回对象，获得预期的返回对象；

向所述mock对象返回所述预期的返回对象。

2.根据权利要求1所述的系统接口测试方法，其特征在于，当所述处理逻辑有多种时，每种处理逻辑由一一对应的返回处理模块完成，并且所述mock对象发起的业务请求预先与一个返回处理模块绑定。

3.根据权利要求1所述的系统接口测试方法，其特征在于，所述根据预设的处理逻辑修改所述返回对象，包括：

根据所述业务请求中的特定输入参数修改所述返回对象中的特定输出参数。

4.根据权利要求1所述的系统接口测试方法，其特征在于，所述根据预设的处理逻辑修改所述返回对象，包括：

根据预定义的条件属性修改所述返回对象中的特定输出参数。

5.根据权利要求1所述的系统接口测试方法，其特征在于，所述根据预设的处理逻辑修改所述返回对象，包括：

当所述mock对象需多次调用同一个目标调用对象并预先配置有多个期望的返回对象时，根据业务请求中携带的特定指示参数决定选择所述多个期望的返回对象中的哪个作为本次调用后所期望的返回对象。

6.根据权利要求2所述的系统接口测试方法，其特征在于，所述的绑定包括：

在所述业务请求中携带有返回处理模块的标识。

7.一种系统接口测试装置，其特征在于，包括：

请求获取模块，用于获取模拟mock对象发起的业务请求；

返回处理模块，用于在获取到目标调用对象针对所述业务请求返回的返回对象后，根据预设的处理逻辑修改所述返回对象，获得预期的返回对象；

返回发送模块，用于向所述mock对象返回所述预期的返回对象。

8.根据权利要求7所述的系统接口测试装置，其特征在于，当所述处理逻辑有多种时，每种处理逻辑由一一对应的返回处理模块完成，并且所述mock对象发起的业务请求预先与一个返回处理模块绑定。

9.根据权利要求7所述的系统接口测试装置，其特征在于，所述根据预设的处理逻辑修改所述返回对象，包括：

根据所述业务请求中的特定输入参数修改所述返回对象中的特定输出参数。

10.根据权利要求7所述的系统接口测试装置，其特征在于，所述根据预设的处理逻辑修改所述返回对象，包括：

根据所述业务请求中的特定输入参数修改所述返回对象中的特定输出参数。

11.根据权利要求7所述的系统接口测试装置，其特征在于，所述根据预设的处理逻辑修改所述返回对象，包括：

当所述mock对象需多次调用同一个目标调用对象并预先配置有多个期望的返回对象时，根据业务请求中携带的特定指示参数决定选择所述多个期望的返回对象中的哪个作为本次调用后所期望的返回对象。

12.根据权利要求8所述的系统接口测试装置，其特征在于，所述的绑定包括：

在所述业务请求中携带有返回处理模块的标识。