CN111831542A

CN111831542A - API application debugging method and device and storage medium

Info

Publication number: CN111831542A
Application number: CN201910328886.5A
Authority: CN
Inventors: 路国翠; 张磊; 陈晓明
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-04-23
Filing date: 2019-04-23
Publication date: 2020-10-27
Anticipated expiration: 2039-04-23
Also published as: CN111831542B

Abstract

The embodiment of the application discloses an API application debugging method and device and a storage medium, and belongs to the technical field of networks. The method comprises the following steps: acquiring a target debugging log, wherein the target debugging log is generated in the process of debugging a target API application, and the target API application is formed by arranging at least one API service; acquiring a target call log of a target API service from the target call log, wherein the target API service is any API service called in the process of testing the target API application; acquiring key information in a target call log; and presenting the key information. The method and the device for testing the API application help to solve the problem that the testing efficiency of the API application is low, and help to improve the testing efficiency of the API application. The embodiment of the application is used for API application debugging.

Description

API application debugging method and device and storage medium

Technical Field

The embodiment of the present application relates to the field of network technologies, and in particular, to an Application Programming Interface (API) application debugging method, device, and storage medium.

Background

In an internet cloud scenario, API orchestration refers to the process of orchestrating one or more API services into API applications using a specialized API management tool. The API service refers to a functional unit meeting specific requirements, and the API services arranged by the API have a certain sequence. After the API application is formed by the orchestration, the API application typically needs to be debugged.

Currently, the MuleSoft API deployment tool is typically used to debug API applications. The debugging process comprises the following steps: the MuleSoft API layout tool generates an API model according to a model code edited by a tester, calls an API service in the API application through interaction with an API gateway according to the API model to debug the API application, generates a debug log in the debugging process, acquires the debug log from the API gateway and displays the debug log in a text form, so that the tester manually analyzes the debug log to determine key information of the debug log (such as input information of the invoked API service, output information of the invoked API service, request information forwarded by the invoked API service, response information forwarded by the invoked API service, abnormal information and the like), and determines a problem point of API layout according to the key information of the debug log.

However, since manual analysis is inefficient, the API application is inefficient to debug.

Disclosure of Invention

The embodiment of the application provides an API application debugging method and device and a storage medium, and the API application debugging method and device and the storage medium are beneficial to improving the debugging efficiency of the API application. The technical scheme is as follows:

in a first aspect, a method for debugging an API application is provided, where the method includes:

acquiring a target debugging log, wherein the target debugging log is generated in the process of debugging a target API application, and the target API application is formed by arranging at least one API service; acquiring a target call log of a target API service from the target call log, wherein the target API service is any API service called in the process of testing the target API application; acquiring key information in a target call log; and presenting the key information.

According to the scheme provided by the embodiment of the application, the key information in the call log can be acquired and presented without manual analysis, so that the debugging efficiency of the API application is improved.

Optionally, obtaining a target call log of the target API service from the target call log includes: and acquiring a target call log from the association relationship between the called API service and the call log, wherein the association relationship between the called API service and the call log is established according to the target call log.

According to the scheme provided by the embodiment of the application, the target call log can be obtained from the association relation between the called API service and the call log, so that the target call log can be conveniently and quickly obtained.

Optionally, before obtaining the target call log from the association relationship between the called API service and the call log, the method further includes: determining the calling sequence of the API service in the target API application according to the target calling log; acquiring a call log of each called API service from a target call log; and establishing an association relation between the called API service and the call log according to each called API service and the corresponding call log.

According to the scheme provided by the embodiment of the application, before the target call log is acquired, the association relation between the called API service and the call log is established, so that the target call log can be acquired quickly.

Optionally, obtaining a call log of each called API service from the target call log includes: determining a characteristic label of each called API service, wherein the characteristic label comprises an identifier of the called API service and a tracking instance identifier for testing a target API application; and extracting the call logs of each called API service from the target call logs according to the feature tags of each called API service.

According to the scheme provided by the embodiment of the application, the call logs of the called API services can be extracted from the target call log in a characteristic label mode, so that the call logs of the called API services can be conveniently extracted.

Optionally, before obtaining the target call log of the target API service from the target call log, the method further includes:

determining the calling sequence of the API service in the target API application according to the target calling log;

presenting an API service calling track according to the calling sequence, wherein the API service calling track at least comprises primitives of the called API service and trajectory lines for connecting the primitives of at least two called API services according to the calling sequence, and the primitives of the API service indicate the API service;

obtaining a target call log of the target API service from the target call log, including: and when an acquisition instruction triggered by the graphic primitive aiming at the target API service is detected, acquiring a target call log of the target API service from the target call log.

According to the scheme provided by the embodiment of the application, the API service calling track can be presented, so that the debugging personnel can conveniently know the calling flow and calling branch of the debugging process, and the visual effect of API application debugging is good. Further, presenting the API service call trace may facilitate a tester to obtain a call log (e.g., a target call log) of a desired API service.

Optionally, before presenting the API service call tracks according to the call order, the method further includes:

determining the last called API service according to the calling sequence; determining the end API service of the target API application according to the API service arrangement sequence of the target API application; judging whether the last called API service is the ending API service of the target API application; when the last called API service is the ending API service of the target API application, determining that the calling track of the API service is a normal track; and when the last called API service is not the ending API service of the target API application, determining that the calling track of the API service is an abnormal track.

According to the scheme provided by the embodiment of the application, the normal track is different from the abnormal track, so that whether the API service calling track is the normal track or not is determined before the API service calling track is presented, and the API service calling track can be presented conveniently.

Optionally, presenting the API service call tracks according to a call order, including:

when the API service calling track is a normal track, presenting the API service calling track according to a calling sequence, wherein the API service calling track comprises primitives of the called API service and trajectory lines for connecting all the primitives of the called API service according to the calling sequence;

when the API service calling track is an abnormal track, presenting the API service calling track according to a calling sequence and an API service arrangement sequence, wherein the API service calling track comprises primitives of called API services and primitives of non-called API services, tracks of all the primitives of the called API services are connected according to the calling sequence, arrangement lines of all the primitives of the non-called API services are connected according to the API service arrangement sequence, arrangement lines of the primitives of the called API services and the primitives of the non-called API services are connected according to the API service arrangement sequence, the called API services comprise calling normal API services and calling abnormal API services, and presentation forms of the primitives of the calling normal API services, the primitives of the calling abnormal API services and the primitives of the non-called API services are different.

According to the scheme provided by the embodiment of the application, because the primitives for calling the normal API service, the primitives for calling the abnormal API service and the primitives for the un-called API service can be presented in different forms, a tester can conveniently and quickly determine the calling condition of each API service.

Optionally, determining a calling order of API services in the target API application according to the target debug log includes: and analyzing the target debugging log in a regular mode, and determining the calling sequence of the called API service in the target API application.

Optionally, the obtaining a target debugging log, where the target debugging log is generated in a process of debugging the target API application, includes: sending a debugging request to an API gateway, wherein the debugging request carries an API application identifier and a first timestamp, the API application identifier indicates a target API application, and the first timestamp is a starting timestamp of debugging of the target API application; and receiving a debugging response sent by the API gateway, wherein the debugging response comprises a target debugging log, the target debugging log is generated by the API gateway between the second timestamp and the first timestamp aiming at the target API application, and the second timestamp is an ending timestamp of the target API application debugging.

According to the scheme provided by the embodiment of the application, the debugging process can be triggered by sending the debugging request to the API gateway, the debugging response sent by the API gateway can be received when the debugging is finished, the debugging response comprises the target debugging log, so that the target debugging log can be obtained when the debugging is finished, the target debugging log is obtained timely, the timely analysis is facilitated, and the problem is found timely.

Optionally, before obtaining the target commissioning log, the method further includes: acquiring a debugging execution result, wherein the debugging execution result is an execution result of debugging the target API application; presenting a debugging execution result;

obtaining a target commissioning log, comprising: and when an analysis instruction triggered according to the debugging execution result is received, acquiring a target debugging log.

According to the scheme provided by the embodiment of the application, the testing execution result can be presented, so that a tester can know the testing execution result; in addition, the target debugging log is obtained when the analysis instruction triggered according to the debugging execution result is received, so that the analysis of the target debugging log can be triggered by a tester, and the controllability of the debugging process is improved.

In a second aspect, an API application debugging apparatus is provided, where the API application debugging apparatus includes at least one module, and the at least one module is configured to implement the API application debugging method provided in the first aspect or any optional manner of the first aspect.

In a third aspect, an API application debugging apparatus is provided, where the API application debugging apparatus includes: the API application debugging method comprises a processor, a communication interface, a memory, and a bus, the processor being configured to execute instructions stored in the memory to implement the API application debugging method provided by the first aspect or any alternative of the first aspect.

In a fourth aspect, a computer-readable storage medium is provided, where instructions are stored in the computer-readable storage medium, and when the instructions are executed on a processing component of a computer, the instructions cause the processing component to execute the API application commissioning method provided in the first aspect or any optional manner of the first aspect.

In a fifth aspect, there is provided a computer program product comprising instructions which, when run on a computer, cause the computer to perform the API application commissioning method provided in the first aspect or any alternative to the first aspect.

A sixth aspect provides a chip comprising programmable logic circuits and/or program instructions, which when run, is configured to implement the API application commissioning method provided by the first aspect or any alternative form of the first aspect.

The beneficial effects of the second to sixth aspects can refer to the first aspect, and are not described herein again.

Drawings

FIG. 1 is a schematic illustration of an implementation environment to which embodiments of the present application relate;

fig. 2 is a flowchart of a method for debugging an API application according to an embodiment of the present application;

FIG. 3 is a schematic diagram of an API service orchestration sequence in a target API application according to an embodiment of the present application;

fig. 4 is a schematic diagram illustrating a test execution result according to an embodiment of the present disclosure;

fig. 5 is a flowchart of a method for obtaining a call log of a called API service according to an embodiment of the present application;

FIG. 6 is a schematic diagram of an API service orchestration sequence and API service call trajectory according to an embodiment of the present application;

FIG. 7 is a schematic diagram of another API service orchestration sequence and API service call trajectory provided by embodiments of the present application;

FIG. 8 is a flowchart of a method for determining whether an API service call trace is a normal trace according to an embodiment of the present disclosure;

fig. 9 is a schematic logical structure diagram of an API application debugging apparatus according to an embodiment of the present application;

fig. 10 is a schematic logic structure diagram of another API application debugging apparatus according to an embodiment of the present application;

fig. 11 is a schematic physical structure diagram of an API application deployment apparatus according to an embodiment of the present application.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the embodiments of the application and, together with the description, serve to explain the principles of the embodiments of the application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

With the popularization of the internet cloud scene, more and more cloud sites integrate own resources (such as API services) and are opened to be called by developers through API gateways so as to provide high-performance and high-availability API hosting services for cloud computing users. The API gateway is a gateway which completely hosts API services, so that developers can easily create, publish, maintain and protect API services of any scale.

In an internet cloud scenario, API orchestration refers to the process of orchestrating one or more API services into API applications using a specialized API management tool. API orchestration does not involve programming, only by configuring and/or mapping at the cloud platform to invoke and/or combine API services. Wherein, the API service refers to a functional unit that meets a specific requirement. In an API application, there may be a sequential (the output of a previous API service is the input of a subsequent API service), parallel (two API services are parallel), or conditional jump (a jump from one API service to another API service when a condition is met) relationship between API services. Whether an API application is orchestrated by API services and how many API services an API application is orchestrated by are not visible to users (including testers and actual users). Therefore, through API layout, users do not need to be concerned with the complicated configuration flow of API application.

After the API layout forms the API application, the API application typically needs to be debugged. However, in an actual scenario, when a problem occurs in a debugging process, a conventional debugging method cannot intuitively locate a problem point of API arrangement, and a tester needs to check a debugging log and find the problem point of API arrangement according to the debugging log, which results in long time consumption and low efficiency in debugging and testing of API application.

Currently, a MuleSoft API editing tool is generally used for debugging API applications, and the MuleSoft API editing tool is a graphical editing tool based on an offline integrated development environment, which allows a user to adopt a graphical development business process, and can provide debugging execution results (normal or abnormal) for testers. When debugging is abnormal, the MuleSoft API arrangement tool can generate an API model according to codes written by testers, obtain a debugging log by sending a specific request to an API gateway according to the API model, display the debugging log in a text form, analyze the debugging log by the testers, determine key information of the debugging log, and determine problem points of API arrangement according to the key information of the debugging log.

However, the current scheme needs manual analysis of the debugging logs, and the debugging and the testing of the API application are long in time and low in efficiency; the current scheme only provides a debugging execution result and a debugging log for a tester, and cannot visually provide a calling flow and a calling branch of the API service of the debugging process for the tester (namely cannot provide an API service calling track for the tester), so that the visualization effect is poor; the current scheme displays the debugging log in a text form, so that testers cannot quickly check the problem points of API arrangement, and the user experience is low.

The embodiment of the application provides an API application debugging method and device and a storage medium, key information in a debugging log can be obtained and presented without manual analysis, time consumed by debugging and testing the API application is reduced, debugging and testing efficiency of the API application is improved, and user experience is improved; and the API service calling track in the API application debugging and testing process can be obtained and presented, and the visualization effect of the API application debugging and testing is better. The following provides a detailed description of the embodiments of the present application.

Referring to fig. 1, a schematic diagram of an implementation environment according to an embodiment of the present application is shown, where the implementation environment includes an API application debugging device 01 and an API gateway 02, where the API application debugging device 01 and the API gateway 02 may be communicatively connected through a wired network or a wireless network, and the wireless network may include but is not limited to: wireless fidelity (WIFI), bluetooth, infrared, zigbee, data, or the like.

The API application debugging device 01 may be a terminal or a debugging device or a debugging tool running on the terminal. The terminal can be a smart phone, a tablet computer, a desktop computer or the like. The API gateway 02 may be one gateway or a gateway cluster consisting of several gateways. Illustratively, the API gateway 02 may include a gateway deployed in a test environment (e.g., a sandbox test environment) and a gateway deployed in a production environment (e.g., a real application environment for API applications).

The API application deployment and testing device 01 is configured to deploy the arranged API application into the API gateway 02, and deploy and test the API application by interacting with the API gateway 02. The API gateway 02 is configured to generate a debug log and provide the debug log to the API application debug device 01. In addition, the API gateway 02 is also used for lifecycle management of API applications.

In some implementation scenarios, the API application testing apparatus 01 is also referred to as an API service tracking system, and the API service tracking system may include an API development unit and an API testing unit, where the API development unit is mainly used for development of the API application, and the API testing unit is mainly used for testing the API application. Illustratively, the API development unit is used for generating an arrangement relation between the API and the API service and configuring a sandbox environment and a production environment; the API test unit is used for generating a test case (for testing the API application), executing a test (i.e., calling the API service), and analyzing a test log.

It should be noted that the implementation environment shown in fig. 1 is only for example and is not used to limit the technical solution of the embodiment of the present application. It will be appreciated by those skilled in the art that the implementation environment of the present application may also include other devices, and that the number of individual devices may be configured as desired, in particular implementations.

Please refer to fig. 2, which shows a flowchart of a method for API application debugging provided in an embodiment of the present application, where the method can be applied to the above implementation environment and can be executed by the API application debugging apparatus 01. Referring to fig. 2, the method may include the steps of:

step 101, obtaining a debugging execution result, wherein the debugging execution result is an execution result of debugging a target API application, and the target API application is formed by arranging at least one API service.

Optionally, the API application debugging device may debug the target API application by interacting with the API gateway according to the test case. After the debugging execution is completed (i.e., the API service call in the target API application is completed), the API gateway may generate a debugging execution result, and the API application debugging apparatus may obtain the debugging execution result from the API gateway. The test execution result may be normal or abnormal. The test case may be deployed in the API application debugging device by a tester, and the target API application is composed of at least one API service. For example, please refer to fig. 3, which shows a schematic diagram of an API service arrangement sequence in a target API application provided by an embodiment of the present application, referring to fig. 3, the target API application is formed by sequentially arranging an API service N1, an API service N3, and an API service N2, and the API service arrangement sequence in the target API application is as follows: API service N1- > API service N3- > API service N2. Where each circle in fig. 3 represents a primitive, the primitive indicating an API service. For example, the circle in which N1 is located represents a primitive of API service N1 (which may be referred to as primitive N1), the primitive N1 indicates API service N1, the circle in which N2 is located represents a primitive of API service N2 (which may be referred to as primitive N2), the primitive N2 indicates API service N2, the circle in which N3 is located represents a primitive of API service N3 (which may be referred to as primitive N3), and the primitive N3 indicates API service N3.

Optionally, the obtaining, by the API application debugging apparatus, the debugging execution result from the API gateway may include: the API application debugging device sends a debugging request to the API gateway, wherein the debugging request can carry an API application identifier and a test case, and the API application identifier indicates a target API application; after receiving the debugging request, the API gateway determines a target API application according to the API application identifier, calls API service in the target API application according to the test case to debug the target API application, and generates a debugging execution result when the API service in the target API application is called; then, the API gateway sends a debugging response to the API application debugging device, wherein the debugging response comprises a debugging execution result; and after receiving the debugging response, the API application debugging device analyzes the debugging response to obtain a debugging execution result.

In this embodiment of the application, before the step 101, the API application deployment and testing apparatus may perform API deployment on at least one API service to obtain a target API application, and deploy the target API application on the API gateway. The process of the API application deployment device deploying the target API application on the API gateway may include: the API application debugging device sends a deployment request to the API gateway, where the deployment request carries orchestration information of API services in the target API application, and after receiving the deployment request, the API gateway deploys the target API application on the API gateway according to the orchestration information in the deployment request, and sends a response indicating that the target API application is successfully deployed to the API application debugging device after successful deployment.

And 102, presenting a debugging execution result.

After the API application debugging device obtains the debugging execution result, the debugging execution result can be presented, so that a tester can obtain the debugging execution result. Optionally, the API application debugging device has a display interface, and the API application debugging device may display the debugging execution result in the display interface.

For example, please refer to fig. 4, which shows a schematic diagram of the API application debugging apparatus displaying the debugging execution result provided in the embodiment of the present application, and referring to fig. 4, the display interface of the API application debugging apparatus displays the debugging execution result "debugging abnormal", and in addition, displays "whether to analyze", and "yes" and "no" buttons. When the tester clicks the 'yes' button, the API application debugging device can analyze the debugging execution process, and when the tester clicks the 'no' button, the API application debugging device does not analyze the debugging execution process. The process of analyzing the measurement execution process may refer to steps 103 to 110 described below.

It should be noted that fig. 4 is described by taking an abnormal debugging execution result as an example, when the debugging execution result is normal, reference may be made to fig. 4 for the interface of the API application debugging apparatus presenting the debugging execution result, which is not described herein again in this embodiment of the present application.

Step 103, obtaining a target debugging log, wherein the target debugging log is generated in the process of debugging the target API application.

In the process of debugging the target API application, the API gateway can generate a target debugging log, and the API application debugging device can acquire the target debugging log from the API gateway. Optionally, after the API application debugging device presents the debugging execution result, the tester may trigger the analysis instruction according to the debugging execution result, and when the API application debugging device receives the analysis instruction triggered according to the debugging execution result, the API application debugging device may obtain the target debugging log from the API gateway. For example, when the tester clicks the "yes" button in fig. 4, an analysis instruction may be triggered, and the API application commissioning device obtains the target commissioning log from the API gateway.

Optionally, the obtaining, by the API application commissioning device, the target commissioning log from the API gateway may include: the API application debugging device sends a debugging request to the API gateway, wherein the debugging request carries an API application identifier and a first timestamp, the API application identifier indicates a target API application, and in addition, the debugging request can also carry a test case; after receiving the debugging request, the API gateway calls an API service in the target API application to debug the target API application, the API gateway can generate a debugging log aiming at the target API application in the debugging process, when the API service in the target API application is called, the API gateway stops generating the debugging log aiming at the target API application, and the debugging log generated between the first timestamp and the second timestamp aiming at the target API application is used as the target debugging log; then, the API gateway sends a debugging response to the API application debugging device, wherein the debugging response comprises the target debugging log; and after receiving the debugging response, the API application debugging device analyzes the debugging response to obtain a target debugging log. Wherein, first timestamp is the beginning timestamp of target API application debugging, this first timestamp can be API application debugging device and send the timestamp of debugging request to the API gateway, the second timestamp is the end timestamp of target API application debugging, this second timestamp can be for the API gateway to call the timestamp of the last API service of target API application, perhaps the API gateway calls unusual timestamp to the API service of target API application, the second timestamp specifically can be according to normally confirming API service call to target API application, this application embodiment no longer has been repeated here.

It should be noted that the test request in step 103 and the test request in step 101 may be the same test request or different test requests, and the test response may be the same test response or different test responses. When the debugging request in step 103 and the debugging request in step 101 may be the same debugging request, and the debugging response in step 103 and the debugging request in step 101 may be the same debugging response, it is easy to understand that, in step 101, the API gateway has returned the target debugging log to the API application debugging device, and the API application debugging device may store the target debugging log first, so that in step 103, the API application debugging device reads the target debugging log from its own storage space, and may obtain the target debugging log, which is not limited in this embodiment of the present application.

For example, in the embodiment of the present application, the target debug log may be as follows:

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:14,031]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N1,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:14,056]|INFO||253753916688722|End Element Execution[Element Id:diagram_N1,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,021]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N3,xxx]>>>

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,039]|DEBUG||253753916688722|Start execute diagram,element Id diagram_N3…,inputs:{“rest3_POST_xxxInfo”:{“a”:“stringa”,“b”:intb}，outputs:{“rest3_POST_xxxInfo”:{“a”:“stringa”,“b”:intb}.requestInfo:{“reqUrl”:“http://www.example.com”,“method”:“POST”,“headers”:{“content-length”:“162”,“content-type”:“application/json；charset＝UTF-8”},“body”：“”}responseInfo:{“statusCode”:200,“code”:200,“headers”:{“content-type”:“application/json”},“body”:“xxx”}

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,055]|DEBUG||253753916688722|Complete execute diagram,element Id diagram_N3,cost:7(ms),element execute info is…

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,098]|INFO||253753916688722|End Element Execution[Element Id:diagram_N3,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,321]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N2,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,448]|INFO||253753916688722|End Element Execution[Element Id:diagram_N2,xxx]>>>

....

wherein, diagram _ N1 is an identifier of primitive N1, which represents primitive N1, and primitive N1 indicates API service N1, so diagram _ N1 can also be regarded as an identifier of API service N1; diagram _ N3 is an identifier of primitive N3, which represents primitive N3, primitive N3 indicates API service N3, and Diagram _ N3 can also be regarded as an identifier of API service N3; diagram _ N2 is an identifier of primitive N2, which represents primitive N2, primitive N2 indicates API service N2, and Diagram _ N2 can also be regarded as an identifier of API service N2; 2018-09-2114: 31:14,031 is a first timestamp; 2018-09-2114: 31:15,448 is a second timestamp; the INFO is the log level of the target debugging log; 253753916688722 is a trace instance identifier for testing the target API application (i.e., an identifier of a test case for testing the target API application, or a trace instance identifier of a target test log); the application Impl Theadpool-4 is a thread identification of the thread pool, and represents the thread execution indicated by the application Impl Theadpool-4 for the invocation of the target API application. The target debugging log comprises a calling log of the API service N1, a calling log of the API service N3 and a calling log of the API service N2, and indicates that the API service N1, the API service N3 and the API service N2 of the target API application are called in sequence in the debugging process of the target API application. Wherein,

the call log of the API service N1 may be call log 1, and the content of the call log 1 is:

“<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:14,031]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N1,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:14,056]|INFO||253753916688722|End Element Execution[Element Id:diagram_N1,xxx]>>>”

the call log of the API service N1 indicates that the call (keyword begin Element Execution) of the API service N1 (keyword diagram _ N1) is started at 2018-09-2114: 31:14,031, and the call (keyword End Element Execution) of the API service N1 is ended at 2018-09-2114: 31:14,056.

The call log of the API service N3 may be call log 3, and the content of the call log 3 is:

“<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,021]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N3,xxx]>>>

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,098]|INFO||253753916688722|End Element Execution[Element Id:diagram_N3,xxx]>>>”

the call log of the API service N3 indicates that a call (keyword BeginElement Execution) is started at 2018-09-2114: 31:15,021 to the API service N3 (keyword diagram _ N3) and a call (keyword End Element Execution) to the API service N3 is ended at 2018-09-2114: 31:15,098, the input information (keyword inputs) of the API service N3 is { "rest 3_ POST _ xxxInfo": { "a": stringa "," b ": intb }, the output information (keyword outputs) is {" rest3_ POST _ xxxInfo ": a": stringa "," stringb ": intb }, the request information (keyword requestInfo) is {" real ": symbol/: http {" postscript ": www.example.com {" content ": result": www.example.com ": content": result ": content/162"; charset-8 "}," body ": "}, the response information (keyword responseInfo) is {" status code ": 200," headers ": {" content-type ": application/json" }, "body": xxx "}, and the time taken to call the API service N3 (keyword cost) is 7 milliseconds.

The call log of the API service N2 may be call log 2, and the content of the call log 2 is:

“<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,321]|INFO||253753916688722|Begin Element Execution[Element Id:diagram_N2,xxx]>>>

....

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,448]|INFO||253753916688722|End Element Execution[Element Id:diagram_N2,xxx]>>>”

the call log of the API service N2 indicates that the call (keyword begin Element Execution) of the API service N2 (keyword diagram _ N2) is started at 2018-09-2114: 31:15,321, and the call (keyword End Element Execution) of the API service N2 is ended at 2018-09-2114: 31:15,448.

And step 104, determining the calling sequence of the API service in the target API application according to the target debugging log.

Optionally, the API application debugging apparatus may analyze the target debugging log in a regular manner, and determine a calling order of the called API services in the target API application. The API application debugging device can analyze the target debugging log in a regular mode according to the calling keywords in the target debugging log, and determine the calling sequence of the called API services in the target API application. The call keywords may include a call start keyword (e.g., Begin Element Execution), a call End keyword (e.g., End Element Execution), a primitive identifier (e.g., diagram _ N1), and the like.

Illustratively, the API application debugging apparatus determines, according to the target debugging log in step 103, that the calling order of the API services in the target API application is: API service N1- > API service N3- > API service N2.

In some scenarios, the call order is also referred to as an execution order, and the execution order may be embodied in a list, for example, the execution order may be an execution order list [ API service N1, API service N3, API service N2 ].

And 105, acquiring a call log of each called API service from the target call log.

Optionally, the API application debugging device may obtain, from the target debugging log, a debugging log of each invoked API service according to the feature tag of the invoked API service. In some scenarios, the call log is also referred to as a feature log.

Referring to fig. 5, which shows a flowchart of a method for obtaining a call log of each called API service from a target call log according to an embodiment of the present application, referring to fig. 5, the method may include:

substep 1051 determines a feature tag for each called API service, the feature tag including an identification of the called API service and an identification of a trace instance that was invoked for the target API application.

If the target debugging log contains the identifier of a certain API service, the API service is called in the process of debugging the target API application.

Optionally, the API application debugging apparatus may generate the feature tag of each called API service according to the identifier of each called API service and the identifier of the trace instance for debugging the target API application.

Illustratively, the trace instance for debugging the target API application is identified as 253753916688722, the API service 1 may be identified as diagram _ N1, the API service 2 may be identified as diagram _ N2, the API service 3 may be identified as diagram _ N3, and the API service 1, the API service 2, and the API service 3 are all called API services, then the feature tag of the API service 1 may be {253753916688722, diagram _ N1}, the feature tag of the API service 2 may be {253753916688722, diagram _ N2}, and the feature tag of the API service 3 may be {253753916688722, diagram _ N3 }.

Substep 1052 extracts the call log of each called API service from the target call log according to the feature tag of each called API service.

Optionally, the API application debugging device may determine, according to the feature tag of each called API service, a call log of each called API service from the target debugging log in combination with the call time keyword in the target debugging log, and extract the call log of each called API service. The call time keyword may include a call start keyword (e.g., Begin Element Execution) and a call End keyword (e.g., End Element Execution).

Illustratively, the API application deployment apparatus extracts the call log 1 of the API service 1 from the target deployment log of step 103 according to {253753916688722, diagram _ N1}, Begin Element Execution and End Element Execution, extracts the call log 2 of the API service 2 from the target deployment log of step 103 according to {253753916688722, diagram _ N2}, Begin Element Execution and End Element Execution, and extracts the call log 3 of the API service 3 from the target deployment log of step 103 according to {253753916688722, diagram _ N3}, Begin Element Execution and End Element Execution.

And 106, establishing an association relation between the called API service and the call log according to each called API service and the corresponding call log.

Optionally, the API application tuning device may associate each called API service with a call log of the called API service, so as to obtain an association relationship between the called API service and the call log. For example, the API application testing apparatus associates the API service 1 with the call log 1, associates the API service 2 with the call log 2, and associates the API service 3 with the call log 3, and obtains an association relationship between the called API service and the call log as shown in table 1 below:

TABLE 1

API service	Call logs
		API service 1	Call Log 1
API service 2	Call Log 2
		API service 3	Call Log 3

And step 107, presenting an API service calling track according to the calling sequence of the API service in the target API application.

The API application debugging device may present the API service call tracks according to the call order of the API services in the target API application, for example, display the API service call tracks. The API service calling track at least comprises primitives of the called API service and a track line which connects the primitives of at least two called API services according to a calling sequence, and the primitives of the API service indicate the API service. In some implementation scenarios, the call trace is also referred to as the execution trace.

In the embodiment of the application, the API service call track may be a normal track or an abnormal track. The API application debugging means presenting the API service call tracks according to the call order of the API services in the target API application may include: and when the API service calling track is a normal track, the API application calling device presents the API service calling track according to the calling sequence, and the API service calling track comprises the primitives of the called API service and the track lines which are connected with the primitives of all the called API services according to the calling sequence. When the API service calling track is an abnormal track, the API application calling and testing device presents the API service calling track according to a calling sequence and an API service arranging sequence, the API service calling track comprises primitives of called API services and primitives of the unused API services, tracks of the primitives of all the called API services are connected according to the calling sequence, arranging lines of the primitives of all the unused API services are connected according to the API service arranging sequence, arranging lines of the primitives of the called API services and the primitives of the unused API services are connected according to the API service arranging sequence, the called API services comprise calling normal API services and calling abnormal API services, and the presenting forms of the primitives of the called normal API services, the primitives of the called abnormal API services and the primitives of the unused API services are different. In order to more intuitively present that the API service calling track is a normal track or an abnormal track, the API application debugging device can also present an API service arranging sequence, so that a tester can intuitively determine that the API service calling track is the normal track or the abnormal track according to the API service arranging sequence.

For example, please refer to fig. 6, which shows a schematic diagram of an API service call track provided in an embodiment of the present application, and fig. 6 also shows an API service arrangement sequence. Referring to fig. 6, an API service call trajectory includes primitives of an API service N1, an API service N3, and an API service N2 (called API services) and a trajectory connecting the primitives of the API service N1, the API service N3, and the API service N2 in a call order, where fig. 6 shows that in a process of debugging a target API application, an API service N1, an API service N3, and an API service N2 are called in sequence, and an API service N1, an API service N3, and an API service N2 all call normally, and the API service call trajectory shown in fig. 6 is a normal trajectory.

For example, please refer to fig. 7, which shows a schematic diagram of another API service call track provided in an embodiment of the present application, and fig. 7 also shows an API service arrangement sequence. Referring to fig. 7, the API service call trace includes primitives for API service N1 and API service N3 (all called API services), primitives for API service N2 (all un-called API services), the trajectory of the primitives connecting API service N1 and API service N3 (all called API services) in call order, the orchestration lines of primitives for API service N2 (the API service not being invoked) are connected in API service orchestration order, and an arrangement line connecting the primitive of the API service N3 (called API service) and the primitive of the API service N2 (un-called API service) in the API service arrangement order, the called API service including the API service N1 (calling normal API service) and the API service N3 (calling abnormal API service), the primitives of the API service N1 (calling normal API service), the primitive of the API service N3 (calling abnormal API service), and the primitives of the API service N2 (un-called API service) being different in presentation form. Fig. 7 shows that in the process of debugging the target API application, the API service N2 and the API service N3 are sequentially called, the API service N2 is not called, the API service N1 is normally called, the API service N3 is abnormally called, and the API service calling track shown in fig. 7 is an abnormal track.

And step 108, acquiring a target call log of the target API service from the target call log.

The target API service is any API service called in the process of debugging the target API application, and the target API service can be an API service calling abnormally or a API service calling normally.

Optionally, before step 108, the API application testing apparatus may determine, according to the target testing log, a calling sequence of the API service in the target API application, and present an API service calling track according to the calling sequence of the API service in the target API application, after the API application testing apparatus presents the API service calling track, the tester may trigger an obtaining instruction (for example, click a primitive obtaining instruction of the target API service in the API service calling track) for a primitive of the target API service according to the API service calling track; when the API application debugging device detects an obtaining instruction triggered by a primitive for the target API service, the API application debugging device may obtain a target call log of the target API service from the target call log. Optionally, the API application debugging apparatus may obtain a target call log of the target API service from an association relationship between the called API service and the call log. The association relationship between the called API service and the call log may be an association relationship between an identifier of the called API service and the call log, and the API application debugging device may query the association relationship between the called API service and the call log according to the identifier of the target API service to obtain the target call log, and obtain the target call log.

Illustratively, taking fig. 6 as an example, the API service call trace is as shown in fig. 6, and the target API service is API service N3 (call normal API service). The tester may trigger a get instruction for the primitive of the API service N3 according to the API service call trace shown in fig. 6, and when the API application test apparatus detects the get instruction for the primitive trigger of the API service N3, the API application test apparatus may obtain a call log 3 (target call log) of the API service N3 from table 1 described above.

Illustratively, the contents of the call log 3 (target call log) are:

<<<[applicationImpl TheadPool-4]|[2018-09-21 14:31:15,098]|INFO||253753916688722|End Element Execution[Element Id:diagram_N3,xxx]>>>”。

and step 109, acquiring key information in the target call log.

The key information may include, but is not limited to: input information (keyword inputs), output information (keyword outputs), request information (keyword requestInfo), response information (keyword responseInfo), and Exception information (keyword Exception). When the target API service is the API service calling normally, the key information in the target call log comprises input information, output information, request information and response information, and when the target API service is the API service calling abnormally, the key information in the target call log comprises abnormal information.

Optionally, the API application debugging apparatus may obtain the key information in the target call log by combining the key word according to the identifier of the target API service. Illustratively, continuing with fig. 6 as an example, the target API service is API service N3, and the API application debugging apparatus obtains the key information in the target call log (call log 3 in step 108) according to the identifier diagram _ N3, the keyword inputs, the keyword outputs, the keyword requestInfo, and the keyword responseInfo of API service N3, where the key information may be: "inputs {" rest3_ POST _ xxxInfo ": {" a ": stringa", "b": intb }, outputs { "rest 3_ POST _ xxxInfo": { "a": stringa "," b ": intb }. requestInfo {" reqUrl ": http:// www.example.com", "method": "POST", "heads": content-length ": 162", "content-type": application/json; charset-8 "}," body ": "} responselnfo {" status code ": 200," headers "{" content-type ": application/json" }, "body": xxx "}.

And step 110, presenting key information.

After the API application debugging device acquires the key information in the target call log, the key information can be presented, so that a tester can know the key information. Optionally, the API application debugging device has a display interface, and the API application debugging device may display the key information in the target call log in the display interface.

Optionally, the target call log may include key information and non-key information, and the API application deployment apparatus presenting the key information in the target call log may include: the API application commissioning device presents the target call log and presents the critical information in a form different from the non-critical information.

For example, the API application commissioning device presenting the target call log and presenting the critical information in a form different from the non-critical information may include: the API application debugging device displays a target calling log, and the word size of the key information is larger than that of the non-key information; the API application debugging device displays a target calling log, and the font of the key information is different from the font of the non-key information; the API application debugging device displays a target calling log, and key information is highlighted, and non-key information is not highlighted; the API application debugging device displays a target calling log, and the fonts of the key information are thickened and the fonts of the non-key information are not thickened; the API application debugging device displays the target call log, and the font of the key information is inclined, the font of the non-key information is not inclined, and the like.

For example, the API application debugging device displays the target call log, and the font of the key information is bolded, and the font of the non-key information is not bolded, the key information (target call log) displayed by the API application debugging device may be as follows:

it should be noted that, steps 108 to 110 are described by taking the target API service as the API service that calls normally, and when the target API service is the API service that calls abnormally, the corresponding implementation process may refer to steps 108 to 110. For example, when the target API service is an API service calling an exception, the key information (target call log) acquired and presented by the API application commissioning apparatus may be as follows:

“||com.huawei.xxx.service.excuteByLocal(xxx.java:17)>>>

javax.script.ScriptException:rebate amt over limit in<eval>at linenumber 5at column number 8”

the 'Exception' is an abnormal keyword, and the presentation form of the 'Exception' is different from the presentation form of non-key information, so that after the API application debugging device presents the key information, a tester can quickly determine the problem point of API layout according to the abnormal keyword 'Exception' in the key information. In the scheme provided by the embodiment of the application, the API application debugging device can automatically analyze the debugging execution process, so that a tester can rapidly determine the problem point.

It should be noted that, in this embodiment of the application, the API application debugging apparatus may include an API development unit and an API debugging unit, and the above steps 101 to step 110 may be completed by the API development unit and the API debugging unit in a cooperation manner, for example, the API development unit performs related steps such as arranging a target API application, deploying the target API application in an API gateway, and the API debugging unit performs related steps such as obtaining and analyzing a target debugging log.

It should be further noted that, in the embodiment of the present application, the debugging execution process is analyzed when the debugging execution result is normal, and it should be understood by those skilled in the art that, in practical application, the debugging execution process may be analyzed only when the debugging execution result is abnormal, the debugging execution process may not be analyzed when the debugging execution result is normal, specifically, the debugging execution process may be analyzed under any condition, and the operation of the debugging execution result may be determined according to the operation of the tester (for example, the operation of the tester in the display interface shown in fig. 4), which is not limited in the embodiment of the present application.

Those skilled in the art will readily understand that the order of the steps of the API application debugging method provided in the embodiment of the present application may be appropriately adjusted, for example, step 105 may be executed between step 102 and step 103, or executed synchronously with step 103, or the steps may be increased or decreased according to the circumstances, and any method that is easily considered to be changed by those skilled in the art within the technical scope disclosed in the present application should be covered in the protection scope of the present application, and therefore, the description is not repeated.

To sum up, the API application debugging method provided in the embodiment of the present application obtains the target debugging log, obtains the target calling log of the target API service from the target debugging log, obtains the key information in the target calling log, and presents the key information. In addition, the API service calling track can be presented in a primitive form, so that the calling personnel can conveniently know the calling flow and calling branches of the calling and testing process, and the visualization effect of the API application calling and testing is better; furthermore, after the API service calling track is presented, the target calling log of the target API service can be obtained according to the obtaining instruction triggered by the graphic element aiming at the target API service, and the key information of the target calling log is presented, so that a tester can conveniently and quickly check the key information and position the problem point of API arrangement, the problem of API arrangement can be corrected in time, and the debugging efficiency is high.

In this embodiment, before the API application invoking device presents the API service invoking trace (step 107), it may be determined whether the API service invoking trace is a normal trace. Referring to fig. 8, which shows a flowchart of a method for determining whether an API service call trace is a normal trace according to an embodiment of the present application, referring to fig. 8, the method may include:

step 201, determining the last called API service according to the calling sequence of API services in the target API application.

Optionally, the API application invoking device determines the last API service in the calling order of the API services as the last called API service. By way of example, assume that the calling order of the API services in the target API application is: API service N1- > API service N3- > API service N2, the API application deployment test apparatus determines API service N2 as the last called API service; by way of further example, assume that the calling order of the API services in the target API application is: API service N1- > API service N3, the API application commissioning device determines API service N3 as the last called API service.

Step 202, determining the ending API service of the target API application according to the API service arrangement sequence of the target API application.

Optionally, the API application deployment and testing apparatus determines the last API service in the API service deployment order of the target API application as the end API service of the target API application. Illustratively, the API service orchestration order in the target API application is: API service N1- > API service N3- > API service N2, the API application deployment apparatus determines API service N2 as the ending API service of the target API application.

Step 203, determine whether the last called API service is the ending API service of the target API application.

Alternatively, the API application tuning device may determine an identifier of a last called API service (e.g., an identifier of a primitive of the called API service) and an identifier of a finishing API service of the target API application (e.g., an identifier of a primitive of the finishing API service), compare the identifier of the last called API service with the identifier of the finishing API service of the target API application to determine whether the last called API service is the finishing API service of the target API application, if the identity of the last called API service is the same as the identity of the ending API service of the target API application, the last called API service is the ending API service of the target API application, if the identity of the last called API service is different from the identity of the ending API service of the target API application, the last called API service is not the ending API service of the target API application.

For example, assuming that the last called API service is API service N2, and the ending API service of the target API application is API service N2, the API application debugging apparatus may determine that the last called API service is the ending API service of the target API application through identifier comparison; for another example, assuming that the last called API service is API service N3, and the ending API service of the target API application is API service N2, the API application debugging apparatus may determine that the last called API service is not the ending API service of the target API application through the identifier comparison.

And step 204, when the last called API service is the ending API service of the target API application, determining that the calling track of the API service is a normal track.

If the API application deployment testing means determines that the last invoked API service is the ending API service of the target API application in step 203, the API application deployment testing means determines that the API service invocation trajectory is a normal trajectory. Illustratively, when the last called API service is API service N2 and the ending API service of the target API application is API service N2, the API application debugging means determines that the API service calling trajectory is a normal trajectory.

And step 205, when the last called API service is not the ending API service of the target API application, determining that the calling track of the API service is an abnormal track.

If the API application deployment testing apparatus determines in step 203 that the last called API service is not the ending API service of the target API application, the API application deployment testing apparatus determines that the API service invocation trajectory is an abnormal trajectory. Illustratively, when the last called API service is API service N3 and the ending API service of the target API application is API service N2, the API application debugging means determines that the API service calling trajectory is an abnormal trajectory.

It should be noted that, in the case that the API service call trace is an abnormal trace, when the API service call trace is presented, the last called API service may be set as an abnormal API service (for example, API service 3 in fig. 7) in the API service call trace.

In the embodiment of the application, the API service calling track can be a normal track or an abnormal track, the normal track is different from the abnormal track, and the API application testing device determines whether the API service calling track is the normal track before presenting the API service calling track, so that presentation of the API service calling track can be facilitated.

The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.

Referring to fig. 9, which shows a schematic logical structure diagram of an API application debugging apparatus 300 according to an embodiment of the present application, where the API application debugging apparatus 300 may be used to execute the API application debugging method according to the foregoing embodiment, referring to fig. 9, the API application debugging apparatus 300 may include, but is not limited to:

a first obtaining module 301, configured to obtain a target debugging log, where the target debugging log is a debugging log generated in a debugging process of a target API application, and the target API application is formed by arranging at least one API service;

a second obtaining module 302, configured to obtain a target call log of a target API service from the target call log, where the target API service is any API service that is called in a process of testing a target API application;

a third obtaining module 303, configured to obtain key information in the target call log;

a first presenting module 304 for presenting the key information.

To sum up, according to the API application debugging device provided in the embodiment of the present application, after the first obtaining module obtains the target debugging log, the second obtaining module obtains the target calling log of the target API service from the target debugging log, the third obtaining module obtains the key information in the target calling log, and the first presenting module presents the key information.

Optionally, the second obtaining module 302 is configured to obtain a target call log of the target API service from an association relationship between the called API service and the call log, where the association relationship between the called API service and the call log is established according to the target call log.

Optionally, referring to fig. 10, which shows a schematic logical structure diagram of another API application debugging apparatus 300 provided in an embodiment of the present application, referring to fig. 10, on the basis of fig. 9, the API application debugging apparatus 300 further includes:

a first determining module 305, configured to determine, according to the target debug log, a call order of API services in the target API application;

a fourth obtaining module 306, configured to obtain, from the target call log, a call log of each called API service;

the establishing module 307 is configured to establish an association relationship between each called API service and the corresponding call log.

Optionally, the fourth obtaining module 306 is configured to:

determining a characteristic label of each called API service, wherein the characteristic label comprises an identifier of the called API service and a tracking instance identifier for testing a target API application;

and extracting the call logs of each called API service from the target call logs according to the feature tags of each called API service.

Optionally, with continuing reference to fig. 10, the API application debugging apparatus 300 further includes:

a second determining module 308, configured to determine, according to the target debug log, a call order of API services in the target API application;

a second presentation module 309, configured to present an API service call trajectory according to the call order, where the API service call trajectory at least includes primitives of the called API service and trajectory lines connecting at least two primitives of the called API service according to the call order, and the primitives of the API service indicate the API service;

a second obtaining module 302, configured to, when an obtaining instruction triggered by a primitive for the target API service is detected, obtain the target call log from an association relationship between the called API service and the call log.

a third determining module 310, configured to determine a last called API service according to the calling order;

a fourth determining module 311, configured to determine an end API service of the target API application according to the API service arrangement order of the target API application;

a determining module 312, configured to determine whether the last called API service is an end API service of the target API application;

a fifth determining module 313, configured to determine that the API service calling track is a normal track when the last called API service is an end API service of the target API application;

a sixth determining module 314, configured to determine that the API service call trajectory is an abnormal trajectory when the last called API service is not the ending API service of the target API application.

Optionally, a second rendering module 309, configured to:

Optionally, the first determining module 305 is configured to analyze the target call log in a regular manner, and determine a call order of the called API services in the target API application.

Optionally, the first obtaining module 301 is configured to:

sending a debugging request to an API gateway, wherein the debugging request carries an API application identifier and a first timestamp, the API application identifier indicates a target API application, and the first timestamp is a starting timestamp of debugging of the target API application;

and receiving a debugging response sent by the API gateway, wherein the debugging response comprises a target debugging log, the target debugging log is generated by the API gateway between the second timestamp and the first timestamp aiming at the target API application, and the second timestamp is an ending timestamp of the target API application debugging.

Optionally, the debugging response further includes a debugging execution result, where the debugging execution result is an execution result of the API gateway performing debugging on the target API application, please refer to fig. 10 again, and the API application debugging apparatus 300 further includes:

a fifth obtaining module 315, configured to obtain a debugging execution result, where the debugging execution result is an execution result of debugging the target API application;

a third presenting module 316, configured to present a debugging execution result;

the first obtaining module 301 is configured to obtain a target debug log when an analysis instruction triggered according to a debug execution result is received.

To sum up, according to the API application debugging device provided in the embodiment of the present application, after the first obtaining module obtains the target debugging log, the second obtaining module obtains the target calling log of the target API service from the target debugging log, the third obtaining module obtains the key information in the target calling log, and the first presenting module presents the key information. In addition, the API service calling track can be presented in a primitive form, so that the calling personnel can conveniently know the calling flow and calling branches of the calling and testing process, and the visualization effect of the API application calling and testing is better; furthermore, after the API service calling track is presented, the target calling log of the target API service can be obtained according to the obtaining instruction triggered by the graphic element aiming at the target API service, and the key information of the target calling log is presented, so that a tester can conveniently and quickly check the key information and position the problem point of API arrangement, the problem of API arrangement can be corrected in time, and the debugging efficiency is high.

Referring to fig. 11, which shows a schematic diagram of a hardware structure of an API application debugging apparatus 400 according to an embodiment of the present application, referring to fig. 11, the API application debugging apparatus 400 includes a processor 402, a memory 404, a communication interface 406, and a bus 408, where the processor 402, the memory 404, and the communication interface 406 are connected through the bus 408. The memory 404 may be used to store instructions 4042 and data 4044. It will be readily appreciated that the connections between the processor 402, the memory 404, and the communication interface 406 shown in FIG. 11 are exemplary only, and that in particular implementations, the processor 402, the memory 404, and the communication interface 406 may be communicatively coupled to each other using connections other than the bus 408.

Where processor 402 may be a general-purpose processor, which may be a processor that performs certain steps and/or operations by reading and executing instructions (e.g., instructions 4042) stored in a memory (e.g., memory 404), the general-purpose processor may use data (e.g., data 4044) stored in the memory (e.g., memory 404) in performing the above-described steps and/or operations. A general purpose processor may be, for example and without limitation, a Central Processing Unit (CPU). Further, the processor 402 may also be a special purpose processor, which may be a specially designed processor for performing certain steps and/or operations, such as, but not limited to, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), and the like. Further, processor 402 may also be a combination of multiple processors, such as a multi-core processor. The processor 402 may include at least one circuit to perform the steps of the API application commissioning method in the embodiments described below.

The memory 404 may be various types of storage media, such as Random Access Memory (RAM), ROM, non-volatile RAM (NVRAM), Programmable ROM (PROM), Erasable PROM (EPROM), Electrically Erasable PROM (EEPROM), flash memory, optical storage, registers, and the like. The memory 404 is specifically configured to store the instructions 4042 and the data 4044, and when the processor 402 is a general-purpose processor, the processor 402 may perform specific steps and/or operations by reading and executing the instructions 4042 stored in the memory 404, and the data 4044 may be required in the process of performing the steps and/or operations.

Depending on the API application commissioning device, the communication interface 406 may include a transceiver, a plurality of antennas, or an I/O (input/output) interface for receiving instructions and/or data from a peripheral device and outputting instructions and/or data to a peripheral device, etc. The antenna is connected to a transceiver, and the transceiver transmits and receives signals through at least one antenna connected thereto.

In particular implementations, processor 402 may be configured to perform, for example but not limited to, a debugging related process, and the transceiver may be configured to perform, for example but not limited to, a transceiving related process. The above devices may be respectively disposed on separate chips, or at least a part or all of the devices may be disposed on the same chip. For example, the processor 402 may be further divided into an analog baseband processor and a digital baseband processor, wherein the analog baseband processor may be integrated with the transceiver on the same chip, and the digital baseband processor may be disposed on a separate chip. With the development of integrated circuit technology, more and more devices can be integrated on the same chip, for example, a digital baseband processor can be integrated on the same chip with various application processors (such as, but not limited to, a graphics processor, a multimedia processor, etc.). Such a Chip may be referred to as a System on Chip. Whether each device is separately located on a different chip or integrated on one or more chips often depends on the specific needs of the product design. The embodiment of the present application does not limit the specific implementation form of the above device.

It is to be understood that the API application testing apparatus 400 shown in fig. 11 is only exemplary, and in a specific implementation process, the API application testing apparatus 400 may further include other hardware devices, which are not listed herein. The specific functions of the hardware components in the API application debugging apparatus 400 will be described in detail below.

An embodiment of the present application provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the instructions are executed on a processing component of a computer, the processing component is caused to execute the API application debugging method provided in the foregoing embodiment.

The embodiment of the present application provides a computer program product containing instructions, which when running on a computer, causes the computer to execute the API application tuning method provided in the foregoing embodiment.

Embodiments of the present application provide a chip, where the chip includes a programmable logic circuit and/or a program instruction, and when the chip runs, the chip is configured to implement the API application debugging method provided in the foregoing embodiments.

In the embodiment of the present application, the term "and/or" is only one kind of association relationship describing an associated object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

In the embodiments of the present application, the term "at least one" means one or more, and a plurality means more than one, for example, two.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above description is only exemplary of the present application and should not be taken as limiting, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for API application debugging, the method comprising:

acquiring a target debugging log, wherein the target debugging log is generated in the debugging process of a target API application, and the target API application is formed by arranging at least one API service;

acquiring a target call log of a target API service from the target call log, wherein the target API service is any API service called in the process of calling and testing the target API application;

acquiring key information in the target call log;

and presenting the key information.

2. The method of claim 1, wherein obtaining a target call log of a target API service from the target call log comprises:

and acquiring the target call log from the association relationship between the called API service and the call log, wherein the association relationship between the called API service and the call log is established according to the target call log.

3. The method of claim 2, wherein before obtaining the target call log from the association of the called API service with the call log, the method further comprises:

determining a calling sequence of API services in the target API application according to the target debugging log;

obtaining a call log of each called API service from the target call log;

and establishing an association relation between the called API service and the call log according to each called API service and the corresponding call log.

4. The method of claim 3, wherein obtaining a call log for each called API service from the target call log comprises:

determining a feature tag of each called API service, wherein the feature tag comprises an identifier of the called API service and a tracking instance identifier for testing the target API application;

and extracting the call logs of the called API services from the target call logs according to the feature tags of the called API services.

5. The method of claim 1,

before obtaining the target call log of the target API service from the target call log, the method further includes:

obtaining a target call log of a target API service from the target call log, including:

and when an acquisition instruction triggered by the graphic element of the target API service is detected, acquiring a target call log of the target API service from the target call log.

6. The method of claim 5, wherein prior to presenting API service call traces according to the call order, the method further comprises:

determining the last called API service according to the calling sequence;

determining the end API service of the target API application according to the API service arrangement sequence of the target API application;

judging whether the last called API service is the ending API service of the target API application;

when the last called API service is the ending API service of the target API application, determining that the API service calling track is a normal track;

and when the last called API service is not the ending API service of the target API application, determining that the API service calling track is an abnormal track.

7. The method of claim 6, wherein presenting API service call tracks according to the call order comprises:

when the API service calling track is a normal track, presenting the API service calling track according to the calling sequence, wherein the API service calling track comprises primitives of the called API service and trajectory lines for connecting all the primitives of the called API service according to the calling sequence;

when the API service calling track is an abnormal track, presenting the API service calling track according to the calling sequence and the API service arranging sequence, the API service call trace includes primitives for called API services, primitives for un-called API services, connecting the trajectory lines of the primitives of all the called API services according to the calling sequence, connecting the layout lines of the primitives of all the un-called API services according to the API service layout sequence, and an arrangement line connecting the primitives of the called API service and the primitives of the un-called API service according to the API service arrangement sequence, the called API service includes calling a normal API service and calling an abnormal API service, and the presentation forms of the primitive calling the normal API service, the primitive calling the abnormal API service and the primitive not called the API service are different.

8. The method of claim 3, wherein determining the calling order of the API services in the target API application from the target commissioning log comprises:

and analyzing the target debugging log in a regular mode, and determining the calling sequence of the called API service in the target API application.

9. The method of claim 1, wherein obtaining a target commissioning log, the target commissioning log being a commissioning log generated during commissioning of a target API application, comprises:

sending a debugging request to an API gateway, wherein the debugging request carries an API application identifier and a first timestamp, the API application identifier indicates the target API application, and the first timestamp is a starting timestamp of debugging of the target API application;

receiving a debugging response sent by the API gateway, wherein the debugging response comprises the target debugging log, the target debugging log is the debugging log generated by the API gateway aiming at the target API application between a second timestamp and the first timestamp, and the second timestamp is an ending timestamp of the target API application debugging.

10. The method of any of claims 1 to 9, wherein prior to obtaining the target commissioning log, the method further comprises:

obtaining a debugging execution result, wherein the debugging execution result is an execution result of debugging the target API application;

presenting the debugging execution result;

the acquiring of the target survey log includes:

and when an analysis instruction triggered according to the debugging execution result is received, acquiring the target debugging log.

11. An apparatus for API application debugging, the apparatus comprising:

the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring a target debugging log, the target debugging log is generated in the debugging process of a target API application, and the target API application is formed by arranging at least one API service;

a second obtaining module, configured to obtain a target call log of a target API service from the target call log, where the target API service is any API service that is called in a process of testing the target API application;

the third acquisition module is used for acquiring key information in the target call log;

and the first presentation module is used for presenting the key information.

12. The apparatus of claim 11,

the second obtaining module is configured to obtain a target call log of the target API service from an association relationship between the called API service and the call log, where the association relationship between the called API service and the call log is established according to the target call log.

13. The apparatus of claim 12, further comprising:

a first determining module, configured to determine, according to the target debug log, a call order of API services in the target API application;

a fourth obtaining module, configured to obtain, from the target call log, a call log of each called API service;

and the establishing module is used for establishing the association relationship between the called API service and the call log according to each called API service and the corresponding call log.

14. The apparatus of claim 13, wherein the fourth obtaining module is configured to:

15. The apparatus of claim 11, further comprising:

a second determining module, configured to determine, according to the target debug log, a call order of API services in the target API application;

the second presentation module is used for presenting an API service calling track according to the calling sequence, wherein the API service calling track at least comprises primitives of the called API service and trajectory lines for connecting at least two primitives of the called API service according to the calling sequence, and the primitives of the API service indicate the API service;

and the second obtaining module is used for obtaining a target call log of the target API service from the target call log when an obtaining instruction triggered by the primitive aiming at the target API service is detected.

16. The apparatus of claim 15, further comprising:

a third determining module, configured to determine, according to the call order, a last called API service;

a fourth determining module, configured to determine, according to the API service arrangement order of the target API application, an end API service of the target API application;

the judging module is used for judging whether the last called API service is the ending API service of the target API application;

a fifth determining module, configured to determine that the API service calling track is a normal track when the last called API service is an end API service of the target API application;

a sixth determining module, configured to determine that the API service call trajectory is an abnormal trajectory when the last called API service is not the end API service of the target API application.

17. The apparatus of claim 16, wherein the second rendering module is configured to:

18. The apparatus of claim 13,

the first determining module is configured to analyze the target debugging log in a regular manner, and determine a calling order of the called API service in the target API application.

19. The apparatus of claim 11, wherein the first obtaining module is configured to:

20. The apparatus of any one of claims 11 to 19, further comprising:

a fifth obtaining module, configured to obtain a debugging execution result, where the debugging execution result is an execution result of debugging the target API application;

the third presentation module is used for presenting the debugging execution result;

the first obtaining module is used for obtaining the target debugging log when receiving an analysis instruction triggered according to the debugging execution result.

21. An API application deployment test apparatus, comprising: a processor, a communication interface, a memory, and a bus, the processor to execute instructions stored in the memory to implement the API application commissioning method of any one of claims 1 to 10.

22. A computer-readable storage medium having stored therein instructions which, when run on a processing component of a computer, cause the processing component to perform the API application commissioning method of any one of claims 1 to 10.

23. A computer program product comprising instructions for causing a computer to perform the API application commissioning method of any one of claims 1 to 10 when said computer program product is run on the computer.

24. A chip comprising programmable logic circuitry and/or program instructions for implementing the API application commissioning method of any one of claims 1 to 10 when said chip is run.