CN113468001A - 一种接口处理逻辑的测试方法及装置 - Google Patents

Abstract

本申请公开了一种接口处理逻辑的测试方法及装置，方法包括：当检测到测试指令时，获取样本调用返回值，样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；通过测试接口对样本调用返回值进行处理，得到第一处理结果；比对第一处理结果和第二处理结果，得到比对结果，第二处理结果为原始接口对样本调用返回值进行处理得到的结果；若比对结果为第一处理结果与第二处理结果不相同，则确定测试接口的处理逻辑异常。通过获取原始接口对请求信息进行处理得到的调用返回值，并将调用返回值发送至测试接口进行处理的方式，确保测试接口与原始接口获取到的调用返回值一致，进而确定测试接口的处理逻辑是否存在问题。

Description

一种接口处理逻辑的测试方法及装置

技术领域

本申请涉及接口测试领域，具体涉及一种接口处理逻辑的测试方法及装置。

背景技术

随着软件的快速发展，各种软件被研发并应用在用户端设备上，而软件对应有后台服务器对其进行支持，当服务器重新构建、迁移至云平台或软件功能迭代时，可能会对服务器中一些业务接口进行改造或重新构建，而新接口的处理逻辑需要对其进行测试。

现有技术中，为了确定新接口的处理逻辑是否存在问题会将实际发送至旧接口的请求信息重新发送至新接口最后比对两接口处理得到的处理结果是否一致，从而确定新接口的处理逻辑是否异常。但当一些业务接口的业务代码存在使用随机数生成函数或时间戳获取函数等代码时，由于旧接口在进行处理时所用到的随机数和时间戳与测试新接口时的数据存在不一致，这样会导致新旧接口在接收到请求信息去调用第三方组件得到的调用返回值会不一致，从而对不同的调用返回值进行处理得到的处理结果是不同的，也就无法确定新接口的处理逻辑是否存在问题。

发明内容

本申请实施例提供一种接口处理逻辑的测试方法及装置，可以确保测试接口与原始接口获取到的调用返回值一致，进而确定测试接口的处理逻辑是否存在问题。

本申请实施例提供一种接口处理逻辑的测试方法，包括：

当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；

通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；

比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；

若所述比对结果为所述第一处理结果与所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。

本申请实施例还提供一种接口处理逻辑的测试装置，包括：

第一获取单元。用于当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；

接口处理单元，用于通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；

比对单元，用于比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；

确定单元，用于若所述比对结果为所述第一处理结果与所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。

本申请实施例提供的接口处理逻辑的测试方法，包括：当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；若所述比对结果为所述第一处理结果与所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。通过获取原始接口对请求信息进行处理得到的调用返回值，并将调用返回值发送至测试接口进行处理的方式，确保测试接口与原始接口获取到的调用返回值一致，进而确定测试接口的处理逻辑是否存在问题。

附图说明

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

图1a为本申请实施例提供的接口处理逻辑的测试方法的场景示意图。

图1b为本申请实施例提供的接口处理逻辑的测试方法的第一种流程示意图。

图1c为本申请实施例提供的原始接口在接收到请求信息后的调用过程示意图。

图1d为本申请实施例提供的原始接口在接收到请求信息后的处理过程示意图。

图1e为本申请实施例提供的针对于静态语言获取请求信息、调用返回值以及处理结果的示意图。

图1f为本申请实施例提供的针对于静态语言检测测试接口处理逻辑是否异常的示意图。

图2a为本申请实施例提供的接口处理逻辑的测试方法的第二种流程示意图。

图2b为本申请实施例提供的接口处理逻辑的测试方法的第一种框架示意图。

图2c为本申请实施例提供的接口处理逻辑的测试方法的第二种框架示意图。

图3为本申请实施例提供的接口处理逻辑的测试装置的结构示意图。

图4为本申请实施例提供的服务器的结构示意图。

具体实施方式

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

本申请实施例提供了一接口处理逻辑的测试方法、装置、存储介质及服务器。其中，接口处理逻辑的测试装置可以集成在服务器中，该服务器指的是应用于接口测试平台中的测试服务器，也即由测试服务器来实现本申请方法。

请参阅图1a，图1a为本申请实施例提供的接口处理逻辑的测试方法的场景示意图。包括：用户端设备10、业务处理服务器20以及测试服务器30。其中，业务处理服务器20即为线上正常使用的软件所对应的业务平台中的服务器，其可以接收用户端设备10所发送的请求信息，并发送至原始接口，原始接口根据请求信息调用第三方组件从而获取调用返回值，再对调用返回值进行处理，最终得到一处理结果(即第二处理结果)反馈给用户端设备10。而测试服务器30即应用于测试平台中的服务器，其用于获取业务平台中由原始接口根据请求信息调用第三方组件获取到的调用返回值，并将该调用返回值发送至测试接口进行测试，最终由测试接口得到一处理结果(即第一处理结果)，再比对第一处理结果与第二处理结果是否一致，即检测测试接口的处理逻辑是否异常，当输入原始接口及测试接口的调用返回值相同，但输出的处理结果不同时，则可以确定测试接口的处理逻辑异常。图1a是以用户端设备10为手机为例。该用户端设备10中可以安装有各种用户所需的应用，比如具备娱乐功能的应用(如视频应用，音频播放应用，游戏应用，阅读软件)，又如具备服务功能的应用(如地图导航应用、餐饮应用等)。

基于上述图1a所示的系统，以软件功能的迭代为例，D软件当前线上的版本为1.0版本，并在线下研发了具备新功能的2.0版本，需要对2.0版本的软件中的业务接口进行测试，1.0版本的软件接收真实用户通过手机所发送的请求信息，并发送至原始业务接口，原始业务接口根据请求信息调用第三方组件从而获取调用返回值，再对调用返回值进行处理，最终得到一处理结果反馈给真实用户的手机。而2.0版本的软件用于获取1.0版本中原始业务接口根据请求信息调用第三方组件获取到的调用返回值，并将该调用返回值发送至测试接口进行测试，最终由测试接口得到一处理结果，再比对原始业务接口与测试接口得到的处理结果是否一致，即检测2.0版本的软件D接口的处理逻辑是否异常，若比对后的比对结果为不一致的，则检测出2.0版本的软件D接口的处理逻辑异常。

本发明实施例涉及的系统可以是由客户端、多个节点(接入网络中的任意形式的计算设备，如服务器、用户终端)通过网络通信的形式连接形成的分布式系统。例如区块链，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链(Blockchain)，本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性(防伪)和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成(账户管理)、密钥管理以及用户真实身份和区块链地址对应关系维护(权限管理)等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置(风控审计)；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理(接口适配)，然后通过共识算法将业务信息加密(共识管理)，在加密之后完整一致的传输至共享账本上(网络通信)，并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上(合约注册)，根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

上述图1a的例子只是实现本申请实施例的一个系统架构实例，本申请实施例并不限于上述图1a所示的系统结构，基于该系统架构，提出本申请各个实施例。

在一些实施例中，提供了一种接口处理逻辑的测试方法，如图1b所示，该接口处理逻辑的测试方法包括：

步骤101、当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值。

具体的，在用户端设备向业务平台的处理服务器发送请求信息后，业务平台中的原始接口会接收到该请求信息，并根据请求信息去调用第三方组件，请参阅图1c，图1c为本申请实施例提供的原始接口在接收到请求信息后的调用过程示意图。其中，请求信息可以包括有第三方的远程过程调用(RPC)以及http请求，http请求中还可以包括：消息首行中，对资源的请求方法、资源的标识符及使用的协议等。线上服务也即业务平台，当线上服务接收到该请求信息后会去调用第三方组件，即图1c中的远程过程调用后端服务、http后端服务、数据库(DB)、缓存(Cache)及消息队列(Message Queue，MQ)等的第三方组件。而具体在接收到请求信息后需要调用何种组件需要根据请求信息所携带的请求内容而定，此处不做限定。

请参阅图1d，图1d为本申请实施例提供的原始接口在接收到请求信息后的处理过程示意图。在调用第三方组件得到调用返回后，原始接口会对得到的调用返回值进行相应处理，最终生成一处理结果反馈给用户端设备。

其中，测试指令为测试平台中用户点击测试按钮触发的指令，或者为在编译流水线中加入触发测试节点等的方式触发测试指令。根据测试的方式不同可以将测试方式分为两种，第一种为实时测试，即检测到处理服务器接收到客户端发送的请求信息时，实时拦截处理接口调用第三方组件得到的调用返回值，并将该调用返回值发送至测试平台中的测试接口中。以确保向测试接口发送的调用返回值与业务平台中原始接口接收到的调用返回值相同，也即保证输入两接口的输入相同。第二种为线下测试，即先将业务平台中产生的调用返回值进行保存，当检测到测试指令时，再向测试平台的测试接口输入调用返回值。这样可以避免在当原始接口有数据库(DB)调用的操作时，不能做到幂等，进而造成数据重复写入，数据污染。无论采取何种测试方式，都需事先获取原始接口调用目标组件产生的调用返回值，因此，在检测到测试指令之前，还包括：

拦截用户端设备发送的请求信息；

控制原始接口根据所述请求信息调用目标组件获取目标调用返回值。以实时测试的方式为例，因为要进行实时测试，所以在获取到目标调用返回值后，需要将该目标调用返回值发送至测试接口，因此，获取样本调用返回值，包括：

将所述目标调用返回值作为样本调用返回值。

以线下测试的方式为例，将从业务平台中获取到的调用返回值进行存储，并在接收到测试指令时，从事先存储的存储区中取出该调用返回值并输送至测试接口。而由于存储区中可能会存在一些除调用返回值以外的数据，因此，在从存储区中取出调用返回值时可能存在取错或无法取出的问题，因此，可以根据业务平台中运行时的调用次数、调用时长等信息为调用返回值进行标识。例如：在业务平台中调用3次后得到的信息为调用返回值，因此在将调用返回值存储时，可将调用返回值标识为3。这样，从存储区中取出调用返回值时，可以查找被标识为3的值，从而确定该信息为调用返回值并取出；或者拟定在业务平台中经历5ms得到的信息为调用返回值，因此在将调用返回值存储时，可将调用返回值标识为5ms。这样，从存储区中取出调用返回值时，可以查找被标识为5ms的值，从而确定该信息为调用返回值并取出。因此，在检测到测试指令之前，还可以包括：

拦截用户端设备发送的请求信息；

控制原始接口根据所述请求信息调用目标组件获取对应的调用返回值；

基于第一标识对获取的调用返回值进行标记；

将标记后的调用返回值存储至预设存储区中；

所述获取样本调用返回值，包括：

从所述预设存储区中获取被第一标识标记的信息；

将被第一标识标记的信息作为所述样本调用返回值。

而由于单个请求需要调用的第三方组件可能不同，或者无需调用某一或某些个第三方组件时，将原始接口调用得到的调用返回值发送至测试接口时，测试接口中的处理逻辑代码也仅是针对某一或某些第三方组件的调用返回值进行处理，这样测试的不够全面，无法得知测试接口在针对其他第三方组件的调用返回值进行处理时，处理逻辑是否正常。因此，可获取原始接口根据多个请求信息调用第三方组件得到的调用返回值。但随之带来的问题是，有些请求信息需要调用多个第三方组件得到多个调用返回值，而在测试阶段，从数据库中无法得知那些调用返回值对应的哪一个请求信息，因此，可将业务平台接收到的请求信息一并获取并加以标识进行保存，并将原始接口根据该请求信息进行处理得到的一系列值均为与该条请求信息标识为相同的标识。此处的标识可用通用唯一识别码(Universally Unique Identifier，UUID)进行标识，例如：业务平台接收到请求信息时，将该请求信息标识为A，当原始接口根据该请求信息调用第三方组件得到调用返回值时，也对该调用返回值标识为A，以及原始接口对该调用返回值进行处理得到的处理结果也标识为A。以此可得知那些调用返回值及处理结果对应的哪条请求信息。而与从存储区取调用返回值的方式相同，为了确定哪个值代表的是请求信息，可以根据调用次数的方式对请求信息添加另一标识，此处不做赘述。因此，在拦截用户端设备发送的请求信息之后，还包括：

基于第二标识对所述请求信息进行标记；

将标记后的请求信息存储至预设存储区中；

在所述将标识后目标调用返回值存储至预设存储区中之后，还包括：

基于第二标识对所述目标调用返回值进行标记。

对应的，在测试阶段，可以根据代表着调用次数或调用时长等信息的第三标识从存储区中逐条取出请求信息，并通过解析请求信息所携带的第二标识，从而再去存储区中找出携带第二标识的值，并根据代表着调用次数的第一标识从存储区中取出对应于该条请求信息的调用返回值。因此，在基于第二标识对请求信息进行标记之后，还包括：

基于第三标识对所述请求信息进行标记；

获取样本调用返回值之前，还包括：

从所述预设存储区中获取被第三标识标记的信息，将所述被第三标识标记的信息确定为请求信息，并向所述测试接口发送所述请求信息；

所述将被第一标识标记的信息作为所述样本调用返回值，包括：

解析所述请求信息，若所述请求信息被所述第二标识标记，则从所述预设存储区中查找与所述请求信息具有相同第二标识的信息的集合；

从所述集合中获取被所述第一标识标记的信息，将所述被所述第一标识标记的信息确定为所述样本调用返回值。

步骤102、通过测试接口对所述样本调用返回值进行处理，得到第一处理结果。

具体的，在步骤101中确定了样本调用返回值后，将该样本调用返回值发送至测试接口，由测试接口的处理逻辑代码对其进行处理，从而会得到第一处理结果。在得到第一处理结果后可将其存储为json格式。

步骤103、比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果。

具体的，根据测试方式的不同，因此获取原始接口对样本调用返回值进行处理得到的第二处理结果的方式也不同，针对于第一种实时测试的方式，第二结果只需在比对第一处理结果与第二处理结果之前由原始接口处理得到即可。针对于第二种线下测试的方式，需要将第二处理结果存储在存储区中，在进行比对之前从存储区中取出第二处理结果，而针对于单条请求信息，在存储第二处理结果时只需对其按照调用次数的方式进行标识，这样就可按照标识的调用次数取出第二处理结果；针对于多条请求信息的，在存储第二处理结果时不仅需按照调用次数的方式进行标识，还需根据请求信息的第二标识对其进行相同的标识，从而确定哪一第二处理结果对应的哪条请求信息。

其中，在获取请求信息、调用返回值以及处理结果等的值时，可以通过针对于静态语言的面向切面编程技术(Aspect Oriented Programming，AOP)(即在用户端设备与业务平台之间，以及业务平台中原始接口与第三方组件之间织入代码，以获取对应参数值的技术)对go语言等静态编译性语言开发的服务实现获取，也可以直接对java这类自带aop技术的运行时即时编译语言实现获取，具体如何获取可根据语言类型的种类做相应处理。以针对于静态语言获取请求信息、调用返回值以及处理结果为例，请参阅图1e及图1f，图1e为本申请实施例提供的针对于静态语言获取请求信息、调用返回值以及处理结果的示意图，图1f为本申请实施例提供的针对于静态语言检测测试接口处理逻辑是否异常的示意图。其中，在图1e中，在用户端设备与业务平台之间织入代码，从而拦截用户端设备发送至业务平台的请求信息，并在业务平台与第三方组件之间织入代码，从而获取调用及返回值，并将获取到的值存储至存储区中。其中，具体的拦截获取代码为如下形式：

public AnyReturnObject aspectAroundAccess(AnyParam..params){

//从当前上下文获取标记本次请求的唯一标记id

Long uuid＝ThreadContext.getUUID():

//发起真正调用

AnyReturmObject returmObject＝doRealAccess(params)；

//录制本次请求和返回

String request＝uuid+"_”+toString(params)；

cache.set(request,response)

//请求返回

return return0bject；

}

在图1f中，测试平台模拟用户端设备向测试平台中的测试接口发送请求信息，测试接口会根据该请求信息去调用第三方组件，而通过织入代码的方式直接将业务平台中得到的调用返回值返回给测试接口进行处理，最终得到第一处理结果，并存储至存储区，用于比对处理结果。其中，具体的测试接口的处理逻辑代码如下：

public AnyReturnObject aspectAroundAccess(AnyPara..params){

//从当前上下文获取标记本次请求的唯一标记id

long uuid＝ThreadContext.getUUID()；

//屏蔽掉真正的调用

//AnyReturnObject returnObject＝doReaLAccess(params)；

//Mock本次请求的返回

String request＝uuid+"_”+toString(params)；

AnyReturnObject returnObject＝cache.get(request)

//请求返回

return returnObject；

}

步骤104、若比对结果为第一处理结果与第二处理结果不相同，则确定测试接口的处理逻辑异常。

其中，若比对结果为第一处理结果与第二处理结果相同，则证明测试接口的处理逻辑正常；若比对结果为第一处理结果与第二处理结果不相同，则证明测试接口的处理逻辑异常。而造成异常的原因可能为接口逻辑代码漏配置或配置错误导致，需要测试人员进行人工排查。

由上可知，本申请实施例采用当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；若所述比对结果为所述第一处理结果以及所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。通过获取原始接口对请求信息进行处理得到的调用返回值，并将调用返回值发送至测试接口进行处理的方式，确保测试接口与原始接口获取到的调用返回值一致，进而确定测试接口的处理逻辑是否存在问题。

在一些实施例中，以测试方式为线下测试，即先将业务平台中产生的调用返回值进行保存，当检测到测试指令时，再向测试平台的测试接口输入调用返回值，测试存储多条请求信息为例，如图2a所示，该接口处理逻辑的测试方法包括：

步骤201、拦截用户端设备发送的请求信息。

具体的，在获取请求信息时，可以通过针对于静态语言的aop切面技术(即在用户端设备与业务平台之间，以及业务平台中原始接口与第三方组件之间织入代码，以获取对应参数值的技术)对go语言等静态编译性语言开发的服务实现获取，也可以直接对java这类自带aop技术的运行时即时编译语言实现获取，具体如何获取可根据语言类型的种类做相应处理。

步骤202、基于第二标识及第三标识对请求信息进行标记。

为了避免单个请求需要调用的第三方组件可能不同，或者无需调用某一或某些个第三方组件时，将原始接口调用得到的调用返回值发送至测试接口时，测试接口中的处理逻辑代码也仅是针对某一或某些第三方组件的调用返回值进行处理，导致测试不够全面，无法得知测试接口在针对其他第三方组件的调用返回值进行处理时，处理逻辑是否正常。因此，可获取原始接口根据多个请求信息调用第三方组件得到的调用返回值。但随之带来的问题是，有些请求信息需要调用多个第三方组件得到多个调用返回值，而在测试阶段，从数据库中无法得知那些调用返回值对应的哪一个请求信息，因此，可将业务平台接收到的请求信息一并获取并加以标识进行保存，并将原始接口根据该请求信息进行处理得到的一系列值均为与该条请求信息标识为相同的标识。此处的标识可用通用唯一识别码(Universally Unique Identifier，UUID)进行标识，例如：业务平台接收到请求信息时，将该请求信息标识为A，当原始接口根据该请求信息调用第三方组件得到调用返回值时，也对该调用返回值标识为A，以及原始接口对该调用返回值进行处理得到的处理结果也标识为A。以此可得知那些调用返回值及处理结果对应的哪条请求信息。而与从存储区取调用返回值的方式相同，为了确定哪个值代表的是请求信息，可以根据调用次数的方式对请求信息添加另一标识，此处不做赘述，其中，对请求信息进行第二标识及第三标识时的先后顺序不做规定，也可同时进行。

步骤203、将标记后的后请求信息存储至预设存储区中。

步骤204、控制原始接口根据请求信息调用目标组件获取对应的调用返回值。

步骤205、基于第一标识对获取的调用返回值进行标记。

由于存储区中可能会存在一些除调用返回值以外的数据，因此，在从存储区中取出调用返回值时可能存在取错或无法取出的问题，因此，可以根据业务平台中运行时的调用次数或调用时长等信息来为调用返回值进行标识。以调用次数为例：在业务平台中调用3次后得到的值为调用返回值，因此在将调用返回值存储时，可将调用返回值标识为3。这样，从存储区中取出调用返回值时，可以查找标识为3的值，从而确定该值为调用返回值并取出。

步骤206、将标记后的调用返回值存储至预设存储区中。

在对目标调用返回值进行第一标识后，存储至预设存储区中，其中，预设存储区可以包括缓存等，此处不做赘述。

步骤207、基于第二标识对获取的调用返回值进行标记。

为了确保发送至测试接口的调用返回值是对应该条请求信息的，因此还需要将调用返回值标识为与该条请求信息相同的第二标识。

步骤208、当检测到测试指令时，从预设存储区中获取被第三标识标记的信息，将被第三标识标记的信息确定为请求信息，并向测试接口发送请求信息。

具体的，测试指令可以为测试平台中用户点击测试按钮触发的指令，或者为在编译流水线中加入触发测试节点等的方式触发测试指令。对于多条请求信息，需要从存储区中根据代表调用次数的第三标识找出请求信息，并将请求信息发送至测试接口。

步骤209、解析请求信息，若请求信息被第二标识标记，则从预设存储区中查找与请求信息具有相同第二标识的信息的集合。

通过解析请求信息具有的第二标识，确定业务平台在对该条请求信息做处理时对应产生的调用返回值、第二处理结果等与请求信息携带相同第二标识的值的集合。

步骤210、从集合中获取被第一标识标记的信息，将被第一标识标记的信息确定为样本调用返回值。

根据存储区中代表调用次数或调用时长等信息的第一标识确定集合中具有第一标识的值为样本调用返回值。

步骤211、通过测试接口对样本调用返回值进行处理，得到第一处理结果。

具体的，在确定了样本调用返回值后，将该样本调用返回值发送至测试接口，由测试接口的处理逻辑代码对其进行处理，从而会得到第一处理结果。在得到第一处理结果后可将其存储为json格式。

步骤212、控制原始接口对目标调用返回值进行处理，得到第二处理结果。

具体的，此处控制原始接口对目标调用值进行处理可以为在测试时原始接口并未对调用返回值处理完成，而测试平台已经获取了多个请求信息及调用返回值的基础上才执行的处理。也可以将第二处理结果存储在存储区中，在进行比对之前从存储区中取出第二处理结果，在存储第二处理结果时不仅需按照调用次数的方式进行标识，还需根据请求信息的第二标识对其进行相同的标识，从而确定哪一第二处理结果对应的哪条请求信息。

步骤213、比对第一处理结果和第二处理结果，得到比对结果。

步骤214、若比对结果为第一处理结果与第二处理结果相同，则确定测试接口的处理逻辑正常。

其中，若比对结果为第一处理结果与第二处理结果相同，则证明测试接口的处理逻辑正常。

步骤215、若比对结果为第一处理结果与第二处理结果不相同，则确定测试接口的处理逻辑异常。

若比对结果为第一处理结果与第二处理结果不相同，则证明测试接口的处理逻辑异常。而造成异常的原因可能为接口逻辑代码漏配置或配置错误导致，需要测试人员进行人工排查。

请继续参阅图2b及图2c，图2b为本申请实施例提供的接口处理逻辑的测试方法的第一种框架示意图，图2c为本申请实施例提供的接口处理逻辑的测试方法的第二种框架示意图。

图2b及图2c的框架图适用于线下测试的方式，即先经过图2b中的数据获取框架，再通过图2c中的测试框架进行测试。

在数据获取阶段，用户端设备作为客户端发起请求；将请求入口调用代理到业务平台的rpc框架适配器；适配器会对入口调用函数的参数请求二进制包进行解析，获取外层协议的包结构数据,同时在外层二进制包末尾追加一个请求唯一标识形成新的二进制请求包，新的包用于测试阶段的请求发起的数据包；构建请求上下文容器Context，Context包含标识，采用gls框架将请求处理线程做全局映射；将新的请求包二进制数据异步提交到存储；rpc框架适配器回调实际的rpc框架的接口处理器；rpc框架的接口处理器将请求分发到具体的业务接口处理逻辑代码；业务接口处理逻辑代码会发起对第三方组件的调用，此处的调用被代理层拦截；代理层将第三方组件调用的参数和返回值进行截获；将截获的参数和返回值异步提交到存储，作为回放的组件依赖值(Mock)数据，用Context的TraceID作为key进行存储；业务平台返回业务逻辑处理结果，rpc框架适配器收到返回将截获的接口处理结果(json格式)数据异步提交到存储；rpc框架返回业务接口结果到客户端；测试平台的存储落地服务消费异步提交的数据消息；将数据消息解析和分类存储到参数/结果数据模块(cassandra)；将cassandra的数据同步到接口/参数/结果索引模块(ES),可通过索引检索对不同的请求内容字段过滤。

在测试接口阶段，管理后台启动一个回放任务；调用API接口服务将本次任务录制的数据从Cassandra预热到高速缓存模块(redis),实现高速回放的目的；调用回放客户端开启一个请求信息的发包任务；回放客户端按照录制顺序将请求二进制包从预热好的redis中获取出来；依次将获取到的二进制包内容发往测试平台；rpc框架接收到请求后，rpc框架适配器通过解析请求包末尾的标识，恢复从客户端传递过来的请求唯一标识(第二标识)，构建请求上下文Context，然后调用rpc框架的接口处理器；rpc框架适配器回调实际的rpc框架的接口处理器；rpc框架的接口处理器将请求分发到具体的业务接口处理逻辑代码；接口处理逻辑调用第三方组件的AOP切面，rpc框架适配器回调rpc框架的接口处理器；在AOP切面中调用store组件根据上下文中的traceID获取录制好的组件Mock数据，将它返回给调用者；业务接口处理器返回业务逻辑处理结果；rpc框架适配器收到返回将截获的接口响应结果数据异步提交到存储，用于回放结果的对比；rpc框架返回测试接口的处理结果到客户端；测试平台的存储落地服务消费异步提交的数据消息。

在一些实施例中，还提供了一种接口处理逻辑的测试装置，如图3所示，该接口处理逻辑的测试装置可以包括：第一获取单元301、接口处理单元302、比对单元303以及确定单元304。

第一获取单元301，用于当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值。

接口处理单元302，用于通过测试接口对所述样本调用返回值进行处理，得到第一处理结果。

比对单元303，用于比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果。

确定单元304，用于若所述比对结果为所述第一处理结果以及所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。

在一些实施例中，接口处理逻辑的测试装置，还包括：

第一拦截单元305，用于拦截用户端设备发送的请求信息；

第二获取单元306，用于控制原始接口根据所述请求信息调用目标组件获取目标调用返回值；

第一获取单元301，用于将所述目标调用返回值作为样本调用返回值。

在一些实施例中，接口处理逻辑的测试装置，还包括：

控制单元307，用于控制所述原始接口对所述目标调用返回值进行处理，得到第二处理结果。

在一些实施例中，接口处理逻辑的测试装置，还包括：

第二拦截单元308，用于拦截用户端设备发送的请求信息。

第三获取单元309，用于控制原始接口根据所述请求信息调用目标组件获取对应的调用返回值。

第一标记单元310，用于基于第一标识对获取的调用返回值进行标记。

第一存储单元311，用于将标识后目标调用返回值存储至预设存储区中。

第一获取单元301，还用于从所述预设存储区中获取被第一标识标记的信息；

将被第一标识标记的信息作为所述样本调用返回值。

在一些实施例中，接口处理逻辑的测试装置，还包括：

第二标记单元312，用于基于第二标识对所述请求信息进行标记；

第二存储单元313，用于将标记后的请求信息存储至预设存储区中。

第一存储单元311，还用于基于第二标识对获取的调用返回值进行标记。

在一些实施例中，接口处理逻辑的测试装置，还包括：

第三标记单元314，用于基于第三标识对所述请求信息进行标记。

在一些实施例中，第一获取单元301还用于从所述预设存储区中获取被第三标识标记的信息，将所述被第三标识标记的信息确定为请求信息，并向所述测试接口发送所述请求信息；

所述将被第一标识标记的信息作为所述样本调用返回值，包括：

解析所述请求信息，若所述请求信息被所述第二标识标记，则从所述预设存储区中查找与所述请求信息具有相同第二标识的信息的集合；

从所述集合中获取被所述第一标识标记的信息，将所述被所述第一标识标记的信息确定为所述样本调用返回值。

在一些实施例中，比对单元303还用于若所述比对结果为所述第一处理结果以及所述第二处理结果相同，则确定所述测试接口的处理逻辑正常。

具体实施时，以上各个单元可以作为独立的实体来实现，也可以进行任意组合，作为同一或若干个实体来实现，以上各个单元的具体实施可参见前面的方法实施例，在此不再赘述。

由上可知，本申请实施例数据处理方法采用第一获取单元301当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；接口处理单元302通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；比对单元303比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；确定单元304，用于若比对结果为第一处理结果与第二处理结果不相同，则确定测试接口的处理逻辑异常。通过获取原始接口对请求信息进行处理得到的调用返回值，并将调用返回值发送至测试接口进行处理的方式，确保测试接口与原始接口获取到的调用返回值一致，进而确定测试接口的处理逻辑是否存在问题。

参考图4，本申请实施例提供了一种服务器800，可以包括一个或者一个以上处理核心的处理器801、一个或一个以上计算机可读存储介质的存储器802、射频(RadioFrequency，RF)电路803、电源804、输入单元805、以及显示单元806等部件。本领域技术人员可以理解，图4中示出的服务器结构并不构成对服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器801是该服务器的控制中心，利用各种接口和线路连接整个服务器的各个部分，通过运行或执行存储在存储器802内的软件程序和/或模块，以及调用存储在存储器802内的数据，执行服务器的各种功能和处理数据，从而对服务器进行整体监控。可选的，处理器801可包括一个或多个处理核心；优选的，处理器801可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器801中。

存储器802可用于存储软件程序以及模块，处理器801通过运行存储在存储器802的软件程序以及模块，从而执行各种功能应用以及数据处理。

RF电路803可用于收发信息过程中，信号的接收和发送。

服务器还包括给各个部件供电的电源804(比如电池)，优选的，电源可以通过电源管理系统与处理器801逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

该服务器还可包括输入单元805，该输入单元805可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

该服务器还可包括显示单元806，该显示单元806可用于显示由用户输入的信息或提供给用户的信息以及服务器的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。具体在本实施例中，服务器中的处理器801会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器802中，并由处理器801来运行存储在存储器802中的应用程序，从而实现各种功能，如下：

当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；若所述比对结果为所述第一处理结果以及所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。

由上可知，本申请实施例服务器可以当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；比对所述第一处理结果和第二处理结果，得到比较结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；若所述比对结果为所述第一处理结果以及所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。通过获取原始接口对请求信息进行处理得到的调用返回值，并将调用返回值发送至测试接口进行处理的方式，确保测试接口与原始接口获取到的调用返回值一致，进而确定测试接口的处理逻辑是否存在问题。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，RandomAccess Memory)、磁盘或光盘等。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

以上对本申请实施例所提供的一种接口处理逻辑的测试方法、装置、存储介质及移动终端进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的技术方案及其核心思想；本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例的技术方案的范围。

Claims (10)

1.一种接口处理逻辑的测试方法，其特征在于，包括：

当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；

通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；

比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；

若所述比对结果为所述第一处理结果与所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。

2.根据权利要求1所述的接口处理逻辑的测试方法，其特征在于，在所述检测到测试指令之前，还包括：

拦截用户端设备发送的请求信息；

控制原始接口根据所述请求信息调用目标组件获取目标调用返回值；

所述获取样本调用返回值，包括：

将所述目标调用返回值作为样本调用返回值。

3.根据权利要求2所述的接口处理逻辑的测试方法，其特征在于，在所述比对所述第一处理结果和第二处理结果之前，还包括：

控制所述原始接口对所述目标调用返回值进行处理，得到第二处理结果。

4.根据权利要求1所述的接口处理逻辑的测试方法，其特征在于，在所述检测到测试指令之前，还包括：

拦截用户端设备发送的请求信息；

控制原始接口根据所述请求信息调用目标组件获取对应的调用返回值；

基于第一标识对获取的调用返回值进行标记；

将标记后的调用返回值存储至预设存储区中；

所述获取样本调用返回值，包括：

从所述预设存储区中获取被第一标识标记的信息；

将被第一标识标记的信息作为所述样本调用返回值。

5.根据权利要求4所述的接口处理逻辑的测试方法，其特征在于，在所述拦截用户端设备发送的请求信息之后，还包括：

基于第二标识对所述请求信息进行标记；

将标记后的请求信息存储至预设存储区中；

在所述将标记后的调用返回值存储至预设存储区中之后，还包括：

基于第二标识对获取的调用返回值进行标记。

6.根据权利要求5所述的接口处理逻辑的测试方法，其特征在于，在所述基于第二标识对所述请求信息进行标记之后，还包括：

基于第三标识对所述请求信息进行标记；

所述获取样本调用返回值之前，还包括：

从所述预设存储区中获取被第三标识标记的信息，将所述被第三标识标记的信息确定为请求信息，并向所述测试接口发送所述请求信息；

所述将被第一标识标记的信息作为所述样本调用返回值，包括：

解析所述请求信息，从所述预设存储区中查找与所述请求信息具有相同第二标识的信息的集合；

从所述集合中获取被所述第一标识标记的信息，将所述被所述第一标识标记的信息确定为所述样本调用返回值。

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

若所述比对结果为所述第一处理结果与所述第二处理结果相同，则确定所述测试接口的处理逻辑正常。

8.一种接口处理逻辑的测试装置，其特征在于，包括：

第一获取单元。用于当检测到测试指令时，获取样本调用返回值，所述样本调用返回值为业务平台中原始接口根据用户端设备发送的请求信息调用目标组件获取的值；

接口处理单元，用于通过测试接口对所述样本调用返回值进行处理，得到第一处理结果；

比对单元，用于比对所述第一处理结果和第二处理结果，得到比对结果，其中，所述第二处理结果为所述原始接口对所述样本调用返回值进行处理得到的结果；

确定单元，用于若所述比对结果为所述第一处理结果与所述第二处理结果不相同，则确定所述测试接口的处理逻辑异常。

9.根据权利要求8所述的接口处理逻辑的测试装置，其特征在于，所述接口处理逻辑的测试装置，还包括：

拦截单元，用于拦截用户端设备发送的请求信息；

第二获取单元，用于控制原始接口根据所述请求信息调用目标组件获取目标调用返回值；

所述第一获取单元，用于将所述目标调用返回值作为样本调用返回值。

10.根据权利要求8所述的接口处理逻辑的测试装置，其特征在于，所述接口处理逻辑的测试装置，还包括：

控制单元，用于控制所述原始接口对所述目标调用返回值进行处理，得到第二处理结果。

Images