CN107977308A - 接口测试方法及装置 - Google Patents

Abstract

本申请提供一种接口测试方法及装置，所述方法包括：获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序；基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务；基于预设的接口串联测试周期，周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口串联测试。使用本申请实施例提供的方法，可以有效地提高接口管理的效率。

Description

接口测试方法及装置

技术领域

本申请涉及计算机通信领域，尤其涉及接口测试方法及装置。

背景技术

现在常用的客户端开发模式是前后端分离式开发。前端提供HTML(HyperTextMarkup Language，超文本标记语言)页面，后端提供相应程序的接口。当开发人员触发前端交互界面上相应选项时，前端可以调用后端的接口，进行相应的响应。在这种开发模式下，接口就成为前后端连接的重要“纽带”。为了保证接口的稳定性，有效地对接口进行管理就变得极为重要。

发明内容

有鉴于此，本申请提供一种接口测试方法及装置，用以提高接口管理的效率。

具体地，本申请是通过如下技术方案实现的：

第一方面，本申请提供一种接口测试方法，所述方法应用于客户端，所述方法包括：

获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序；

基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务；

基于预设的接口串联测试周期，周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口串联测试。

第二方面，本申请提供一种接口测试装置，所述装置包括：

获取单元，用于获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序；

第一生成单元，用于基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务；

执行单元，用于基于预设的接口串联测试周期，周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口串联测试。

本申请实施例提供一种接口管理方法，客户端可以获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序，并可以基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务。客户端可以基于预设的接口串联测试周期周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口的串联测试。

由于客户端可以基于开发人员录入的若干相关联的后台接口的接口信息和接口测试顺序自动生成对应的接口串联测试任务，并基于预设的串联测试周期，周期性地对该关联接口执行接口串联测试任务，从而实现周期性地自动监测后台接口的状态，有效地保证了后台接口的稳定性，并且大大降低了人力成本，提高了接口管理的效率。

附图说明

图1是本申请一示例性实施例示出的一种接口测试方法的流程图；

图2是本申请一示例性实施例示出的一种接口测试装置所在设备的硬件结构图；

图3是本申请一示例性实施例示出的一种接口测试装置的框图。

具体实施方式

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

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

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

现在常用的工程开发模式是前后端分离式开发。前端提供HTML页面，后端提供相应程序的接口。当开发人员触发前端交互界面上相应选项时，前端可以调用后端的接口，由后端服务器进行相应的响应，并将响应结果返回至前端。在这种开发模式下，接口就成为前后端连接的重要“纽带”。为了保证接口的稳定性，有效地对接口进行管理就变得极为重要。

然而，在实际应用中，很难通过调用一个接口完成开发人员在前端发布的任务，当需要调用多个接口，并且需要按照一定的顺序调用多个接口时，换句话来说，调用一个接口需要发送的参数是调用上一个接口获得的返回字段。在这种情况下，对单个接口进行测试就很难达到接口测试的目的，也很难通过测试模拟出实际的应用场景。此时，就需要对这些相关联的接口进行接口串联测试，判断接口是否处于正常状态，才能保证在实际应用时接口的稳定。

在相关的接口串联测试的技术中，通常情况下，开发人员可以使用jmeter工具，对接口进行测试。在对接口进行测试前，开发人员需要把该相关联的后台接口的接口信息录入jmeter工具中，以对这些相关联的后台接口进行接口测试。

此外，开发人员还需要用word或者在线的Markdown编写接口文档。开发人员还需要基于接口的调用顺序，绘制接口结构图。

然而，一方面，当使用jmeter工具对接口进行串联测试时，开发人员不仅需要手工录入接口信息，还需要人工开启测试流程，因此很难实现周期性地自动进行接口串联测试。

另一方面，对于接口文档的编写和接口结构图的绘制都需要开发人员手工完成，这就大大增加了接口管理的时间成本。

此外，当需要对接口的接口信息进行修改时，开发人员需要对已编写好的文档进行修改，对已画出的接口结构图进行修改等。而在人工编写接口文档、画接口结构图和录入接口信息以及对接口信息进行修改时，难免会出现错误，这就大大增加了接口管理的时间，降低了接口管理的效率。

为了解决相关技术中的问题，本申请提供一种接口管理的工具(即客户端)。该接口管理工具集成了自动执行接口串联测试，结构文档地自动编写，以及自动绘制接口结构图等功能，并且可以执行本申请提出的接口测试方法的逻辑。

客户端可以获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序，并可以基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务。客户端可以基于预设的接口串联测试周期周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口的串联测试。此外，当客户端获取到开发人员录入的上述接口信息和测试顺序后，客户端可以自动生成接口文档和接口结构图。

一方面，由于客户端可以基于开发人员录入的若干相关联的后台接口的接口信息和接口测试顺序自动生成对应的接口串联测试任务，并基于预设的串联测试周期，周期性地对该关联接口执行接口串联测试任务，从而实现周期性地监测后台接口的状态，有效地保证了后台接口的稳定性，并且大大降低了人力成本，提高了接口管理的效率。

另一方面，由于开发人员只需要录入一次接口信息，该客户端就可以自动生成接口文档，接口结构图，并对开发人员选择的相关联的接口进行接口串联测试，从而可以有效地缩短接口管理的时间；

此外，由于当开发人员需要对接口信息进行修改时，开发人员只需要将修改的接口信息录入客户端，该客户端就可以对接口文档，接口结构图和接口串联测试中的相关接口信息进行修改，从而可以有效地降低人力成本，有效地避免接口信息修改错误的出现。

综上所述，使用本申请实施例提供的方法，可以有效地提高接口管理地效率。

综上所述，使用本申请实施例提供的方法可以有效地提高接口管理的效率。

参见图1，图1是本申请一示例性实施例示出的一种接口测试方法的流程图；所述方法应用于客户端，具体包括如下所示步骤：

步骤101：获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序；

步骤102：基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务；

步骤103：基于预设的接口串联测试周期周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口的串联测试。

上述客户端可以包括面向开发人员进行接口管理的客户端软件，上述客户端软件可以是接口管理工具，该接口管理工具可以为开发人员提供一交互界面，开发人员可以通过该交互界面录入相关接口信息、测试顺序等，对接口进行管理。此外，该接口管理工具还具有接口串联测试、自动生成接口文档和接口结构图等功能，开发人员可以通过交互界面，使用上述功能，对接口进行相应地管理。

其中，承载上述客户端的硬件环境，例如，可以是PC主机、移动终端或者服务器等。在本实施例中，不进行特别限定。

在本申请实施例中，上述客户端可以是引用步骤101至步骤103的接口测试逻辑的已有接口管理工具，也可以是基于步骤101至103的接口测试逻辑开发出的新的接口管理工具，在本实施例中，不进行特别限定。

上述相关联的后台接口，在实际应用中，是指彼此之间具有关联关系的后台接口，换句话来说，就是如果调用上一个后台接口获得的返回字段是调用这一个后台接口需要发送的参数，那么这两个后台接口就是相关联的接口。例如，从后台接口A接收到的返回字段是调用后台接口B需要发送的参数，则表明后台接口A和后台接口B是相关联的。

上述接口串联测试，是指对一组相关联的多个后台接口进行测试，以确保后台接口是否处于正常状态。当调用后台接口进行测试后，客户端接收到的调用该后台接口后的返回字段包含开发人员录入的期望返回字段时，则表明该接口处于正常状态，当客户端接收到的该接口返回字段未包含或者未完全包含开发人员录入的接口信息中的返回字段时，则表明该接口处于异常状态。

上述接口串联测试任务，是指用以执行接口串联测试的工具，可以是接口串联测试线程，也可以是用以实现接口串联测试的进程。

在相关技术中，通常情况下，开发人员一般使用jmeter工具对接口进行接口串联测试。然而，使用jmeter工具进行接口串联测试，需要人工开启测试流程，因此很难实现周期性地自动进行接口串联测试，以监控实际生产环境中接口的稳定性。

此外，接口文档的编写以及接口结构图的绘制都需要人工完成，大大提高了人力成本，降低了接口管理的效率。

本发明实施例主要是提供了一种接口管理的工具，该接口管理工具集成了自动执行接口串联测试，结构文档地自动编写，以及自动绘制接口结构图等功能。

开发人员可以通过该接口管理工具的交互界面录入的接口信息的测试顺序，自动生成对应的接口串联测试任务，并且可以周期性自动执行该接口串联测试任务，执行接口串联测试，而不需要人工周期性地开启测试任务，从而有效地提高了接口测试的效率，保证了接口的稳定性。因此，可以有效地提高接口管理的效率。

此外，在开发人员录入接口信息后，该管理工具可以自动编写接口文档，自动绘制接口结构图。当开发人员需要修改接口信息的内容时，接口文档，接口结构图以及接口串联测试的相关内容也会自动做相应地修改，从而大大降低了人力成本，节省了结构管理的时间，有效地提高了接口管理的效率。

在实现时，开发人员可以通过客户端的交互界面，在界面中录入后台接口信息，此时，录入的后台接口信息可以保存在后台的数据库中，在此，不作特别地限定。开发人员可以在该客户端交互界面的“接口列表”中添加已录入的所有相关联的后台接口，并可以设置所添加的相关联的后台接口的测试顺序。

在客户端获取到开发人员录入的相关联的后台接口的接口信息和测试顺序后，可以基于录入的接口信息和测试顺序，自动生成对应的接口串联测试任务(例如接口串联测试线程)。

客户端可以基于预设的接口串联测试周期，周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口串联测试。

其中，上述接口信息包括接口名称、用于区别各个接口；接口的角色类型信息，用于区别在实际应用中，调用该接口的用户角色类型信息，比如该接口的角色类型可以是货主，也可以是司机等；接口功能描述，主要用于对该接口的功能进行描述；接口路径，主要是指客户端调用该接口的路径信息；参数，所述参数包括自定义参数和从已调用接口获取的返回字段；期望返回字段，主要是指，调用接口后，期望从与该接口对应的后台返回的返回字段，可以用作下一个即待调用的接口的参数。

在本实施例中，客户端在获取到开发人员录入的所述接口信息时，可以自动生成对应的接口文档。当开发人员完成录入接口信息后，开发人员可以触发客户端交互界面上的相应选项，客户端交互界面则可以显示出该接口文档。

此外，客户端可以基于开发人员录入的若干相关后台接口的角色类型信息和测试顺序，自动生成接口结构图，以供开发人员的查阅等。在生成接口结构图后，开发人员可以触发客户端交互界面上的相应选项，客户端交互界面则可以显示出该接口结构图。

此外，当需要对某个接口的接口信息进行修改时，开发人员只需要在交互界面进行一次修改，客户端在获取到开发人员的接口修改信息后，可以自动对生成的接口文档、接口结构图以及接口串联测试任务中的参数进行动态修改，从而有效地缩短了接口管理的时间，提高了接口管理的效率。

在本实施例中，客户端可以基于上述若干相关联的后台接口之间的关联关系，对所述串联测试线程中的测试顺序进行验证。在这里，值得说明的是，待验证的测试顺序为开发人员添加的测试顺序，然而由于开发人员的失误等一些原，该测试顺序很难作为接口串联测试时调用接口的执行顺序，所以需要对该测试顺序进行验证，检查接口的测试顺序是否正确。

例如，假设对测试顺序为第一位的接口进行验证，如果客户端发现该接口的参数中包含有返回字段，则客户端可以确定该接口不可以作为第一测试接口，即该接口的测试位置不可以放置于第一位。

其中，具体的验证方法，客户端可以基于开发人员设定的具体业务场景和验证策略进行验证。在这里，只对验证进行示例性说明，不对其进行特别地限定。

当然，对于该测试顺序的验证操作，可以在执行接口串联测试任务前执行，也可以在自动生成接口结构图前执行，在这里，不作特别地时序限定。

在本实施例中，在执行相关联接口的串联测试任务时，基于所述测试顺序，依次为所述若干相关联的后台接口构造用于调用所述返回字段的HTTP模拟请求；将构造出的所述HTTP模拟请求，发送至对应的后台服务器，以完成模拟调用；接收所述后台服务器响应所述HTTP模拟请求后的返回字段，并验证所述返回字段中是否包含预设的期望返回字段；如果是，确定对应的后台接口处于正常状态；如果否，记录所述返回字段中未包含的期望返回字段；如果所述后台服务器未响应所述HTTP模拟请求，确定对应的后台接口测试失败，并记录该HTTP模拟请求中携带的所述预设参数及所述后台服务器返回的调用失败的状态码。

在实现时，当客户端对开发人员录入的接口测试顺序进行的验证通过时，客户端可以基于该测试顺序和上述若干相关联的后台接口的接口信息，对该相关联的后台接口进行接口串联测试。

对于第一待测试的后台接口，客户端可以将开发人员录入的自定义参数等构造成HTTP模拟请求，用以通过该第一待测试的后台接口模拟调用后台服务器返回的返回字段，对第一待测试的接口进行验证。

客户端可以向该后台接口对应的后台服务器发送构造好的HTTP模拟请求。当该第一待测试后台接口对应的后台服务器接收到该HTTP模拟请求后，可以基于该HTTP模拟请求，进行相应的处理操作，然后可以向通过该第一待测试的后台接口向客户端返回若干返回字段。

对于第二待测试的后台接口，客户端可以在接收到模拟调用第一待测试的后台接口后，接收其对应的后台服务器返回的若干返回字段，并判断哪些返回字段是否可以作为参数，在调用第二待测试的后台接口时，发送给与第二待测试的后台接口对应的后台服务器。客户端可以将作为第二待测试接口对应的参数的返回字段以及开发人员预先录入的自定义参数构造成HTTP模拟请求，并可以将该HTTP模拟请求发送至第二待测试的后台接口对应的后台服务器。客户端可以接收该后台服务器返回的若干返回字段。

对于后续的待测试的后台接口，客户端对其进行接口串联测试的方法，与针对第二待测试的后台接口串联测试的方法相同，在这里，不再一一赘述。

以上是针对若干相关联的后台接口的接口测试方法的说明，下面对接口串联测试的结果以及判定后台接口是否处于正常状态进行详细地说明。

在本实施例中，在客户端模拟调用每个接口，向每个接口对应的后台服务器发送HTTP模拟请求时，如果所述后台服务器未响应所述HTTP模拟请求，则客户端可以确定对应的后台接口测试失败，此时客户端可以接收到HTTP模拟请求失败消息。

为了使开发人员更好地找到测试中的问题，更有效地对接口进行管理，客户端可以记录该HTTP模拟请求失败消息中携带的状态码和该HTTP模拟请求携带的预设参数。开发人员可以在交互界面上进行相应的操作，查看客户端记录的请求失败的状态码和该状态码对应的HTTP模拟请求报文携带的预设参数，以更好的排除问题。

例如，如果该HTTP模拟请求失败消息中携带的状态码是404，则表明未找到与该后台接口对应的后台服务器。如果HTTP模拟请求失败消息中携带的状态码是301，则表明HTTP模拟请求被重定向，此时可以认为该接口本身存在问题等。这里只是对请求失败状态码进行示例性说明，并不进行特别地限定。

当客户端向任一接口对应的后台服务器发送的HTTP模拟请求请求成功后，客户端可以接收到该后台服务器返回的若干返回字段。

客户端可以将该返回字段与开发人员预先录入的接口信息中的期望返回字段进行比较。当调用后台接口返回的返回字段包含开发人员预先录入的期望返回字段时，则确定该接口处于正常状态，此时，该客户端的交互界面上，可以出现该后台接口处于正常状态的提示。该提示可以是指示灯，指示文字等，在此不做特定地限定。

当调用后台接口返回的返回字段未包含或者未完全包含与开发人员预先录入的期望返回字段时，客户端则可以确定该接口处于非正常状态。此时，客户端可以记录后台服务器返回的返回字段中未包含的期望返回字段，并可以记录该HTTP响应请求的内容。此时，客户端可以通过交互界面向开发人员展示，模拟调用该后台接口后，缺少的期望返回字段的名称，以及HTTP响应请求的内容，以供开发人员进行错误排查。

例如，假设开发人员期望接口1返回的期望返回字段是A、B和C字段，此时，调用某接口后，从后台服务器返回的的返回字段可能存在几种情况，一种是未包含任何返回字段，即返回字段为空值，则客户端可以记录未包含的期望返回字段为A、B和C字段。另一种是后台服务器返回了返回字段，但返回字段并未包含开发人员录入的期望返回字段，比如，后台服务器返回的返回字段为D和E字段，则此时客户端记录的未包含期望返回字段为A、B和C字段，并可以通过交换界面向开发人员展示该未包含的期望返回字段名称。此外，如果后台服务器返回的返回字段未完全包含开发人员录入的期望返回字段，比如后台服务器返回的返回字段是A、B和D字段，则客户端记录的未包含的期望返回字段为C字段，并可以通过交换界面想开发人员展示该未包含的期望返回字段名称。当然，上述几种情况只是对客户端记录后台服务器返回的未包含的期望返回字段的名称的示例性说明，在本实施例中，不进行特别地限定。

本申请提供一种本发明实施例主要是提供了一种接口管理的工具(即客户端)。该接口管理工具集成了自动执行接口串联测试，接口文档地自动编写，以及自动绘制接口结构图等功能，并且可以执行本申请提出的接口测试方法的逻辑。

客户端可以获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序，并可以基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务。客户端可以基于预设的接口串联测试周期周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口的串联测试。此外，当客户端获取到开发人员录入的上述接口信息和测试顺序后，客户端可以自动生成接口文档和接口结构图。

此外，当客户端获取到开发人员录入的上述接口信息和测试顺序后，客户端可以自动生成接口文档和接口结构图。

一方面，由于客户端可以基于开发人员录入的若干相关联的后台接口的接口信息和接口测试顺序自动生成对应的接口串联测试任务，并基于预设的串联测试周期，周期性地对该关联接口执行接口串联测试任务，从而实现周期性地监测后台接口的状态，有效地保证了后台接口的稳定性，并且大大降低了人力成本，提高了接口管理的效率。

另一方面，由于开发人员只需要录入一次接口信息，该客户端就可以自动生成接口文档，接口结构图，并对开发人员选择的相关联的接口进行接口串联测试，从而可以有效地缩短接口管理的时间；

此外，由于当开发人员需要对接口信息进行修改时，开发人员只需要将修改的接口信息录入客户端，该客户端就可以对接口文档，接口结构图和接口串联测试中的相关接口信息进行修改，从而可以降低人力成本，有效地避免接口信息修改错误的出现。

与此同时，当测试接口处于非正常状态后，该客户端的交互界面上可以为开发人员展示，模拟调用该接口未包含的期望返回字段等相关信息，从而便于开发人员排查错误。

综上所述，使用本申请实施例的方法，可以有效地提高接口管理的效率。

下面以一个货物运输的实际场景，对上述接口测试的方法进行进一步的说明：

货主A需要将自己的货物发送给用户B，则货主A可以登录相关的货物运输的APP。货主A可以输入自己货物的规格，选择需要运输货物的车型，和发货时间等。APP在接收货主输入的信息后，可以自动生成订单，然后将该订单进行“广播”。司机可以接收该订单，并在在预约时间内，将货主A的货物运送至用户B。用户B收到货物后，可以点击APP上的“确定收货”选项。货主A收到用户B的“确认收货”选项后，可以对该订单进行付款。

在上述场景中，从软件角度来讲，用到的接口有，登录接口，货主发货接口，司机接单接口，用户确认收货接口和货主付款接口。

本申请实施例就是提供一种接口管理工具(即客户端)，该客户端可以使用本申请提出的接口测试的逻辑，模拟上述场景，对上述接口进行接口串联测试，并可以自动生成接口文档及接口结构图等。

在实现时，开发人员可以通过客户端的交互界面，对上述接口的接口信息以及接口测试顺序进行录入。

对于接口信息的录入，主要包括参数、返回阶段，接口的角色类型，接口名称和路径信息等。比如，对于登录接口来讲，货主登录上述APP时输入的用户名和密码为调用该登录接口需要输入的参数，而从该接口返回的期望返回字段为Session key(会话密钥)；对于货主发货接口来讲，所要发送的参数不仅包括自定义参数，如货主输入的“车型”“货物规格”以及“发货时间”等，还包括从登录接口返回的Session key，从该货主发货接口返回的期望返回字段为“订单信息”；对于司机接单接口来讲，所要发送的参数为“订单信息”，期望返回字段为“接单信息”和该“订单信息”；对于用户确认收货接口，所要向该接口发送的参数为“订单信息”和“确认收货信息”，期望返回字段为“确认收货消息”和与该消息对应的“订单信息”；对于货主付款接口，所要向该接口发送的参数为“确认收货消息”和与该消息对应的“订单信息”，期望返回字段为“付款成功消息”和该“订单信息”。

而对于该场景接口的测试顺序(即调用接口的先后顺序)可以依次为登录接口，货主发货接口，司机接单接口，用户确认收货接口和货主付款接口。

在对上述接口进行接口串联测试时，开发人员可以将上述接口信息和接口的测试顺序录入客户端中。

客户端在接收到上述接口的接口信息和测试顺序后，可以自动生成对应的接口串联测试线程，对上述接口进行测试。

对于登录接口，客户端可以基于开发人员输入的用户名和密码，构造HTTP模拟请求，并可以向该登录接口对应的后台服务器发送该HTTP模拟请求。该服务器可以通过该登录接口向客户端发送返回字段(Session key)。

此时，客户端可以判断后台服务器返回的返回字段是否包含开发人员录入的针对登录接口的期望返回字段，如果包含，则确定该登录接口处于正常状态。如果不包含或者未完全包含，则确定该接口处于非正常状态，此时，客户端可以记录该登录接口未包含的期望返回字段，并记录该HTTP响应请求的内容。

对于货主发货接口，客户端可以基于开发人员输入的自定义参数，如“车型”“货物规格”以及“发货时间”，以及通过登录接口返回的期望返回字段，如Session key，构造HTTP模拟请求，并可以向该登录接口对应的后台服务器发送该HTTP模拟请求。该服务器可以通过该登录接口向客户端发送返回字段(订单信息)。

此时，客户端可以判断后台服务器返回的返回字段是否包含开发人员录入的针对货主发货接口的期望返回字段，如果包含，则确定该货主发货接口处于正常状态。如果不包含或者未完全包含，则确定该货主发货接口处于非正常状态，此时，客户端可以记录该货主发货接口未包含的期望返回字段，并记录该HTTP响应请求的内容。

客户端可以使用上述接口串联测试的方法对其余接口进行接口串联测试，在此，不再一一赘述。

此外，客户端可以基于开发人员录入的上述接口的接口信息和测试顺序，自动生成接口文档和接口结构图。

本申请提供一种本发明实施例主要是提供了一种接口管理的工具(即客户端)。该接口管理工具集成了自动执行接口串联测试，接口文档地自动编写，以及自动绘制接口结构图等功能，并且可以执行本申请提出的接口测试方法的逻辑。

客户端可以获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序，并可以基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务。客户端可以基于预设的接口串联测试周期周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口的串联测试。此外，当客户端获取到开发人员录入的上述接口信息和测试顺序后，客户端可以自动生成接口文档和接口结构图。

此外，当客户端获取到开发人员录入的上述接口信息和测试顺序后，客户端可以自动生成接口文档和接口结构图。

一方面，由于客户端可以基于开发人员录入的若干相关联的后台接口的接口信息和接口测试顺序自动生成对应的接口串联测试任务，并基于预设的串联测试周期，周期性地对该关联接口执行接口串联测试任务，从而实现周期性地监测后台接口的状态，有效地保证了后台接口的稳定性，并且大大降低了人力成本，提高了接口管理的效率。

另一方面，由于开发人员只需要录入一次接口信息，该客户端就可以自动生成接口文档，接口结构图，并对开发人员选择的相关联的接口进行接口串联测试，从而可以有效地缩短接口管理的时间；

此外，由于当开发人员需要对接口信息进行修改时，开发人员只需要将修改的接口信息录入客户端，该客户端就可以对接口文档，接口结构图和接口串联测试中的相关接口信息进行修改，从而可以降低人力成本，有效地避免接口信息修改错误的出现。

与此同时，当测试接口处于非正常状态后，该客户端的交互界面上可以为开发人员展示，模拟调用该接口未包含的期望返回字段等，从而便于开发人员排查错误。

与前述接口测试方法的实施例相对应，本申请还提供了接口测试装置的实施例。

本申请接口测试装置的实施例可以应用在客户端上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图2所示，为本申请接口测试装置所在设备的一种硬件结构图，除了图2所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的设备通常根据该接口测试的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图3，图3是本申请一示例性实施例示出的一种接口测试装置的框图。所述装置包括获取单元310，第一生成单元320和执行单元330。

其中，获取单元310，用于获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序；

第一生成单元320，用于基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务；

执行单元330，用于基于预设的接口串联测试周期，周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口串联测试。

在一个可选的实现方式中：

所述装置还包括：第二生成单元340，用于基于开发人员录入的所述接口信息，自动生成对应的接口文档。

在另一个可选的实现方式中：

所述装置还包括：第三生成单元350，用于基于所述角色类型信息和所述测试顺序，自动生成接口结构图。

在另一个可选的实现方式中：

所述装置还包括：验证单元360，用于基于所述若干相关联的后台接口之间的关联关系，对所述串联测试线程中的测试顺序进行验证。

在另一个可选的实现方式中：

所述接口信息包括用于对接口进行测试的预设参数；其中，所述预设参数包含上一待测试接口被调用后台服务器后的返回字段；

所述执行单元330，具体用于基于所述测试顺序，依次为所述若干相关联的后台接口构造用于调用所述返回字段的HTTP模拟请求；将构造出的所述HTTP模拟请求，发送至对应的后台服务器，以完成模拟调用；接收所述后台服务器响应所述HTTP模拟请求后的返回字段，并验证所述返回字段中是否包含预设的期望返回字段；如果是，确定对应的后台接口处于正常状态；如果否，记录所述返回字段中未包含的期望返回字段；如果所述后台服务器未响应所述HTTP模拟请求，确定对应的后台接口测试失败，并记录该HTTP模拟请求中携带的所述预设参数及所述后台服务器返回的调用失败的状态码。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

Claims (10)

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

获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序；

基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务；

基于预设的接口串联测试周期，周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口串联测试。

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

基于开发人员录入的所述接口信息，自动生成对应的接口文档。

3.根据权利要求1所述的方法，其特征在于，所述接口信息包括所述后台接口的角色类型信息；

基于所述角色类型信息和所述测试顺序，自动生成接口结构图。

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

基于所述若干相关联的后台接口之间的关联关系，对所述串联测试线程中的测试顺序进行验证。

5.根据权利要求1所述的方法，其特征在于，所述接口信息包括用于对接口进行测试的预设参数；其中，所述预设参数包含上一待测试接口被调用后台服务器后的返回字段；

所述执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口的串联测试，包括：

基于所述测试顺序，依次为所述若干相关联的后台接口构造用于调用所述返回字段的HTTP模拟请求；

将构造出的所述HTTP模拟请求，发送至对应的后台服务器，以完成模拟调用；

接收所述后台服务器响应所述HTTP模拟请求后的返回字段，并验证所述返回字段中是否包含预设的期望返回字段；如果是，确定对应的后台接口处于正常状态；如果否，记录所述返回字段中未包含的期望返回字段；

如果所述后台服务器未响应所述HTTP模拟请求，确定对应的后台接口测试失败，并记录该HTTP模拟请求中携带的所述预设参数及所述后台服务器返回的调用失败的状态码。

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

获取单元，用于获取开发人员录入的若干相关联的后台接口的接口信息和测试顺序；

第一生成单元，用于基于所述接口信息和所述测试顺序，生成对应的接口串联测试任务；

执行单元，用于基于预设的接口串联测试周期，周期性执行所述接口串联测试任务，以完成针对所述若干相关联的后台接口串联测试。

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

第二生成单元，用于基于开发人员录入的所述接口信息，自动生成对应的接口文档。

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

第三生成单元，用于基于所述角色类型信息和所述测试顺序，自动生成接口结构图。

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

验证单元，用于基于所述若干相关联的后台接口之间的关联关系，对所述串联测试线程中的测试顺序进行验证。

10.根据权利要求6所述的装置，其特征在于，所述接口信息包括用于对接口进行测试的预设参数；其中，所述预设参数包含上一待测试接口被调用后台服务器后的返回字段；

所述执行单元，具体用于基于所述测试顺序，依次为所述若干相关联的后台接口构造用于调用所述返回字段的HTTP模拟请求；将构造出的所述HTTP模拟请求，发送至对应的后台服务器，以完成模拟调用；接收所述后台服务器响应所述HTTP模拟请求后的返回字段，并验证所述返回字段中是否包含预设的期望返回字段；如果是，确定对应的后台接口处于正常状态；如果否，记录所述返回字段中未包含的期望返回字段；如果所述后台服务器未响应所述HTTP模拟请求，确定对应的后台接口测试失败，并记录该HTTP模拟请求中携带的所述预设参数及所述后台服务器返回的调用失败的状态码。