具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

接口测试，作为常见的功能测试方式，是QA(Quality Assurance，测试工作人员)保证系统稳定和持续集成的重要手段之一。而在频繁迭代的业务中，不断回归已有接口的测试，严重影响了QA的测试效率和项目进度。因此，实现接口自动化测试，可以让QA把更多的时间花在用例设计和新功能的测试上，从而加速项目迭代。

在一些相关的实施例中，可以通过一些测试工具提供自动化测试功能，例如Postman、JMeter、soapUI等工具。然而，在很多实际项目中，这些工具并没办法完全满足“自动化”，只能作为QA的辅助工具，或者甚至无法运用到项目中。要实现真正意义上的自动化，还需要解决以下几个问题：

1.接口测试结果校验过于简单

大多数的测试工具基本上只能通过对接口的消息回包做检验来判断测试结果是否正确。对于一个复杂系统的接口，可能涉及到多个上下游服务的调用，简单的回包校验很容易造成问题遗漏或问题定位不正确。例如，在一次迭代中，调用链路上的某个服务少更新了数据库字段，或没有继续调用上游服务，但仍然正确返回，导致这个问题继续向下游业务潜伏行进，直到真的影响到下游业务时，才可能被发现。所以，面对复杂业务的接口，QA还是需要人为观察相关服务的调用情况和数据库的数据变换，来保证接口的准确性。

2.无法自动化解决接口依赖的业务数据

普通的接口测试工具没办法自动化设置接口依赖的业务数据。例如，在一个电商系统中，如果需要测试购买商品的接口，QA需要在每次测试之前，先找一个有足够余额的账号，或给某个测试账号设置足够的余额，再进行测试。

基于上述待解决的问题，本示例实施方式首先提供了一种接口的测试方法。参考图1所示，上述接口的测试方法可以包括以下步骤：

步骤S110.获取待测接口的测试用例，其中，待测接口中包含多个服务。

步骤S120.向待测接口发送包含追踪标记位的追踪协议包，并执行待测接口的测试用例。

步骤S130.在执行测试用例时，若待测接口中的服务接收到的协议包为追踪协议包，则将追踪标记位添加至服务发出的协议包中，并将服务发出的协议包标记为追踪协议包。

步骤S140.若测试用例执行完毕，获取所有服务接收到的追踪协议包与发出的追踪协议包中的协议数据，并根据协议数据以及待测接口的预期协议数据得到待测接口的测试结果。

本公开示例实施方式的接口的测试方法中，通过向待测接口发送包含追踪标记位的追踪协议包，并检测待测接口中的各个服务所接收到的协议包是否为追踪协议包，在服务接收到的协议包为追踪协议包时，将追踪标记位添加至该服务向其他服务发出的协议包中，然后根据所有追踪协议包中的协议数据得到待测接口的测试结果。本公开示例实施方式中的接口的测试方法，通过链路追踪的方式，在协议包中添加追踪标记位，来追踪记录接口发起后调用链路上所有服务的上下行消息，通过分析追踪协议包中的协议数据是否正确，来确定接口中相关服务的调用情况和相关数据的变化，从而得到接口的测试结果。对于涉及到多个上下游服务调用的复杂系统的接口来说，可以提高接口测试的效率和准确性。

下面，结合图2至图8对本示例实施方式的上述步骤进行更加详细的说明。

在步骤S110中，获取待测接口的测试用例，其中，待测接口中包含多个服务。

测试用例是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，最终形成文档。简单地认为，测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，用于核实是否满足某个特定软件需求。

本示例实施方式中，待测接口的测试用例指的是待测试的接口对应的测试用例。其中，待测接口可以为一个复杂系统的接口，涉及多个上下游服务的调用。

在执行测试用例之前，本示例实施方式中的接口的测试方法还需要设置测试所需的环境数据，具体方法可以为：若存在预先设置的接口参数，则调用通用网关接口，根据预先设置的接口参数，初始化测试用例中所需的业务数据；若不存在预先设置的接口参数，则根据预先设置的数据库参数和/或缓存参数，初始化测试用例中所需的业务数据。

本示例实施方式中，可以根据预先配置的CGI(Common Gateway Interface，通用网关接口)和接口参数，直接调用对应的CGI，初始化测试用例中所需的业务数据，简化复杂业务的数据库和缓存的初始化操作。如果没有提供相应的接口调用服务，则通过数据库或者缓存的设置，来完成业务数据的初始化操作。

举例而言，在一个网络购物的业务场景中，需要给用户设置足够的金额，测试人员可以通过两种方式进行初始化业务数据。如果配置了“设置余额”服务接口，则直接通过接口调用来完成业务数据的初始化，设置足够的用户余额，无需通过数据库或缓存进行设置；如果没有提供相应的服务接口，则通过预先设置的数据库参数和缓存参数来初始化业务数据，例如，将用户余额的数据库表设置成足够的金额，或者如果用户余额有做缓存，则设置缓存，具体通过数据库还是缓存来进行设置，可以根据实际的业务需求来确定。

本示例实施方式中，如图2所示，根据预先设置的数据库参数和/或缓存参数，初始化测试用例中所需的业务数据，具体可以包括以下几个步骤：

步骤S210.根据预先设置的数据库参数连接对应的数据库。

数据库参数可以包括数据库的数据库地址、端口配置信息和授权信息，根据上述数据库参数即可连接对应的数据库。

步骤S220.通过执行数据库预先配置的数据库初始操作，初始化测试用例中所需的业务数据。

本示例实施方式中，预先配置的数据库初始操作可例如insert(插入)、set(设置)、inc(增加)和remove(移除)等操作。通过执行配置提供的数据库初始操作，可以初始化业务数据。

举例而言，假设某一业务用于计算用户所拥有的球的数量，则预先配置的数据库初始操作可以为：设置连接数据库的ip、端口、用户和密码，然后执行上述四种数据库初始操作：首先通过执行insert操作插入ball_count数据表，表中球的id为2，数量为1；第二步，通过执行set操作更新id为2的球数量为2；第三步，通过执行inc操作给id为2的球的数量加1，将数量为更新为3；最后，通过执行remove操作删除id为1的球。

步骤S230.根据预先设置的缓存参数初始化测试用例中的缓存。

本示例实施方式中，缓存参数可以包括缓存的地址和端口配置信息。在执行数据库初始设置后，可以根据缓存的地址和端口配置信息，对缓存进行初始化设置。

步骤S240.通过执行缓存中预先配置的缓存初始操作，初始化测试用例中所需的业务数据。

缓存初始操作可例如set(设置)、del(删除)等。

举例而言，可以通过set操作设置id为2的球数量为3，再通过del操作将id为1的球删除。

在初始化测试用例中所需的业务数据之前，本示例实施方式中的接口的测试方法还可以对数据库和缓存进行备份，得到备份环境数据，以便在测试用例执行完毕后，根据备份环境数据对数据库和缓存中的数据进行恢复。

本示例实施方式中，在初始化测试用例中所需的业务数据之后，本示例实施方式中的接口的测试方法还可以包括：判断用于执行测试用例的业务服务器是否开启了用于配置虚拟协议的虚拟服务；若业务服务器开启了虚拟服务，则通过虚拟协议获取预先配置的虚拟数据作为测试所需的业务数据；若业务服务器未开启虚拟服务，则通过第三方服务协议获取真实数据作为测试所需的业务数据。

在初始化业务数据之后，还可以通过设置相关协议的Mock(虚拟)信息，让服务在请求第三方的协议时，能够返回预先配置的数据信息。其中，协议Mock指的是，在请求协议时不返回真实数据，而返回虚拟的配置数据。

在步骤S120中，向待测接口发送包含追踪标记位的追踪协议包，并执行待测接口的测试用例。

做好相关的环境准备之后，就可以对测试用例配置的协议进行请求，开始执行测试用例。在发起协议前，可以先向待测接口发送包含追踪标记位的追踪协议包，具体的，可以将追踪标记位添加在协议包的头部，得到对应追踪协议包，并收集该协议包的数据，存储到用于协议分析的日志数据库中。

在步骤S130中，在执行测试用例时，若待测接口中的服务接收到的协议包为追踪协议包，则将追踪标记位添加至服务发出的协议包中，并将服务发出的协议包标记为追踪协议包。

在执行测试用例时，接口中的下游服务通过向其所依赖的上游服务发送协议包，从而完成接口中各个服务的调用，最终实现接口的完整功能。接口中的下游服务发送来的协议包在经过当前服务之后，当前服务会根据接收到的协议包产生多个协议包并发送出去。接口中的每个服务接收到的协议包，如果头部包含追踪标记位的字段，则自动解析出该追踪标记位，并将追踪标记位添加到服务发出的协议包中，然后将服务发出的协议包标记为追踪协议包。

本示例实施方式中，服务发出的追踪协议包可以包括：服务返回给下游服务的协议包、服务发送至上游服务的协议包和服务广播的协议包。其中，服务返回给下游服务的协议包指的是该服务返回给下游服务的消息回包，服务发送至上游服务的协议包指的是发送至该服务所依赖的上游服务的消息包，服务广播的协议包指的是该服务广播至各个客户端的消息包。同时，收集记录所有服务收到的追踪协议包和发出的追踪协议包，存储到用于协议分析的日志数据库中。

在步骤S140中，若测试用例执行完毕，获取所有服务接收到的追踪协议包与发出的追踪协议包中的协议数据，并根据协议数据以及待测接口的预期协议数据得到待测接口的测试结果。

本示例实施方式中，可以支持两种用例结束检测标准，一种是检测到对应的测试结束协议，另一种是超时结束。具体而言，若用于执行测试用例的业务服务器检测到预先配置的测试结束协议，则测试用例执行完毕；若业务服务器未检测到测试结束协议，则当测试时长大于或等于测试时长阈值时，测试用例执行完毕。

测试用例执行完毕时，从日志数据库中获取之前存储的所有服务接收到的追踪协议包与发出的追踪协议包中的协议数据，然后获取测试用例中的预期协议数据，通过对比日志数据库中的协议数据和预期协议数据，得到待测接口的测试结果。协议数据一般以JSON(JavaScript Object Notation，JS对象简谱)等数据格式进行存储，包含了接口运行过程中的一些关键的数据，例如，对于一个支付接口来说，协议数据可以包括用户余额、用户支付金额等数据。

本示例实施方式中，根据协议数据以及待测接口的预期协议数据得到待测接口的测试结果的具体方法为：判断预期产生的所有协议是否完整，以及协议数据是否符合待测接口的预期协议数据；若预期产生的协议不完整，或者协议数据不符合待测接口的预期协议数据，则生成测试结果告警信息。

测试结束后，可以对每一个测试用例生成对应的测试报告，在报告中可以对收集到的协议数据进行分析，首先判断预期产生的所有关键协议是否全部存在，其次，将收集到的协议数据与测试用例中的预期协议数据一一比对，判断收集到的协议数据是否符合预期。比如，某一协议数据需要等于测试用例中给出的预期值，如果测试结束后该协议数据与预期值不相同，则说明该协议数据不符合预期。又比如，某一协议数据需要大于测试用例中给出的预期值，那么如果测试结束后该协议数据小于或等于对应的预期值，则说明该协议数据不符合预期。若测试结果不符合预期，则生成测试结果告警信息并发送给相关工作人员。

除了对协议数据的准确性进行分析以外，还需要对测试前后的数据库和缓存进行分析，具体方法为：若测试用例执行完毕，获取数据库关键数据和缓存关键数据，并判断数据库关键数据和缓存关键数据是否符合预期数据；若数据库关键数据和缓存关键数据不符合预期数据，则生成测试结果告警信息。

本公开示例实施方式中的接口的测试方法，利用链路追踪的方式，追踪记录一个接口发起后调用链路上所有服务的上下行消息，通过分析测试用例执行前后的关键协议是否正确、数据库及缓存数据变换，利用多维度的校验，保证接口真正意义上的准确性。并且支持在执行测试用例前，通过接口设置、数据库设置、缓存设置以及接口返回mock数据的方式，保障接口执行依赖的业务环境，最后生成测试报告并对不符合预期的执行结果进行告警。

如图3所示，是本公开的一个具体实施方式中根据本示例实施方式中的接口的测试方法提供的一个复杂系统下的接口自动化测试装置的框图，是对本示例实施方式中的上述步骤具体应用场景的举例说明，该装置可以包括环境准备模块310、用例执行模块320、结束检测模块330和用例结束模块340四个部分，各模块的具体功能如下：

1.环境准备模块310

在执行测试用例前，该装置会通过环境准备模块310备份数据库和缓存，并根据配置，初始化测试环境的数据库、缓存、接口及业务相关的环境数据。初始化的具体内容如下：

(1)数据库设置：执行用例前，设置依赖业务相关的数据。

(2)缓存设置：执行用例前，设置依赖业务相关的缓存。

(3)接口设置：执行用例前，调用依赖业务接口进行设置。

(4)协议mock：执行用例前，mock某个协议，保证协议期间该协议不返回真实数据，返回mock数据，用于服务中使用到第三方接口的情况。

通过数据库和缓存的设置，基本可以保证大部分自有业务所需要的业务数据(除少部分数据需要通过读取配置文件等方式)。但数据库和缓存的设置较为繁琐，尤其对一些较为复杂的业务逻辑，因此该装置也提供了调用服务接口(CGI)的方式，来简化服务本身业务数据环境的准备过程，如果装置提供了接口调用的服务，则可以直接通过调用服务接口(CGI)的方式初始化业务数据，而不需要通过设置数据库和缓存的的方式来进行初始化。同时，考虑到服务可能依赖第三方服务，该装置还提供协议Mock方式，让依赖第三方协议固定返回配置的虚拟数据，保障测试用例的顺利执行。

如图4所示，是环境准备模块310在初始化环境数据时的整体流程，具体可以包括以下几个步骤：

步骤S410.读取环境准备配置。

装置会备份数据库和缓存，并读取后台配置的数据库地址、缓存地址、相关的业务接口和需要Mock的协议，以及各自对应设置的参数。

步骤S420.初始数据库设置。

装置会根据配置的数据库地址、端口、授权信息连接对应的数据库，并执行配置提供的数据库操作，初始化业务数据和缓存。该装置支持4种数据库数据初始操作，分别是insert、set、inc和remove。

步骤S430.初始缓存设置。

装置会根据缓存的地址、端口配置信息对缓存进行初始化设置。该装置支持2种缓存初始操作，分别是set、del。

步骤S440.调用接口初始设置。

如果装置提供了接口调用的服务，则直接根据配置的CGI和CGI参数，调用对应CGI，通过获取预先设置的参数进行业务数据的初始化，简化复杂业务的数据库和缓存初始化操作。

如果装置提供了接口调用的服务，则测试人员可以直接根据步骤S440进行业务数据的初始化，忽略步骤S420和步骤S430中的逻辑。如果没有提供相应的接口服务，也可以通过步骤S420或步骤S430中的方法初始化业务数据。

步骤S450.对第三方协议进行Mock。

初始化自身的业务数据后，装置还会设置相关协议的Mock信息，让服务请求第三方的协议时，返回预先配置的数据信息。

其中，协议Mock的工作原理如图5所示，接口自动化测试装置自身的业务服务器501需要请求第三方协议数据时，该请求会经过一个proxy代理服务器502，此时，装置会判断该代理服务器502是否开启了Mock服务。若开启了Mock服务，则直接返回固定配置的数据，不进行真实的请求；若没开启Mock，则真实请求第三方服务协议，获取数据。

2.用例执行模块320

做好相关的环境准备之后，该装置会对用例配置的协议进行请求，开始执行测试用例。测试用例的执行过程中，重点包括以下两个部分：

(1)发起协议时，消息进行标记。

发起协议前，装置会在发送协议包的header(头部)添加一个唯一标记位pt(protocol track)，并收集该协议包的数据，类型为client_msg，存储到日志数据库中。

(2)服务接口收到标记消息时，记录日志，并把标记传递给上游服务。

每个服务接收到的请求包，如果头部包含pt字段时，会解析出该标记位pt，并将标记位pt打包到该服务的消息回包、发给上游服务的消息包、以及广播的消息包的头部，其类型分别为send_client_msg、send_svr_msg以及broadcast_msg，然后收集记录该服务收到的协议包(类型为receive_msg)和发出的协议包，存储到日志数据库中。

3.结束检测模块330

如图6所示，执行用例后，装置支持两种用例结束检测标准，一种是检测到对应的测试结束协议，另一种是超时结束。

步骤S610.检测到测试结束协议。

测试用例中如果配置了测试结束协议，例如服务的回包协议，装置会在检测到测试结束协议时结束用例的执行，然后设置用例的执行状态，并开始结束处理模块。

步骤S620.超时结束。

装置在执行到一段时间后，若还没检测到配置的测试结束协议，或用例无法配置结束协议(比如用例结束后需要后台执行一些任务，不能用任何协议来做标识)，用例会自动结束。超时结束也是用例结束的最后保障，例如，可以默认5s的超时结束时间，即用例执行5s后，如果没检测到配置的测试结束协议则会自动结束，该超时结束时间也支持修改。

4.用例结束模块340

装置在结束用例测试后，会根据备份恢复环境准备的数据，并根据配置生成用例分析报告，在报告异常时，发出邮件告警给相关人员。

(1)环境恢复：恢复环境准备的相关环境设置

用例结束后，装置会用环境准备模块310中备份好的数据库和缓存环境进行恢复，并将已经设置的Mock进行恢复。

(2)分析并生成数据报告：

如图7所示，装置会对每个测试用例生成报告，主要是对用例执行模块320中收集到的各个协议进行分析，以及对比数据库和备份数据的变换，生成的测试报告中的具体内容如下：

1)协议分析：关键协议是否存在以及协议数据是否符合预期

装置会先根据用例标记的pt，在收集的协议日志数据库中，判断是否有预先配置的协议产生；然后装置会拿取日志的协议数据，跟配置的预期协议数据一一比对，判断协议数据是否符合预期。

2)数据库分析：数据库关键数据是否正确

接下来，装置还会根据配置的数据库，比对用例执行后的数据和备份数据的变换，判断数据是否符合预期。如图8所示是一个测试结果分析界面的示意图，界面中的配置项说明如下：

数据库连接配置：ip/port/db/user/pwd，分别对应数据库的地址、端口、数据库名称、授权用户和密码。

查询表：报告分析的数据表

查询语句query：用例执行前后对应数据的查询条件，对应不同操作有不同意义。

操作：①insert：查询用例执行后，是否有插入满足query(查询)的记录，假设设置有期望结果，也会比较是否符合期望结果，insert的query一般会查出多条语句，所以装置一般会加入数据表数据插入时间的判断；

②update：查询用例执行后，是否存在满足query的记录，假设设置有期望结果，也会比较是否符合期望结果，比如查询用户的某个状态；

③inc：查询用例执行后，是否存在满足query的记录，符合设置期望的变换结果，此时期望结果必须设置为数值，且允许负值，代表减少，比如查询用户送礼后金锭是否扣除固定额度。

期望结果：查询满足query的记录，配置的字段是否符合操作的预期。如图8所示，界面中的期望结果代表执行用例后，会检测ball_count表id为2的列中，字段number是否会更新为3。

3)缓存分析：缓存关键数据是否更新正确

最后，装置会根据配置的缓存，比对用例执行后，配置检测的key是否存在，以及对应的值是否符合预期值。

(3)错误告警

装置在结束报告分析后，如果发生不符合预期的结果，会发生送告警信息到对应的工作人员，保证问题被及时解决。

应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

进一步的，本公开还提供了一种接口的测试装置。参考图9所示，该接口的测试装置可以包括测试用例获取模块910、追踪协议包标记模块920、追踪标记位添加模块930以及测试结果确定模块930。其中：

测试用例获取模块910可以用于获取待测接口的测试用例，其中，待测接口中包含多个服务；

追踪协议包标记模块920可以用于向待测接口发送包含追踪标记位的追踪协议包，并执行待测接口的测试用例；

追踪标记位添加模块930可以用于在执行测试用例时，若待测接口中的服务接收到的协议包为追踪协议包，则将追踪标记位添加至服务发出的协议包中，并将服务发出的协议包标记为追踪协议包；

测试结果确定模块940可以用于若测试用例执行完毕，获取所有服务接收到的追踪协议包与发出的追踪协议包中的协议数据，并根据协议数据以及待测接口的预期协议数据得到待测接口的测试结果。

在本公开的一些示例性实施例中，追踪标记位添加模块930中服务发出的追踪协议包，包括：服务返回给下游服务的协议包、服务发送至上游服务的协议包和服务广播的协议包。

在本公开的一些示例性实施例中，本公开提供的一种接口的测试装置还可以包括环境数据设置模块，该环境数据设置模块可以包括接口调用单元以及数据库缓存设置单元。其中：

接口调用单元可以用于若存在预先设置的接口参数，则调用通用网关接口，根据预先设置的接口参数，初始化测试用例中所需的业务数据；

数据库缓存设置单元可以用于若不存在预先设置的接口参数，则根据预先设置的数据库参数和/或缓存参数，初始化测试用例中所需的业务数据。

在本公开的一些示例性实施例中，数据库缓存设置单元可以包括数据库连接单元、第一数据初始化单元、缓存初始化单元以及第二数据初始化单元。其中：

第一数据初始化单元可以用于根据预先设置的数据库参数连接对应的数据库，其中，数据库参数包括数据库的数据库地址、端口配置信息和授权信息；

数据库初始化单元可以用于通过执行数据库预先配置的数据库初始操作，初始化测试用例中所需的业务数据；

缓存初始化单元可以用于根据预先设置的缓存参数初始化测试用例中的缓存，其中，缓存参数包括缓存的地址和端口配置信息；

第二数据初始化单元可以用于通过执行缓存中预先配置的缓存初始操作，初始化测试用例中所需的业务数据。

在本公开的一些示例性实施例中，环境数据设置模块还可以包括虚拟服务判断单元、虚拟数据获取单元以及真实数据获取单元。其中：

虚拟服务判断单元可以用于判断用于执行测试用例的业务服务器是否开启了用于配置虚拟协议的虚拟服务；

虚拟数据获取单元可以用于若业务服务器开启了虚拟服务，则通过虚拟协议获取预先配置的虚拟数据作为测试所需的业务数据；

真实数据获取单元可以用于若业务服务器未开启虚拟服务，则通过第三方服务协议获取真实数据作为测试所需的业务数据。

在本公开的一些示例性实施例中，本公开提供的一种接口的测试装置还可以包括环境数据备份单元，可以用于在初始化测试用例中所需的业务数据和缓存之前，对数据库和缓存进行备份，得到备份环境数据。

在本公开的一些示例性实施例中，本公开提供的一种接口的测试装置还可以包括环境数据恢复模块，可以用于在测试用例执行完毕后，根据备份环境数据对数据库和缓存中的数据进行恢复。

在本公开的一些示例性实施例中，测试结果确定模块940可以包括协议结束单元以及超时结束单元。其中：

协议结束单元可以用于若用于执行测试用例的业务服务器检测到预先配置的测试结束协议，则测试用例执行完毕；

超时结束单元可以用于若业务服务器未检测到测试结束协议，则当测试时长大于或等于测试时长阈值时，测试用例执行完毕。

在本公开的一些示例性实施例中，测试结果确定模块940还可以包括预期协议数据判断单元以及测试结果告警单元。其中：

预期协议数据判断单元可以用于判断预期产生的所有协议是否完整，以及协议数据是否符合待测接口的预期协议数据；

测试结果告警单元可以用于若预期产生的协议不完整，或者协议数据不符合待测接口的预期协议数据，则生成测试结果告警信息。

在本公开的一些示例性实施例中，测试结果确定模块940还可以包括关键数据判断单元以及测试结果告警单元。其中：

关键数据判断单元可以用于若测试用例执行完毕，获取数据库关键数据和缓存关键数据，并判断数据库关键数据和缓存关键数据是否符合预期数据；

测试结果告警单元可以用于若数据库关键数据和缓存关键数据不符合预期数据，则生成测试结果告警信息。

上述接口的测试装置中各模块/单元的具体细节在相应的方法实施例部分已有详细的说明，此处不再赘述。

图10示出了适于用来实现本发明实施例的电子设备的计算机系统的结构示意图。

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

如图10所示，计算机系统1000包括中央处理单元(CPU)1001，其可以根据存储在只读存储器(ROM)1002中的程序或者从存储部分1008加载到随机访问存储器(RAM)1003中的程序而执行各种适当的动作和处理。在RAM 1003中，还存储有系统操作所需的各种程序和数据。CPU1001、ROM 1002以及RAM 1003通过总线1004彼此相连。输入/输出(I/O)接口1005也连接至总线1004。

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

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

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

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

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

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

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

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