CN111488285A - 接口测试方法、装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本公开实施例涉及自动化测试技术领域，公开了一种接口测试方法、装置、电子设备及计算机可读存储介质，其中，接口测试方法包括：获取测试用例，测试用例是基于待测试接口的应用程序接口API生成的，待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块封装成的，预定服务协议模块是待测试接口的请求协议对应的封装模块；接着，运行测试用例，通过调用待测试接口的API对待测试接口进行测试。实现了测试用例与接口信息之间的解耦，有效避免测试用例因接口信息的变动而大量修改的情况的发生，极大降低测试用例维护成本与维护难度。

Description

接口测试方法、装置、电子设备及计算机可读存储介质

技术领域

本公开实施例涉及自动化测试技术领域，具体而言，本公开涉及一种接口测试方法、装置、电子设备及计算机可读存储介质。

背景技术

随着敏捷开发模式在互联网行业的广泛应用，持续集成和持续发布在研发过程中的使用，显得日益重要。其中，接口自动化测试是持续集成和持续发布过程中非常重要的一环。

目前的接口自动化测试中，测试人员预先编写待测试接口对应的测试用例，向待测试接口发送该测试用例对应的接口请求消息，并接收待测试接口反馈的响应消息，根据测试用例对应的接口请求消息与响应消息确定测试结果。在实际应用中，每一个接口都对应有参数，每一个参数可能有多个取值，每一个测试用例中包括所有参数的取值。为了保证对接口测试的全面性，测试人员需要编写多个测试用例，以使该多个测试用例可以覆盖所有参数取值的组合。

然而，本公开的发明人在具体实施过程中，发现：在目前的接口自动化测试中，测试用例和测试接口之间是紧密相关，当测试接口的接口信息发生变更，比如接口参数变更、接口迁移等，涉及该测试接口的原有测试用例均需要修改，导致需要维护大量的测试用例，造成较高的测试用例维护成本。

发明内容

本公开实施例的目的旨在至少能解决上述的技术缺陷之一，特提供该发明内容部分以便以简要的形式介绍构思，这些构思将在后面的具体实施方式部分被详细描述。该发明内容部分并不旨在标识要求保护的技术方案的关键特征或必要特征，也不旨在用于限制所要求的保护的技术方案的范围。

一方面，提供了一种接口测试方法，包括：

获取测试用例，测试用例是基于待测试接口的应用程序接口API生成的；待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块封装成的，预定服务协议模块是待测试接口的请求协议对应的封装模块；

运行测试用例，通过调用待测试接口的API对待测试接口进行测试。

一方面，提供了一种接口测试装置，包括：

获取模块，用于获取测试用例，测试用例是基于待测试接口的应用程序接口API生成的；待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块封装成的，预定服务协议模块是待测试接口的请求协议对应的封装模块；

测试模块，用于运行测试用例，通过调用待测试接口的API对待测试接口进行测试。

一方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行所述程序时实现上述的接口测试方法。

一方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述的接口测试方法。

本公开实施例提供的接口测试方法，根据待测试接口的接口信息，通过预定服务协议模块对待测试接口进行封装，将接口信息的频繁变动拦截在接口封装这一阶段，在接口测试过程中，当接口信息发生变化时，只需修改对应的待测试接口的API即可，不会对获取到的测试用例造成任何影响，从而可以基于获取到的测试用例对修改后的待测试接口的API进行测试，实现了测试用例与接口信息之间的解耦，有效避免测试用例因接口信息的变动而大量修改的情况的发生，极大降低测试用例维护成本与维护难度。

本公开实施例附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本公开的实践了解到。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本公开实施例的接口测试方法的流程示意图；

图2为本公开实施例的三层模型架构示意图；

图3为本公开实施例的三层模型在HTTP服务中的应用示意图；

图4为本公开实施例的基于三层模型的接口测试示意图；

图5为本公开实施例的接口测试装置的基本结构示意图；

图6为本公开实施例的电子设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

应当理解，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

需要注意，本公开中提及的“第一”、“第二”等概念仅用于对装置、模块或单元进行区分，并非用于限定这些装置、模块或单元一定为不同的装置、模块或单元，也并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

需要注意，本公开中提及的“一个”、“多个”的修饰是示意性而非限制性的，本领域技术人员应当理解，除非在上下文另有明确指出，否则应该理解为“一个或多个”。

本公开实施方式中的多个装置之间所交互的消息或者信息的名称仅用于说明性的目的，而并不是用于对这些消息或信息的范围进行限制。

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合附图对本公开实施方式作进一步地详细描述。

下面以具体地实施例对本公开实施例的技术方案以及本公开实施例的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本公开的实施例进行描述。

本公开一个实施例提供了一种接口测试方法，该方法由计算机设备执行，该计算机设备可以是终端或者服务器。终端可以是台式设备或者移动终端。服务器可以是独立的物理服务器、物理服务器集群或者虚拟服务器。

如图1所示，该方法包括：

步骤S110，获取测试用例，测试用例是基于待测试接口的应用程序接口API生成的；待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块封装成的，预定服务协议模块是待测试接口的请求协议对应的封装模块；步骤S120，运行测试用例，通过调用待测试接口的API对待测试接口进行测试。

具体地，在接口测试过程中，需要运行测试用例来对待测试接口进行测试，故需要先获取测试用例，再运行获取到的测试用例，来对待测试接口进行测试，其中，测试用例可以是基于待测试接口的应用程序接口API预先生成的，且在运行获取到的测试用例对待测试接口进行测试时，可以运行测试用例，通过调用待测试接口的API来对待测试接口进行测试。

具体地，在对待测试接口进行测试之前，可以预先通过预定服务协议模块，对待测试接口的接口信息进行封装，得到封装后的待测试接口的API，即待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块预先封装成的，从而在对待测试接口进行测试的过程中，运行测试用例，并通过调用待测试接口的API即可完成对待测试接口的测试，即在对待测试接口进行测试的过程中，可以通过调用待测试接口的API，来对待测试接口进行测试。

具体地，预定服务协议模块是待测试接口的请求协议对应的封装模块，当待测试接口A的请求协议为A协议时，预定服务协议模块是待测试接口A的A协议对应的封装模块，当待测试接口B的请求协议为B协议时，预定服务协议模块是待测试接口B的B协议对应的封装模块。

本公开实施例提供的接口测试方法，根据待测试接口的接口信息，通过预定服务协议模块对待测试接口进行封装，将接口信息的频繁变动拦截在接口封装这一阶段，在接口测试过程中，当接口信息发生变化时，只需修改对应的待测试接口的API即可，不会对获取到的测试用例造成任何影响，从而可以基于获取到的测试用例对修改后的待测试接口的API进行测试，实现了测试用例与接口信息之间的解耦，有效避免测试用例因接口信息的变动而大量修改的情况的发生，极大降低测试用例维护成本与维护难度。

下面对本公开实施例的方法进行具体介绍：

在一种可能的实现方式中，获取测试用例，包括：首先，获取配置文件，配置文件用于指示测试环境、测试数据和测试逻辑；测试环境、所述测试数据和所述测试逻辑分别独立维护；接着，根据配置文件，组合生成测试用例，测试用例用于在测试环境下，基于测试逻辑和测试数据，通过调用待测试接口的API实现测试。

具体地，测试人员可以根据测试需求，在配置文件中统一配置测试计划、测试过程中涉及到的数据库及Redis(缓存)等信息，测试计划不仅可以包括待测试接口，还可以包括测试环境、测试逻辑及测试数据等，即配置文件用于指示测试环境、测试数据和测试逻辑。其中，测试环境、测试数据和测试逻辑之间是相互独立的，即分别独立维护测试环境、测试数据和测试逻辑，从而实现了测试环境、测试数据和测试逻辑的三要素分离。

其中，测试逻辑与测试数据之间是相对应的，这个对应关系在编写测试逻辑时已经确定好，从而在配置好测试逻辑后，即可根据测试逻辑确定出对应的测试数据。由于测试环境会影响测试数据，比如线下测试环境与线上测试环境使用不同的测试数据等，因此，需要在确定测试环境后，才能根据测试环境、测试逻辑与测试数据组合生成相应的测试用例，即根据配置文件，组合生成测试用例，便于生成的测试用例可以在确定出的测试环境下，基于确定出的测试逻辑和测试数据，通过调用待测试接口的API实现对待测试接口的测试。

具体地，测试计划也可以包括待测试场景、待测试场景的测试环境、待测试场景的测试逻辑与待测试场景的测试数据等。当测试计划包括待测试场景时，该待测试场景下的各个接口都为待测试接口，即将该待测试场景的各个接口均作为待测试接口。其中，在该待测试场景的测试环境下，根据该待测试场景的测试环境、测试逻辑与测试数据，组合生成测试用例，便于该生成的测试用例在确定出的测试环境下，基于确定出的测试逻辑和测试数据，通过调用该待测试场景下的各个待测试接口的API分别实现对各个待测试接口的测试。

具体地，在根据配置文件确定出测试环境、测试逻辑与测试数据后，可以在确定出的测试环境下，根据确定出的测试逻辑与测试数据，生成相应的测试用例，从而通过运行测试用例并调用待测试接口的API实现对待测试接口的测试，使得在接口测试过程中，当接口信息发生变化时，只需修改对应的封装接口即可，不会对测试逻辑造成影响，从而根据该测试逻辑和修改后的待测试接口所对应的测试数据，即可自动生成修改后的待测试接口所对应的测试用例。

具体地，在对待测试接口进行测试之前，预先通过预定服务协议模块，对待测试接口的接口信息进行封装，得到封装后的待测试接口，该封装后的待测试接口即为配置的待测试接口，即配置的待测试接口是根据待测试接口的接口信息，通过预定服务协议模块封装成的。通过预定服务协议模块，对待测试接口的接口信息进行封装，将接口信息的频繁变动拦截在接口封装这一阶段，从而当接口信息发生变化时，只需修改对应的封装接口即可，封装好的接口可以供不同的测试用例直接调用，从而不会影响到测试用例本身，实现了测试用例与接口信息之间的解耦。

具体地，测试逻辑中关注的是测试用例中的测试部分，测试数据存储于CSV(Comma-Separated Values，字符分隔值)文件中，配置文件用于配置测试计划、测试过程中涉及到的数据库及Redis(缓存)等信息。

在一种可能的实现方式中，通过预定三层模型的第三层分离式维护测试环境、测试逻辑及测试数据，通过预定三层模型的第二层维护待测试接口，以及通过预定三层模型的第一层维护预定服务协议模块。

具体地，预定服务协议模块至少包括以下任一项：基于HTTP请求协议的服务协议模块，基于Dubbo请求协议的微服务协议模块，基于Thrift请求协议的微服务协议模块，基于Motan请求协议的微服务协议模块，基于Grpc请求协议的微服务协议模块。其中，当待测试接口的请求协议为HTTP请求协议时，预定服务协议模块为基于HTTP请求协议的服务协议模块；当待测试接口的请求协议为Dubbo请求协议时，预定服务协议模块为基于Dubbo请求协议的服务协议模块；当待测试接口的请求协议为Thrift请求协议时，预定服务协议模块为基于Thrift请求协议的服务协议模块；当待测试接口的请求协议为Motan请求协议时，预定服务协议模块为基于Motan请求协议的服务协议模块；当待测试接口的请求协议为Grpc请求协议时，预定服务协议模块为基于Grpc请求协议的服务协议模块。

具体地，在通过预定服务协议模块，对待测试接口的接口信息进行封装之后，可以将封装后的待测试接口的API配置于预定三层模型的第二层中。

具体地，采用三层模型架构可以将接口测试拆分为三层，分别为第一层(或称为基础框架层)、第二层(或称为接口封装层)及第三层(或称为测试用例层)。其中，基础框架层涉及对HTTP(HyperText Transfer Protocol，超文本传输协议)服务、微服务、数据库及Redis等基础模块或者公共模块的定义，微服务又包括基于Dubbo请求协议的微服务、基于Thrift请求协议的微服务、基于Motan请求协议的微服务及基于Grpc请求协议的微服务等，当然，除了包括上述请求协议的微服务之外，还包括基于其它请求协议的微服务，在此不再一一列举。为便于描述，可以将HTTP服务这一基础模块记作基于HTTP请求协议的服务协议模块；根据不同的微服务协议，可以将微服务这一基础模块拆分为基于Dubbo请求协议的微服务协议模块、基于Thrift请求协议的微服务协议模块、基于Motan请求协议的微服务协议模块及基于Grpc请求协议的微服务协议模块。

具体地，基于HTTP请求协议的服务协议模块包含了HTTP服务的请求头、请求体等之间的类定义和关系描述；基于Dubbo请求协议的微服务协议模块包含了Dubbo服务的请求头、请求体等之间的类定义和关系描述；基于Thrift请求协议的微服务协议模块包含了Thrift服务的请求头、请求体等之间的类定义和关系描述。数据库模块实现对数据库表头、数据等之间的抽象和数据库基础操作的封装。Redis模块实现了与缓存操作相关的封装。

具体地，接口封装层主要是根据基础框架层的预定服务协议模块，对待测试接口进行封装，并且在对待测试接口进行封装之后，可以把封装后的待测试接口配置于接口封装层中，以便于可以基于测试用例层对其进行测试，即接口封装层中的接口为通过预定服务协议模块，对待测试接口的接口信息进行封装之后的待测试接口。

具体地，当三层模型架构运用在HTTP服务中时，即待测试接口是基于HTTP请求协议的接口，接口封装层可以根据基础框架层的基于HTTP请求协议的服务协议模块，来对待测试接口进行封装；当三层模型架构运用在Dubbo请求协议的微服务中时，即待测试接口是基于Dubbo请求协议的接口，接口封装层可以根据基础框架层的基于Dubbo请求协议的微服务协议模块，来对待测试接口进行封装；当三层模型架构运用在Thrift请求协议的微服务中时，即待测试接口是基于Thrift请求协议的接口，接口封装层可以根据基础框架层的基于Thrift请求协议的微服务协议模块，来对待测试接口进行封装。

需要说明的是，接口封装层在对待测试接口进行封装的过程中，除了依赖于基础框架层的预定服务协议模块外，还需要依赖于公共模块。

具体地，测试环境、测试逻辑及测试数据均位于预定三层模型的第三层(即测试用例层)，且测试环境、测试逻辑及测试数据之间是相互独立的；即通过预定三层模型实现了测试环境、测试逻辑及测试数据三要素的分离。在配置文件中可以通过设置一个全局变量的方式，来设置测试环境，比如线上测试环境、线下测试环境等，在配置文件的测试计划中可以通过设置一个局部变量的方式，再次根据测试需求对测试环境进行重新设置，比如设置一部分测试用例在线上环境下测试、另一部分测试用例在线上环境下测试等。其中，当在测试计划中重新设置了测试环境时，配置文件中设置的测试环境将会失效，即根据测试计划中设置的测试环境进行测试，当测试计划中未重新设置测试环境时，配置文件中设置的测试环境有效，即根据配置文件中设置的测试环境进行测试，从而能够有效地进行测试环境的隔离。

具体地，在测试用例层可以将测试数据和对应的待测试接口配置在一起，待测试接口的测试逻辑是固定不变的，但是待测试接口的测试数据可以发生增、删、改等变更，从而实现了对测试数据和测试逻辑的分离。无论测试数据如何变化，只要测试逻辑不变，即可以根据测试逻辑与测试数据，自动生成待测试接口的测试用例，以便于根据测试用例对待测试接口进行测试，实现了测试用例的自动生成，实现了测试用例与接口信息之间的解耦。

具体地，三层模型的架构如图2所示，在图2中，基础框架层(即第一层)可以包括基于HTTP请求协议的服务协议模块、基于Dubbo请求协议的微服务协议模块、基于Thrift请求协议的微服务协议模块、基于Motan请求协议的微服务协议模块及基于Grpc请求协议的微服务协议模块等预定服务协议模块、数据库模块、Redis模块及公共模块；其中，基础框架层中的各个模块本质上也是API(Application Programming Interface，应用程序接口)，在使用过程中可以直接进行接口调用，方便使用。接口封装层为根据基于框架层的预定服务协议模块封装成的待测试接口，比如登录接口(LoginAPI)、用户接口(UserFacade)、评论接口(CommentAPI)、搜索接口(SearchAPI)、作品接口(ItemFacade)及计数接口(CountFacade)等，其中，用户接口、作品接口及计数接口等是与微服务相对应的接口，登录接口、评论接口及搜索接口等是与HTTP服务相对应的接口。测试用例层可以包括登录测试用例、评论测试用例及发布测试用例等测试用例。

在一种可能的实现方式中，在通过预定服务协议模块，对待测试接口的接口信息进行封装的过程中，可以执行如下处理：首先，确定预定服务协议模块对应的请求模板；接着，将待测试接口的接口信息写入请求模板中，并将写入接口信息后的请求模板封装为相应版本的数据包，从而实现待测试接口的封装。

在实际应用中，可以通过将待测试接口的接口信息写入预定服务协议模块的请求模板中，来对待测试接口进行封装，得到封装后的待测试接口。其中，当待测试接口为基于HTTP服务协议的接口时，可以通过将待测试接口的接口信息写入基于HTTP请求协议的服务协议模块的请求模板中，来对待测试接口进行封装；当待测试接口为基于Dubbo请求协议的接口时，可以通过将待测试接口的接口信息写入基于Dubbo请求协议的微服务协议模块的请求模板中，来对待测试接口进行封装；当待测试接口为基于Thrift请求协议的接口时，可以通过将待测试接口的接口信息写入基于Thrift请求协议的微服务协议模块的请求模板中，来对待测试接口进行封装。

具体地，在将待测试接口的接口信息写入预定服务协议模块的请求模板之前，需要先生成预定服务协议模块的请求模板。在生成预定服务协议模块的请求模板的过程中，可以执行如下处理过程：首先，将预定服务协议模块的请求协议的各部分协议内容，分别封装为对应的各个协议类；接着，定义各个协议类之间的关联关系，并根据关联关系生成请求模板。

具体地，对于基于HTTP请求协议的服务协议模块，可以将HTTP请求协议的各部分协议内容进行封装，得到各个协议类，通过定义各个协议类之间的关系，生成基于HTTP请求协议的服务协议模块的请求模板。对于基于Dubbo请求协议的微服务协议模块，可以将Dubbo请求协议的各部分协议内容进行封装，得到各个协议类，通过定义各个协议类之间的关系，生成基于Dubbo请求协议的服务协议模块的请求模板。对于基于Thrift请求协议的微服务协议模块，可以将Thrift请求协议的各部分协议内容进行封装，得到各个协议类，通过定义各个协议类之间的关系，生成基于Thrift请求协议的服务协议模块的请求模板。

下面三层模型应用于HTTP服务中为例，对生成预定服务协议模块对应的请求模板进行具体介绍：

三层模型应用于HTTP服务中时，相当于预定服务协议模块为基于HTTP请求协议的服务协议模块。在生成请求模板的过程中，基础框架层对HTTP请求中的请求头、请求体等进行封装，实现了类Header、Endpoint(用户订阅主题时，指定接收消息的终端地址)、Body、RestfulAPI和IClient等，通过定义这些类之间的关系，抽象成基于HTTP请求协议的服务协议模块的请求模版。相当于，对HTTP请求协议进行了拆分，并将各个拆分部分封装成了不同的类，把各个类之间的关系定义清楚，就可以根据各个类之间的关系，创建基于HTTP请求协议的服务协议模块的请求模板。

图3给出了以HTTP协议中的Request(请求)为例，给出了HTTP协议的拆分示例。在图3中，空心菱形代表组成关系，实心三角形代表继承关系。在实际应用中，若要构造一个Request，则必须包含Request的Header、Endpoint和Body三大必要元素。此外，请求必然具有发送能力，故需要有一个具有发送能力的IClient(客户端)，RestfulAPI为请求中各个部分的展现形式，也是一种协议，它可以是JSON(JavaScript Object Notation，JS对象简谱)展现形式，即图中的JSONBodyRestfulAPI，也可以是XML(eXtensible Markup Language，可扩展标记语言)展现形式，即图中的XMLBodyRestfulAPI。

其中，在对HTTP协议中的Request进行拆分之后，可以得到Header、Endpoint、Body、IClient及RestfulAPI等各个类。在得到各个类之后，可以将该各个类之间的关系抽象出来，从而相应的请求模板。

本申请实施例中请求模板对于扩展是开放的、而对于修改是封闭的，符合开闭原则，使得请求模板具有很高的通用性和稳定性。例如Body可以被XMLBody、HTMLBody、JSONBody等多种不同类型的Body继承，当新增一种类型时，只需新增一个类继承Body即可，而Body本身和请求模版均无需更改。

具体地，基于基础框架层提供的请求模板，可以非常便捷地对待测试接口进行封装，只需要将待测试接口的接口信息写入到请求模板中，即可得到封装后的待测试接口，并不会影响到测试用例本身。比如待测试接口为登录接口，只需要将登录接口的接口信息(比如接口信息F1)写入到请求模板中，即可得到封装后的登录接口。其中，将待测试接口的接口信息写入到请求模板后，可以将写入接口信息后的请求模板封装为第一版本(例如版本1.0.0)的数据包(例如JAR数据包)，该数据包即为封装后的待测试接口对应的数据信息，且数据包的版本与待测试接口的版本是一一对应的。

具体地，在运行测试用例，通过调用待测试接口的API对待测试接口进行测试的过程中，首先，获取与待测试接口的API相对应的数据包；接着，运行测试用例，通过调用待测试接口的API对应的数据包，来待测试接口进行测试。比如，可以先确定待测试接口的API的版本信息，再根据该版本信息获取相应版本的数据包，再运行测试用例对该相应版本的数据包进行测试。相当于，在根据测试用例对封装后的待测试接口的API进行测试时，测试用例可以直接调用与该待测试接口的API相对应的数据包，来完成对待测试接口的测试。

具体地，当待测试接口的接口信息发生变化时，比如由接口信息F1更新为接口信息F2，则可以将变化后的接口信息(比如接口信息F2)重新写入请求模板中，从而得到重新封装后的待测试接口的API。其中，将待测试接口的接口信息F2写入到请求模板后，可以将写入接口信息F2后的请求模板重新封装为第二版本(例如版本1.0.1)的数据包(例如JAR数据包)，该数据包即为封装后的待测试接口的API对应的数据信息，且数据包的版本(例如版本1.0.1)与待测试接口的API的版本是一一对应的。在这种情况下，若确定待测试接口的API的版本信息为1.0.1，则获取与其对应的1.0.1版本的数据包，并在确定出的测试环境下，基于确定出的测试逻辑与测试数据，通过调用待测试接口的API对应的1.0.1版本的数据包进行测试，从而完成对待测试接口的测试；若确定待测试接口的API的版本信息为1.0.0，则获取与其对应的1.0.0版本的数据包，并在确定出的测试环境下，基于确定出的根据测试逻辑与测试数据，通过调用待测试接口的API对应的1.0.0版本的数据包进行测试，从而完成对待测试接口的测试。

具体地，图4给出了基于三层模型的接口测试示意图。在图4中，测试用例可以直接调用封装后的点赞接口(即待测试接口为封装后的点赞接口)的API，如果点赞接口的接口信息发生变更，只需修改点赞接口的API即可，比如将原来的点赞接口的API(例如API_1.0)修改更新后的点赞接口的API(例如API_1.1)，从而实现测试用例与接口信息之间的解耦，有效避免测试用例随着接口信息的更新而大量更新的情况的发生。

本申请实施例的方法，通过将接口测试抽象成基础框架层、接口封装层和测试用例层，成功地将接口信息的频繁变动拦截在接口封装层，并实现了配置文件、测试数据与测试逻辑这三元素之间的分离，有效降低了测试用例的维护成本，提高接口自动化测试的效率。

图5为本公开又一实施例提供的一种接口测试装置的结构示意图，如图5所示，该装置500可以包括获取模块501与测试模块502，其中：

获取模块501，用于获取测试用例，测试用例是基于待测试接口的应用程序接口API生成的；待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块封装成的，预定服务协议模块是待测试接口的请求协议对应的封装模块；

测试模块502，用于运行测试用例，通过调用待测试接口的API对待测试接口进行测试。

在一种可能的实现方式中，获取模块在获取测试用例时，用于：

获取配置文件，配置文件用于指示测试环境、测试数据和测试逻辑；测试环境、测试数据和测试逻辑分别独立维护；

根据配置文件，组合生成测试用例，测试用例用于在测试环境下，基于测试逻辑和测试数据，通过调用待测试接口的API的实现测试。

在一种可能的实现方式中，该装置还包括：处理模块；

处理模块，用于通过预定三层模型的第三层分离式维护测试环境、测试逻辑及测试数据，通过预定三层模型的第二层维护待测试接口的API，以及通过预定三层模型的第一层维护预定服务协议模块。

在一种可能的实现方式中，该装置还包括：封装模块，封装模块用于通过预定服务协议模块，对待测试接口的接口信息进行封装；

封装模块具体用于：

确定预定服务协议模块对应的请求模板；

将待测试接口的接口信息写入请求模板中，并将写入接口信息后的请求模板封装为相应版本的数据包。

在一种可能的实现方式中，该装置还包括生成模块，生成模块用于：

将预定服务协议模块的请求协议的各部分协议内容，分别封装为对应的各个协议类；

定义各个协议类之间的关联关系，并根据关联关系生成请求模板。

在一种可能的实现方式中，当待测试接口的请求协议为HTTP请求协议时，预定服务协议模块为基于HTTP请求协议的服务协议模块；

当待测试接口的请求协议为Dubbo请求协议时，预定服务协议模块为基于Dubbo请求协议的服务协议模块；

当待测试接口的请求协议为Thrift请求协议时，预定服务协议模块为基于Thrift请求协议的服务协议模块；

当待测试接口的请求协议为Motan请求协议时，预定服务协议模块为基于Motan请求协议的服务协议模块；

当待测试接口的请求协议为Grpc请求协议时，预定服务协议模块为基于Grpc请求协议的服务协议模块。

本公开实施例提供的装置，根据待测试接口的接口信息，通过预定服务协议模块对待测试接口进行封装，将接口信息的频繁变动拦截在接口封装这一阶段，在接口测试过程中，当接口信息发生变化时，只需修改对应的待测试接口的API即可，不会对获取到的测试用例造成任何影响，从而可以基于获取到的测试用例对修改后的待测试接口的API进行测试，，实现了测试用例与接口信息之间的解耦，有效避免测试用例因接口信息的变动而大量修改的情况的发生，极大降低测试用例维护成本与维护难度。

需要说明的是，本实施例为与上述的方法项实施例相对应的装置项实施例，本实施例可与上述方法项实施例互相配合实施。上述方法项实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在上述方法项实施例中。

下面参考图6，其示出了适于用来实现本公开实施例的电子设备600的结构示意图。本公开实施例中的终端设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。图6出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

电子设备包括存储器以及处理器，其中，这里的处理器可以称为下方所述的处理装置601，存储器包括下文中的只读存储器(ROM)602、随机访问存储器(RAM)603以及存储装置608中的至少一项，具体如下所示：

如图6所示，电子设备600可以包括处理装置(例如中央处理器、图形处理器等)601，其可以根据存储在只读存储器(ROM)602中的程序或者从存储装置608加载到随机访问存储器(RAM)603中的程序而执行各种适当的动作和处理。在RAM 603中，还存储有电子设备600操作所需的各种程序和数据。处理装置601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

通常，以下装置可以连接至I/O接口605：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置606；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置607；包括例如磁带、硬盘等的存储装置608；以及通信装置609。通信装置609可以允许电子设备600与其他设备进行无线或有线通信以交换数据。虽然图6示出了具有各种装置的电子设备600，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置609从网络上被下载和安装，或者从存储装置608被安装，或者从ROM 602被安装。在该计算机程序被处理装置601执行时，执行本公开实施例的方法中限定的上述功能。

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：获取测试用例，测试用例是基于待测试接口的应用程序接口API生成的；生成的待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块封装成的，预定服务协议模块是待测试接口的请求协议对应的封装模块；接着，运行测试用例，通过调用待测试接口的API对待测试接口进行测试。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

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

描述于本公开实施例中所涉及到的模块或单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块或单元的名称在某种情况下并不构成对该单元本身的限定，例如，获取模块还可以被描述为“检测到发生预定直播事件时，获取预定直播事件对应的至少一种事件处理方式的模块”。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：现场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、片上系统(SOC)、复杂可编程逻辑设备(CPLD)等等。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

根据本公开的一个或多个实施例，提供了一种接口测试方法，包括：

获取测试用例，测试用例是基于待测试接口的应用程序接口API生成的；待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块封装成的，预定服务协议模块是待测试接口的请求协议对应的封装模块；

运行测试用例，通过调用待测试接口的API对待测试接口进行测试。

在一种可能的实现方式中，获取测试用例，包括：

获取配置文件，配置文件用于指示测试环境、测试数据和测试逻辑；测试环境、测试数据和测试逻辑分别独立维护；

根据配置文件，组合生成测试用例，测试用例用于在测试环境下，基于测试逻辑和测试数据，通过调用待测试接口的API的实现测试。

在一种可能的实现方式中，通过预定三层模型的第三层分离式维护测试环境、测试逻辑及测试数据，通过预定三层模型的第二层维护待测试接口的API，以及通过预定三层模型的第一层维护预定服务协议模块。

在一种可能的实现方式中，通过预定服务协议模块，对待测试接口的接口信息进行封装，包括：

确定预定服务协议模块对应的请求模板；

将待测试接口的接口信息写入请求模板中，并将写入接口信息后的请求模板封装为相应版本的数据包。

在一种可能的实现方式中，在确定预定服务协议模块对应的请求模板之前，还包括：

将预定服务协议模块的请求协议的各部分协议内容，分别封装为对应的各个协议类；

定义各个协议类之间的关联关系，并根据关联关系生成请求模板。

在一种可能的实现方式中，当待测试接口的请求协议为HTTP请求协议时，预定服务协议模块为基于HTTP请求协议的服务协议模块；

当待测试接口的请求协议为Dubbo请求协议时，预定服务协议模块为基于Dubbo请求协议的服务协议模块；

当待测试接口的请求协议为Thrift请求协议时，预定服务协议模块为基于Thrift请求协议的服务协议模块；

当待测试接口的请求协议为Motan请求协议时，预定服务协议模块为基于Motan请求协议的服务协议模块；

当待测试接口的请求协议为Grpc请求协议时，预定服务协议模块为基于Grpc请求协议的服务协议模块。

根据本公开的一个或多个实施例，提供了一种接口测试装置，包括：

获取模块，用于获取测试用例，测试用例是基于待测试接口的应用程序接口API生成的；待测试接口的API是根据待测试接口的接口信息，通过预定服务协议模块封装成的，预定服务协议模块是待测试接口的请求协议对应的封装模块；

测试模块，用于运行测试用例，通过调用待测试接口的API对待测试接口进行测试。

在一种可能的实现方式中，获取模块在获取测试用例时，用于：

获取配置文件，配置文件用于指示测试环境、测试数据和测试逻辑；测试环境、测试数据和测试逻辑分别独立维护；

根据配置文件，组合生成测试用例，测试用例用于在测试环境下，基于测试逻辑和测试数据，通过调用待测试接口的API的实现测试。

在一种可能的实现方式中，该装置还包括：处理模块；

处理模块，用于通过预定三层模型的第三层分离式维护测试环境、测试逻辑及测试数据，通过预定三层模型的第二层维护待测试接口的API，以及通过预定三层模型的第一层维护预定服务协议模块。

在一种可能的实现方式中，该装置还包括：封装模块，封装模块用于通过预定服务协议模块，对待测试接口的接口信息进行封装；

封装模块具体用于：

确定预定服务协议模块对应的请求模板；

将待测试接口的接口信息写入请求模板中，并将写入接口信息后的请求模板封装为相应版本的数据包。

在一种可能的实现方式中，该装置还包括生成模块，生成模块用于：

将预定服务协议模块的请求协议的各部分协议内容，分别封装为对应的各个协议类；

定义各个协议类之间的关联关系，并根据关联关系生成请求模板。

在一种可能的实现方式中，当待测试接口的请求协议为HTTP请求协议时，预定服务协议模块为基于HTTP请求协议的服务协议模块；

当待测试接口的请求协议为Dubbo请求协议时，预定服务协议模块为基于Dubbo请求协议的服务协议模块；

当待测试接口的请求协议为Thrift请求协议时，预定服务协议模块为基于Thrift请求协议的服务协议模块；

当待测试接口的请求协议为Motan请求协议时，预定服务协议模块为基于Motan请求协议的服务协议模块；

当待测试接口的请求协议为Grpc请求协议时，预定服务协议模块为基于Grpc请求协议的服务协议模块。

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

此外，虽然采用特定次序描绘了各操作，但是这不应当理解为要求这些操作以所示出的特定次序或以顺序次序执行来执行。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

Claims (10)

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

获取测试用例，所述测试用例是基于待测试接口的应用程序接口API生成的；所述待测试接口的API是根据所述待测试接口的接口信息，通过预定服务协议模块封装成的，所述预定服务协议模块是所述待测试接口的请求协议对应的封装模块；

运行所述测试用例，通过调用所述待测试接口的API对所述待测试接口进行测试。

2.根据权利要求1所述的方法，其特征在于，所述获取测试用例，包括：

获取配置文件，所述配置文件用于指示测试环境、测试数据和测试逻辑；所述测试环境、所述测试数据和所述测试逻辑分别独立维护；

根据所述配置文件，组合生成所述测试用例，所述测试用例用于在所述测试环境下，基于所述测试逻辑和所述测试数据，通过调用所述待测试接口的API实现测试。

3.根据权利要求2所述的方法，其特征在于，通过预定三层模型的第三层分离式维护所述测试环境、所述测试逻辑及所述测试数据，通过所述预定三层模型的第二层维护所述待测试接口的API，以及通过所述预定三层模型的第一层维护所述预定服务协议模块。

4.根据权利要求1所述的方法，其特征在于，通过所述预定服务协议模块，对所述待测试接口的接口信息进行封装，包括：

确定所述预定服务协议模块对应的请求模板；

将所述待测试接口的接口信息写入所述请求模板中，并将写入接口信息后的请求模板封装为相应版本的数据包。

5.根据权利要求4所述的方法，其特征在于，在确定所述预定服务协议模块对应的请求模板之前，还包括：

将所述预定服务协议模块的请求协议的各部分协议内容，分别封装为对应的各个协议类；

定义各个协议类之间的关联关系，并根据所述关联关系生成所述请求模板。

6.根据权利要求1-5任一项所述的方法，其特征在于，当所述待测试接口的请求协议为HTTP请求协议时，所述预定服务协议模块为基于HTTP请求协议的服务协议模块；

当所述待测试接口的请求协议为Dubbo请求协议时，所述预定服务协议模块为基于Dubbo请求协议的服务协议模块；

当所述待测试接口的请求协议为Thrift请求协议时，所述预定服务协议模块为基于Thrift请求协议的服务协议模块；

当所述待测试接口的请求协议为Motan请求协议时，所述预定服务协议模块为基于Motan请求协议的服务协议模块；

当所述待测试接口的请求协议为Grpc请求协议时，所述预定服务协议模块为基于Grpc请求协议的服务协议模块。

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

获取模块，用于获取测试用例，所述测试用例是基于待测试接口的应用程序接口API生成的；所述待测试接口的API是根据所述待测试接口的接口信息，通过预定服务协议模块封装成的，所述预定服务协议模块是所述待测试接口的请求协议对应的封装模块；

测试模块，用于运行所述测试用例，通过调用所述待测试接口的API对所述待测试接口进行测试。

8.根据权利要求7所述的装置，其特征在于，获取模块在获取测试用例时，用于：

获取配置文件，所述配置文件用于指示测试环境、测试数据和测试逻辑；所述测试环境、所述测试数据和所述测试逻辑分别独立维护；

根据所述配置文件，组合生成所述测试用例，所述测试用例用于在所述测试环境下，基于所述测试逻辑和所述测试数据，通过调用所述待测试接口的API实现测试。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1-6任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现权利要求1-6任一项所述的方法。

Images