WO2020029375A1

WO2020029375A1 - Interface testing method and system, and computer device and storage medium

Info

Publication number: WO2020029375A1
Application number: PCT/CN2018/106403
Authority: WO
Inventors: 刘琼; 李琦
Original assignee: 平安科技（深圳）有限公司
Priority date: 2018-08-08
Filing date: 2018-09-19
Publication date: 2020-02-13
Also published as: CN109298997A

Abstract

An interface testing method and system, and a computer device and a storage medium. The method comprises: generating request data for an interface to be tested (S101); sending the request data to a server of the interface to be tested (S102); receiving response data for the request data returned by the server (S103); when a test task occurs, generating and outputting an origin log file according to an obtained dynamic invocation dependency relationship and a combination of each identified task, and storing the origin log file in an interface description database after performing data processing (S104); and invoking a service logic to verify received response data, returning a verification result, and generating an interface test report (S105). The method increases the coverage of abnormal test, reduces the investment of manual test and improves the test efficiency.

Description

Interface test method, system, computer equipment and storage medium

This application claims priority from a Chinese patent application filed with the Chinese Patent Office on August 08, 2018 with an application number of 201810893803.2 and an invention name of "Interface Test Method, System, Computer Equipment and Storage Medium", the entire contents of which are incorporated by reference In this application.

Technical field

The present application relates to the field of testing technology, and in particular, to an interface testing method, system, computer equipment, and storage medium.

Background technique

Web crawler tests usually only test normal scenarios. For account expiration, the returned table data is the boundary value, and the returned data has abnormal scenarios such as special characters and cannot be overwritten.

Database class test. Generally, the data configuration scenarios of the database are limited and cannot meet the requirements of normal data and abnormal data. API interface class tests. Generally, the return of the interface requires the cooperation of the server, and some rely on the return of the network, which cannot be achieved through real scenarios.

Scenario method is a method to improve the test effect by describing the function points or business processes of the system by using scenarios. The scenario method generally includes elementary streams and backup streams. Starting from a process, the process is determined by describing the path passed, and the entire scene is completed by traversing all the basic streams and backup streams.

Summary of the invention

Based on this, it is necessary to provide an interface test method, a system, a computer device, and a storage medium for the disadvantages of the current interface test method.

An interface testing method includes: generating request data for an interface to be tested; sending the request data to a server where the interface to be tested is located; receiving response data for the request data returned by the server; and when testing When a task occurs, the origin log file is generated and output according to the combination of the obtained dynamic invocation dependencies and each identified task, and after the origin log file is processed, it is stored in the interface description database, and the origin log file records For all data sending and receiving processes, the interface description database includes the interface name and its corresponding response data description; calling business logic to verify the received response data and returning the verification result to generate an interface test report.

An interface test system includes:

A generating module configured to generate request data for an interface to be tested;

A sending module configured to send the request data to a server where the interface to be tested is located;

A receiving module configured to receive response data for the request data returned by the server;

The calling module is set to generate and output the origin log file according to the combination of the obtained dynamic invocation dependencies and each identified task when the test task occurs, and after the origin log file is processed, it is stored in the interface description database The origin log file records the process of sending and receiving all data, and the interface description database includes an interface name and a corresponding response data description;

The verification module is configured to call business logic to verify the received response data and return a verification result to generate an interface test report.

A computer device includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor causes the processor to perform the steps of the interface test method.

A storage medium storing computer-readable instructions, when the computer-readable instructions are executed by one or more processors, cause the one or more processors to execute the steps of the foregoing interface test method.

The above interface test method, system, computer equipment and storage medium generate request data for the interface to be tested, send the request data to the server where the interface to be tested is located, and receive the request data returned by the server When the test task occurs, the origin log file is generated and output according to the combination of the obtained dynamic invocation dependencies and each identified task, and after the origin log file is processed, it is stored in the interface description database. The interface description database includes an interface name and a corresponding response data description, generates an interface test report for the interface to be tested according to the verification result, and establishes an association between the interface test report and the interface name of the interface to be tested Relationship, the interface test report includes one or more of request data, verification result, verification result status, and verification failure reason analysis of the interface to be tested, the verification result status includes success and failure, and an exception is added Test coverage, reducing manual testing Trial investment to improve testing efficiency.

BRIEF DESCRIPTION OF THE DRAWINGS

Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the detailed description of the preferred embodiments below. The drawings are only for the purpose of illustrating preferred embodiments and are not to be considered as limiting the present application.

FIG. 1 is a flowchart of an interface test method in an embodiment; FIG.

2 is a flowchart of calling an interceptor to generate and output an origin log file in an embodiment;

3 is a structural block diagram of an interface test system in an embodiment;

FIG. 4 is a structural block diagram of a calling module in an embodiment.

detailed description

In order to make the purpose, technical solution, and advantages of the present application clearer, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the application, and are not used to limit the application.

Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms "a", "an", "the" and "the" may include plural forms. It should be further understood that the word "comprising" used in the specification of the present application refers to the presence of the described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, Integers, steps, operations, elements, components, and / or groups thereof.

As a better embodiment, as shown in FIG. 1, an interface test method includes:

Step S101, generating request data for an interface to be tested;

Step S102, sending the request data to a server where the interface to be tested is located;

This technical solution provides a method for testing abnormal scenarios. By intercepting the returned messages, the simulation of message return in abnormal scenarios is realized, and the coverage of abnormal process branches can be achieved through automated testing. The coverage and regression of abnormal scenarios can be automated. No manual intervention is required during the test. Start the client and invoke the data generation tool. The data generation tool modifies the normal data source file in the excel file format based on the abnormal data generation rules, modifies it according to the rules entered by the client user, and finally generates the modified excel file and saves it to the specified Directory. The CASE name corresponding to the modified file is saved in the mapping folder, and the modified excel file is saved in the files folder. The data generation tool can be Quest Data Factory, which is a fast and easy to generate test data tool. It can model complex data relationships and has a GUI interface. As a powerful data generator, it allows Developers effortlessly generate millions of rows of meaningful test data.

The abnormal data generation rule has three operations, the three operations are: the first update command: the value of a certain row and a column can be updated, or it can be replaced with the boundary value, 0 value, and abnormal format value of this field ; The second is the delete command: you can delete discrete multiple lines, represented by x1, x2 ... xn, or you can delete consecutive multiple lines, represented by xy; the third is the copy increase command: multiple rows can be copied, x1, x2 ... xn means copy the discrete rows to the end of the table, while xy means copy the consecutive rows to the end of the table. For example, the operations that can be performed on the converted format are Update: Row-Column-Value, Delete: {x1, x2 ... xn / x-y rows}, Copy: {x1, x2 ... xn / x-y rows}. The normal data source file is a data source file that passes the code normal flow test. For some legal data, it has been saved in an excel file format in the previous period. The acquisition process is as follows: first crawl the corresponding web page address, or request the API interface address, or SQL query the corresponding table structure, convert the returned message into the data frame format through the python pandas package and save it into an excel file.

Step S103: Receive response data for the request data returned by the server;

After sending the request data to the server, the server receives the request data through the interface to be tested, performs operation processing according to the request parameter values in the request data, and returns the processing result, that is, the response data, to the server. The request data sender is described.

In step S104, when a test task occurs, the origin log file is generated and output according to the combination of the obtained dynamic invocation dependency and each identified task, and after the origin log file is processed, it is stored in the interface description database. The origin log file records the process of sending and receiving all data, and the interface description database includes the interface name and its corresponding response data description;

When a test task occurs, the service call interceptor generates and outputs the origin log file according to the service origin data specification, according to the obtained service dynamic invocation dependencies and the identified service combination of each task; the service origin data specification is a nine yuan Group, BasicProv (Token, InvokingService, ServiceInvoked, Location, Elapsedtime, Timestamp, Input, Output, Status); The data specification parameters of the service origin have the following meanings: Token: a 32-bit string used to identify a dynamic combined task , InvokingService: service caller, also known as service consumer. The data format is a 32-bit string. Servicelnvoked: The service callee, which can also be called a service provider. The data format is a 32-bit string. Location: The location where the service call occurred. In the cloud service environment, it is mainly the IP address. Elapsed time: The time taken for the service call. This time is the time required to complete a service call from the perspective of the service caller, including the nested execution time of the called service. The data format is an eight-bit integer type in milliseconds. Timestamp: Timestamp of the service call event, the format is year / month / day hour / minute / second / millisecond, Input: input parameters of the service call, the data storage format is a 32-bit string. Output: The output data file of the service call, usually an XML object or a json data object. Status: The status of the service execution. The data format is a Boolean value. 1 indicates success and 0 indicates failure. The origin log file is generated and output based on the obtained dynamic call dependencies and each identified task, and the origin log file is output. After data processing, it is stored in the interface description database. The origin log file records the process of sending and receiving all data, which is convenient for analyzing the origin of the test exception or fault. The interface description database includes the interface name and its corresponding response data description. The scalability of acquisition. In the process of collecting interceptor information, in order to provide support for heterogeneous systems, the interceptor and interceptor management are separated. The management module is responsible for all interception registration, log collection, and processing. The interceptor is responsible for capturing the origin of the service and Standard output log. Different interceptors can be designed according to different service protocols. The interceptor and management module are loosely coupled. The strategy and method of interceptor operation is achieved by reading an XML configuration file, which is managed and managed by the management module. Maintenance. By updating and modifying this file, the interceptor implements different sampling strategies and execution methods. All interceptors use common standard data specifications and transmission protocols. When a service call interceptor intercepts a service call request, the interception frequency of the service call interceptor is determined according to different service call frequencies.

In step S105, the business logic is invoked to verify the received response data and return the verification result to generate an interface test report.

The abnormal data generated by the abnormal data generating tool is used as the input of the business code, and the business code is normally called for execution and the result is returned. By querying the database records, the returned results are matched with the relevant records. If the match is successful, the test is successful. The test is verified as a pass. If the match fails, the test is failed and the verification is a fail. . There are different judgments on what the matching result is success and failure, and the specific business logic shall prevail. The business code refers to the business logic to be executed in the test case. For example, the test crawler returns null, and the test crawler returns a user name error. The return after executing the business code is the return result.

As shown in FIG. 2, in one embodiment, when a test task occurs, the source log file is generated and output according to the combination of the obtained dynamic invocation dependency and each identified task, and the origin log file is processed. After the data is processed, it is stored in the interface description database including:

Step S201: design a call interceptor according to the service framework and the call protocol;

The design of the call interceptor includes creating a file for storing the origin information of the service. The caller generates a unique token value, which is used to identify the dynamic dependency of the service. It also creates parameters for reading and storing the call start time. Read and store the parameters of the current IP address, create a parameter to store the called task name, and create a parameter to store the entry parameters of the called task. The above parameters, file, and token value together constitute the call interceptor. The unique token value is generated based on time and network card.

Step S202, the call interceptor is built into the call protocol;

The service call interceptor is built into the service call protocol. When a service call occurs, the service call interceptor intercepts the service call request, obtains the dynamic call dependency, and identifies the combination of each task.

Step S203: When the call occurs, the call interceptor intercepts the call request, obtains the dynamic call dependency, and identifies the combination of each task;

The service call interceptor generates and outputs the origin log file according to the service origin data specification, according to the obtained dynamic invocation dependency and each identified task; the service origin data specification is a nine-tuple, BasicProv (Token, InvokingService, ServiceInvoked, Location, Elapsed time, Timestamp, Input, Output, where Token is a 32-bit string used to identify a dynamic combined task, Invoking Service is a service caller, also known as a service consumer, and its data format Is a 32-bit string, Service Invoked is the service callee, also known as the service provider, its data format is a 32-bit string, Location is the location where the service call occurs, and in the cloud service environment, it is the IP address Elapsed time is the time taken by the service call, which is the time required to complete a service call from the perspective of the service caller, including the nested execution time of the called service, and its data format is an 8-bit Integer; [0022] Timestamp is the timestamp of the service call event, Input is the input of the service call Input parameters, the data storage format is a 32-bit string, Output is the output data file of the service call, an XML object, or a json data object, Status is the status of the service execution, the data format is a Boolean value, 1 means success , 0 means failure.

In step S204, the call interceptor generates and outputs the origin log file according to the combination of the originating data specification and the obtained dynamic invocation dependency and each identified task;

The call interceptor will generate and output the origin log file according to the origin data specification, according to the combination of the obtained dynamic invocation dependencies and each identified task. Read the service origin log records and check whether it conforms to the current service origin data specifications. Users can set the service origin data specifications as required. For example, when distributed debugging is not required, the service input and output may not be intercepted. The related information is not checked when the format check is performed.

Step S205: After the origin log file is processed, it is stored in the interface description database.

After the origin log file is processed, it is stored in the interface description database, and the service origin log is stored on the local server where the service is located. Through the log collection tool, data is read, transmitted, and inserted into the database.

In one embodiment, the invoking business logic verifies the received response data and returns a verification result, and generating an interface test report includes:

Generating an interface test report for the interface to be tested according to the verification result, and establishing an association relationship between the interface test report and the interface name of the interface to be tested, the interface test report including request data of the verified interface to be tested One or more of verification result, verification result status, and verification result failure cause analysis, the verification result status includes success and failure.

In one embodiment, performing data processing on the origin log file includes: checking the integrity of the origin data information in the origin log file, discarding the data that does not meet the requirements, and then normalizing the origin data information that meets the requirements, then inserting it into the database, The origin log files are aggregated and stored in the interface description database.

Check the integrity of the origin data information in the origin log file, discard the data that does not meet the requirements, then normalize the origin data information that meets the requirements, and then insert it into the database to aggregate and store the origin log files in the database. This structure realizes the collection of Scalability.

In one embodiment, the interface test method further includes: using the received response data as test data of an interface to be tested, and establishing an association relationship between the interface test data and an interface name of the interface to be tested.

The received response data is used as the test data of the interface to be tested, and the association relationship between the interface test data and the interface name of the interface to be tested is established. Interface refers to the communication rules between different functional layers of the same system, and provides an interface as a service. In an end-to-end interface system, it is particularly important to ensure the quality and stability of the interface that the front and back interact with, and the quality of the interface is particularly important. And stability is verified through interface testing during interface development.

As shown in FIG. 3, in one embodiment, an interface test system includes:

In one embodiment, the generating module includes a normal data source file modification unit configured to call a data generation tool to modify the normal data source file based on the abnormal data generation rule, wherein the abnormal data generation rule has three operations: first One is the update command; the second is the delete command; the third is the copy add command.

As shown in FIG. 4, in an embodiment, the calling module further includes:

Design unit, set to design the call interceptor according to the service framework and the call protocol;

Built-in unit, set to embed the call interceptor in the calling protocol;

The interception unit is set to call the interceptor to intercept the call request when the call occurs, obtain the dynamic call dependency, and identify the combination of each task;

The calling unit is set to make the call interceptor generate and output the origin log file according to the combination of the dynamic invocation dependency and each identified task according to the origin data specification;

The storage unit is configured to store the origin log file in the interface description database after data processing.

In one embodiment, the verification module is further configured to generate an interface test report for the interface to be tested according to the verification result, and establish an association relationship between the interface test report and the interface name of the interface to be tested. The interface test report includes one or more of the requested data of the verified interface to be tested, the verification result, the status of the verification result, and the analysis of the cause of the failure of the verification result. The status of the verification result includes success and failure.

In one embodiment, the calling module includes: a source log processing unit configured to check the integrity of the source data information in the source log file, discard the data that does not meet the requirements, and then normalize the source data information that meets the requirements, and then insert Database, which aggregates and stores the origin log files in the interface description database.

In one embodiment, the verification module includes: an abnormal data input unit configured to take the abnormal data generated by the abnormal data generating tool as input of a business code, and normally call the business code to execute and return the result; and the query matching unit is set to Query the database records and match the returned results with the related records. If the match is successful, the test is successful and the test is passed. If the match fails, the test is failed and the verification is Fail.

In one embodiment, the calling module includes a call interceptor design unit, and the call interceptor design unit includes: an origin information file creation unit configured to create a file for storing service origin information; a Token value generation unit, set To generate a unique token value based on time and network card, as a sign to identify the dynamic dependency of the service;

Call start time parameter creation unit, set to create a parameter to read and store the call start time; current IP address parameter creation unit, set to create a parameter to read and store the current IP address; task name parameter creation unit , Set to create a parameter for storing the called task name; task entry parameter parameter creation unit, set to create a parameter for storing the entry parameter of the called task;

The call interceptor constituting unit is set to a file created according to the origin information file creation unit, a Token value generated by the Token value generation unit, a call start time created by the call start time parameter creation unit, and the current IP address The current IP address created by the parameter creation unit, the task name created by the task name parameter creation unit, and the entry parameters of the called task created by the task entry parameter parameter creation unit together constitute a call interceptor.

In one embodiment, the calling unit includes:

Origin data specification checking unit, which is set to read service origin log records and check whether it conforms to the current service origin data specification;

The origin data specification setting unit is set to set the specification requirements of the service origin data so that when distributed debugging is not required, the input and output of the service are not intercepted, and the relevant information is not checked when the format is checked.

In one embodiment, the interface test system further includes an association establishing module. The association relationship establishing module is configured to use the received response data as test data of an interface to be tested, and establish an association relationship between the interface test data and an interface name of the interface to be tested.

In one embodiment, a computer device is provided. The computer device includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor is caused to execute the foregoing embodiments. Steps in the interface test method.

In one embodiment, a storage medium storing computer-readable instructions is provided. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the interfaces in the foregoing embodiments. Steps of the test method. The storage medium may be a non-volatile storage medium.

A person of ordinary skill in the art may understand that all or part of the steps in the various methods of the foregoing embodiments may be implemented by a program instructing related hardware. The program may be stored in a computer-readable storage medium. The storage medium may include: Read-only memory (ROM, Read Only Memory), random access memory (RAM, Random Access Memory), magnetic disks or optical disks, etc.

The technical features of the embodiments described above can be arbitrarily combined. In order to simplify the description, all possible combinations of the technical features in the above embodiments have not been described. However, as long as there is no contradiction in the combination of these technical features, It should be considered as the scope described in this specification.

The above-mentioned embodiments only express some exemplary embodiments of the present application, and their descriptions are more specific and detailed, but cannot be understood as a limitation on the scope of the patent of the present application. It should be noted that, for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can be made, which all belong to the protection scope of the present application. Therefore, the protection scope of this application patent shall be subject to the appended claims.

Claims

An interface test method, including:

Generate request data for the interface to be tested;

Sending the request data to a server where the interface to be tested is located;

Receiving response data for the request data returned by the server;

When a test task occurs, the origin log file is generated and output according to the combination of the obtained dynamic invocation dependencies and each identified task, and after the origin log file is processed, it is stored in the interface description database. The origin log The file records the process of sending and receiving all data. The interface description database includes the interface name and its corresponding response data description.

Call the business logic to verify the received response data and return the verification result to generate an interface test report.
The interface test method according to claim 1, wherein the generating request data for an interface to be tested comprises calling a data generation tool to modify a normal data source file based on abnormal data generation rules, wherein there are three types of abnormal data generation rules Operation: the first is the update command; the second is the delete command; the third is the copy increase command.
The interface test method according to claim 1, wherein, when a test task occurs, generating and outputting an origin log file according to a combination of the obtained dynamic invocation dependency and each identified task, and performing the origin log file After the data is processed, it is stored in the interface description database including:

Design the call interceptor according to the service framework and call protocol;

The call interceptor is built into the call protocol;

When the call occurs, the call interceptor intercepts the call request, obtains the dynamic call dependencies, and identifies the combination of each task;

The call interceptor generates and outputs the origin log file according to the origin data specification, according to the combination of the obtained dynamic invocation dependencies and each identified task;

After the origin log file is processed, it is stored in the interface description database.
The interface test method according to claim 1, wherein the invoking business logic verifies the received response data and returns a verification result, and generating the interface test report comprises:

Generating an interface test report for the interface to be tested according to the verification result, and establishing an association relationship between the interface test report and the interface name of the interface to be tested, the interface test report including request data of the verified interface to be tested One or more of verification result, verification result status, and verification result failure cause analysis, the verification result status includes success and failure.
The interface testing method according to claim 1, wherein the data processing on the origin log file comprises: checking the integrity of the origin data information in the origin log file, discarding the data that does not meet the requirements, and then normalizing the origin data information that meets the requirements , Then insert it into the database, aggregate and store the origin log files in the interface description database.
The interface test method according to claim 1, wherein the invoking business logic verifies the received response data and returns a verification result, and generating the interface test report comprises:

Use the exception data generated by the exception data generation tool as the input of the business code, call the business code for execution normally and return the result;

By querying the database records, the returned results are matched with the related query records. If the matching is successful, the test is successful, and the test is verified as a pass. If the matching fails, the test is failed and the verification is performed. As fail.
The interface test method according to claim 1, wherein the designing a call interceptor according to a service framework and a call protocol includes designing the call interceptor, and specifically includes:

Create files for storing service origin information;

Generate a unique Token value based on time and network card, as a sign to identify the dynamic dependency of the service;

Create a parameter to read and store the start time of the call;

Create parameters for reading and storing the current IP address;

Create a parameter to store the name of the called task;

Create parameters for storing the entry parameters of the called task;

The above parameters, files, and token values together constitute the call interceptor.
The interface test method according to claim 1, wherein the call interceptor generates and outputs an origin log file according to the origin data specification, according to a combination of the obtained dynamic invocation dependency and each identified task, comprising:

Read service origin log records and check if they conform to current service origin data specifications;

The specification of setting the service origin data requires that when distributed debugging is not needed, the input and output of the service is not intercepted, and the related information is not checked when the format is checked.
The interface test method according to claim 1, further comprising: using the received response data as test data of an interface to be tested, and establishing an association relationship between the interface test data and an interface name of the interface to be tested.
An interface test system, wherein the interface test system includes:

A generating module configured to generate request data for an interface to be tested;

A sending module configured to send the request data to a server where the interface to be tested is located;

A receiving module configured to receive response data for the request data returned by the server;

The calling module is set to generate and output the origin log file according to the combination of the obtained dynamic invocation dependencies and each identified task when the test task occurs, and after the origin log file is processed, it is stored in the interface description database The origin log file records the process of sending and receiving all data, and the interface description database includes an interface name and a corresponding response data description;

The verification module is configured to call business logic to verify the received response data and return a verification result to generate an interface test report.
The interface test system according to claim 10, wherein the generating module comprises:

The normal data source file modification unit is set to call a data generation tool to modify a normal data source file based on abnormal data generation rules, wherein the abnormal data generation rule has three operations: the first is an update command; the second is a delete command; The third is to add commands for replication.
The interface test system according to claim 10, wherein the calling module further comprises:

Design unit, set to design the call interceptor according to the service framework and the call protocol;

Built-in unit, set to embed the call interceptor in the calling protocol;

The interception unit is set to call the interceptor to intercept the call request when the call occurs, obtain the dynamic call dependency, and identify the combination of each task;

The calling unit is set to make the call interceptor generate and output the origin log file according to the combination of the dynamic invocation dependency and each identified task according to the origin data specification;

The storage unit is configured to store the origin log file in the interface description database after data processing.
The interface test system according to claim 10, wherein the verification module is further configured to generate an interface test report for the interface to be tested according to the verification result, and establish an interface between the interface test report and the interface to be tested Association relationship of names, the interface test report includes one or more of request data, verification results, verification result status, and verification failure cause analysis of the interface to be tested, the verification result status includes success and failure .
The interface test system according to claim 10, wherein the calling module comprises:

The origin log processing unit is configured to check the integrity of the origin data information in the origin log file, discard the data that does not meet the requirements, then normalize the origin data information that meets the requirements, and then insert it into the database to aggregate and store the origin log files in the interface description database.
The interface test system according to claim 10, wherein the verification module comprises:

The abnormal data input unit is set to use the abnormal data generated by the abnormal data generating tool as input of the business code, and normally call the business code to execute and return the result;

The query matching unit is configured to query the database records and match the returned result with the related query records. If the matching is successful, the test is successful, and the test is verified to pass. If the matching fails, then This test failed, and the verification was failed.
The interface test system according to claim 10, wherein the calling module comprises a call interceptor design unit, and the call interceptor design unit comprises:

Origin information file creation unit, set to create a file for storing service origin information;

Token value generation unit, set to generate a unique Token value according to time and network card, as a sign to identify the dynamic dependency of the service;

Call start time parameter creation unit, set to create a parameter for reading and storing the call start time;

The current IP address parameter creation unit is set to create parameters for reading and storing the current IP address;

Task name parameter creation unit, set to create a parameter for storing the called task name;

Task entry parameter parameter creation unit, which is set to create a parameter for storing entry parameters of the called task;

The call interceptor constituting unit is set to a file created according to the origin information file creation unit, a Token value generated by the Token value generation unit, a call start time created by the call start time parameter creation unit, and the current IP address The current IP address created by the parameter creation unit, the task name created by the task name parameter creation unit, and the entry parameters of the called task created by the task entry parameter parameter creation unit together constitute a call interceptor.
The interface test system according to claim 10, wherein the calling unit comprises:

Origin data specification checking unit, which is set to read service origin log records and check whether it conforms to the current service origin data specification;

The origin data specification setting unit is set to set the specification requirements of the service origin data so that when distributed debugging is not required, the input and output of the service are not intercepted, and the relevant information is not checked when the format is checked.
The interface test system according to claim 10, further comprising an association establishing module configured to use the received response data as test data of an interface to be tested, and establish an interface name of the interface test data and the interface to be tested Relationship.
A computer device includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor causes the processor to perform the following steps:

Generate request data for the interface to be tested;

Sending the request data to a server where the interface to be tested is located;

Receiving response data for the request data returned by the server;

When a test task occurs, the origin log file is generated and output according to the combination of the obtained dynamic invocation dependencies and each identified task, and after the origin log file is processed, it is stored in the interface description database. The origin log The file records the process of sending and receiving all data. The interface description database includes the interface name and its corresponding response data description.

Call the business logic to verify the received response data and return the verification result to generate an interface test report.
A storage medium storing computer-readable instructions, wherein when the computer-readable instructions are executed by one or more processors, the one or more processors execute the following steps:

Generate request data for the interface to be tested;

Sending the request data to a server where the interface to be tested is located;

Receiving response data for the request data returned by the server;

When a test task occurs, the origin log file is generated and output according to the combination of the obtained dynamic invocation dependencies and each identified task, and after the origin log file is processed, it is stored in the interface description database. The origin log The file records the process of sending and receiving all data. The interface description database includes the interface name and its corresponding response data description.

Call the business logic to verify the received response data and return the verification result to generate an interface test report.