一种多接口测试方法及装置与流程

本发明涉及计算机技术领域，具体涉及一种多接口测试方法及装置。

背景技术：

随着计算机技术的不断发展，应用程序越来越多，各个应用程序中开发的接口也越来越多，各应用程序通过相应的接口进行数据传输。对于新开发的接口，需要进行接口测试从而验证新开发的接口是否正确、运行是否稳定以及对异常数据的处理机制。

现有技术中通过测试用例(testcase)完成接口测试，测试用例是按照接口协议组装成服务接口能识别的报文字符串，一般来说包括输入数据、测试步骤和预期结果等内容。现有的多接口测试方法将多个待测接口排列组合到一起形成测试接口群组。比如，现有的一种多接口测试方法中，基于压力测试工具jmeter以线程组的方法来将多个待测接口组合成测试接口群组。再如，现有的另外一种多接口测试方法中基于自动化测试框架以xml文件的形式将多个待测接口组合成测试接口群组。现有的多接口测试方法中测试接口群组(上述的线程组或xml文件)中的各个待测接口依次完成测试。

然而，发明人在实现本发明实施例的过程中发现：现有技术针对各个单一的待测接口的测试结果一般没有问题，但在实际的接口测试过程中，各应用程序之间的交互通常涉及多种复杂业务场景，在复杂业务场景下对耦合度比较高的多个接口的测试就会出现问题。

技术实现要素：

本发明实施例提供一种多接口测试方法及装置，用于解决现有的多接口测试方法不支持复杂业务场景下接口测试的问题。

本发明实施例提供了一种多接口测试方法，包括：

对测试用例进行解析，获取所述测试用例中的多个待测接口以及各个待测接口的依赖关系；

根据所述各个待测接口的依赖关系，向服务器依次发送与所述各个待测接口对应的多个接口请求；

接收所述服务器返回的与各个接口请求对应的响应结果；

对所述响应结果进行解析，以完成所述多个待测接口的测试；

其中，具有所述依赖关系的两个待测接口中，在后的待测接口对应的接口请求是根据在先的待测接口对应的响应结果而发送的。

可选地，所述各个待测接口的依赖关系是通过所述各个待测接口在所述命令序列中的位置指定的。

可选地，所述各个待测接口的依赖关系是通过依赖字段指定的。

可选地，在后的待测接口对应的接口请求是将在先的待测接口对应的响应结果作为输入参数而发送的。

可选地，在后的待测接口对应的接口请求是在接收到在先的待测接口对应的响应结果后而发送的。

可选地，所述方法还包括：

采用包含命令从预先存储的公共命令序列文件中提取目标命令序列，所述目标命令序列中包括多个常用待测接口以及各个常用待测接口的依赖关系；

将提取到的目标命令序列写入目标测试用例中。

本发明实施例提供一种多接口测试装置，包括：

测试用例解析单元，用于对测试用例进行解析，获取所述测试用例中的多个待测接口以及各个待测接口的依赖关系；

接口请求发送单元，用于根据所述各个待测接口的依赖关系，向服务器依次发送与所述各个待测接口对应的多个接口请求；

响应结果接收单元，用于接收所述服务器返回的与各个接口请求对应的响应结果；

响应结果解析单元，用于对所述响应结果进行解析，以完成所述多个待测接口的测试；

其中，具有所述依赖关系的两个待测接口中，在后的待测接口对应的接口请求是根据在先的待测接口对应的响应结果而发送的。

可选地，所述各个待测接口的依赖关系是通过所述各个待测接口在所述命令序列中的位置指定的。

可选地，所述各个待测接口的依赖关系是通过依赖字段指定的。

可选地，在后的待测接口对应的接口请求是将在先的待测接口对应的响应结果作为输入参数而发送的。

可选地，在后的待测接口对应的接口请求是在接收到在先的待测接口对应的响应结果后而发送的。

可选地，还包括：

目标命令序列提取单元，用于采用包含命令从预先存储的公共命令序列文件中提取目标命令序列，所述目标命令序列中包括多个常用待测接口以及各个常用待测接口的依赖关系；

目标命令序列写入单元，用于将提取到的目标命令序列写入目标测试用例中。

本发明实施例提供一种电子设备，包括：处理器、存储器和总线；其中，

处理器和存储器通过总线完成相互间的通信；

处理器用于调用存储器中的程序指令，以执行上述的多接口测试方法。

本发明实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述的多接口测试方法。

本发明实施例提供的多接口测试方法及装置，对测试用例进行解析，获取所述测试用例中的多个待测接口以及各个待测接口的依赖关系；根据所述各个待测接口的依赖关系，向服务器依次发送与所述各个待测接口对应的多个接口请求；接收所述服务器返回的与各个接口请求对应的响应结果；对所述响应结果进行解析，以完成所述多个待测接口的测试；其中，具有所述依赖关系的两个待测接口中，在后的待测接口对应的接口请求是根据在先的待测接口对应的响应结果而发送的。本发明实施例通过在测试用例指定各个待测接口的依赖关系，增加了接口测试的深度，能满足复杂业务场景下耦合度比较高的多个接口的测试需求。

附图说明

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

图1是本发明一个实施例的多接口测试方法的流程示意图；

图2是本发明一个实施例的多接口测试方法的原理图；

图3是本发明一个实施例的多接口测试装置的结构示意图；

图4是本发明一个实施例的电子设备的结构示意图。

具体实施方式

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

图1是本发明一个实施例的多接口测试方法的流程示意图。如图1所示，该实施例的方法以测试终端为执行主体，测试终端可以是智能手机、个人数码助理(pda)、平板电脑、笔记本电脑等电子设备，本发明对此不作限制。

该实施例的多接口测试方法包括：

s11：对测试用例进行解析，获取所述测试用例中的多个待测接口以及各个待测接口的依赖关系；

需要说明的是，现有技术中的多接口测试方法中，各个待测接口是依次完成测试，没有考虑各个待测接口之间的依赖关系，无法支持复杂业务场景下接口测试。

而本发明实施例的测试终端中保存了预先生成的测试用例，且测试用例中指定了多个待测接口的依赖关系，能满足复杂业务场景下耦合度比较高的多个接口的测试需求。

在实际应用中，测试终端中的测试用例可以用轻量级的数据交换格式json(javascriptobjectnotation,js对象标记)保存，一次编辑，可无限次使用，当然也可以用xml文件、csv文件等其他格式的文件进行保存，本发明对此不作限制。

在实际应用中，测试用例中至少包括一个命令序列，多个待测接口以及各个待测接口的依赖关系保存在命令序列中。

s12：根据所述各个待测接口的依赖关系，向服务器依次发送与所述各个待测接口对应的多个接口请求；

需要说明的是，具有所述依赖关系的两个待测接口中，在后的待测接口对应的接口请求是根据在先的待测接口对应的响应结果而发送的。

s13：接收所述服务器返回的与各个接口请求对应的响应结果；

需要说明的是，本发明实施例的服务器接收到测试终端发送的接口请求后，对接口请求进行处理，生成响应结果，并将生成的响应结果发送至测试终端。

s14：对所述响应结果进行解析，以完成所述多个待测接口的测试；

需要说明的是，测试终端对响应结果进行解析，将响应结果与测试用例的期望结果进行对比，验证多个待测接口是否按照预期运行，以完成多个待测接口的测试。

本发明实施例提供的多接口测试方法，通过在测试用例中指定各个待测接口的依赖关系，增加了接口测试的深度，能满足复杂业务场景下耦合度比较高的多个接口的测试需求。

在实际应用中，本发明实施例提供的多接口测试方法可适用于http、tcp等标准协议的接口测试，也可适用于私有协议的接口测试。

在本发明实施例的一种可选的实施方式中，所述各个待测接口的依赖关系是通过所述各个待测接口在所述命令序列中的位置指定的。

需要说明的是，测试用例中包括多个待测接口，排在前面的接口先于排在后面的接口进行测试，即排在后面的接口的测试要依赖于排在前面接口的响应结果。可理解的是，这种实施方式中的多个待测接口的依赖关系是默认依赖，无需特殊字段指定依赖关系。

以下以抢红包的业务场景中的多接口测试过程进行举例说明，如图2所示，测试终端22向服务器21发送接口请求；服务器21的应用程序中包括接口a和接口b(当然应用程序中还可以包括其他接口，此处以两个接口为例进行说明)，接口a为抢红包接口，接口b为开红包接口。在实际应用中，需要先抢红包得到开红包的凭证，再利用该凭证去开红包，即接口b依赖于接口a抢红包的响应结果作为输入。

该测试用例的部分源码如下：

分析以上源码可知，在测试用例的命令序列中接口a位于接口b之前，且接口a的响应结果作为接口b的输入，本发明实施例通过接口a和接口b在测试用例的命令序列的位置指定接口a和接口b的依赖关系。

在本发明实施例的另一种可选的实施方式中，所述各个待测接口的依赖关系是通过依赖字段指定的。

需要说明的是，测试用例中至少包括一个命令序列，每个命令序列有唯一的标识，这种实施方式通过依赖dependid字段指定各个待测接口的依赖关系。

举例来说，testcase1和testcase2为两个测试用例，假设测试用例testcase1用于测试接口a，测试用例testcase2用于测试接口b；当前的业务场景需要先执行testcase1中的第一个命令序列(tc1#c1)和第三个命令序列(tc1#c3)，然后再执行testcase2中的命令序列。

该测试用例的部分源码如下：

分析以上源码可知，测试用例testcase2中的第一个命令序列(tc2#c1)依赖于测试用例testcase1中的第一个命令序列(tc1#c1)和第三个命令序列(tc1#c3)。本发明实施例通过指定dependid字段，提高了多个待测接口进行组合测试的灵活性，完成了复杂业务场景多接口测试的深度覆盖，弥补了现有的多接口测试方法的堆砌式测试的缺陷。

具体地，待测接口的依赖关系包括：在先待测接口对应的接口请求的响应结果作为在后待测接口对应的接口请求的输入参数，在先待测接口的接口请求的处理结果是在后待测接口对应的接口请求的处理结果的前提。

在本发明实施例的一种可选的实施方式中，在后的待测接口对应的接口请求是将在先的待测接口对应的响应结果作为输入参数而发送的。

例如，上述实施例中的抢红包业务场景中的多接口测试中，在后的接口b对应的接口请求是将在先的接口a对应的响应结果作为输入参数而发送的。即测试终端根据接口a和接口b的依赖关系，先向服务器发送接口a对应的接口请求，接收服务器返回的与该接口请求对应的响应结果，将该响应结果作为接口b对应的接口请求的输入参数并向服务器发送接口b对应的接口请求。

在本发明实施例的另一种可选的实施方式中，在后的待测接口对应的接口请求是在接收到在先的待测接口对应的响应结果后而发送的。

可理解的是，在另外的业务场景下，在后的待测接口对应的接口请求的输入参数并不依赖在先的待测接口对应的接口请求的响应结果，而是在先待测接口的接口请求的处理结果是在后待测接口对应的接口请求的处理结果的前提，因而，在后的待测接口对应的接口请求是在接收到在先的待测接口对应的响应结果后而发送的。

在实际应用中，当某个复杂业务场景下的多接口测试完成后，测试终端可重新发送接口请求调用服务器的接口模拟更多的业务场景，完成耦合度比较高的多个接口的测试。

进一步地，所述方法还包括：

采用包含命令从预先存储的公共命令序列文件中提取目标命令序列，所述目标命令序列中包括多个常用待测接口以及各个常用待测接口的依赖关系；

将提取到的目标命令序列写入目标测试用例中。

需要说明的是，现有的多接口测试方法中的测试用例生成没有上述抽离操作，增大了测试用例生成的复杂度和时间成本。而本发明实施例为了简化测试用例的生成过程，将常用待测接口(比如登录login操作对应的待测接口)对应的命令序列存储到公共命令序列文件，在实际生成目标测试用例的过程中，采用包含include命令从公共命令序列文件中提取目标命令序列。

具体地，公共命令序列文件的格式为json文件(当然也可以其他文件形式保存公共命令序列，本发明对此不作限制)，公共命令序列文件的数据结构为map，其中key表示命令序列名，value是命令序列。

举例来说，公共命令序列文件comm.json的部分源码如下：

在实际应用中，可采用包含include命令根据命令序列名将comm.json中的对应的命令序列写入到实际的测试用例中，降低了测试用例生成的复杂度和时间成本。

通过此优化，就把复用率较高的一些接口请求，放入到类似模版的一个容器里面，待需要调用的时候，直接include就可以了，就不需要每次有新的接口测试的任务的时候，都需要去编辑这些重复的数据,大大的提高了接口测试的效率，一次编辑无限引用.

图3是本发明一个实施例的多接口测试装置的结构示意图。如图3所示，本发明实施例的装置包括：测试用例解析单元31、接口请求发送单元32、响应结果接收单元33和响应结果解析单元34，具体地：

测试用例解析单元31，用于对测试用例进行解析，获取所述测试用例中的多个待测接口以及各个待测接口的依赖关系；

接口请求发送单元32，用于根据所述各个待测接口的依赖关系，向服务器依次发送与所述各个待测接口对应的多个接口请求；

响应结果接收单元33，用于接收所述服务器返回的与各个接口请求对应的响应结果；

响应结果解析单元34，用于对所述响应结果进行解析，以完成所述多个待测接口的测试；

其中，具有所述依赖关系的两个待测接口中，在后的待测接口对应的接口请求是根据在先的待测接口对应的响应结果而发送的。

本发明实施例提供的多接口测试装置，通过在测试用例中指定各个待测接口的依赖关系，增加了接口测试的深度，能满足复杂业务场景下耦合度比较高的多个接口的测试需求。

可选地，所述各个待测接口的依赖关系是通过所述各个待测接口在所述命令序列中的位置指定的。

可选地，所述各个待测接口的依赖关系是通过依赖字段指定的。

可选地，在后的待测接口对应的接口请求是将在先的待测接口对应的响应结果作为输入参数而发送的。

可选地，在后的待测接口对应的接口请求是在接收到在先的待测接口对应的响应结果后而发送的。

可选地，还包括：

目标命令序列提取单元，用于采用包含命令从预先存储的公共命令序列文件中提取目标命令序列，所述目标命令序列中包括多个常用待测接口以及各个常用待测接口的依赖关系；

目标命令序列写入单元，用于将提取到的目标命令序列写入目标测试用例中。

本发明实施例的多接口测试装置可以用于执行上述方法实施例，其原理和技术效果类似，此处不再赘述。

图4是本发明一个实施例的电子设备的结构示意图。

参照图4，电子设备包括：处理器(processor)41、存储器(memory)42和总线43；其中，

处理器41和存储器42通过总线43完成相互间的通信；

处理器41用于调用存储器42中的程序指令，以执行上述各方法实施例所提供的多接口测试方法。

此外，上述的存储器42中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本实施例提供一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的多接口测试方法。

本实施例提供一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令使所述计算机执行上述各方法实施例所提供的多接口测试方法。

本发明实施例提供的多接口测试方法及装置，对测试用例进行解析，获取所述测试用例中的多个待测接口以及各个待测接口的依赖关系；根据所述各个待测接口的依赖关系，向服务器依次发送与所述各个待测接口对应的多个接口请求；接收所述服务器返回的与各个接口请求对应的响应结果；对所述响应结果进行解析，以完成所述多个待测接口的测试；其中，具有所述依赖关系的两个待测接口中，在后的待测接口对应的接口请求是根据在先的待测接口对应的响应结果而发送的。本发明实施例通过在测试用例中指定各个待测接口的依赖关系，增加了接口测试的深度，能满足复杂业务场景下耦合度比较高的多个接口的测试需求。

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

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

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

本发明的说明书中，说明了大量具体细节。然而能够理解的是，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。类似地，应当理解，为了精简本发明公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

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