CN116974882A - 接口测试方法及相关装置 - Google Patents

Abstract

本申请的实施例提供了一种接口测试方法及相关装置，该方法包括：获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息；接收在所述可视化交互界面上输入的用于测试所述目标线上服务接口的参数信息；当接收到通过所述可视化交互界面提交的对所述目标线上服务接口的测试指令时，根据所述参数信息调用与所述接口选择信息对应的所述目标线上服务接口，以对所述目标线上服务接口进行测试；在所述可视化交互界面上显示对所述目标线上服务接口的测试结果。本申请实施例的方案无需编写脚本，降低了接口测试的门槛和测试成本，提高了接口测试的便捷性和效率。本申请实施例可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景。

Description

接口测试方法及相关装置

技术领域

本申请涉及软件测试技术领域，具体而言，涉及一种接口测试方法及相关装置。

背景技术

目前，开发者可以在本地开发环境中使用一些工具来进行对本地接口测试操作。

对于线上服务器的***提供的接口，现有的测试方案主要采用的方式是先利用人工编写脚本，然后将脚本上传至服务器来执行测试。这种方式的主要缺陷是：由于测试时需要以人工方式编写脚本，还要将脚本上传，因而操作十分繁琐，效率十分低下；同时，由于每次测试时需要具备专业知识的人员编写测试脚本，人力成本高。

发明内容

本申请的实施例提供了一种接口测试方法及相关装置，进而至少在一定程度上可以无需编写脚本即可实现接口测试，并提高接口测试的效率。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供了一种接口测试方法，所述方法包括：获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息；接收在所述可视化交互界面上输入的用于测试所述目标线上服务接口的参数信息；当接收到通过所述可视化交互界面提交的对所述目标线上服务接口的测试指令时，根据所述参数信息调用与所述接口选择信息对应的所述目标线上服务接口，以对所述目标线上服务接口进行测试；在所述可视化交互界面上显示对所述目标线上服务接口的测试结果。

根据本申请实施例的一个方面，提供了一种接口测试装置，所述装置包括：获取单元，用于获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息；接收单元，用于接收在所述可视化交互界面上输入的用于测试所述目标线上服务接口的参数信息；测试单元，用于当接收到通过所述可视化交互界面提交的对所述目标线上服务接口的测试指令时，根据所述参数信息调用与所述接口选择信息对应的所述目标线上服务接口，以对所述目标线上服务接口进行测试；显示单元，用于在所述可视化交互界面上显示对所述目标线上服务接口的测试结果。

在本申请的一些实施例中，基于前述方案，所述参数信息包括接口请求参数和服务器选择信息，所述服务器选择信息用于指示对提供所述目标线上服务接口的指定服务器进行测试。

在本申请的一些实施例中，基于前述方案，所述测试单元配置为：根据所述参数信息生成与所述指定服务器对应的测试任务，并将与所述指定服务器对应的所述测试任务加入消息队列中；从所述消息队列中获取所述测试任务，并执行所述测试任务，以对所述指定服务器进行测试。

在本申请的一些实施例中，基于前述方案，所述指定服务器为多个，所述测试单元配置为：依次从消息队列中获取与各个指定服务器对应的测试任务；在每次获取到测试任务之后，根据所述测试任务的内容封装得到接口调用请求，并向相应的指定服务器发送所述接口调用请求，以对提供所述目标线上服务接口的多个指定服务器进行测试。

在本申请的一些实施例中，基于前述方案，所述获取单元还用于：获取与各个线上服务接口对应的接口协议定义文件，所述接口协议定义文件是根据相应线上服务接口的业务代码生成的，所述接口协议定义文件包括接口信息；在获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息之后，对与所述目标线上服务接口对应的所述接口协议定义文件进行解析，得到接口信息；所述显示单元还用于：通过所述可视化交互界面显示所述接口信息。

在本申请的一些实施例中，基于前述方案，所述参数信息还包括脚本配置参数，所述获取单元还用于：对各线上服务接口对应的接口协议定义文件进行解析，得到各接口协议定义文件中的接口信息；根据脚本规范和各接口协议定义文件中的接口信息，生成与各线上服务接口对应的原始性能测试脚本，所述原始性能测试脚本包括至少一个预留配置项；所述测试单元配置为：从所述消息队列中获取所述测试任务；根据所述测试任务的内容确定对应的原始性能测试脚本，并将所述脚本配置参数填入所述原始性能测试脚本中的预留配置项，得到完整性能测试脚本；通过执行所述完整性能测试脚本，对所述指定服务器进行性能测试。

在本申请的一些实施例中，基于前述方案，所述测试单元配置为：确定处于空闲状态的目标执行机；向所述目标执行机发送所述完整性能测试脚本，以通过在所述目标执行机上执行所述完整性能测试脚本，对所述指定服务器进行性能测试。

在本申请的一些实施例中，基于前述方案，所述指定服务器为多个，所述测试单元配置为：在所述目标执行机上执行所述完整性能测试脚本，以触发向负载均衡服务器发送测试请求，所述测试请求用于对所述负载均衡服务器根据负载均衡策略选定的指定服务器进行性能测试。

在本申请的一些实施例中，基于前述方案，所述显示单元配置为：定期对所述目标执行机进行轮询，以确定所述完整性能测试脚本是否执行完毕；若所述完整性能测试脚本执行完毕，则从所述目标执行机获取测试结果；通过所述可视化交互界面输出所述测试结果。

根据本申请实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的接口测试方法。

根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的接口测试方法。

根据本申请实施例的一个方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中，计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令，所述处理器执行所述计算机指令，使得所述计算机设备执行如上述实施例中所述的接口测试方法。

在本申请的一些实施例所提供的技术方案中，整个接口测试方案是通过测试方与可视化交互界面的交互操作来驱动的，具体地，测试方通过可视化交互界面，可以配置接口选择信息，也可以输入用于测试目标线上服务接口的参数信息，还可以提交相应的测试指令，在接收到测试指令指挥，可以自动根据参数信息调用与目标线上服务接口，从而实现对目标线上服务接口的测试，最后，通过可视化交互界面可以输出和显示相应的测试结果。因此，本申请实施例的方案使得测试方只需要与可视化交互界面进行几个交互操作即可实现对接口的测试，实现了接口测试的可视化，整个流程无需编写测试脚本，测试过程方便快捷，大大降低了接口测试的门槛，显著提高了接口测试的效率，还降低了测试成本。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了本申请实施例的技术方案的整体架构示意图；

图2示出了根据本申请的一个实施例的接口测试方法的流程图；

图3示出了本申请实施例的技术方案的架构框图；

图4示出了根据本申请的一个实施例的用于进行接口调试的可视化交互界面的示意图；

图5示出了根据本申请的一个实施例的用于进行性能测试的可视化交互界面的示意图；

图6示出了根据本申请的一个实施例的通过可视化交互界面显示接口信息的流程图；

图7示出了根据本申请的一个实施例的图2中步骤230的细节的流程图；

图8示出了根据本申请的一个实施例的在可视化交互界面上显示对目标线上服务接口的测试结果的流程图；

图9示出了根据本申请的一个实施例的以图表形式显示性能测试结果的可视化交互界面的示意图；

图10示出了根据本申请的一个实施例的在启动调试之前以及启动单实例调试后的交互流程图；

图11示出了根据本申请的一个实施例的在启动服务全量调试之后以及请求查看全量调试结果之后的交互流程图；

图12示出了根据本申请的一个实施例的在启动性能测试之前以及启动性能测试后的交互流程图；

图13示出了根据本申请的一个实施例的异步执行性能测试以及异步轮询测试结果的交互流程图；

图14示出了根据本申请的一个实施例的查询性能测试结果的交互流程图；

图15示出了根据本申请的一个实施例的接口测试装置的框图；

图16示出了适于用来实现本申请实施例的电子设备的计算机***的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

接口测试可以包括接口调试及对提供接口的服务器的性能测试。

目前针对本地接口进行接口调试及性能测试时，开发者在本地开发环境可以使用一些可视化工具方便快捷的操作，例如postman接口调试工具可以进行接口调试，也可以通过JMeter性能测试工具来进行性能测试。

但对于部署到线上环境的服务，由于线上服务器的***通常没有UI界面，无法安装及使用可视化的工具。在相关技术中，开发人员在对线上接口进行接口调试及性能测试的时候往往需要采用编写脚本的方式并将脚本上传到服务器上的方式来执行测试操作。

目前采用的线上接口调试方式可以满足基本的接口调试需求，但是对于开发者来说，需要编写复杂接口调试脚本并运行到服务器上，而复杂的脚本通常是用完即止，如果没有妥善保存的话，下一次调试又需要重新编写造成重复工作。同时，对于线上大规模服务，例如上百台服务器的服务，假如需要对该服务的所有服务器进行接口调试验证可用性，则需要修改上百次脚本，给开发者带来极大的压力。

目前采用的线上性能测试方式，是采用线上编写脚本并上传到服务器上执行的方式来执行，该方式可以满足基本的性能测试需要。但对于开发者来说，需要掌握专业的性能测试知识，才能够编写性能测试脚本，而且脚本通过上传到服务器来执行的方式比较繁琐。对于性能测试结果，在服务器上只能通过简单的数字结果来查看，无法实现丰富的图表展示。

为此，本申请提供了一种接口测试方法，基于本申请实施例提供的接口测试方法可以克服上述缺陷，实现了对接口调试及对提供接口的服务器的性能测试的可视化操作，可自动生成测试脚本，无需编写测试脚本，测试人员无需掌握专业的测试知识即可进行测试，可以快速地对提供接口的大规模服务器进行批量测试，提高了接口测试的效率，还降低了测试成本。

图1示出了可以应用本申请实施例的技术方案的示例性***架构的示意图。如图1所示，该***架构100可以包括：用户终端110、***服务器120以及服务器集群130，服务器集群130具体包括第一服务器131、第二服务器132以及第三服务器133。服务器集群130中的各个服务器向外提供了接口，其他终端或服务器可以通过访问服务器集群130中的各个服务器来调用该接口。用户终端110与***服务器120之间以及服务器集群130中的各个服务器与***服务器120之间均建立了通信连接。***服务器120上部署有接口调试及性能测试自动化平台，用户终端110上部署有能够与接口调试及性能测试自动化平台通信的客户端。当本申请提供的接口测试方法应用于图1所示的***架构中时，一个过程可以是这样的：首先，用户通过用户终端110的客户端访问***服务器120上的接口调试及性能测试自动化平台，从而打开接口调试及性能测试自动化平台返回的接口调试界面，该接口调试界面包含了一个用于发起接口调试的按钮；接着，用户在接口调试界面中可配置各种信息，具体地，用户需要选择需要调试的接口，并通过接口调试界面输入用于调试该接口的接口请求参数，然后选择需要进行接口调试的指定服务器；接下来，当用户通过用户终端110点击了该接口调试界面中用于发起接口调试的按钮后，用户终端110会将用户通过接口调试界面配置的各种信息发送至***服务器120上的接口调试及性能测试自动化平台，由接口调试及性能测试自动化平台向服务器集群130中的指定服务器发起接口调试；然后，接口调试及性能测试自动化平台会接收到接口响应信息，并生成相应的调试结果；最后，***服务器120会将调试结果返回给用户终端110，从而在接口调试界面中展示调试结果。

在本申请的一些实施例中，调试结果是在接口调试界面中以图表的方式进行展示的。

在本申请的一些实施例中，用户通过用户终端110的客户端访问***服务器120上的接口调试及性能测试自动化平台，还可以打开由接口调试及性能测试自动化平台提供的性能测试页面，用户可以在性能测试页面中选择需要调试的接口，输入用于测试该接口的接口请求参数和脚本配置参数，然后选择需要进行性能测试的指定服务器；***服务器120上的接口调试及性能测试自动化平台在接收到这些信息后，会自动生成相应的性能测试脚本，并通过执行性能测试脚本来对指定服务器进行性能测试。

应该理解，图1中的用户终端、***服务器以及服务器集群中服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的用户终端、***服务器，服务器集群中服务器的数目也可以是任意的。比如***服务器可以是多个服务器组成的服务器集群，服务器集群中服务器的数量可以低于三个或超过三个。

需要说明的是，图1示出的仅为本申请的一个实施例。虽然在图1实施例的方案中，实施终端以及用于提供接口的终端设备均为服务器，但在本申请的其他实施例中，实施终端以及用于提供接口的终端设备可以是台式机、笔记本电脑、iPAD、智能手机、车载终端等各种各样的终端设备；虽然在图1实施例的方案是通过在接口调试及性能测试自动化平台上执行性能测试脚本来进行性能测试的，但在本申请的其他实施例中，接口调试及性能测试自动化平台还可以将生成的性能测试脚本发送至执行机，由执行机执行性能测试脚本，从而对指定服务器进行性能测试；虽然在图1实施例的方案中，服务器集群130中的各个服务器向外提供了相同的接口，但在本申请的其他实施例中，服务器集群130中的各个服务器还可以向外提供不同的接口，且一些服务器可以同时向外提供多个接口。本申请实施例对此不作任何限定，本申请的保护范围也不应因此而受到任何限制。

易于理解，本申请实施例所提供的接口测试方法一般由服务器执行，相应地，接口测试装置一般设置于服务器中。但是，在本申请的其它实施例中，终端设备也可以与服务器具有相似的功能，从而执行本申请实施例所提供的接口测试方案。

因此，本申请实施例方案可以应用于终端或服务器中。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图2示出了根据本申请的一个实施例的接口测试方法的流程图，该接口测试方法可以具体用于对接口调试或者对提供接口的服务器的性能测试。该接口测试方法可以由各种能够计算和处理的设备来执行，比如可以是用户终端或云服务器，用户终端包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、可穿戴设备等。本申请实施例可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。请参照图2所示，该接口测试方法至少包括以下步骤：

在步骤210中，获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息。

测试方可以是各种能够进行接口测试的用户，例如可以是接口的测试人员或者开发人员。接口可以为API接口，API(Application Programming Interface，应用程序编程接口)是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。

可视化交互界面可以是利用HTML(HyperText Markup Language，超文本标记语言)、CSS(Cascading Style Sheets，层叠样式表)、JavaScript等技术等设计的Web页面。可视化交互界面显示在测试方使用的浏览器等能够访问Web页面的客户端上。

接口选择信息可以是接口的名称、标识、接口描述等接口的基本信息，测试方通过配置接口选择信息来指示测试方想要测试的接口是哪一个。

在本申请的一个实施例中，获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息，包括：获取测试方通过可视化交互界面的指定服务入口配置的与由指定服务提供的目标线上服务接口对应的接口选择信息。

下面将结合图3来详细介绍本申请实施例的方案。图3示出了本申请实施例的技术方案的架构框图。请参见图3所示，整个架构框图分为接入层、逻辑层以及数据层，其中，逻辑层为核心部分，逻辑层包括接口调试及性能测试自动化平台、执行机集群、Nginx集群以及业务服务集群，其中，接口调试及性能测试自动化平台可以作为本申请实施例方案的执行主体。用户终端可以通过接入层中的Nginx服务来访问接口调试及性能测试自动化平台，从而可以获得接口调试及性能测试自动化平台返回的平台可视化页面，该平台可视化页面即为步骤210中的可视化交互界面，用户可以与平台可视化页面进行交互，配置各种与接口调试或者性能测试有关的信息，从而发起接口调试或者性能测试。业务服务集群中包含多个服务实例，每个服务实例可以部署在一个服务器上，每个服务实例可以提供一个或多个接口，各个服务实例可以向外提供相同的接口，也可以向外提供不同的接口。其他终端设备可以通过网关正常访问业务服务集群，从而调用业务服务集群中服务实例提供的接口。接口调试及性能测试自动化平台中包括接口调试模块和性能测试模块，通过接口调试模块可以进行接口调试操作，通过性能测试模块可以对提供接口的服务器进行性能测试操作。

在接口调试页面中，用户可以选择需要进行接口调试的线上服务接口。图4示出了根据本申请的一个实施例的用于进行接口调试的可视化交互界面的示意图。请参见图4所示，显示了用户点开了服务列表中的会控服务，进入了会控服务入口，当用户点击“接口调试”控件，进入接口调试子界面，其中会显示若干会议接口的基本信息，这些会议接口的基本信息即为接口选择信息。会议接口的基本信息可以包括接口请求http方法、接口路径以及接口名称。比如，图4示出第一个会议接口的基本信息中的接口请求http方法为POST，接口路径为“/metting/create”、接口名称为“创建会议”；图4示出第二个会议接口的基本信息中的接口请求http方法为POST，接口路径为“/metting/query”、接口名称为“查询会议”。当用户点击某一会议接口的基本信息，会展开对相应会议接口的调试入口，当用户在调试入口中配置相应的参数信息并提交测试指令后，会自动实现对相应的接口选择信息的配置。

因此，测试方可以通过一个可视化交互界面配置与多个线上服务接口对应的接口选择信息。创建会议接口和查询会议接口均属于会控服务，所以会议接口和查询会议接口可以同时由图3实施例中的一个服务实例提供；图3实施例中的所有服务实例可以均为能够创建会议接口和查询会议接口的会控服务。图5示出了根据本申请的一个实施例的用于进行性能测试的可视化交互界面的示意图。请参见图5所示，当用户在会控服务入口中点击“性能测试”控件，会进入性能测试子界面，在性能测试子界面中可以发起对接口的性能测试操作。性能测试子界面中同样会显示若干会议接口的基本信息，当用户点击某一会议接口的基本信息，会展开对相应会议接口的性能测试入口。图5所示的即为用户打开了查询会议接口的性能测试入口。当用户在查询会议接口的性能测试入口中配置相应的参数信息并提交测试指令后，会自动对查询会议接口的接口选择信息的配置。

图6示出了根据本申请的一个实施例的通过可视化交互界面显示接口信息的流程图。请参见图6所示，该接口测试方法还可以包括以下步骤：

在步骤610中，获取与各个线上服务接口对应的接口协议定义文件，接口协议定义文件是根据相应线上服务接口的业务代码生成的，接口协议定义文件包括接口信息。

在本申请的一个实施例中，与各个线上服务接口对应的接口协议定义文件是在构建业务代码时由工具依赖库根据在业务代码中添加的注解生成的，工具依赖库被引入至业务代码中。

具体地，可以在提供每个线上服务接口的业务代码，可以在业务代码中引入Swagger这一工具依赖库，并在业务代码的接口代码中添加接口名、接口描述、接口请求http方法，接口请求地址、接口请求参数定义，接口响应参数定义等信息的注解。注解添加完毕后，对业务代码进行构建的时候，Swagger会自动生成接口协议定义文件，该接口协议定义文件中包含了所有接口的信息。

Swagger是一个规范和完整的框架，消除了API文档中的手动工作，提供了一系列用于生成、可视化和维护API文档的解决方案。

在本申请的一个实施例中，该接口测试方法还包括：对与各个线上服务接口对应的接口协议定义文件进行解析，得到各接口协议定义文件的接口信息中包含的接口选择信息；将接口协议定义文件存储至磁盘中；将接口选择信息和接口协议定义文件在磁盘中存储的地址对应存储至数据库的相应接口记录中。

接口选择信息可以是接口基本信息，接口信息可以是包括接口选择信息在内的接口详细信息。具体地，接口信息可以包括生成接口名、接口描述、接口请求http方法，接口请求地址等各种信息。

请参见图3所示，数据层包括数据库和磁盘，数据库用于存储接口选择信息和接口协议定义文件在磁盘中存储的地址，磁盘用于存储接口协议定义文件。

数据库和磁盘可以位于接口调试及性能测试自动化平台所在的终端设备或者接口调试及性能测试自动化平台能够访问的终端设备上。

本申请实施例通过将接口选择信息存储在数据库中，使得用户在通过可视化交互界面配置接口选择信息时能够保证配置的效率。

在步骤620中，在获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息之后，对与目标线上服务接口对应的接口协议定义文件进行解析，得到接口信息。

由于接口选择信息和接口协议定义文件在磁盘中存储的地址是在数据库中对应存储的，因而，在获取到测试方配置的接口选择信息之后，可以得到相应的接口协议定义文件在磁盘中存储的地址，进而根据接口协议定义文件在磁盘中存储的地址进行寻址，获取到与目标线上服务接口对应的接口协议定义文件，进而对该接口协议定义文件进行解析。

可以根据Swagger协议文件规范对接口协议定义文件进行解析，通过对接口协议定义文件进行解析，可以得到该文件中包含的完整的接口信息。对接口协议定义文件进行解析可以通过图3示出的接口调试及性能测试自动化平台中Swagger接口协议解析模块来实现。

在步骤630中，通过可视化交互界面显示接口信息。

当用户选择了需要测试的接口，可以进一步通过可视化交互界面显示详细的接口信息，从而可以指导用户如何输入参数信息。

请继续参见图2，在步骤220中，接收在可视化交互界面上输入的用于测试目标线上服务接口的参数信息。

在本申请的一个实施例中，参数信息包括接口请求参数和服务器选择信息，服务器选择信息用于指示对提供目标线上服务接口的指定服务器进行测试。

指定服务器可以是提供目标线上服务接口的一个或多个服务器，还可以是提供目标线上服务接口的全部服务器。

用户可以通过可视化交互界面提供的表单输入参数信息。

接口请求参数是需要传入目标线上服务接口的参数，其用来生成请求报文。比如，在图4和图5实施例中，接口请求参数为与“meettingID”这一参数名对应的“12345678”。可以看到，可视化交互界面中还显示有与请求参数对应的参数说明，参数说明包括参数名和描述，参数说明可以属于图6实施例中通过对接口协议定义文件进行解析而得到的接口信息。服务器选择信息可以是用户通过在下拉菜单中选择的方式来输入的，比如，在图4和图5实施例中，服务器对应的下拉菜单中的选择结果均为ALL，这代表用户指示对提供会议接口的全量服务器进行测试。当然，在本申请的其他实施例中，还可以在下拉菜单中选择其他服务器，比如可以选择某一个指定服务器或者服务器群组，从而实现对指定服务器或服务器群组的测试。

在步骤230中，当接收到通过可视化交互界面提交的对目标线上服务接口的测试指令时，根据参数信息调用与接口选择信息对应的目标线上服务接口，以对目标线上服务接口进行测试。

测试指令、参数信息以及接口选择信息可以是一同接收到的。

在图4和图5实施例中示出的可视化交互界面中均示出了请求按钮，用户点击该请求按钮可以提交对相应的会议接口的测试指令。可以通过将接口请求参数封装为http请求报文，并将http请求报文发送至提供目标线上服务接口的指定服务器的方式来调用目标线上服务接口。

图7示出了根据本申请的一个实施例的图2中步骤230的细节的流程图。请参见图7所示，步骤230具体可以包括以下步骤：

在步骤231中，根据参数信息生成与指定服务器对应的测试任务，并将与指定服务器对应的测试任务加入消息队列中。

具体地，可以将测试任务加入Kafka消息队列中。

Kafka是使用Scala和Java语言编写的开源流处理平台。它是一个分布式发布订阅消息***，能为实时数据提供一个统一、高通量、低等待的消息传递平台。图3所示的数据层还包括Kafka队列，用于存储测试任务。

在步骤232中，从消息队列中获取测试任务，并执行测试任务，以对指定服务器进行测试。

在本申请的一个实施例中，指定服务器为多个，从消息队列中获取测试任务，并执行测试任务，以对指定服务器进行测试，包括：依次从消息队列中获取与各个指定服务器对应的测试任务；在每次获取到测试任务之后，根据测试任务的内容封装得到接口调用请求，并向相应的指定服务器发送接口调用请求，以对提供目标线上服务接口的多个指定服务器进行测试。

每当获取到并执行完一个测试任务，就实现了对提供目标线上服务接口的一个与该测试任务对应的指定服务器的测试；当执行完消息队列中的所有测试任务，便完成了对所有指定服务器的测试。可以以异步方式来执行消息队列中的所有测试任务，在开始执行消息队列中排在前面的测试任务之后，即使该测试任务尚未执行完毕，也可以执行排在后面的测试任务。

在本申请的一个实施例中，参数信息还包括脚本配置参数，该接口测试方法还包括：对各线上服务接口对应的接口协议定义文件进行解析，得到各接口协议定义文件中的接口信息；根据脚本规范和各接口协议定义文件中的接口信息，生成与各线上服务接口对应的原始性能测试脚本，原始性能测试脚本包括至少一个预留配置项；

从消息队列中获取测试任务，并执行测试任务，以对指定服务器进行测试，包括：从消息队列中获取测试任务；根据测试任务的内容确定对应的原始性能测试脚本，并将脚本配置参数填入原始性能测试脚本中的预留配置项，得到完整性能测试脚本；通过执行完整性能测试脚本，对指定服务器进行性能测试。

在完成对接口协议定义文件的解析之后，接口调试及性能测试自动化平台还会根据Jmeter的脚本规范，利用各接口协议定义文件中的接口信息生成相应的原始性能测试脚本，原始性能测试脚本的内容中除了包含接口信息，还会包含通过占位符的方式预留特定的配置项，例如，配置项可以是请求线程数、测试时长等。可以将原始性能测试脚本保存在磁盘中，并在数据库的相应记录中保存原始性能测试脚本在磁盘中的存储地址，以供后续检索。原始性能测试脚本的生成可以通过图3示出的接口调试及性能测试自动化平台中Jmeter运行脚本生成模块来实现。

由于测试任务是与线上服务接口对应的，而原始性能测试脚本也是与线上服务接口对应的，因此，测试任务与原始性能测试脚本之间也存在对应关系。请参见图5所示，用户在请求对查询会议接口进行性能测试时，还在可视化交互界面中输入了线程数和测试时长这两个脚本配置参数；在接口调试及性能测试自动化平台执行测试任务时，会将这两个脚本配置参数填入原始性能测试脚本中的占位符这一配置项中，从而生成完整性能测试脚本。

在本申请的一个实施例中，通过执行完整性能测试脚本，对指定服务器进行性能测试，包括：确定处于空闲状态的目标执行机；向目标执行机发送完整性能测试脚本，以通过在目标执行机上执行完整性能测试脚本，对指定服务器进行性能测试。

目标执行机可以是执行机集群中处于空闲状态的一个执行机，执行机集群可以包括多个执行机，每个执行机可以是一个服务器。请参见图3所示，接口调试及性能测试自动化平台中包括性能测试执行机管理模块，其能够与执行机集群中的执行机进行交互，在执行机集群中，有的执行机处于空闲状态，有的执行机处于繁忙状态。处于空闲状态的目标执行机可以通过执行完整性能测试脚本来测试单个服务实例。

由于性能测试需要执行的时间较长，因此会占用较多的资源。本申请实施例通过利用目标执行机来执行完整性能测试脚本，可以使得脚本执行功能可以与接口调试及性能测试自动化平台，提高了平台的可维护性，避免了平台过于冗余；同时，通过设置执行机集群，使得即使一部分执行机繁忙时，也能够即时进行性能测试，保证了性能测试的效率。

在本申请的一个实施例中，确定处于空闲状态的目标执行机，包括：获取执行机集群中各执行机的CPU使用率和内存使用率；根据各执行机的CPU使用率和内存使用率在执行机集群中确定出处于空闲状态的目标执行机。

在本申请的一个实施例中，根据各执行机的CPU使用率和内存使用率在执行机集群中确定出处于空闲状态的目标执行机，包括：确定CPU使用率低于预设CPU使用率阈值且内存使用率低于预设内存使用率的执行机，作为目标执行机。

在本申请的一个实施例中，根据各执行机的CPU使用率和内存使用率在执行机集群中确定出处于空闲状态的目标执行机，包括：针对每一执行机，确定该执行机的CPU使用率和内存使用率的加权和；确定加权和低于预设加权和阈值的执行机，作为目标执行机。

CPU使用率和内存使用率的权重可以根据专家经验设置。

在本申请的一个实施例中，确定处于空闲状态的目标执行机，包括：向执行机集群中各执行机发送空闲状态获取请求；获取各执行机根据空闲状态获取请求返回的空闲状态信号；根据空闲状态信号确定处于空闲状态的目标执行机。

具体地，各执行机可以根据自身的CPU使用率和内存使用率确定自身是否空闲，并生成相应的空闲状态信号。

在本申请实施例中，只需要发送空闲状态获取请求就可以确定出处于空闲状态的目标执行机，不需要其他额外计算，可以减少计算开销。

执行机集群中的各执行机上可以部署Jmeter工具，目标执行机在执行完整性能测试脚本时，需要启动Jmeter工具来执行完整性能测试脚本。JMeter是基于Java的压力测试工具，用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java小服务程序、CGI脚本、Java对象、数据库、FTP服务器等等。JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。

在本申请的一个实施例中，指定服务器为多个，通过在目标执行机上执行完整性能测试脚本，对指定服务器进行性能测试，包括：在目标执行机上执行完整性能测试脚本，以触发向负载均衡服务器发送测试请求，测试请求用于对负载均衡服务器根据负载均衡策略选定的指定服务器进行性能测试。

具体地，在向目标执行机发送完整性能测试脚本之前，为负载均衡服务器配置包含各指定服务器的信息的指定服务器信息列表，以得到负载均衡服务器的负载均衡IP地址。根据负载均衡IP地址，可以触发向负载均衡服务器发送测试请求。负载均衡服务器可以采用Nginx服务器。

在本申请的一个实施例中，负载均衡服务器是通过如下方式选择指定服务器的：每隔预定时长确定各指定服务器在该预定时长内的测试请求接收量；选择测试请求接收量最小的指定服务器。

在本申请的一个实施例中，负载均衡服务器是通过如下方式选择指定服务器的：获取各指定服务器在当前时刻的测试请求并发量；选择测试请求并发量小于预设测试请求并发量阈值的指定服务器。

Nginx是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务，可以作为负载均衡服务器使用。

请继续参见图3所示，当需要对全量服务器进行性能测试时，Nginx集群中处于空闲状态的执行机可以作为负载均衡服务器，实现多个服务实例之间的负载均衡，保证了测试效率，避免了对某一个服务实例的测试压力过大。

请继续参见图2，在步骤240中，在可视化交互界面上显示对目标线上服务接口的测试结果。

图4示出了对与多个IP地址对应的调试结果和执行状态，每个IP地址代表一个服务器，比如，IP地址为192.168.1.102的服务器的执行状态为执行失败。图5示出了对服务器的性能测试结果，性能测试结果包括多项指标，分别为速率、总量、成功数、失败数、成功率、平均耗时、最小耗时、最大耗时等，其中，速率的单位为tps(Transaction Per Second，每秒事务处理量)，这代表每秒发送的测试请求的数量，总量为发送的测试请求总数，成功数为成功响应的测试请求数，失败数为未成功响应的测试请求数，成功率为成功响应的测试请求数与发送的测试请求总数的比值，平均耗时为各测试请求的响应耗时的平均值，最小耗时为测试请求的最短响应耗时，最大耗时为测试请求的最长响应耗时。

可以以轮询的方式得到每个测试任务的测试结果，并在可视化交互界面上实时显示轮询得到的测试结果，从而可以使得用户就对每个服务器的执行情况一目了然。

图8示出了根据本申请的一个实施例的在可视化交互界面上显示对目标线上服务接口的测试结果的流程图。请参见图8所示，在可视化交互界面上显示对目标线上服务接口的测试结果具体可以包括以下步骤：

在步骤810中，定期对目标执行机进行轮询，以确定完整性能测试脚本是否执行完毕。

通过对目标执行机可以得到对测试任务的执行状态，即可以得到完整性能测试脚本是否执行完毕。

在步骤820中，若完整性能测试脚本执行完毕，则从目标执行机获取测试结果。

完整性能测试脚本是由目标执行机执行的，因此，目标执行机会得到相应的测试结果。

在步骤830中，通过可视化交互界面输出测试结果。

将测试结果返回给可视化交互界面所在的终端设备，在终端设备显示有可视化交互界面的屏幕上展示测试结果。

具体地，也可以以数据表格的方式展示测试结果，也可以以饼图、柱状图、扇形图、折线图等图表的方式展示测试结果。请参见图5所示，性能测试结果是以数据表格的方式显示在可视化交互界面上的。图9示出了根据本申请的一个实施例的以图表形式显示性能测试结果的可视化交互界面的示意图。请参见图9所示，性能测试结果是以图表的方式显示在可视化交互界面上的，其中，耗时分布是以扇形图的方式展示的，速率变化曲线是以折线图的方式展示的。在图5和图9中，可视化交互界面上还示出了与性能测试结果对应设置的“下载结果”按钮，当用户点击“下载结果”按钮，可以将性能测试结果以图片、文档等方式导出至本地。

下面，将结合图10至图14进一步介绍本申请实施例的方案，图10至图14中的测试平台即前述实施例中的接口调试及性能测试自动化平台。

图10示出了根据本申请的一个实施例的在启动调试之前以及启动单实例调试后的交互流程图。请参见图10所示，在启动调试之前可以包括以下流程：首先，用户在测试平台web点击需要调试的接口，测试平台web向测试平台请求查看接口详情；然后，测试平台通过查询数据库得到接口协议文件在磁盘中存储的地址；接下来，测试平台根据地址从磁盘中检索接口协议文件，并解析接口协议文件；最后，测试平台向测试平台web返回接口详情。

在启动单实例调试后包括以下交互流程：首先，用户在测试平台web启动单实例调试，测试平台web向测试平台发送请求，以请求服务单实例调试；然后，测试平台根据请求参数封装得到http请求，并通过发送http请求，向业务服务集群中指定IP的实例发送接口请求；接着，业务服务集群向测试平台返回接口响应；最后，测试平台向测试平台web返回接口调试结果。

图11示出了根据本申请的一个实施例的在启动服务全量调试之后以及请求查看全量调试结果之后的交互流程图。请参见图11所示，在启动服务全量调试之后可以包括以下交互流程：首先，用户在测试平台web启动服务全量调试，测试平台web向测试平台发送请求，以请求服务全实例调试；然后，测试平台将调试任务放入Kafka队列中，并向测试平台web返回任务id。接下来，异步执行全量调试，包括以下交互流程：测试平台从Kafka获取任务，并根据任务内容封装http请求；然后，测试平台向业务服务集群中的服务实例请求接口，业务服务集群中的服务实例向测试平台返回接口响应；最后，测试平台将结果数据写入数据库。

在请求查看全量调试结果之后包括以下交互流程：首先，用户在测试平台web请求查看全量调试结果，测试平台web向测试平台发送请求，以请求查看调试结果；然后，测试平台根据任务id查看数据库中的结果数据；最后，测试平台向测试平台web返回全量结果。

图12示出了根据本申请的一个实施例的在启动性能测试之前以及启动性能测试后的交互流程图。请参见图12所示，在启动性能测试之前可以包括以下交互流程：首先，用户在测试平台web点击需要调试的接口，测试平台web向测试平台请求查看接口详情；然后，测试平台通过查询数据库得到接口协议文件在磁盘中存储的地址；接下来，测试平台根据地址从磁盘中检索接口协议文件，并解析接口协议文件；最后，测试平台向测试平台web返回接口详情。

在启动性能测试之后，可以包括以下交互流程：首先，用户在测试平台web启动性能测试，测试平台web向测试平台请求性能测试；然后，测试平台将性能测试任务放入Kafka；最后，测试平台向测试平台web返回任务id。

图13示出了根据本申请的一个实施例的异步执行性能测试以及异步轮询测试结果的交互流程图。请参见图13所示，异步执行性能测试时包括以下交互流程：首先，测试平台从Kafka获取任务；然后，测试平台判断是否执行全量性能测试，如果执行全量性能测试，则申请配置nginx，如果执行单实例测试则跳过本步骤；接着，测试平台获取空闲的执行机；接下来，测试平台根据任务内容找到脚本并填充脚本；然后，测试平台将脚本上传到性能测试执行机集群中的执行机，在执行机上执行脚本，执行机可以向测试平台返回脚本接收成功的信息；最后，执行机在执行脚本时会向业务服务集群中的指定ip或负载均衡ip发起测试，并接收业务服务集群返回的测试结果。

异步轮询测试结果时包括以下交互流程：首先，测试平台向性能测试执行机集群异步轮询测试结果，以确定性能测试是否执行完毕；然后，性能测试执行机集群向测试平台返回执行成功；接着，测试平台向性能测试执行机集群拉取执行结果文件，性能测试执行机集群向测试平台返回结果文件；最后，测试平台解析结果文件，并将解析内容放入数据库中。

图14示出了根据本申请的一个实施例的查询性能测试结果的交互流程图。请参见图14所示，查询性能测试结果时包括以下交互流程：首先，用户在测试平台web请求查询测试结果，测试平台web向测试平台发送请求，以请求查询测试结果；然后，测试平台根据任务id从数据库查找结果，并向测试平台web返回测试结果；最后，测试平台web构造图表，以图表的方式展示测试结果。

综上所述，根据本申请实施例提供的接口测试方法，设计了一款自动化的接口调试及性能测试平台，为开发人员提供了一种便捷的线上接口调试及性能测试方式，使得开发人员无需掌握复杂的脚本编写技巧，无需进行繁琐的脚本编写执行，仅仅通过与可视化界面进行交互就能对接口实现专业的测试。对于大规模服务来说，用户可以点选该服务下指定的服务器进行调试，或者一键对所有服务器进行调试。因此本申请实施例的方案大大降低了接口测试的门槛，使得开发人员可以更加专注于业务开发及实际的性能调优，大大提供工作效率。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的接口测试方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的接口测试方法的实施例。

图15示出了根据本申请的一个实施例的接口测试装置的框图。

参照图15所示，根据本申请的一个实施例的接口测试装置1500，包括：获取单元1510、接收单元1520、测试单元1530以及显示单元1540。其中，获取单元1510用于获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息；接收单元1520用于接收在所述可视化交互界面上输入的用于测试所述目标线上服务接口的参数信息；测试单元1530用于当接收到通过所述可视化交互界面提交的对所述目标线上服务接口的测试指令时，根据所述参数信息调用与所述接口选择信息对应的所述目标线上服务接口，以对所述目标线上服务接口进行测试；显示单元1540用于在所述可视化交互界面上显示对所述目标线上服务接口的测试结果。

在本申请的一些实施例中，基于前述方案，所述参数信息包括接口请求参数和服务器选择信息，所述服务器选择信息用于指示对提供所述目标线上服务接口的指定服务器进行测试。

在本申请的一些实施例中，基于前述方案，测试单元1530配置为：根据所述参数信息生成与所述指定服务器对应的测试任务，并将与所述指定服务器对应的所述测试任务加入消息队列中；从所述消息队列中获取所述测试任务，并执行所述测试任务，以对所述指定服务器进行测试。

在本申请的一些实施例中，基于前述方案，所述指定服务器为多个，测试单元1530配置为：依次从消息队列中获取与各个指定服务器对应的测试任务；在每次获取到测试任务之后，根据所述测试任务的内容封装得到接口调用请求，并向相应的指定服务器发送所述接口调用请求，以对提供所述目标线上服务接口的多个指定服务器进行测试。

在本申请的一些实施例中，基于前述方案，获取单元1510还用于：获取与各个线上服务接口对应的接口协议定义文件，所述接口协议定义文件是根据相应线上服务接口的业务代码生成的，所述接口协议定义文件包括接口信息；在获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息之后，对与所述目标线上服务接口对应的所述接口协议定义文件进行解析，得到接口信息；显示单元1540还用于：通过所述可视化交互界面显示所述接口信息。

在本申请的一些实施例中，基于前述方案，所述参数信息还包括脚本配置参数，获取单元1510还用于：对各线上服务接口对应的接口协议定义文件进行解析，得到各接口协议定义文件中的接口信息；根据脚本规范和各接口协议定义文件中的接口信息，生成与各线上服务接口对应的原始性能测试脚本，所述原始性能测试脚本包括至少一个预留配置项；测试单元1530配置为：从所述消息队列中获取所述测试任务；根据所述测试任务的内容确定对应的原始性能测试脚本，并将所述脚本配置参数填入所述原始性能测试脚本中的预留配置项，得到完整性能测试脚本；通过执行所述完整性能测试脚本，对所述指定服务器进行性能测试。

在本申请的一些实施例中，基于前述方案，测试单元1530配置为：确定处于空闲状态的目标执行机；向所述目标执行机发送所述完整性能测试脚本，以通过在所述目标执行机上执行所述完整性能测试脚本，对所述指定服务器进行性能测试。

在本申请的一些实施例中，基于前述方案，所述指定服务器为多个，测试单元1530配置为：在所述目标执行机上执行所述完整性能测试脚本，以触发向负载均衡服务器发送测试请求，所述测试请求用于对所述负载均衡服务器根据负载均衡策略选定的指定服务器进行性能测试。

在本申请的一些实施例中，基于前述方案，显示单元1540配置为：定期对所述目标执行机进行轮询，以确定所述完整性能测试脚本是否执行完毕；若所述完整性能测试脚本执行完毕，则从所述目标执行机获取测试结果；通过所述可视化交互界面输出所述测试结果。

图16示出了适于用来实现本申请实施例的电子设备的计算机***的结构示意图。

需要说明的是，图16示出的电子设备的计算机***1600仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图16所示，计算机***1600包括中央处理单元(Central Processing Unit，CPU)1601，其可以根据存储在只读存储器(Read-Only Memory，ROM)1602中的程序或者从存储部分1608加载到随机访问存储器(Random Access Memory，RAM)1603中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1603中，还存储有***操作所需的各种程序和数据。CPU 1601、ROM 1602以及RAM 1603通过总线1604彼此相连。输入/输出(Input/Output，I/O)接口1605也连接至总线1604。

以下部件连接至I/O接口1605：包括键盘、鼠标等的输入部分1606；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1607；包括硬盘等的存储部分1608；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1609。通信部分1609经由诸如因特网的网络执行通信处理。驱动器1610也根据需要连接至I/O接口1605。可拆卸介质1611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1610上，以便于从其上读出的计算机程序根据需要被安装入存储部分1608。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1609从网络上被下载和安装，和/或从可拆卸介质1611被安装。在该计算机程序被中央处理单元(CPU)1601执行时，执行本申请的***中限定的各种功能。

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

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

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

可以理解的是，在本申请的具体实施方式中，涉及到与接口测试相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (10)

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

获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息；

接收在所述可视化交互界面上输入的用于测试所述目标线上服务接口的参数信息；

当接收到通过所述可视化交互界面提交的对所述目标线上服务接口的测试指令时，根据所述参数信息调用与所述接口选择信息对应的所述目标线上服务接口，以对所述目标线上服务接口进行测试；

在所述可视化交互界面上显示对所述目标线上服务接口的测试结果。

2.根据权利要求1所述的接口测试方法，其特征在于，所述参数信息包括接口请求参数和服务器选择信息，所述服务器选择信息用于指示对提供所述目标线上服务接口的指定服务器进行测试。

3.根据权利要求2所述的接口测试方法，其特征在于，所述根据所述参数信息调用与所述接口选择信息对应的所述目标线上服务接口，以对所述目标线上服务接口进行测试，包括：

根据所述参数信息生成与所述指定服务器对应的测试任务，并将与所述指定服务器对应的所述测试任务加入消息队列中；

从所述消息队列中获取所述测试任务，并执行所述测试任务，以对所述指定服务器进行测试。

4.根据权利要求3所述的接口测试方法，其特征在于，所述指定服务器为多个，所述从所述消息队列中获取所述测试任务，并执行所述测试任务，以对所述指定服务器进行测试，包括：

依次从消息队列中获取与各个指定服务器对应的测试任务；

在每次获取到测试任务之后，根据所述测试任务的内容封装得到接口调用请求，并向相应的指定服务器发送所述接口调用请求，以对提供所述目标线上服务接口的多个指定服务器进行测试。

5.根据权利要求1所述的接口测试方法，其特征在于，所述方法还包括：

获取与各个线上服务接口对应的接口协议定义文件，所述接口协议定义文件是根据相应线上服务接口的业务代码生成的，所述接口协议定义文件包括接口信息；

在获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息之后，对与所述目标线上服务接口对应的所述接口协议定义文件进行解析，得到接口信息；

通过所述可视化交互界面显示所述接口信息。

6.根据权利要求3所述的接口测试方法，其特征在于，所述参数信息还包括脚本配置参数，所述方法还包括：

对各线上服务接口对应的接口协议定义文件进行解析，得到各接口协议定义文件中的接口信息；

根据脚本规范和各接口协议定义文件中的接口信息，生成与各线上服务接口对应的原始性能测试脚本，所述原始性能测试脚本包括至少一个预留配置项；

所述从所述消息队列中获取所述测试任务，并执行所述测试任务，以对所述指定服务器进行测试，包括：

从所述消息队列中获取所述测试任务；

根据所述测试任务的内容确定对应的原始性能测试脚本，并将所述脚本配置参数填入所述原始性能测试脚本中的预留配置项，得到完整性能测试脚本；

通过执行所述完整性能测试脚本，对所述指定服务器进行性能测试。

7.根据权利要求6所述的接口测试方法，其特征在于，所述通过执行所述完整性能测试脚本，对所述指定服务器进行性能测试，包括：

确定处于空闲状态的目标执行机；

向所述目标执行机发送所述完整性能测试脚本，以通过在所述目标执行机上执行所述完整性能测试脚本，对所述指定服务器进行性能测试。

8.根据权利要求7所述的接口测试方法，其特征在于，所述指定服务器为多个，所述通过在所述目标执行机上执行所述完整性能测试脚本，对所述指定服务器进行性能测试，包括：

在所述目标执行机上执行所述完整性能测试脚本，以触发向负载均衡服务器发送测试请求，所述测试请求用于对所述负载均衡服务器根据负载均衡策略选定的指定服务器进行性能测试。

9.根据权利要求7所述的接口测试方法，其特征在于，所述在所述可视化交互界面上显示对所述目标线上服务接口的测试结果，包括：

定期对所述目标执行机进行轮询，以确定所述完整性能测试脚本是否执行完毕；

若所述完整性能测试脚本执行完毕，则从所述目标执行机获取测试结果；

通过所述可视化交互界面输出所述测试结果。

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

获取单元，用于获取测试方通过可视化交互界面配置的与目标线上服务接口对应的接口选择信息；

接收单元，用于接收在所述可视化交互界面上输入的用于测试所述目标线上服务接口的参数信息；

测试单元，用于当接收到通过所述可视化交互界面提交的对所述目标线上服务接口的测试指令时，根据所述参数信息调用与所述接口选择信息对应的所述目标线上服务接口，以对所述目标线上服务接口进行测试；

显示单元，用于在所述可视化交互界面上显示对所述目标线上服务接口的测试结果。