CN115454400A - 接口参数的处理方法、装置、设备、介质及程序产品 - Google Patents

Abstract

本申请提供一种接口参数的处理方法、装置、设备、介质及程序产品，该方法包括：终端设备响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识，根据操作通过目标接口与服务器进行数据交互，获取数据交互过程中目标接口的接口参数，将接口参数与目标控件标识进行关联，生成关联信息，该关联信息用于指示目标控件标识对应的接口参数。该技术方案避免了由于设置的事件类型不全面导致的获取接口参数不完整的问题，节约了人力成本。此外，若目标应用程序不与后端服务器进行数据交互则不进行数据采集处理，提高了获取接口参数的准确性。

Description

接口参数的处理方法、装置、设备、介质及程序产品

技术领域

本申请涉及金融科技技术领域，尤其涉及一种接口参数的处理方法、装置、设备、介质及程序产品。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技转变。示例性的，银行业将过往传统银行的线下金融相关业务转化为手机线上应用来满足用户的需求，从而为用户提供便利。

在线上应用业务丰富度和复杂度日渐增大的背景下，开发人员以及测试人员需要关注不同用户行为触发的一个或多个接口对应的接口参数，以使通过该接口参数确定该线上应用与服务器通讯是否存在问题，来保证线上应用的可靠性、正确性以及安全性。目前，主要是通过查看上报的用户行为埋点数据，根据该用户行为埋点数据分析用户访问了什么页面，点击了什么页面元素，对应的业务场景，再去分析对应的接口调用情况，从而达到获取该用户行为对应的接口参数的目的。

然而，现有技术中存在获取接口参数的完整性以及准确性较低的问题。

发明内容

本申请提供一种接口参数的处理方法、装置、设备、介质及程序产品，以解决现有技术中获取接口参数的完整性以及准确性较低的问题。

第一方面，本申请实施例提供一种接口参数的处理方法，包括：

响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识；

根据所述操作通过目标接口与服务器进行数据交互，获取数据交互过程中所述目标接口的接口参数；

将所述接口参数与所述目标控件标识进行关联，生成关联信息，所述关联信息用于指示所述目标控件标识对应的所述接口参数。

在第一方面的一种可能设计中，所述根据所述操作通过目标接口与服务器进行数据交互，获取数据交互过程中所述目标接口的接口参数，包括：

当所述目标控件用于通过所述目标接口与所述服务器进行数据交互时，根据所述操作通过所述目标接口与所述服务器进行数据交互；

通过扦插在所述目标控件中的接口参数收集器收集数据交互过程中所述目标接口的接口参数。

可选的，所述响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识之后，所述方法还包括：

将所述接口参数收集器的状态更改为待激活；

相应的，在所述当所述目标控件用于通过所述目标接口与所述服务器进行数据交互时，根据所述操作通过所述目标接口与所述服务器进行数据交互之前，所述方法还包括：

将所述接口参数收集器的状态更改为收集中；

相应的，所述通过扦插在所述目标控件中的接口参数收集器收集数据交互过程中所述目标接口的接口参数，包括：

当通过所述目标接口向所述服务器发送请求时，通过所述接口参数收集器将所述目标接口的请求参数推送至记录栈；

当通过所述目标接口接收所述服务器返回的数据时，通过所述接口参数收集器将所述目标接口的响应参数推送至所述记录栈，所述请求参数以及所述响应参数为所述目标接口的接口参数；

将所述接口参数收集器的状态更改为收集结束。

可选的，在所述将所述接口参数收集器的状态更改为收集中之前，所述方法还包括：

删除所述记录栈中存储的历史接口参数。

在第一方面的另一种可能设计中，在所述将所述接口参数与所述目标控件标识进行关联，生成关联信息之后，所述方法还包括：

针对所述目标接口，获取触发所述目标接口的多个控件；

根据所述多个控件中的各控件的关联信息，生成目标接口信息，所述目标接口信息用于表示所述多个控件中各控件对应的接口参数和业务场景。

在第一方面的再一种可能设计中，所述响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识，包括：

响应于所述用户针对所述目标应用程序中所述目标控件的操作，确定所述目标控件所在的页面路由；

确定所述目标控件所在的页面控件区标识；

根据所述目标控件的初始标识、所述页面路由以及所述页面控件区标识，生成所述目标控件标识。

第二方面，本申请实施例提供一种接口参数的处理装置，包括：

生成模块，用于响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识；

获取模块，用于根据所述操作通过目标接口与服务器进行数据交互，获取数据交互过程中所述目标接口的接口参数；

所述生成模块，还用于将所述接口参数与所述目标控件标识进行关联，生成关联信息，所述关联信息用于指示所述目标控件标识对应的所述接口参数。

在第二方面的一种可能设计中，所述生成模块，具体用于：

当所述目标控件用于通过所述目标接口与所述服务器进行数据交互时，根据所述操作通过所述目标接口与所述服务器进行数据交互；

通过扦插在所述目标控件中的接口参数收集器收集数据交互过程中所述目标接口的接口参数。

可选的，所述响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识之后，所述装置还包括：

处理模块，用于将所述接口参数收集器的状态更改为待激活；

相应的，在所述当所述目标控件用于通过所述目标接口与所述服务器进行数据交互时，根据所述操作通过所述目标接口与所述服务器进行数据交互之前，所述处理模块还用于：

将所述接口参数收集器的状态更改为收集中；

相应的，所述获取模块，具体用于：

当通过所述目标接口向所述服务器发送请求时，通过所述接口参数收集器将所述目标接口的请求参数推送至记录栈；

当通过所述目标接口接收所述服务器返回的数据时，通过所述接口参数收集器将所述目标接口的响应参数推送至所述记录栈，所述请求参数以及所述响应参数为所述目标接口的接口参数；

将所述接口参数收集器的状态更改为收集结束。

可选的，所述处理模块，还用于：

删除所述记录栈中存储的历史接口参数。

在第二方面的另一种可能设计中，在所述将所述接口参数与所述目标控件标识进行关联，生成关联信息之后，所述获取模块，还用于针对所述目标接口，获取触发所述目标接口的多个控件；

所述获取模块，还用于根据所述多个控件中的各控件的关联信息，生成目标接口信息，所述目标接口信息用于表示所述多个控件中各控件对应的接口参数和业务场景。

在第二方面的再一种可能设计中，所述生成模块具体用于：

响应于所述用户针对所述目标应用程序中所述目标控件的操作，确定所述目标控件所在的页面路由；

确定所述目标控件所在的页面控件区标识；

根据所述目标控件的初始标识、所述页面路由以及所述页面控件区标识，生成所述目标控件标识。

第三方面，本申请实施例提供一种终端设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序指令，所述处理器执行所述计算机程序指令时用于实现第一方面以及各可能设计提供的方法。

第四方面，本申请实施例可提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现第一方面以及各可能设计提供的方法。

第五方面，本申请实施例提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时用于实现第一方面以及各可能设计提供的方法。

本申请实施例提供的接口参数的处理方法、装置、设备、介质及程序产品，在该方法中，终端设备响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识，根据操作通过目标接口与服务器进行数据交互，获取数据交互过程中目标接口的接口参数，将接口参数与目标控件标识进行关联，生成关联信息，该关联信息用于指示目标控件标识对应的接口参数。在本技术方案中，可以根据用户对目标控件的操作获取对应的目标接口以及该目标接口的接口参数，无需事先设置事件类型，避免了由于设置的事件类型不全面导致的获取接口参数不完整的问题，节约了人力成本。此外，若目标应用程序不与后端服务器进行数据交互则不进行数据采集处理，提高了获取接口参数的准确性。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1为本申请实施例提供的图形用户界面实施例一的结构示意图；

图2为本申请实施例提供的接口参数的处理方法实施例一的流程示意图；

图3为本申请实施例提供的接口参数的处理方法实施例二的流程示意图；

图4为本申请实施例提供的接口参数的处理方法实施例三的流程示意图；

图5为本申请实施例提供的图形用户界面实施例二的结构示意图；

图6为本申请实施例提供的生成目标控件的初始标识的流程示意图；

图7为本申请实施例提供的接口参数的处理装置的结构示意图；

图8为本申请实施例提供的终端设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

在介绍本申请的实施例之前，首先对本申请实施例所涉及的名词进行解释：

全球广域网(Web)前端：一种Web页面，用于通过超文本标记语言(Hyper TextMarkup Language，HTML)、层叠样式表(Cascading Style Sheets，CSS)、JavaScript(一种具有函数优先的轻量级，解释型或即时编译型的编程语言，简称JS)以及衍生出来的各种技术、框架、解决方案，来实现互联网产品(如上述手机线上应用)的用户界面交互。

用户行为：指用户访问Web页面时，为了使用该Web页面的功能在该Web页面上进行的点击、滑动、输入等操作。

用户行为埋点：用户触发特定事件时将用户行为埋点数据进行上报的前端程序，特定事件包括点击事件、输入事件等。后端服务器可以通过上报的用户行为埋点数据确定用户在访问前端应用时实际发生的用户行为。

事件委托：在JavaScript中也称为事件托管或事件代理，就是把目标节点的事件绑定到祖先节点上，这样在事件传播过程中，目标节点的事件逐层冒泡总能被祖先节点捕获。

addEventListener：是文档对象模型(Document Object Model，DOM)接口的一个方法，用于将指定的监听器注册到目标元素上，当该目标元素触发指定的事件时，对应的回调函数就会被执行。

事件回调函数：是上述addEventListener方法的入参，用于指定某文档元素的某事件被触发后需要执行的事件处理逻辑。

接口：前后端通信需要协定特定的网络接口。

接口参数：前端通过发送接口请求将参数提交给后台，后台处理完业务逻辑后将结果参数响应给前端。前端提交的参数数据结构和后台返回的参数数据结构分别称为该接口的请求参数和响应参数。

接口元数据：是描述数据属性的数据，如描述接口请求参数的类型、枚举值等属性，接口元数据可以组成详细的接口文档。

XMLHTTPRequest(XHR)：浏览器提供的一个对象，在JavaScript中客户端可以通过该对象上的方法与服务器进行网络通信。

本申请具体的应用场景如下：银行业通过广泛流行的服务端-客户端架构，将过往传统银行的线下金融相关业务转化为手机线上应用来满足用户的需求。其中，上述架构中的服务端可以理解为后端，客户端可以理解为前端。

在线上应用中，大量的金融业务流程的展开，是通过前端页面与用户的交互来实现的，前端页面元素替代了原有线下服务厅的人工服务。用户在前端页面的用户行为决定了用户当前希望获得的金融业务服务是什么，对应的是不同的服务端-客户端接口参数。在线上应用业务丰富度和复杂度日渐增大的背景下，开发人员和测试人员不仅仅应该关注单一的接口通讯，还需要关注及分析在同一系统或者具体到同一前端页面中，不同的用户行为触发的一个或多个接口对应的请求参数和响应参数的正确组合，来保证线上应用的可靠性、正确性、安全性。

假如开发人员或者测试人员需要去分析线上应用中的一些具体业务行为会触发哪些对应的接口和接口参数时，比如，技术人员需要获知用户在银行应用中的“去还款”的这个业务行为对应了哪些接口和接口参数，可以通过查看上报的用户行为埋点数据，分析用户访问了什么页面，点击了什么页面元素，代表了是什么业务场景，再去分析对应的接口调用情况。

然而，上述方法存在以下问题：

(1)、收集到的用户行为埋点数据是单点式的，一个埋点数据往往只代表用户的某个单一动作。比如，确认按钮的点击行为埋点，代表的是用户点击了这个按钮。但是埋点之间没有关联关系，并且埋点与接口调用之间也没有关联关系，所以无法进行一个业务场景式的接口与接口参数的串联关系分析。

(2)、现主流的埋点收集是事件委托收集，需要提前定义收集的事件类型，比如定义上报事件类型枚举可以为：点击事件(CLICK)、聚焦事件(FOCUS)、失焦事件(BLUR)等。但是接口触发的时机可能不在这些提前定义的事件类型中，比如可能有些接口是页面滚动时触发的，但页面滚动事件没有在上述事件类型的列表中，获取接口参数的过程中可能会发生遗漏，存在获取接口参数的完整性较低的问题。

(3)、事件委托收集是对数据进行全监听全收集，在数据收集过程中会收集到很多不相干的数据，存在收集接口参数的准确性较低的问题。

综上所述，现有技术获取的接口参数之间割裂无关联性，数据零散，存在获取接口参数的完整性以及准确性较低的问题，从而导致后续根据该接口参数进行分析处理的困难度较高、效率较低。技术人员想要根据获取的接口参数统计分析一些具体的用户行为会触发怎样一系列的接口，以及这些接口的请求参数在不同行为下的差异性是十分困难的。

针对上述问题，本申请的发明构思如下：逻辑处理型元素在前端程序(也就是上述线上应用)中都需要通过JavaScript的注册事件程序addEventListener来给该元素注册相关事件的回调函数。基于此，可以在利用前端程序调用addEventListener来进行添加某一个事件的监听器时，在事件执行中扦插定义一个逻辑，该逻辑用于在该元素用于与后端交互时，采集交互过程中的各接口的接口参数，并将该接口参数与元素的唯一标识进行关联，通过该逻辑就能够获取不同元素对应的接口数据。这样，无需事先定义事件类型，且前端只有在与后端进行数据交互时才会采集接口参数，从而提高获取接口参数的完整性以及效率。

示例性的，本申请实施例提供的接口参数的处理方法可以应用于图1所示的图形用户界面图中。图1为本申请实施例提供的图形用户界面实施例一的结构示意图。

为了实现对前端页面的业务场景分析，需要定位到用户触发业务流程的起点。例如，判断用户是否触发了目标应用程序中的目标控件，以及识别该目标控件对应的业务。

但是，用户在前端应用上的操作有以下特征：无序性、发散性以及随机性。举例来说，用户可能会点击页面上的任意的元素，也可能在任何一个时间节点关闭页面终止程序。然而，并不是所有元素都是引发业务流程流转的关键元素，比如有些元素只是一个静态图片展示，而用户只是出于个人行为点击了静态图片。虽然用户确实是进行了点击行为，但是这个行为没有触发任何接口请求和数据交互。所以这种行为在本发明关注的接口以及接口参数统计的领域里面，可以认为是用户的无意义行为。

因此，在本实施例中，将图形用户界面中的各元素划分为逻辑处理型元素以及展示型元素。如图1所示，该图形用户界面通过应用程序或者浏览器在终端设备的触摸显示屏中进行显示，该图像用户界面包括逻辑处理型元素以及展示型元素。

其中，逻辑处理型元素是绑定了事件回调函数的元素，图1上半部分虚线框中的四个按钮(圆形)即为逻辑处理型元素，它们可以是四个功能入口，分别绑定了点击事件或者其他事件，用户操作后会触发对应的事件处理逻辑，一般是请求接口和页面跳转。

展示型元素为没有绑定事件回调函数的元素，图1下半部分虚线框内的区域即为逻辑处理型元素，可能是一段文案描述或者图标展示，以供用户浏览静态信息，没有绑定可点击等相关事件处理逻辑，也就没有可交互性。

也就是说，展示型元素和逻辑处理型元素的区别在于有没有绑定事件处理逻辑，有事件处理逻辑且逻辑中有进行接口请求的元素则可以认为是一个有效用户行为的元素，是一个业务流程的触发起点。

在本实施例中，在用户点击图形用户界面上的按钮时，若该按钮为逻辑处理型元素，则执行接口参数的处理方法的程序代码，收集与后端服务器交互过程中的各接口的接口参数，将该按钮标识与该接口参数进行关联，并触发该按钮对应的事件处理逻辑。

可以理解的是，本申请实施例的执行主体是终端设备，例如，计算机、平板电脑、智能手机等，可以根据实际情况而定，本申请实施例不对终端设备的类型进行具体限制。

下面，通过具体实施例对本申请的技术方案进行详细说明。

需要说明的是，下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本申请实施例提供的接口参数的处理方法实施例一的流程示意图。如图2所示，该接口参数的处理方法可以包括如下步骤：

S201、响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识。

在本申请实施例中，目标应用程序用于显示图形用户界面，该图形用户界面中包括多个控件，以使为用户提供不同的业务。也就是说，不同控件对应于不同的业务场景。

可选的，图形用户界面可以包括多个页面控件区，不同页面控件区中的控件可以是相同的，也可以是不同的。可以响应于用户针对目标应用程序中目标控件的操作，根据目标控件所在的页面路由、页面控件区标识以及该目标控件的初始标识，确定目标控件标识。

其中，该操作可以为用户对终端设备的触摸显示屏的触控操作，还可以是用户对终端设备的语音输入操作。示例性的，该操作可以为用户对目标应用程序中的目标控件的点击操作，还可以是用户发送语音“打开A应用程序的B功能”的语音输入操作，本申请不对上述操作的类型进行具体限制。

示例性的，目标控件即为上述逻辑处理型元素，可以为按钮，还可以为其他类型的控件，本申请实施例不对目标控件的类型进行具体限制。

S202、根据操作通过目标接口与服务器进行数据交互，获取数据交互过程中目标接口的接口参数。

其中，上述接口参数包括请求参数和响应参数。

可选的，在获取数据交互过程中的目标接口的接口参数后，还可以执行该目标接口对应的事件处理逻辑。

S203、将接口参数与目标控件标识进行关联，生成关联信息。

其中，关联信息用于指示目标控件标识对应的接口参数。

示例性的，该关联信息可以通过表1进行表示。

表1

如表1所示，假设目标控件标识为page1NavBtn2，该目标控件关联的接口标识分别为/api/d、/api/e以及/api/f，/api/d的接口参数为request body-d和response body-d，/api/e的接口参数为request body-e和response body-e，/api/f的接口参数为requestbody-f和response body-f。

本申请实施例提供的接口参数的处理方法，终端设备响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识，根据操作通过目标接口与服务器进行数据交互，获取数据交互过程中目标接口的接口参数，将接口参数与目标控件标识进行关联，生成关联信息，该关联信息用于指示目标控件标识对应的接口参数。在本技术方案中，可以根据用户对目标控件的操作获取对应的目标接口以及该目标接口的接口参数，无需事先设置事件类型和手动编写目标控件标识，避免了由于设置的事件类型不全面导致的获取接口参数不完整的问题，达到了全事件收集，节约了人力成本。此外，若目标应用程序不与后端服务器进行数据交互则不进行数据采集处理，提高了获取接口参数的准确性和效率。此外，本申请可以对代码无侵入，在与服务器进行数据交互过程中接口参数进行拦截，不影响前端应用功能。

现有技术中，后端开发者会编写和维护接口文档，该接口文档用于说明接口的请求参数和响应参数的定义，但接口文档中无法描述各参数对前端页面的哪些元素交互产生影响，也就是说相关技术人员无法从接口文档中的接口元数据中获得接口应用的业务场景的相关定义，或者说无法从接口元数据(此处接口元数据主要是列举接口地址、参数字段名称类型定义、字段含义描述以及字段枚举值)中得知该接口或者该入参用于什么业务流程，存在用户行为与接口参数之间无法对应的问题。例如，后台程序开发者无法在接口文档中说明什么情况下请求参数的值会不一样，因为请求参数的差异性是由用户在不同页面不同操作下引发的。而这个用户行为输入维度的缺失，会导致后台开发者和测试人员，无法明确参数的使用是否正常。后端开发者在排查问题时，无法从用户提供的前端故障页面，快速定位到出现问题的接口和接口参数。而在本方案中，在获取接口参数后会将该接口参数与目标控件标识进行关联，从而能够获取不同业务场景下对应的接口参数，便于后续能够根据故障控件标识准确定位到对应的接口以及接口数据。

可选的，在一些实施例中，结合图2所示的实施例，对202进行详细介绍，上述S202可以通过以下步骤实现：

当目标控件用于通过目标接口与服务器进行数据交互时，根据操作通过目标接口与服务器进行数据交互，并通过扦插在目标控件中的接口参数收集器收集数据交互过程中目标接口的接口参数。

示例性的，可以通过下述伪代码实现接口参数收集器。

如上述伪代码所示，可以将原来的浏览器window.EventTarget的addEventListener函数保存下来，并且命名为originAddEventListener。然后定义一个新的addEventListener函数，命名为newAddEventListener，之后在新函数中插入逻辑：判断当前是否命中了数据交互标记(也就是判断目标控件是否用于与服务器进行数据交互)，并且插入收集逻辑(也就是接口参数收集器)。在通过接口参数收集器收集数据交互过程中目标接口的接口参数后，还可以调用原有的逻辑originAddEventListener实现目标控件的事件处理逻辑。

其中，上述伪代码中的eventName为目标控件标识。

在前端应用中，前端程序一般使用XMLHTTPRequest对象实例进行网络交互，实现与服务端通信。XMLHTTPRequest对象提供了open、send以及onreadystatechange等方法，分别用于初始化一个请求、发送请求以及监听readyState。在请求属性发生变化时，就会调用相应的处理函数。

本发明针对浏览器的XMLHTTPRequest对象设置了代理器，实现了在通信的发出请求和接收响应节点进行数据截取接口参数的目的。

示例性的，可以通过下述伪代码实现代理器。

如上述伪代码所示，将原来的window.XMLHttpRequest对象保存下来，并且命名为orginXHR。然后定义一个新的newXHR函数，代理XMLHttpRequest的open、send以及onreadystatechange等方法，此函数内会判断当前网络请求处理流程是处于发送请求状态，还是处于接受响应状态。然后针对两种的状态根据接口参数收集器的指令做出对应的参数记录。

现有技术还可以通过提前设计某个业务场景的操作路径，根据这个操作路径人工操作前端页面，记下真实操作后触发的接口和参数的调用情况来获取接口数据。然而，该方法的人力成本较高，且依赖于后置分析法。后置分析法指的是在系统应用开发完成进入交付阶段后，再通过实际操作去分析接口调用时序。但后置分析法无法应对快速迭代的功能需求，分析报告使用期限的可持续性会有很大限制，几个开发版本迭代后，分析报告就可能不再适用最新的业务逻辑。而在本实施例中，无论系统如何迭代，都可以通过扦插在目标控件中的接口参数收集器收集数据交互过程中目标接口的接口参数，提高了本方案的兼容性。

可选的，在一些实施例中，结合图2所示的实施例，在S201之后，该接口参数的处理方法还可以包括如下步骤：

将接口参数收集器的状态更改为待激活。

相应的，在当目标控件用于通过目标接口与服务器进行数据交互时，根据操作通过目标接口与服务器进行数据交互之前，该接口参数的处理方法还可以包括如下步骤：

将接口参数收集器的状态更改为收集中。

相应的，通过扦插在目标控件中的接口参数收集器收集数据交互过程中目标接口的接口参数，可以根据以下步骤实现：

当通过目标接口向服务器发送请求时，通过接口参数收集器将目标接口的请求参数推送至记录栈。

当通过目标接口接收服务器返回的数据时，通过接口参数收集器将目标接口的响应参数推送至记录栈，请求参数以及响应参数为目标接口的接口参数。

将接口参数收集器的状态更改为收集结束。

为了更好的说明本实施例，接下来通过一个具体的示例进行展开说明。

步骤a、响应于用户对按钮的点击操作，将接口参数收集器状态设置为待激活。

步骤b、检查用户当前触发事件的元素(也就是步骤a中的按钮)的事件处理逻辑中是否涉及与后台进行接口通讯。

步骤c、如果涉及与后台进行接口通讯，则将当前接口参数收集器的状态更改为收集中，并生成目标控件标识；假设不涉及与后台进行接口通讯，则不进行任何处理。

步骤d、当通过目标接口向服务器发送请求时，通过接口参数收集器将目标接口的请求参数推送至记录栈。

步骤e、当通过目标接口接收服务器返回的数据时，通过接口参数收集器将目标接口的响应参数推送至记录栈。

步骤f、将接口参数收集器的状态更改为收集结束。

步骤g、将接口参数与目标控件标识进行关联，生成关联信息，并触发原有的事件回调函数，进行原有的事件处理逻辑。

在本示例中，在通过目标接口向服务器发送请求时，可以代理XMLHTTPRequest对象的open函数，在前端程序使用open函数初始化请求的时候，检测当前接口参数收集器状态；还可以代理XMLHTTPRequest对象的onreadystatechange函数，在接收到服务端返回的响应参数时，判断当前的接口参数收集器状态是否处于收集中。

在上述实施例中，可以根据接口参数收集器状态采集接口参数，从而保证了采集到的接口参数的准确性。

可选的，在一些实施例中，在将接口参数收集器的状态更改为收集中之前，该接口参数的处理方法还可以包括如下步骤：

删除记录栈中存储的历史接口参数。

在上述实施例中，删除记录栈中存储的历史接口参数能够避免本次采集的接口参数中掺杂历史接口参数的问题，提高了采集接口参数的准确性。

接下来通过一个具体的示例，对接口参数的处理方案进行展开说明。

步骤1、在前端程序中，通过addEventListener定义“去还款按钮”的点击事件处理逻辑，事件处理逻辑定义为handleRepayBtnClick函数。

步骤2、定义以下内容：如果监听到用户点击了“去还款按钮”，那么前端程序就会执行handleRepayBtnClick函数。handleRepayBtnClick函数用于处理以下逻辑：发起借据列表信息获取接口，并且检查用户当前的账户状态是否正常，假如正常则跳转借据详情页面，展示“确认还款按钮”。

步骤3、在用户点击去“还款按钮”时，启动接口参数收集器，并将接口参数收集器状态更新为待激活。

步骤4、接口参数收集器判断到当前“去还款按钮”触发了接口调用，事件接口参数收集器状态从待激活更新为收集中，并且为“去还款按钮”生成目标控件标识，清空记录栈中的历史接口参数，结束上一次收集并且启动当前属于该目标控件标识的接口，进行接口参数记录。

步骤5、执行前端程序中的点击事件响应函数handleRepayBtnClick，调用XMLHttpRequest的open方法初始化借据列表信息获取接口的请求。

步骤6、通过接口参数收集器将接口请求地址和请求参数推送到记录栈中。

步骤7、向后端服务器发送接口请求，后端服务器处理接口请求，并返回响应数据。

步骤8、前端接收接口响应，接口状态发生变更，触发onreadystatechange方法，将响应参数推送到记录栈中。

步骤9、将接口参数与目标控件标识进行关联，生成关联信息。

步骤10、执行原有的事件处理逻辑handleRepayBtnClick函数，根据handleRepayBtnClick函数发起接口调用和页面跳转。

在该示例中，上述关联信息可以通过表2进行表示。

表2

可选的，终端设备可以包括行为数据采集层和接口数据代理层，行为数据采集层负责收集用户在前端应用中具体操作的控件和对应的事件，接口数据代理层负责在前后端数据通信过程中拦截数据，采集接口数据。在前端程序中，这两层架构相互配合，来实现将用户使用的业务场景标记到接口元数据中的目的。

图3为本申请实施例提供的接口参数的处理方法实施例二的流程示意图。如图3所示，用户点击目标控件触发点击事件，行为数据采集层判断目标控件是否用于与服务器进行数据交互，若是，则生成目标控件标识，并向接口数据代理层发送数据请求，接口数据代理层通过请求代理将该数据请求转发至服务器，并采集接口数据的请求参数部分数据。服务器对数据请求进行处理，将处理得到的数据响应发送给终端设备。终端设备通过接口数据代理层的响应代理将该数据响应发送至图形用户界面，以便于后续处理，并采集接口数据的响应参数部分数据。

可选的，在一些实施例中，在S203之后，该接口参数的处理方法还可以包括如下步骤：

针对目标接口，获取触发目标接口的多个控件；并根据多个控件中的各控件的关联信息，生成目标接口信息。其中，目标接口信息用于表示多个控件中各控件对应的接口参数和业务场景。

可选的，本步骤可以通过终端设备的数据处理层实现，数据处理层根据多个控件中的各控件的关联信息，进行数据清洗和过滤，得到一份有具体用户操作输入的多维接口元数据文档，该文档即为目标接口信息。进一步的，该数据处理层还可以将上述目标接口信息发送至数据中心。

为了更清楚的对本步骤进行说明，接下来通过一个具体的示例进行解释说明。

示例性的，多个控件中的各控件的请求参数可以通过表3进行表示。

表3

如表3所示，“去还款按钮”用户行为触发时，接口数据请求列表应包含：/info/receiptList借据列表、/user/checkStatus用户状态检查、/info/advert广告信息查询。由此可得，确定前端应用“去还款按钮”的用户行为对应的前后端系统间通信接口列表及其接口参数，有益于后台开发者和测试人员分析和解决问题。

示例性的，在表3的基础上，以用户状态接口为例进行举例说明，用户状态接口的目标接口信息可以通过表4进行表示。

表4

如表4所示，该目标接口信息可以直观得到用户状态接口对应到的用户操作行为汇总，以及不同用户操作行为对应的接口参数。如上表所列举的，用户状态检查接口会在去还款、去借款这两个前端业务场景中被调用，而且用户状态接口的同个参数对应不同用户行为，如otpType的不同枚举值对应的用户事件行为：otpType为repay时对应的是用户去还款，而otpType为loan时对应的是用户去借款。

现有技术中，交互设计师会提供交互设计稿，以展现应用的所有业务流程，定义所有用户行为对应的页面和页面元素。但是交互设计稿无法说明和枚举页面中元素展示与否、样式差异、信息差异，这些关键信息的差异性导致的接口参数差异性是什么，存在页面设计和接口参数无法对应的问题。因此，交互设计稿也无法作为测试人员等技术人员检查接口参数是否正确的文档依据。而在本实施例中，使用特定算法生成目标接口信息，以统计不同用户行为变化下前端应用发出的请求接口以及请求参数的差异。为前后端系统间数据通讯管理提供了用户触发行为的分析维度，优化了当前的前后端接口元数据对于请求参数和响应参数的定义缺失了具体使用场景的问题，便于后台开发人员和测试人员检查接口数据和确认程序运行的正确性。提高各技术人员角色的工作效率。

可选的，图4为本申请实施例提供的接口参数的处理方法实施例三的流程示意图。如图4所示，终端包括接口数据代理层、行为数据采集层以及关联数据处理层。接口数据代理层向行为数据采集层发送接口请求，行为数据采集层向服务器发送该接口请求并采集请求参数。服务器根据接口请求进行处理，生成接口响应，并将该接口响应发送给终端。行为数据采集层接收接口响应，将该接口响应转发至接口数据代理层，并采集响应参数。进一步的，行为数据采集层将目标控件标识与接口参数进行关联，生成关联信息并发送至关联数据处理层。关联数据处理层根据多个控件中的各控件的关联信息，生成目标接口信息，并将该目标接口信息发送至数据中心。

可选的，在一些实施例中，S201可以通过以下步骤实现：

响应于用户针对目标应用程序中目标控件的操作，确定目标控件所在的页面路由；之后确定目标控件所在的页面控件区标识，最后根据目标控件的初始标识、页面路由以及页面控件区标识，生成目标控件标识。

可选的，图5为本申请实施例提供的图形用户界面实施例二的结构示意图。如图5所示，目标控件所在的页面路由为/home，页面控件区标识为btnList，目标控件的初始标识为repayBtn，将目标控件的初始标识、页面路由以及页面控件区标识进行拼接，从而得到目标控件标识(eventId)：home_btnList_repayBtn。其中，目标控件标识用于唯一识别该目标控件以及该目标控件对应的业务流程。

可选的，图6为本申请实施例提供的生成目标控件的初始标识的流程示意图。如图6所示，生成目标控件的初始标识可以通过一下步骤实现：

步骤1、判断是否有ID属性，若有则返回ID，并执行步骤4；若无则执行步骤2。

步骤2、判断是否有CLASS属性，若有则返回CLASS，并执行步骤4；若无则执行步骤3。

步骤3、返回元素类型，并执行步骤4。

步骤4、判断是否包含文字节点，若有则返回元素文案，并执行步骤7；若无则执行步骤5。

步骤5、判断是否包含name节点，若有则返回name属性值，并执行步骤7；若无则执行步骤6。

步骤6、判断是否包含attr节点，若有则返回attr属性值，若无则返回空，并执行步骤7。

步骤7、生成目标控件的初始标识。

可选的，生成页面控件区标识的方式和原理可以参照图6所示的实施例，此处不再赘述。

在上述实施例中，根据目标控件的初始标识、页面路由以及页面控件区标识，能够生成用于唯一识别目标控件的目标控件标识，从而提高后续获取关联信息以及目标接口信息的准确性。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图7为本申请实施例提供的接口参数的处理装置的结构示意图。如图7所示，该接口参数的处理装置包括：

生成模块81，用于响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识；

获取模块82，用于根据操作通过目标接口与服务器进行数据交互，获取数据交互过程中目标接口的接口参数；

生成模块81，还用于将接口参数与目标控件标识进行关联，生成关联信息，关联信息用于指示目标控件标识对应的接口参数。

在本申请实施例的一种可能设计中，生成模块81，具体用于：

当目标控件用于通过目标接口与服务器进行数据交互时，根据操作通过目标接口与服务器进行数据交互；

通过扦插在目标控件中的接口参数收集器收集数据交互过程中目标接口的接口参数。

可选的，响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识之后，该装置还包括：

处理模块，用于将接口参数收集器的状态更改为待激活；

相应的，在当目标控件用于通过目标接口与服务器进行数据交互时，根据操作通过目标接口与服务器进行数据交互之前，处理模块还用于：

将接口参数收集器的状态更改为收集中；

相应的，获取模块82，具体用于：

当通过目标接口向服务器发送请求时，通过接口参数收集器将目标接口的请求参数推送至记录栈；

当通过目标接口接收服务器返回的数据时，通过接口参数收集器将目标接口的响应参数推送至记录栈，请求参数以及响应参数为目标接口的接口参数；

将接口参数收集器的状态更改为收集结束。

可选的，处理模块，还用于：

删除记录栈中存储的历史接口参数。

在本申请实施例的另一种可能设计中，在将接口参数与目标控件标识进行关联，生成关联信息之后，获取模块82，还用于针对目标接口，获取触发目标接口的多个控件；

获取模块82，还用于根据多个控件中的各控件的关联信息，生成目标接口信息，目标接口信息用于表示多个控件中各控件对应的接口参数和业务场景。

在本申请实施例的再一种可能设计中，生成模块81具体用于：

响应于用户针对目标应用程序中目标控件的操作，确定目标控件所在的页面路由；

确定目标控件所在的页面控件区标识；

根据目标控件的初始标识、页面路由以及页面控件区标识，生成目标控件标识。

本申请实施例提供的接口参数的处理装置，可用于执行上述任一实施例中的接口参数的处理方法，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。此外，这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

图8为本申请实施例提供的终端设备的结构示意图。如图8所示，该终端设备可以包括：处理器91、存储器92及存储在所述存储器92上并可在处理器91上运行的计算机程序指令，所述处理器91执行所述计算机程序指令时实现前述任一实施例提供的接口参数的处理方法。

可选的，该终端设备的上述各个器件之间可以通过系统总线连接。

存储器92可以是单独的存储单元，也可以是集成在处理器中的存储单元。处理器的数量为一个或者多个。

可选的，终端设备还可以包括与其他设备进行交互的接口。

可选的，终端设备还可以包括显示器。

显示器用于显示处理器91的处理结果以及和人机交互。可选的，在一些实施例中，显示器可以为终端设备的前面板；在另一些实施例中，显示器可以是柔性显示屏，设置在终端设备的弯曲表面上或折叠面上。甚至，显示器还可以设置成非矩形的不规则图形的显示屏，也即异形屏。显示器可以采用液晶显示屏(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode，OLED)等材质制备。

应理解，处理器91可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

系统总线可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。存储器可能包括随机存取存储器(randomaccess memory，RAM)，也可能还包括非易失性存储器(non-volatile memory，NVM)，例如至少一个磁盘存储器。

实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一可读取存储器中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储器(存储介质)包括：只读存储器(read-only memory，ROM)、RAM、快闪存储器、硬盘、固态硬盘、磁带(英文：magnetic tape)、软盘(英文：floppy disk)、光盘(英文：optical disc)及其任意组合。

本申请实施例提供的终端设备，可用于执行上述任一方法实施例提供的接口参数的处理方法，其实现原理和技术效果类似，在此不再赘述。

本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，当该计算机执行指令在计算机上运行时，使得计算机执行上述接口参数的处理方法。

上述的计算机可读存储介质，上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器，电可擦除可编程只读存储器，可擦除可编程只读存储器，可编程只读存储器，只读存储器，磁存储器，快闪存储器，磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。

可选的，将可读存储介质耦合至处理器，从而使处理器能够从该可读存储介质读取信息，且可向该可读存储介质写入信息。当然，可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits，ASIC)中。当然，处理器和可读存储介质也可以作为分立组件存在于设备中。

本申请实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中，至少一个处理器可以从该计算机可读存储介质中读取该计算机程序，所述至少一个处理器执行所述计算机程序时可实现上述接口参数的处理方法。

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

Claims (10)

1.一种接口参数的处理方法，其特征在于，包括：

响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识；

根据所述操作通过目标接口与服务器进行数据交互，获取数据交互过程中所述目标接口的接口参数；

将所述接口参数与所述目标控件标识进行关联，生成关联信息，所述关联信息用于指示所述目标控件标识对应的所述接口参数。

2.根据权利要求1所述的方法，其特征在于，所述根据所述操作通过目标接口与服务器进行数据交互，获取数据交互过程中所述目标接口的接口参数，包括：

当所述目标控件用于通过所述目标接口与所述服务器进行数据交互时，根据所述操作通过所述目标接口与所述服务器进行数据交互；

通过扦插在所述目标控件中的接口参数收集器收集数据交互过程中所述目标接口的接口参数。

3.根据权利要求2所述的方法，其特征在于，所述响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识之后，所述方法还包括：

将所述接口参数收集器的状态更改为待激活；

相应的，在所述当所述目标控件用于通过所述目标接口与所述服务器进行数据交互时，根据所述操作通过所述目标接口与所述服务器进行数据交互之前，所述方法还包括：

将所述接口参数收集器的状态更改为收集中；

相应的，所述通过扦插在所述目标控件中的接口参数收集器收集数据交互过程中所述目标接口的接口参数，包括：

当通过所述目标接口向所述服务器发送请求时，通过所述接口参数收集器将所述目标接口的请求参数推送至记录栈；

当通过所述目标接口接收所述服务器返回的数据时，通过所述接口参数收集器将所述目标接口的响应参数推送至所述记录栈，所述请求参数以及所述响应参数为所述目标接口的接口参数；

将所述接口参数收集器的状态更改为收集结束。

4.根据权利要求3所述的方法，其特征在于，在所述将所述接口参数收集器的状态更改为收集中之前，所述方法还包括：

删除所述记录栈中存储的历史接口参数。

5.根据权利要求1至4任一项所述的方法，其特征在于，在所述将所述接口参数与所述目标控件标识进行关联，生成关联信息之后，所述方法还包括：

针对所述目标接口，获取触发所述目标接口的多个控件；

根据所述多个控件中的各控件的关联信息，生成目标接口信息，所述目标接口信息用于表示所述多个控件中各控件对应的接口参数和业务场景。

6.根据权利要求1至4任一项所述的方法，其特征在于，所述响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识，包括：

响应于所述用户针对所述目标应用程序中所述目标控件的操作，确定所述目标控件所在的页面路由；

确定所述目标控件所在的页面控件区标识；

根据所述目标控件的初始标识、所述页面路由以及所述页面控件区标识，生成所述目标控件标识。

7.一种接口参数的处理装置，其特征在于，包括：

生成模块，用于响应于用户针对目标应用程序中目标控件的操作，生成目标控件标识；

获取模块，用于根据所述操作通过目标接口与服务器进行数据交互，获取数据交互过程中所述目标接口的接口参数；

所述生成模块，还用于将所述接口参数与所述目标控件标识进行关联，生成关联信息，所述关联信息用于指示所述目标控件标识对应的所述接口参数。

8.一种终端设备，包括：处理器、存储器及存储在所述存储器上并可在处理器上运行的计算机程序指令，其特征在于，所述处理器执行所述计算机程序指令时用于实现如权利要求1至6任一项所述的接口参数的处理方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至6任一项所述的接口参数的处理方法。

10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时用于实现如权利要求1至6任一项所述的接口参数的处理方法。

Images